Open Source Software

Szkoła Główna Handlowa w Warszawie
Studium Dyplomowe
Praca magisterska
na kierunku EKONOMIA
Grzegorz Andruszkiewicz
Nr albumu: 19939
Analiza mikroekonomiczna
oprogramowania o otwartym źródle – rola
przedsi˛ebiorstw w jego rozwoju
Praca wykonana pod kierunkiem
prof. Aleksandera Sulejewicza
katedra Ekonomii II
Warszawa 2004
Prac˛e przedkładam do oceny
Data
Podpis autora pracy:
Praca jest gotowa do oceny przez recenzenta
Data
Podpis kierujacego
˛
praca:
˛
Spis treści
Wst˛ep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1. Oprogramowanie o otwartym źródle . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.1. Licencje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2. Tworzenie oprogramowania o otwartym źródle . . . . . . . . . . . . . . . . . . 23
1.2.1. Motywacja programistów . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.2.2. Motywacja firm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.2.3. Proces powstawania . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.2.4. Niezawodność . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
1.3. Rola przedsi˛ebiorstw i rzadu
˛ w tworzeniu wolnego oprogramowania . . . . . . . 47
2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.1. Funkcja produkcji firm komercyjnych . . . . . . . . . . . . . . . . . . . . . . . 51
2.2. Funkcja produkcji ruchu wolnego oprogramowania . . . . . . . . . . . . . . . . 52
2.3. Funkcja użyteczności użytkownika oprogramownia . . . . . . . . . . . . . . . . 54
2.4. Producent oprogramowania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.5. Powstawanie oprogramowania o otwartym źródle . . . . . . . . . . . . . . . . . 57
2.6. Porównanie oprogramowania komercyjnego z oprogramowaniem o otwartym
źródle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.7. Wnioski z modelu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3. Wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3
Wst˛ep
W ostatnich latach na rynku oprogramowania komputerowego zauważamy nowa˛ tendencj˛e –
pojawiło si˛e tzw. oprogramowanie o otwartym źródle (ang. open source software, skr. OSS),
czyli oprogramowanie, którego każdy ma prawo używać bez konieczności zakupu licencji1 i
które każdy ma prawo poprawiać, ponieważ kod źródłowy2 jest publicznie dost˛epny. Fenomenem ostatnich kilku lat jest fakt, że oprogramowanie to jest coraz lepsze i coraz bardziej rozpowszechnione. Najlepszym przykładem jest serwer WWW3 Apache, który można ściagn
˛ ać
˛
za darmo ze strony http://www.apache.org, a jednocześnie ma (luty 2004) ponad 69%
udziału w rynku4 .
Poza Apache’m istnieje wiele innych bardzo zaawansowanych technicznie projektów, konkurencyjnych do rozwiazań
˛
komercyjnych,5 jak chociażby system operacyjny GNU/Linux6 , prze-
1
Licencja jest rodzajem ograniczonego prawa do korzystania z dobra intelektualnego. Oprogramowanie o otwar-
tym źródle także jest obj˛ete licencjami, ale licencje te istotnie różnia˛ si˛e od licencji komercyjnych, gdyż staraja˛ si˛e
zagwarantować każdemu prawo do korzystania z oprogramowania, a nie je ograniczyć. Problemy licencji zostana˛
dokładniej omówione w rozdziale 1.1
2
Kodem źródłowym nazywamy tekst programu bezpośrednio tworzony przez programistów. Programy, które
uruchamiamy na komputerze sa˛ w postaci tzw. kodu wykonywalnego, który istotnie różni si˛e od kodu źródłowego
– jest praktycznie nieczytelny dla człowieka. Posiadajac
˛ kod źródłowy możemy łatwo otrzymać kod wykonywalny
poprzez kompilacj˛e (proces zautomatyzowany). Proces ten jest jednakże praktycznie nieodwracalny – istnieja˛ tzw.
dekompilatory, lecz nie potrafia˛ one wiernie odtworzyć kodu źródłowego, w szczególności nie da si˛e odzyskać
komentarzy programistów, cz˛esto niezb˛ednych do zrozumienia sposobu działania programu. Można wi˛ec przyjać,
˛
że posiadajac
˛ tylko kod wykonywalny programu, nie da si˛e w programie nic poprawić.
3
Serwer WWW to program umożliwiajacy
˛ udost˛epnienie innym użytkownikom sieci naszej strony internetowej.
4
Netcraft, Web Server Survey.
5
Analiza˛ poziomu zaawansowania i konkurencyjnościa˛ oprogramowania o otwartym źródle zajm˛e si˛e w rozdziale 1.2.4
6
http://www.linux.org
5
gladarka
˛
internetowa Mozilla 7 , pakiet biurowy Open Office8 , kompilator gcc9 , debugger gdb10 ,
system zarzadzania
˛
baza˛ danych MySQL11 , itd.
Narzucajacym
˛
si˛e pytaniem jest jak to si˛e dzieje, że takie oprogramowanie powstaje? Stworzenie tak zaawansowanych programów wymaga niesłychanie dużego nakładu pracy wysoko
wykwalifikowanych programistów, którzy rozdaja˛ swoje produkty za darmo. Poza tym obserwujemy czynny udział firm w rozwijaniu oprogramowania o otwartym źródle. Na „pierwszy
rzut oka” wydaje si˛e, że ten fenomen przeczy zasadom ekonomii klasycznej, gdyż dlaczego ludzie i firmy mieliby rozdawać owoce swojej pracy, zamiast czerpać zyski z ich sprzedaży?
W niniejszej pracy chciałbym przedstawić analiz˛e tego paradoksu. Najpierw, w rozdziale
1 zdefiniuj˛e dokładnie oprogramowanie o otwartym źródle i dokonam przegladu
˛ licencji, na
których to oprogramowanie jest wypuszczane. Licencje zostana˛ przeanalizowane pod katem
˛
możliwości wykorzystania obj˛etego nimi oprogramowania do celów komercyjnych. Nast˛epnie
postaram si˛e wytłumaczyć fenomen, że wielu programistów tworzy, a nast˛epnie dobrowolnie
i nieodpłatnie udost˛epnia innym swoje poprawki do istniejacych
˛
programów, czy wypuszcza
nowe programy na licencjach oprogramowania o otwartym źródle. Pokaż˛e różne motywacje
programistów: poczawszy
˛
od rozwijania oprogramowania dla własnej korzyści, poprzez zagadnienia dotyczace
˛ ekonomii kariery, a na aspektach kulturowo-psychologicznych skończywszy.
Na koniec przedstawi˛e także analiz˛e porównawcza˛ oprogramowania o otwartym źródle i oprogramowania komercyjnego pod wzgl˛edem użyteczności dla użytkowników (pokaż˛e że oprogramowanie o otwartym źródle cz˛esto zawiera mniej bł˛edów, nowo-zgłoszone bł˛edy sa˛ poprawiane
szybciej, a oprogramowanie to lepiej pasuje do potrzeb niektórych użytkowników) oraz samego
procesu powstawania (tworzenia) oprogramowania (przeanalizuj˛e efektywność obu procesów,
stopień dostosowania produktu do potrzeb użytkowników i możliwość kontrolowania tworzenia
oprogramowania – pokaż˛e mi˛edzy innymi, że nie każda forma wspierania oprogramowania o
otwartym źródle przyspiesza jego rozwój).
W rozdziale 2 przedstawi˛e model powstawania oprogramowania o otwartym źródle na rynku,
przeanalizuj˛e proces powstawania wolnego oprogramowania oraz jego konkurencyjności z produktem firmy komercyjnej. Zauważamy ostatnio, że w rozwój oprogramowania o otwartym
źródle angażuje si˛e coraz wi˛ecej komercyjnych firm, zarówno nowo powstałych, zajmujacych
˛
7
http://www.mozilla.org
http://www.openoffice.org
9
http://gcc.gnu.org
10
http://www.gnu.org/software/gdb/gdb.html
11
http://www.mysql.com
8
6
si˛e tylko tym oprogramowaniem, jak i wielkich światowych gigantów. Na przykład firma Red
Hat Software12 , powstała w 1995 roku, zajmuje si˛e dostarczaniem firmom rozwiazań
˛
softwarowych opartych na Linuksie i oprogarmowaniu o otwartym źródle. Dystrybucja Linuksa Red
Hat13 jest jedna˛ z najbardziej znanych i rozpowszechnionych. Red Hat zajmuje si˛e sprzedaża˛ pudełkowych wersji swojej dystrybucji, można ja˛ jednak ściagn
˛ ać
˛ za darmo ze strony internetowej,
cz˛esto nawet wcześniej niż dotrze do sklepów. Firma zarabia głównie na wsparciu technicznym,
konsultingu, indywidualne usługi informatyczne czy szkolenie techników (wprowadzono kursy
na stopnie: Red Hat Certified Engineer i Red Hat Certified Technician) i inne. Red Hat jest notowana na NASDAQ (RHAT) – dnia 14.03.2004 miała wartość $ 3,158,185,200. Red Hat aktywnie
inwestuje w rozwój wolnego oprogramowania, chociaż konkurenci moga˛ korzystać z jej pracy
bez żadnych ograniczeń. Z drugiej strony IBM, tradycyjny gigant na rynku, także poświ˛eca
ogromne środki na rozwój oprogramowania o otwartym źródle, w tym np. na dostosowanie
Linuksa do własnych platform sprz˛etowych.
Firmy te ponosza˛ koszty na wspieranie projektów OSS, udost˛epniaja˛ publicznie owoce swojej
pracy, a nie maja˛ możliwości czerpania z tego żadnych bezpośrednich zysków (z powodu licencji). Sytuacja z przedsi˛ebiorstwami jest o tyle ciekawsza od motywacji programistów, że przedsi˛ebiorstwa sa˛ nastawione tylko na zysk (zgodnie z ekonomia˛ klasyczna),
˛ nie wyst˛epuja˛ tutaj
aspekty kulturowe, psychologiczne, etc. Co wi˛ecej, cz˛esto sie zdarza, że różne przedsi˛ebiorstwa
rozwijajace
˛ to samo oprogramowanie o otwartym źródle sa˛ bezpośrednimi konkurentami, co raczej nie zachodziło w przypadku programistów. Analizujac
˛ model postaram si˛e wyciagn
˛ ać
˛ kilka
wniosków o możliwości wpływu tych firm na sam proces rozwoju oprogramowania o otwartym
źródle.
12
13
http://www.redhat.com
Dystrybucja jest to jadro
˛
Linuksa razem ze zbiorem narz˛edzi i programów użytkowych. Dystrybucje posia-
daja˛ własny instalator, czyli program uruchamiajacy
˛ (przegrywajacy
˛ na dysk, tworzacy
˛ odp. struktur˛e katalogów,
zakładajacy
˛ pliki konfiguracyjne, etc) wszystkie programy na komputerze użytkownika.
7
Rozdział 1
Oprogramowanie o otwartym źródle
Na poczatku
˛ istnienia komputerów oprogramowanie powstawało głównie albo w ośrodkach akademickich (jak Berkeley czy MIT), albo w centralnych korporacyjnych laboratoriach badawczych, gdzie naukowcy także mieli duża˛ autonomi˛e (np. Bell Labs i centrum badawcze firmy
Xerox w Palo Alto). Nikt nie starał si˛e zarobić na samym oprogramowaniu, w zwiazku
˛
z czym
źródła były otwarte, a ludzie wymieniali si˛e nowymi wersjami i ew. swoimi poprawkami. W latach 70-tych korporacje włożyły wiele wysiłku w prób˛e stworzenia systemu operacyjnego, który
mógłby działać na wielu platformach sprz˛etowych. Najbardziej udane „wynalazki” tego okresu
to j˛ezyk C i system UNIX, stworzone poczatkowo
˛
w laboratoriach AT&T – Bell Labs. Oprogramowanie to było jednak przekazywane (za darmo lub za minimalna˛ opłata)
˛ innym instytucjom,
które wprowadzały kolejne poprawki i innowacje, czym dzieliły si˛e z pozostałymi użytkownikami. Proces „dzielenia si˛e” kodem był ułatwiony, gdy w 1979 powstała sieć Usenet, łacz
˛ aca
˛
społeczność programistów uniksowych. Wraz z rozwojem tej sieci, możliwości wymiany technologii przez poszczególne uniwersytety i laboratoria gwałtownie rosły.1
Jednak w latach 80-tych firma AT&T zacz˛eła rościć sobie prawa własności intelektualnej do
Unixa (opisany powyżej proces był nieformalny i formalne prawa własnościowe nie były ustalone)2 , inne instytucje zacz˛eły post˛epować podobnie. Mi˛edzy innymi MIT sprzedała firmie komercyjnej licencj˛e na oprogramowanie wytworzone w laboratoriach . Firma ta natychmiast ograniczyła dost˛ep do kodu źródłowego tego oprogramowania, przez co osoby niezatrudnione, w tym
twórcy oprogramowania (naukowcy z MIT), przestali mieć możliwość korzystania, nauczania i
dalszego rozwijania projektów. W odpowiedzi Richard Stallman z MIT Artificial Intelligence
1
2
Lerner i Tirole, The Simple Economics of Open Source.
Ibid.
9
Laboratory założył w 1985 roku organizacj˛e Free Software Foundation3 , która za cel postawiła
sobie stworzenie i rozprowadzenie szerokiego wachlarza darmowego oprogramowania z ogólnie
dost˛epnym źródłem – w pełni funkcjonalnego systemu operacyjnego złożonego tylko z darmowego (wolnego) oprogramowania. Projekt ten nazywa si˛e GNU4 . Bardziej dziś znane aplikacje
to kompilator gcc, debugger gdb, edytor Emacs, graficzny interfejs użytkownika GNOME i wiele
innych. Stallman był osobiście dotkni˛ety zdarzeniem w MIT, uważał także, że nowa światowa
tendencja do produkcji i sprzedaży oprogramowania w postaci kodu wykonywalnego, którego
nie można było modyfikować ani uczyć si˛e na jego podstawie, jest „moralnie zła”.5 Stworzył
ide˛e i definicj˛e wolnego oprogramowania (ang. Free Software) – jest to oprogramowanie, które
daje użytkownikowi cztery „wolności”: (1) Wolność do używania programu do jakiegokolwiek
zastosowania, (2) Wolność do analizowania działania programu i dostosowania go do swoich potrzeb, (3) Wolność do rozprowadzania programu, (4) Wolność do poprawiania, modyfikowania
i wypuszczania swoich wersji. Stallman podkreśla, że aby oprogramowanie było wolne w jego
rozumieniu, kod źródłowy musi być ogólnie dost˛epny. Jest to niezb˛edny warunek do spełnienia
punktów (2) i (4). Stallman (w ramach działalności Free Software Foundation), żeby zapobiec
ewentualnym sporom o prawa autorskie wolnego oprogramowania (projektu GNU), postanowił
umiejscowić to oprogramowanie w istniejacych
˛
standardach prawnych. Została stworzona specjalna licencja GNU GPL (General Public License), która gwarantowała, że obj˛ete nia˛ oprogramowanie pozostanie wolnym oprogramowaniem (w sensie zdefiniowanym powyżej). Stallman
stworzył termin „Copyleft” (pozostawienie do kopiowania), jako przeciwieństwo „copyright”
(prawa autorskie, dokł. prawo do kopiowania).6 Normalnie każdy autor dobra intelektualnego
ma właśnie „copyright”, co oznacza że tylko on ma prawo do kopiowania i rozprowadzania swojego dzieła, zaś pozostali ludzie sa˛ tego prawa pozbawieni. Wolne oprogramowanie obj˛ete jest
„copyleft”, czyli jest pozostawione do kopiowania, każdy ma prawo dowolnie rozprowadzać te
programy. Analogicznie jak „copyright”, dobra pochodne7 także obj˛ete sa˛ „copyleft”. Ta˛ cech˛e
licencji GPL b˛edziemy nazywać żywotnościa.˛ Żywotność nie jest niezb˛edna˛ cecha˛ licencji wolnego oprogramowania.8 Dokładniej analiza˛ różnych żywotnych i nieżywotnych licencji wolnego
3
http://www.gnu.org
Od “GNU’s Not Unix”.
5
von Hippel i von Krogh, Open Source Software and the “Private-Collective” Innovation Model. . . .
6
Stallman, The Free Software Definition.
7
Dobrem (programem) pochodnym innego dobra (programu) – pierwotnego – b˛edziemy nazywać coś, co po4
wstało na bazie dobra (programu) pierwotnego – jako jego modyfikacja, rozbudowa, lub nawet gdy wykorzystano
tylko elementy dobra (programu) pierwotnego.
8
Stallman, Categories of Free and Non-Free Software.
10
oprogramowania zajmiemy si˛e w rozdziale 1.1.
W latach 90-tych nastapił
˛ dynamiczny rozwój różnych projektów b˛edacych
˛
wolnym oprogramowaniem. W 1991 roku Linus Torvalds stworzył Linuksa9 , czyli jadro
˛ „wolnego” uniksowego
systemu operacyjnego. Razem z narz˛edziami i aplikacjami GNU powstał darmowy system operacyjny GNU/Linux, bardzo popularny w kr˛egach akademickich i zdobywajacy
˛ coraz wi˛ekszy
udział w rynku serwerowych systemów operacyjnych. Zacz˛eło powstawać wiele nowych projektów, ich rozwój był ułatwiony dynamicznym rozwojem Internetu - rosła pula potencjalnych
programistów, chcacych
˛
wziać
˛ udział w rozwoju oprogramowania o otwartym źródle. Poza tym
drastycznie zmniejszyły sie koszty komunikacji. Zacz˛eły powstawać inne niż GPL licencje nadal
spełniajace
˛ definicj˛e wolnego oprogramowania10 .
Żeby to uporzadkować,
˛
w 1995 roku Debian11 stworzył „Debian Free Software Guideliness”12 – zasady opisujace
˛ kiedy dana licencja jest licencja˛ wolnego oprogramowania (dokument
ten był zupełnie niezależny od Free Software Foundation, aczkolwiek GPL spełniała te zasady).
Pomimo popularności wolnego oprogramowania wśród programistów, było ono rzadko wykorzystywane przez firmy i pozostałych użytkowników komputerów. W 1997 Bruce Perens (szef
Debiana) i Eric Raymond (publicysta i programista OSS) doszli do wniosku, że przyczyna˛ tego
jest „nieszcz˛esna” dwuznaczność terminu „free software” - ludziom kojarzyło sie ono pejoratywnie z darmowym oprogramowaniem niskiej jakości. Stworzyli oni nowy termin – Open Source
Software (po polsku oprogramowanie o otwartym źródle)13 . Założono organizacj˛e Open Source
Initiative14 , która z kolei opublikowała „Open Source Definition”15 (definicj˛e oprogramowania o
otwartym źródle) – niewiele zmieniony dokument „Debian Free Software Guideliness”. „Open
Source Definition” składa si˛e z 10 punktów:
1. Wolna redystrybucja – licencja musi umożliwiać każdemu użytkownikowi programu jego
dalsza˛ dystrybucj˛e, w tym pobieranie za to opłaty.
2. Kod Źródłowy – licencja musi zezwalać na dystrybucj˛e kodu źródłowego obj˛etego nia˛
9
Oparł si˛e na szkoleniowym systemie operacyjnym stworzonym przez Andrew Tanenbaum’a w MIT na potrzeby
prowadzenia zaj˛eć ze studentami.
10
von Hippel i von Krogh, Open Source Software and the “Private-Collective” Innovation Model. . . .
11
Debian jest stowarzyszeniem zajmujacym
˛
si˛e tworzeniem wolnego systemu operacyjnego opartego na
GNU/Linux – konkretniej ma własna˛ dystrybucj˛e Debian GNU/Linux. Zobacz: http://www.debian.org
12
Debian, Debian Free Software Guideliness.
13
von Hippel i von Krogh, Open Source Software and the “Private-Collective” Innovation Model. . . .
14
http://www.opensource.org
15
Perens, Open Source Definition.
11
oprogramowania. Gdy oprogramowanie jest dystrybuowane bez kodu źródłowego, musi
być on dost˛epny za darmo lub za opłata˛ równa˛ kosztowi reprodukcji.
3. Prace Pochodne – licencja musi umożliwiać tworzenie programów pochodnych i dystrybuowanie ich na tych samych zasadach, co licencja pierwotna.
4. Integralność kodu źródłowego autora – licencja może ograniczać dystrybucj˛e zmodyfikowanego kodu źródłowego tylko gdy pozwala na dystrybucj˛e „łatek”.16
5. Brak dyskryminacji żadnej osoby czy grupy osób.
6. Brak dyskryminacji żadnego pola zastosowania programu (w tym zastosowania w biznesie
lub do badań z dziedziny inżynierii genetycznej)
7. Dystrybucja Licencji – Licencja na której jest rozprowadzany program musi, bez konieczności dokonania dodatkowych czynności, dotyczyć także wszystkich, którzy ten program
posiad
˛ a.˛
8. Licencja nie może być specyficzna dla konkretnego produktu – nie może zależeć od tego,
czy program jest cz˛eścia˛ jakieś wi˛ekszej dystrybucji.
9. Licencja nie może wykluczać innego oprogramowania rozprowadzanego na tym samym
nośniku danych.
10. Licencja musi być niezależna od technologii – nie może zależeć od sposobu rozprowadzania programu (w sensie technicznym).
Definicje „Open Source Definition”17 i definicja wolnego oprogramowania opublikowana
przez Free Software Foundation18 różnia˛ si˛e. Obie te instytucje publikuja˛ list˛e licencji, które
uznaja˛ za wolne/o otwartym źródle19 . Dodatkowo Free Software Foundation podaje także list˛e
16
Łatka (ang. patch) – zawiera różnice pomi˛edzy pierwotnym kodem a kodem zmodyfikowanym. Korzystajac
˛
ze specjalnych narz˛edzi, po „nałożeniu” łatki na pierwotny kod, otrzymujemy kod zmodyfikowany. Taki sposób
dystrybucji programów pozwala odseparować program pierwotny od później dokonanych zmian. Stosuje si˛e go
głównie wtedy, gdy autorzy pierwotnego programu nie sa˛ w stanie stwierdzić jakiej jakości sa˛ poprawki, a nie chca˛
ryzykować utraty zaufania do jakości własnego oprogramowania. Użytkownik wtedy wie, że „nakłada łatk˛e” na
własne ryzyko.
17
Perens, Open Source Definition.
18
Stallman, The Free Software Definition.
19
Odpowiednio http://www.opensource.org/licenses/ i http://www.gnu.org/licenses/
license-list.html
12
licencji uznanych za niespełniajace
˛ kryteriów wolności. Po dokonaniu analizy okazało sie, że
organizacje te nie zgadzaja˛ si˛e tylko w przypadku jednej licencji: Artistic Licence. Free Software Foundation nie uznało tej licencji jako wolnej, a dla Open Source Initiative jest ona „open
source”.20 W uzasadnieniu jest napisane, że „Nie możemy stwierdzić, że jest licencja˛ wolnego
oprogramowania, ponieważ jest zbyt nieprecyzyjna – pewne ust˛epy sa˛ zbyt niejasne.”, i dalej
„Kłopoty dotycza˛ sformułowań, nie samego sensu.”21 Tak wi˛ec jedyny przypadek sprzecznej
klasyfikacji licencji opiera si˛e tylko na nieścisłości sformułowań. Co wi˛ecej, „Istnieje skorygowana wersja Licencji Twórczej (ochrzczona “Licencja˛ Twórcza˛ 2.0”), która jest licencja˛ wolnego
oprogramowania, a nawet jest zgodna z GPL.” – czyli problematyczna wersja Artistic License
została już poprawiona. Podsumowujac,
˛ obie organizacje sa˛ prawie zgodne co do ram opisywanego przeze mnie ruchu. W zwiazku
˛
z tym poj˛eć „wolne oprogramowanie” i „oprogramowanie
o otwartym źródle” b˛ed˛e używał wymiennie.
Organizacje te różnia˛ si˛e natomiast podejściem filozoficznym. Richard Stallman napisał
„Fundamentalna różnica mi˛edzy tymi dwoma ruchami leży w uznawanych przez nie wartościach, sposobach patrzenia na świat. Dla Open Source kwestia, czy oprogramowanie powinno
mieć dost˛epne otwarte źródła to problem praktyczny, nie etyczny. Jak to ktoś ujał:
˛ „Open source
to metodyka konstruowania, wolne oprogramowanie to ruch społeczny”. Dla ruchu Open Source
oprogramowanie, które nie jest wolne to rozwiazanie
˛
gorsze niż optymalne. Dla ruchu Wolnego
Oprogramowania programy, które nie sa˛ wolne to problem społeczny, którego rozwiazaniem
˛
jest
wolne oprogramowanie.”22
1.1. Licencje
Oprogramowanie komputerowe jest dobrem intelektualnym, charakteryzujacym
˛
si˛e prawie zerowym kosztem krańcowym utworzenia kolejnej kopii. Dobra intelektualne obj˛ete sa˛ specyficznymi dla tej kategorii prawami własności. Istnieja˛ trzy podstawowe rodzaje praw własności
intelektualnej23 :
Prawa Autorskie (ang. Copyright) Gdy powstaje nowe dobro intelektualne (np. program kom20
Niestety Open Source Initiative nie publikuje listy licencji, które nie sa˛ „open source”. W zwiazku
˛
z tym
jedyne badanie jakie mogłem przeprowadzić, to znalezienie wszystkich licencji uznanych za „open source” przez
Open Source Initiative a jednocześnie odrzuconych przez Free Software Foundation.
21
http://www.gnu.org/licenses/license-list.pl.html
22
Stallman, Dlaczego termin „Free Software” jest lepszy niż „Open Source”.
23
Koek, Free Software Licensing.
13
puterowy), autor automatycznie dostaje prawo własności tego dobra24 , co w uproszczeniu
oznacza że ma on wyłaczne
˛
prawo do kopiowania tego dobra. Prawo to jest automatyczne
i uniwersalne (obowiazuje
˛
wsz˛edzie). Gdy autor sprzedaje kopi˛e jakiemuś innemu podmiotowi, prawo autorskie nie przechodzi na kupujacego
˛
– tylko prawo do normalnego
użytkowania konkretnej kopii. Warto także zauważyć, że prawo autorskie (w szczególności w przypadku programów) odnosi si˛e tylko do konkretnego kodu, a nie pomysłu,
funkcjonalności, etc. Majac
˛ dany program, można stworzyć niezależnie nowy program o
identycznych możliwościach jak ten poprzedni – nie b˛edzie on już obj˛ety prawami własności autora pierwszego programu. W przypadku dóbr pochodnych, autor dobra pierwotnego
zachowuje prawa autorskie do cz˛eści napisanej przez siebie, zaś osoba wprowadzajaca
˛
modyfikacje uzyskuje prawo autorskie do tych modyfikacji.25 Prawo autorskie wygasa,
zwykle po 70 latach.
Patenty Patent jest dokumentem wydanym przez odp. urzad
˛ państwowy, który daje posiadaczowi wyłaczne
˛
prawo do wykorzystywania pewnego konkretnego wynalazku (invention)
– czyli samego pomysłu, idei, a nie konkretnej implementacji. Żeby wynalazek dało sie
opatentować, musi być on (1) nowy (nieopublikowany, nie używany publicznie), (2) nie
może być oczywisty (tzn. nie może być tak, że specjalista w danej dziedzinie z łatwościa˛
stworzyłby dany wynalazek), (3) musi należeć do dziedziny techniki26 i (4) musi sie nadawać do przemysłowego wykorzystania. Cz˛estym argumentem przeciwko stosowaniu patentów jest fakt, że to organizacja rzadowa
˛
jest odpowiedzialna za stwierdzenie, czy dany
wynalazek spełnia warunki (1) i (2). Ostatnio technika posun˛eła si˛e na tyle do przodu, że
bł˛edne decyzje zdarzaja˛ si˛e coraz cz˛eściej, szczególnie jeżeli chodzi o patenty na oprogramowanie. Patenty ulegaja˛ przedawnieniu po minimum 20 latach.27 Sa˛ prawem terytorialnym i nieautomatycznym. O patent trzeba si˛e ubiegać w biurze patentowym, które może
24
O ile stworzone przez niego dobro nie jest identyczne lub bardzo podobne do już istniejacego
˛
(np. algorytmu z
podr˛ecznika).
25
Jest to czasem wykorzystywane np. przez wydawców – gdy wydaja˛ jakieś stare dzieło, w przypadku którego
prawa autorskie już wygasły, dodaja˛ komentarze/interpretacj˛e, które sa˛ niezależnie obj˛ete prawem autorskim. Dzi˛eki
temu dobra jako całości (ksiażki
˛ z komentarzami) nie można kopiować i rozprowadzać.
26
Kwestia czy oprogramowanie jest patentowalne jest różnie rozstrzygalne w różnych krajach. W Stanach Zjednoczonych i Japonii wydaje si˛e patenty na oprogramowanie, w Unii Europejskiej sprawa jest dyskutowana.
27
Taki minimalny czas trwania patentów został przyj˛ety w TRIPS (Trade Related aspects of Intellectual Property
Rights) – mi˛edzynarodowej umowie dotyczacej
˛ ochrony intelektualnej, ratyfikowanej przez wi˛ekszość rozwini˛etych
gospodarczo państw.
14
przyznać patent lub go odrzucić. Patenty obowiazuj
˛ a˛ tylko na terytorium państwa, które je
wydało.28
Znaki handlowe Znak handlowy to znak umożliwiajacy
˛ rozpoznanie towarów lub dóbr danej
organizacji. Znakiem handlowym jest np. „Open Source” i „OSI Certified”, należa˛ one do
Open Source Initiative29 . Znaki handlowe nie wiaż
˛ a˛ si˛e bezpośrednio z prawami własności
intelektualnej programów komputerowych, wi˛ec nie b˛edziemy si˛e nimi wi˛ecej zajmować.
Tajemnica firmowa Jest to nieformalny sposób ochrony własności intelektualnej, bardzo istotny
jednak w odniesieniu do oprogramowania komputerowego. Ponieważ programy komputerowe sprzedaje si˛e w postaci kodu binarnego, na bazie którego bardzo trudno jest (czyli
kosztownie) odkryć rzeczywiste mechanizmy działania programu ukryte pod interfejsem
użytkownika, firma nie musi obawiać si˛e ujawnienia tajemnicy służbowej dystrybuujac
˛
program. Jest to jedyna forma ochrony wynalazków używana w małych i średnich przedsi˛ebiorstwach, ponieważ firm tych nie stać na aplikowanie o patenty.
Właściciele dóbr intelektualnych moga˛ dać(sprzedać) innym prawo do korzystania ze swojej kopii. To zezwolenie b˛edziemy nazywać licencja.˛ Licencja może ograniczać użytkownika
dobra intelektualnego i zabraniać mu dokonywania niektórych czynności (jak kopiowanie, rozpowszechnianie, modyfikacj˛e).
Autorzy wolnego oprogramowania wykorzystuja˛ istniejace
˛ mechanizmy ochrony praw autorskich do zapewnienia „wolności” swojemu oprogramowaniu. Posiadajac
˛ prawa autorskie,
„rozdaja”
˛ program na pożadanej
˛
przez siebie licencji.30
Przeglad
˛ licencji oprogramowania o otwartym źródle
The General Public License (GPL) – kiedyś GNU Public License – jest to pierwsza licencja
wolnego oprogramowania, stworzona przez Free Software Foundation, nazywana także
„copyleft”. Najważniejsze cechy to:
• użycie oprogramowania jest nieograniczone.
28
Ostatnio wprowadzono pojecie patentu europejskiego, który b˛edzie obowiazywał
˛
w całej Unii Europejskiej.
Zobacz http://opensource.org/trademarks/.
30
Ibid.
29
15
• kopiowanie i rozpowszechnianie jest możliwe pod kilkoma warunkami, w szczególności kopia programu obj˛etego GPL jest również obj˛eta GPL. Pobieranie opłaty
za kopi˛e jest explicite dopuszczone.
• modyfikacja jest dozwolona pod warunkiem, że jeżeli zmodyfikowany program b˛edzie rozpowszechniany, modyfikacje b˛eda˛ obj˛ete taka˛ sama˛ licencja˛ jak oryginał (ta˛
cech˛e nazywamy żywotnościa˛ licencji).
Żywotność oznacza, że licencja gwarantuje nie tylko wolność obj˛etego nia˛ oprogramowania, ale także zapewnia, że wszystkie programy pochodne, modyfikacje i udoskonalenia
także b˛eda˛ wolnym oprogramowaniem.
The Library GPL (obecnie Lesser GPL)– gdy biblioteki były obj˛ete GPL, napotkano problem:
czy program zlinkowany31 z biblioteka˛ zawiera kod obj˛ety GPL? W uj˛eciu prawnym prawdopodobnie (nie było to jeszcze testowane w sadzie)
˛
taki program jest uznawany za program pochodny, co nie zawsze było intencja˛ autorów bibliotek. Powstała nowa licencja
LGPL – różniaca
˛ si˛e od GPL tylko zapisem, że programy zlinkowane32 z biblioteka˛ nie
musza˛ być wolnym oprogramowaniem (natomiast nowa biblioteka oparta na naszej musi
być na LGPL). Konieczne jest natomiast udost˛epnienie pliku obiektowego(czyli skompilowanego, ale nie zlinkowanego z biblioteka),
˛ żeby użytkownik mógł samodzielnie zlinkować ten plik z inna˛ (nowsza)
˛ wersja˛ biblioteki.
typu MIT/X – poprzednio omówione licencje były „żywotne”, czyli wymagały by programy
pochodne także były wolnym oprogramowaniem, obj˛etym taka˛ sama˛ licencja.˛ Dla wielu
twórców taki zapis jest jednak niewygodny. Licencje typu MIT/X pozwalaja˛ na dowolne
licencjonowanie programów pochodnych, wprowadzaja˛ jednak ograniczenia:
• wszystkie istniejace
˛ informacje o prawach autorskich i warunkach licencji musza˛
pozostać niezmienione.
• nazwiska autorów nie moga˛ być wykorzystywane do promocji programów pochodnych.
31
32
W uproszczeniu korzystajacy
˛ z biblioteki
Licencja zawiera bardzo konkretna˛ definicj˛e „bycia zlinkowanym”: (fragment §5 – plik obiektowy jest plikiem
już skompilowanym, ale jeszcze nie zlinkowanym z biblioteka)
˛ „(. . . ) Jeżeli taki plik obiektowy korzysta tylko
z parametrów liczbowych, schematów struktur danych oraz małych (maksymalnie 10 linii kodu) makr i funkcji
wstawianych (ang. inline functions), to użycie takiego pliku obiektowego jest nieograniczone, niezależnie czy
formalnie jest to program pochodny”. Pełen tekst licencji: http://www.gnu.org/licenses/lgpl.html
16
Na licencjach tego typu istnieje obecnie bardzo dużo oprogramowania, najważniejszym
przykładem jest X Window System – graficzny interfejs użytkownika używany w wi˛ekszości systemów uniksowych (w tym w Linuksie). Licencje takie niosa˛ ze soba˛ jednak
niebezpieczeństwo, że w pewnym momencie poprawki i rozszerzenia kodu przestana˛ być
wolnym oprogramowaniem. Taka sytuacja miała miejsce z X Window System – w kwietniu 1998 roku Open Group (organizacja zajmujaca
˛ si˛e wtedy systemem) ogłosiła, że implementacja nast˛epnej wersji nie b˛edzie już wolnym oprogramowaniem. W tym momencie
ludzie zajmujacy
˛ si˛e dostosowaniem tego systemu do wolnych systemów operacyjnych
(Linux i FreeBSD) zadeklarowali, że nie b˛eda˛ oni korzystać z komercyjnej wersji proponowanej przez Open Group, tylko b˛eda˛ niezależnie rozwijać oprogramowanie (wszystkie wersje sprzed kwietnia pozostawały nadal wolnym oprogramowaniem). We wrześniu
Open Group ogłosiła, że nowa˛ wersj˛e wyda na tych samych zasadach co dotychczas.
licencje typu BSD – (Berkeley Software Distribution) Uniwersytet Kalifornijski Berkeley był
jednym z dwóch ośrodków badawczych, w których powstawał system operacyjny UNIX
(drugim były Bell Laboratories z AT&T). Rodzaj licencji, na której uniwersytet wypuszczał swoje oprogramowanie nazywamy „licencjami typu BSD”. Ponieważ prace te były
sponsorowane przez rzad
˛ Stanów Zjednoczonych, kod jest licencjonowany bardzo liberalnie. Warunki licencji sa˛ podobne do MIT/X z dodanym zastrzeżeniem, że wszystkie
reklamy musza˛ zawierać podzi˛ekowanie dla twórców. Zapis ten powoduje, że licencje
BSD nie sa˛ „kompatybilne” z GPL33 – to znaczy nie można połaczyć
˛
oprogramowania na
licencji BSD z oprogramowaniem na GPL i wypuścić całości na GPL (licencje typu MIT/X
nie maja˛ tej własności, gdyż nie zawieraja˛ zapisu sprzecznego z GPL). Przykładami programów na licencji typu BSD sa˛ sendmail, Apache czy freeBSD.
Podwójne licencjonowanie Zdarza si˛e także, że oprogramowanie jest dost˛epne na dwóch różnych licencjach – klient wybiera ta˛ która mu bardziej pasuje. Najbardziej znane przykłady
to:
• J˛ezyk skryptowy Perl daje użytkownikowi wybór pomi˛edzy GPL’em, a Artistic License (nie jest żywotna – modyfikacje moga˛ nie być oprogramowaniem o otwartym
źródle – ale wymaga by modyfikacje były rozprowadzane pod inna˛ nazwa).
˛
33
W nowej wersji licencji BSD zrezygnowano tego kłopotliwego zapisu i jest już ona kompatybilna z GPL –
program utworzony z fragmentów kodu na GPL i BSD b˛edzie ostatecznie na GPL.
17
• Autor programu Ghostscript wypuszcza nowa˛ wersj˛e programu na licencji AFPL
(Aladdin Free Public License). Pozwala ona tylko na redystrybucj˛e niekomercyjna˛
– w przeciwnym przypadku trzeba zapłacić. Jednak po pojawieniu si˛e nowej wersji,
poprzednie przechodza˛ automatycznie na GPL.
• Podejście typu opublikuj albo płać – oprogramowanie jest dost˛epne na jakiejś żywotnej licencji oprogramowania o otwartym źródle (np. GPL) lub na licencji komercyjnej, umożliwiajacej
˛ sprzedaż oprogramowania pochodnego na dowolnej licencji(np. system zarzadzania
˛
baza˛ danych MySQL).
Podwójne licencjonowanie niesie jednak ze soba˛ pewne problemy. Jeżeli zostanie nadesłana poprawka do wersji licencjonowanej na GPL, to czy może być ona uwzgl˛edniona
w wersji komercyjnej? Trzeba by przekonać autora poprawki, by wypuścił ja˛ na innej
licencji. Dlaczego jednak miałby to robić?
Komercyjne licencje – ostatnio obserwujemy rosnace
˛ zaangażowanie wielkich korporacji w
rozwój wolnego oprogramowania. Gdy firmy takie wypuszczaja˛ swoje oprogramowanie
jako oprogramowanie o otwartym źródle, cz˛esto tworza˛ nowa˛ licencj˛e, która lepiej pasuje
do ich potrzeb. Licencje te zawieraja˛ cz˛esto kontrowersyjne zapisy i toczy si˛e burzliwa
dyskusja czy pozostaja˛ one nadal licencjami oprogramowania o otwartym źródle. Przedstawi˛e dwa najbardziej znane przykłady:
• The Netscape Public License (NPL) licencja ta jest żywotna tylko w niektórych
przypadkach – modyfikacje znajdujace
˛ si˛e w oddzielnych plikach moga˛ być rozprowadzane na innej licencji, a modyfikacje istniejacych
˛
plików nie. Poza tym, Netscape zostawia sobie prawo do wykorzystywania modyfikacji w jakikolwiek sposób
– powyższe ograniczenia go nie obowiazuj
˛ a˛ (jako jedyny podmiot ma prawo wypuścić komercyjna˛ wersj˛e). Na tej licencji została wypuszczona przegladarka
˛
internetowa Netscape (lecz nie cały kod, gdyż do cz˛eści Netscape nie miał praw autorskich). Dziś projekt ten nazywa si˛e Mozilla (http://www.mozilla.org),
zaś licencjonowanie stało si˛e bardzo skomplikowane, szczegóły można znaleźć na
http://www.mozilla.org/MPL/. Wi˛ekszość licencji jest jednak podobna do
NPL.
• The Apple Public Source License (APSL) Licencja ta obejmuje produkty Apple
wypuszczone jako oprogramowanie o otwartym źródle. Licencja ta jest żywotna,
18
nakłada na użytkownika kilka specyficznych ograniczeń:
– Każda modyfikacja albo nawet użycie zmodyfikowanej wersji oprogramowania
obj˛etego APSL musi być zgłoszone Apple.
– Podobnie jak Netscape, firmy Apple żywotność nie obowiazuje
˛
jeżeli chodzi o
wszelkie modyfikacje.
– Apple zostawia sobie prawo do unieważnienia licencji gdy ktoś zaskarży firm˛e o
złamanie patentu czy prawa autorskiego. Dla użytkownika oznacz to, że licencja
może być w każdym momencie unieważniona, gdyż nie ma zapisu, że to oskarżenie ma być sensowne. W nowszej wersji osłabiono ten zapis: licencja b˛edzie
zawieszona na czas procesu. Przez ten zapis pierwsza wersja licencji w ogóle
nie była uznawana jako licencja oprogramowania o otwartym źródle.
Cechy różnych licencji
Z poprzedniego podrozdziału wynika, że choć oprogramowanie o otwartym źródle wydaje si˛e
jednym, spójnym fenomenem, tak naprawd˛e każdy projekt może mieć inna˛ licencj˛e, dalej pozostajac
˛ oprogramowaniem o otwartym źródle. Przeanalizujmy (na podstawie Lerner i Tirole, The
Scope of Open Source Licensing) czym kieruja˛ si˛e liderzy projektów wybierajac
˛ jakaś
˛ konkretna˛
licencj˛e, jaki wpływ ma dana licencja na powodzenie projektu oraz jak determinuje możliwości
wykorzystania projektu przez firmy komercyjne. W momencie wyboru licencji, licencjodawca
musi uwzgl˛ednić czynniki jak współpraca z innym oprogramowaniem (nie każde licencje sa˛
ze soba˛ komplementarne), motywacja innych programistów, żeby przyłaczyli
˛
si˛e do projektu,
możliwości rozwidlenia projektu, możliwa współpraca z komercyjnymi dystrybutorami, etc.
Zauważmy także, że cz˛esto motywacje licencjodawcy b˛eda˛ si˛e różniły od motywacji licencjobiorców, szczególnie gdy licencjodawca˛ jest nastawione na zysk przedsi˛ebiorstwo komercyjne.
Można wyróżnić nast˛epujace
˛ czynniki:
1. Interakcje z innym oprogramowaniem – charakterystyczna˛ cecha˛ oprogramowania o
otwartym źródle jest to, że bardzo cz˛esto w jednym projekcie korzysta sie z innych projektów czy łaczy
˛
si˛e kilka programów razem. Co wi˛ecej, jak przeanalizujemy w kolejnym
rozdziale, niektóre rodzaje oprogramowania (np. programy rozrywkowe czy branżowe)
maja˛ bardzo mała˛ szans˛e wyjść na licencji oprogramowania o otwartym źródle. Dlatego
potencjalna możliwość współpracy z oprogramowaniem komercyjnym także ma znaczenie.
19
Łaczenie
˛
z innym oprogramowaniem ma istotne znaczenie gdy autor oprogramowania
chce ustalić jakiś obowiazuj
˛ acy
˛ standard (jak na przykład w przypadku projektów ukierunkowanych na komunikacj˛e sieciowa).
˛ Możemy przewidywać, że takie projekty b˛eda˛
na mniej restrykcyjnych licencjach (nieżywotnych), mimo zagrożenia rozwidleniem lub
przej˛eciem projektu.
Co ciekawe, wybór licencji może spowodować powstanie efektów sieciowych (ang. network externalities)34 wśród liderów oprogramowania o otwartym źródle. Wybór nowej
licencji dla programu w pewnym polu zastosowania może być zdeterminowany ch˛ecia˛
współpracy z istniejacymi
˛
już projektami. Brak dowolności w tym wzgl˛edzie wynika z
niekompatybilności licencji. Jeżeli istniejace
˛ oprogramowanie jest np. na pierwotnej licencji BSD35 , to wypuszczenie nowego projektu na GPL spowoduje, że zupełnie nie b˛edzie
możliwe połaczenie
˛
obu programów. Z kolei jeżeli istnieje jakiś duży projekt na liberalnej
licencji (np. X Window Server), a my wypuścimy oprogramowanie na GPL, to liderzy dużego i uznanego projektu nie b˛eda˛ raczej skorzy do zmiany licencji na GPL, żeby połaczyć
˛
si˛e z naszym oprogramowaniem, etc.
2. Komercjalizacja projektów – zwolennicy żywotnych licencji argumentuja,˛ że gdy oprogramowanie jest na liberalnej licencji, jest ono narażone na komercyjne przej˛ecia. Firma
może dopisać troch˛e własnego, zamkni˛etego kodu, dodać do oprogramowania o otwartym
źródle i wypuścić wszystko jako własne oprogramowanie z zamkni˛etym źródłem (podobnie jak w 1998 roku próbowano zrobić z X Window Server). Takie oprogramowanie może
w końcu zdominować rynek. Samo to jeszcze nie koniecznie musi być gorsze dla społeczeństwa niż istnienie tylko wersji OSS. W kolejnym jednak kroku firma komercyjna może
zaczać
˛ wykorzystywać swoja˛ pozycj˛e monopolisty, a stara, jeszcze wolna wersja oprogramowania, może być już zupełnie niekompatybilna z nowymi standardami. W każdym wariancie wszyscy (głównie programiści rozwijajacy
˛ to oprogramowanie) straca˛ możliwości
wynikajace
˛ z wolności oprogramowania i otwartości kodu, jak dostosowanie oprogramowania do swoich potrzeb czy szacunek kolegów wynikajacy
˛ z pracy nad programem. Taka
ewentualność może w ogóle odstraszyć potencjalnych programistów zanim jeszcze po34
Mówimy, że wyst˛epuja˛ efekty sieciowe, gdy konsument używajacy
˛ pewnego produktu uzyskuje wi˛eksza˛ uży-
teczność, gdy inni konsumenci korzystaja˛ z tego samego dobra. Dobrym przykładem jest oprogramowanie komunikacyjne – konsument ma z niego użyteczność, gdy ma si˛e z kim komunikować za jego pośrednictwem.
35
Istnieje wiele innych licencji niekompatybilnych z GPL, patrz:
http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses
20
dejma˛ prac˛e nad tym projektem.
3. Patenty na oprogramowanie – łatwo sobie wyobrazić sytuacj˛e, gdy zostanie udowodnione, że oprogramowanie o otwartym źródle narusza jakiś patent na oprogramowanie –
mogłoby to co najmniej odstraszyć programistów i użytkowników. Najbardziej widoczne
jest to w przypadku Apple, gdzie w licencji zapisano, że firma może „zawiesić” ważność
licencji w czasie post˛epowania. W GPL także w jawny sposób (patrz §7) jest napisane, że
korzystanie z programu w ramach licencji (czyli np. użytkowanie czy rozpowszechnianie)
jest dozwolone tylko gdy nie narusza to innych przepisów prawa, np. patentowego.
4. Bodźce do produkcji komplementarnego oprogramowania – standardowym argumentem na korzyść liberalnych licencji jest umożliwienie firmom komercyjnym tworzenie
aplikacji, które współpracuja˛ (wykorzystuja)
˛ istniejacy
˛ kod. Wydaje si˛e, że szczególnie
w przypadku dojrzałych projektów, gdy poczatkowa
˛
energia programistów jest już na wyczerpaniu, zaangażowanie komercyjnych firm w tworzenie kodu może być kluczowym
bodźcem dla dalszego rozwoju.
5. Znajomość licencji przez środowisko programistów – jeżeli korzystamy ze znanej licencji, potencjalni programiści nie musza˛ inwestować dodatkowego czasu, żeby zaznajomić
sie z warunkami nowej licencji.
6. Rozwidlanie – poza powstawaniem konkurencyjnych wersji komercyjnych i koniecznościa˛ zmiany nazwy projektu w przypadku niektórych licencji, nie wiadomo na razie jak
wybór licencji może wpływać na prawdopodobieństwo rozwidlenia projektu.
Lerner i Tirole przeprowadzaja˛ analiz˛e empiryczna˛ licencjonowania projektów OSS. Dane
pochodza˛ z SourceForge (http://sourceforge.net/), najwi˛ekszego internetowego serwisu oferujacego
˛
utrzymywanie projektów (ang. hosting – czyli udost˛epnienie strony projektu,
przestrzeni na dysku na kod źródłowy i wykonywalny, systemu zgłaszania bł˛edów i poprawek,
etc.). Badania zostały przeprowadzone w maju 2002 i wtedy SourceForge zawierał ok. 39 tys.
projektów. Oczywiście nie wszystkie programy OSS korzystaja˛ z SourceForge, jednak serwis
ten ma znaczna˛ przewag˛e liczebna˛ nad konkurencja˛ – w 2002 drugim pod wzgl˛edem wielkości takim portalem był Savannah i zawierał tylko 790 projektów. Przy czym nawet gdy jakiś
projekt fizycznie znajduje si˛e gdzieś indziej, cz˛esto na SourceForge’u także ma swoja˛ stron˛e,
zawierajac
˛ a˛ podstawowe dane i odnośnik do właściwej lokalizacji.
21
Dane pokazuja˛ asymetryczny rozkład licencji: 72% projektów jest na licencji GPL, 10%
na LGPL, a tylko 7% na BSD. Wynika to pewnie z faktu, że GPL i LGPL sa˛ najbardziej znane
wśród programistów i gwarantuja,˛ że praca programistów nie zostanie „skradziona” przez przedsi˛ebiorstwa. Gdy już powstało dużo programów na tych licencjach, kolejne powstawały także
36
z powodów kompatybilności z już istniejacymi
˛
. Najwi˛ecej jest młodych projektów (poniżej 2
lat) – widać wyraźnie że popularność oprogramowania o otwartym źródle najbardziej dynamicznie rosła w ciagu
˛ ostatnich kilku lat.
W danych można zaobserwować kilka wyraźnych i statystycznie istotnych zależności:
• Projekt w stadium planowania (dopiero rozpoczynany) ma o 12% wi˛eksze przewidywane
prawdopodobieństwo że b˛edzie miał restrykcyjna˛ licencj˛e niż projekt dojrzały. Może to
oznaczać, że kiedyś GPL nie miała aż takich efektów sieciowych, albo że starsze projekty
chca˛ zwi˛ekszyć swoje szanse na przetrwanie.37
• Projekty zorientowane na użytkowników końcowych maja˛ o 23% cz˛eściej restrykcyjne
licencje niż projekty zorientowane na programistów.38
• Projekty działajace
˛ na komercyjnych systemach operacyjnych (Ms Windows) rzadziej maja˛
restrykcyjne licencje.39 Może to wynikać z faktu, że Linux i podstawowe narz˛edzia i biblioteki sa˛ na GPL, co tworzy efekty sieciowe.
• Projekty atrakcyjne dla konsumentów (np. gry) maja˛ licencje bardziej restrykcyjne.40 Tutaj
groźba przej˛ecia przez firm˛e komercyjna˛ wydaje si˛e dominujacym
˛
czynnikiem.
Autorzy pracy wyodr˛ebnili z próbki 51 projektów, które były wypuszczone jako oprogramowanie o otwartym źródle przez firmy komercyjne. Okazało si˛e, że licencje restrykcyjne dominuja˛
w tej grupie (chociaż zależność ta nie jest istotna statystycznie). Widocznie ch˛eć pozyskania programistów i ich obawa, czy projekt nie b˛edzie z powrotem „sprywatyzowany” przez firm˛e, były
warunkami kluczowymi.
36
Można powiedzieć, że na rynku ustaliła si˛e równowaga z dominujac
˛ a˛ pozycja˛ licencji GPL. Istnienie jednej
dominujacej
˛ licencji wynika z efektów sieciowych (network effects) – gdy wszyscy (racjonalnie) wierza˛ że jedna
z licencji stanie si˛e dominujaca,
˛ wypuszczaja˛ swoje programy na tej właśnie licencji, żeby zagwarantować sobie
korzyści sieciowe – łaczenie
˛
z innymi programami, wykorzystywanie kawałków kodu, łatwe przyciagni˛
˛ ecie programistów znajacych
˛
licencj˛e, itd.
37
Lerner i Tirole, The Scope of Open Source Licensing s.28.
38
Ibid.
39
Ibid. s.30.
40
Ibid.
22
1.2. Tworzenie oprogramowania o otwartym źródle
Oprogramowanie o otwartym źródle powstaje w sposób inny niż oprogramowanie komercyjne.
Programiści nie sa˛ zwiazani
˛
kontraktem i nie musza˛ pisać kodu. Nie maja˛ przełożonych w klasycznym rozumieniu tego słowa, którzy koordynowaliby ich prac˛e, przydzielali do konkretnych
zadań, pilnowali zachowania jakości pracy i wyznaczonych terminów. Co wi˛ecej, programiści
nie dostaja˛ wynagrodzenia pieni˛eżnego za swój udział w projekcie wi˛ec kwestia ich motywacji
do podj˛ecia pracy nie jest oczywista. W tym rozdziale chciałbym si˛e zastanowić nad procesem
powstawania oprogramowania o otwartym źródle, sposobem koordynacji i kontroli pracy programistów, oraz bodźców kierujacych
˛
ich do podj˛ecia wysiłku rozwoju wolnego oprogramowania.
Nast˛epnie przeanalizuj˛e jakość powstałego w ten sposób oprogramowania41 i możliwościa˛ kontroli badź
˛ wpłyni˛ecia na wolne oprogramowanie przez firmy komercyjne.
Proces tworzenia wolnego oprogramowania istotnie różni si˛e od tradycyjnej inżynierii oprogramowania używanej w przedsi˛ebiorstwach. Eric Raymond42 w Raymond, The Cathedral and
the Bazaar porównuje styl pracy w firmach informatycznych do budowania katedry, a powstawanie oprogramowania o otwartym źródle do wymiany na chaotycznym i hałaśliwym bazarze.43
Żeby zbudować katedr˛e, trzeba na poczatku
˛ przemyśleć i zaprojektować jej wyglad,
˛ a nast˛epnie
po kolei wykonywać plan, w „spokoju i izolacji”. Katedra nie może być oddana do użytku (testowania) zanim nie b˛edzie w pełni skończona. Bazar, z drugiej strony, rzadzi
˛ si˛e zupełnie innymi
prawami. Tam każdy programista może mieć własna˛ wizj˛e i termin ukończenia swoich kawałków kodu, każdy może w dowolnym momencie przyjść na bazar, popracować nad projektem, a
nast˛epnie go opuścić. Nowe wersje oprogramowania sklecone z kawałków nadesłanych przez
programistów wypuszczane sa˛ bardzo cz˛esto (nawet codziennie) i bardzo szybko (gdy oprogramowanie osiagnie
˛
jakakolwiek
˛
użyteczność, w przeciwieństwie do doskonałości katedry). W
taki właśnie bazarowy sposób powstał mi˛edzy innymi Linux, coraz bardziej popularny system
operacyjny o otwartym kodzie. Postaram si˛e wyjaśnić, jak z tego (pozornego) chaosu może
powstać oprogramowanie o tak dużej złożoności jak nowoczesny system operacyjny, i o takiej
jakości, że ludzie i firmy decyduja˛ si˛e go używać.
41
Jakość rozumiem jako (1) liczba bł˛edów wykrywanych w programach i czas ich poprawienia (2) dopasowanie
możliwości programu do potrzeb użytkowników - przeanalizuj˛e jakie grupy użytkowników sa˛ odbiorcami oprogramowania o otwartym źródle
42
Lider projektu „Fetchmail”, publicysta ruchu oprogramowania o otwartym źródle, prezes Open Source Initiative.
43
ibid. s. 2-3.
23
Autorzy (szczególnie Eric Raymond w Raymond, The Cathedral and the Bazaar) podkreślaja˛ konieczność samodzielnego napisania przez programist˛e poczatkowej
˛
wersji programu.
Raymond pisze: „Każdy dobry program ma swój poczatek
˛ w połechtaniu osobistych ambicji
programisty”44 .Podkreśla, że w bazarowym stylu można rozwijać tylko już istniejacy
˛ program,
który musi rzeczywiście działać i wykonywać jakaś
˛ sensowna˛ prac˛e, chociaż może zawierać
jeszcze bł˛edy, niedociagni˛
˛ ecia i braki pewnych (oczywistych) funkcjonalności. Żeby namówić
potencjalnych twórców do stworzenia bazaru, musza˛ oni widzieć, że oprogramowanie (1) działa
(2) może być rozwini˛ete do czegoś naprawd˛e wartościowego.45
O programach nie rozwijanych jeszcze w stylu bazarowym b˛ed˛e mówił, że sa˛ w fazie wst˛epnej. Lerner i Tirole podkreślaja,˛ że poza warunkami, że projekt ma być działajacy
˛ i „do zrobienia”, pierwotny twórca musi zostawić także jakieś ciekawe i nietrywialne problemy do rozwiaza˛
nia potencjalnym programistom. Linus Torvalds, gdy napisał pierwsza˛ wersj˛e Linuksa, stworzył
specjalna˛ stron˛e internetowa,˛ gdzie zach˛ecał innych programistów do dalszego rozwoju tego
programu. W swoich pierwszych publikacjach, majacych
˛
wzbudzić zainteresowanie Linuksem,
podkreślał ilość kreatywnego programowania, jaka jest jeszcze potrzebna by program uzyskał
pełna˛ funkcjonalność.46 Dopiero po utworzeniu produktu przyciagaj
˛ acego
˛
innych programistów
projekt wchodzi w faz˛e dojrzała,˛ rozwijajac
˛ a˛ si˛e już w stylu bazarowym. Co wi˛ecej, wypuszczenie ewidentnie działajacego
˛
i funkcjonalnego oprogramowania niekoniecznie musi zapoczatko˛
wać jego rozwój w stylu bazarowym. Przykład przegladarki
˛
Netscape Navigator47 pokazuje, że
programiści nie podejma˛ si˛e pracy nad programem źle zaprojektowanym, z niechlujnym kodem
czy źle zdefiniowanymi celami.48
Zauważmy, że przez cała˛ faz˛e wst˛epna˛ programista (grupa programistów) pracuje sam, czyli
posiada pełna prawa autorskie do swojego dzieła. Czemu decyduja˛ si˛e oni do wypuszczenia
44
Oryginalnie: „Every good work of software starts by scratching a developer’s personal itch.”
Raymond, The Cathedral and the Bazaar s.18.
46
Lerner i Tirole, The Simple Economics of Open Source s. 26, 29-30.
47
W 1998 firma Netscape wypuściła kod swojej przegladarki
˛
internetowej na licencji oprogramowania o otwar45
tym źródle. Program ten przegrywał wtedy z konkurencyjnym produktem Microsoft Internet Explorer. Ponieważ
jednak na poczatku
˛ Navigator (1) nie do końca był funkcjonalny, gdyż Netscape nie mógł opublikować cz˛eści kodu
– do którego nie miał wszystkich praw (2) kod był charakterystyczny dla firm, składał si˛e z wielkich fragmentów
współzależnych ze soba,˛ praktycznie niemożliwe było poprawienie małej cz˛eści. Dopiero po dopisaniu brakujacych
˛
fragmentów i podzieleniu kodu na mniejsze, funkcjonalne kawałki (wysoka modularność programów jest bardzo
charakterystyczna dla oprogramowania o otwartym źródle) projekt zaczał
˛ dynamicznie zyskiwać twórców i użytkowników. Dziś nazywa sie Mozilla, http://www.mozilla.org.
48
Raymond, The Cathedral and the Bazaar s. 29.
24
oprogramowania jako oprogramowanie o otwartym źródle, zamiast je sprzedać i czerpać z tego
zyski? Przedyskutujemy ten problem w dalszej cz˛eści pracy.
Po analizie licencji wydawałoby si˛e, że projekty OSS charakteryzuja˛ si˛e „równouprawnieniem” wszystkich twórców i użytkowników, duża˛ liczba˛ rozwidleń (gdyż każdy, gdy nie zgadza
si˛e z pozostałymi, ma prawo stworzyć własna˛ wersj˛e, ew. zobligowany jest do zmiany nazwy
czy wypuszczenia swojej wersji na tych samych warunkach co oryginał – w zależności od licencji) i ogólnym chaosem. Okazuje si˛e jednak, że w społeczności hakerów (twórców wolnego
oprogramowania) istnieja˛ bardzo silne, niepisane normy. W szczególności każdy projekt posiada Lidera, który jest nieformalnym, ale w rzeczywistości bardzo poważanym, przywódca˛ projektu. Eric Raymond wprowadza nawet termin „własności projektów OSS”49 . Pokazuje analogi˛e
do anglo-amerykańskiego prawa własności ziemi w przypadku słabej władzy centralnej (Johna
Locke’a). Ziemi˛e można było nabyć na 3 sposoby: zagospodarować leżacy
˛ odłogiem teren (na
granicy cywilizacji), poprzez transfer tego prawa od poprzedniego właściciela badź
˛ przez zaj˛ecie i zagospodarowanie porzuconego obszaru. Podobnie jest z projektami programistycznymi –
zawsze można znaleźć osob˛e (lub grup˛e osób), która zajmuje si˛e projektem, ma uprawnienia do
modyfikacji strony i oficjalnego kodu źródłowego, etc. Taka osoba jest „właścicielem projektu” i
najcz˛eściej jego liderem. Rozwidlanie projektu uznawane jest przez społeczność za niemoralne,
sprzeczne z zasadami norm kulturowych, gdyż jest to swoista kradzież praw własności do projektu. Ma to także uzasadnienie racjonalne – po rozwidleniu grupa programistów zwiazana
˛
z
tym oprogramowaniem dzieli si˛e na dwa obozy. Przez to nast˛epuje spadek tempa rozwoju każdej z tych wersji, a co za tym idzie spadek użyteczności społeczności z nowych funkcjonalności.
Praktyka wskazuje, że w długim okresie szans˛e na „przeżycie” ma tylko jeden projekt.
Obowiazkiem
˛
właściciela/lidera jest dbanie o uwzgl˛ednienie opinii, poprawek, pomysłów,
etc. wszystkich zainteresowanych. Gdy nie wywiazuje
˛
si˛e on z tego, projekt uznaje si˛e za
porzucony i możliwe jest przej˛ecie jego praw własności przez innego programist˛e. Społeczność
hakerów mocno preferuje jednak transfer praw od poprzedniego właściciela, który zdajac
˛ sobie
spraw˛e, że sam nie ma już czasu/ch˛eci to zajmowania si˛e projektem, ogłasza, że przekazuje swoje
funkcje konkretnemu nast˛epcy. Zupełnie opuszczone projekty zdarzaja˛ si˛e stosunkowo rzadko.
Zanim całkowicie si˛e przejmie prawa własności takiego projektu, wypada ogłaszać taki zamiar
na listach dyskusyjnych zwiazanych
˛
z projektem i czekać na ew. sprzeciw.50
49
50
Raymond, Homeseading the Noosphere.
Ibid. s. 6-11.
25
Istnienie centralnej grupy51 dla każdego projektu, która najwi˛ecej si˛e tym projektem zajmuje, potwierdzaja˛ także badania empiryczne. Lerner i Tirole cytuja˛ wyniki badań Ghosh’a i
Prakash’a. Zbadali oni 25 milionów linii kodu oprogramowania o otwartym źródle (3149 różnych projektów). Ponad 13 tysi˛ecy programistów rozwijało to oprogramowanie. Ciekawe, że
ponad trzy czwarte z nich dokonało tylko jednej kontrybucji. Tylko jedna osoba na 25 ma
wi˛ecej niż 5, górny decyl programistów napisał 72% kodu. Dane te byłyby jeszcze bardziej
asymetryczne, gdyby w badaniu wzi˛eto pod uwag˛e także samo zgłoszenie bł˛edu, a nie tylko poprawki i dopisywanie nowych funkcjonalności. Szacuje si˛e, że na jedna˛ poprawk˛e/nowy kawałek
przypada ok. pi˛eciu raportów bł˛edów. Główna grupa programistów jest najlepiej widoczna w
przypadku projektu Apache’a - tam 15 programistów dokonuje 83-91% zmian.52 Najcz˛eściej
liderem/członkami grupy centralnej zostaja˛ pierwotni założyciele projektu (ci, którzy go rozwijali w fazie wst˛epnej) i programiści, którzy pokazali swoje umiej˛etności dopisujac
˛ błyskotliwe
kawałki kodu.
Zjawisko to jest dla nas bardzo istotne, gdyż istniejace
˛ normy kulturowe maja˛ duży wpływ
na sam proces powstawania oprogramowania o otwartym źródle. Tylko lider (grupa centralna)
maja˛ prawo zapisywać do oficjalnego repozytorium programu – czyli zmieniać oficjalny kod
źródłowy. Oni sa˛ odpowiedzialni za dodawanie przysłanych poprawek do oficjalnego kodu, jeżeli
uznaja,˛ że sa˛ dobre. Maja˛ wi˛ec bezpośredni wpływ na rozwój projektu. Ponieważ programistów
(potencjalnych) jest bardzo wielu i pracuja˛ oni nad projektem w sposób niekontrolowany, nie
jest możliwa pełna koordynacja ich działań – zdarza si˛e że powstana˛ dwie takie same poprawki
na raz, lub że dwie poprawki wzajemnie si˛e wykluczaja˛ i nie moga˛ być jednocześnie dołaczone
˛
do programu. Za rozwiazywanie
˛
takich problemów odpowiedzialny jest lider projektu. Żeby
zminimalizować to zjawisko, kolejne wersje oprogramowania o otwartym źródle sa˛ wypuszczane
bardzo cz˛esto (nawet kilka razy dziennie – a programy komercyjne wychodza˛ co rok-dwa), przez
co potencjalni programiści moga˛ si˛e zorientować, że interesujacy
˛ ich fragment kodu źródłowego
uległ modyfikacjom. Dzi˛eki takiej organizacji tracimy produktywność na pokrywajacej
˛ si˛e pracy
i niekompatybilnościach poprawek. Nie trzeba jednak utrzymywać pełnej koordynacji pomi˛edzy
wszystkimi programistami, a tylko pomi˛edzy każdym programista˛ a liderem.
51
52
ang. core developers
Lerner i Tirole, The Simple Economics of Open Source s. 11-12.
26
1.2.1. Motywacja programistów
W tym rozdziale chciałbym si˛e zastanowić, dlaczego użytkownicy wolnego oprogramowania/programiści
decyduja˛ si˛e je rozwijać i dzielić z innymi owoce swojej pracy. Fakt, że zgłaszaja˛ znalezione
bł˛edy można łatwo wytłumaczyć ekonomicznie – licza˛ na to, że ktoś te bł˛edy poprawi, przez co
zwi˛ekszy si˛e użyteczność jaka˛ maja˛ z korzystania z oprogramowania. Czemu jednak wysyłaja˛
i publikuja˛ poprawki, nowe funkcjonalności, etc.? Autorzy analizujacy
˛ ruch oprogramowania o
otwartym źródle zwracaja˛ uwag˛e na kilka różnych przyczyn.
Zauważmy, że ludzie zajmujacy
˛ si˛e oprogramowaniem o otwartym źródle ponosza˛ koszt: zarówno koszt utraconych możliwości zużytego czasu na kodowanie, koszt zużycia komputera,
pradu,
˛
połaczeń
˛
komunikacyjnych, etc. Ponadto, programista rozwijajac
˛ oprogramowania o
otwartym źródle nie skupia si˛e w tym czasie nad głównym życiowym celem – kariera˛ zawodowa˛ czy akademicka.˛ Sa˛ to tzw. koszty przyszłe, wynikajace
˛ z opóźnienia realizacji swoich
celów.53
Podstawowa˛ przyczyna˛ jest rozwój oprogramowania dla własnej korzyści. Jak już zauważyliśmy wcześniej, prawie wszystkie projekty powstaja˛ jako zaspokojenie pewnych potrzeb autorów. Lerner i Tirole podaja˛54 cztery analizy przypadków bardzo udanych projektów: Apache,
Sendmail, Linux i Perl. Bodźcem we wszystkich przypadkach była jakaś osobista potrzeba.
Apache jest serwerem WWW.55 W 1994 roku najpopularniejszym produktem tego typu był
program National Center for Supercomputer Applications (NCSA). Kod źródłowy był rozpowszechniany za darmo. W NCSA istniała pewna grupa korespondujaca
˛ z użytkownikami, uwzgl˛edniajac
˛ poprawki i sugestie dotyczace
˛ oprogramowania. W pewnym momencie użytkownicy
zacz˛eli napotykać trudności w kontaktach z firma.˛ (Wtedy grupa programistów NCSA zajmujaca
˛ si˛e tym oprogramowaniem odłaczyła
˛
sie i założyła firm˛e Netscape.) Siedmiu administratorów sieciowych (w tym Brian Behlendorf) postanowiło wziać
˛ spraw˛e w swoje r˛ece,
gdyż do swojej pracy potrzebowali wysokiej jakości oprogramowania, zaspokajajace
˛ coraz bardziej rozbudowane potrzeby klientów administrowanych przez siebie serwisów internetowych.
Założyli pionierska˛ list˛e dyskusyjna˛56 na której duża liczba użytkowników może sugerować
zmiany/poprawki, ale tylko niewielka, zaufana grupa głównych programistów, może te zmiany
53
Ibid. s. 20.
Ibid. s. 12-19.
55
Serwer WWW to oprogramowanie umożliwiajace
˛ publikowanie stron WWW, czyli umożliwienie innym użyt54
kownikom sieci (Internetu) na ich czytanie.
56
ang. mailing list.
27
fizycznie umieszczać w kodzie. Grupa ta zebrała wszystkie istniejace
˛ łatki i wypuściła w 95 roku
Apache wersja 0.8. Głównym bodźcem do rozpocz˛ecia tego projektu był wi˛ec brak alternatyw.
Każdy z programistów zdawał sobie spraw˛e, że łatwiej uzyskać wysoka˛ jakość współpracujac
˛ z
innymi administratorami niż rozwijajac
˛ program samemu.
Linux jest najbardziej rozpowszechnionym systemem operacyjnym o otwartym źródle. Pierwsza wersja została stworzona przez Linusa Torvalds’a w 1991 roku jako praca dyplomowa (oparty
był na wcześniejszym darmowym systemie Minix). Wynikał raczej z ciekawości naukowej niż
bezpośredniej potrzeby. Linus opublikował swój projekt w Internecie zach˛ecajac
˛ innych użytkowników do współpracy, po czym zyskał on rzesze użytkowników.
Perl (Practical Extraction and Reporting Language) został stworzony przez Larry’ego Wall’a
w 1987 roku. Wall pracujac
˛ dla firmy Burroughs musiał wykonywać wiele rutynowych zadań
administracyjnych na komputerze. Zdał sobie spraw˛e, że działania te nadawały si˛e do zautomatyzowania – stworzył swój j˛ezyk skryptowy dedykowany specjalnie do tego celu, b˛edacy
˛
czymś pomi˛edzy j˛ezykiem C (j˛ezyk dedykowany do pisania oprogramowania) i j˛ezykiem skryptów Bash (przeznaczonym do automatyzacji prostych operacji dyskowych). Perl pozwalał dużo
szybciej pisać programy wykonujace
˛ zadania administracyjne, a jednocześnie miał dużo wi˛eksze
możliwości niż skrypty shell’owe w rodzaju Bash’a. Dziś jest to jeden z najcz˛eściej stosowanych
j˛ezyków tego typu, mi˛edzy innymi w Apache’u. Projekt powstał żeby zaspokoić potrzeby autora.
Sendmail został pierwotnie stworzony przez Eric’a Allman’a, studenta informatyki w Berkeley, w drugiej połowie lat 70-tych. Wtedy na tym uniwersytecie istniały dwie niezależne sieci
komputerowe – BerkNet oparta na komputerach uniksowych wewn˛etrzna sieć uniwersytecka,
oraz ArpaNet – przodek dzisiejszego Internetu. BerkNet opierała si˛e na protokole UUCP (Unixto-Unix Copy Protocol), zaś Arpanet na niekompatybilnym TCP/IP. Każdy student/pracownik
miał oddzielne konta pocztowe na każdej z tych podsieci i nie było możliwości przesyłania pomi˛edzy nimi wiadomości. Oprogramowanie Allman’a rozwiazywało
˛
problemy adresowania w
różnych sieciach(na poczatku
˛
program nazywał si˛e DeliverMail). Sendmail stał si˛e głównym
programem do przesyłania e-maili w Arpanecie.
Cz˛esto także już w fazie dojrzałej projektu główna˛ przyczyna˛ wkładu programistów jest korzyść własna. Programiści z głównej grupy czasem nie kwapia˛ si˛e do poprawienia zgłoszonego
bł˛edu czy napisania zasugerowanej funkcjonalności. Szeregowy programista, nie doczekawszy
si˛e łatki, może dojść do wniosku, że jego użyteczność z poprawki programu b˛edzie wi˛eksza niż
wysiłek potrzebny na jej dokonanie i samemu poprawić program. Czasem programiście (czy
całej firmie) bardziej opłaca si˛e dostosować wolne oprogramowanie do swoich potrzeb niż ku28
pić program komercyjny, szczególnie gdy takie gotowe rozwiazanie
˛
nie istnieje. Zauważmy,
że możliwość samodzielnego poprawiania czy dopasowywania programu jest cecha˛ charakterystyczna˛ tylko dla oprogramowania o otwartym źródle. Używajac
˛ programu komercyjnego nie
mamy dost˛epu do kodu źródłowego, czyli możliwości sensownej modyfikacji produktu.
Nie bez znaczenia jest także fakt, że programiści, w przeciwieństwie do pracy w firmie komercyjnej, sami moga˛ wybrać sobie kawałek kodu, który chca˛ rozwijać. Dzi˛eki temu moga˛
osiagać
˛
przyjemność z pracy nad wolnym oprogramowaniem (jak Linus Torvalds). Ponieważ
kod wolnego oprogramowania jest ogólnie dost˛epny, zaawansowani użytkownicy cz˛esto dyskutuja˛ konkretne rozwiazania,
˛
ew. je zmieniajac.
˛ Programista rozwijajac
˛ ciekawa˛ dla siebie cz˛eść
programu i analizujac
˛ przy okazji kod innego programisty, może si˛e wiele nauczyć. Istotna˛ zaleta˛
jest także fakt, że po napisaniu kawałka kodu oprogramowania o otwartym źródle, informatyk
może liczyć na twórcze i fachowe komentarze innych programistów (ang. peer review), co dodatkowo sprawia, że może wyeliminować swoje bł˛edy lub poznać jakieś inne spojrzenie na problem.
Jest to także sposób na pokazanie światu (kolegom, innym programistom, firmom komercyjnym)
swój kunszt i umiej˛etności. Taka możliwość nie istnieje w przypadku oprogramowania rozwijanego w przedsi˛ebiorstwach, które w programie umieszczaja˛ tylko informacje o firmie, w której
powstało oprogramowanie, a nie o poszczególnych programistach. Nawet gdyby było wiadomo,
kto pisał konkretny kawałek, nie można docenić do końca programisty bez zobaczenia jego kodu
źródłowego. Z kolei informacja o programistach rozwijajacych
˛
oprogramowanie jest integralna˛
cecha˛ oprogramowania o otwartym źródle – każdy fragment kodu źródłowego jest podpisany
imieniem i nazwiskiem oraz jest podany adres poczty elektronicznej, gdyby ktoś chciał zgłosić
uwag˛e czy zadać pytanie. Usuni˛ecie programisty z listy autorów wolnego programu jest jednym
z najgorszych przest˛epstw kulturowych w społeczności hakerów.57
Opierajac
˛ si˛e na ekonomii informacji, firmy komputerowe nie b˛eda˛ nigdy płaciły programistom zgodnie z ich produktywnościa.˛ Po pierwsze może nie być możliwe rozróżnienie dobrego
informatyka od złego (np. przy podpisywaniu kontraktu) – w takim przypadku firmy b˛eda˛ płaciły wszystkim średnia˛ stawk˛e, na czym dobrze wyjda˛ kiepscy specjaliści (b˛eda˛ otrzymywać
wynagrodzenie wyższe od swojej produktywności) kosztem tych lepszych. Co wi˛ecej, jeżeli nawet pracodawca jest w stanie rozróżnić pracowników, ale inni przedsi˛ebiorcy nie sa,˛ i tak b˛edzie
on przyznawał najlepszym jednostkom przeci˛etne wynagrodzenie. Gdyby wyróżnił tych pracowników, dałby sygnał konkurentom, że dany pracownik ma ponadnormalna˛ produktywność.
Konkurencja miałaby bodziec by danego pracownika podkupić i przedsi˛ebiorca straciłby swoja˛
57
Raymond, The Cathedral and the Bazaar.
29
rent˛e.58 W zwiazku
˛
z tym dobrzy programiści maja˛ motywacj˛e, by w jakiś sposób zasygnalizować na rynku pracy, że ich umiej˛etności przewyższaja˛ średnia.˛ Właśnie temu może służyć
aktywny udział w przedsi˛ewzi˛eciach tworzenia oprogramowania o otwartym źródle – tam kod
przez nich stworzony jest podpisany i powszechnie widoczny.
Istnieja˛ wi˛ec przyszłe korzyści z rozwijania wolnego oprogramowania – satysfakcja z szacunku innych programistów i użytkowników59 oraz zainteresowanie kariera˛60 . Sa˛ to dwa rozróżnialne bodźce, chociaż z ekonomicznego punktu widzenia jest to jeden bodziec – ch˛eć sygnalizacji otoczeniu swojego mistrzostwa61 .62 Rozumowanie to można poprzeć modelem ekonomicznym zaproponowanym przez Samuela Lee, Nin˛e Moisa i Marco Weiss’a63 . Autorzy przedstawiaja˛ model rynku pracy programistów. Zakładaja,˛ że istnieja˛ dwa rodzaje programistów – słabi
i fachowcy. Pokazuja,˛ że możliwa jest równowaga, w której firma i oprogramowanie o otwartym
źródle współistnieja.˛ Jeżeli sa˛ programiści dobrzy, którzy maja˛ motywacj˛e do zasygnalizowania
swoich umiej˛etności by otrzymywać wyższe przyszłe dochody niż bieżace
˛ w firmie, prawdopodobieństwo powstania projektu OSS jest dodatnie (projekt musi być wystarczajaco
˛ duży, by
zapewnić wiarygodność sygnału).
Analiz˛e empiryczna˛ znajdujemy w publikacji Hann’a et al.64 Autorzy analizuja˛ trzy główne
produkty rozwijane przez Apache Group: Apache, Jakarta i Mod_Perl. Projekty te zostały wybrane, ponieważ kwestie widoczności wkładu programisty w projekt sa˛ tam wyjatkowo
˛
mierzalne. Istnieje pi˛eć stopni wtajemniczenia: developer, committer, ASF member, project management committee member, ASF board member. Developer’em zostaje si˛e po przesłaniu pierwszej poprawki, a na wyższe poziomy przechodzi si˛e na zasadzie ścisłej merytokracji – gdy ktoś
cz˛esto przysyła wartościowe łatki, dopracowane technicznie i wnoszace
˛ coś nowego, przechodzi na wyższy poziom.65 Autorzy przeprowadzaja˛ analiz˛e wpływu reputacji, liczby zgłoszonych
poprawek, wykształcenia, doświadczenia zawodowego, etc. na wysokość pensji programisty
58
Stiglitz, Information and the change in the paradigm in economics.
ang. ego gratification incentive
60
ang. career concern incentive
61
ang. signaling incentive
62
Lerner i Tirole, The Simple Economics of Open Source s. 21.
63
Lee, Moisa i Weiss, Open Source as a Signalling Device – An Economic Analysis.
64
Hann et al., Delayed Returns to Open Source Participation: An Empirical Analysis of the Apache HTTP Server
59
Project
65
Eric Raymond zauważa w Raymond, Homeseading the Noosphere, że jest to cecha charakterystyczna dla całego ruchu OSS, a nie tylko projektu Apache. Tutaj jest to jednak bardziej widoczne dzi˛eki jasno zdefiniowanym
stopniom uczestników.
30
w kolejnym roku. Wyniki sa˛ bardzo ciekawe – liczba wysłanych patch’y jest nieznaczaca
˛ statystycznie dla wysokości pensji, za to fakt posiadania stopnia conajmniej Committer (zmienna
binarna) wpływa istotnie i pozytywnie na zmienna˛ endogeniczna˛ – programiści z wysokimi stopniami zarabiaja˛ statystycznie 29% wi˛ecej (Caeteris Paribus). Co ciekawe, w próbce nikt o randze
Committer lub wyższej nie miał doktoratu. Wśród programistów o randze powyżej Committer
nie znalazł si˛e żaden magister – wi˛ekszość z czołowych programistów, nie dysponuje tradycyjnymi sygnałami – dyplomami uniwersyteckimi. Wyniki te potwierdzaja˛ nasza˛ tez˛e – sygnał
(wysoka ranga) powoduje wyższe przychody dla programisty.
Warto zastanowić si˛e jeszcze, dlaczego programiści po napisaniu jakiejś poprawki decyduja˛
si˛e ja˛ opublikować. Oczywiście sygnalizowanie swoich umiej˛etności otoczeniu nast˛epuje dopiero po opublikowaniu swojego kodu, a nie tylko jego stworzeniu, tak wi˛ec powyższa analiza
ch˛eci sygnalizacji dotyczy także udost˛epnienie innym użytkownikom swojego kodu. Dlaczego
jednak użytkownicy, którzy stworzyli poprawk˛e „na własny użytek”, czyli czerpia˛ cała˛ użyteczność z samego faktu dokonania poprawki, mieliby ja˛ rozpowszechniać, a nie np. sprzedać czy
zachować w tajemnicy? Sama sprzedaż poprawki może być niemożliwa – ze wzgl˛edu na żywotność licencji (jeżeli jest rozpowszechniana, to tylko jako wolne oprogramowanie) czy faktu,
że firma, która zatrudnia programist˛e (zakładajac,
˛ że poprawka powstała w czasie jego pracy)
może mieć obiekcje co do sprzedaży przez niego kodu powstałego w ramach obowiazków
˛
służbowych.66 Co wi˛ecej wkłady poszczególnych programistów sa˛ na tyle małe, że koszt wyceny poprawki przewyższyłby prawdopodobnie jej wartość.67 Z drugiej strony, trzymanie poprawek dla
siebie jest cz˛esto mniej użyteczna˛ opcja˛ dla agenta. Skoro zajał
˛ si˛e on poprawianiem oprogramowania na użytek własny, możemy sadzić
˛
że jest on zainteresowany używaniem go i ściaganiem
˛
nowych oficjalnych wersji majacych
˛
wi˛eksza˛ funkcjonalność. Jeżeli koszt wynikajacy
˛ z tego,
że jacyś jego konkurencji b˛eda˛ mogli wykorzystać jego poprawk˛e (zwykle mały) jest mniejszy
niż koszt poprawiania każdej kolejnej nowej wersji programu (a nowe wersje wolnego oprogramowania pojawiaja˛ si˛e cz˛esto) to b˛edzie mu si˛e opłacało opublikować poprawk˛e, by została ona
dołaczona
˛
do oficjalnego źródła.68 W przypadku zachowania kodu dla siebie, istnieje niebezpieczeństwo, że jakiś inny agent dopisze ta˛ sama˛ funkcjonalność w sposób niekompatybilny – co
jeszcze zwi˛ekszy koszty zachowania kodu dla siebie.
66
Lerner i Tirole, The Simple Economics of Open Source s. 22.
Raymond, The Magic Cauldron s. 9.
68
Ibid. s. 10.
67
31
1.2.2. Motywacja firm
Naturalna˛ rzecza˛ jest, że ruchem wolnego oprogramowania interesuja˛ si˛e także przedsi˛ebiorstwa.
Moga˛ one starać si˛e na nim zarobić na dwa sposoby. Po pierwsze oprogramowanie o otwartym
źródle wypracowało zupełnie nowy proces tworzenia oprogramowania (analiza nastapi
˛ w dalszej
cz˛eści pracy) i firmy komercyjne próbuja˛ go kopiować by poprawić jakość czy zmniejszyć koszt
wytwarzanych przez siebie produktów. Nie moga˛ jednak w pełni zaimplementować pewnych
mechanizmów jak darmowe szkolenie programistów na uczelniach i produkowanie przez użytkowników wartościowych poprawek, gdyż to oznaczałoby konieczność otwarcia kodu źródłowego. Cz˛esto nie opłaca im si˛e informować publicznie o dokonaniach poszczególnych programistów, gdyż istnieje zagrożenie, że ci najlepsi zostaliby podkupieni przez konkurencj˛e. Próbuja˛
za to implementować współdzielenie kodu w obr˛ebie przedsi˛ebiorstwa i w miar˛e możliwości
pozostawiać pracownikom wybór zadań, którymi maja˛ si˛e zajmować.69
Z drugiej strony obserwujemy rosnace
˛ zainteresowanie firm produktami komplementarnymi
do wolnego oprogramowania. Powstaja˛ nowe, wyspecjalizowane firmy jak RedHat, zajmujace
˛
si˛e tworzeniem dystrybucji Linuksa.70 RedHat oferuje także kompleksowe usługi serwisowe,
infolini˛e (24 godziny na dob˛e), swój produkt sprzedaje nagrany na kompakty z dołaczon
˛
a˛ drukowana˛ instrukcja.˛ Dodatkowo zajmuje si˛e konsultingiem i przygotowaniem indywidualnych
rozwiazań
˛
software’owych dla firm. Sa˛ to wszystko usługi charakterystyczne dla (komercyjnego) rynku oprogramowania, a zupełnie nie oferowane przez społeczności programistów. Niektóre podmioty, jak firmy komputerowe, uzależniaja˛ swoja˛ decyzj˛e instalacji (kupna) systemu
od takich usług. Widać wi˛ec wyraźna˛ nisz˛e – RedHat jest w stanie oferować pełne rozwiaza˛
nia informatyczne taniej niż konkurencja, gdyż nie ponosi kosztów tworzenia oprogramowania.
Nasza˛ analiz˛e potwierdza pozycja tej firmy na giełdzie NASDAQ.
Podobnym przykładem jest firma Collab.Net, przygotowujaca
˛ kompleksowe systemy dla
przedsi˛ebiorstw oparte na wolnym oprogramowaniu, certyfikujaca
˛ to oprogramowanie i gwarantujaca
˛ jego niezawodność, oferujaca
˛ kompleksowa˛ pomoc techniczna,˛ etc. Taka certyfikacja
69
70
Lerner i Tirole, The Simple Economics of Open Source s. 33-34.
Dystrybucja to zbiór dużej liczby darmowego oprogramowania o otwartym źródle, specjalnie przygotowany do
łatwej instalacji, który spełnia wi˛ekszość potrzeb użytkownika bez potrzeby samodzielnego wyszukiwania projektów. Nazwa „Linux” jest w tym przypadku bł˛edna – oznacza ona tylko jadro
˛ tego systemu operacyjnego, czyli szkielet pozwalajacy
˛ wykonywać si˛e innym programom, bez oprogramowania pomocniczego absolutnie bezużyteczny.
System Operacyjny jako całość powinno si˛e nazywać GNU/Linux, gdyż GNU stworzyła wi˛ekszość wspomnianych
programów narz˛edziowych.
32
niezawodności oprogramowania jest bardzo ważna dla niektórych podmiotów gospodarczych, a
nieformalna grupa programistów oprogramowania o otwartym źródle nie może jej oczywiście
zapewnić.71
Kolejna˛ możliwościa˛ jest sprzedaż sprz˛etu zoptymalizowanego do użycia z systemem operacyjnym GNU/Linux – tym zajmowała si˛e firma VA Linux. Dziś oprogramowanie o otwartym źródle jest na tyle popularne, że wszystkie wi˛eksze firmy produkujace
˛ sprz˛et jak HP, Compaq, IBM oferuja˛ komputery z zainstalowanym GNU/Linux, w zwiazku
˛
z czym VA Linux si˛e
przekwalifikowała – prowadzi najwi˛ekszy portal internetowy wolego oprogramowania SourgeForge.net, oferujacy
˛ projektom wolnego oprogramowania (za darmo) miejsce na serwerze i różne
usługo sieciowe jak np. system rejestracji bł˛edów, CVS72 , list dyskusyjnych, stron WWW, etc.
Pieniadze
˛
zarabia oferujac
˛ podobne usługi firmom.
Cz˛esto podkreślanym zjawiskiem jest fakt, że programiści nie lubia˛ pisać dokumentacji do
projektów, szczególnie skierowanej do poczatkuj
˛ acych
˛
użytkowników. Fakt ten wykorzystało
wydawnictwo O’Reilly & Associates, skupiajac
˛ si˛e na wydawaniu pozycji poświ˛econych wolnemu oprogramowaniu.73
Co ciekawe, zauważalne jest także zainteresowanie oprogramowaniem o otwartym źródle
wśród istniejacych
˛
firm na rynku – w tym gigantów o stabilnej pozycji jak IBM czy Novell.
Bardzo wiele firm decyduje si˛e na wypuszczenie swoich produktów skompilowanych dla Linuxa
– ale cz˛eść z nich decyduje si˛e wypuścić swój produkt na licencji oprogramowania o otwartym
źródle, czyli opublikować jego kod źródłowy. Przykładem firmy stawiajacej
˛ na wolne oprogramowanie jako platform˛e jest Oracle – planuje ona przyjać
˛ Linuxa jako podstawowy system
operacyjny dla swojej bazy danych. Główna˛ przyczyna˛ jest ch˛eć uniezależnienia swojej strategii biznesowej od firmy Sun Microsystems, producenta unixa Solaris, poprzedniej platformy
programowej. Dzi˛eki temu może oferować tańsze systemy kompleksowe, oparte na klastrach
PC’tów zamiast drogich serwerów Sun’a i systemie operacyjnym Linux.
Wypuszczenie kodu źródłowego na licencji oprogramowania o otwartym źródle może być
bardzo ważnym posuni˛eciem strategicznym. Łatwo pokazać, że producenci sprz˛etu komputerowego zyskaja,˛ gdy spadnie cena dobra komplementarnego, jakim jest oprogramowanie, a szczególnie system operacyjny. Dla wi˛ekszości korporacji produkujacych
˛
przemysłowe komputery74
71
72
Ibid. s. 35-36.
Concurrent Versioning System – system archiwizowania i tworzenia różnych wersji dokumentów (także kodu
źródłowego programów)
73
Raymond, The Magic Cauldron.
74
Czyli „wi˛eksze” od popularnych komputerów osobistych.
33
tworzenie systemu operacyjnego jest tylko niezb˛ednym kosztem, bo zwykle na nim nie zarabiaja.˛ 75 Na przykład firma Sun Microsystems, produkujaca
˛ serwery i stacje robocze, rozdaje za
darmo najnowsze wersje swojego oprogramowania każdemu posiadaczowi komputera ich produkcji76 . Hewlett Packard zdecydował si˛e wypuścić jako wolne oprogramowanie swój Spectrum
Object Model Linker, by ułatwić przystosowanie Linuxa do architektury RISC’owej komputerów
tej firmy. Analogicznie Sun Microsystems pomagał w dostosowaniu Linuxa do swoich procesorów. Dzi˛eki tym zabiegom w przyszłości przedsi˛ebiorstwa te b˛eda˛ mogły rozważyć zupełne
odejście od rozwijania własnych systemów operacyjnych, a dziś umożliwiły administratorom
zainstalowanie dokładnie tych samych programów na ich serwerach i popularnych oraz tanich
PC.
Nawet Intel, czyli producent podzespołów do najpopularniejszych na świecie PC’tów, zyska
gdy wolne oprogramowanie odbije Microsoftowi cz˛eść rynku. Końcowy użytkownik, gdy b˛edzie
potrzebował komputer, nie b˛edzie musiał płacić Microsoftowi za system operacyjny, w zwiazku
˛
z tym sumaryczna cena funkcjonalnego komputera widziana przez użytkownika b˛edzie niższa.77
Co ciekawe, specjalnie opracowana wersja Linuxa (embedded Linux) jest także coraz szerzej stosowana w małych urzadzeniach
˛
elektronicznych jak telefony komórkowe czy podr˛eczne
komputerki(ang. PDA – Pesonal Digital Assistant). Przykłady można znaleźć na stronie internetowej http://www.linuxdevices.com/. Motyw tego działania jest analogiczny – taniej
jest dostosować istniejacy
˛ system do konkretnego urzadzenia
˛
i zastosowania, zyskujac
˛ dodatkowo kompatybilność z innymi urzadzeniami
˛
(w tym z komputerami) niż tworzyć go od nowa.
Użytkownik i tak nie płaci dodatkowo za system operacyjny, kupuje działajace
˛ urzadzenie.
˛
Jedna˛ z głównych zalet procesu powstawania oprogramowania o otwartym źródle dla przedsi˛ebiorstw, poza stosunkowo niska˛ liczba˛ bł˛edów (analiza jakości wolnego oprogramowania b˛edzie w dalszej cz˛eści pracy), jest fakt, że bardzo duża˛ cz˛eść pracy zwiazan
˛ a˛ z produkcja˛ oprogramowania przejmuja˛ użytkownicy, co zmniejsza koszty firmy. Najlepszym przykładem jest firma
Apple, która właśnie w celu zmniejszenia kosztów rozwoju oprogramowania udost˛epniła jadro
˛
swojego systemu operacyjnego MacOS X.
Z kolei firma Netscape zdecydowała si˛e otworzyć źródła swojej przegladarki
˛
internetowej
Netscape Navigator w obliczu konkurencji Internet Explorera Microsoftu. Pod koniec lat 9075
76
Koek, Free Software Licensing.
Problemy z piractwem czy free-riding’iem tutaj nie wyst˛epuja,˛ gdyż oprogramowanie to działa wyłacznie
˛
na
tych komputerach.
77
Lerner i Tirole, The Simple Economics of Open Source.
34
tych Internet Explorer zaczał
˛ dominować na rynku i wydawało si˛e, że upadek Navigatora jest
nieunikniony. Był to jedyny liczacy
˛ si˛e konkurent Microsoftu w segmencie komputerów PC, co
mogłoby spowodować przej˛ecie przez Microsoft kontroli nad j˛ezykiem HTML. Jest to tym groźniejsze dla konkurentów tej firmy, że Microsoft zwykł nie publikować cz˛eści kontrolowanych
przez siebie protokołów oraz modyfikować standardy tak, by jak najbardziej były niekompatybilne z produktami konkurencji78 . Netscape zaś produkuje serwer WWW (oprogramowanie
pozwalajace
˛ udost˛epniać użytkownikom sieci stron WWW – a wi˛ec komplementarne do przegladarek),
˛
który stałby si˛e zupełnie niekompatybilny z istniejacymi
˛
przegladarkami
˛
(czyli Internet Explorerem). Decyzja o wypuszczeniu Navigatora na licencji oprogramowania o otwartym
źródle okazała si˛e słuszna – po poczatkowych
˛
problemach wynikajacych
˛
z małej modularności
kodu i braku niektórych fragmentów, do których Netscape nie miał praw – projekt spotkał si˛e odzewem społeczności hakerów i rozwija si˛e bardzo dynamicznie.79 Co wi˛ecej, Netscape zostawił
sobie „furtk˛e” do wykorzystania kodu stworzonego przez społeczność programistów w swoim
programie Navigator – licencja jest żywotna, ale zawiera zapis, że Netscape może wykorzystać
kod do celów komercyjnych. Wywoływało to spore kontrowersje, ale licencja została uznana za
„wolna”
˛ przez Free Software Foundation i „open source” przez Open Source Initiative.80
Sporo programów jest na tzw. podwójnej licencji (patrz rozdział 1.1) – firmy rozdaja˛ wtedy
oprogramowanie ludziom, którzy chca˛ zrobić z niego oprogramowanie o otwartym źródle, zaś
licencje musza˛ wykupić firmy chcace
˛ zawrzeć te projekty w swoich komercyjnych systemach o
zamkni˛etym źródle. Przykładem jest Aladdin Enterprises, produkujaca
˛ Ghostscript (narz˛edzie
do wydruków oparte o standard PostScript), firma Trolltech z Norwegii produkuje wieloplatformowa˛ (UNIX, Windows, MacOS) bibliotek˛e graficzna˛ Qt81 , używana˛ w jednym z bardziej popularnych wolnych środowisk graficznych KDE, czy MySQL ze swoja˛ baza˛ danych. Z podwójnym
licencjonowaniem sa˛ jednak zwiazane
˛
pewne problemy prawne, zarysowane w rozdziale o licencjach (1.1).
78
Sa˛ to działania majace
˛ zapewnić firmie pozycj˛e monopolistyczna˛ na rynku. Dodatkowo Microsoft dodaje „gra-
tisowo” do swojego systemu operacyjnego Windows programy obsługujace
˛ te protokoły i formaty jak przegladark˛
˛
e
Internet Explorer czy Windows Media Player, przez co staja˛ si˛e one de facto obowiazuj
˛ acymi
˛
standardami (Windows ma ponad 90% udział w rynku systemów operacyjnych komputerów osobistych). Tocza˛ si˛e o to procesy
antymonopolistyczne przeciwko firmie zarówno w Stanach Zjednoczonych, jak i ostatnio w Europie, ale nie sa˛ one
w stanie skutecznie powstrzymać monopolisty.
79
Dziś nazywa si˛e Mozilla: http://www.mozilla.org. Szczegóły dotyczace
˛ licencji sa˛ opisane w rozdziale 1.1
80
Koek, Free Software Licensing.
81
http://www.trolltech.no
35
Kolejnym rozwiazaniem
˛
strategicznym jest stworzenie pewnego standardu, wypuszczenie go
razem z podstawowym oprogramowaniem jako oprogramowanie o otwartym źródle, zaś zarabianie na bardziej zaawansowanych czy wr˛ecz indywidualnie dostosowanych projektach. Przykładem może być Jabber82 , protokół i zestaw narz˛edzi do komunikacji sieciowej w czasie rzeczywistym. Ze strony projektu można pobrać oprogramowanie na licencji wolnego oprogramowania.
Jednym z głównych sponsorów projektu jest Jabber Inc.83 , firma oferujaca
˛ przemysłowe systemy
przesyłania wiadomości (ang. instant messaging systems) oparte na otwartej technologii Jabber.
Eric Raymond zauważa, że oprogramowanie komercyjne przynosi firmie zyski tylko w poczatkowej
˛
fazie cyklu rozwoju, gdy jest nowatorskie i konsumenci je kupuja.˛ Potem jednak
powstaja˛ nowe, lepsze produkty i konsumenci nie maja˛ motywacji do kupowania przestarzałej
wersji. Cz˛eść konsumentów jednak, która już wcześniej kupiła program i si˛e do niego przyzwyczaiła, nie chce go zmieniać. Tej grupie trzeba zapewnić piel˛egnacj˛e oprogramowania (ang.
maintenance), czyli poprawiać bł˛edy i uaktualniać informacje (np. dodać obsług˛e nowych urza˛
dzeń, uwzgl˛ednić zmiany legislacyjne, etc.). W pewnym momencie staje si˛e to tylko kosztem
dla firmy, gdyż tego oprogramowania już nie sprzedaje, ale kosztem koniecznym, gdyż nikt nie
kupi nowego oprogramowania od firmy, która nie dba o swoich klientów. W tej ostatniej fazie
powstaje naturalna motywacja do wypuszczenia oprogramowania na licencji oprogramowania o
otwartym źródle i stworzenia społeczności zajmujacej
˛ si˛e dalej projektem. Tak postapiła
˛
firma
IdSoftware z gra˛ Doom. W 1993, gdy gra ta została wypuszczona na rynek, była absolutnie
nowatorska, wyprzedzała o ponad rok wszystkich konkurentów, zyskała wielu zwolenników. Z
biegiem czasu powstawały jednak nowe rozwiazania
˛
– sama firma IdSoftware zacz˛eła tworzyć
nowsza˛ gr˛e tego samego typu: Quake. W 1997 roku podj˛eła decyzj˛e o opublikowaniu kodu źródłowego Doom’a. Firma nic nie straciła, gdyż algorytmy wykorzystane w grze stały si˛e wtedy
praktycznie wiedza˛ ogólna.˛ Użytkownicy od razu zacz˛eli poprawiać gr˛e, a firma mogła si˛e skupić na nowej. Dodatkowo taki krok robi reklam˛e firmie i zach˛eca użytkowników, którzy ściagn
˛ a˛
stara˛ gr˛e i im si˛e spodoba, do kupienia nowszego odpowiednika. Warto jednak zauważyć, że
społeczność hakerów zwykle zajmuje si˛e tylko jednym programem danego typu, zaś programy
staja˛ si˛e przestarzałe stopniowo, a nie natychmiast. Pozostaje wi˛ec problem decyzji kiedy opublikować kod, by nie stracić za dużo swojej renty twórcy, a jednocześnie nie zostać ubiegni˛etym
przez konkurencj˛e.
Oczywiście firmy moga˛ si˛e stać użytkownikami oprogramowania o otwartym źródle – gdy
82
83
http://www.jabber.org
http://www.jabber.com
36
okaże si˛e ono bardziej konkurencyjne niż komercyjne. Moga˛ wtedy analogicznie jak zwykli
użytkownicy wprowadzać modyfikacje i dodawać je do ogólnego kodu. Przedsi˛ebiorstwa nie
maja˛ motywacji wynikajacych
˛
z ch˛eci sygnalizowania, ale za to sami programiści pracujacy
˛ dla
tych przedsi˛ebiorstw maja˛ takie bodźce.
Bardzo ważnym argumentem dla przedsi˛ebiorstw jest fakt, że korzystajac
˛ z oprogramowania
o otwartym źródle uniezależniaja˛ si˛e od producenta oprogramowania. Ponieważ kod źródłowy
jest dost˛epny, każdy może si˛e zajać
˛ dalszym rozwojem systemu. Kupienie rozwiazania
˛
o zamkni˛etym źródle powoduje, że nasza firma musi polegać na jego producencie, co powoduje
powstanie kosztów transakcyjnych. Oprogramowanie o zamkni˛etym źródle staje si˛e bardzo specyficznym aktywem, zależnym od konkretnego dostawcy. Cz˛esto, ze wzgl˛edu na zbyt wysokie
koszty, nie jest możliwa pionowa integracja (czyli wytworzenie oprogramowania wewnatrz
˛ korporacji) – dostawca usług informatycznych rozkłada koszt stworzenia oprogramowania na wiele
transakcji z różnymi podmiotami. Natomiast gdy źródła oprogramowania sa˛ otwarte, nie istnieje
ta bariera wejścia dla innych firm informatycznych, koszty transakcyjne sa˛ dużo niższe.84
Powyższy argument jest szczególnie ważny, gdy dane oprogramowanie jest kluczowe dla
działalności firmy lub gdy posiada ono duże efekty sieciowe (zewn˛etrzne) – np. ustanawia standard uniwersalnej struktury komunikacyjnej. W obu tych przypadkach ryzyko zwiazane
˛
z nieuczciwa˛ postawa˛ dostawcy usług jest duże – koszty byłyby ogromne.
Ciekawym przykładem jest wspominany już wielokrotnie serwer WWW Apache. Wiele firm
internetowych, dla których program ten jest kluczowym aktywem w działalności, wyliczyło,
że bardziej opłaca im si˛e dostosować Apache’a do swoich konkretnych potrzeb i podzielić si˛e
poprawkami cz˛esto z bezpośrednimi konkurentami, niż kupować rozwiazanie
˛
komercyjne czy
pisać osobny system tylko na użytek własny. Współpraca (nieformalna) z innymi podmiotami
miała na celu rozłożenie kosztów tworzenia programu na wiele firm.
1.2.3. Proces powstawania
W tym podrozdziale chciałbym przyjrzeć si˛e bliżej samemu procesowi powstawania wolnego
oprogramowania. W poprzednich dwóch podrozdziałach starałem si˛e udowodnić, że zarówno
prywatni użytkownicy jak i firmy maja˛ motywacj˛e do korzystania i rozwijania oprogramowania
o otwartym źródle. Jak to jest jednak możliwe, że małe poprawki wielu różnych, niezależnych
podmiotów da si˛e połaczyć
˛
w jedna˛ działajac
˛ a˛ całość?
84
Raymond, The Magic Cauldron.
37
Zajmiemy si˛e tutaj analiza˛ jedynie projektów w fazie dojrzałej, czyli na tyle rozwini˛etymi, że
motywacje programistów zaczynaja˛ „działać”. Wcześniej oprogramowanie musi być rozwini˛ete
w domu przez grup˛e hobbystów badź
˛ w firmie (jak Netscape Navigator). Proces powstawania
oprogramowania komercyjnego został już dobrze opisany w literaturze (najbardziej obrazowa
pozycja to według mnie Brooks, Mityczny osobomiesiac)
˛ i nie b˛ed˛e si˛e tym gł˛ebiej zajmował w
tej pracy. Za to wolne oprogramowanie jest nowym fenomenem, nie mieszczacym
˛
si˛e w ramach
istniejacej
˛ Inżynierii Oprogramowania i na tym fenomenie skupi˛e si˛e w tym rozdziale.
Jeszcze kilkanaście lat temu nikt nie przypuszczał, by oprogramowanie, które nie powstało w
dużym przedsi˛ebiorstwie, zgodnie z bardzo sformalizowanymi procedurami (opisanymi miedzy
innymi przez Brooksa85 ), osiagn˛
˛ eło na tyle duża˛ jakość, by ktokolwiek zdecydował si˛e go użyć
do celów innych niż zabawa. Dziś serwer WWW Apache używany jest na prawie 70% serwerów
internetowych86 , czyli na dużo wi˛ekszej liczbie niż jakiekolwiek rozwiazanie
˛
komercyjne. Z
systemu operacyjnego Linux korzysta mi˛edzy innymi najcz˛eściej wykorzystywana na świecie
przegladarka
˛
internetowa Google87 , polski portal internetowy Onet88 czy polskie Ministerstwo
Gospodarki, Pracy i Polityki Społecznej89 .
Jak już wcześniej zarysowałem, aby oprogramowanie po fazie wst˛epnej miało szans˛e zyskać
zainteresowanie hakerów, musi spełniać pewne kryteria. Po pierwsze, musi być funkcjonalne,
musi si˛e dać je uruchomić i zobaczyć, że coś robi. Po drugie, hakerzy musza˛ być przekonani,
że robi ono coś przydatnego. Najlepiej, żeby nie duplikował funkcjonalności jakiegoś już istniejacego
˛
projektu oprogramowanie o otwartym źródle – bo po co rozwijać równolegle dwa takie
same projekty. Jak już napisałem, rozwój wolego oprogramowania nast˛epuje w „bazarowym”
stylu – ludzie tworza˛ i wymieniaja˛ mi˛edzy soba˛ poprawki, uwagi, łatki, itd. Żeby to było możliwe, musi istnieć możliwość tworzenia bardzo małych kawałków które si˛e wymienia, tak żeby
minimalnie si˛e na siebie nakładały. Autorzy podkreślaja,˛ że jedna˛ z kluczowych cech wolnego
oprogramowania jest modularność jego budowy – czyli podział hierarchiczny kodu na kawałki
majace
˛ precyzyjnie zdefiniowana˛ funkcjonalność. Jest to trudny do uzyskania efekt, ponieważ
w dużych projektach informatycznych ten hierarchiczny podział jest zwykle niejednoznaczny i
nieewidentny oraz pomi˛edzy poszczególnymi funkcjonalnościami istnieja˛ nietrywialne zwiazki.
˛
W firmach komputerowych powstaja˛ zwykle niemodularne programy – tworzy si˛e od razu cała˛
85
Brooks, Mityczny osobomiesiac.
˛
Netcraft, Web Server Survey.
87
http://www.google.com
88
http://www.onet.pl
89
www.mpips.gov.pl
86
38
kolumn˛e katedry, a nie pojedyncza˛ cegiełk˛e nadajac
˛ a˛ si˛e do wymiany na bazarze. Różnic˛e t˛e
obrazuje przypadek firmy Netscape: pierwsza publikacja kodu jej przegladarki
˛
internetowej Navigator zakończyła si˛e fiaskiem. Główna˛ przyczyna,˛ poza brakiem pewnych fragmentów kodu,
był brak modularności – niemożność napisania sensownej poprawki, zmieniajacej
˛ lokalnie kod.
Dopiero gdy Netscape dopisał brakujace
˛ fragmenty i podzielił kod na moduły, projekt si˛e rozwinał.
˛ 90
Charakterystyczna˛ cecha˛ bazarowego stylu jest brak formalnych powiazań
˛
mi˛edzy pracujacymi
˛
równolegle programistami. Brooks podkreślał, że jest to główny problem dla rozwoju
oprogramowania w firmach – w projektach gdzie wyst˛epuje dużo zależności pomi˛edzy różnymi
składnikami systemu (czyli we wszystkich dużych) to właśnie konieczność uzgodnienia protokołu na „styku” fragmentów pisanych przez różnych programistów staje si˛e głównym obciaże˛
niem dla dużych projektów.91 W przypadku wolnego oprogramowania ten problem nie istnieje –
programiści komunikuja˛ si˛e ze soba˛ nieformalnie, wymieniaja˛ spostrzeżenia, ale rzadko ustalane
sa˛ sztywne normy. Poszczególne łatki zbierane sa˛ w jedna˛ całość przez Lidera projektu. Projekty
wolnego oprogramowania utrzymywane sa˛ cały czas w stanie „działajacym”
˛
(chociaż oczywiście zawieraja˛ cz˛esto bł˛edy). Głównym obciażeniem
˛
dla oprogramowania o otwartym źródle jest
z jednej strony free-riding (zaraz wrócimy) a z drugiej dublujaca
˛ si˛e i niekompatybilna ze soba˛
praca. Żeby zmniejszyć negatywny efekt drugiego zjawiska, liderzy projektów prowadza˛ polityk˛e „wypuszczaj szybko (prawie bez testów) i cz˛esto (nawet kilka razy dziennie)”. Dzi˛eki temu
programiści moga˛ si˛e od razu zorientować, że ich praca została już wykonana, albo że łatka która˛
pisza˛ jest niekompatybilna z nowa˛ wersja˛ programu. W trosce o niezawodność oprogramowania
Linus Torvalds wprowadził dwa rodzaje wydań: stabilne, zawierajace
˛ sprawdzone rozwiaza˛
nia, i testowe, zawierajace
˛ najnowsze pomysły, które przechodza˛ potem do wersji stabilnej.92
Osoby potrzebujace
˛ oprogramowanie godne zaufania(np. na serwer) wybieraja˛ wersj˛e stabilna,˛
zaś chcacy
˛ wykorzystać najnowsze nowinki techniczne wersje testowa.˛ 93 Te różnice pomi˛edzy
oprogramowaniem wolnym a komercyjnym postaram si˛e uchwycić analitycznie w rozdziale (2).
Raymond argumentuje, że przy powyższych założeniach odnośnie projektów, można zrównoleglić proces debugowania (wyszukiwania i poprawiania bł˛edów). Dzi˛eki temu, że kod źródłowy jest otwarty i wszystkie poprawki sa˛ szybko wprowadzane do oficjalnej wersji, projekt po90
Raymond, The Cathedral and the Bazaar.
Brooks, Mityczny osobomiesiac.
˛
92
W rzeczywistości może istnieć jeszcze wi˛ecej wydań, np. dystrybucja Debian ma :stable, testing, unstable i
91
experimental.
93
Raymond, The Cathedral and the Bazaar.
39
siada bardzo duża˛ baz˛e testerów (użytkowników) oprogramowania. Użytkownicy ci, dzi˛eki dost˛epowi do kodu, moga˛ dużo precyzyjniej wytropić bład
˛ lub wr˛ecz go poprawić, co jest zupełnie
niedost˛epne dla projektów komercyjnych. Co wi˛ecej, w przypadku oprogramowania o zamkni˛etym źródle, najlepszych programistów przypisuje si˛e zwykle do samego planowania programu,
a testowanie i poprawianie bł˛edów wykonuja˛ osoby o niższych wynagrodzeniach. W wolnym
oprogramowaniu także najlepsi programiści sa˛ testerami i moga˛ dokonać poprawek, zauważajac
˛
cz˛esto nieoczywiste bł˛edy czy możliwości rozwoju. Poza tym grupa użytkowników/testerów jest
bardzo duża i w zwiazku
˛
z tym działa tzw. mechanizm Delphi – jeżeli jakoś bład
˛ jest wyjatkowo
˛
trudny do odszukania, to w dużej grupie ludzi z wi˛ekszym prawdopodobieństwem znajdzie si˛e
osoba, dla której jest on oczywisty.94
Istotnym problemem wolnego oprogramowania jest tzw. free riding. Zwykły użytkownik
zdaje sobie spraw˛e, że poprawianie przez niego programu stanowi koszt. Zawsze istnieje niezerowe prawdopodobieństwo, że jakaś inna osoba zdecyduje si˛e poprawić ten sam bład
˛ i dopisać
t˛e sama˛ funkcjonalność. Problem ten dotyczy również firm jako użytkowników oprogramowania. W wyniku poprawek b˛edzie mniej niż potencjalnych programistów. Dogł˛ebna˛ analiz˛e tego
zjawiska znajdziemy w Johnson, Economics of Open Source Software. Autor przedstawia model rozwoju wolnego oprogramowania. Rozpatruje zbiór egoistycznych agentów rozpatrujacych
˛
dokonanie poprawki w programie. Agenci sa˛ heterogeniczni. Każdego agenta charakteryzuja˛
dwa parametry – użyteczność z wykorzystania poprawki vi oraz koszt dokonania przez niego
tej poprawki ci . Agent zna tylko swoje wartości parametrów oraz rozkład parametrów w całej społeczności. Rozwiazaniem
˛
modelu jest równowaga Bayes’a-Nash’a, czyli dla każdego
agenta i para (ψ i , π i ), gdzie ψ i oznacza prawdopodobieństwo, że agent zdecyduje si˛e napisać
poprawk˛e, zaś π i – oczekiwane przez agenta i prawdopodobieństwo, że jakiś inny agent stworzy
dana˛ poprawk˛e. W równowadze każdy agent maksymalizuje swoja˛ oczekiwana˛ użyteczność,
przy założeniu racjonalnych oczekiwań, czyli że wartości π i sa˛ równe odpowiednim prawdopodobieństwom. Rozpatrywane sa˛ tylko równowagi symetryczne. Autor udowodnił, że przy
powyższych założeniach (zgodnie z intuicja),
˛ wszyscy hakerzy maja˛ wi˛eksza˛ użyteczność gdy
ich liczba (pracujacych
˛
nad projektem) si˛e zwi˛ekszy. Analogicznie wzrasta społeczny dobrobyt (ang. social welfare). Autor pokazuje, że oczekiwana liczba wyprodukowanych niezależnie
fragmentów kodu, b˛edacych
˛
ta˛ sama˛ poprawka,˛ zbiega przy liczbie hakerów daż
˛ acej
˛ do nieskończoności, do pewnej stałej (tak wi˛ec koszt pokrywajacej
˛ si˛e pracy jest ograniczony). Dalej, przy
założeniu, że jest wiele poprawek (k) robionych w sposób modularny, prawdopodobieństwo, że
94
Raymond, The Cathedral and the Bazaar.
40
wynikowe oprogramowanie b˛edzie zawierało wszystkie możliwe funkcjonalności, wynosi zero
– nawet przy liczbie programistów daż
˛ acej
˛ do nieskończoności. Autor słusznie zauważa, że
przy rozsadnych
˛
założeniach firma komercyjna majac
˛ nieskończona˛ liczb˛e klientów stworzyłaby wszystkie funkcjonalności.95 Analiza tego problemu znajduje si˛e także w moim modelu w
rozdziale 2 – przy nieco innych założeniach, ale uzyskuj˛e zbliżone wnioski.
Yochai Benkler uważa nawet, że peer production jest trzecia˛ forma˛ produkcji, obok firmy
i rynku. Ronald Coase w 1937 roku wprowadził podział na dwie formy produkcji: firm˛e, zatrudniajac
˛ a˛ pracowników i koordynujac
˛ a˛ ich działania poprzez hierarchi˛e zarzadcz
˛ a˛ oraz rynek,
koordynowany poprzez mechanizm cen. Z kryterium maksymalizacji zysku (w tym przypadku
konkretnie minimalizacji kosztów) wynika optymalna wielkość firmy – im firma jest wi˛eksza,
tym wi˛eksze sa˛ narzuty na biurokracj˛e i menadżerów. Na rynku z kolei wyst˛epuja˛ koszty transakcyjne, które moga˛ być zinternalizowane przez firm˛e poprzez połaczenie
˛
dwóch podmiotów.96
Benkler zauważa natomiast, że proces tworzenia wolnego oprogramowania97 ma odmienna˛ charakterystyk˛e od dwóch poprzednich. Nie wyst˛epuje tutaj hierarchia (każdy programista decyduje
si˛e wysłać łatk˛e z własnej woli, sam także wybiera fragment którym chce si˛e zajmować). Istnieja˛ liderzy projektów, jednak nie maja˛ oni bezpośredniej władzy nad programistami, moga˛
tylko przyjmować badź
˛ odrzucać poszczególne poprawki. Z drugiej strony pełnia˛ oni pewna˛
funkcj˛e społeczna˛ – sa˛ nieformalnie wybierani przez społeczność na zasadzie merytokracji. Gdy
nie kieruja˛ projektem zgodnie z zasadami merytorycznej doskonałości, projekt ma duże szanse
si˛e rozwidlić i straca˛ oni swoja˛ funkcj˛e. Wymiana łatek nie opiera si˛e także na mechanizmie cen.
Eric Raymond pisze, że siła˛ motywujac
˛ a˛ programistów jest ich ch˛eć dawania innym wartościowych podarunków (programów), zaspokojenie potrzeb znajdujacych
˛
si˛e najwyżej w piramidzie
Maslow’a.98 Żeby projekt miał szans˛e powstać w ten sposób, musza˛ być spełnione pewne założenia, o których już pisałem: program musi mieć budow˛e modularna˛ i koszty kopiowania
wyniku musza˛ być prawie zerowe (nie powstanie w ten sposób na pewno żadne materialne dobro konsumpcyjne).99 Kwestia, czy rzeczywiście da si˛e ten fenomen nazwać forma˛ produkcji,
jest kontrowersyjna. Z jednej strony widzimy oprogramowanie stworzone przez społeczności
hakerów, widzimy, że wielkie korporacje inwestuja˛ w ten ruch liczac
˛ na uzyskanie oprogramo95
ibid.
Coase, The Nature of the Firm.
97
Benkler rozpatruje szersza˛ grup˛e produktów, bardzo jednak zbliżonych do wolnego oprogramowania, jak np.
96
powstawanie internetowej encyklopedii WikiPedia (http://www.wikipedia.org).
98
Raymond, Homeseading the Noosphere.
99
Benkler, Coase’e Penguin, or, Linux and The Nature of the Firm.
41
wania bardziej efektywnie niż tradycyjnymi metodami. Z drugiej jednak strony nie możliwe jest
kontrolowanie procesu powstawania wolnego oprogramowania. Nie można narzucić hakerom
żadnego terminu ukończenia badź
˛ zestawu funkcjonalności, które maja˛ si˛e znaleźć w programie. Być może peer production okaże si˛e najlepsza˛ forma˛ produkcji w długim okresie, poprzez
mechanizm ewolucyjnego dobierania optymalnego zestawu funkcjonalności i architektury systemu100 daż
˛ acy
˛ do jakości nieosiagalnej
˛
dla przedsi˛ebiorstw komercyjnych, ograniczonych maksymalizacja˛ zysku w krótkim okresie? Myśl˛e, że za wcześnie jeszcze jest na takie hipotezy.
Warto jeszcze zauważyć, że nie wszystkie typy produktów jednakowo cz˛esto powstaja˛ jako
wolne oprogramowanie – te nie używane przez programistów maja˛ małe szanse powstać w
formie oprogramowanie o otwartym źródle. Programiści z jednej strony nie maja˛ motywacji
tworzyć oprogramowania, którego nie używaja,˛ a z drugiej nie jest możliwe skonstruowanie poprawnej specyfikacji programu bez dogł˛ebnej znajomości zagadnienia. W firmach komercyjnych
zbieraniem danych o potrzebach użytkowników i przekształceniem tej wiedzy na list˛e i opis niezb˛ednych funkcjonalności zajmuja˛ si˛e mocno rozbudowane struktury zarzadzaj
˛
ace
˛ projektem.
Programiści maja˛ ograniczony kontakt z innymi kreatywnymi użytkownikami oprogramowania.
Projekty oprogramowania o otwartym źródle nie spełniaja˛ roli współczesnego marketingu, który
nie tylko bada potrzeby konsumentów, ale cz˛esto tworzy nowe.
Z drugiej strony managerowie w projektach używanych przez wykwalifikowanych programistów sa˛ cz˛esto pośrednikiem pomi˛edzy programistami piszacymi
˛
oprogramowanie a programistami wykorzystujacymi
˛
ten program. Pośrednikiem gubiacym
˛
pewne informacje, gdyż rzadko
managerowie posiadaja˛ niezb˛edne wykształcenie i doświadczenie techniczne. Eric von Hippel
podkreśla znaczenie innowacji tworzonych przez użytkowników (ang. user driven innovations).
Zjawisko wymyślania przez użytkowników nowych funkcjonalności spotyka si˛e w wielu sektorach – von Hippel daje przykład produkcji desek do windsurfingu. Autor podkreśla, że cz˛esto
takie innowacje sa˛ bardziej wartościowe niż pomysły stworzone w firmie. W przypadku wolnego oprogramowania ten efekt jest jeszcze wi˛ekszy – użytkownicy nie tylko wymyślaja˛ nowe
charakterystyki oprogramowania ale także sami to oprogramowanie wytwarzaja!
˛ Jest to cecha
unikalna – użytkownicy sa˛ w stanie obyć si˛e zupełnie bez producenta komercyjnego.101
James Bessen zauważa, że oprogramowania o otwartym źródle ma cechy dóbr publicznych
– może być używane przez wszystkich ch˛etnych jednocześnie (ang. non-rival). Powstanie darmowych dóbr publicznych jest sprzeczne z klasyczna˛ ekonomia,˛ Bessen bada przyczyny tego
100
101
Oliva, The Competitive Advantages of Free Software.
von Hippel, Open Source Shows the Way: Innovation by and for Users – No Manufacturer Required!.
42
fenomenu. Swoja˛ analiz˛e opiera na złożoności produktu, jakim jest oprogramowanie komputerowe. W pierwszej cz˛eści pracy pokazuje, że proste dobra intelektualne, zawierajace
˛ kilka
funkcjonalności, nigdy nie powstana˛ jako oprogramowanie o otwartym źródle – bardziej optymalnie dla twórcy b˛edzie nie publikować kodu. W drugiej jednak cz˛eści zakłada, że oprogramowanie ma bardzo wiele (M ) potencjalnych funkcjonalności. Zakłada dalej, że firma komputerowa, by wypuścić niezawodny produkt, musi przetestować wszystkie produkty użytkowe
(ang. use products)102 – czyli każda˛ możliwa˛ kombinacj˛e funkcjonalności. Połaczenie
˛
użycia
kilku funkcjonalności może prowadzić do bł˛edów wynikajacych
˛
z nietrywialnych zależności pomi˛edzy kawałkami systemu je obsługujacymi.
˛
W przypadku tworzenia oprogramowania istnieje
asymetria informacji – firma komputerowa nie jest w stanie stwierdzić, które funkcjonalności
b˛eda˛ używane. W zwiazku
˛
z tym, tworzac
˛ skomplikowany produkt, jest narażona na olbrzymie
koszty. Umieszczajac
˛ w programie Mf funkcjonalności, musi przetestować 2Mf różnych produktów użytkowych. Przewaga społeczności wolnego oprogramowania, mimo istnienia problemów
wynikajacych
˛
z free-riding’u i duplikacji pracy, wynika z faktu, że społeczność ta dokładnie wie
jakie produkty użytkowe b˛eda˛ stosowane – każdy użytkownik testuje te używane przez siebie.
Dla bardzo dużych projektów liczba wszystkich produktów użytkowych drastycznie przewyższa
liczb˛e tych naprawd˛e używanych. Bessen dochodzi do wniosku, że grupy hakerów czasem sa˛ w
stanie wyprodukować oprogramowanie o wi˛ekszej złożoności niż firmy komercyjne.103
1.2.4. Niezawodność
W poprzednich rozdziałach przeprowadziłem analiz˛e przyczyn powstawania oprogramowania o
otwartym źródle. Starałem si˛e odpowiedzieć na pytania: dlaczego takie oprogramowanie powstaje? Co kieruje programistami wkładajacymi
˛
swój czas w jego rozwój? Jak przebiega sam
proces jego powstawania?
Teraz chciałbym si˛e zastanowić nad użytecznościa˛ powstałego w ten sposób oprogramowania. Jak już wcześniej napisałem, użytkownicy sami dodaja˛ do projektów funkcjonalności, z
których chca˛ korzystać. Można z tego faktu wnosić, że oprogramowanie to ma dostosowany
zestaw cech do pewnej grupy użytkowników. Bardzo charakterystyczna˛ cecha˛ oprogramowania
jest jednak fakt, że cz˛esto zawiera ono bł˛edy nie do wykrycia przez konsumenta decydujacego
˛
sie na kupno i używanie. Z rozumowania Jamesa Bessena104 wynika wr˛ecz, że koszt przete102
Takie same spostrzeżenia można znaleźć w Brooks, Mityczny osobomiesiac
˛
Bessen, Open Source Software: Free Provision of Complex Public Goods.
104
Ibid.
103
43
stowania programu jest główna˛ składowa˛ kosztu jego wytworzenia! Brooks pisze natomiast, że
faza testowania wynosi około połowy czasu tworzenia projektu.105 W tym podrozdziale chciałbym si˛e zastanowić nad niezawodnościa˛106 wolnego oprogramowania, powstajacego
˛
w wyniku
opisanego wcześniej procesu.
Zastanawiajace
˛ jest, czy produkt powstały z chaotycznie tworzonych i nadsyłanych łatek
może być niezawodny. Wydawałoby si˛e, że oprogramowanie jest tak skomplikowanym dobrem,
że aby je wytworzyć sa˛ niezb˛edne precyzyjne plany całości, a podejście polegajace
˛ na wielokrotnym poprawianiu małych fragmentów musi prowadzić do porażki. Dlaczego wi˛ec wolne
programy sa˛ używane w industri, cz˛esto w zastosowaniach kluczowych dla działalności firmy?
Postaram si˛e najpierw przedstawić argumenty teoretyczne, a nast˛epnie analiz˛e empiryczna.˛
Programiści bioracy
˛ udział w projektach oprogramowania o otwartym źródle podkreślaja,˛
że szacunek innych hakerów a jednocześnie prawo dost˛epu do oficjalnego kodu projektów zdobywa si˛e na zasadzie ścisłej merytokracji. Im programista jest lepszy (im lepszy kod dodaje do
programu) tym ma wi˛ekszy wpływ na rozwój projektu. W ten naturalny sposób projekty oprogramowania o otwartym źródle gwarantuja˛ sobie, że b˛eda˛ rozwijane przez najlepszych specjalistów, a jednocześnie zabezpieczaja˛ si˛e przed partaczami. Jest to procedura lepsza niż rekrutacja
w firmach komercyjnych, gdyż nie towarzyszy jest asymetria informacji. Firma zatrudniajac
˛ programistów nie może sprawdzić ich umiej˛etności potrzebnych do tworzenia konkretnego projektu.
Opiera si˛e głównie na widocznych sygnałach – jak dyplomy uniwersyteckie czy doświadczenie
zawodowe.107
Programiści oprogramowania o otwartym źródle sami wybieraja˛ funkcjonalność, która˛ chca˛
si˛e zajać.
˛ Sami programiści najlepiej znaja˛ swoje możliwości i słabe strony, dzi˛eki czemu dokonuja˛ optymalnej alokacji. W firmach komputerowych wyst˛epuje asymetria informacji – osoba
przydzielajaca
˛ programistom zadania ma niepełna˛ informacj˛e na temat ich stopnia kompetencji
w danym zakresie. Co wi˛ecej, hakerzy wybieraja˛ zwykle zadania, które sprawiaja˛ im przyjemność, angażuja˛ si˛e emocjonalnie w prac˛e, co nie jest do końca możliwe dla planisty w firmie.
Badania socjologiczne dowodza,˛ że ludzie zadowoleni pracuja˛ bardziej efektywnie. Tak wi˛ec w
procesie tworzenia wolnego oprogramowania mamy optymalna˛ alokacj˛e programistów, co także
wpływa na zmniejszenie liczby bł˛edów.108
105
106
Brooks, Mityczny osobomiesiac.
˛
Niezawodność rozumiem jako liczb˛e znajdowanych bł˛edów. Przeanalizuj˛e także średni czas poprawy zgłoszo-
nego bł˛edu przez firm˛e komercyjna˛ oraz społeczność oprogramowania o otwartym źródle.
107
Raymond, Homeseading the Noosphere.
108
Raymond, The Cathedral and the Bazaar.
44
Programiści podkreślaja˛ negatywny wpływ zbyt krótkich terminów na niezawodność oprogramowania. Ponieważ na rynku można zaobserwować tendencj˛e, że firma, która pierwsza wyda
oprogramowanie o nowatorskiej funkcjonalności, zyskuje najwi˛ecej ze wzgl˛edu na efekty sieciowe. Dlatego firmy komercyjne maja˛ tendencj˛e to wydawania nie do końca przetestowanych
produktów, zawierajacych
˛
dużo bł˛edów, aby zyskać przewag˛e konkurencyjna.˛ 109 Programiści
bardzo krytykuja˛ taka˛ strategi˛e, gdyż p˛ed by zdażyć
˛
w terminie powoduje tworzenie niedopracowanego kodu, który jest dodatkowo podatny na bł˛edy. Oprogramowanie o otwartym źródle jest
wolne od tego problemu, ustalane terminy publikacji oparte sa˛ wyłacznie
˛
na wzgl˛edach technicznych.110
W przypadku wi˛ekszości systemów producent oprogramowania nie pisze samodzielnie całości kodu, tylko w miar˛e możliwości korzysta z istniejacych
˛
już (darmowych lub nie) bibliotek.
Zdarza si˛e niestety, że biblioteki takie zawieraja˛ bł˛edy. Gdy korzystamy z bibliotek na licencji
oprogramowania o otwartym źródle, jesteśmy w stanie te bł˛edy poprawić. Gdy natomiast korzystamy z komercyjnych bibliotek, musimy zdać si˛e na producenta tego oprogramowania. Czasem
producent nie jest w stanie zlokalizować bł˛edu bez podania konkretnego przykładu użycia, zaś
my nie możemy ujawnić naszego kodu gdyż jest on obj˛ety tajemnica˛ firmowa.˛ 111 Pozostaje
wtedy tylko znaleźć obejście bł˛edu w bibliotece (ang. workaround), czego rezultatem jest powstanie „rozpaczliwego” kodu bardzo wrażliwego na bł˛edy – bład
˛ z biblioteki rozprzestrzenia
si˛e na nasze oprogramowanie.112
Bardzo ważnym mechanizmem wykluczania wielu bł˛edów jest mechanizm koleżeńskiej weryfikacji (ang. peer review), który, ze wzgl˛edu na ograniczenia kosztów, rzadko wyst˛epuje w
przedsi˛ebiorstwach. Każdy kawałek kodu, a szczególnie nowatorski lub kluczowy dla projektu,
jest zawsze czytany przez innych programistów. Motywacja˛ takiego działania może być zarówno
ch˛eć dopisania czegoś twórczego od siebie, sprawdzenia czy poprawka jest godna zaufania, czy
po prostu ch˛eć nauczenia si˛e czegoś nowego. W wyniku takiego procesu można wyłapać wiele
bł˛edów wynikajacych
˛
z nieuwagi programisty, czasem trudnych do znalezienia w fazie testowej.
Rozwój wolnego oprogramowania bardzo przypomina proces ewolucji. Kolejne wersje pro109
Szczególnie za takie praktyki krytykowana jest firma Microsoft. Niektórzy przypisuja˛ takiej strategii jej sukces
rynkowy. Ludzie nie sa˛ w stanie ocenić niezawodności oprogramowania, okazuje si˛e to dopiero podczas użytkowania. Wtedy jednak efekty sieciowe sa˛ tak duże, że nie opłaca si˛e przenosić na inne oprogramowanie. Cz˛esto
konkurent w ten sposób plajtuje.
110
Jackson, Why is software freedom useful, and what does it mean?.
111
ang. I can’t show you my source code and you can’t show me your’s problem.
112
Ibid.
45
gramów komercyjnych wydawane sa˛ co kilka lat i każdy kolejny jest rewolucyjny – wprowadza
wiele zmian, nowych funkcjonalności i pomysłów. Oprogramowanie o otwartym źródle natomiast rozwija si˛e małymi kroczkami, kolejne wersje powstaja˛ bardzo cz˛esto (czasem codziennie)
i nie różnia˛ si˛e bardzo od siebie. Pomi˛edzy kolejnymi wersjami programiści poprawiaja˛ to, co si˛e
okazało słabe w wersji poprzedniej. Firmy komercyjne zaś staraja˛ si˛e przekonać konsumenta, że
ich wersja jest na tyle ulepszona, że warto ja˛ kupić zamiast używać poprzedniej. Alexandre Oliva
argumentuje113 , że taki rozwój ewolucyjny sprzyja powstawaniu „ładnego” kodu, zawierajacego
˛
mało bł˛edów.
Co wi˛ecej, w projektach o otwartym źródle inaczej przebiega proces akceptowania zmian
w programie. W oprogramowaniu komercyjnym propozycje zmian sa˛ przyjmowane przez kierownictwo po przeczytaniu dokumentacji. Nast˛epnie zmiany przeznaczane sa˛ do realizacji –
powstaje odpowiedni kod źródłowy. W przypadku wolnego oprogramowania Lider rozpatruje
wyłaczenie
˛
poprawki w postaci już gotowego kodu. Kontrola jest tutaj wi˛ec na poziome samego
kodu źródłowego, a nie jak w przypadku oprogramowania firmowego - na poziomie projektu.
Zdarza si˛e, że Lider odrzuca kiepsko napisane poprawki, podczas gdy dostaja˛ si˛e one do tradycyjnych systemów.114
Fakt, że małe cegiełki moga˛ być połaczone
˛
w jedna,˛ funkcjonalna˛ całość wynika z wysokiej
modularności projektów. Proces powstawania oprogramowania o otwartym źródle wymaga od
programistów dzielenia każdego wi˛ekszego modułu na mniejsze kawałki. Dzi˛eki temu powstaje
wiele małych modulików. Niektóre moduły (czy sam program) maja˛ bardzo duża˛ funkcjonalność, ale składaja˛ si˛e tylko ze „zlepienia” odpowiednio mniejszych kawałków. Dzi˛eki temu ich
kod także jest krótki i przejrzysty.
Analiz˛e empiryczna˛ możemy znaleźć w Kuan, Open Source Software as Lead User’s Make
or Buy Decision: A Study of Open and Closed Source Quality. Autorka porównuje trzy pary produktów: wolny system operacyjny FreeBSD z komercyjnym odpowiednikiem (niestety nazwy
konkurencyjnych odpowiedników nie sa˛ podane), Apache’a z komercyjnym serwerem WWW i
Gnome’a z komercyjnym graficznym interfejsem użytkownika. Dla wszystkich produktów porównywane sa˛ liczby znalezionych bł˛edów, uwzgl˛edniajac
˛ ich szkodliwość, oraz średni czas ich
poprawienia. We wst˛epnej analizie danych, autorka zauważa, że w oprogramowaniu komercyjnym spotyka si˛e generalnie wi˛ecej bł˛edów. Liczba tych bł˛edów bardzo mocno waha si˛e w czasie
(w przypadku wolnego oprogramowania jest praktycznie stabilna) – wynika to z komercyjnego
113
114
Oliva, The Competitive Advantages of Free Software.
Asklund i Bendix, Configuration Management for Open Source Software.
46
modelu produkcji. Dalej, z analizy serwerów WWW i systemów operacyjnych wynika, że w programach o otwartym źródle bł˛edy poprawiane sa˛ szybciej niż w komercyjnych odpowiednikach.
W przypadku graficznych interfejsów użytkownika sytuacja jest odwrotna. Może to wynikać
z faktu, że interfejsy użytkownika sa˛ znanym słabym punktem wolnego oprogramowania – sa˛
słabiej rozwini˛ete niż pozostałe dwie kategorie oprogramowania.
Podsumowujac,
˛ uważam, że założenie o porównywalnej niezawodności wolnego i komercyjnego oprogramowania, wykorzystywane w wi˛ekszości cytowanych modeli oraz w moim modelu
w rozdziale 2, jest zasadne.
1.3. Rola przedsi˛ebiorstw i rzadu
˛ w tworzeniu wolnego oprogramowania
W tym rozdziale chciałbym zajać
˛ si˛e kwestia˛ wpływu firm komercyjnych i państwa na wolne
oprogramowanie. W rozdziale 1.2.2 opisałem wiele rodzajów działalności komplementarnej
do rozwoju oprogramowania o otwartym źródle, na której firmy zarabiaja.˛ Ponieważ produkty
firm sa˛ komplementarne do wolnego oprogramowania, firmy te sa˛ zainteresowane rozwojem
tego oprogramowania. Wzrost jakości czy udziału w rynku wolnego oprogramowania b˛edzie
skutkował wi˛ekszym popytem dla przedsi˛ebiorstw. Z drugiej jednak strony wyst˛epuja˛ tutaj wyraźne efekty zewn˛etrzne – firma pomagajac
˛ wolnemu oprogramowaniu, pomaga pośrednio także
swoim bezpośrednim konkurentom.
Analityczny model powyższego zjawiska, oparty na teorii gier, możemy znaleźć w Harhoff,
Henkel i von Hippel, Profiting from voluntary information spillovers. . . . Autorzy zakładaja,˛ że
każda poprawka jest najbardziej dopasowana do indywidualnych potrzeb autora. Inni agenci
też maja˛ użyteczność z tej poprawki, ale mniejsza˛ niż autor. Zakłada si˛e także, że społeczność
wolnego oprogramowania, otrzymawszy dwie różne poprawki (od różnych agentów), wybieraja˛
„najlepsze” cechy z obu i robi własna˛ poprawk˛e. Obaj autorzy maja˛ mniejsza˛ użyteczność z
poprawki społeczności niż z własnej, ale wi˛eksza˛ niż z poprawki innego agenta. Z modelu
wynika, że dla rozsadnych
˛
wartości parametrów, podmiotowi posiadajacemu
˛
innowacj˛e opłaca
si˛e ja˛ opublikować, by została dodana do wersji oficjalnej.
Wkład firm komercyjnych, zajmujacych
˛
si˛e produktami komplementarnymi, różni si˛e zwykle
od wkładu pojedynczych programistów. Firmy staraja˛ si˛e przybliżyć wolne oprogramowanie
szerszemu gronu potencjalnych użytkowników, staraja˛ si˛e zmniejszyć różnice pomi˛edzy wolnym
47
oprogramowaniem a komercyjnym. Zajmuja˛ si˛e np. instalatorami czy graficznymi interfejsami
użytkownika, dokumentacja˛ programów, etc. – sferami niech˛etnie rozwijanymi przez samych
programistów. Cz˛esto firmy zwiazane
˛
z ruchem oprogramowania o otwartym źródle przydzielaja˛
grupk˛e swoich programistów bezpośrednio do pracy nad wolnym oprogramowaniem (np. IBM,
RedHat), by lepiej poznać proces jego powstania i zyskać aprobat˛e w oczach hakerów.
Firmy tradycyjnie zajmuja˛ si˛e także marketingiem, dzi˛eki czemu informuja˛ społeczeństwo o
istnieniu wolnego oprogramowania i jego cechach. To wpływa pośrednio na jego rozwój – im
wi˛eksza baza potencjalnych użytkowników, tym wi˛ecej potencjalnych programistów.115
Warto także zauważyć, że firmom zależy na wypromowaniu si˛e i odróżnieniu od konkurencji,
by zdobyć jak najwi˛ekszy udział w rynku, a co za tym idzie zwi˛ekszyć zyski. Wynika stad,
˛ że
firmy sprzedajace
˛ dobra komplementarne do wolnego oprogramowania maja˛ motywacj˛e sygnalizacyjna˛ – chca˛ pokazać klientom, że to właśnie dana firma najlepiej si˛e zna na oprogarmowaniu
o otwartym źródle. W tym celu zatrudniaja˛ liderów najwi˛ekszych projektów na stanowiskach
„konsultantów”. Zyskuje na tym zarówno sam lider, cała społeczność zajmujaca
˛ si˛e danym projektem (gdyż lider de facto zajmuje si˛e rozwojem projektu), oraz firma, która pokazuje że skoro
dla niej pracuje lider projektu, to ona jest najlepszym specjalista˛ w zakresie danej technologii na
rynku.
Niektóre firmy zajmuja˛ si˛e także zapewnieniem miejsca na serwerze danemu projektowi
(ang. „hosting”). Robia˛ to albo dla projektu zwiazanego
˛
ze swoja˛ działalnościa˛ 116 , lub dla
wielu (VA Linux ma portal SourceForge.net). W pierwszym przypadku firma, analogicznie jak
poprzednio, stara si˛e pokazać jako specjalista w danej dziedzinie, w drugim pokazuje, że może
zapewnić infrastruktur˛e do rozwoju projektów programistycznych. Hakerzy zyskuja,˛ ponieważ
spadaja˛ koszty monetarne rozwoju projektów oprogramowania o otwartym źródle.
Podsumowujac,
˛ firmy sprzedajace
˛ dobra komplementarne do wolnego oprogramowania, przyczyniaja˛ si˛e pośrednio do szerszego rozprzestrzenienia tego oprogramowania oraz do zmniejszenia kosztów prowadzenia projektu.
Oprogramowanie o otwartym źródle zostało ostatnio zauważone przez rzady
˛ państw. W
legislacjach europejskich pojawiaja˛ si˛e zapisy o wspieraniu wolnego oprogramowania (np. w
115
116
Stallman, The Free Software Definition.
Np. firma Code Weavers sponsoruje serwer projektu Wine (http://www.winehq.com). Wine jest imple-
mentacja˛ API (ang. Application Programming Interface) Windows’ów (umożliwia uruchamianie programów pod
Windows’y pod Linuksem). Code Weavers oferuje CrossOver Office – oprogramowanie oparte na Wine umożliwiajace
˛ łatwe uruchomienie programu Microsoft Office (i kilku innych) pod Linuksem.
48
dokumencie eEurope). Poza tym poszczególne rzady
˛ (np. niemiecki) niezależnie wspieraja˛
wolne oprogramowanie, np. publikujac
˛ podr˛ecznik użytkowania. Nasuwa si˛e pytanie, czy takie
działania sa˛ korzystne ze społecznego punktu widzenia.
W dużej mierze jest to temat otwarty. W Xu, Development costs and open source software
mamy model oparty w dużej mierze na modelu Johnsona117 , majacy
˛ te same założenia. Autor
przeprowadza analiz˛e z której wnioskuje, że zmniejszenie kosztu pojedynczej poprawki (z powodu pewnych działań subwencjonujacych
˛
rzadu
˛ badź
˛ firm) może prowadzić do zmniejszenia
prawdopodobieństwa wykonania tej poprawki. Ja w moim modelu w rozdziale 2 otrzymuj˛e przeciwny wynik – obniżenie kosztu pojedynczej poprawki jest jedynym środkiem do zwi˛ekszenia
oczekiwanej liczby funkcjonalności oprogramowania o otwartym źródle.
W Schmidt i Schnitzer, Public Subsidies for Open Source?. . . znajdujemy analiz˛e potencjalnych działań rzadu
˛ wspierajacych
˛
oprogramowania o otwartym źródle. Autorzy modeluja˛ wolne
oprogramowanie i konkurencyjnego przedsi˛ebiorc˛e komercyjnego. Konsumenci rozrzuceni sa˛
równomiernie w modelu liniowego miasta. Wyst˛epuje asymetria informacyjna – wszyscy wiedza˛ o istnieniu oprogramowania komercyjnego, ale tylko cz˛eść wie o oprogramowaniu wolnym.
Wynikiem modelu jest wniosek, że jedynym działaniem rzadu
˛ podnoszacym
˛
dobrobyt społeczny
sa˛ działania informacyjne. Bezpośrednie dofinansowanie konkretnych projektów czy ustawowe
zmuszanie niektórych podmiotów do korzystania z oprogramowania o otwartym źródle prowadzi
do spadku ogólnego dobrobytu.
Warto jeszcze wspomnieć, że patenty na oprogramowanie sa˛ legislacja˛ opóźniajac
˛ a˛ rozwój
wolnego oprogramowania. Społeczności hakerów nie sa˛ w stanie patentować swoich rozwiazań,
˛
bronić si˛e w sadzie
˛
przed oskarżeniami o naruszenie patentów czy podpisywać umowy o wymianie patentów (ang. cross-licensing). Istnieje ponadto wiele publikacji dowodzacych,
˛
że patenty
na oprogramowanie zmniejszaja˛ a nie zwi˛ekszaja˛ wydatki na badania i rozwój w sektorze (np.
Bessen i Hunt, An Empirical Look at Software Patents). W Stanach Zjednoczonych i Japonii patenty na oprogramowanie funkcjonuja,˛ w Unii Europejskiej kwestia ta podlega aktualnie debacie
politycznej.
117
Johnson, Economics of Open Source Software.
49
Rozdział 2
Model
W tym rozdziale chciałbym przedstawić stworzony przez siebie model oprogramowania o otwartym źródle i oprogramowania komercyjnego. Model obrazuje rynek, na którym wolne oprogramowanie konkuruje z tym stworzonym w firmie. Uwzgl˛edniłem heterogeniczność konsumentów
w postrzeganiu atrakcyjności obu rodzajów oprogramowania – swój model oparłem na znanym
modelu zróżnicowania popytu: „liniowego miasta”. Starałem si˛e uchwycić zarówno charakterystyk˛e procesu produkcji oprogramowania w przedsi˛ebiorstwie (opierajac
˛ si˛e na inżynierii
oprogramowania), jak i „bazarowy” proces powstawania wolnego oprogramowania, opisany w
poprzednim rozdziale. Wyciagam
˛
wnioski jak wpłynie obecność oprogramowania o otwartym
źródle na równowag˛e na rynku oraz analizuj˛e jak zewn˛etrzna pomoc dla oprogramowania o
otwartym źródle wpłynie na rozwój tego dobra.
2.1. Funkcja produkcji firm komercyjnych
Funkcja produkcji oprogramowania w firmie zależy jedynie od liczby programistów. Frederich
P. Brooks zauważa, że po pierwsze, przy tworzeniu oprogramowania wi˛ecej czasu poświ˛eca si˛e
na wyszukiwanie i poprawianie bł˛edów w już napisanym kodzie niż na samo pisanie. Dlatego
też można założyć że poszukiwanie bł˛edów jest dominujacym
˛
składnikiem w funkcji produkcji
oprogramowania. Po drugie, najwi˛ecej bł˛edów pojawia si˛e na styku modułów pisanych przez
różnych ludzi. Przy założeniu, że nad projektem pracuje N programistów, takich „styków” jest
N (N −1)
2
(tzw. Prawo Brooksa – przytoczone przez Eric’a Raymonda1 ). Liczba nowych funkcjo-
nalności nie b˛edzie wi˛ec proporcjonalna do liczby programistów, a raczej do pierwiastka z tej
1
Raymond, The Cathedral and the Bazaar s. 10.
51
liczby, gdyż programiści musza˛ „zdebugować” każdy (także pośredni) interfejs miedzy dwoma
kawałkami kodu. Tak wi˛ec żeby wyprodukować M funkcjonalności, musza˛ rozpatrzyć rz˛edu M 2
problemów. Ponieważ mój model jest statyczny, czyli przyjmuj˛e, że oprogramowanie powstaje
√
w ciagu
˛ jednostki czasu, N programistów może stworzyć (i poprawić bł˛edy) tylko N funkcjonalności.2 Zauważmy także, jednostki N , czyli liczby programistów zatrudnionych w firmie
komercyjnej, sa˛ zupełnie niezależne od rynku na oprogramowanie i osób rozwijajacych
˛
wolne
oprogramowanie. Możemy wi˛ec pominać
˛ wszelkie stałe współczynniki na tym etapie analizy
– wystarczajacym
˛
współczynnikiem b˛edzie płaca programisty. Mamy wi˛ec nast˛epujac
˛ a˛ funkcj˛e
produkcji:
√
fCSS (N ) =
N
(2.1)
2.2. Funkcja produkcji ruchu wolnego oprogramowania
Funkcja produkcji dla oprogramowania o otwartym źródle ma zupełnie inna˛ postać niż dla tradycyjnego oprogramowania. Jak już zarysowałem, programiści nie maja˛ przypisanych zadań ani
funkcjonalności nad którymi pracuja.˛ Sami wybieraja˛ jaki element chca˛ rozwinać
˛ – co może
rodzić problem, że ich praca b˛edzie zdublowana i ogólna użyteczność spadnie. Linus Torvalds
pokazał, że wyszukiwanie i poprawianie bł˛edów w kodzie może być wykonywane równocześnie
i niezależnie przez wielu programistów, oprogramowania o otwartym źródle nie dotycza˛ ograniczenia dla tradycyjnego oprogramowania wynikajace
˛ z kwadratowej liczby miejsc, gdzie powstaja˛ bł˛edy. Ponieważ projekty OSS działaja˛ zgodnie z zasada˛ „Wypuszczaj cz˛esto i szybko”3 ,
także sam rozwój kodu może nast˛epować równolegle, gdyż każda poprawka jest „niewielka” i
jest małe prawdopodobieństwo, że dwie poprawki wypuszczone w tym samym momencie dotycza˛ dokładnie tego samego kawałka kodu. Nawet gdy si˛e to zdarzy, stosunkowo łatwo „dopasować” do siebie obie poprawki, gdyż sa˛ „niewielkie”.
Dodatkowo przyjmijmy, że liczba możliwych funkcjonalności (poprawek) jest stosunkowo
duża (wynika to z poziomu skomplikowania oprogramowania), stała i wynosi M . Jest to zało2
Firmy komercyjne cz˛esto rezygnuja˛ z poprawiania wszystkich bł˛edów w programie – gdy cz˛estość znajdowania
bł˛edów spadnie poniżej ustalonego poziomu podejmuje si˛e decyzj˛e o wypuszczeniu oprogramowania. Ma to jednak
ujemne skutki – oprogramowanie dalej zawiera sporo bł˛edów, czasem krytycznych. Nie b˛edziemy tego explicite
√
modelować, założymy tylko dla uproszczenia, że nawet jeżeli N programistów zrealizuje wi˛ecej niż N funkcjonalności, to wynikowe oprogramowanie, w wyniku istnienia wielu niepoprawionych bł˛edów, b˛edzie postrzegane
√
przez konsumentów równorz˛ednie z oprogramowaniem o N funkcjonalnościach i bez bł˛edów.
3
Raymond, The Cathedral and the Bazaar s. 7.
52
żenie sensowne, gdyż projekty informatyczne maja˛ tendencj˛e do rozwoju ewolucyjnego. Każdy
projekt zawiera skończona˛ liczb˛e funkcjonalności, które można rozwinać
˛ na skończona˛ liczb˛e
sensownych sposobów. Inny argument: pomysły na nowe funkcjonalności zostaja˛ wymyślone
przez ludzi. Ponieważ ludzi jest skończenie wiele i rozpatrujemy skończony przedział czasu,
możliwych innowacji też może być skończenie wiele. Z kolei założenie o stałości tej liczby jest
upraszczajace
˛ i wynika z faktu, że przyjałem
˛
statyczny model, w którym oprogramowanie rozwija si˛e tylko przez jednostk˛e czasu. W zwiazku
˛
z tym ogólny poziom technologii, wyznaczajacy
˛
M , nie ulega zmianie. Ograniczenie M jest znane wszystkim agentom – także dla uproszczenia.
Przyjmijmy także, że agent decyduje si˛e poprawiać jedna˛ z M rzeczy w sposób losowy, każda˛
z równym prawdopodobieństwem
1
.
M
Zdefiniujmy rodzin˛e zmiennych losowych Xi dla i ∈ {1, . . . , M }:
(
0 gdy i-ta funkcjonalność nie została zrealizowana
Xi =
1 w p.p.
(2.2)
Wtedy, jeżeli LOSS agentów zdecyduje si˛e rozwijać oprogramowanie o otwartym źródle,
prawdopodobieństwo, że i-ta funkcjonalność nie zostanie zrealizowana wynosi:
1
1−
M
LOSS
1
E[Xi ] = 1 − 1 −
M
LOSS
P (Xi = 0) =
(2.3)
Łatwo obliczyć wartość oczekiwana:
˛
(2.4)
Możemy zdefiniować zmienna˛ losowa˛ X = X1 + X2 + · · · + XM oznaczajac
˛ a˛ liczb˛e zrealizowanych funkcjonalności. Korzystajac
˛ z własności wartości oczekiwanej4 możemy policzyć wartość
oczekiwana˛ liczby zrealizowanych funkcjonalności przez LOSS programistów:
E[X] = E[X1 ] + E[X2 ] + · · · + E[XM ] =
LOSS !
LOSS !
1
1
=
1− 1−
+ 1− 1−
+ ··· +
M
M
LOSS !
1
= M 1− 1−
M
4
1
1− 1−
M
LOSS !
Zmienne Xi sa˛ od siebie zależne, nie wpływa to jednak na własność liniowości wartości oczekiwanej.
53
(2.5)
Funkcja produkcji ma wi˛ec postać:
fOSS (LOSS ) = M
1
1− 1−
M
LOSS !
(2.6)
W naszej analizie pomin˛eliśmy jednak jeden bardzo istotny czynnik: użytkownicy moga˛ pomyśleć „po co ja mam coś dopisywać do programu, jeżeli moga˛ to zrobić inni zamiast mnie, a
ja tylko z tego skorzystam bez żadnych kosztów”. Jest to tzw. Free Riding Problem5 . Dokładniej analiza˛ tego zjawiska zajmiemy si˛e analizujac
˛ użyteczność agentów i rynek. Przyjmijmy
chwilowo, że istnieje takie prawdopodobieństwo ψ ∈ [0, 1], że programiście zdecydowanemu
używać oprogramowania o otwartym źródle b˛edzie oboj˛etne, czy z prawdopodobieństwem ψ
dopisze nowa˛ funkcjonalność czy z 1 − ψ b˛edzie uprawiał free riding.6 Tak wi˛ec programista
wybierze każda˛ z innowacji z prawdopodobieństwem ψ M1 =
ψ
.
M
Przeprowadzajac
˛ analogiczna˛
analiz˛e jak powyżej uzyskujemy nowa˛ funkcj˛e produkcji, zależna˛ od prawdopodobieństwa ψ:
LOSS !
ψ
(2.7)
fOSS (LOSS , ψ) = M 1 − 1 −
M
2.3. Funkcja użyteczności użytkownika oprogramownia
Oprogramowanie tradycyjne i oprogramowanie o otwartym źródle różnia˛ si˛e nie tylko sposobem powstawania i licencja.˛ Wolne oprogramowanie jest w dużo wi˛ekszym stopniu nastawione
na programistów i administratorów sieciowych, zaś oprogramowanie komercyjne skupia si˛e na
„zwykłych” użytkownikach komputera, posiadajacych
˛
cz˛esto minimalna˛ wiedz˛e informatyczna.˛
Wynika to z faktu, że (1) programiści piszacy
˛ oprogramowanie o otwartym źródle cz˛esto rozwia˛
zuja˛ jakieś problemy napotykane w swojej codziennej pracy, (2) firmom zależy na jak najszerszym gronie odbiorców. Programiści poradza˛ sobie z oprogramowaniem dla niedoświadczonych
użytkowników, a na odwrót już nie.
Chciałbym zaproponować klasyczny model zróżnicowania produktu – model „liniowego
miasta”. Zakładam, że na rynku jest L odbiorców oprogramowania. Sa˛ oni rozmieszczeni w
równomiernie na odcinku [0, 1]. Na końcu odcinka oznaczonego 1 znajduje si˛e firma komercyjna, zaś w 0 lider projektu oprogramowania o otwartym źródle. Każdy użytkownik może
wybrać oprogramowanie komercyjne/wolne. Gdy wybierze wariant komercyjny, ma nast˛epujac
˛ a˛
5
6
Po polsku zwykle określany „problemem gapowicza”.
B˛edziemy rozpatrywać tylko równowagi symetryczne.
54
funkcj˛e użyteczności:
UCSS (x) = θMCSS − t(1 − x) − p
(2.8)
gdzie x oznacza adres agenta w mieście, θ jest współczynnikiem krańcowej użyteczności z
nowej funkcjonalności, MCSS to liczba funkcjonalności w zaproponowanym przez firm˛e komercyjna˛ produkcie, t - współczynnik zróżnicowania użytkowników, 1 − x - odległość preferencji
konsumenta od polityki firmy, zaś p to cena oprogramowania ustalana przez firm˛e.
Użyteczność w przypadku korzystania z oprogramowania OSS wyglada
˛ analogicznie, sa˛ tu
jednak dwa przypadki. Agent może zdecydować si˛e wziać
˛ udział w pracach nad oprogramowaniem:
d
UOSS,d (x) = θMOSS
− tx − c
(2.9)
gdzie c jest kosztem, jaki musi ponieść programista. Może on si˛e jednak zdecydować na Free
Riding i nie ponosi kosztu c:
fr
UOSS,f r (x) = θMOSS
− tx
(2.10)
Warto w tym momencie zauważyć dwie rzeczy. Po pierwsze, niezb˛edne jest założenie o
skończonej liczbie użytkowników. Gdyby liczba ta była nieskończona, każdy by wiedział, że
jego indywidualny wkład do oprogramowania byłby zerowy, wi˛ec decydowałby si˛e na free riding. W zwiazku
˛
z tym wolne oprogramowanie by nie istniało. Po drugie, zauważmy, że MOSS
fr
d
jest wi˛eksze od MOSS
o kontrybucj˛e
we wzorach (2.9) i (2.10) nie sa˛ sobie równe – w (2.9) MOSS
rozpatrywanego agenta, caeteris paribus.
2.4. Producent oprogramowania
Firma produkujaca
˛ oprogramowanie kieruje si˛e maksymalizacja˛ zysku. Zatrudnia programistów (zał. że rynek pracy programistów jest doskonale konkurencyjny, zaś płaca wynosi w) w
celu wytworzenia oprogramowania na sprzedaż. Przypomnijmy, że funkcja produkcji ma postać
(2.1):
√
fCSS (N ) =
N
Popyt na produkt firmy zależy od jakości produktu (liczby zatrudnionych przez firm˛e programistów), ceny (na te zmienne firma ma wpływ) i na MCSS , czyli jakości wolnego oprogramowania. Zauważmy, że konsument indyferentny (ang. „pivotal consumer” – czyli taki któremu
wszystko jedno, czy b˛edzie używał OSS, czy CSS) b˛edzie si˛e zastanawiał, czy wybrać wolne
oprogramowanie jako free rider, czy zakupić komercyjne. B˛edzie wolał wydać pieniadze
˛
na
55
oprogramowanie komercyjne niż brać si˛e za rozwój oprogramowania OSS. Przyjmujac
˛ chwilowo MOSS jako dana,˛ możemy policzyć popyt na produkty przedsi˛ebiorstwa. Przypomnijmy,
że użyteczność konsumenta z oprogramowania o zamkni˛etym kodzie wynosi (2.8):
UCSS (x) = θMCSS − t(1 − x) − p
zaś z oprogramowania OSS jako free rider (2.10):
UOSS,f r (x) = θMOSS − tx
Ponieważ x jest konsumentem indyferentnym, uzyskuje on ta˛ sama˛ użyteczność z obu źródeł:
θMCSS − t(1 − x) − p = θMOSS − tx
MCSS obliczmy podstawiajac
˛ funkcj˛e produkcji (2.1). Popyt po przekształceniu:
D(N, p, MOSS ) = L(1 − x)
= L 1−
θ(MOSS −
√
N) + p + t
!
2t
√
θ( N − MOSS ) − p + t
= L
2t
(2.11)
Widzimy, że popyt rośnie gdy firma obniża cen˛e, oraz jest tym wi˛ekszy, im lepszy jest produkt komercyjny od wolnego oprogramowania. Firma ma nast˛epujac
˛ a˛ funkcj˛e zysku:
√
θ( N − MOSS ) − p + t
− wN
π(N, p) = pD(N, p, MOSS ) − wN = Lp
2t
(2.12)
która˛ maksymalizuje ustalajac
˛ wartości p i N . Po zróżniczkowaniu uzyskujemy nast˛epujace
˛
warunki pierwszego rz˛edu:
√
∂π
θ( N − MOSS ) − 2p + t
=L
=0
∂p
2t
(2.13)
∂π
pθL
= √ −w =0
(2.14)
∂N
4t N
Po przekształceniu (2.13) uzyskujemy wzór na cen˛e oprogramowania komercyjnego:
√
4wt N
p=
(2.15)
θL
56
Wyliczajac
˛ MCSS z równania (2.13) otrzymujemy:
√
θMOSS − t
N = MCSS = θL
θ2 L − 8wt
Rozsadnie
˛
jest założyć, że czynnik
θMOSS −t
θ2 L−8wt
(2.16)
jest wi˛ekszy od zera. Wtedy cały rynek b˛edzie
pokryty przez oprogramowanie, a oprogramowanie komercyjne b˛edzie bezpośrednim konkurentem wolnego. Bez tego założenia firma komercyjna byłaby monopolista˛ w swojej niszy, zaś OSS
zajmowaliby sie tylko hobbyści – przypadek nieciekawy.
Co ciekawe, ze wzoru (2.16) wynika, że jakość oprogramowania jest zależna dodatnio od
jakości oprogramowania o otwartym źródle. Tak wi˛ec firma komercyjna zagrożona wolnym
oprogramowaniem b˛edzie z nim walczyła wyższa˛ jakościa.˛ Ze wzoru (2.13) widać, że cena jest
wprost proporcjonalna do jakości. Firma komercyjna skupi si˛e na w˛eższym gronie odbiorców
(popyt, jak pokazaliśmy, jest ujemnie zależny od ceny) i zaproponuje im wyższa˛ jakość, gdy
istnieje dobrze rozwini˛ete wolne oprogramowanie (MOSS jest duże).
2.5. Powstawanie oprogramowania o otwartym źródle
Przyjmijmy chwilowo, że LOSS użytkowników oprogramowania zdecydowało sie używać oprogramowania OSS i rozważa możliwość dopisania jakiejś nowej funkcjonalności. Ci wszyscy
użytkownicy wola˛ nawet poświ˛ecić czas na rozwój tego oprogramowania niż skorzystać z wersji
komercyjnej. Tak wi˛ec sa˛ trzy grupy użytkowników7 :
• Zdecydowani na wersj˛e komercyjna˛ – popyt dla przedsi˛ebiorstwa (D(p, N, MOSS )).
• Zdecydowani na free riding, bioracy
˛ jakość wolnego oprogramowania jako dana˛ – ta grupa
woli oprogramowanie komercyjne, niż dopisywanie własnor˛eczne kodu.
• Prawdziwi zwolennicy wolnego oprogramowania, w ogóle nie bioracy
˛ pod uwag˛e kupna
rozwiazania
˛
komercyjnego. Maksymalizuja˛ użyteczność wybierajac
˛ pomi˛edzy programowaniem a free riding (LOSS ).
Każdy użytkownik z trzeciej grupy maksymalizujac
˛ oczekiwana˛ użyteczność, bierze pod
uwag˛e równowag˛e Nasha w strategiach mieszanych – z prawdopodobieństwem ϕ wybiera rozwój, z 1 − ϕ free riding. Zauważmy, że wprowadzajac
˛ funkcj˛e produkcji wolnego oprogramowania założyliśmy, że równowaga ta b˛edzie symetryczna – tutaj dalej utrzymujemy to założenie.
7
Zakładajac
˛ odp. wartości parametrów. Opisywana˛ sytuacj˛e obserwujemy w rzeczywistości, wi˛ec wydaje mi
si˛e, że możemy si˛e na niej skupić. Pozostałe sytuacje sa˛ zdegenerowane, a przez to mniej ciekawe.
57
Każdy agent zdaje sobie spraw˛e, że ma wpływ na jakość wolnego oprogramowania – wartość
oczekiwana b˛edzie miała inna˛ wartość gdy zdecyduje si˛e na programowanie niż gdy pozostanie
przy free riding. Wartość oczekiwana agenta wynosi:
!
LOSS −1 !
ψ
1
E[uOSS ] = ϕ θM 1 − 1 −
1−
− ty − c
M
M
!
LOSS −1 !
ψ
+ (1 − ϕ) θM 1 − 1 −
− ty
(2.17)
M
gdzie y oznacza adres rozpatrywanego agenta. Liczymy pochodna˛ po ϕ:
LOSS −1 !
∂E[uOSS ]
ψ
1
= θM 1 − 1 −
1−
− ty − c
∂ϕ
M
M
!
LOSS −1 !
ψ
− θM 1 − 1 −
− ty
(2.18)
M
Po przyrównaniu do zera, przekształceniu i wyliczeniu ψ otrzymujemy:
c L 1 −1 OSS
ψ =M 1−
θ
(2.19)
Otrzymana zależność opisuje charakterystyk˛e problemu free riding w przypadku tworzenia wolnego oprogramowania. Zauważmy, że gdy programistów jest stosunkowo niewielu w porównaniu do potencjalnej liczby funkcjonalności, ψ wyliczone z powyższego wzoru b˛edzie wi˛eksze od
jedności. Ponieważ ψ opisuje prawdopodobieństwo, taki rezultat nie ma bezpośredniej interpretacji ekonomicznej (nie można stosować kolejnych wzorów korzystajacych
˛
z równania (2.19)).
Oznacza to jednak, że programiści sa˛ zdecydowani rozwijać oprogramowanie i zjawisko free
riding w ogóle nie wyst˛epuje.
We wzorze pojawia si˛e θc , czyli stosunek kosztu wytworzenia pojedynczej funkcjonalności do
użyteczności wytworzonej funkcjonalności. Ze wzoru widzimy, że żeby ψ było wi˛eksze od zera
(czyli żeby rozwój oprogramowania o otwartym źródle miał miejsce), musi być spełnione θ > c.
Jest to rozsadny
˛
rezultat, gdyż nikt nie zdecydowałby si˛e pisać programu wiedzac,
˛ że jego praca,
nawet gdy nie b˛edzie zdublowana przez innego programist˛e, da mu mniejsza˛ użyteczność niż jej
koszt. Jak napisałem na poczatku
˛ pracy, amatorskie oprogramowanie pojawiało si˛e zawsze, wi˛ec
taki stosunek parametrów dobrze modeluje rzeczywistość.
Podstawiajac
˛ ψ do funkcji produkcji wolnego oprogramowania (2.7) otrzymujemy:
!
c LLOSS−1
OSS
MOSS = M 1 −
θ
58
(2.20)
Jest to bardzo ciekawy rezultat, gdyż przy LOSS → ∞ oczekiwana jakość oprogramowania
OSS daży
˛ do stałej, mniejszej niż liczba dost˛epnych funkcjonalności:
c
MOSS = M 1 −
LOSS →∞
θ
lim
(2.21)
Jeżeli przyjmiemy, że LOSS jest ustalone, możemy zbadać wpływ wartości współczynników
na poziom ψ, czyli na stopień zjawiska free riding. Gdy c spadnie, ψ wzrośnie. Czyli spadek
kosztu wytworzenia funkcjonalności, spowodowany np. niższymi cenami dost˛epu do internetu
czy wyższa˛ jakościa˛ darmowych narz˛edzi programistycznych, spowoduje niższy poziom free riding i wyższa˛ jakość oprogramowania OSS. Jest to bardzo ważny rezultat, gdyż wskazuje na coś
przeciwnego niż pokazał Xiaopeng Xu, opierajac
˛ si˛e na troch˛e innych założeniach.8 Rozwijajac
˛
model Johnsona9 , założył że użytkownicy oprogramowania OSS zastanawiaja˛ si˛e nad rozwojem
jednego, konkretnego ulepszenia programu. Analizował za to zróżnicowanie indywidualnych
użyteczności jednostkowych z ulepszenia (u mnie jednolity parametr θ) i kosztów wytworzenia
innowacji (u mnie c) oraz asymetri˛e informacji (dla uproszczenia pominałem
˛
w analizie). Ja natomiast skupiłem si˛e na kompleksowości programów komputerowych i możliwości ich rozwoju
w wielu kierunkach – rozpatrujac
˛ M możliwych udoskonaleń. Xiaopeng Xu wyszło, że gdy
koszt c si˛e zmniejszy, może to prowadzić do mniejszego prawdopodobieństwa wyprodukowania ulepszenia. Mój rezultat pokazuje, że państwo subsydiujac
˛ (wprowadzajac
˛ ulgi podatkowe
czy inne ułatwienia dla pozarzadowych
˛
podmiotów subsydiujacych)
˛
rozwój skomplikowanego
oprogramowania zwi˛eksza prawdopodobieństwo jego powstania i przesuwa granic˛e maksymalnej liczby funkcjonalności, która może być wytworzona przez ruch oprogramowania o otwartym
źródle. Rezultaty Xiaopeng Xu i mój sa˛ zgodne z wynikami Jamesa Bessena10 , który rozpatruje proces powstawania informacyjnych dóbr publicznych oparty na ich złożoności (dokładniej
rozpatruje tzw. produkty użytkowe – ang. use products11 ). Bessen pokazuje, że gdy potencjalna liczba funkcjonalności M jest mała (proste produkty) oprogramowanie o otwartym źródle
8
Xu, Development costs and open source software.
Johnson, Economics of Open Source Software.
10
Bessen, Open Source Software: Free Provision of Complex Public Goods.
11
Produkt użytkowy to zestaw funkcjonalności produktu z których użytkownik naprawd˛e korzysta. Bessen przyj9
muje, że każdy produkt użytkowy trzeba oddzielnie przetestować, gdyż relacje pomi˛edzy różnymi modułami programu sa˛ na tyle skomplikowane, że nie da si˛e przewidzieć zachowania konkretnego produktu użytkowego bez
testów. Wynika stad,
˛ że gdy jest M możliwych funkcjonalności, firma komercyjna musi wykonać 2M testów.
Wspólnoty oprogramowania o otwartym źródle maja˛ tutaj t˛e przewag˛e, że każdy programista testuje tylko ta˛ wersj˛e,
której używa i nieużywane produkty użytkowe nie musza˛ być testowane.
59
w ogóle nie powstanie – agenci b˛eda˛ preferować rozwój oprogramowania dla siebie i nieujawnianie go konkurentom. Sytuacja natomiast wyglada
˛ zupełnie inaczej, gdy oprogramowanie jest
bardzo skomplikowane – im M jest wi˛eksze tym wi˛eksza˛ przewag˛e konkurencyjna˛ ma OSS.
2.6. Porównanie oprogramowania komercyjnego z oprogramowaniem o otwartym źródle
Ciekawy problem stanowi także porównanie oprogramowania wolnego i komercyjnego. Niestety
nie da si˛e wyliczyć dokładnego analitycznego rozwiazania
˛
modelu ze wzgl˛edu na postać wzorów, ale można wyciagn
˛ ać
˛ wiele interesujacych
˛
wniosków analizujac
˛ tylko zależności pomi˛edzy
zmiennymi.
Ze wzoru (2.16), jak już zauważyliśmy, wynika że firma komercyjna dostosowuje si˛e do
oprogramowania o otwartym źródle podnoszac
˛ jakość produktu. Gdy podstawimy MCSS ze
wzoru (2.16) do wzoru (2.15) otrzymamy zależność ceny tego oprogramowania od jakości wolnego oprogramowania:
θMOSS − t
p = 4wt
(2.22)
θ2 L − 8wt
Widzimy tutaj z kolei, że cena także b˛edzie wzrastać wraz z jakościa˛ oprogramowania o otwartym źródle. Zwróćmy uwag˛e, że z wcześniejszego założenia, że
θMOSS −t
θ2 L−8wt
jest wi˛ekszy od zera
(przy analizie równania (2.16)) wynika, że cena równowagi także jest wi˛eksza od zera. Możemy
podstawić oba te wyniki do równania na popyt przedsi˛ebiorstwa, żeby sprawdzić jak te dwa
efekty – zwi˛ekszenie jakości powodujace
˛ wi˛ekszy popyt i wyższa cena majaca
˛ efekt odwrotny –
wpłyna˛ na wielkość popytu:
1 2wθMOSS + 2wt − 12 θ2 L
θMOSS − 2wt
D(MOSS ) = L
+
= 2wL
2
θ2 L − 8wt
θ2 L − 8wt
(2.23)
I widzimy, że efekt wzrostu jakości jest silniejszy niż wzrostu cen – popyt na produkty przedsi˛ebiorstwa wzrośnie! Sprawdźmy jaki wpływ ma jakość oprogramowania o otwartym źródle na
zysk przedsi˛ebiorstwa – podstawiamy równanie (2.16) i (2.23) do (2.12):
π(MOSS ) =
2
2
8w2 θtL(θMOSS
− 2tMOSS ) − wθ2 L2 (θ2 MOSS
− 2θtMOSS + t2 )
(θ2 L − 8wt)2
Policzmy pochodna˛ czastkow
˛
a˛ zysku po jakości oprogramowania o otwartym źródle:
16w2 θ2 tLMOSS − 16w2 θt2 L − 2wθ2 l2 MOSS + 2θ3 L3 tw
∂π
=
∂MOSS
(θ2 L − 8wt)2
60
(2.24)
Po uporzadkowaniu
˛
i uproszczeniu otrzymujemy:
∂π
t − θMOSS
= 2wθL
∂MOSS
θ2 L − 8wt
Ponieważ
θMOSS −t
θ2 L−8wt
(2.25)
> 0, wi˛ec pochodna zysku po jakości OSS jest ujemna. Zgodnie z intuicja˛
im wyższa jest jakość wolnego oprogramowania, tym słabsza˛ pozycj˛e strategiczna˛ ma przedsi˛ebiorstwo komercyjne i może sobie pozwolić na mniejsze zyski.
Warto si˛e jeszcze zastanowić, jak powstanie i wzrost jakości wolnego oprogramowania wpływa
na użyteczność użytkowników. Użytkownicy wolnego oprogramowania w oczywisty sposób na
tym zyskuja.˛ Natomiast skutek dla użytkowników oprogramowania komercyjnego jest niejasny
i wymaga analizy. Po podstawieniu wzorów (2.16) i (2.22) do (2.8) otrzymujemy:
θMOSS − t
2
− t(1 − x)
UCSS (x) = (θ L − 4wt)
θ2 L − 8wt
Po policzeniu pochodnej czastkowej
˛
po MOSS otrzymujemy:
2
∂UCSS
θ L − 4wt
=θ
∂MOSS
θ2 L − 8wt
(2.26)
Znak tej pochodnej nie jest ustalony. Zauważmy jednak, że dla rynków z dobrze rozwini˛etym
oprogramowaniem OSS, z małym kosztem transportowym (zróżnicowaniem klientów) i duża˛
użytecznościa˛ z oprogramowania, czyli takimi z jakimi mamy do czynienia, b˛edzie spełniona
nierówność MOSS >
t
.
θ
Ponieważ założyliśmy nieujemność
θMOSS −t
,
θ2 L−8wt
wyrażenie θ2 L − 8wt
także b˛edzie nieujemne, czyli pochodna b˛edzie dodatnia. W opisanych okolicznościach nawet użytkownicy oprogramowania komercyjnego b˛eda˛ zyskiwali na rozwoju oprogramowania
o otwartym źródle.
2.7. Wnioski z modelu
W powyższym modelu starałem si˛e zbadać analitycznie niektóre zjawiska wyst˛epujace
˛ przy
tworzeniu wolnego oprogramowania. Założyłem, że oprogramowanie komputerowe jest dobrem skomplikowanym, majacym
˛
wiele możliwych funkcjonalności, trudnym do wytworzenia
i zagwarantowania niezawodności. Wykorzystałem standardowy model „liniowego miasta” do
uchwycenia różnego podejścia programistów-amatorów piszacych
˛
programy dla siebie, dla pokazania swojego kunsztu kolegom po fachu, od firm komputerowych, chcacych
˛
zyskać jak najszersze grono odbiorców, najcz˛eściej tych niezaawansowanych.
61
Przy rozsadnych
˛
wartościach parametrów na rynku ukształtuje si˛e równowaga, w której rozwiazania
˛
komercyjne i wolne b˛eda˛ współistniały, każde majac
˛ swoich zwolenników. Analizujac
˛
oprogramowania o otwartym źródle wziałem
˛
pod uwag˛e zjawisko free riding, czyli sytuacj˛e, gdy
użytkownik, zamiast samemu dodać do programu brakujac
˛ a˛ jego zdaniem funkcjonalność, czeka
w nadziei że zrobi to ktoś inny. Zgodnie z intuicja˛ pokazałem, że gdy projekt jest w fazie wst˛epnej, czyli zostało zrealizowanych bardzo niewiele potencjalnych funkcjonalności, zjawisko free
riding w ogóle nie wyst˛epuje. Dopiero gdy jakość oprogramowania si˛e zwi˛ekszy, poświ˛ecenie
programistów spada. Co ciekawe, pokazałem że jest pewna „graniczna” jakość wolnego oprogramowania, wynikajaca
˛ z relacji kosztów rozwoju oprogramowania do użyteczności z niego,
powyżej której programiści nie widza˛ sensu dalej rozwijać programu. Wnioski z mojego modelu potwierdzaja˛ słuszność pogladów
˛
nieformalnych liderów wolnego oprogramowania, którzy
podkreślaja˛ pozytywny efekt zaangażowania wyspecjalizowanych firm komercyjnych w rozwój
oprogramowania o otwartym źródle12 . Firmy takie, by maksymalizować swój zysk zwiazany
˛
z
wi˛eksza˛ popularnościa˛ wolnego oprogramowania13 , samodzielnie rozwijaja˛ niektóre porzucone
przez programistów funkcjonalności lub zmniejszaja˛ koszty rozwoju wolnego oprogramowania,
oferujac
˛ np. miejsce i odp. serwisy na swoich serwerach14 . Gdy koszty si˛e zmniejsza,˛ programiści maja˛ motywacj˛e do dalszego rozwoju.
Rozwój wolnego oprogramowania wpływa także na firm˛e komercyjna.˛ Traci ona pozycj˛e
monopolisty i musi si˛e bronić przed darmowym konkurentem. Okazuje si˛e, że firma podnosi
zarówno jakość jak i cen˛e swojego produktu7, zyskujac
˛ rynek, ale tracac
˛ zyski. Przy wystarczajaco
˛ dobrym oprogarmowaniu o otwartym źródle wszyscy użytkownicy oprogramowania (także
komercyjnego) na tym zyskuja.˛ Mój model potwierdza zatem zasadność wspierania rozwoju
wolnego oprogramowania przez Uni˛e Europejska˛ oraz poszczególne państwa członkowskie –
powoduje to wi˛eksza˛ użyteczność ludności kosztem istniejacej
˛ firmy monopolistycznej.
12
13
Stallman, The Free Software Definition; Perens, Open Source Definition.
Firmy moga˛ w różny sposób zarabiać na wolnym oprogramowaniu – tworzac
˛ dystrybucje (czyli gotowe do
zainstalowania produkty zawierajace
˛ odp. dobrane portfele różnych wolnych projektów), oferujac
˛ usługi serwisowodoradcze, sprzedajac
˛ dedykowany sprz˛et, etc.
14
Usługi takie oferuje np. VA Software Corporation, posiadacz (za pośrednictwem spółki zależnej Open Source
Development Network, Inc.) portalu SourceForge.net
62
Rozdział 3
Wnioski
W niniejszej pracy starałem si˛e przybliżyć czytelnikowi oprogramowanie o otwartym źródle.
Dokonałem analizy motywacji programistów rozwijajacych
˛
to oprogramowanie, oraz firm starajacych
˛
si˛e znaleźć nisz˛e rynkowa˛ oferujac
˛ dobra komplementarne do tego oprogramowania.
Starałem si˛e przekonać czytelnika, że wolne oprogramowanie nie jest tylko nieznaczac
˛ a˛ „zabawka”
˛ grupy hobbystów, ale jest produktem konkurencyjnym do najlepszych systemów komputerowych oferowanych przez firmy komercyjne. Obserwujemy, chociażby artykułach na ten
temat coraz cz˛eściej pojawiajacych
˛
si˛e w prasie, że oprogramowanie o otwartym źródle staje si˛e
ważnym elementem rzeczywistości, dlatego zasadne jest przeprowadzić badania ekonomiczne
tego fenomenu.
Zaproponowałem mikroekonomiczny model badajacy
˛ konkurencj˛e pomi˛edzy firma˛ komercyjna˛ a wolnym oprogramowaniem. Pokazałem, że w momencie pojawienia si˛e wolnego oprogramowania i jego rozwoju (daż
˛ acego
˛
do punktu równowagi), wszyscy użytkownicy oprogramowania zyskaja.˛ Jedynym poszkodowanym b˛edzie firma komercyjna. Przedstawiłem dodatkowo analiz˛e wpływu pomocy egzogenicznej (jak rzad
˛ państwa czy firma komputerowa oferujaca
˛ swoje produkty na rynku komplementarnym) dla wolnego oprogramowania. Udowodniłem
w oparciu o model, że taka pomoc z zewnatrz
˛ stymuluje rozwój oprogramowanie o otwartym
źródle, pozwala mu si˛e bardziej rozwinać.
˛
W ramach niniejszej pracy nie zmieściła si˛e niestety analiza rynku przy założeniu, że firma
z produktem komplementarnym do wolnego oprogramowania jest agentem endogenicznym modelu. Podejście takie byłoby bardzo ciekawe, gdyż firma komercyjna produkujaca
˛ oprogramowanie o zamkni˛etym źródle, oferuje najcz˛eściej także usługi komplementarne. Na rynku oprogramowania firma taka jest bezpośrednim konkurentem samego oprogramowania o otwartym
63
źródle, zaś na rynku usług firmy wspomagajacej
˛ wolne oprogramowanie. Kolejna˛ kwestia˛ warta˛
dalszych badań jest dogł˛ebna analiza organizacyjna procesu powstawania wolnego oprogramowania, uwzgl˛edniajaca
˛ struktur˛e przepływu informacji, koszty transakcyjne czy inne koszty charakterystyczne dla tej formy powstawania oprogramowania. Można by porównać efektywność
tej metody z odpowiednia˛ stosowana˛ w przedsi˛ebiorstwach informatycznych.
64
Bibliografia
Asklund, Ulf/Bendix, Lars: Configuration Management for Open Source Software.
Benkler, Yochai: Coase’e Penguin, or, Linux and The Nature of the Firm. aug 2002
Bessen, James: Open Source Software: Free Provision of Complex Public Goods. may 2001
Bessen, James/Hunt, Robert M.: An Empirical Look at Software Patents. jul 2003
Brooks, Frederick P.:
Mityczny osobomiesiac.
˛ Warszawa:
Wydawnictwa Naukowo-
Techniczne, 2000
Coase, R. H.: The Nature of the Firm. 1937
Debian: Debian Free Software Guideliness. 1995 hURL: http://www.debian.org/
social_contract#guidelinesi
Hann, Il-Horn et al.: Delayed Returns to Open Source Participation: An Empirical Analysis of
the Apache HTTP Server Project. mar 2002
Harhoff, Dietmar/Henkel, Joachim/Hippel, Eric von: Profiting from voluntary information
spillovers: How users benefit by freely revealing their innovations. 2000
Hippel, Eric von: Open Source Shows the Way: Innovation by and for Users – No Manufacturer
Required! Sloan Management Review 2001
Hippel, Eric von/Krogh, Georg von: Open Source Software and the “Private-Collective” Innovation Model: Issues for Organization Science. Organization Science, 14 2003, Nr. 2,
209–223
Jackson, Ian: Why is software freedom useful, and what does it mean? nov 1998
65
Johnson, Justin Pappas: Economics of Open Source Software. 2001
Koek, Mark: Free Software Licensing. jun 1999
Kuan, Jennifer: Open Source Software as Lead User’s Make or Buy Decision: A Study of Open
and Closed Source Quality.
Lee, Samuel/Moisa, Nina/Weiss, Marco: Open Source as a Signalling Device – An Economic
Analysis. mar 2003
Lerner, Josh/Tirole, Jean: The Simple Economics of Open Source. dec 2000
Lerner, Josh/Tirole, Jean: The Scope of Open Source Licensing. nov 2002
Netcraft: Web Server Survey. hURL: http://news.netcraft.com/archives/web_
server_survey.htmli
Oliva, Alexandre: The Competitive Advantages of Free Software. aug 2001 hURL: http:
//www.ic.unicamp.br/~oliva/i
Perens, Bruce: Open Source Definition. 1997 hURL: http://www.opensource.org/
docs/definition.phpi
Raymond, Eric S.: The Cathedral and the Bazaar. aug 2000
Raymond, Eric S.: Homeseading the Noosphere. aug 2000
Raymond, Eric S.: The Magic Cauldron. aug 2000
Schmidt, Klaus M./Schnitzer, Monika: Public Subsidies for Open Source? Some Economic
Policy Issues of the Software Market. 2002
Stallman, Richard: Categories of Free and Non-Free Software. hURL: http://www.gnu.
org/philosophy/categories.htmli
Stallman, Richard: Dlaczego termin „Free Software” jest lepszy niż „Open Source”.
Stallman, Richard:
The Free Software Definition. hURL: http://www.gnu.org/
philosophy/free-sw.htmli
Stiglitz, Joseph E.: Information and the change in the paradigm in economics. dec 2001
66
Xu, Xiaopeng: Development costs and open source software.
67