Przedmowa
Dlaczego powstała ta książka?
Na różnych spotkaniach ludzie już nie gapią się na mnie pustym
wzrokiem, gdy mówię im, że piszę wolne oprogramowanie. "Ach tak, otwarte
oprogramowanie - coś jak Linux?" - mówią. Skwapliwie potwierdzam: "Tak,
dokładnie! Tym się właśnie zajmuje." Miło nie być już uznawanym za
kompletnego wariata. Dawniej następne pytanie było zazwyczaj łatwe do
przewidzenia: "Jak ty na tym zarabiasz?" Żeby odpowiedzieć musiałbym
przybliżyć im ekonomię otwartego oprogramowania: że istnieją organizacje,
w których interesie jest, aby pewne oprogramowanie istniało, ale nie muszą
sprzedawać jego kopii. Chcą tylko by oprogramowanie było dostępne i
utrzymywane, jako narzędzie a nie jako towar.
Jednak ostatnio kolejne pytanie już nie zawsze dotyczy pieniędzy.
Biznesowe wykorzystanie otwartego oprogramowaniaTerminy
"otwarte oprogramowanie" oraz "wolne oprogramowanie" w
tym kontekście są właściwie synonimami; zostały one dokładniej omówione
w w . nie jest już tak
tajemnicze, a ludzie nie zajmujący się programowaniem rozumieją—lub
przynajmniej nie są zaskoczeni— że do rozwoju takiego oprogramowania
zatrudnia się ludzi na pełny etat. Zamiast tego następne pytanie, które
słyszę coraz częściej, brzmi "Och, a jak to działa?"
Nie miałem pod ręką dobrej odpowiedzi na to pytanie, a im bardziej
próbowałem do niej dojść, tym wyraźniej zdawałem sobie sprawę jak bardzo
ta kwestia jest skomplikowana. Prowadzenie projektu związanego z wolnym
oprogramowanie nie polega dokładnie na tym samym, co działalność
biznesowa (wyobraź sobie ciągłą konieczność negocjowania natury produktu
z grupą ochotników, których w większości nie miałeś okazji spotkać!). Z
różnych powodów nie jest również tożsame z prowadzeniem tradycyjnej
organizacji niedochodowej czy rządowej. Prowadzenie projektów tego typu
ma wiele podobieństw do wszystkich tych rzeczy, ale stopniowo doszedłem
do wniosku że wolne oprogramowanie jest sui
generis. Jest wiele rzeczy, do których można je
sensownie porównywać, ale żadna z nich nie jest z nim identyczna. W
rzeczy samej, nawet założenie że projekt takiego typu można "prowadzić"
jest uproszczeniem. Wolny projekt można rozpocząć i
mogą na niego wpływać zainteresowane strony, zazwyczaj dosyć mocno.
Jednak sam w sobie nie może stać się własnością żadnego pojedynczego
posiadacza, i dopóki gdzieś—gdziekolwiek—istnieją osoby
zainteresowane jego kontynuowaniem, to nie da się go zamknąć
jednostronną decyzją. Każdy ma nieograniczoną władzę; nikt nie ma
władzy. Tworzy to interesującą dynamikę.
To właśnie sprawiło, że chciałem napisać tę książkę. Projekty
wolnego oprogramowania wytworzyły własną kulturę, etos, w którym wolność
tworzenia oprogramowania, które robi czego tylko się zapragnie, stała
się kwestią nadrzędną, a jednak efektem tej wolności nie jest
rozpraszanie się jednostek, z których każda idzie własną drogą, ale
entuzjastyczna współpraca. W rzeczy samej—umiejętność kooperacji jest
jedną z najwyżej cenionych zdolności w ruchu wolnego oprogramowania.
Zarządzanie takimi projektami polega na zaangażowaniu się w przerośnięty
system współpracy, w którym umiejętność nie tylko pracy z innymi, ale
także dochodzenia do nowych sposobów wspólnej pracy, może owocować
namacalnymi korzyściami dla oprogramowania. Książka ta stara się opisać
techniki, jakie są używane w tym celu. W żadnym wypadku nie jest
kompletnym ich podręcznikiem, ale przynajmniej punktem wyjścia.
Dobre wolne oprogramowanie jest wartościowym celem samym w sobie i
mam nadzieję, że czytelnicy, którzy szukają wskazówek jak to osiągnąć,
będą usatysfakcjonowani tym co tutaj znajdą. Mam jednak także nadzieję,
że udało mi się przekazać coś z czystej przyjemności, którą daje praca
z umotywowanym zespołem twórców open source oraz kontakty z
użytkownikami w ten cudownie bezpośredni sposób, do jakiego zachęca otwarte
oprogramowanie. W końcu uczestniczenie w udanych projektach wolnego
oprogramowania jest zabawą, i dlatego cały ten
system działa.
Kto powinien przeczytać tę książkę?
Niniejsza książka jest przeznaczona dla twórców oprogramowania i
menedżerów, którzy biorą pod uwagę rozpoczęcie projektu open source lub
właśnie takowy zaczęli i zastanawiają się co dalej. Powinna być także
przydatna dla osób, które po prostu chcą uczestniczyć w projekcie open
source, a jeszcze nigdy dotąd tego nie robili.
Czytelnik niekoniecznie musi być programistą, powinien jednak
posiadać podstawową wiedzę o takich pojęciach z zakresu inżynierii
oprogramowania jak kod źródłowy, kompilatory i łatki.
Wcześniejsze doświadczenie związane z oprogramowaniem open source,
czy to jako użytkownik, czy też programista, nie jest konieczne. Ci,
którzy brali już udział w projektach open source, mogą uznać pewne
części tej książki za oczywiste i zapewne zechcą je pominąć. Mając na
uwadze fakt potencjalnie tak szerokiego zakresu doświadczeń czytelników,
postarałem się jasno oznaczać sekcje i dawać znać, które znane już
kwestie można ominąć.
Źródła
Wiele materiałów źródłowych w tej książce zebrałem w trakcie
pięciu lat pracy w projekcie Subversion (). Subversion to system kontroli
wersji oparty na zasadach open source, napisany od początku i
zaprojektowany jako następca CVS w roli de
facto standardowego systemu kontroli wersji w
społeczności open source. Projekt został założony przez mojego
pracodawcę, CollabNet (), na
początku roku 2000, i na szczęście CollabNet od samego początku rozumiał
jak poprowadzić go jako naprawdę rozproszony system współpracy. Wielu
ochotników wcześnie w to weszło; obecnie w projekcie jest około 50
współtwórców, z których tylko kilku jest pracownikami CollabNet.
Subversion jest pod wieloma względami klasycznym przykładem
projektu open source i wspominam o nim o wiele częściej niż zakładałem
na początku. Po części jest to kwestia wygody: gdy tylko szukałem
przykładu danego zjawiska, to zwykle mogłem się natychmiast odwołać do
Subversion. Ponadto była to również kwestia sprawdzalności. Mimo, że
byłem w różnym stopniu zaangażowany w inne projekty wolnego
programowania i rozmawiałem ze znajomymi oraz uczestnikami wielu innych
projektów, to zauważyłem, że gdy pisze się pod kątem druku, to wszelkie
założenia muszą być sprawdzone. Nie chciałem wypowiadać się na temat
wydarzeń w innych projektach w oparciu tylko o to, co mogłem przeczytać
w archiwach publicznych grup dyskusyjnych. Gdyby ktoś zastosował taką
metodą w przypadku Subversion, to zapewne w połowie miałby rację, a w
połowie nie. Zatem gdy inspirowało mnie coś lub brałem przykłady z
projektów, z którymi nie miałem bezpośrednich doświadczeń, to próbowałem
najpierw zweryfikować te dane przez informatora w tym projekcie, kogoś,
do kogo mam zaufanie, że powie mi o co rzeczywiście chodziło.
Praca nad Subversion była moim zajęciem przez ostatnie 5 lat, ale
z wolnym oprogramowaniem jestem związany od 12. Inne projekty, które
miały wpływ na tę książkę to między innymi:
Projekt edytora GNU Emacs przy Free
Software Foundation, w którym zajmuję się kilkoma małymi
pakietami.
Concurrent Versions System
(CVS), nad którym pracowałem intensywnie w latach 1994-1995 z Jimem
Blandym, ale od tego czasu angażowałem się tylko sporadycznie.
Zbiór projektów open source znanych jako
Apache Software Foundation, głównie Apache Portable Runtime (APR) i
serwer HTTP Apache.
OpenOffice.org,
baza danych Berkeley od Sleepycat i baza danych MySQL; nie byłem w tych
projektach zaangażowany osobiście, obserwowałem je jednak i - w
niektórych - przypadkach, rozmawiałem z zaangażowanymi osobami.
GNU Debugger (GDB) (jak wyżej).
Projekt Debian (jak wyżej).
Oczywiście powyższa lista nie jest kompletna. Jak większość
programistów open source trzymam rękę na pulsie różnych projektów, by
wiedzieć co w trawie piszczy. Nie wymienię ich wszystkich tutaj z nazwy,
ale wspominam o nich w odpowiednich miejscach w tekście.
Podziękowania
Napisanie tej książki zajęło mi czterokrotnie więcej czasu niż się
spodziewałem i przez większość tego czasu, cokolwiek robiłem, czułem
jakby nad moją głową wisiał fortepian. Bez pomocy wielu ludzi nie dałbym
rady ukończyć jej pozostając przy zdrowych zmysłach.
Andy Oram, mój wydawca w wydawnictwie O'Reilly, był marzeniem
pisarza. Poza gruntowną wiedzą na tym polu (zasugerował mi wiele
tematów) ma rzadki dar zgadywania, co chce się powiedzieć, i pomagania w
znalezieniu właściwego sposobu wyrażenia tego. Praca z nim była dla mnie
zaszczytem. Dzięki również dla Chucka Toporka za natychmiastowe
skierowanie tej propozycji do Andy'ego.
Brian Fitzpatrick sczytywał niemal cały materiał w trakcie jego
powstawania, co nie tylko uczyniło książkę lepszą, ale też zmuszało mnie
do pisania w chwilach, gdy wolałem być gdziekolwiek indziej, byle nie
przed komputerem. Ben Collins-Sussman i Mike Pilato także śledzili moje
postępy i zawsze byli gotowi rozmawiać - czasem szczegółowo - na dowolny
temat, na który starałem się pisać w danym tygodniu. Zwracali też uwagę
kiedy traciłem tempo i delikatnie popędzali mnie, gdy było to konieczne.
Dzięki, chłopaki.
Biella Coleman pisała swoją dysertację w tym samym czasie, gdy ja
pisałem tę książkę. Ona wie, co to znaczy siadać i pisać przez cały
dzień, i była dla mnie inspirującym przykładem oraz życzliwym
słuchaczem. Ma także fascynujący wgląd w ruch wolnego oprogramowania
okiem antropologa, co dostarczało mi zarówno pomysły jak i odniesienia,
które zdołałem wykorzystać w tej książce. Alex Golub - inny antropolog
jedną nogą tkwiący w świecie wolnego oprogramowania i także kończący
swoją dysertację w tym samym czasie - był niezwykle pomocny od samego
początku, co ogromnie mi pomogło.
Micah Anderson w jakiś sposób nigdy nie sprawiał wrażenia zbyt
przytłoczonego własnym maratonem pisania, co było inspirujące w chory,
wywołujący zazdrość sposób, ale zawsze gotów był służyć swoją
przyjaźnią, rozmową i (przynajmniej w jednym wypadku) pomocą techniczną.
Dzięki, Micah!
Jon Trowbridge i Sander Striker udzielali mi zarówno zachęty jak i
konkretnej pomocy - ich bogate doświadczenie w kwestiach wolnego
oprogramowania dostarczyło mi materiału, którego nie mógłbym zdobyć w
żaden inny sposób.
Dzięki dla Grega Steina nie tylko za jego przyjaźń i zachętę w
najbardziej odpowiednich chwilach, ale też za pokazanie w projekcie
Subversion jak ważne są regularne przeglądy kodu w budowaniu
społeczności programistów. Dzięki także Brianowi Behlendorfowi, który
taktownie wbijał nam do głów znaczenie prowadzenia dyskusji publicznie;
mam nadzieję, że ta zasada znalazła swoje odzwierciedlenie w tej
książce.
Dzięki Benjaminowi "Mako" Hillowi i Sethowi Schoenowi za różne
rozmowy o wolnym oprogramowaniu i jego zagadnieniach politycznych;
Zackowi Urlockerowi i Louisowi Suarez-Potts za poświęcenie czasu z ich
wypełnionych planów na udzielenie wywiadów; Shanowi z listy Slashcode za
zgodę na zacytowanie jego wiadomości oraz Haggenowi So za jego
nadzwyczaj pomocne porównanie canned-hostingu.
Dzięki dla Alli Dekhtyar, Poliny i Soni za ich nie afiszującą się
i cierpliwą zachętę. Bardzo się cieszę, że już nie będę musiał kończyć
(lub raczej bez powodzenia próbować kończyć) naszych wieczorów wcześnie,
aby wrócić do domu i pracować nad "tą książką".
Dzięki dla Jacka Repenninga za przyjaźń, rozmowy i upartą odmowę
zaakceptowania łatwej, ale niesłusznej analizy, kiedy dostępna jest
trudniejsza, ale właściwa. Mam nadzieję, że część z jego długiego
doświadczenia zarówno z rozwijaniem oprogramowania jak i branżą
programistyczną odcisnęła w tej książce swój ślad.
CollabNet był niezwykle hojny pozwalając mi w elastyczny sposób
planować czas na pisanie i nie miał pretensji gdy trwało to dłużej niż
początkowo zamierzałem. Nie znam wszystkich zawiłości na drodze do
podejmowania przez szefostwo takich decyzji, ale podejrzewam, że Sandhya
Klute, a następnie Mahesh Murthy, mieli z tym coś wspólnego - moje
podziękowania dla nich obu.
Cały zespół rozwijający Subversion był dla mnie inspiracją przez
ostatnie pięć lat, i większość tego, co znalazło się w tej książce,
nauczyłem się dzięki pracy z nimi. Nie będę im tu dziękował po nazwisku,
ponieważ jest ich zbyt wielu, ale nalegam aby każdy czytelnik, który
spotka członka tego zespołu, aby postawił mu ulubionego drinka - ja na
pewno zamierzam tak zrobić.
Wielokrotnie uskarżałem się Rachel Scollon na temat stanu tej
książki; zawsze była gotowa mnie wysłuchać i jakimś sposobem potrafiła
czynić problemy mniejszymi niż to było zanim z nią rozmawiałem. Bardzo
mi to pomogło - dzięki.
Dzięki (znowu) dla Noela Taylora, który na pewno był ciekaw
dlaczego chciałem napisać kolejną książkę, pamiętając jak bardzo
narzekałem ostatnim razem, ale którego przyjaźń i dowodzenie "Golosem"
pozwalało muzyce grać dalej, oraz za braterstwo nawet w najbardziej
wypełnionych pracą momentach. Dzięki również dla Matthew Deana i
Dorothei Samtleben, przyjaciół i starych partnerów muzycznych, którzy
byli bardzo wyrozumiali, gdy moje wymówki w kwestii braku prób zaczynały
się spiętrzać. Megan Jennings była mi przez cały czas wsparciem i
szczerze interesowała się tematem, mimo że był jej obcy - wspaniałe
wzmocnienie dla niepewnego pisarza. Dzięki, kumpelko!
Miałem czwórkę znających się na rzeczy i skrupulatnych recenzentów
tej książki, byli to: Yoav Shapira, Andrew Stellman, Davanum Srinivas i
Ben Hyde. Gdybym był w stanie uwzględnić wszystkie ich wspaniałe
sugestie, to ta książka byłaby lepsza. W praktyce ograniczenia czasowe
zmusiły mnie do wybierania, ale ich poprawki i tak były znaczące. Błędy,
które w niej pozostały, są wyłącznie moje.
Moi rodzice, Frances i Henry, jak zwykle dawali mi cudowne
wsparcie, a ponieważ ta książka jest mniej techniczna niż poprzednie, to
żywię nadzieję, że uznają ją za bardziej nadającą się do
czytania.
Chciałbym wreszcie podziękować dwojgu osobom, którym dedykuję tę
książkę, Karen Underhill i Jimowi Blandy'emu. Przyjaźń Karen i jej
zrozumienie znaczyły dla mnie wszystko, nie tylko w trakcie pisania tej
książki, ale przez ostatnie siedem lat. Po prostu nie dobrnąłbym do
końca bez jej pomocy. Podobnie Jimowi, prawdziwemu przyjacielowi i
hakerowi nad hakerami, który jako pierwszy uczył mnie wolnego
oprogramowania, tak jak ptak mógłby uczyć samolot latania.
Zastrzeżenie
Myśli i opinie wyrażone w niniejszej książce są moje własne.
Niekoniecznie reprezentują stanowisko CollabNet czy projektu
Subversion.