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. 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ąć. 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. 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. Myśli i opinie wyrażone w niniejszej książce są moje własne. Niekoniecznie reprezentują stanowisko CollabNet czy projektu Subversion.