biblioteki Open Source

Jak open-source zmienił świat

Nie tylko wielkie programy do wszystkiego

Eric S. Raymond, jeden z założycieli oprogramowania open source, napisał w swoim The Cathedral and the Bazaar: Każde dobre oprogramowanie open-source zaczęło się od podrapania się po osobowości programisty . Jest w tym dużo prawdy. Takie dzieła jak serwer WWW Apache, MySQL czy Linux zaczęły się właśnie tak, podobnie jak zresztą wiele mniejszych programów. Jest mało prawdopodobne, że wiele osób miało ochotę od razu tworzyć gigantyczne programy, takie jak kombajny OpenDaylight czy OPNFV dla telekomunikacji albo Unified Code Base Automotive Grade Linux (AGL). Obecnie także firmy skupione na wąskich dziedzinach także korzystają z oprogramowania open source.

Od usera do dewelopera

W niedawnym raporcie McKinsey & Company „Jak doskonałość oprogramowania napędza wyniki biznesowe” (How software excellence fuels business performance) stwierdzono, że „największym wyróżnikiem” najważniejszych firm w branży jest przyjęcie oprogramowania typu open source. Takie przyjęcie oprogramowania open-source do stosowania w dużej organizacji powodowało niemal zawsze, że dotychczasowi użytkownicy zmieniali się we współpracowników uczestniczących w rozwoju software’u. Dane z raportu pokazują, że przyjęcie przez firmy otwartego oprogramowania ma trzykrotnie większy wpływ na innowacje niż w przypadku firm korzystających z oprogramowania zamkniętego. Innymi słowy, firmy odnoszące sukcesy nie tylko używają programów typu open-source, ale aktywnie pracują nad projektami open-source mającymi znaczenie dla ich branży.

Logika trudna do zrozumienia

To właśnie wciąż przytłacza wielu przedsiębiorców. W jaki sposób aktywny wkład w coś, co mogą wykorzystać ich rywale, może pomóc im na rynku? Nie pojmują nawet teraz, że jak powiedział prezydent John F. Kennedy, przypływ podnosi wszystkie łodzie . Kiedy dzielimy się naszymi zasobami, naszą pracą i naszą wiedzą w zakresie oprogramowania open-source, wszyscy odnoszą korzyści. Ale firmy, które wykorzystują to najlepiej, to te, które aktywnie uczestniczą w projektach open-source. Bo one są w projekcie, znają go, mają wpływ na jego kształt i czerpią z jego doświadczeń.

Nie jest tak? Ilu z nas używa dziś Uniksa zamiast jego bliźniaczego Linuksa o otwartym kodzie źródłowym? W prawie każdym rodzaju oprogramowania dominuje dziś open-source. Korzystają z niego niemal wszyscy czołowi giganci technologiczni: Amazon, Google, IBM a nawet Microsoft. Może z wyjątkiem odstającego Apple, wszyscy albo opierają się na otwartym kodzie źródłowym, albo przynajmniej korzystają z niego w szerokim zakresie.

Firma w modelu definiowanym programowo

W branżach pionowych niektóre firmy robią to samo, co zawsze w kółko. Poprawiają swoją podstawową przewagę konkurencyjną, szybkość lub koszty, ale model pozostaje ten sam. Jest jednak i inna droga. W ramach tak zwanej „transformacji cyfrowej” firmy przyjmują podstawowe modele biznesowe i procesy ale przekształcają je w oprogramowanie i usługi typu open-source. Można to zrobić na wiele sposobów: kod, interfejsy programowania aplikacji (API), zasoby chmury czy kontenery. Ostatecznie jednak wszystkie one zamieniają procesy biznesowe i zasoby w usługi definiowane programowo.

Stephen O'Grady, współzałożyciel firmy analitycznej Red Monk, zauważył to już w swojej książce sprzed 7 lat (The New Kingmakers: How Developers Conquered the World, 2013). Przejście do modelu definiowanego programowo to radykalna zmiana. Open source umożliwiło taką metamorfozę wielu firmom, z których większość rozpoczęła transformację ze stosunkowo niewielkimi zespołami programistycznymi.

Telekomunikacja za przykład

Tak było na przykład w telekomunikacji. Inwestycje kapitałowe w celu przejścia z jednej technologii na drugą, takie jak przejście z 2G na 3G, kosztują miliardy dolarów. W pierwszej dekadzie XXI wieku stało się jasne, że stare modele klient-serwer nie sprostają wyzwaniu setek milionów użytkowników telefonów komórkowych będących w ciągłym ruchu. Jeszcze w 2000 roku stworzono projekt open-source, OpenFlow. Ten zdefiniowany standardowy interfejs komunikacyjny został przyjęty przez główne firmy technologiczne, takie jak Deutsche Telekom, Google, Microsoft, Verizon czy Cisco. Po czasie także inne firmy, takie jak AT&T, również zdały sobie sprawę, że samodzielne rozwiązywanie tych samych problemów automatyzacji sieci było stratą czasu i pieniędzy.

Linux Foundation pomogła w tym, zapewniając firmom neutralną przestrzeń do współpracy. Dzisiaj pod parasolem Linux Foundation Networking (LFN) 8 różnych projektów sieciowych połączyło razem prawie największą światową firmę telekomunikacyjną.

Java i wolne oprogramowanie

Java jest częściowo bezpłatna i open source (od patrz dalej ), a jego licencja pozwoliła na powstanie dużej liczby bezpłatnych narzędzi w najróżniejszych dziedzinach.

Dyskusja na temat licencjonowania Java

Pozwolenie n O 1

Licencja Java (Licencja Sun Community Sourced - SCSL) umożliwia:

Bezpłatne przejęcie środowiska JRE (maszyna wirtualna wraz z podstawowymi bibliotekami) w witrynie firmy Sun;

Bezpłatna redystrybucja środowiska JRE, jeśli towarzyszy aplikacji napisanej w języku Java przeznaczonej na komputer stacjonarny lub serwer do ogólnego użytku, podlega zatem opłatom licencyjnym za maszyny przeznaczone do jednorazowego użytku (takie jak telefony, konsole do gier, samochody itp.). nazywane jest „oprogramowaniem pokładowym”.

Licencja Java nie pozwala na:

Dekompilacja, modyfikacja platformy Java.

Ta licencja nie pozwala na uznanie technologii Java za bezpłatną. Z drugiej strony pozwala na tworzenie narzędzi, oprogramowania i bezpłatnych bibliotek napisanych w języku Java.

Niezależny organ, JCP , pomaga w standaryzacji tych narzędzi w celu ujednolicenia wysiłków na rzecz rozwoju i pomocy w promowaniu tych narzędzi.

Od początku 2004 roku pojawiło się wiele głosów na temat wydania przez firmę Sun kodu Java. Pierwsza prośba pochodzi od IBM , a następnie przez osobistości ze świata wolnego oprogramowania, takie jak Eric Raymond .

Od marca 2005 roku firma Sun wprowadziła nowe licencje na Javę, zwiększając jej otwartość, nie stając się jednak open-source:

Licencja użytkownika wewnętrznego Java (JIUL), przeznaczona do wdrożeń wewnętrznych;

Licencja Java Distribution License (JDL), umożliwiająca pełną dystrybucję oprogramowania Java;

Licencja Java Research (JRL) do oceny i użytku niekomercyjnego. Ta licencja umożliwia również zapoznanie się z kodem źródłowym Java.

Ponadto firma Sun oferuje na tej stronie udział w rozwoju kolejnej wersji języka Java ( Mustang ) .

Jak wskazano poniżej, oczekuje się, że Sun wyda Javę w 2006 roku.

Polityka firmy Sun

Polityka firmy Sun polega na utrzymaniu kontroli nad ewolucją Javy, co wyjaśnia odmowę umieszczenia maszyny JVM i kompilatora Javy w oprogramowaniu typu open source .

Firma Sun w przeszłości umieszczała technologię Jini , opartą na Javie, na licencji, którą Sun twierdził, że jest open-source . Zostało to jednak zakwestionowane, w szczególności przez Linusa Torvaldsa (por. Kiedyś Linux ).

Jednak po umieszczeniu NetBeans w open source do czerwca 2000 r. Nastąpiła ewolucja Sun, który umieścił niektóre elementy pakietów Java w open-source na konferencji JavaOne 2004 :

Java3D ;

Rozszerzenia dla JFC pozwalające na zdefiniowanie pełnego interfejsu graficznego w pliku XML ( XUI ), JDNC ( Java Desktop Network Components ) oraz JDIC ( Desktop Integration Components );

) oraz JDIC ( ); Graficzny interfejs 3D dla Linux Looking Glass .

Ogólnie rzecz biorąc, możemy zauważyć przez pewien czas silniejsze zaangażowanie firmy Sun w tworzenie wolnego oprogramowania:

Uruchomienie czystej dystrybucji Linuksa ( Java Desktop System );

); ;

Uruchomienie , witryny społecznościowej, w tym wiki Javapedia, inspirowanej Wikipedią .

Na początku 2005 roku firma Sun ogłosiła utworzenie nowej licencji typu open source o nazwie Common Development and Distribution License (CDDL). Ta licencja zostanie wykorzystana do publikacji dużej liczby oprogramowania, w tym Solaris , w wersji OpenSolaris , a także Java Enterprise System i Java Desktop System . Jest możliwe (co oznacza, że ​​zostało wspomniane), że cały katalog oprogramowania Sun zostanie wydany na tej licencji, która w związku z tym obejmowałaby platformę Java.

W czerwcu 2005 r. Firma Sun ogłosiła uruchomienie projektu open source, mającego na celu stworzenie kolejnej wersji Java System Application Server w wersji deweloperskiej, pod nazwą projektu GlassFish , wraz ze specyfikacją magistrali integracyjnej Java, JBI .

W 2006 roku Sun zdecydował się wypuścić wszystkie swoje narzędzia programistyczne, w tym te dla języka Java, a mianowicie Java Studio Creator i Java Studio Enterprise ( NetBeans był już darmowy).

Dodatkowo, w trakcie jego przemówienie na JavaOne konferencji na 16 maja, nowy CEO firmy Sun, Jonathan Schwartz , wskazał, że zamierza uczynić Java darmo.

Plik Sun umieszcza rdzeń technologii Java, JDK (JRE - JVM i biblioteki - oraz narzędzia programistyczne, w tym kompilator javac) na licencji GPL w wersji 2, a także na platformę Java ME. Implementacja Java EE ( GlassFish ) firmy Sun , już na wolnej licencji CDDL , ma również dodaną licencję GPL. Dlatego ta zmiana kładzie kres prawnie zastrzeżonemu aspektowi Javy, która ostatecznie staje się wolnym oprogramowaniem .

Plik , Sun ogłasza, że ​​Java jest teraz w pełni Open Source w projekcie OpenJDK .

Darmowe implementacje Java

Free Software Foundation była pierwsza próba stworzenia elementów wolnej implementacji Javy, za pośrednictwem dwóch odrębnych projektów:

GNU Classpath , bezpłatna implementacja bibliotek Java Core;

GCJ , rozszerzenie kompilatora GCC do kompilowania kodu Java.

W maju 2005 roku Apache Foundation ogłosiła uruchomienie projektu Harmony , mającego na celu stworzenie kompletnego, bezpłatnego środowiska Java, z kompilatorem, JVM i bibliotekami Core. Projekt ma na celu kompatybilność z J2SE .

Pozostałe elementy środowiska Java zostały zaimplementowane w wersji darmowej:

Darmowe narzędzia Java

Darmowe narzędzia dla języka Java dzielą się zasadniczo na cztery kategorie:

Narzędzia programistyczne ;

Serwery;

Biblioteki;

Kompletne oprogramowanie, patrz Kategoria: Darmowe oprogramowanie napisane w Javie .

narzędzia programistyczne

Nazwisko Aktualna wersja (data) Opis Licencja Link zewnętrzny Mrówka 1.6.5 ( 2 czerwca 2005 ) Narzędzie do tworzenia aplikacji Licencja oprogramowania Apache 2.0 Avalon 4.2 Narzędzie do tworzenia komponentów według wzorców projektowych Licencja na oprogramowanie Apache Zaćmienie 3.4 Środowisko programistyczne Licencja Common Public License 1.0 Jakarta Cactus 1.6.1 Framework testowy dla aplikacji internetowych, oparty na JUnit Licencja na oprogramowanie Apache Kompilator GNU dla Java (GCJ) 4.1.1 (wersja GCC) Kompilator umożliwiający natywną kompilację na różnych platformach (Linux na PC, Alpha, Itanium, PowerPC, Athlon 64, SH-3/4, Solaris na SPARC, BSD na PC, Irix, Windows, MacOS X ...), zawarty w GCC LPG mówię 4.2 Programistyczny edytor tekstu napisany w Javie LPG Jikes 1.21 Kompilator Licencja Publiczna IBM Jakarta JMeter 2.0.1 Narzędzie do pomiaru wydajności Licencja na oprogramowanie Apache JSwat 1.5.4 Graficzny debugger LPG JUnit 3.8.1 Zautomatyzowane testowanie jednostkowe ramy , Extreme Programming zorientowanych Powszechna Licencja Publiczna Kaffe 1.0.7 Maszyna wirtualna LPG Maven 1.0 (13.07.2004) Narzędzie do integracji aplikacji i zarządzania projektami Licencja oprogramowania Apache 2.0 NetBeans 8.0 (18.03.2014) Środowisko programistyczne Licencja publiczna firmy Sun SableCC 2.18.2 Zorientowany obiektowo generator kompilatorów LGPL SandVM 1.1.9 Maszyna wirtualna LGPL Jakarta Watchdog 4.0 Narzędzie do sprawdzania poprawności kodu dla serwletów i stron JSP Licencja na oprogramowanie Apache XDoclet 1.2.2 Narzędzie do generowania kodu Licencja na oprogramowanie Apache Gruchot 1.3 Narzędzie pozwalające na układanie kodu java według predefiniowanych reguł Licencja BSD Checkstyle 4 (2006) Narzędzie do kontroli standardów deweloperskich LGPL

Serwery

Nazwisko Aktualna wersja (data) Opis Licencja Link zewnętrzny Szklana ryba 2 Pełny serwer Java EE 5 (w tym klastrowanie) CDDL i GPL EasyBeans 1.0RC1 Lekki kontener i serwer EJB3.0 LGPL Tomcat Apache 6.0 Serwer sieciowy i kontener serwletów , kompatybilne z JSP, comet API Licencja oprogramowania Apache 2.0 Molo 5.0 Serwer sieciowy i kontener serwletów , kompatybilne z JSP, comet API Licencja na oprogramowanie Apache JBoss 4.2.3 Kontener i serwer EJB, serwletów i JSP (przez Tomcat onboarding), w pełni kompatybilny z J2EE LGPL JOnAS 5.1.1 Serwer zgodny z J2EE LGPL Serwer Enhydra 5.1-15 Kontener serwletów i serwer zorientowany na XML LGPL Java Apache Mail Enterprise Server (James) 2.2.0 Serwer poczty i grup dyskusyjnych (protokoły SMTP, POP3 i NNTP) Licencja na oprogramowanie Apache JServ 1.1.2 Kompatybilny z JSP kontener serwletów i serwer . JServ to uśpiony projekt, już nie ewoluuje Licencja na oprogramowanie Apache Geronimo 1,0-M2 Serwer łączący wiele projektów Apache Java w celu stworzenia kompletnego i innowacyjnego serwera J2EE opartego na JMX Licencja na oprogramowanie Apache OpenEJB 0.9.2 Kontener i serwer EJB Konkretne:

Biblioteki i frameworki

Kompletne oprogramowanie

Nazwisko Aktualna wersja (data) Opis Licencja Link zewnętrzny XWiki 0.9.840 Oprogramowanie do zarządzania Wiki LPG Azureus 2.5.0.0 Klient BitTorrent LPG zirytowany 0.3 Radio LPG GeoGebra 2.7 Matematyka (geometria i algebra) LPG http://www.geogebra.at/ GEONExT 1.51 Matematyka (geometria dynamiczna) LPG http://www.geonext.de/

Inne narzędzia

Nazwisko Aktualna wersja (data) Opis Licencja Link zewnętrzny Lenya 1.2 System zarządzania treścią oparty na Apache Cocoon Licencja oprogramowania Apache 2.0 Jython 2.1 Interpreter Pythona napisany w Javie specyficzne: BeanShell Wygląd J. 1.2 Rozszerzenie do programowania aspektowego Licencja Common Public License 1.0 Jakarta Lucene 1.4 Wyszukiwarka Licencja na oprogramowanie Apache Jakarta Slide 2.0 Repozytorium dla serwera WWW, kompatybilne z WebDAV Licencja na oprogramowanie Apache

Uwagi i odniesienia

Zobacz też

Powiązane artykuły

biblioteki Open Source

Nie ma nic za darmo - biblioteki Open Source

Tomasz Skutnik, 2009-03-08

Po co nam Open Source?

Stosowanie bibliotek o otwartym kodzie źródłowym (open source) podczas programowania w języku Java jest codzienną praktyką. Przeciętny system zbudowany w technologii J2EE zawierać może od kilku do kilkudziesięciu bibliotek pomocniczych. Duża część z nich to biblioteki open source, które można zgrać bezpośrednio z Internetu i użyć we własnym projekcie – zwykle bez dodatkowych opłat bądź ograniczeń licencyjnych.

Zalety stosowania bibliotek o otwartym kodzie źródłowym są dość oczywiste:

- brak bądź niewielkie koszty nabycia biblioteki,

- wygoda programowania – szczególnie debugowania,

- możliwość szybkiego naprawiania błędów ujawniających się podczas wdrożenia i eksploatacji systemu,

- lepsze zrozumienie sposobu działania systemu jako całości.

Z doświadczeń firmy e-point SA w tworzeniu i utrzymaniu systemów informatycznych wynika, że główną korzyścią stosowania bibliotek open source jest posiadanie kodu źródłowego. Przede wszystkim ze względu na możliwość szybkiej analizy i usuwania błędów wykrywanych podczas eksploatacji systemu. Pozostałe korzyści mają charakter drugorzędny.

Nie zawsze jednak decydując się na użycie w projekcie biblioteki o otwartym kodzie źródłowym zdajemy sobie w pełni sprawę z konsekwencji, jakie taka decyzja pociąga za sobą. Szczególnie jeśli uwzględni się problemy występujące podczas utrzymania i konserwacji systemów informatycznych w dłuższym horyzoncie czasowym.

Przegląd problemów związanych ze stosowaniem bibliotek open source

Musimy zdawać sobie sprawę, że decyzja o użyciu konkretnej biblioteki ma najczęściej charakter ostateczny. Zjawisko to, kojarzone zwykle z dostawcami oprogramowania komercyjnego, określa się mianem "vendor lock-in". Oznacza to, że również w przypadku oprogramowania open source, potencjalny koszt wymiany dowolnej biblioteki pomocniczej po wdrożeniu systemu jest bardzo duży. Dla istotnych komponentów – na przykład warstwy prezentacji czy warstwy dostępu do danych (O/R mapping) – wymiana taka jest zupełnie nieopłacalna z biznesowego punktu widzenia.

Jednym z najważniejszych zagadnień utrzymania systemów krytycznych biznesowo jest możliwość szybkiej analizy i usuwania błędów napotkanych we wdrożeniach produkcyjnych. Często zdarza się, że błąd ujawnia się nie w oprogramowaniu wytworzonym przez nas, lecz w bibliotece pomocniczej. Posiadanie w takiej sytuacji jej kodu źródłowego jest niezbędne do szybkiego znalezienia i usunięcia problemu.

Podstawowym grzechem popełnianym przez programistów i kierowników projektów jest nadmierne zaufanie pokładane w binarnych wersjach bibliotek o otwartym kodzie źródłowym. W sytuacjach awaryjnych, kiedy potrzeba dostępu do kodu źródłowego staje się paląca, pośpieszne szukanie go w Internecie może zakończyć się niepowodzeniem. Niefrasobliwe uzależnienie projektu od binarnej wersji biblioteki, bez jej minimalnej choćby weryfikacji, powodować może różnorakie problemy.

Najbardziej oczywistym z nich jest brak kodu źródłowego do biblioteki, której używamy. Zwykle po dołączeniu biblioteki do projektu programiści przestają śledzić jej dalszy rozwój. Z czasem, gdy publikowane są kolejne wersje, zarządzający projektami open source mają zwyczaj kasować wersje archiwalne (zarówno binarne i źródłowe) ze stron WWW projektu. Wtedy zdobycie lub odtworzenie kodu źródłowego do binarnej wersji biblioteki używanej w naszym projekcie (o ile zapobiegliwie nie zgraliśmy go wcześniej) nie jest ani łatwe, ani szybkie.

Jeżeli na stronach projektu nie można znaleźć źródeł, to pierwsze kroki kierujemy do repozytorium kodu źródłowego. Tu jednak czekać na nas mogą niezbyt miłe niespodzianki. Pierwszą z nich jest brak samego repozytorium. Dzieje się tak zazwyczaj, gdy autorzy projektu open source decydują się na migrację kodu źródłowego pomiędzy systemami kontroli wersji (np. z CVS do SVN). Jeżeli wersja, której używamy, jest na tyle wiekowa, że była rozwijana jeszcze w starym repozytorium, może się zdarzyć, że nie jest ono już nigdzie dostępne – co w połączeniu z brakiem wersji źródłowej na stronach WWW projektu istotnie utrudnia odnalezienie źródeł. Kolejnym problemem bywa brak w repozytorium tagu odpowiadającego interesującej nas wersji oprogramowania. Najczęściej jest to spowodowane błędem ludzkim, tj. autorzy projektu open source czasem zapominają nadać właściwy tag w repozytorium.

Przyjmijmy, że udało nam się jednak zdobyć wersję źródłową projektu. Nie oznacza to końca naszych problemów. Bywa, że zgrany przez nas kod źródłowy po prostu się nie kompiluje. Zwykle błędy kompilacji wynikają z niezgodności wersji JDK lub są to trywialne błędy syntaktyczne (np. brak średnika itp.). Zagadką pozostaje wtedy, kto i w jaki sposób zbudował binarną wersję biblioteki. Na pewno nie powstała ona ze źródeł, które mamy do dyspozycji.

Czasami zdarza się, że budowana przez nas ze źródeł biblioteka kompiluje się prawidłowo, lecz wykonanie dołączonych do niej automatycznych testów kończy się niepowodzeniem. Teoretycznie moglibyśmy zastąpić pierwotnie używaną przez nas wersję biblioteki nową, skompilowaną ze źródeł. Pojawia się jednak w takiej sytuacji pytanie – czy na pewno źródła, z których skompilowaliśmy własną wersję binarną, są prawidłowe? Kto ma rację? Czy to kod źródłowy działa prawidłowo, a testy jednostkowe są nieaktualne, czy może to autorzy projektu opublikowali nową wersję biblioteki z wprowadzonym błędem, bez wcześniejszego sprawdzenia czy dotychczasowe testy kończą się prawidłowo?

Bywa, że projekt open source buduje się z wersji źródłowej, testy jednostkowe kończą się powodzeniem, natomiast wygenerowany artefakt binarny nie odpowiada oczekiwanej przez nas wersji. Przykładowo: paczka źródłowa oznaczona jako 2.3 buduje artefakt oznaczony jako 2.4. Bardzo trudno w takiej sytuacji dociec, gdzie leży problem – czy w niewłaściwym nazwaniu paczki źródłowej, czy w niespójności źródeł.

Istnieje też cała klasa mniej krytycznych problemów utrudniających zbudowanie prawidłowej wersji binarnej z posiadanych źródeł, takich jak np. brak domyślnego mechanizmu budowania. O ile w przypadku prostej biblioteki własnoręczne napisanie prostego skryptu budującego nie stanowi problemu, to dla bardziej złożonych projektów – kompilujących klasy warunkowo, bądź modyfikujących kod wynikowy – uzyskanie własnej wersji binarnej może stanowić duże wyzwanie. Dzieje się tak zwykle, gdy autorzy projektu nie mają sformalizowanego, zewnętrznego mechanizmu budowania i publikacji biblioteki, a polegają jedynie na konfiguracji własnego, lokalnego IDE.

Kiedy już zbudujemy wersję binarną ze źródeł, testy jednostkowe kończą się sukcesem oraz, na pierwszy rzut oka, artefakt binarny jest tym, co chcieliśmy uzyskać – wciąż nie musi oznaczać to końca naszych kłopotów.

Czasami, po zamianie oryginalnej wersji binarnej biblioteki na wersję skompilowaną ze źródeł, aplikacja przestaje działać sygnalizując awarię wyjątkami typu ClassNotFoundException lub IncompatibleClassChangeError . Przyczyną takiego stanu rzeczy okazują się najczęściej obce klasy (tj. pochodzące z innych projektów) dołączone do pierwotnego artefaktu binarnego . I znowu mamy do rozwiązania zagadkę: kto, w jaki sposób i z jakich źródeł zbudował wersję binarną biblioteki, której używamy, oraz w jaki sposób znalazły się tam klasy z innych bibliotek.

Najbardziej nieprzyjemnym i najtrudniejszym do zdiagnozowania problemem jest sytuacja, w której (pomimo prawidłowej kompilacji, testów i uruchomienia we własnym projekcie) okazuje się, że zbudowana przez nas biblioteka zachowuje się inaczej niż wersja pierwotnie zgrana z Internetu. Przykładowo: dla określonych parametrów wejściowych jakaś funkcja zamiast zwracać wartość null rzuca wyjątek. Takie niespodziewane zmiany kontraktu mają tendencję do nakładania się na błędy, które właśnie próbujemy diagnozować, znacząco komplikując proces naprawy.

Oprócz opisanych powyżej problemów, mających charakter techniczny, projekty open source mają również szereg innych, mniej uciążliwych wad – głównie w sferze zarządzania. Szczególnie dotyczy to małych, jednoosobowych projektów. Zdarza się bowiem, że gdy projekt spoczywa na barkach jednego człowieka – w sytuacji, gdy ten znajdzie mocno angażującą go pracę, zmieni zainteresowania zawodowe (np. ulubiony język programowania), itp. – rozwój biblioteki zamiera. Nie pojawiają się nowe wersje, błędy nie są naprawiane, a poprawki przesyłane przez użytkowników nie są przeglądane i dołączane do istniejącego kodu źródłowego.

Przed użyciem każdej biblioteki open source (zwłaszcza w zastosowaniach komercyjnych!) należy również bezwzględnie sprawdzić licencję, która dołączona jest do projektu. Część bibliotek nie określa jawnie, na jakiej licencji można ich używać – nagłe pojawienie się licencji, której warunki wykluczają użycie jej w naszym projekcie – w momencie, gdy mamy już system wdrożony produkcyjnie – może narazić nas na dużą i kosztowną modyfikację istniejącego już i przetestowanego oprogramowania.

Decydując się na wybór biblioteki warto również zwrócić uwagę na jakość dokumentacji, aktywność użytkowników i autorów oprogramowania (listy dyskusyjne, wiki itp.). Co prawda, posiadanie i dobra znajomość kodu źródłowego biblioteki, której chcemy użyć, pozwala nam uniezależnić się częściowo od dokumentacji i autorów. Niemniej dobra dokumentacja techniczna, samouczki i przykłady użycia znacznie ułatwiają pracę z konkretną biblioteką.

Jak sobie radzić w przypadku problemów?

Opis wszystkich powyższych problemów nie byłby kompletny bez próby oszacowania ich skali i zasugerowania możliwych środków zaradczych. W e-point SA przeprowadziliśmy analizę części aktywnych projektów pod kątem użycia zewnętrznych bibliotek o otwartym kodzie źródłowym, ze szczególnym uwzględnieniem problemów opisanych w poprzedniej sekcji. Przegląd obejmował 22 najbardziej aktywne projekty, rozwijane na 43 gałęziach rozwojowych, które korzystały ze 173 różnych bibliotek o otwartym kodzie źródłowym w 253 różnych wersjach.

Wnioski z analizy były pesymistyczne: 33% binarnych wersji bibliotek o otwartym kodzie źródłowym jest obarczona którymś z wcześniej omówionych problemów.

Co to oznacza? Oznacza to, że w przypadku długoterminowego utrzymania systemów IT, natknięcie się na któryś z powyższych problemów jest jedynie kwestią czasu. Pytanie nie brzmi "czy może nas to spotkać?" lecz "kiedy nas to spotka?".

A co jeżeli jednak nie możemy znaleźć źródeł wcześniejszej wersji biblioteki na stronach projektu? Gdzie ich szukać? Jak sobie radzić, jeśli pomimo poszukiwań nie uda nam się ich znaleźć?

Pierwszym, często najskuteczniejszym krokiem który można wykonać, jest poszukiwanie źródeł w wyszukiwarkach internetowych, takich jak np. Google, Yahoo. Bywa, że gdzieś w Internecie ktoś posiada archiwalną wersję źródeł, których szukamy, a które nie są już dostępne na stronach projektu. Jeżeli takie poszukiwania zawiodą, można również spróbować sprawdzenia w serwisie Przechowuje on archiwalne strony WWW i możliwe, że wśród nich znajdziemy także wersję archiwalną biblioteki. Oczywiście, jeżeli jest dostępne publiczne SCM, to jest ono najlepszym miejscem aby zdobyć kod źródłowy. Można zgrać z niego źródła na podstawie oznaczenia tagiem odpowiadającego interesującej nas wersji (pod warunkiem, że taki tag istnieje i jest prawidłowy).

Jeżeli żaden z powyższych sposobów nie doprowadził do znalezienia źródeł, można skorzystać z pomocy dekompilatorów. Nie zawsze uda nam się tak zdekompilować klasę, aby można było w niej naprawić błąd, a następnie ponownie ją skompilować i zaktualizować archiwum biblioteki. Ale można na podstawie zdekompilowanego kodu spróbować przynajmniej znaleźć przyczynę błędu i skonstruować jego tymczasowe obejście.

Jeżeli znaleźliśmy się w sytuacji, w której musimy naprawić błąd w bibliotece, której źródeł nie mamy, możemy również podjąć jedno z dwóch dodatkowych działań rozwiązujących problem: próbować zmigrować oprogramowanie do nowszej wersji biblioteki, której kod źródłowy mamy, bądź całkowicie usunąć daną zależność z projektu. Które z nich wybrać? Zależy to od tego, z jak dużej liczby funkcji danej biblioteki korzysta nasz system oraz potencjalnych niezgodności z nowszymi wersjami biblioteki. Jeżeli korzystamy z niewielu funkcji biblioteki zewnętrznej (w stosunku do całkowitej wielkości naszego systemu), to najkorzystniejsze może być napisanie tych kilku funkcji bibliotecznych na nowo i dołączenie ich do własnego kodu źródłowego.

Jak wobec tego najlepiej zabezpieczyć się przed wszystkimi opisanymi wcześniej kłopotami albo przynajmniej zminimalizować ich niekorzystny wpływ na nasz projekt? Z doświadczeń firmy e-point SA wynika, że jedynym naprawdę skutecznym sposobem na uniknięcie powyższych komplikacji jest kompilowanie ze źródeł wszystkich używanych w projekcie bibliotek open source.

Oczywiście, nie jest to ani tak proste, ani tak łatwe jak zgranie i bezpośrednie użycie skompilowanej wersji binarnej biblioteki open source. Początkowy (wcześniej niemal zerowy) koszt dołączenia biblioteki do naszego rozwiązania nagle zaczyna być zauważalny. Jeśli zamierzamy skorzystać z kilkunastu bibliotek i każdą z nich chcemy skompilować własnoręcznie, to wtedy – w zależności od szybkości budowania poszczególnych bibliotek i napotykanych po drodze przeszkód – czas spędzony przez programistów na dołączaniu bibliotek do projektu zaczyna być zauważalny w budżecie i harmonogramie.

W przypadku większej liczby projektów, czy prowadzenia i utrzymywania wielu projektów na wielu gałęziach rozwojowych równocześnie, bez mechanizmów automatyzujących budowanie i centralne zarządzanie lokalnie skompilowanymi bibliotekami nie da się w zasadzie zapewnić odpowiednio szybkiej reakcji na błędy mogące ujawniać się w systemach produkcyjnych. Ich zaprojektowanie, wdrożenie, utrzymanie i udokumentowanie procesu posługiwania się nimi jest jednak zdaniem długotrwałym i dość kosztownym. Dlatego każdy z zespołów tworzących oprogramowanie sam musi sobie odpowiedzieć na pytanie: w jaki sposób ma zarządzać źródłami zależności projektu oraz jaką część budżetu i harmonogramu może na to poświęcić.