Otwarte projekty są fenomenem, który wkroczył na arenę historii informatyki na przełomie lat osiemdziesiątych i dziewięćdziesiątych XX wieku, w postaci ruchu na rzecz wolnego oprogramowania (ang. free software). W tym czasie biznesowi gracze branży IT postrzegali je jako fanaberię kilku członków środowiska akademickiego, która to nie ma racji bytu w warunkach komercyjnych. Wizja otwartych projektów, w ramach których oprogramowanie mogło być używane i kopiowane za darmo, a użytkownicy byliby traktowani jako współpracownicy, wydawała się nie mieć żadnych szans na opracowanie i udoskonalanie wartościowych produktów informatycznych.
Powszechne praktyki lat 60' i 70'
Dzielenie się oprogramowaniem jest zjawiskiem tak starym, jak samo oprogramowanie. Jakkolwiek może się to wydawać nieprawdopodobne w dzisiejszym świecie, zdominowanym przez licencje EULA i liczne zabezpieczenia przeciw nieautoryzowanemu kopiowaniu, dzielenie się kodami źródłowymi było powszechną praktyką w latach sześćdziesiątych i siedemdziesiątych. W czasach tych oprogramowanie było wytwarzane i używane w głównej mierze przez naukowców oraz wysoko wykwalifikowanych techników. Wśród obu tych grup istniała stosunkowo otwarta kultura współdzielenia się własnością intelektualną oraz jej opiniowania. Wynikająca z tego wymiana wartości intelektualnych nie była oprawiana w żadną postać prawną, ani też limitowana postanowieniami licencyjnymi. Zresztą dostawcy sprzętu komputerowego mieli równie luźny stosunek do oprogramowania, gdyż nie postrzegali go jako istotnego aktywa biznesowego. Jak wyraźnie widać, branża IT w tamtych odległych o kilkadziesiąt lat czasach znacznie różniła się od obecnej. Jedną z kolejnych istotnych różnic była istniejąca wówczas duża liczba niestandaryzowanych architektur sprzętowych pozostających w powszechnym użyciu oraz brak języków programowania, które byłyby przenośne między tymi architekturami. Dlatego też dostawcy sprzętu komputerowego nie tylko nie ograniczali w żaden sposób współdzielenia się źródłami oprogramowania, a wręcz zachęcali do tego typu zachowań. Postawa taka wynikała z faktu, iż pomagało im to w dostosowywaniu oprogramowania do nowych architektur, a to z kolei zapewniało szybszą adaptację na rynku. Jednocześnie klienci tych dostawców wyrażali chęć do nawiązywania takiej współpracy, ponieważ tak czy inaczej konieczność zmuszała ich do pisania własnego oprogramowania, ściśle dopasowanego do wymogów prowadzonych przez nich badań. Zresztą moc obliczeniowa sama w sobie była wówczas znacznie ważniejsza od bogatego w opcje oprogramowania. Jednak wraz z dojrzewaniem tego przemysłu, w latach osiemdziesiątych zachodziły pewne zmiany, które zakończyły tzw. pierwszą erę współtworzenia oprogramowania[TES].
Eskalacja zamkniętego oprogramowania w latach 80'
Druga era, która rozpoczęła się w latach 80', jest określana mianem eskalacja zamkniętego oprogramowania. Jest to czas, w którym dostawcy sprzętu komputerowego zaczynają postrzegać oprogramowanie jako sprzedawalne dobro, towar sam w sobie podlegający wymianie handlowej, bądź chociażby w charakterze istotnego atrybutu przy sprzedaży sprzętu[POS]. Dwa najważniejsze czynniki, które doprowadziły do wspomnianej zmiany to powstanie wysokopoziomowych języków programowania oraz fakt, że rynek zaczął się skupiać na tylko kilku architekturach sprzętowych. Dzięki takiemu stanowi rzeczy wytwarzanie na szeroką skalę bogatych w opcje systemów informatycznych stało się opłacalnym przedsięwzięciem. Wytwórcy sprzętu zauważyli również, że wartość ich produktów, z perspektywy klienta, przesunęła się z oferowanej mocy obliczeniowej na dostępność oprogramowania. To z kolei sprawiło, że niektóre firmy zaczęły wymuszać przestrzegania własności intelektualnej w stosunku do produktów programistycznych, do których wcześniej wielu naukowców oraz techników ofiarowało własne poprawki. Jednym z najbardziej rozpoznawalnych przykładów tego typu był przypadek działań firmy AT&T wobec systemu operacyjnego UNIX[TES].
Praktyki te zerwały panujący cykl wymiany usprawnień w oprogramowaniu oraz obniżyły motywację społeczności IT do nieformalnego ofiarowania kolejnych poprawek. W trakcie, gdy trend ten rozprzestrzenił się, opanowując zdecydowanie większą część przemysłu komputerowego, kilka mniejszych społeczności (głównie powiązanych ze środowiskiem akademickim) skutecznie mu się opierało poprzez nie zamykanie swoich kodów źródłowych. Jedną z nich była grupa Computer Systems Research Group na Uniwersytecie Kalifornijskim Berkeley, która udostępniała swój pakiet oprogramowania Berkeley Software Distribution na zasadach bardzo liberalnej licencji BSD. Dzięki temu można było wykorzystywać ich kody źródłowe zarówno w projektach otwartych, jak i zamkniętych. Na początku Berkeley Software Distribution było zbiorem nowych programów oraz zamienników dla komercyjnego Sixth Edition Unix. Powoli jednak BSD zaczęło przeradzać się w niezależny system operacyjny. W międzyczasie niejaki Richard Stallman pojawił się na scenie branży IT jako jedna z najbardziej wpływowych oraz aktywnych osobowości opierających się trendowi zamkniętego oprogramowania. Rzucił on swoją pracę w laboratoriach AI w Massachusetts Institute of Technology, kiedy tylko przeszły one na zamknięte oprogramowanie i rozpoczął budowanie społeczności wokół projektu GNU oraz fundacji Free Software Foundation[AGP]. Stallman przewodził obydwoma organizacjami budując prawne i ideologiczne podstawy nowej społeczności działającej na rzecz wolnego oprogramowania. Społeczności, która mogłaby dzielić się swoją pracą bez ryzyka, że ofiarowane przez nich kody źródłowe zostaną znów przekształcone w formę zamkniętego oprogramowania. Manifestacją tego było utworzenie licencji GNU GPL, która zezwalała na nieograniczoną dystrybucję niezmodyfikowanej wersji oprogramowania, ale jednocześnie nakładała pewne restrykcje jeżeli chodzi o dzieła powstałe z wykorzystaniem jego źródeł. Te restrykcje określały, że każde oprogramowanie, wykorzystujące źródła lub linkujące się z wolnym oprogramowaniem, musiało być również dostępne na zasadach licencji GPL. Ważnym efektem końcowym tego był fakt, że każde usprawnienie wykonane na wolnym oprogramowaniu stawało się automatycznie dostępne dla jego pierwotnych autorów. Projekt GNU Richarda Stallmana był pierwszym polem testowym dla zasad licencjonowania GPL. Budowała go społeczność z podobnymi celami jak ludzie związani z projektem BSD, jednak o wiele bardziej przesączona ideologią w swoich dążeniach. Dla członków zespołu BSD za otwartością projektu przemawiały względy praktyczne, podczas gdy dla ruchu wolnego oprogramowania była to kwestia natury moralnej. Ta różnica dała początek dwóm typom licencji open source: BSD-podobnym nierestrykcyjnym licencjom (nazywanymi także ang. permissive licenses) oraz restrykcyjnym licencjom zbliżonym do GPL (inaczej nazywanymi ang. copyleft licenses).
Jednocześnie w tych samych czasach zostały poczynione pierwsze próby czerpania zysku z wolnego oprogramowania. Jedną z nich było sprzedawanie kopii wolnego oprogramowania wykonywane przez Richarda Stallmana oraz FSF. Taki model biznesowy miał duży potencjał przed boomem internetowym i ewoluował później w sprzedaż dystrybucji oprogramowania dobieranego specjalnie pod konkretne zlecenie.
Innym przejawem rozwoju otwartego oprogramowania w tych czasach był projekt o nazwie X Window System. Stanowił on otwarte środowisko graficzne wykonane przez uczelnię MIT wraz z dostawcami sprzętu komputerowego, którzy byli zainteresowani dostarczaniem swoim klientom również systemu okienkowego. Projekt ten był jednakże daleki od idei sprzeciwu wobec zamkniętego oprogramowania, w końcu przecież i jego licencja X jawnie zezwalała na wykonywanie zamkniętych rozszerzeń do tego środowiska. Każdy członek konsorcjum pragnął mieć możliwość dodania własnych modułów do domyślnego wariantu środowiska, aby móc zyskać przewagę nad pozostałymi członkami. X Window System został stworzony jako wolne oprogramowanie, a sam projekt stanowił prostą formę współpracy kilku dotychczas współzawodniczących ze sobą przedsiębiorstw nad wspólnym narzędziem[POS]. To pozwoliło im na drastyczne obniżenie kosztów wytworzenia produktu, który sam w sobie nie stanowił dla nich dobra podlegającego wymianie handlowej. Taka strategia pozwoliła wszystkim oszczędzić własne zasoby oraz rozproszyć ryzyko związane z projektem.
Poza przykładami wymienionymi powyżej, w tym samym czasie istniało wiele innych, mniej zauważalnych, otwartych projektów, posługujących się jeszcze innymi licencjami. Różnorodność otwartych licencji odzwierciedlała różnorodność istniejących motywacji. Wielu programistów, którzy decydowali się na wybranie licencji GPL dla swoich projektów, nie kierowało się w takim stopniu ideologią, jak chociażby osoby uczestniczące w projektach GNU. Niektórzy czuli moralny impuls, aby uwolnić świat od tzw. software hoarding (określenie Stallmana na nie-wolne oprogramowanie), ale inni byli bardziej motywowani poprzez techniczną fascynację i postrzegali metodologie stosowane w otwartych projektach jako efektywny sposób organizacji współpracy. Programiści mieli też inne powody, aby trzymać się razem na takich zasadach: wiele otwartych projektów wytwarzało bardzo dobrej jakości kod. Ta tendencja na pewno nie była czymś uniwersalnym, ale zarazem była coraz częściej spotykana. Nie mogło tego nie dostrzec i środowisko biznesowe. Menedżerowie wyższego szczebla nie zawsze są w pełni świadomi tego, co wykorzystują ich działy IT i często zdumieni dowiadują się z dużym opóźnieniem, że już używają wolnego oprogramowania w swoich codziennych operacjach. W związku z tym korporacje zaczęły obierać aktywną rolę w wolnych projektach poprzez oferowanie własnej siły roboczej lub sprzętu komputerowego, a czasem nawet poprzez finansowanie programistów. Takie inwestycje mogły, zgodnie z optymistycznymi scenariuszami, zwrócić się wielokrotnie w przyszłości. Mówiąc wprost: sponsor zatrudnia tylko małą liczbę pełnoetatowych ekspertów w projekcie, a czerpie korzyści z pracy ofiarowanej przez wszystkie podmioty w nim zaangażowane, w tym także przez pracujących bez finansowego wynagrodzenia wolontariuszy, jak i innych programistów opłacanych przez inne przedsiębiorstwa.
Rozwój internetu, masowej współpracy oraz open source od lat 90'
Jeżeli spojrzeć na wolne oprogramowanie jako metodologię, można zauważyć, że jest to łatwy sposób na stworzenie prostego środowiska do współpracy wszystkich podmiotów zainteresowanych projektem. Sposób, w którym ograniczamy biurokracje do absolutnego minimum. Otwarte projekty zazwyczaj chętnie akceptują wszystkich, którzy wyrażają chęć uczestniczenia w nich, oraz nie wymuszają, aby ich członkowie pracowali ciągle, tj. z dnia na dzień. Dzięki temu istnieje duża potencjalna grupa ludzi oraz przedsiębiorstw mogących dołączyć do tego typu projektów. Największą jednak barierą były tu początkowo ograniczenia geograficzne, które zanikły wraz z powstaniem i rozwojem internetu w latach dziewięćdziesiątych. Sieć sprowokowała społeczności zaangażowane w wolne oprogramowanie do stworzenia takich narzędzi, jak repozytoria plików, listy mailingowe, IRC chaty, trakery zadań, systemy kontroli wersji itp., a zarazem uczyniła je dostępnymi z każdego miejsca świata. To umożliwiło im w pełni wykorzystanie swojego potencjału i rozpoczęło trzecią erę, która trwa po dzień dzisiejszy[TES].
Narzędzia wymienione powyżej przyspieszyły rozwój sieci współpracy pomiędzy wieloma otwartymi projektami oraz inspirowały nowych twórców wolnego oprogramowania. Jednym z nich był Linus Torvalds, który wykorzystując narzędzia projektu GNU rozpoczął pracę nad projektem kernela Linux. Przy pomocy różnych programistów, którzy odnaleźli projekt w sieci, kernel Linusa dojrzewał w błyskawicznym tempie. Dwa lata od pierwszego wydania Linuxa w 1991 roku ekipa projektu GNU zdecydowała, aby użyć go do budowy swojego systemu operacyjnego. Stabilne jądro systemu było jedynym elementem jakiego im brakowało. Tym sposobem w roku 1993 światło dzienne ujrzała dystrybucja Debian, zwana także GNU/Linux, która była połączeniem kernela Linuxa i oprogramowania systemowego od GNU. Kombinacja ta okazała się wyjątkowo udana i zapewniła sobie rozpoznawalność w branży IT. W trakcie, gdy wolne oprogramowanie zyskiwało coraz szerszą akceptację na świecie, powstał nowy rynek odnoszący się do komercyjnego wsparcia dla tego typu oprogramowania oraz nowych dystrybucji GNU/Linuxa, po to by spełnić rosnące wymagania. Dwie z tych dystrybucji - Red Hat oraz SUSE - zyskały szeroką adaptację na rynku serwerów webowych i serwerów aplikacji. Firmy, które je produkowały urosły do wielomilionowych spółek co pokazało przemysłowi IT, że wolne oprogramowanie może być źródłem znacznych dochodów.
Nowy trend traktował wolne oprogramowanie jedynie jako efektywny sposób wytwarzania i dystrybucji oprogramowania. Zmiana wizerunku z ideologicznego na bardziej praktyczny sprowadziła na scenę nowych aktorów, takich jak Larry Augustin, Jon Hall, Sam Ockman, Michael Tiemann i Eric S. Raymond, którzy zaczęli promować termin open source. Dzięki temu chciano odciąć się od ideologii negującej zamknięte oprogramowanie i promować aktywności o charakterze komercyjnym w ramach swojej społeczności. Bruce Perens i Eric S. Raymond utworzyli inicjatywę o nazwie Open Source Initiative, aby zapewnić merytoryczne i prawne wsparcie dla nowego ruchu. Wysiłek ten okazał się skuteczny, jako że sam termin open source zaczął zyskiwać na popularności, a na rynku pojawiły się nowe firmy czerpiące krociowe zyski z tego typu projektów. Jednym z najbardziej spektakularnych sukcesów była firma MySQL AB z ich low-endową bazą danych oraz Trolltech z zestawem narzędzi programistycznych Qt. Obie firmy wprowadziły nowy model biznesowy zwany podwójnym licencjonowaniem, w którym za darmo udostępniali swoje produkty dla projektów open source, lecz jednocześnie wymagano opłat licencyjnych od tych, którzy chcieli je zintegrować z zamkniętym oprogramowaniem. Również najwięksi giganci branży IT dostrzegli zalety posiadania bogatego portfolio otwartych produktów. Od końca lat 90' można obserwować fale otwierania wielomilionowych produktów oraz tworzenia całych fundacji wspierających ruch open source. Przykładami takowych był Sun Microsystems, który otworzył niemal cały opracowany przez siebie stos technologiczny Java oraz wiele związanych z nim narzędzi. Po dzień dzisiejszy wiele z tych projektów jest aktywnie rozwijanych pod przywództwem firmy Oracle mimo kotrowersyjnego przejęcia Sun Microsystems w 2010 roku. Innym przykładem jest IBM, założyciel fundacji Eclipse Foundation mającej na celu rozwój otwartych narzędzi programistycznych. Swoje podejście zmienił także Microsoft, którego twórca Bill Gates w latach siedemdziesiątych agresywnie atakował ruch wolnego oprogramowania1. Pierwsze przełamanie korporacji z Redmond nastąpiło w 2006 roku gdy utworzyła fundację CodePlex, zajmującą się rozwojem wolnego oprogramowania skoncentrowanego wokół swojego stosu technologicznego. Natomiast w roku 2015 Microsoft wydał otwarte i przestronnę środowisko deweloperskie Visual Studio Code, które stało się w ostatnich latach najpopularniejszym narzędziem tego typu pośród programistów2.
Podsumowanie
W dniu dzisiejszym otwarte oprogramowanie nie posiadaj już wokół siebie takiej aury tajemniczości, jak na początku swojego istnienia i pewne podstawowe cechy, które przyczyniły się do jego sukcesu, są obecnie powszechnie znane. Projekty open source nadal stanowią jednak dosyć istotny problem, gdy potrzebne jest dokonanie ich znacznie bardziej szczegółowej analizy lub też zaplanowanie stworzenia własnego przedsięwzięcia tego typu. Niebawem na blogu pojawią się kolejne artykuły nt. sposobów organizacji oraz źródłach finansowania projektów tego typu inicjatyw.
Źródła
- Computer Hobbyists - Bill Gates, Radio-Electronics (New York NY: Gernsback Publications), 1976
- Stack Overflow Developer Survey 2022 - Integrated Development Environment
[POS] Producing Open Source Software - Karl Fogel, książka, 2009
[AGP] About the GNU Project - Richard Stallman, artykuł