Tytuł oryginału: “The Magic Cauldron”
Autor: Eric S. Raymond
Tłumaczenie pochodzi z serwisu: www.linuxcommunity.pl
Tłumaczenie: Artur Skura, marzec 2001 r.

W kolejnym ze swoich słynnych esejów Eric S. Raymond przedstawia m. in. różne konkretne argumenty przemawiające za uwolnieniem źródeł. Otwartość niekoniecznie musi oznaczać straty finansowe, czy nawet niższe zyski – wręcz przeciwnie. Poczytajmy.

Nieodróżnialna od magii

W

edług walijskiej legendy, w posiadaniu bogini Ceridwen znajdował się wielki kocioł, który – za zaklęciem znanym tylko bogini – w magiczny sposób wytwarzał pożywne jedzenie. Z kolei Buckminsterowi Fullerowi zawdzięczamy należące do terminologii współczesnej nauki pojęcie “efemeralizacji”: technologii, która staje się tańsza i bardziej wydajna w miarę wymiany zasobów występujących we wcześniejszych projektach na zasoby informacyjne. Arthur C. Clarke połączył oba pojęcia w słynnym stwierdzeniu: “Jakakolwiek wystarczająco zaawansowana technologia przestaje być odróżnialna od magii”.

Wielu ludzi uważa sukces wspólnoty otwartego źródła za formę magii. Wysokiej jakości oprogramowanie powstaje “za darmo”, co wydaje się przyjemne ale trudne do utrzymania w rzeczywistym świecie, w którym istnieje konkurencja i braki zasobów. Gdzie czai się kruczek? Czy kocioł Ceridwen jest jedynie trikiem magika? Jeśli nie, to w takim razie jak w tym kontekście działa efemeralizacja? Innymi słowy: jakiego czaru użyła bogini?

Nie tylko maniacy komputerowi rozdają prezenty

Zjawisko otwartego źródła wywołało pewne zamieszanie wśród ludzi, którzy uczyli się rozwijać oprogramowanie na zewnątrz właściwej mu kultury. Katedra i bazar wyjaśnia, w jaki sposób zdecentralizowany rozwój oprogramowania oparty na współpracy obala Prawo Brooksa i sprawia, że rozwijane w ten sposób projekty osiągają bezprecedensową jakość i stabilność. W “Zagospodarowaniu noosfery” zbadałem dynamikę społeczną stanowiącą środowisko rozwoju projektów w “bazarowym” stylu argumentując, że trudno jest ją dobrze zrozumieć używając koncepcji odnoszących się do tradycyjnej gospodarki wymiany dóbr; stanie się to możliwe jeśli przyjmiemy model, który antropolodzy nazywają “kulturą prezentu”, w której współzawodniczy się o status poprzez dawanie prezentów innym. W niniejszym eseju zajmę się kilkoma popularnymi mitami dotyczącymi ekonomii produkcji oprogramowania; następnie przeniesiemy się w sferę ekonomii, teorii gier i modeli biznesowych, tworząc nowe narzędzia koncepcyjne, bez których trudno będzie nam zrozumieć mechanizmy pozwalające kulturze prezentu otwartego źródła zarobić na siebie w gospodarce wymiany.

Aby móc bez przeszkód oddać się rozważaniom, musimy (przynajmniej chwilowo) zapomnieć o wyjaśnieniu mechanizmów działania kultury prezentu. W “Zagospodarowaniu noosfery” postawiliśmy tezę, że zachowania właściwe dla kultury prezentu powstają wtedy, kiedy istnieje obfitość dóbr koniecznych do przetrwania, przez co gra w wymianę staje się mało interesująca; jest to jednak psychologiczne wyjaśnienie, nie odpowiada na pytanie o mieszany kontekst ekonomiczny, w którym pracuje większość programistów otwartego źródła. Dla większości z nich gra w wymianę straciła na atrakcyjności, co nie zmienia faktu, że nadal ich ogranicza. Ich zachowanie musi być wystarczająco uzasadnione w kontekście tradycyjnej ekonomii ubytku, by mogli się utrzymać w sferze obfitości, będącej podstawą kultury prezentu.

Dlatego w niniejszym eseju zajmiemy się metodami współpracy i wymiany utrzymującymi rozwój projektów otwartego źródła (jedynie z punktu widzenia tradycyjnej gospodarki). Równocześnie szczegółowo odpowiemy na pragmatyczne pytanie “Jak na tym zarobić pieniądze?”, podając praktyczne przykłady. Jednak najpierw wykażemy, że napięcie kryjące się za tym pytaniem w dużej mierze ma swoje źródło w dominujących, popularnych modelach ekonomii produkcji oprogramowania, z których niektóre faktycznie funkcjonują, a niektóre nie działają w ogóle.

(Jeszcze jedna uwaga: przedstawionej w tym eseju argumentacji i promocji modelu otwartego źródła nie należy traktować jako całościowej krytyki zamkniętych metod rozwoju oprogramowania, własności intelektualnej w stosunku do oprogramowania ani jako altruistycznego wezwania do “dzielenia się” oprogramowaniem. Choć głośna mniejszość społeczności otwartego źródła wciąż uwielbia tego typu argumenty, wydarzenia zaistniało po publikacji Katedry i bazaru jasno ukazują, że są one zbędne. Dla rozwoju otwartego źródła wystarczą przesłanki ekonomiczne i techniczne – wyższa jakość, większa stabilność, niższy koszt i większy wybór.)

Fabryka nie istnieje

Na wstępie powinniśmy zdać sobie sprawę z faktu, że programy komputerowe, tak jak wszelkie inne narzędzia i dobra materialne, mają dwojaką wartość: wartość użytkową i wartość rynkową.

Wartość użytkowa programu to jego ekonomiczna wartość jako narzędzia, zaś jego wartość rynkowa to wartość dobra materialnego (mówiąc językiem ekonomistów, wartość rynkowa to wartość dobra końcowego, zaś wartość użytkowa to wartość dobra pośredniego).

Większość ludzi myśląc o ekonomii produkcji oprogramowania odwołuje się do “modelu fabryki”, opartego na następujących przesłankach:

• Za większość czasu pracy programistów płaci się wartością rynkową
• Wartość sprzedaży oprogramowania jest proporcjonalna do kosztów jego rozwoju (tj. kosztów wymaganych do odtworzenia jego funkcjonalności) i jego wartości użytkowej.
• Innymi słowy ludzie mają silną tendencję do klasyfikacji wartości oprogramowania według standardów tradycyjnych dóbr przemysłowych. Obie te koncepcje są jawnie błędne.

Po pierwsze, kod pisany na sprzedaż to szczyt góry lodowej. W erze poprzedzającej nadejście mikrokomputerów 90 procent kodu pisanego na świecie było pisane na własne potrzeby w bankach i firmach ubezpieczeniowych. Najprawdopodobniej tak już nie jest: inne gałęzi przemysłu o wiele bardziej intensywnie korzystają z oprogramowania, zaś sektor finansowy nie ma tak dużego udziału w rynku jak kiedyś, ale mimo to istnieją namacalne dowody na to, że 95% kodu wciąż jest pisane na własne potrzeby przez pracowników firmy.

Zawiera się w tym większość oprogramowania tworzonego w departamentach informatyki, modyfikacje oprogramowania finansowego i bazodanowego, które są niezbędne w każdej średniej i dużej firmie. Zawiera się w tym również specjalistyczne oprogramowanie, takie jak kod sterowników urządzeń (prawie nikt nie zarabia na sprzedaży sterowników – wrócimy do tej kwestii później). Wreszcie – cały kod zawarty w urządzeniach specjalizowanych, sterowanych mikroukładami, od mechanicznych narzędzi i samolotów po samochody, kuchenki mikrofalowe i tostery. Większość kodu tworzonego na własne potrzeby firm jest zintegrowana ze środowiskiem, w którym kod ten jest używany do tego stopnia, że bardzo trudno jest go powielać i wykorzystać gdzie indziej. (Jest to prawdą bez względu na to, czy “środowiskiem” jest zestaw procedur biznesowych używanych w biurze czy system wtrysku paliwa w snopowiązałce). Tak więc zmiany zachodzące w środowisku wymagają ciągłej pracy, dzięki której oprogramowanie będzie mogło nadal spełniać swoją rolę.

Nosi to nazwę “utrzymywania” oprogramowania. Każdy inżynier oprogramowania czy analityk systemowy zdaje sobie sprawę z faktu, że związane z tym koszty stanowią ogromną większość (ponad 75%) kwot wydawanych na rozwój oprogramowania. Tak więc większość roboczogodzin programistów (a co za tym idzie – również większa część pensji) jest poświęcona pisaniu i utrzymywaniu wewnętrznego kodu, który pozbawiony jest wartości jako towar, który można sprzedać. Fakt ten można łatwo zweryfikować sprawdzając ogłoszenia o pracę dla informatyków w którejkolwiek gazecie w dziale “Potrzebna pomoc”.

Przeglądanie ogłoszeń o pracę w lokalnej gazecie jest interesującym eksperymentem, do którego przeprowadzenia gorąco Czytelnika zachęcam. Warto zbadać ogłoszenia w działach: programowanie, przetwarzanie danych i inżynieria oprogramowania, pod kątem stanowisk na których rozwija się oprogramowanie, a następnie przeanalizować dane stanowisko: czy dana osoba będzie tworzyła oprogramowanie do wewnętrznego użytku czy na sprzedaż?

Szybko stanie się jasne, że nawet korzystając z definicji określenia “na sprzedaż” o najszerszym zakresie znaczeniowym, przynajmniej w 19 przypadkach na 20 oferuje się pensję za wytwarzanie wartości użytkowej (tj. wartości jako dobra pośredniego). Z tego powodu uważamy, że jedynie 5 procent przemysłu oprogramowania opiera się na zysku ze sprzedaży. Należy jednak zauważyć, że fakt ten nie ma wielkiego znaczenia dla reszty rozważań w tym eseju; gdyby procent ten zwiększył się do 15 czy nawet 20, konsekwencje ekonomicznie byłyby w zasadzie takie same.

(Kiedy przemawiam na konferencjach technicznych, zazwyczaj rozpoczynam od zadania dwóch pytań: ilu uczestników spotkania otrzymuje zapłatę za pisanie oprogramowania oraz dla ilu z nich wysokość pensji jest uzależniona od wartości rynkowej oprogramowania. Zazwyczaj w odpowiedzi na pierwsze pytanie widzę las rąk, na drugie pytanie nie odpowiada twierdząco nikt lub prawie nikt, zaś uczestnicy są zwykle zdziwieni rozmiarem dysproporcji).

Po drugie, badając zachowanie konsumentów bardzo łatwo obalić teorię mówiącą, iż wartość rynkowa oprogramowania odpowiada kosztom jego rozwoju czy wymiany. Istnieje wiele typów dóbr materialnych, dla których teoria ta jest prawdziwa (przed dewaluacją): żywność, samochody, części do maszyn. Istnieje nawet wiele dóbr niematerialnych, których wartość rynkowa ma silny związek z kosztami rozwoju i wymiany – np. prawa do reprodukcji partytur, map czy baz danych. Tego typu dobra zachowują (a czasem nawet zwiększają) wartość rynkową, kiedy pierwotny producent nie jest już dostępny.

Natomiast jeżeli producent danego programu odchodzi z branży (albo jeśli linia produkcyjna nie jest rozwijana), maksymalna cena, którą konsumenci zechcą zapłacić za produkt gwałtownie spadnie niemal do zera, bez względu na teoretyczna wartość użytkową czy koszt wytworzenia funkcjonalnego odpowiednika. (Aby się o tym naocznie przekonać, wystarczy sprawdzić kosze na śmieci pierwszego z brzegu sklepu z oprogramowaniem.)

Zachowanie detalistów w chwili odejścia producenta może nas wiele nauczyć. Detaliści wiedzą o czymś, z czego producenci nie zdają sobie sprawy: mianowicie cena, którą klient zapłaci za produkt jest zależna od przyszłej wartości usług producenta (termin “usługi” ma tu szeroki zakres znaczeniowy, który obejmuje ulepszenia, aktualizacje i kolejne projekty).

Innymi słowy oprogramowanie należy do sektora usług, jednak funkcjonuje opierając się na bezpodstawnym złudzeniu, że należy do sektora produkcji.

Warto się zastanowić skąd się bierze to złudzenie. Przyczyna może być prosta: otóż ta niewielka część przemysłu informatycznego produkująca programy na sprzedaż jako jedyna reklamuje swoje produkty. Być może chodzi też o to, że ludzie zazwyczaj uważają produkcję za coś bardziej “rzeczywistego” niż usługi (ponieważ wynikiem jej działania są rzeczy, które można dotknąć) {1}. Warto również zauważyć, że najbardziej widoczne i reklamowane produkty są efemeryczne podobnie jak gry, w przypadku których prawdopodobieństwo kontynuacji usług jest niewielkie (jest to wyjątek, nie reguła) {2}.

Warto również zauważyć, że owo złudzenie dotyczące produkcji jest przyczyną takiej a nie innej struktury cenowej, która absolutnie nie odpowiada rozłożeniu kosztów. Jeśli (jak to jest ogólnie przyjęte) ponad 75% kosztów cyklu życiowego typowego projektu programistycznego to utrzymywanie programu, odpluskwianie go i tworzenie rozszerzeń, to powszechna polityka cenowa polegająca na ustalaniu wysokich, stałych cen zakupu i stosunkowo niskich lub zerowych opłat za obsługę techniczną musi doprowadzić do rezultatów źle służących wszystkim.

Konsumenci tracą, ponieważ model “fabryczny” nie sprzyja udostępnieniu kompetentnych usług, mimo że przemysł produkcji oprogramowania należy do sektora usług: jeśli większość pieniędzy producenta pochodzi ze sprzedaży bitów, większość wysiłków zostanie włożona w tworzenie bitów i pokazywanie ich wszędzie; to centrum pomocy a nie ośrodek przynoszenia zysku jest miejscem, do którego kieruje się najmniej skutecznych pracowników, które otrzymuje ilość środków wystarczającą jedynie do tego, by aktywnie nie odstraszać zbyt wielu klientów.

Dzieje się jeszcze gorzej. Użytkowanie programu wiąże się z telefonami do działu obsługi technicznej, co zmniejsza zyski, chyba że pobiera się opłaty za usługi. W świecie otwartego źródła próbuje się utworzyć jak największą bazę użytkowników, aby uzyskać jak największy odzew i najbardziej żywe rynki drugorzędne; w świecie zamkniętych źródeł próbuje się znaleźć jak najwięcej klientów, ale jak najmniej rzeczywistych użytkowników. Tak logika modelu “fabrycznego” najbardziej nagradza sprzedawców produkujących programy leżące na półkach: na tyle rozreklamowane, by się dobrze sprzedać, lecz w praktyce bezużyteczne.

Jest tez druga strona monety: producenci, którzy przyjęli ten moduł, po pewnym czasie poniosą klęskę. Ciągłe finansowanie kosztów obsługi ustaloną ceną produktu ma szanse powodzenia tylko na rynku rozwijającym się wystarczająco szybko, by jutrzejszymi zyskami pokryć obsługę techniczną i koszty utrzymywania programu, które pociągnęła za sobą wczorajsza sprzedaż. Kiedy rynek dojrzeje i sprzedaż spadnie, większość producentów zostanie zmuszona do redukcji kosztów osieracając produkt.

Bez względu na to, czy dzieje się to jawnie (rezygnacja z utrzymywania produktu) czy niejawnie (utrudniając uzyskanie pomocy technicznej), skutkiem jest odpychanie klientów w stronę konkurencji (ponieważ tego typu działania ujemnie wpływają na przyszłą wartość produktu, która zależy od tych usług). Tymczasowe rozwiązanie to udostępnianie poprawek jako nowych produktów opatrzonych nową ceną, jednakże konsumenci szybko się tym zmęczą. Dlatego jedyną drogą ucieczki jest brak konkurencji, tj. mieć monopol na danym rynku. Na końcu zostać może tylko jeden gracz.

I rzeczywiście: wielokrotnie byliśmy świadkami sytuacji, w których ten wadliwy, samo niszczący system eliminował potężnych zawodników zajmujących drugie miejsce w danej niszy rynkowej. (Wzorzec ten powinien być szczególnie znajomy tym wszystkim, którzy obserwowali historię zamkniętych systemów operacyjnych dla PC, edytorów tekstu, programów do obsługi księgowości czy oprogramowania biznesowego w ogólności.) Niewłaściwe bodźce, ustanowione przez ‘fabryczny’ model, wywołały dynamikę rozwoju w której zwycięzca bierze wszystko i nawet klienci zwycięzcy ostatecznie tracą.

W takim razie jaki model przyjąć? Model wydajnie i skutecznie odpowiadający strukturze kosztów cyklu życiowego oprogramowania musiałby mieć strukturę cenową opartą na kontraktach serwisowych, prenumeracie kolejnych edycji oprogramowania i ciągłej wymianie wartości między sprzedawcą a klientem. Wiedząc, że wolny rynek dąży do jak największej wydajności, możemy postawić tezę, że dojrzały przemysł produkcji oprogramowania ostatecznie przyjmie właśnie taką strukturę cenową.

Powyższe rozważania mogą nam pomóc zrozumieć dlaczego oprogramowanie otwartego źródła stanowi nie tylko technologiczne, ale i ekonomiczne wyzwanie dla obowiązującego obecnie stanu rzeczy. Wydaje się, że ustanowienie oprogramowania “wolnym/darmowym” przenosi nas do świata zdominowanego opłatami za usługi i ukazuje, jak słabym filarem poprzedniego modelu były skrywane bity zamkniętego oprogramowania.

Termin “darmowy” jest mylący z jeszcze jednego powodu: obniżenie ceny danego towaru zwiększa a nie zmniejsza całość inwestycji w podtrzymującą go infrastrukturę. Kiedy ceny samochodów spadają, automatycznie zwiększa się popyt na mechaników samochodowych – i dlatego właśnie nawet te 5% programistów otrzymujących pieniądze ze sprzedaży produktów nie powinno ucierpieć w świecie otwartego źródła. W okresie przejściowym stracą nie programiści, lecz inwestorzy, którzy błędnie zaufali strategii zamkniętych źródeł.

Kolejny mit: “informacja chce być darmowa”

Istnieje jeszcze jeden mit, znajdujący się na tym samym poziomie co model fabryczny lecz przeczący mu, którego oddziaływanie wprowadza zamieszanie do postrzegania ekonomii oprogramowania otwartego źródła. Chodzi o mit “informacja chce być darmowa” (“information wants to be free”), który sprowadza się do stwierdzenia, iż z zerowego kosztu odtworzenia informacji cyfrowej wynika, że je cena powinna wynosić 0.

Mit ten w jego najbardziej ogólnej postaci można obalić badając wartość informacji dającej dostęp do jakiegoś dobra: weźmy choćby mapę prowadzącą do skarbu, numer konta w banku szwajcarskim czy hasło do konta na komputerze. I chociaż samą informację można odtworzyć przy kosztach równych zeru, to nie można tego samego powiedzieć o rzeczach, do których bronią dostępu. Tak więc informacja może przejąć niezerowy koszt danego dobra.

Wspominam o tym micie w tym miejscu głównie po to by podkreślić, że nie ma on związku z argumentami o ekonomicznej użyteczności modelu otwartego źródła; jak później zobaczymy, miałyby one swoje uzasadnienie nawet wtedy, gdy oprogramowanie miało (dodatnią) strukturę wartości, taka jak produkowane towary. Dlatego nie ma potrzeby zajmować się pytaniem o to, czy oprogramowanie “powinno” być darmowe czy nie.

Przeciwieństwo publicznych pastwisk

Odniósłszy się sceptycznie do obowiązującego powszechnie modelu spróbujmy zbudować inny – twarde, realistyczne wyjaśnienie metod utrzymania modelu otwartego źródła.

Kwestię tę należy przeanalizować na wielu różnych poziomach. Jeden z nich dotyczy zachowania osób uczestniczących w projektach otwartych źródeł; następny – sił ekonomicznych podtrzymujących współpracę przy projektach takich jak Linux czy Apache.

I ponownie musimy obalić powszechny pogląd na model rozwoju, który utrudni nam zrozumienie omawianej kwestii. Za każdym razem, kiedy próbujemy wyjaśnić zachowanie współpracujących ze sobą osób, unosi się nad nami cień “Tragedii łąk publicznych” Garreta Hardina.

Jak wiadomo, Hardin każe nam sobie wyobrazić sobie pastwisko, którego właścicielami są chłopi z wioski, pasący na nim bydło. Jednak wypas prowadzi do stopniowej degradacji pastwiska – trawa niknie i pojawiają się błotniste pasy, na których trawa odrasta bardzo powoli. Jeśli nie istnieją żadne wspólne (i przestrzegane!) ustalenia dotyczące praw wypasu i zapobiegające degradacji, wszyscy będą próbowali wypaść jak najszybciej wypaść jak najwięcej bydła, próbując uzyskać jak najwięcej zanim pastwisko zmieni się w bagniste błoto.

Większość ludzi intuicyjnie rozumie współpracę w taki właśnie sposób. Nie jest to wcale dobra diagnoza problemów ekonomicznych otwartego źródła, które mają związek z “jazdą na gapę” (niedostatek) raczej niż zatłoczonym dobrem publicznym (używanie przez zbyt wiele osób). Tak czy inaczej analogia ta pobrzmiewa w większości nieprzemyślanych obiekcji, które możemy usłyszeć pod adresem otwartego źródła.

“Tragedia pastwisk” może zakończyć się w trojaki sposób. Łąka może zmienić się w bagno. Może też pojawić się ktoś trzeci o wystarczającej władzy, by narzucić wiosce reguły przydzielania powierzchni pastwiska (wariant komunistyczny). Trzecia możliwość to załamanie się współpracy, ogrodzenie przez chłopów tych fragmentów pastwiska, które będą w stanie obronić i zarządzanie nimi tak, by móc się utrzymać (wariant praw własności).

Kiedy ludzie bez zastanowienia umieszczają w takim modelu współpracę właściwą projektom otwartego źródła, oczekują, że będzie ona niestabilna a jej okres rozpadu będzie krótki. Ponieważ nie istnieje żaden sposób wymuszenia przydziału czasu pracy programisty przez Internet, osoba opierająca się na tym modelu może dojść do wniosku, że pastwiska zostaną podzielone, pojedyncze fragmenty oprogramowania zostaną zamknięte, zaś ilość wspólnej pracy gwałtownie spadnie.

Doświadczenie uczy nas jednak, że jest dokładnie odwrotnie. Tendencje wzrostowe oprogramowania otwartego źródła można zmierzyć ilością dziennych zgłoszeń do archiwum Metalab (głównego archiwum źródeł linuksowych) czy codziennych ogłoszeń na freshmeat.net (witrynie służącej do ogłaszania nowych (wersji) programów). Ilość przybywających programów w obu tych miejscach stale rośnie. Jest oczywiste, że istnieje coś, czego model “Tragedii pastwisk” nie jest w stanie odzwierciedlić.

Jedną z przyczyn może być fakt, że używanie oprogramowania nie obniża jego wartości. Przeciwnie – powszechne używanie oprogramowania otwartego źródła raczej zwiększa jego wartość, ponieważ użytkownicy podsyłają własne poprawki i nowe funkcje (w postaci łat nakładanych na kod). Jest to przeciwieństwo publicznych pastwisk – im większy jest wypas, tym bardziej rośnie trawa.

Następną z możliwych przyczyn jest fakt, że trudno uchwycić rynkową wartość małych łat nakładanych na wspólny kod. Załóżmy, że napiszę łatę poprawiającą irytujący błąd i wielu ludzi uzna, że ma on wartość pieniężną – w jaki sposób miałbym zebrać od nich wszystkich pieniądze? Konwencjonalne systemy płatnicze mają na tyle wysokie koszty stałe, by stać się prawdziwą przeszkodą dla tego typu mikroopłat, które mogłyby być dobrym rozwiązaniem.

Co ważniejsze, nie tylko trudno uchwycić tę wartość – trudno ja nawet określić. Przeprowadźmy eksperyment myślowy: wyobraźmy sobie, że istnieje w Internecie teoretycznie idealny system pozwalający uiszczać mikro opłaty – bezpiecznym powszechnie dostępny i o zerowych kosztach stałych. Załóżmy, że napisaliśmy łatę “Rozmaite poprawki do jądra Linuksa”. W jaki sposób ją wycenić? W jaki sposób potencjalny nabywca, który nie widział łaty, wiedziałby ile zapłacić?

Sytuacja ta przypomina odbity w krzywym zwierciadle obraz “problemu obliczeniowego” F.A. Hayka: aby handel się kręcił, potrzebny byłby nadczłowiek, potrafiący ocenić wartość użytkową łat i cieszący się dostatecznym zaufaniem, by móc ustalać ceny.

Na nieszczęście ostatnio bardzo brakuje nadludzi, więc autor łaty, J. Zwykły Hacker ma więc dwa wyjścia: albo nie pozwolić go nikomu dotknąć, albo dać go wszystkim za darmo.

Pierwsze rozwiązanie nie przynosi żadnej korzyści. Co więcej, pociąga za sobą koszty związane z wysiłkiem potrzebnym do nałożenia i przystosowania łaty do każdej nowej wersji jądra. Tak więc zysk płynący z takiego rozwiązania jest raczej ujemny (co zwielokrotnia jeszcze szybkie tempo ukazywania się nowych wersji w świecie otwartego źródła).

Udostępnienie łaty może nie przynieść żadnej korzyści, może też zachęcić innych do podzielenia się swoimi łatami i poprawkami, które mogą rozwiązać niektóre problemy J. Hackera, które mogłyby się pojawić w przyszłości. Wybór ten, z pozoru altruistyczny, jest w rzeczywistości optymalnie egoistyczny, jeśli przyjąć punkt widzenia teorii gier.

Analizując współpracę w ramach projektów otwartego źródła powinniśmy zwrócić uwagę na fakt, że choć istnieje problem “jazdy na gapę” (może zabraknąć rąk do pracy z powodu braku pieniędzy czy innej rekompensaty), problem ten nie rośnie wraz z liczbą użytkowników {3}. Złożoność i koszty stałe komunikacji w projektach otwartego źródła niemal zawsze są funkcją liczby zaangażowanych programistów; zwiększenie liczby użytkowników projektu, którzy nigdy nie badają źródeł nic nie kosztuje. Może się co prawda zwiększyć ilość głupich pytań na listach dyskusyjnych związanych z projektem, jednak łatwo sobie z tym poradzić tworząc i utrzymując listę najczęściej zadawanych pytań i odpowiedzi (FAQ, Frequently Asked Questions) i jawnie ignorować tych, którzy się z nią nie zapoznali (w praktyce często stosuje się obie te metody).

Problem “jazdy na gapę” w projektach otwartego źródła jest głównie funkcją kosztów związanych z przesyłaniem łat.

Ponieważ nie istnieje żadna materialna rekompensata, potencjalny uczestnik projektu, któremu niespecjalnie zależy na grze o reputację w kulturze hackerskiej (zob. Zagospodarowanie noosfery) , może sobie pomyśleć: “Nie chce mi się wysyłać tej poprawki, bo będę musiał uporządkować łatę, przygotować wpis do ewidencji zmian (Changelog) i podpisać dokumenty FSF…”. Dlatego też liczba uczestników (oraz, w drugim rzędzie, również sukces) projektów jest silnie uzależniony i odwrotnie proporcjonalny do liczby kroków, które uczestnik musi podjąć aby podesłać swoje poprawki. Koszty związane z przyłączeniem się do projektu mogą być natury technicznej lub politycznej. Dlatego w mojej opinii wyjaśniają one dlaczego luźna, amorficzna kultura linuksowa przyciągnęła o rząd wielkości więcej energii ludzi skłonnych do współpracy niż bardziej zorganizowana i scentralizowana grupa BSD – i dlaczego rola Free Software Foundation zmalała wraz z powstaniem Linuksa.

No dobrze: wyjaśniliśmy już sobie dlaczego J. Zwykły Hacker udostępnił swoją łatę za darmo – jest to jednak wyjaśnienie faktu, który miał już miejsce. Spróbujmy teraz zastanowić się nad przesłankami ekonomicznymi: co spowodowało, że J. P. Hacker w ogóle napisał łatę, zamiast pracować nad jakimś zamkniętym programem, który mógłby mu przynieść korzyści materialne? Jakie modele biznesowe tworzą korzystne warunki, dzięki którym oprogramowanie otwartego źródła może rozwijać się bez przeszkód?

Dlaczego źródła są zamykane

Zanim przejdziemy do klasyfikacji modelów biznesowych otwartego źródła, zastanówmy się nad korzyściami płynącymi z zamknięcia kodu. Co tak naprawdę chronimy zamykając źródła?

Załóżmy, że wynajmujemy kogoś do napisania specjalnego pakietu księgowego dla naszej firmy. Problem ten nie zostanie rozwiązany lepiej jeśli zamkniemy źródła; jedynym racjonalnym powodem ich zamknięcia może być chęć sprzedaży pakietu lub niedopuszczenia do niego konkurencji.

Oczywiście w ten sposób ochrania się wartość rynkową, ale w przypadku 95% programów pisanych na użytek wewnętrzny nie ma to znaczenia. Jakie więc inne korzyści niesie z sobą zamknięcie źródeł?

Warto również przyjrzeć się kwestii ochrony pakietu przed konkurencją. Załóżmy, że udostępniamy ów program księgowy na licencji otwartego źródła. Po pewnym czasie zdobywa popularność, dzięki czemu rozwija się również korzystając z poprawek naniesionych przez społeczność otwartego źródła. Załóżmy, że konkurencja też zaczyna go używać: odnosi korzyść nie ponosząc kosztów i wchodzi na nasz teren. Czy argument ten przemawia przeciwko udostępnieniu pakietu na zasadach otwartego źródła?

Może tak, może nie. W rzeczywistości chodzi bowiem głównie o to, czy zysk pochodzący z tworzenia pakietu w modelu rozproszonym przewyższy straty spowodowane rosnącą konkurencją ze strony firm, które również na tym skorzystały. Wielu ludziom trudno jest rzeczowo podejść do tej kwestii i zazwyczaj popełniają błąd polegający na (a) pominięciu korzyści płynących z pomocy w rozwijaniu projektu, oraz (b) doliczaniu kosztów stworzenia programu: ponieważ i tak musielibyśmy zapłacić za napisanie programu, więc traktowanie ich jako kosztów otwarcia źródeł jest nieporozumieniem.

Często jako powód zamknięcia źródeł podaje się obawę przed ujawnieniem poufnych szczegółów planu biznesowego, które mogą być zawarte w jakiejś szczególnej funkcji programu. W rzeczywistości jest to argument nie przeciwko zamknięciu źródeł, lecz przeciwko złemu projektowaniu: w dobrze napisanym programie księgowym wiedza biznesowa w ogóle nie powinna być zawarta w kodzie, lecz w schemacie lub języku specyfikacji zaimplementowanym w silniku programu (analogicznie do schematów baz danych, w których wiedza biznesowa oddzielona jest od mechaniki silnika bazodanowego). Oddzielenie tych dwóch funkcji pozwoli nam zachować klejnot koronny (schemat) uzyskując równocześnie maksymalne korzyści z otwarcia silnika.

Istnieją jeszcze inne przyczyny zamykania kodu źródłowego, są one jednak całkiem irracjonalne. Możemy np. się łudzić, że zamknięcie źródeł wpłynie pozytywnie na bezpieczeństwo systemów biznesowych chroniąc je przed krakerami i szpiegami – w tym wypadku polecam natychmiastową rozmowę terapeutyczną ze specjalistą od kryptografii. Naprawdę profesjonalni paranoicy wiedzą, że nie warto ufać bezpieczeństwu systemów zamkniętych, ponieważ doświadczyli tej prawdy na własnej skórze. Bezpieczeństwo to jeden z aspektów solidności: jedynie algorytmy i implementacje, które zostały dogłębnie sprawdzone, można uznać za bezpieczne.

Model oparty na wartości użytkowej

Dzięki istotnemu rozróżnieniu między wartością użytkową i rynkową możemy zauważyć, że otwarcie kodu źródłowego zagraża jedynie wartości rynkowej, a nie wartości użytkowej.

Jeśli istotnie wartość użytkowa a nie rynkowa jest głównym motorem rozwoju oprogramowania i (jak przekonywałem w Katedrze i bazarze) otwarty rozwój jest rzeczywiście bardziej skuteczny i wydajny niż zamknięty, możemy oczekiwać, że powstaną sytuacje, w których wartość użytkowa pozwoli na finansowanie rozwoju projektu.

Przypadek Apache: podział kosztów

Załóżmy, że pracujemy dla firmy, która – by móc funkcjonować – potrzebuje bardzo wydajnego i stabilnego serwera WWW. Być może zajmuje się handlem elektronicznym, być może jest to znana agencja reklamowa, być może portal: serwer musi być dostępny 24 godziny na dobę 7 dni w tygodniu, musi być szybki i elastyczny. Jak to uzyskać?

Mamy trzy drogi do wyboru:

Kupno zamkniętego serwera WWW

W tym wypadku zakładamy, że priorytety producenta zgadzają się z naszymi i że jest on na tyle kompetentny, by spełnić wspomniane założenia. Nawet jeśli oba te warunki zostaną spełnione, prawdopodobnie serwer będzie miał problemy z elastycznością: będziemy mogli dostosować go do własnych potrzeb jedynie poprzez interfejsy wybrane przez producenta. Wybór zamkniętego serwera WWW nie jest popularną decyzją.

Stworzenie własnego serwera

Napisanie własnego serwera WWW nie jest opcją, którą należy odrzucić na samym początku: serwery WWW nie są zbyt skomplikowane, a w każdym razie na pewno mniej niż przeglądarki, tak więc specjalizowany serwer może być stosunkowo niewielki. I choć będziemy musieli zapłacić za czas pracy programistów, otrzymamy dokładnie te funkcje, których potrzebujemy oraz wymaganą elastyczność. Z drugiej strony może się okazać, że po naszym odejściu firma będzie miała z nim problemy.

Dołączenie do Apache Group

Serwer Apache został zbudowany przez grupę administratorów stron WWW współpracujących przez Internet, którzy zdali sobie sprawę z faktu, że wspólna praca nad kodem ma większy sens niż rozwijanie wielu równoległych projektów. Dzięki temu udało im się połączyć większość zalet płynących z utworzenia własnego projektu z czystością kodu płynącą z weryfikacji przez szersze grono osób.

Argumenty przemawiające za wyborem Apache są bardzo silne; o ich sile możemy przekonać się choćby z przeprowadzanych co miesiąc badań firmy Netcraft, które wykazują, że udział Apache w rynku serwerów WWW rośnie od samego początku, skutecznie konkurując ze wszystkimi zamkniętymi serwerami. Kiedy piszę te słowa w czerwcu 1999 roku, Apache i powstałe na jego bazie serwery zdobyły 61% rynku (Netcraft), a wszystko to bez prawnego właściciela, bez promocji ani żadnej firmy, która podpisałaby z Apache Group umowę o stałej współpracy serwisowej.

Historia Apache przedstawia ogólny model, w którym użytkownicy sami decydują się na finansowanie projektu otwartego źródła, ponieważ dzięki temu niższym kosztem uzyskują lepszy produkt {4}.

Przypadek Cisco: rozłożenie ryzyko

Kilka lat temu dwóm programistom w Cisco (firmie produkującej osprzęt sieciowy) zlecono napisanie rozproszonego systemu kolejkowania zadań do wydruku, który miał być używany w sieci korporacyjnej Cisco. Było to duże wyzwanie: należało nie tylko pozwolić dowolnemu użytkownikowi A skorzystać z dowolnej drukarki B (która mogła znajdować się w sąsiednim pokoju lub tysiące kilometrów od niego), należało również zadbać o to, by w przypadku braku papieru lub tonera zadanie zostało przydzielone innej drukarce znajdującej się w pobliżu, zaś administrator powinien zostać powiadomiony o zaistniałej sytuacji.

Programiści z Cisco dokonali szeregu sprytnych modyfikacji (http://www.tpp.org/CiscoPrint/) standardowego uniksowego oprogramowania do zarządzania kolejką wydruku, dodali kilka skryptów pomocniczych – i oprogramowanie było gotowe. I wtedy właśnie zdali sobie sprawę, że Cisco ma problem.

Problem polegał na tym, że żaden z nich nie mógł zostać w Cisco wiecznie. Po pewnym czasie tak czy inaczej odejdą, zaś oprogramowanie pozostawione bez opieki zacznie gnić (tj. stopniowo przestać odpowiadać rzeczywistości). Żaden programista nie chce, by przytrafiło się to jego pracy, zaś nasz dzielny duet słusznie uważał, że Cisco zapłaciło za rozwiązanie, które powinno trwać dłużej niż ich zatrudnienie w tej firmie.

Poszli więc do dyrektora działu prosząc go o pozwolenie na udostępnienie tego oprogramowania na zasadach otwartego źródła. Argumentowali, że wartość rynkowa nie ulegnie utracie, zaś zyskać można wiele. Tworząc korzystne warunki dla rozwoju społeczności użytkowników i programistów pracujących w różnych korporacjach, Cisco mogło zrekompensować utratę twórców oprogramowania.

Historia Cisco przedstawia ogólny model, w którym otwarte źródło służy nie tyle do obniżenia kosztów, co do rozłożenia ryzyka. Wszystkie strony zgodziły się, że otwartość źródła, jak również obecność społeczności współpracowników, finansowanej przez różne niezależne instytucje, stanowi zabezpieczenie mające wartość ekonomiczną (co sprawiło, że zdecydowano się na finansowanie projektu).

Dlaczego wartość rynkowa sprawia problemy

Trudno jest uchwycić bezpośrednią wartość rynkową oprogramowania otwartego źródła. Problem ten nie jest natury technicznej: kod źródłowy można kopiować dokładnie tek samo, jak wersje binarne, zaś przestrzeganie praw autorskich i licencji nie mogłoby być trudniejsze w przypadku produktów otwartego źródła niż ma to miejsce w przypadku programów zamkniętych.

Problemem jest natura społecznego kontraktu, dzięki któremu rozwijają się projekty otwartego źródła. Istnieją trzy powody, z których każdy wspiera dwa pozostałe, dla których główne licencje otwartego źródła zabraniają wprowadzania ograniczeń dotyczących użytkowania, redystrybucji i modyfikacji, które ułatwiłyby uchwycenie przychodów pochodzących ze sprzedaży bezpośredniej. Aby zrozumieć te powody, należy zbadać kontekst społeczny, w którym dokonała się ewolucja istniejących licencji: internetową kulturę hackerską.

Mimo mitów na temat kultury hackerskiej, w które wciąż jeszcze (w 1999 r.) wierzy się na zewnątrz, żaden z tych powodów nie ma nic wspólnego z wrogim nastawieniem do rynku. Chociaż mniejszość hackerów rzeczywiście ma wrogie nastawienie do motywacji opartej na chęci zysku, ogólna chęć i wola współpracy społeczności z firmami przygotowującymi pakiety z Linuksem dla zysku, takimi jak Red Hat, SuSE czy Caldera ukazuje, że większość hackerów z entuzjazmem podejmie współpracę ze światem korporacyjnym, jeśli będzie to służyło ich celom. Prawdziwe powody, dla których hackerzy są niechętni licencjom pozwalającym uzyskać bezpośredni przychód, są bardziej subtelne i interesujące.

Pierwszy powód ma związek z symetrią. Choć większość programistów otwartego źródła nie ma w zasadzie nic przeciwko temu, by inni zarabiali na ich prezentach, większość domaga się również, by nikt (być może za wyjątkiem twórcy pakietu) nie znajdował się w uprzywilejowanej pozycji jeśli chodzi o czerpanie zysków. Innymi słowy J. Zwykły Hacker chce, by Korporacja Fubar czerpała zysk ze sprzedaży jego programów i łat dopóty, dopóki sam J. Z. Hacker również może na nich zarabiać.

Kolejny powód ma związek z niezamierzonymi konsekwencjami. Hackerzy zaobserwowali, że licencje zawierające ograniczenia dotyczące opłat za “komercyjne” użytkowanie czy sprzedaż (najbardziej powszechna forma czerpania zysku z bezpośredniej wartości rynkowej, niewydająca się nierozsądną), mają poważne negatywne konsekwencje. Pierwszy problem to komplikacje prawne związane z publikacją tanich antologii archiwów z oprogramowaniem na płytach CD, które chcielibyśmy wspierać. Ujmując rzecz bardziej ogólnie: ograniczenia dotyczące użytkowania, sprzedaży, modyfikacji i dystrybucji (i inne komplikacje zawarte w licencji) utrudniają śledzenie zgodności i (w miarę, jak liczba pakietów rośnie) powodują eksplozję subiektywnej niepewności i potencjalnego ryzyka związanego z kwestiami prawnymi. Tego typu skutki są uważane za szkodliwe, stąd też silna presja społeczna by licencje były proste i wolne od ograniczeń.

Ostatni i najistotniejszy powód ma związek zachowaniem dynamiki weryfikacji kodu przez społeczność oraz kultury prezentu, które opisałem w Zagospodarowaniu noosfery. Ograniczenia licencyjne mające na celu ochronę własności intelektualnej czy przechwycenie bezpośredniej wartości rynkowej sprawiają, że “rozwidlenie” projektu staje się niemożliwe ze względów prawnych. (Jest tak np. w przypadku tak zwanych “licencji społeczności” Suna dla produktów takich jak Java czy Jini). Chociaż rozwidlenie jest traktowane negatywnie, uważa się je równocześnie za niezmiernie ważny czynnik, umożliwiający wyjście z sytuacji takich jak niekompetencja opiekuna pakietu czy zmiana kierunku rozwoju (np. przyjęcie bardziej zamkniętej licencji).

Społeczność hackerska toleruje pewne odstępstwa od reguły symetrii; toleruje więc licencje takie jak NPL Netscape, które dają pewne przywileje twórcom kodu (w przypadku NPL jest to wyłączność na korzystanie z otwartego kodu Mozilli w produktach pochodnych, włączając w to programy zamknięte). Jest natomiast mniej tolerancyjna w kwestii niezamierzonych konsekwencji, a już zupełnie nie toleruje restrykcji dotyczącej rozwidlenia projektu (dlatego sunowskie “licencje społeczności” stworzone dla Javy i Jini zostały w większości odrzucone przez społeczność).

(Warto jeszcze raz powtórzyć, że nikt w społeczności hackerskiej nie chce rozszczepienia projektów na dwie współzawodniczące ze sobą linie projektowe. Przeciwnie: jak zauważyliśmy w Zagospodarowaniu noosfery, istnieje bardzo silna presja społeczna przeciwna rozwidlaniu, za którą stoją bardzo rzeczowe przesłanki. Nikt również nie chce stać na linii frontu, zeznawać w sądzie czy gasić pożary. Jednak prawo do rozwidlania projektów jest jak prawo do walki, do ścigania kogoś na drodze sadowej, do noszenia broni: nie chcemy wykorzystać żadnego z tych praw, jeśli jednak ktoś próbuje nam je odebrać, jest to oznaką poważnego niebezpieczeństwa.)

Stąd też klauzule zawarte w Definicji Open Source (OSD), którą napisano właśnie po to, by wyrazić konsensus społeczności hackerskiej dotyczący kluczowych aspektów standardowych licencji (GPL, BSD, MIT i artystycznej). Klauzule te bardzo utrudniają przechwycenie bezpośredniej wartości rynkowej.

Modele oparte na pośredniej wartości rynkowej

Mimo to istnieją metody utworzenia rynków zbytu w sektorze usług związanych z oprogramowaniem, dzięki którym możliwe jest przejęcie czegoś w rodzaju pośredniej wartości rynkowej. Istnieje pięć znanych modeli tego typu i dwa oparte na spekulacjach (w przyszłości może powstać ich więcej).

Przewodnictwo/tworzenie pozycji rynkowej

W tym modelu korzystamy z oprogramowania otwartego źródła aby stworzyć pozycję rynkową zamkniętemu oprogramowaniu, które wytwarza bezpośredni przychód. Najpopularniejszy wariant to udostępnienie źródeł oprogramowania klienckiego, umożliwiającego sprzedaż serwerów czy czerpanie dochodów z subskrypcji i reklam związanych z portalem.

Netscape Communications przyjęła właśnie tę strategie otwierając źródła Mozilli na początku 1998 roku. Kiedy pojawiła się pierwsza wersja Internet Explorera Microsoftu, przychody ze sprzedaży przeglądarki Netscape wynosiły 13% i spadały. Agresywny marketing Internet Explorera (oraz półlegalne praktyki polegające na sprzedaży IE wraz z Windows, które stały się kluczową kwestią w procesie antymonopolowym) szybko doprowadziły do spadku udziału w rynku przeglądarki Netscape wywołując obawy, że Microsoft chce zmonopolizować rynek przeglądarek i użyć zdobytej w ten sposób kontroli nad HTML w celu eliminacji Netscape z rynku serwerów.

Otwierając źródła wciąż bardzo popularnej przeglądarki, Netscape skutecznie zablokowała możliwość zmonopolizowania rynku przeglądarek przez Microsoft. Netscape oczekiwało, że współpraca wokół otwartego projektu przyspieszy rozwój i odpluskwianie przeglądarki zmuszając Microsoft do nadrabiania zaległości i nie pozwalając mu przejąć wyłączności na określenie kształtu HTML.

Strategia ta okazała się skuteczna: w listopadzie 1998 roku Netscape zaczęło odzyskiwać udział w rynku, który utraciło na rzecz IE. Kiedy na początku 1999 roku firma została przejęta przez AOL, korzyści płynące z utrzymywania Mozilli były wystarczająco jasne, by deklaracja o kontynuacji projektu stała się jedną z pierwszych ogłoszonych przez AOL, mimo że projekt był jeszcze w fazie alfa.

Lukrowane ciasteczka

Ten model przeznaczony jest dla sprzedawców sprzętu (w tym kontekście chodzi o wszelki sprzęt komputerowy – od urządzeń peryferyjnych, takich jak karty ethernetowe, po całe systemy komputerowe). Presja rynku zmusiła firmy produkujące sprzęt do pisania i utrzymywania oprogramowania (od sterowników do urządzeń, poprzez narzędzia konfiguracyjne aż po kompletne systemy operacyjne), jednak samo oprogramowanie nie przynosi zysków. Łączą się z nim pewne koszty stałe, często dość pokaźne. Producent chce sprzedać swoje urządzenie; musi do niego dołączyć oprogramowanie (ów “lukier na ciasteczku”), jednak dla jego biznesu jest to rzecz drugorzędna.

W tej sytuacji otwarte źródło jest oczywista opcją. Nie traci się zysków ze sprzedaży, więc rozwiązanie to nie pociąga negatywnych konsekwencji. Producent zyskuje za to znacznie większy zespół programistów, szybszy i bardziej elastyczny model reakcji na potrzeby użytkowników i większa stabilność, którą zapewnia weryfikacja przez społeczność. Oprogramowanie zostaje przeniesione na inne platformy za darmo. Prawdopodobnie także zyskuje się większą lojalność klientów, w miarę jak ich działy techniczne dokonują modyfikacji pozwalających im lepiej dostosować oprogramowanie do własnych potrzeb.

Producenci zwykle zgłaszają kilka zastrzeżeń w związku z otwarciem kodu sterowników urządzeń. Ponieważ w tym eseju omawiam bardziej ogólne kwestie, napisałem do niego załącznik “Dlaczego zamknięcie kodu sterowników powoduje, że producenci tracą pieniądze”, który można znaleźć na końcu tej książki.

Zabezpieczenie przyszłego rozwoju produktu, właściwe dla modelu otwartego źródła, widać szczególnie wyraźnie w przypadku “lukrowania ciasteczka”. Okres produkcji i wspierania sprzętu dobiega w pewnym momencie końca – a wtedy konsumenci są zdani sami na siebie. Jeśli jednak maja dostęp do kodu źródłowego sterowników i mogą je łatać wedle upodobań, jest bardziej prawdopodobne, że jako zadowoleni klienci dokonają kolejnych zakupów u tego samego producenta.

Bardzo dramatycznym przykładem modelu “lukrowanego ciasteczka” była podjęta w 1999 roku decyzja Apple Computer dotycząca udostępnienia kodu źródłowego “Darwina”, jądra serwerowego systemu operacyjnego MacOS X.

Rozdanie przepisów i otwarcie restauracji

W tym modelu oprogramowanie otwartego źródła służy utworzeniu pozycji rynkowej dla oferowanych usług, a nie zamkniętego oprogramowania (jak w modelu trzecim).

(Wcześniej nazywałem ten model “Rozdanie maszynek do golenia i sprzedaż żyletek do nich”, jednak związek miedzy tymi dwoma nie jest tak ścisły, jak to sugeruje analogia miedzy maszynką a ostrzem.)

Model ten po raz pierwszy wykorzystało Cygnus Solutions, prawdopodobnie pierwsza firma Open Source. Kiedy w 1989 powstawało Cygnus Solutions, narzędzia GNU stanowiły platformę programistyczną istniejącą na wielu platformach, jednak na każdej platformie dane narzędzie korzystało z innego procesu konfiguracji i wymagało innego zestawu łat. Cygnus udomowił narzędzia GNU i stworzył skrypt “configure”, który ujednolicił proces budowania (“przepis”), a następnie zajął się sprzedażą usług serwisowych i wersji binarnych rozpowszechnianych z ich wersją narzędzi GNU (“restauracja”). Zgodnie z wymogami GPL pozwalali klientom swobodnie korzystać, dystrybuować i modyfikować rozpowszechniane przez nich oprogramowanie, jednak mogli zakończyć umowę serwisową (lub zażądać wyższej opłaty) jeśli w danym miejscu było więcej użytkowników korzystających z umów serwisowych, niż to określono w umowie (nie ma dzielenia się przy ladzie z sałatkami).

Tak samo postępuje Red Hat i inni dystrybutorzy Linuksa. W rzeczywistości nie sprzedają oni oprogramowania, bitów samych w sobie, lecz wartość dodaną, polegającą na złożeniu i przetestowaniu działającego systemu operacyjnego, łącznie z gwarancją (choćby niejawną) użyteczności handlowej, oraz kompatybilności komponentów z innymi systemami operacyjnymi tej samej marki. Sprzedawana przez nich wartość dodana mieści w sobie również darmową pomoc techniczna przy instalacji oraz upusty przy przedłużaniu umów serwisowych.

Bardzo potężnym rezultatem przyjęcia modelu otwartego źródła jest budowanie rynku; jest to szczególnie prawdziwe w odniesieniu do firm, które znajdują się w uprzywilejowanej pozycji jeśli chodzi o usługi. Bardzo pouczającym przykładem jest przypadek Digital Creations, powstałej w 1998 roku firmy pierwotnie zajmującej się tworzeniem stron WWW, specjalizującej się w tworzeniu witryn wymagających skomplikowanych baz danych i transakcji. Ich głównym narzędziem, klejnotem koronnym własności intelektualnej firmy, jest aplikacja służąca do publikacji obiektów, która nosiła wiele nazw i występowała w wielu inkarnacjach, a która obecnie nazywa się Zope.

Kiedy firma zaczęła szukać inwestora, jeden z nich dokonał dokładnej analizy segmentu rynku, pracowników firmy i ich narzędzi. Następnie zasugerował, by Digital Creations udostepniło Zope na licencji otwartego źródła.

Jak na standardy tradycyjnego przemysłu produkcji oprogramowania, ruch ten wyglądał na absolutnie szalony. Według konwencjonalnej mądrości przekazywanej w szkołach biznesu, rdzenna własność intelektualna jaka jest Zope, stanowi klejnot koronny firmy, którego pod żadnym pozorem nie można się pozbyć. Jednak inwestor zaobserwował dwa istotne fakty: po pierwsze, prawdziwym atutem firmy była inteligencja i umiejętności jej pracowników; po drugie – prawdopodobieństwo, że Zope wytworzy większą wartość jako budowniczy rynku niż tajne narzędzie, było o wiele większe.

Aby zdać sobie z tego sprawę, wystarczy porównać dwa scenariusze. Gdybyśmy przyjęli scenariusz tradycyjny, Zope pozostałby tajna bronią Digital Creations. Załóżmy, że byłby bronią bardzo skuteczną. W rezultacie firma byłaby w stanie w krótkim czasie dostarczyć wysokiej jakości rozwiązania – ale nikt by się o tym nie dowiedział. Łatwo byłoby zadowolić klientów, ale trudniej ich pozyskać.

Inwestor zauważył zaś, że otwarcie Zope będzie miało kluczowe znaczenie dla rozreklamowania prawdziwego atutu Digital Creations: tworzących tę firmę ludzi. Uważał, że klienci rozważający wykorzystanie Zope zdecydują, iż zatrudnienie ekspertów zamiast rozwijanie specjalizowanego rozwiązania wewnątrz firmy będzie bardziej wydajne.

Jedna z kluczowych osób w Zope oświadczyła publicznie, że przyjęcie przez firmę strategii otwartego źródła “otworzyło przed nią wiele drzwi, które w przeciwnym wypadku pozostałyby zamknięte”. Potencjalni klienci właściwie reagują na logikę tej sytuacji: Digital Creations dobrze prosperuje.

Innym przykładem z ostatniej chwili jest e-smith (http://www.e-smith.net). Firma ta sprzedaje umowy na usługi serwisowe dla kluczowego oprogramowania otwartego źródła, serwerów internetowych działających na zmodyfikowanej wersji Linuksa. Jedna z osób zarządzających firmą tak wyraził się o pobieraniu darmowego oprogramowania e-smith: “Większość firm uważałoby to za piractwo – dla nas jest to darmowy marketing” (http://www.globetechnology.com/gam/News/19990625/BAND.html).

Sprzedaż akcesoriów

Firmy, które przyjęły ten model, sprzedają akcesoria mające związek z oprogramowaniem otwartego źródła, począwszy od drobnostek, takich jak kubki i koszulki, skończywszy na profesjonalnie przygotowanej i wydanej dokumentacji.

O’Reilly & Associates, wydawca wielu znakomitych publikacji dotyczących oprogramowania otwartego źródła jak również niniejszej książki, jest dobrym przykładem firmy korzystającej z tego modelu. Co więcej, O’Reilly zatrudnia i wspomaga znanych hackerów oprogramowania otwartego źródła, takich jak Larry Wall czy Brian Behlendorf), przez co buduje swoją reputację w wybranym przez siebie segmencie rynku.

Wolna przyszłość, płatna teraźniejszość

Ten model polega na udostępnieniu wersji binarnych i źródłowych korzystając z zamkniętej licencji, która zawiera datę wygaśnięcia ograniczeń. Można np. napisać licencję, która zezwala na swobodną redystrybucję, a jednocześnie zabrania bezpłatnego wykorzystywania do celów komercyjnych i gwarantuje, że licencja programu ulegnie zmianie na GPL w rok po dacie udostępnienia danej wersji oraz w przypadku zamknięcia firmy.

Klienci firmy wykorzystującej ten model działalności mogą dostosować produkt do swoich potrzeb, ponieważ dysponują jego źródłem. Produkt jest zabezpieczony na przyszłość – licencja gwarantuje, że społeczność będzie mogła przejąć produkt jeśli firma zakończy działalność.

Ponieważ zarówno cena jak i popyt uzależnione są od oczekiwań klientów, po przyjęciu tego modelu firma powinna zwiększyć obroty. Ponieważ zaś starszy kod jest udostępniany na licencji GPL, zostanie on zweryfikowany przez społeczność, zostaną naprawione błędy i dodane drobne nowe funkcje, co pozwala zdjąć z barek opiekunów pakietu 75% ciężaru.

Model ten jest z powodzeniem stosowany przez Alladin Enterprises, twórców popularnego programu Ghostscript (narzędzia, które potrafi zinterpretować Postscript i przetłumaczyć go na języki rozumiane przez wiele drukarek).

Główna wada tego modelu polega na tym, że początkowe restrykcje ograniczają weryfikację przez społeczność i wczesny udział w cyklu produkcyjnym – właśnie wtedy, kiedy jest to najbardziej potrzebne.

Wolne oprogramowanie, płatna marka

Jest to model teoretyczny: otwieramy technologię, natomiast zatrzymujemy zestaw testów czy też kryteriów decydujących o zgodności ze standardem, a następnie sprzedajemy użytkownikom markę: zaświadczamy, że ich implementacja technologii jest zgodna ze wszystkimi pozostałymi oznaczonymi tą marką. (W ten właśnie sposób Sun Microsystems powinien postąpić z Javą i Jini.)

Wolne oprogramowanie, płatna treść

Jest to kolejny model teoretyczny. Wyobraźmy sobie usługę polegającą na dostarczaniu informacji, np. bieżących cen akcji. W tym przypadku wartość usługi nie leży ani w oprogramowaniu klienckim, ani serwerowym, lecz w obiektywnej informacji, na której można polegać. Można więc otworzyć oprogramowanie i sprzedawać zapisy na treść. W miarę jak hackerzy będą przenosić oprogramowanie klienckie na nowe platformy, rynek będzie się powiększał automatycznie.

(Dlatego AOL powinien otworzyć swoje oprogramowanie klienckie.) [Nie jest to już model zupełnie teoretyczny. Istnieje oprogramowanie Jabber (zarówno kod serwera jak i klientów jest otwarty) służące do przesyłania wiadomości, w tym treści płatnej. 9 maja 2001 France Telecom zainwestowało w Jabbera 7 mln dolarów – przyp. tłum.]

Kiedy warto być otwartym, kiedy warto być zamkniętym

Przyjrzawszy się modelom biznesowym, które wspomagają rozwój oprogramowania, możemy przejść do bardziej ogólnego pytania dotyczącego ekonomicznego uzasadnienia strategii otwartego i zamkniętego źródła. Przede wszystkim musimy sobie jasno zdać sprawę z korzyści wynikających z obu strategii.

Jakie są korzyści?

Podejście zamkniętego źródła pozwala gromadzić dochód z sekretnych bitów, zamyka jednak drogę do prawdziwie niezależnej weryfikacji przez społeczność programistów. Podejście otwartego źródła czyni tego typu weryfikację możliwą, nie otrzymujemy jednak przychodu z okrytych tajemnicą bitów.

Korzyści płynące z ukrywania bitów są ogólnie rozumiane: stanowią one podstawę tradycyjnych modeli biznesowych producentów oprogramowania. Do niedawna nie rozumiano korzyści płynących z niezależnej weryfikacji przez społeczność programistów. Jednak przykład systemu operacyjnego Linux nauczył nas tego, z czego powinniśmy sobie zdać sprawę wiele lat temu, patrząc na powstanie kluczowego oprogramowania utrzymującego Internet i inne dziedziny inżynierii: mianowicie weryfikacja, którą zapewnia otwarte źródło, jest jedyna skalowalna metodą, która pozwala osiągnąć wysoką jakość i stabilność.

Dlatego na rynku, na którym istnieje silna konkurencja, klienci, którym zależy na wysokiej jakości i stabilności wybiorą producentów, którzy zdecydowali się na otwarte źródło i odkryli metody czerpania dochodów z rynku usług, wartości dodanej i dodatkowych rynków związanych z oprogramowaniem. Dlatego właśnie Linux odniósł tak błyskotliwy sukces, którego udział w rynku serwerów wzrósł od zera w 1996 roku do ponad 17% pod koniec 1998 roku i wydaje się, że w ciągu dwóch lat zdominuje rynek. (Według ustaleń IDC z początku 1999 roku, do 2003 roku Linux będzie rozwijać się szybciej niż wszystkie inne systemy operacyjne łącznie.)

Niemal równie ważną korzyścią płynącą z otwartego źródła są promowane przezeń otwarte standardy i powstające wokół nich rynki. Niespotykany rozwój Internetu zawdzięczamy w dużej mierze temu, że nikt nie jest właścicielem TCP/IP, nikt nie może zamknąć podstawowych protokołów, na których opiera się Internet.

“Efekt sieci”, będący głównym czynnikiem odpowiedzialnym za sukces TCP/IP sprowadza się głównie do kwestii zaufania i symetrii. Strony zainteresowane dzieloną infrastrukturą będą mieć do niej większe zaufanie, jeśli będą znały jej działanie na wylot; wybiorą też taką infrastrukturę, w której wszyscy maja symetryczne prawa a nie taką, w której jedna ze stron znajduje się w uprzywilejowanej pozycji jeśli chodzi o czerpanie zysków czy sprawowanie kontroli.

Niekoniecznie jednak trzeba się odwoływać do “efektu sieci” by zauważyć, że kwestia symetrii jest istotna dla użytkowników oprogramowania. Żaden racjonalnie myślący użytkownik oprogramowania nie zdecyduje się na dobrowolne zamknięcie w monopolu kontrolowanym przez jednego dostawcę i uzależnienie od zamkniętego źródła, jeśli dostępne jest jakiekolwiek alternatywne rozwiązanie o możliwej do zaakceptowania jakości. Argument ten zyskuje na sile w miarę jak rola oprogramowania w biznesie użytkownika rośnie: im jest ważniejsze, tym mniej prawdopodobne, że użytkownicy będą tolerować przejęcie nad nim kontroli przez kogoś innego.

Kolejna korzyść płynąca z użytkowania oprogramowania otwartego źródła to zabezpieczenie na przyszłość. Jeśli źródła są otwarte, użytkownik ma gdzie pójść jeśli producent upadnie. Jest to szczególnie istotne w przypadku “lukrowania ciasteczka”, ponieważ cykl życiowy sprzętu jest zazwyczaj dość krótki, jednak ogólny rezultat ma nieco szersze znaczenie i wpływa na wzrost wartości wszelkiego rodzaju oprogramowania otwartego źródła.

Jak ze sobą współpracują?

Kiedy przychód czerpany z utajnienia bitów przewyższa korzyści płynące z otwartego źródła, zamknięcie źródeł ma uzasadnienie ekonomiczne. Kiedy zysk płynący z otwartego źródła przewyższa zysk z zamkniętych bitów, otwarcie źródeł ma sens.

Powyższe stwierdzenie samo w sobie nie jest odkrywcze. Stanie się bardziej interesujące kiedy zauważymy, że o wiele trudniej zmierzyć i oszacować korzyści płynące z otwartego źródła niż dochód z ukrywania bitów; co więcej, o wiele częściej ludzie nie doceniają wspomnianych korzyści niż przeceniają je. Dopóki świat biznesu nie zaczął zastanawiać się nad swoim stanowiskiem w sprawie otwartego źródła po udostępnieniu źródeł Mozilli na początku 1998 roku, powszechnie żywiono błędną opinię, że korzyści płynące z otwartego źródła wynoszą zero.

Jak więc możemy je oszacować? Ogólnie rzecz biorąc jest to trudne pytanie, możemy jednak doń podejść jak do każdego innego problemu związanego z oszacowaniem jakiejś wartości. Przede wszystkim możemy zbadać przypadki, w których podejście otwartego źródła przyniosło danej firmie sukces lub porażkę. Możemy stworzyć model, który choć z grubsza wskazuje na sytuacje, w których otwarte źródło jest pewnym zwycięzcą, idealnym dla inwestora czy firmy próbującej osiągnąć jak największy zysk. Następnie możemy z powrotem przejść do badania danych i próbować uczynić nasz model bardziej precyzyjnym.

Z analizy przedstawionej w Katedrze i bazarze możemy wywnioskować, że zwrot z otwartego źródła jest największy w przypadkach, kiedy (a) największe znaczenie ma stabilność i skalowalność, oraz (b) nie da się łatwo zweryfikować poprawności projektu i implementacji inaczej niż przy pomocy weryfikacji przez społeczność programistów (w praktyce większość skomplikowanych programów spełnia drugie kryterium).

Racjonalnie myślący konsument, który nie chce zostać uwięziony w monopolu stworzonym przez jednego dostawcę, zainteresuje się otwartym źródłem (jak również metodami wykorzystania go jako narzędzia umożliwiającego mu zajęcie lepszej pozycji niż konkurencja) i zainteresowanie to będzie rosło w miarę jak oprogramowanie będzie stawało się ważniejsze dla konsumenta. Mamy więc następne kryterium: (c) otwarcie źródła opłaca się wtedy, kiedy oprogramowanie jest dobrem odgrywającym kluczową rolę w prowadzeniu biznesu (jak np. w departamentach informatyki w wielu przedsiębiorstwach).

Zaobserwowaliśmy wcześniej, że infrastruktura otwartego źródła jest odpowiedzialna za stworzenie zaufania i symetrii w sferze aplikacji, dzięki czemu po pewnym czasie przyciąga coraz więcej klientów i wygrywa z zamkniętą infrastrukturą; często lepszy jest niewielki, szybko rozwijajacy się rynek tego typu, niż rynek zamknięty i pogrążony w stagnacji. Dlatego w przypadku oprogramowania infrastrukturalnego, gra otwartego źródła zmierzająca do otwartości przyniesie na dłuższą metę większe korzyści niż gra zamkniętego źródła, zmierzająca do uzyskania przychodów z własności intelektualnej.

Silniejszym argumentem jest zdolność potencjalnych klientów do analizy konsekwencji strategii sprzedawców i ich niechęć do monopolu dostawców; kiedy jeszcze nie istnieje producent mający ogromna przewagę, można wybrać miedzy grą o równość a grą o dochód z zamkniętego źródła, nie można jednak wybrać obu (analogiczną zasadę można znaleźć gdzie indziej, np. w branży elektronicznej, gdzie klienci często odmawiają zakupu układów pochodzących z jednego źródła). Powyższe można sformułować mniej negatywnie: tam, gdzie dominuje “efekt sieci” (pozytywne, zewnętrzne aspekty mające związek z siecią), otwarte źródło będzie prawdopodobnie właściwym rozwiązaniem.

Możemy podsumować powyższe rozważania stwierdzeniem, że otwarte źródło generuje największe zyski wtedy, kiedy (d) jest wykorzystywane do tworzenia lub umożliwia stworzenie wspólnej infrastruktury informatyczno-komunikacyjnej.

Warto wreszcie zauważyć, że firmy dostarczające jedynych w swoim rodzaju lub bardzo zróżnicowanych usług, mogą bardziej obawiać się powielania swoich metod przez konkurencję niż firmy dostarczające usług opierających się na powszechnie znanych algorytmach i wiedzy. Dlatego też otwarte źródło ma większe szanse na zdobycie dominacji kiedy (e) kluczowe metody (lub ich odpowiedniki) są częścią wspólnej wiedzy technicznej.

Najważniejsze oprogramowanie internetowe, Apache, linuksowa implementacja uniksowego API według standardu ANSI: wszystko to są przykłady pięciu kryteriów przemawiających za wyborem otwartego źródła. Ścieżka ku otwartemu źródłu widoczna w ewolucji wspomnianych branż jest dobrze widoczna w trendach używanych protokołów sieciowych, zwracających się ponownie (w połowie lat dziewięćdziesiątych) w stronę TCP/IP, po piętnastu latach nieudanych prób budowania imperiów opartych na zamkniętych protokołach, takich jak DECNET, XNS, IPX i inne.

Z drugiej strony otwarte źródło przestaje mieć sens w przypadku firm, których jedynym atutem jest unikalna technologia informatyczna tworząca pewną wartość, która jest (a) stosunkowo odporna na błędy, może zostać (b) łatwo zweryfikowana inaczej niż przez weryfikację przez społeczność programistów, (c) nie ma kluczowego znaczenia dla biznesu, a (d) jej wartość nie wzrosłaby znacznie dzięki “efektowi sieci” czy powszechnemu zastosowaniu.

Mogę podać pewien skrajny przykład: na początku 1999 roku przedstawiciele pewnej firmy zapytali mnie, czy powinni przyjąć model otwartego źródła. Firma ta zajmowała się produkcją oprogramowania służącego do obliczania kształtów wycinanych przez piły mechaniczne, dzięki którym uzyskiwało się maksimum powierzchni desek z pni ściętych drzew. Moja odpowiedź brzmiała “nie”. Jedyne kryterium, które ostatecznie można by zastosować to (c), ale prawda jest taka, że nawet doświadczony operator piły może przygotować odpowiednie kształty jeśli zajdzie taka potrzeba.

Warto również wziąć pod uwagę istotny fakt: pozycja danego produktu w stosunku do wymienionych kryteriów może zmieniać się w czasie, jak to ujrzymy w omawianym dalej studium przypadku.

Reasumując: następujące okoliczności przemawiają za przyjęciem modelu otwartego źródła:

• Stabilność i skalowalność ma kluczowe znaczenie
• Prawidłowości projektu i implementacji nie da się łatwo zweryfikować innymi środkami niż weryfikacją przez środowisko programistów.
• Dzięki temu oprogramowaniu, użytkownik może kontrolować swój biznes.
• Oprogramowanie stwarza lub umożliwia zaistnienie wspólnej infrastruktury informatyczno-komunikacyjnej.
• Kluczowe metody (lub ich odpowiedniki) są częścią powszechnej wiedzy technicznej.

Studium przypadku: gra Doom

Historia Dooma, jednej z najlepiej sprzedających się gier firmy id software ukazuje, w jaki sposób nacisk rynku i ewolucja produktu mogą diametralnie zmienić o rząd wielkości korzyści płynące zarówno z zamknięcia, jak i otwarcia źródeł.

Kiedy udostępniono pierwszą wersję Dooma w 1993 roku, była to gra ze wszech miar unikalna ze względu na przeprowadzaną w czasie rzeczywistym animację ruchu gracza, uczestniczącego w grze w pierwszej osobie, co jest antytezą kryterium (e). Zastosowane techniki wizualne nie tylko robiły wielkie wrażenie (o wiele większe, niż płaska animacja poprzednika, Wolfenstein 3D), ale przez wiele miesięcy nikt nie potrafił wyjaśnić, w jaki sposób osiągnięto zamierzony efekt na używanych wtedy powolnych procesorach. Skrywane bity osiągnęły poważną wartość. Co więcej, potencjalny zwrot z otworzenia źródeł byłby niski. Jeśli w grę grała jedna osoba, (a) koszty zaistniałe w przypadku wystąpienia błędu były stosunkowo niskie, (b) weryfikacja nie nastręczała ogromnych trudności, (c) program nie miał kluczowego znaczenia dla żadnego konsumenta, zaś (D) “efekt sieci” nie miał dla niego żadnego znaczenia. Dlatego z ekonomicznego punktu widzenia zamknięcie źródeł Dooma było ekonomicznie uzasadnione.

Rynek jednak nie stoi w miejscu: konkurencja zaczęła rozwijać techniki animacji na wzór tych stosowanych w Doomie; zaczęły się pojawiać inne “strzelanki”, takie jak Duke Nukem. W miarę, jak wypełniały one niszę rynkową, którą zajmował Doom, przychód z ukrywanych bitów malał.

Z drugiej strony wysiłki zmierzające do poszerzenia rynku przyniosły ze sobą nowe wyzwania: większą stabilność, więcej funkcji w grach, więcej użytkowników i więcej obsługiwanych platform. Wraz z nadejściem gier “deathmatch”, w których udział mogło brać wielu graczy, oraz usług umożliwiających grę w Dooma przez sieć, rynek zaczął ukazywać pewną podatność na “efekt sieci”. Wszystko do wymagało od id software poświęcenia czasu programistów, które firma wolałaby przeznaczyć na tworzenie następnej gry.

Od czasu, kiedy udostępniono pierwszą wersję gry, id software pozytywnie zapatrywało się na publikację specyfikacji technicznej, która pomagała graczom tworzyć obiekty wykorzystywane w grze, a od czasu do czasu bezpośrednio współpracowało z hackerami odpowiadając na pytania czy publikując własne specyfikacje. Wspierali również inicjatywy mające na celu rozpowszechnianie nowych danych dla Dooma.

Trendy techniczne i rynkowe zwiększyły korzyści płynące z udostępnienia źródła gry; otwarcie specyfikacji i wspieranie dodatków wytwarzanych przez osoby trzecie zwiększało postrzeganą wartość gry i tworzyło nowy rynek, z którego mogło skorzystać id software. W pewnym momencie krzywe korzyści zbiegły się: w pewnej chwili przestawienie się na drugorzędny rynek (tworząc produkty takie jak antologie scenariuszów gier) i otwarcie źródła Dooma zaczęło być finansowo uzasadnione. I tak też się stało wkrótce potem: pełne źródła Dooma zostały udostępnione pod koniec 1997 roku.

Należy wiedzieć, kiedy podjąć decyzję

Przypadek Dooma jest bardzo interesujący, ponieważ gra ta nie jest ani systemem operacyjnym ani oprogramowaniem sieciowo-komunikacyjnym, dlatego istnieje duża przepaść między nią a zwykle podawanymi przykładami sukcesu oprogramowania otwartego źródła. Cykl życiowy Dooma, wraz z punktem przecięcia się krzywych wyznaczających korzyści płynące z przyjęcie wspomnianych modeli, jest prawdopodobnie typowym cyklem życiowym aplikacji we współczesnym ekosystemie informatycznym, w którym obliczenia rozproszone i oprogramowanie komunikacyjne tworzą poważne problemy związane z integralnością, stabilnością i skalowalnością, którym sprostać może jedynie weryfikacja przez społeczność programistów. Aplikacje te często również przekraczają granice dzielące terytoria techniczne i współzawodniczących ze sobą graczy (co pociąga za sobą omawiane już skutki związane z zaufaniem i symetrią).

Doom przeszedł ewolucję – od gry, w której gra się w pojedynkę, do gry typu “deathmatch”, w której może uczestniczyć wielu graczy. Coraz częściej “efekt sieciowy” wywołuje moc obliczeniowa. Podobne trendy przejawiają się nawet w sferze najpoważniejszych aplikacji biznesowych, takich jak systemy ERP (systemy zarządzania zasobami przedsiębiorstw). Stają się one coraz bardziej widoczne, w miarę jak sieć biznesowa coraz bardziej przeplata się z siecią dostawców i klientów, którzy, rzecz jasna, przenikają całą sieć World Wide Web. Wynika z tego, że niemal wszędzie rosną korzyści wynikające z przyjęcia modelu otwartego źródła.

Jeśli bieżące trendy zostaną utrzymane, głównym wyzwaniem technologii oprogramowania i zarządzania produktami w przyszłym stuleciu będzie znajomość momentu, w którym trzeba będzie podjąć decyzję – kiedy opłacalne stanie się przekazanie kodu infrastrukturze otwartego źródła, dzięki czemu zostanie zweryfikowany przez społeczność, zaś udostępniająca źródło firma uzyska większe zyski czerpane z usług i innych form biznesu.

Istnieją oczywiste powody ekonomiczne, dla których nie warto przegapić punktu przecięcia się wspomnianych krzywych. Poza tym zbyt długie oczekiwanie niesie ze sobą poważne ryzyko: może nas uprzedzić konkurencja, otwierająca produkt należący do tej samej niszy rynkowej.

Jest to poważny problem, ponieważ zarówno liczba użytkowników, jak i potencjalnych utalentowanych współpracowników w danej kategorii produktu jest ograniczona, zaś raz podjęte decyzje trudno zmienić. Jeśli dwóch producentów po kolei udostępnia kod produktów o mniej więcej tych samych funkcjach, pierwszy przyciągnie prawdopodobnie większość użytkowników i najbardziej zdeterminowanych programistów, drugi zaś będzie musiał zadowolić się resztkami. Raz podjęte decyzje trudno zmienić, ponieważ użytkownicy zaznajamiają się z produktami, a programiści inwestują swój czas w sam kod.

Otwarte źródło o strategiczne ryzyko finansowe

Okazuje się, że otwarte źródło wydaje się być modelem przeznaczonym do szerokiego wykorzystania nie ze względu na skuteczność producentów, lecz z powodu nacisków rynku i rosnącego popytu. Poprzednio zbadaliśmy skutki zapotrzebowania na stabilność i infrastrukturę pozbawioną dominującego gracza z punktu widzenia producenta; wiemy, jaką rolę odegrały w ewolucji sieci komputerowych. Należy jednak również wspomnieć o zachowaniu klientów rynku, na funkcjonowanie którego ma wpływ czynnik otwartego źródła.

Wyobraźmy sobie, ze jesteśmy dyrektorem działu IT jednej z korporacji Fortune 500 i planujemy stworzyć lub dokonać aktualizacji infrastruktury informatycznej w naszej firmie. Być może stoimy przed wyborem sieciowego systemu operacyjnego, który zostanie wykorzystany w całym przedsiębiorstwie; być może zależy nam raczej na dostępnych dwadzieścia cztery godziny na dobę usługach WWW i e-handlu; być może kluczową rolę w przedsiębiorstwie odgrywa obsługa ogromnych, bardzo stabilnych transakcyjnych baz danych.

Załóżmy, że zdecydujemy się na tradycyjną ścieżkę zamkniętego źródła. W ten sposób zdamy firmę na łaskę monopolu producenta, ponieważ z natury rzeczy istnieje tylko jedno źródło usług serwisowych, poprawek i ulepszeń produktu. Jeśli producent spisze się źle, trudno będzie znaleźć rozsądne wyjście, ponieważ będziemy ograniczeni poniesionymi kosztami inwestycyjnymi oraz kosztami szkoleń. Producent o tym wie. Czy – wziąwszy to pod uwagę – należy się spodziewać, że oprogramowanie zostanie zmodyfikowane tak, by zaspokoić nasze potrzeby i umożliwić realizację naszego planu biznesowego, czy… potrzeb i planu biznesowego producenta?

Prawda jest brutalna: kiedy kluczowe procesy biznesowe są wykonywane przez ukryte klocki bitów, których nawet nie można zobaczyć (a co dopiero zmodyfikować), kontrola nad firmą została utracona. W takiej sytuacji bardziej potrzebujemy producenta, niż producent nas, i dlatego będziemy płacić, płacić i jeszcze raz płacić za tę nierównowagę mocy. Będziemy płacić wyższymi cenami, będziemy płacić utraconymi możliwościami, będziemy płacić zamknięciem, które będzie się stawać coraz gorsze w miarę jak producent (który wyćwiczył tę taktykę na wielu poprzednich ofiarach) będzie zacieśniał swój uścisk.

Porównajmy tę sytuację z otwartym rozwiązaniem. Jeśli zdecydujemy się na otwarte źródło, będziemy dysponowali kodem źródłowym, którego nikt nam nie zabierze. Zamiast monopolu dostawcy zaciskającego nam pętlę na szyi, mamy do dyspozycji wiele konkurujących ze sobą firm usługowych gotowych pracować dla naszej firmy. Mało tego – jeśli stwierdzimy, że umowy serwisowe są zbyt drogie, możemy stworzyć własną komórkę zajmującą się usługami. Rynek pracuje dla nas.

Logika tej sytuacji jest zniewalająca: zamknięte źródło stanowi niemożliwe do przyjęcia strategiczne ryzyko biznesowe. Uważam, że niedługo zakup zamkniętego oprogramowania od jednego producenta mimo istnienia otwartego odpowiednika będzie postrzegany jako przejaw nieodpowiedzialności.

Ekologia biznesowa otwartego źródła

Społeczność otwartego źródła zorganizowała się w taki sposób, by wzmocnić skutki produktywności otwartego źródła. Widać to zwłaszcza w świecie linuksowym, gdzie duże znaczenie ekonomiczne ma fakt, że istnieje wielu konkurujących ze sobą dystrybutorów Linuksa, którzy stanowią odrębną warstwę, oddzieloną od programistów.

Programiści piszą kod i umieszczają go w Internecie. Każdy dystrybutor wybiera pewien podzbiór dostępnego kodu, łączy go z resztą dystrybucji, pakuje i oznacza swoją marką, po czym sprzedaje klientom. Użytkownicy wybierają spośród różnych dystrybucji; mogę też ominąć dystrybucję i pobrać kod bezpośrednio z witryny programisty.

Wskutek oddzielenia tych dwóch warstw, powstał bardzo elastyczny rynek faworyzujący ulepszenia. Programiści rywalizują ze sobą o uwagę dystrybutorów i użytkowników pracując nad jakością swoich programów. Dystrybutorzy rywalizują o dolary znajdujące się w kieszeni użytkownika, poprzez dobór odpowiednich elementów oraz dodanie wartości własnej.

Dzięki takiej wewnętrznej strukturze rynku, żaden jego element nie jest niezastąpiony. Programiści mogą tracić zainteresowanie; ale nawet jeśli ktoś inny bezpośrednio nie przejmie ich kodu, rywalizacja o uwagę spowoduje, że szybko pojawią się odpowiedniki oferujące podobne funkcje. Dystrybutorzy mogą zawieść bez szkody dla wspólnego, otwartego kodu. Cały ekosystem szybciej reaguje na potrzeby rynku, łatwiej znosi wstrząsy i regeneruje siły niż którykolwiek z monolitycznych producentów systemów operacyjnych.

Innym ważnym aspektem otwartego źródła są niższe koszty stałe i większa wydajność, którą można uzyskać dzięki specjalizacji. Programiści nie doświadczają nacisków, które zazwyczaj przyczyniają się do klęski zamkniętych projektów przekształcając je w pułapki: żadnych niepotrzebnych i rozpraszających funkcji, na implementację których naciska dział marketingu, żadnego przymusu ze strony kierownika zespołu, by używać przestarzałych języków programowania czy nieodpowiednich środowisk programistycznych, żadnego wyważania otwartych drzwi na inne, niekompatybilne sposoby w imię zróżnicowania produktów czy ochrony własności intelektualnej, a (co najważniejsze) – żadnych terminów. Nie trzeba na siłę wypychać wersji 1.0, zanim będzie rzeczywiście gotowa. De Marco i Lister, omawiając styl zarządzania zwany “obudź mnie, kiedy będzie po wszystkim” w Peopleware: Productive Projects and Teams {5} zauważyli, że prowadzi to nie tylko do podwyższenia jakości, ale i szybszego udostępnienia w pełni działającego produktu.

Dystrybutorzy z kolei specjalizują się w tym, co najlepiej wychodzi właśnie dystrybutorom. Ponieważ nie muszą finansować ciągłego rozwoju kosztownych projektów tylko po to, by nie wypaść z rynku, mogą skoncentrować się na integracji systemów, pakowaniu, nadzorem jakości i usługach.

Zarówno dystrybutorzy jak i programiści grają uczciwie: cały czas są nadzorowani przez użytkowników, którzy wyrażają swoje opinie; jest to integralna część modelu otwartego źródła.

Radzenie sobie z sukcesem

Trudno odnieść “Tragedię pastwisk” do współczesnego modelu rozwoju otwartego źródła, nie oznacza to jednak, że otwarte źródło nie może utracić swojego pędu. Czy najważniejsi gracze nie zaprzestaną współpracy, kiedy stawki staną się odpowiednio wysokie?

Powyższe pytanie można zadać na kilku poziomach. Podany przez nas argument wyrażony w “Komedii pastwisk” opiera się na założeniu, że trudno spieniężyć indywidualny udział programisty w projektach otwartego źródła. Jednakże argument ten trudniej odnieść do firm (dystrybutorów Linuksa), które uzyskują już przychód związany z otwartym źródłem – więc ich udział jest spieniężany każdego dnia. Jak bardzo stabilny jest obecny model, oparty na współpracy?

Analizując to pytanie możemy dojść do kilku interesujących wniosków dotyczących zarówno ekonomii oprogramowania otwartego źródła w realnym świecie w chwili obecnej, jak również wpływu paradygmatu sektora usług na rynek produkcji oprogramowania w przyszłości.

Jeśli zadamy to pytanie na poziomie praktycznym, odnosząc je do istniejącej obecnie społeczności otwartego źródła, prawdopodobnie przyjmie ono jedną z dwóch form. Pierwsza to “Czy Linux ulegnie fragmentacji?”, zaś druga – “Czy na rynku linuksowym powstanie dominujący gracz, quasi-monopolista?”.

Wielu ludzi sądzi, że Linux ulegnie fragmentacji, opierając się na wydarzeniach z przeszłości, spowodowanych postępowaniem producentów komercyjnych wersji Uniksa w latach osiemdziesiątych. Mimo niekończących się dywagacji na temat otwartych standardów, mimo wielu wspólnych uzgodnień, tworzenia konsorcjów i wspólnych przedsięwzięć, komercyjny Unix rozpadł się. Dążenie do zróżnicowania swoich produktów poprzez dodawanie i modyfikację funkcji systemu operacyjnego okazało się silniejsze od wspólnego interesu, jakim był rozwój globalnego rynku uniksowego poprzez zachowanie zgodności (a w konsekwencji zmniejszając zarówno bariery, które musieli pokonywać niezależni dostawcy oprogramowania, jak i całkowity koszt utrzymania dla końcowego odbiorcy.

Jest bardzo mało prawdopodobne, by tak samo stało się z Linuksem, a to z bardzo prostego powodu. Mianowicie wszyscy dystrybutorzy są zmuszeni do korzystania z tego samego zbioru kodów źródłowych, więc utrzymanie zróżnicowania nie jest tak naprawdę możliwe, ponieważ licencje, na których udostępniany jest kod Linuksa zobowiązują dystrybutorów, by dzielili się kodem ze wszystkimi. Jeśli jeden z dystrybutorów stworzy jakąś funkcję, wszyscy konkurenci mogą ja zaimplementować u siebie.

Ponieważ wszyscy zdają sobie z tego sprawę, nikt nawet nie myśli o wykonaniu posunięć, które doprowadziły do fragmentacji komercyjnego Uniksa. Dystrybutorzy Linuksa muszą więc konkurować używając metod, które przynoszą pożytek konsumentowi i całemu rynkowi. Muszą więc konkurować w sferze usług i obsługi technicznej, zaś ich powodzenie zależy od implementacji tych składników, które ułatwiają instalację i korzystanie z dystrybucji.

Wspólny kod źródłowy uniemożliwia również powstanie monopolu. Kiedy użytkownicy Linuksa zaczynają rozmawiać na ten temat, zazwyczaj pojawia się nazwa “Red Hat” – jest to największy dystrybutor, który odniósł największy sukces (udział Red Hata w amerykańskim rynku linuksowym szacuje się na około 90% [sytuacja uległa zmianie wraz z pojawieniem się nowego konkurenta, oferującego dystrybucję opartą w dużej mierze na Red Hacie: Linux Mandrake – przyp. Tłum.]). Warto jednak zauważyć, że w ciągu kilku dni od pojawienia się długo oczekiwanej, szóstej wersji Red Hata, zanim jeszcze zaczęto sprzedawać płyty CD-ROM z dystrybucją, można było zakupić CD z obrazami pobranymi z publicznego serwera FTP Red Hata od pewnego wydawcy książek i wielu innych dystrybutorów CD, i to po cenach niższych niż te, które przygotował Red Hat.

Red Hat nawet nie mrugnął okiem z tego powodu, ponieważ założyciele firmy doskonale rozumieją, że nie są i nie mogą być właścicielami bitów zawartych w ich produkcie – zabraniają tego normy społeczne panujące w społeczności linuksowej. W odpowiedzi na słynną uwagę Johna Gilmora (“Internet uznaje cenzurę za przeszkodę i omija ją”) słusznie zauważono, że społeczność hackerska odpowiedzialna za Linuksa uznaje wszelkie próby zdobycia kontroli za przeszkodę i omija je. Gdyby Red Hat sprzeciwił się wczesnemu powielaniu swojego najnowszego produktu, byłoby mu później bardzo trudno nakłonić do współpracy społeczność programistów.

Obecnie jednak większe znaczenie ma fakt, że licencje na oprogramowanie, wyrażające normy istniejące w społeczności w sposób prawnie zobowiązujący do ich przestrzegania, nie pozwolą Red Hatowi zmonopolizować kodu źródłowego, na którym opiera się Red Hat Linux. Firma może sprzedać jedynie markę, usługi i umowy serwisowe; może je sprzedać tylko tym, którzy chcą za nie zapłacić. Nie jest to raczej sytuacja, w której mogłaby się narodzić bestia krwiożerczego monopolu.

Otwarte badania naukowe i ponowne odkrycie mecenatu

Istnieje jeszcze inny aspekt zmian zachodzących w świecie otwartego źródła w miarę przypływu realnego pieniądza: gwiazdy społeczności odkrywają, że mogą otrzymywać pieniądze za wykonywanie tego, co lubią robić, dzięki czemu otwarte źródło przestaje być hobby uprawianym w wolnych chwilach i finansowanym przez inną pracę. Korporacje takie jak Red Hat, O’Reilly & Associates czy VA Linux Systems budują coś, co można nazwać na wpół niezależnym departamentem badawczym, zatrudniając i utrzymując talenty świata otwartego źródła.

Tego typu przedsięwzięcie ma uzasadnienie ekonomiczne jedynie w sytuacji, kiedy koszt utrzymania tego typy laboratorium można łatwo pokryć z przychodów, które firma spodziewa się otrzymać stymulując rozwój danego rynku. Firmę O’Reilly stać na utrzymywanie liderów Perla i Apache, ponieważ dzięki temu spodziewa się ona sprzedać więcej książek związanych z Perlem i Apache, jak również zwiększyć ilość osób uczestniczących w organizowanych przez nią konferencjach. VA Linux stać na utrzymywanie swojego laboratorium, ponieważ ulepszanie Linuksa zwiększa wartość sprzedawanych stacji roboczych i serwerów. Red Hat zaś finansuje Red Hat Advanced Development Labs aby podwyższyć wartość swojej oferty związanej z Linuksem i przyciągnąć więcej klientów.

Trudno wytłumaczyć takie zachowanie strategom pracującym w bardziej tradycyjnych sektorach biznesu informatycznego – osobom wychowanym w kulturze, która za swój klejnot koronny uważa własność intelektualną, chronioną patentami i tajemnicami handlowymi (mimo, że zachowanie to prowadzi do rozwoju rynku). Jak można finansować badania, które z definicji może sobie przywłaszczyć każdy konkurent, nie ponosząc przy tym żadnych kosztów?

Wydaje się, że istnieją ku temu dwa decydujące powody. Po pierwsze, będąc głównymi graczami w swoich segmentach rynku, firmy te mają nadzieję otrzymać lwią część przychodów uzyskanych dzięki otwartym badaniom. Wykorzystanie badań w celu uzyskania dochodów w przyszłości nie jest nowym pomysłem – interesująca jest natomiast kalkulacja zysków, która zakłada na tyle duży przychód, by – chcąc uzyskać korzyści wynikające z weryfikacji kodu przez społeczność – tolerować “gapowiczów”.

Chociaż analiza szacowanej stopy zwrotu jest czymś niezbędnym w świecie kapitalistów-wyjadaczy obserwujących ROI, trudno wyjaśnić nią zatrudnianie gwiazd, ponieważ w przypadku firm sponsorujących otwarte badania kwestia ta jest nieco rozmyta. Ich przedstawiciele stwierdzą po prostu, że robią to co należy zgodnie z duchem społeczności, z której pochodzą. Autor tej książki jest na tyle zaznajomiony z zasadami wyznawanymi przez wymienione wyżej trzy firmy by móc stwierdzić, że jest to czcza mowa. Pod koniec 1998 roku poproszono mnie, bym został członkiem zarządu VA Linux Systems, by móc doradzić firmie “co jest właściwe”; nieprawdą byłoby stwierdzić, że mnie nie słuchano, kiedy wyrażałem swoje opinie.

O oczekiwanym zysku powinien się wypowiedzieć ekonomista. Jeśli zaakceptujemy fakt, że rozprawianie o wykonywaniu “tego, co właściwe” nie jest pustą pozą, powinniśmy zastanowić się, jaki interes mają te firmy w wykonywaniu “tego, co jest właściwe”. Odpowiedź nie jest ani zaskakująca, ani – jeśli zada się odpowiednie pytania – trudna do weryfikacji. Podobnie jak to ma miejsce w przypadku pozornie altruistycznego zachowania, na które można się natknąć w innych gałęziach przemysłu, firmy te wierzą, że kupują dobrą wolę.

Praca mająca na celu wytworzenie dobrej woli, którą uważa się za atut decydujący o przyszłych zyskach, również nie jest niczym nowym. Na uwagę zasługuje natomiast bardzo wysoka wartość, którą – jak możemy ocenić po ich zachowaniu – firmy te przypisują dobrej woli. Ich przedstawiciele – nawet w okresie dużego zapotrzebowania na kapitał – otwarcie wykazują chęć utrzymywania utalentowanych i drogich specjalistów, którzy pracują nad projektami nie przynoszącymi bezpośredniego zysku. Zaś rynek, przynajmniej do tej pory, dobrze wynagradza firmy postępujące w ten sposób.

Przedstawiciele tych firm nie kryją powodów, dla których dobra wola ma dla nich szczególną wartość. Otóż lwią część ich klientów, zarówno jesli chodzi o rozwój produktów jak i nieformalne struktury marketingowe, stanowią ochotnicy. Związek z klientami jest bardzo bliski, często opiera się na osobistym zaufaniu, którym darzą się osoby pracujące w firmie i poza nią. Nie tylko korzystają z pracy kultury hackerskiej, ale się z nią identyfikują.

Fakty te jeszcze mocniej podkreślają postawioną wcześniej tezę, do której doszliśmy stosując inną argumentację: bliski związek między Red Hatem, VA czy O’Reilly a ich klientami i programistami nie jest związkiem typowym dla firmy wytwarzającej produkty, uwydatnia natomiast pewne interesujące wzorce, właściwe wysoko wyspecjalizowanym i wymagającym dużej wiedzy rynkom usług. Podobne wzorce można też znaleźć (m.in.) w kancelariach adwokackich, na uniwersytetach i wśród lekarzy.

Zauważmy, że firmy otwartego źródła zatrudniają największych hackerów z tych samych powodów, dla których uniwersytety zatrudniają sławy świata nauki. W obu przypadkach zarówno mechanizm funkcjonowania jak i rezultat przypomina system arystokratycznego mecenatu, który aż do Rewolucji Przemysłowej finansował powstawanie większości dzieł sztuki. Niektórzy zainteresowani są tego w pełni świadomi.

Jak tam dotrzeć?

Mechanizmy rynkowe pozwalające finansować (i zarabiać!) na modelu otwartego źródła wciąż ewoluują w szybkim tempie. Modele biznesowe, które przedstawiliśmy w tym eseju, z pewnością nie są ostatnimi. Inwestorzy wciąż zastanawiają się nad konsekwencjami przebudowania rynku oprogramowania w taki sposób, by skupiał się wokół usług a nie zamkniętej własności intelektualnej, co w pewnej chwili niechybnie nastąpi.

Rewolucja w koncepcjach dotyczących rynku oprogramowania odbije się na zysku tych, którzy inwestują w 5-procentowy segment rynku zajmujący się produkcją programów w pudełkach; patrząc z historycznego punktu widzenia usługi nie przynoszą takich dochodów, jak produkcja (choć każdy doktor czy prawnik powie, że stopy zwrotu dla osób wykonujących te zawody są często wyższe). Jednak utrata zysku zostanie zrekompensowana ogromnymi oszczędnościami i wydajnością produktów otwartego źródła (można doszukać się pewnej analogii w komunikacji przez Internet, która masowo zastępuje komunikację przy użyciu tradycyjnych linii telefonicznych).

Przedsiębiorcy i inwestorzy powoli zaczynają korzystać z okazji, którą stwarzają wspomniane oszczędności i wydajność. Kiedy przygotowywano pierwszą wersję tego dokumentu, inwestorem strategicznym powstającej firmy, mającej zajmować się świadczeniem usług związanych z obsługą techniczną systemów linuksowych (Linuxcare), była najbardziej prestiżowa firma typu venture capital w Krzemowej Dolinie. Giełdowy debiut Red Hata w 1999 roku był niezwykle udany (mimo spadku akcji spółek internetowych i high-tech). Powszechnie uważa się, że do końca 1999 roku nia giełdę wejdzie wiele innych firm związanych z Linuksem i otwartym źródłem, którym również się powiedzie.

Inną ciekawa tendencją są próby stworzenia usystematyzowanego rynku zadań, wykonywanych w ramach projektów otwartego źródła. SourceXchange (http://www.sourcexchange.com/process.html) i CoSource (http://www.cosource.com) reprezentują dwa nieco odmienne podejścia, polegające na przystosowaniu modelu odwrotnych aukcji do rynku projektów otwartego źródła [CoSource została niedawno zamknięta – przyp. tłum.].

Ogólne trendy nie pozostawiają miejsca na wątpliwości. Wspomniany wcześniej raport IDC przewiduje, że do 2003 Linux będzie rozwijał się szybciej, niż wszystkie pozostałe systemy operacyjne razem. Apache ma 61-procentowy udział w rynku, który stale się zwiększa. Internet przeżywa eksplozję popularności, zaś prowadzone badania popularności systemów operacyjnych, takie jak Internet Operating System Counter (licznik systemów operacyjnych w Internecie) ukazują, że Linux i inne otwarte systemy operacyjne maja przewagę nad jakimkolwiek innym systemem operacyjnym, a ich popularność stale rośnie. Potrzeba eksploatacji otwartej infrastruktury Internetu ma coraz większy wpływ nie tylko na projektowanie innego oprogramowania, lecz również na praktyki biznesowe, jak i modele użytkowania i zakupu oprogramowania w każdej istniejącej korporacji. Trendy te wykazują tendencję zwyżkową.

Konkluzja: życie po rewolucji

Jak będzie wyglądał świat oprogramowania, kiedy zakończy się okres adaptacji modelu otwartego źródła?

Niektórzy programiści martwią się, że w rezultacie tego procesu stracą pracę, a ich zawód straci na wartości. Standardowy scenariusz, jaki się prezentuje, to koszmar zwany “Apokalipsą otwartego źródła”. Zaczyna się od tego, że wartość rynkowa oprogramowania spada do zera z powodu obfitości darmowego kodu (wartość użytkowa nie przyciąga wystarczająco wielu klientów, by tworzenie oprogramowania było opłacalne). Firmy produkujące komercyjne oprogramowanie upadają. Programiści głodują lub przekwalifikowują się. Sądny dzień następuje w chwili, kiedy upada sama kultura otwartego źródła (która zależy od wolnego czasu profesjonalistów). Po pewnym czasie nie ma żadnych kompetentnych programistów… Co za nieszczęście!

Podaliśmy już wystarczająco dużo powodów, dla których nic takiego się nie wydarzy – począwszy od tego, że zarobki większości programistów nie zależą od wartości rynkowej programu. Jednak najważniejszy argument brzmi następująco: kiedy ostatni raz widzieliśmy firmę programistyczną, która nie miała zbyt wiele pracy do wykonania? W szybko zmieniającym się świecie, w którym gospodarka staje się coraz bardziej złożona i ukierunkowana na informację, zawsze będzie wiele pracy i zdrowe zapotrzebowanie na ludzi, którzy potrafią sprawić, by komputery wykonywały różne rzeczy – bez względu na to, ile poświęcą na to czasu i ile swoich sekretów ujawnią w trakcie pracy.

Jeśli chcemy przeanalizować sam rynek oprogramowania, warto posortować grupy programów według stopnia kompletności w stosunku do otwartych standardów technicznych, co ma ścisły związek z użytecznością funkcji oferowanych przez dany program.

Możemy oczekiwać, że przyszłość każdej technologii programistycznej posiadającej konkurencję w postaci odpowiednika otwartego źródła sprowadza się do dwóch możliwości: albo zostanie wyeliminowana, albo stanie się częścią otwartej infrastruktury. I choć nie jest to zbyt wesoła wiadomość dla przedsiębiorców, którzy chcieliby w nieskończoność czerpać zysk z ukrytych bitów, mimo to przemysł informatyczny nadal będzie oferował przedsiębiorcom korzystne możliwości czerpania zysku, wraz z otwarciem się nowych niszy w górnej części rynku (aplikacje) oraz skróceniem długości życia monopoli opierających się na zamkniętej własności intelektualnej, których produkty przestaną być atrakcyjne.

Powstała w ten sposób równowaga będzie korzystna dla konsumenta oprogramowania, który jest główną siłą napędzającą proces przemian. Będzie można stale korzystać z coraz większej ilości wysokiej jakości oprogramowania, którego będzie można używać i rozwijać je, bez konieczności polegania na programach, których linia produkcyjna może zostać w każdej chwili zakończona i które są zamknięte w czyjejś krypcie. Metafora magicznego kotła Ceridwen okazała się zbyt słaba, ponieważ pożywienie jest czymś, co się je i co ulega zepsuciu, zaś źródła programów mogą trwać wiecznie. Wolny rynek, w najbardziej liberalnym znaczeniu, zawierającym wszelką niewymuszoną działalność – czy to handel, czy rozdawanie prezentów – może być dla wszystkich źródłem stale rosnącego bogactwa oprogramowania.

Bibliografia.

Rewizja – 1.1 – 20 Maj 1999 – Ogólny zarys.
Rewizja – 1.2 – 18 Czerwiec 1999 – Pierwsza wersja prywatna.
Rewizja – 1.3 – 23 Czerwiec 1999 – Pierwsza wersja publiczna.
Rewizja – 1.5 – 24 Czerwiec 1999 – Główne uaktualnienia. Główny punkt definicji “hackera”.
Rewizja – 1.7 – 24 Czerwiec 1999 – Główne uaktualnienia. Analizy opłacalności.
Rewizja – 1.9 – 24 Czerwiec 1999 – Nowy materiał na temat darmowej przyszłości.
Rewizja – 1.10 – 24 Czerwiec 1999 – Lepsza nazwa dla modelu ‘Razor Blades’.
Rewizja – 1.13 – 25 Czerwiec 1999 – Korekta 13% materiału o Netscape.
Rewizja – 1.14 – 25 Czerwiec 1999 – Dodanie firmy e-smith, inc.
Rewizja – 1.15 – 9 Lipiec 1999 – Nowy rozdział o sterownikach sprzętowych.
Rewizja – 1.16 – 8 Sierpień 1999 – Nowa sekcja – “Future-Proofing, Market Pressures, and Strategic Business Risk”.
Rewizja – 1.17 – 22 Wrzesień 1999 – Pierwsza wersja drukowana.
Rewizja – 1.18 – 25 Sierpień 2000 – Wersja przekonwertowana na format książkowy. Uaktualnienia z lata 2000.
Rewizja – 1.19 – 25 Sierpień 2000 – Dodany link to Kipling’a “The Mary Gloster”.

Więcej informacji: Linux Community, Magic Cauldron