Wejście na informatyczną ścieżkę uzależnienia w diagnozie UZP
Urząd Zamówień Publicznych przygotował Rekomendacje Udzielania Zamówień Publicznych na Systemy Informatyczne. Powód? "Zaobserwowane w praktyce kontrolnej Urzędu Zamówień Publicznych, niepokojące zjawisko nadużywania przez zamawiających trybu z wolnej ręki w przypadku udzielania zamówień związanych z systemami informatycznymi". W udostępnionym dokumencie pojawiają się interesujące tezy.
Już jakiś czas temu ta notatka pojawiła się na stronach UZP: Rekomendacje Urzędu Zamówień Publicznych dotyczące udzielania zamówień na systemy informatyczne, jest i sama rekomendacja w PDF. Warto zwrócić tu uwagę na diagnozę Urzędu, który mówi o opisywanym w tym serwisie czasem zjawisku "vendor lock in" - czyli wejścia na ścieżkę uzależnienia (por. dział zamówienia publiczne, ale również standardy). Temat ten wiąże się z problematyką neutralności technologicznej i interoperacyjnością.
Ze wstępu do dokumentu UZP (wytłuszczenie moje):
W praktyce kontrolnej Urzędu Zamówień Publicznych, w szczególności w ramach analizy przesyłanych Prezesowi Urzędu obligatoryjnych zawiadomień o wszczęciu postępowania o zamówienie publiczne daje się zaobserwować niepokojące zjawisko dużej skali udzielania zamówień w trybie z wolnej ręki związanych z systemami informatycznymi. Zamówienia takie skutkują wydatkowaniem wielomilionowych kwot rocznie, osiągając w skrajnych przypadkach poziom około 100 mln złotych rocznie wydatkowanych przez jednego zamawiającego. Analizowane przez UZP przypadki dotyczą udzielania kolejnych zamówień w trybie z wolnej ręki często wielokrotnie przekraczających swą wartością zamówienie podstawowe udzielone w trybie konkurencyjnym. W przeważającej większości takich zamówień ich przedmiotem są prace nad rozbudową i modyfikacją systemów informatycznych, czy też zamawiania usług, oprogramowania lub sprzętu niezbędnego do utrzymywania infrastruktury lub oprogramowania gotowego zlecane dotychczasowemu wykonawcy.
Przyczyną opisanego tu zjawiska jest powstanie „uzależnienia” zamawiającego od pierwotnego wykonawcy systemu lub producenta sprzętu lub oprogramowania gotowego uniemożliwiające nabycie niezbędnych usług lub dostaw w trybach konkurencyjnych. Uzależnienie to jest w dużej mierze konsekwencją niewłaściwego przygotowania postępowania i udzielenia zamówienia publicznego. Tymczasem źle przeprowadzony proces udzielania zamówienia podstawowego skutkujący koniecznością udzielenia zamówienia w trybie z wolnej ręki nie jest wystarczającą podstawą do stosowania trybu zamówienia z wolnej ręki. Tryb ten bowiem nie gwarantuje przejrzystości, a praktyka taka jest nie do zaakceptowania w świetle podstawowych zasad ustawy Prawo zamówień publicznych (dalej: Pzp).
Zgodnie z art. 10 ustawy Pzp podstawowymi trybami udzielenia zamówienia są przetarg nieograniczony oraz przetarg ograniczony. Przepis ten służy realizacji podstawowych zasad wynikających z Traktatu Ustanawiającego Wspólnotę Europejską oraz wyrażonych w art. 7 ust. 1 ustawy Pzp tj. zasady przejrzystości, uczciwej konkurencji, niedyskryminacji i równego traktowania. Zastosowanie innego trybu niż przetarg nieograniczony lub ograniczony wymaga spełnienia przesłanek określonych w ustawie, które jako uzasadniające odstępstwo od podstawowej reguły należy interpretować ściśle. Do takich odstępstw należy zaliczyć zawieranie umów w wyniku przeprowadzenia postępowania w trybie z wolnej ręki. We wszystkich takich przypadkach do zamawiającego należy obowiązek wykazania podstawy dla zastosowania odstępstwa od zasady stosowania trybów podstawowych.
W przypadku zamówień informatycznych zamawiający często korzystają z tego trybu powołując się bądź na przyczyny techniczne bądź na przyczyny związane z ochroną praw wyłącznych. Zarówno dyrektywa 2004/18/WE (art. 31) jak i wdrażająca ją ustawa Pzp (art. 67 ust. 1 pkt 1 lit. a) i b) – zamówienie z wolnej ręki), wymieniają te przesłanki wśród przyczyn uzasadniających zastosowanie trybu niekonkurencyjnego, jednakże nie można z nich korzystać w całkowitym oderwaniu od podstawowych zasad traktatowych.
(...)
Proponuję lekturę całej rekomendacji, która ma jedynie 33 strony.
A jako dodatek proponuję tekst US Department of Defense Embraces Open Source, a chodzi o dokument - memorandum: Clarifying Guidance Regarding Open Source Software (OSS) (PDF)
- Login to post comments
Piotr VaGla Waglowski
Piotr VaGla Waglowski - prawnik, publicysta i webmaster, autor serwisu VaGla.pl Prawo i Internet. Ukończył Aplikację Legislacyjną prowadzoną przez Rządowe Centrum Legislacji. Radca ministra w Departamencie Oceny Ryzyka Regulacyjnego a następnie w Departamencie Doskonalenia Regulacji Gospodarczych Ministerstwa Rozwoju. Felietonista miesięcznika "IT w Administracji" (wcześniej również felietonista miesięcznika "Gazeta Bankowa" i tygodnika "Wprost"). Uczestniczył w pracach Obywatelskiego Forum Legislacji, działającego przy Fundacji im. Stefana Batorego w ramach programu Odpowiedzialne Państwo. W 1995 założył pierwszą w internecie listę dyskusyjną na temat prawa w języku polskim, Członek Założyciel Internet Society Poland, pełnił funkcję Członka Zarządu ISOC Polska i Członka Rady Polskiej Izby Informatyki i Telekomunikacji. Był również członkiem Rady ds Cyfryzacji przy Ministrze Cyfryzacji i członkiem Rady Informatyzacji przy MSWiA, członkiem Zespołu ds. otwartych danych i zasobów przy Komitecie Rady Ministrów do spraw Cyfryzacji oraz Doradcą społecznym Prezesa Urzędu Komunikacji Elektronicznej ds. funkcjonowania rynku mediów w szczególności w zakresie neutralności sieci. W latach 2009-2014 Zastępca Przewodniczącego Rady Fundacji Nowoczesna Polska, w tym czasie był również Członkiem Rady Programowej Fundacji Panoptykon. Więcej >>
A jak to wygląda w praktyce...
No Panie Piotrze poruszył Pan nader ciekawy wątek. Zamawiający, wręcz zaczęli już cytować wspomnianą rekomendacje w dokumentach przetargowych i wyjaśnieniach do specyfikacji (vide: http://bip.koscierzyna.gda.pl/i/przetargi/zp32_09_pismo3.pdf). Ciekawe swoją drogą jak zachowają się teraz wykonawcy systemów informatycznych, którzy tworzyli swoje systemy (nie wszystkie są bowiem dedykowane) całe lata a teraz z "ochotą" przekażą do nich majątkowe prawa autorskie Zamawiającemu. Ciekawe też jak będzie wyglądać np. asysta techniczna takiego oprogramowania świadczona przez Wykonawcę niebędącego producentem danego systemu. Ja rozumiem, że nastąpi swoiste "przejęcie wiedzy" (w tym możliwość poznania technologi rozwiązań konkurencji itp.) ale jak długo będzie to trwać?
To prawda, widzialem juz
To prawda, widzialem juz takie SIWZy.
Oprogramowanie państwowe
Tego dałoby się uniknąć gdyby wprowadzić prostą zasadę: SIWZ musi uwzględniać przekazanie kodu źródłowego wraz z niezbędnymi licencjami umożliwiającymi co najmniej wykorzystanie tego kodu w dowolnym innym projekcie administracji publicznej. Czyli nie całkiem open source, ale do dyspozycji całego sektora publicznego. W ten sposób przynajmniej nie płacilibyśmy po parę razy za to samo. Marcin Cieślak sporo o tym mówił przy różnych okazjach.
1% na Fundację Nowoczesna Polska, KRS: 0000070056;
A wystarczy jakby powstał wspólny system zapisu danych
Problem jest i dobrze, że ktoś to zauważa. Nie wiem tylko czy wspomniany sposób (przekazanie praw albo kodów źródłowych) jest odpowiedni. Ilość baz danych i oprogramowania jest liczbą skończoną, tzn. da się określić wszystkie dziedziny zastosowania oprogramowania tak dla instytucji państwowych jak i samorządowych. Wystarczyło by teraz określić, że systemy z danej dziedziny mają "na wyjściu" generować to samo aby można było płynnie przechodzić pomiędzy systemami. Dzięki temu nie było by problemu z wymianą informacji pomiędzy instytucjami, które mają inne programy do tego samego. Instytucja mogła by też dowolnie dobierać sobie oprogramowanie bo bazy danych były by prowadzone w identyczny sposób.
Stan obecny jest taki że trzeba wybierać system od tego kto na danym terenie ma więcej wdrożeń, aby można było się wymieniać bez problemów danymi.
Dotyczy to również BIP'ów gdzie słyszałem o pojedynczych przypadkach zmiany dostawcy rozwiązania, a migracja z jednego rozwiązania na drugie była drogą przez mękę.
Pomysł już jest ujęty w przepisie polskiego prawa.
Witam.
A może by tak wrócić pamięcią do rozporządzenia o wymaganiach minimalnych? Tam było wiele ujęte, tylko trzeba było wymusić przestrzeganie tego rozporządzenia. A co do jednolitego systemu zapisu, to efektywnie najbardziej zbliżonym do neutralności jest csv, albo xml. Ten pierwszy jest tak stary jak komputery :-) , ten drugi pojawił się jako rozwinięcie idei tworzenia stron www, składających się najczęściej w 99% z tekstu.
Osobiście uważam, że kodowanie znaków UTF-8 i plik csv załatwia każdą sprawę przeniesienia danych z aplikacji do aplikacji. Każdy program musi być wyposażony w moduł export/import takiego pliku wg struktury wskazanej przez użytkownika. Struktury odzwierciedlającej konfigurację krotek w bazie danych danej aplikacji importującej.
Ominie się wtedy konieczność ujawniania kodu źródłowego itp. Plik csv jest prosty, mało waży i co najważniejsze - otwiera się w każdym systemie, i dowolną aplikacją bo jest plikiem tekstowym. Plik xml wymaga niestety dodatkowej aplikacji potrafiącej odczytać zinterpretować zawartość opisaną meta znacznikami. To tak mocno skrótowo w temacie jednego formatu.
Tak na marginesie, ja stosuję ten system od wielu lat i to z powodzeniem. Bywają tylko czasem utrudnienia związane z kodowaniem znaków w windowsie, ale wystarczy malutka procedurka konwertująca i po sprawie.
Aż dziw bierze, że wciąż wyważa się otwarte drzwi w informatyce. A wystarczy poczytać o systemach operacyjnych i przenoszeniu danych zanim pojawił się Windows. Jak widać chętnych do czytania jest niewielu. Dobrze, że chociaż tu czytają.
Pozdrawiam
Niestety nie da się tego uniknąć :(
Niestety w praktyce jest tak, że skuteczne przeprowadzenie przetargu tak, aby uniknąć vendor lock-in, jest praktycznie niemożliwe. Bo co komu po przetargu, z którego nic nie wyjdzie?
Mam takie doświadczenia. Próbowaliśmy na uczelni, na której pracowałem, skonstruować przetarg na system informatyczny tak, aby uniknąć uzależnienia od konkretnego dostawcy. Między innymi miały to zapewniać takie wymagania jak korzystanie przez system z zewnętrznej bazy danych, wspólnej dla wszystkich obecnych i przyszłych aplikacji, której struktura miała być własnością zamawiającego, a nie dostawcy. Alternatywnie był wymóg możliwości eksportu/importu wszelkich danych z systemu w plikach XML o udokumentowanej strukturze, tak aby można było wymieniać dane z dowolnymi innymi aplikacjami.
Jaki był rezultat? Nikt nie zgłosił się do przetargu, mimo że uczelnia była wciąż bombardowana marketingowymi materiałami od firm zachwalających swoje rozwiązania dla uczelni, które oczywiście - a jakże! - mają najlepsze, sęk w tym że współpracują tylko same z sobą...
W polskich firmach software'owych cały czas dominuje nastawienie na sprzedanie "z półki" gotowca, którego już się ma, a nie pisanie systemu pod wymagania klienta. Jeżeli zdarzy się firma, która napisze system pod wymagania klienta, to z reguły chodzi o małe systemiki do małych zastosowań. Z kolei od dwóch takich firm próbowaliśmy uzyskać kod źródłowy. Jedna odmówiła kategorycznie - stwierdzili, ze jeżeli mieliby udostępnić kod źródłowy, to oni rezygnują z tego zamówienia i takiej umowy nie podpiszą, bo jest to - jak twierdzili - dla nich skrajnie niekorzystne biznesowo. Druga zażądała za udostępnienie kodu źródłowego dziesięciokrotnie (!) wyższej ceny niż za "normalne" wykonanie zamówienia, bez udostępnienia źródeł. Więc oczywiście wiadomo, że nikt na taką ofertę nie poszedł...
I tak wyglądają realia... :(
Druga zażądała za
To jest akurat dość oczywiste - to znaczy nie wiem jak konkretnie w tym przypadku, ale ogólnie mamy dwa przeciwległe modele:
1) Firma pisze np. system obiegu dokumentów i sprzedaje go 100 urzędom po 10 tys.
2) Firma sprzedaje go 1 agencji rządowej z prawem do wielokrotnej instalacji i kodem źródlowym za 1 mln zł, a agencja rozdaje uczelniom za darmo
W obu przypadkach firma osiąga 1 mln zł przychodu.
Fakt, że w przypadku waszej uczelni wyglądało to absurdalnie drogo wynika z faktu, że przy takiej licencji de facto kupowalibyście ten system dla siebie i wszystkich przyszłych użytkowników. Co jest oczywiście nieopłacalne z punktu widzenia waszego budżetu.
Ale z punktu widzenia sponsora uczelni jakim jest budżet państwa zakup takiego softu centralnie i rozdanie go za darmo uczelniom byłby już racjonalny - bo zamiast 100 przetargów po 10 tys. byłby jeden duży i soft byłby dostępny dla każdej następnej uczelni za darmo.
Co więcej, wartość dodana dla użytkowników jest taka, że mogą sami modyfikować kod lub ogłaszać kolejne przetargi na jego modyfikację przez dowolną firmę. Wartość dodana dla tego kto sprzedał również jest wymierna, bo ma automatycznie przewagę konkurencyjną w przetargach na support i rozbudowę tego systemu.
--
Podpis elektroniczny i bezpieczeństwo IT
http://ipsec.pl/
Nie do końca sie zgodzę
"Fakt, że w przypadku waszej uczelni wyglądało to absurdalnie drogo wynika z faktu, że przy takiej licencji de facto kupowalibyście ten system dla siebie i wszystkich przyszłych użytkowników."
Nie do końca się zgodzę, bo przecież firma mogła nam udostępnić kod z zastrzeżeniem, że jest tylko do naszego użytku i nie możemy go dalej udostępniać nikomu innemu. Udostępnienie kodu źródłowego nie oznacza przecież automatycznie przekazania praw autorskich - takie sprawy można uregulować umową, licencją itp...
Dokładnie
Dokładnie tak jest robione dla korporacji dla których współtworzyłem systemy. Dostawali i aplikację i kod, oczywiście nie do dalszego obrotu nim. Jest to zabezpieczenie na przyszłość:
- może jakaś migracja
- może jakieś zmiany
- może firma dostarczająca rozwiązanie (my) zbankrutuje
Nie zdarzyło się jeszcze aby nasz kod był zmieniany przez kogoś innego niż my, zdarzyło się że my poprawialiśmy rozwiązania dostarczone przez kogoś innego.
To fakt. Pytanie dlaczego
To fakt. Pytanie dlaczego firma postawiła takie zaporowe warunki dla udostępnienia źródeł? Ja się zetknąłem z sytuacją, w której firma musiała najpierw "przygotować" kod do takiej operacji to znaczy usunąć z niego żenujące niedoróbki, puste miejsca "tu napisać moduł X", fragmenty ukradzione z innych projektów oraz komentarze w hindi :)
--
Podpis elektroniczny i bezpieczeństwo IT
http://ipsec.pl/
A może zrobić zamiast kupić?
Witam.
Trochę to zaskakujące, że uczelnia ogłasza przetarg na coś co może mieć własnym sumptem. Niewiele jest obecnie uczelni, które nie mają w swojej ofercie kierunku informatycznego. A przecież to po takich studiach, ludzie powinni umieć pisać programy! Co za problem w ramach dydaktyki zrealizować projekt oprogramowania potrzebnego uczelni, zamiast kupować gotowy produkt. Dla uczelni to czysty zysk. Studenci mogą uczyć się użytecznego zagadnienia programistycznego, mogą rozwijać bądź przebudowywać projekt, w zależności od potrzeb uczelni. No chyba, że jednak te kierunki informatyczne są mocno przereklamowane i nie są w stanie wykształcić koderów i analityków zagadnienia. W takim przypadku byłaby to smutna prawda... I lepiej nie dociekać przyczyny.
A skoro nikt się nie zgłosił do przetargu to jaki problem uruchomić ten proces choćby od najbliższego semestru.
Pozdrawiam.
Student nie jest za darmo
Żaden, ale ile będzie kosztować opłacenie studentów? Przypominam, że większość osób na tym kierunku ma pracę od 3ciego roku studiów i nie musi wyrażać zgody na wykorzystanie ich pracy do celów innych niż ocenienie jej.
Na Politechnice Poznańskiej działa to bez większych problemów. Tzn. projekty są robione w ramach pracy dyplomowej. Studenci dostają umowę o dzieło, wymagania i deadline związany z terminem oddania pracy, chociaż czasem obsługa powdrożeniowa zajmuje trochę dłużej.
Student się uczy i swoją pracą dokumentuje postępy w nauce.
Witam.
No i zaczyna się problem.
Proszę wrócić do czasów gdy uczeń stawał się czeladnikiem, a potem mistrzem. Za naukę swoją płacił, a do tego wykonywał prace zawodowe. Proszę nie zapominać, że nauka jest kosztowniejsza niż wyrobnictwo. Ponadto, taka praca to też swoista reklama swoich umiejętności.
Teraz rozumiem skąd taki poziom bezrobocia. Wynika to z tego, że ludek po studiach przychodzi do pracy i wymaga wynagrodzenia na poziomie jakby posiadał nie tylko wiedzę, ale i praktykę na określonym stanowisku. Dlatego wielu pracodawców woli sobie odpuścić i wziąć nie magistra. Takiego nie magistra można nauczyć zawodu w sposób jaki wymaga profil firmy i do tego za mniejszą stawkę. Wszak i tak, jak koleś nauczy się pracy, to zwiewa do konkurencji. Dlatego taniej jest uczyć kogoś kto żąda niższych stawek za pracę. Czysty rachunek ekonomiczny.
Ale idąc dalej w aspekcie
No cóż... Gdyby uczelnia w ten sposób mogła zarabiać na dobrym produkcie software-owym, to i studia byłyby na takiej uczelni tańsze. Tyle tylko, że nie od razu a po jakimś czasie. Wielce prawdopodobne, że pierwsze roczniki nic by z tego nie miały, poza sławą i wpisem nazwiska w nagłówek programu, jak to ma miejsce w sofcie OpenSource-wym. Jednak skoro tak stawiasz sprawę, to ten wątek powinien być na studiach dziennych. Studia inne mogą płacić jak dotąd. Przynajmniej soft mógłby zostać z założenia OpenSource.
A z drugiej strony, ja zapytam. Jaką kasę z tytułu stworzenia jądra linux-a ma Linus Tornvalds? A jaką ma pozycję na świecie i jaką pozycję ma w firmie?
Owszem, nie musi i dlatego uczy się tego czego uczy, a co w konsekwencji sprawia, że zaawansowany "amator" ale zapaleniec informatyczny wie więcej niż ludzie po studiach informatycznych.
Czego mam bardzo często dowody stykając się z ludźmi w wieku nawet gimnazjalnym i konfrontując ich poczynania z poczynaniami kolegów z pracy, ale mających mgr informatyki. Wystarczy tylko mieć pasję, studia tylko poszerzą wiedzę. Warunek jest jeden, uczelnia musi umieć sprostać kształceniu pasjonatów, a nie kreować modne kierunki.
Pozdrawiam
Cechy rzemieślnicze mamy na szczęście za sobą
Taki ludek po porządnych studiach posiada już 2-3 lata doświadczenia na stanowisku tzw. "wejściowym" i szuka bardziej wymagającego stanowiska. Moi koledzy nie mają problemów ze znalezieniem pracy właśnie dlatego, że zaczęli zdobywać wiedzę i doświadczenie poza uczelnią.
Niestety istnieje sporo uczelni "im. Kubusia Puchatka" z kierunkiem informatyka, po którym można sobie najwyżej złożyć samodzielnie komputer, skonfigurować Windowsa i napisać bardziej zaawansowany Hello World.
Nie byłyby, a właściwie to nie są. Uczelnia zarabia na oprogramowaniu zupełnie niezależnie od zarabiania na dydaktyce. Czym innym jest projekt softwarowy zrobiony za pieniądze, a czym innym projekt zrobiony na zaliczenie i tak właśnie powinno być. Pod żadnym pozorem wynik pracy dydaktycznej nie nadaje się wprost do zastosowań komercyjnych. Gdyby ktoś mnie zmuszał do pisania na zajęciach softu, który później uczelnia chciałaby sprzedawać, to otrzymałaby projekt formalnie zgodny z wymaganiami i nic więcej.
Torvalds napisał sobie jądro z własnej woli, mi się wydawało, że w całym pomyśle "uczelnia ma studentów, więc sobie napisze" chodziło o pracę studentów pod groźbą niezaliczenia. Jeżeli uczelnia stanie się jedynie koordynatorem projektu na licencji open source, to nie widzę żadnych problemów. Zainteresowani studenci/pracownicy przyjdą sami, niezainteresowani pójdą gdzie indziej.
Nie tyle sprostać kształceniu, co nie przeszkadzać :)
Podsumowując nie mam nic przeciwko budowaniu projektu obok dydaktyki i wykorzystywaniu pracy wykonanej przy okazji projektu do zaliczania niektórych przedmiotów. Niestety narzucenie obowiązkowego pisania modułów projektu w ramach zaliczenia przedmiotu muszę uznać za działanie "nie fair" wobec studenta, który za podobną pracę może otrzymać wynagrodzenie, oraz nieefektywne ze względu na jakość produkowanego w ten sposób kodu.
A nie wystarczyło by
A nie wystarczyło by uczelnie ogłosiła konkurs dla studentów?
USOS
Robił sobie Uniwersytet Warszawski USOS-a własnym sumptem, a nawet zdaje się na sprzedaż, a studentów krew zalewała, jakie toporne to było (może dalej jest?). Zajmowali się tym ludzie z przerostem lewej półkuli mózgowej i zanikiem prawej, poznając zapewne arcyciekawe gotowe komponenty Javowe rekreacyjnie, w ramach prac zaliczeniowych, licencjackich i magisterskich, a może i w ramach statutowej działalności pracowniczej. Zalewał system każdego milionem opcji zamiast zrobić jakieś "sensible defaults", help był mało pomocny, wsparcie agresywne, interfejsy mało przejrzyste (no ale na pewno wyświetlające coś-nie-wiadomo-co w Lynksie - to podstawa). Różnie więc bywa z tym szlachetnym łączeniem teorii z praktyką. Zależy czy priorytetem jest, żeby ktoś się pouczył, czy żeby efektywnie wdrożyć jakiś proces - zgodnie z założeniami, w którym będą uczestniczyć ludzie.
Tytuł nie zawsze odzwierciedla użyteczną wiedzę.
Witam.
Jak widzę, niezbyt precyzyjnie się wyraziłem.
Moim zamierzeniem było, aby to właśnie studenci, młodzi, gniewni, byli autorami aplikacji. Działalność gospodarcza grona pedagogicznego uczelni nie była przedmiotem mojej wypowiedzi. Proszę zwrócić uwagę, że to właśnie studenci mają najwięcej pomysłów jak coś zrobić. Brakuje im tylko najczęściej koordynatora. A tym kimś mógłby być właśnie wykładowca. Poruszono tu wcześniej problem kompatybilności danych. A skąd to się bierze? Ano z tego, że każdy ma patent na pomysł i ani myśli dopuścić do sytuacji, że jakiś inny program mógłby korzystać z efektów jego programu. Gdyby jednak na świecie panowało takie nastawienie, to dziś nie byłoby np. formatu jpg, który występuje wszędzie. Każdy program graficzny potrafi otworzyć taki format i wyprodukować plik w takim formacie. W samym programie mniej jest istotne jakich użyto procedur i funkcji, liczy się efekt końcowy. Ciekawe jakby wyglądał świat internetu gdyby nie html, xhtml, css. Jakie ma znaczenie co musi być w przeglądarce aby działała? Ważne jest, że wyświetla tak samo, a przynajmniej powinna.
Jeszcze jedną przyczyną niekompatybilności danych jest fakt, że każdy programista korzysta z aplikacji, które wymuszają zapis w odpowiednim formacie, bo inny jest mało efektywny. A jest mało efektywny nie dlatego, że taki jest, tylko dlatego, że producent kompilatora założył iż tak ma być ! Ewidentnym przykładem są tutaj wszelkiego rodzaju kombajny. Ten sam efekt można uzyskać innymi, mniej rozbudowanymi narzędziami. Co więcej, okaże się, że kod z tych mniej skomplikowanych kombajnów mniej waży, a robi dokładnie to samo. Jest tylko drobna różnica. Ten mniej skomplikowany kompilator wymaga więcej pracy od kodera niż super kombajn. Ale jak to w życiu, "coś za coś".
Pozdrawiam