Katedra i bazar

Linux jest wywrotowy. Kto by pomyślał nawet pięć lat temu (w 1991 roku), że z pracy rozproszonych po całym świecie programistów połączonych cienkimi przewodami Internetu i hakujących{1} w wolnych chwilach wyłoni się w niemal magiczny sposób światowej klasy system operacyjny?

Na pewno nie ja. Kiedy Linux pojawił się na ekranie mojego radaru na początku 1993 roku, moje zaangażowanie w rozwój oprogramowania uniksowego i open source trwało już ponad dziesięć lat. Byłem jedną z osób pracujących nad projektem GNU{2} w połowie lat osiemdziesiątych. Udostępniłem w Internecie wiele programów open source, pracując samemu i z innymi nad rozwojem wielu programów używanych do dziś (takich jak nethack{3}, tryb VC i GUD dla Emacsa{4}, xlife i inne). Byłem przekonany, że wiem, jak to się robi.

Linux wywrócił to przekonanie do góry nogami. Przez wiele lat głosiłem uniksową ewangelię małych narzędzi, szybkiego prototypowania i programowania ewolucyjnego. Wierzyłem jednak, że istnieje pewien punkt krytyczny złożoności, powyżej którego musi się zastosować bardziej scentralizowane podejście a priori. Uważałem, że najważniejsze programy (systemy operacyjne i narzędzia naprawdę sporych rozmiarów, takie jak edytor dla programistów, Emacs) powinny powstawać jak katedry: budowane zręcznymi palcami samotnych czarodziei lub grupy dostojnych magów pracujących w pełnym namaszczenia odosobnieniu, bez wersji beta udostępnianych przed czasem.

Styl rozwoju oprogramowania zaproponowany przez Linusa Torvaldsa, "wypuszczaj nowe wersje wcześnie i często, bądź otwarty, wręcz bliski rozwiązłości", był dla nas sporą niespodzianką. Zamiast budować katedrę w pełnej skupienia ciszy, społeczność linuksowa przypominała jeden wielki hałaśliwy bazar, pełen różnych poglądów i planów (co doskonale reprezentują serwery z archiwami linuksowymi, przyjmujące programy od każdego), z którego, jak się wydawało, spójny i stabilny system mógłby wynurzyć się tylko cudem.

Bardzo zaskoczył nas fakt, że ten bazarowy styl działał, i to działał dobrze. Kiedy nabrałem doświadczenia, nie tylko ciężko pracowałem nad pojedynczymi projektami, lecz również bardzo starałem się zrozumieć dlaczego linuksowy świat nie rozpadł się na kawałki w wielkim zamieszaniu, ale rośnie w siłę z prędkością niewyobrażalną dla budowniczych katedr.

W połowie 1996 roku stwierdziłem, że zaczynam rozumieć. Przypadek dostarczył mi doskonałego sposobu na sprawdzenie mojej teorii: projektu open source, który mogłem rozwijać w bazarowym stylu. Rozpocząłem więc nad nim pracę, która zakończyła się jednoznacznym sukcesem.

Na stronach tej książki opisuję historię tego projektu. Wykorzystałem ją by przedstawić kilka aforyzmów opisujących efektywny rozwój oprogramowania open source. Nie wszystkiego nauczyłem się w świecie linuksowym, jednak właśnie w nim niektóre sprawy nabrały szczególnej barwy. Jeśli mam rację, pomogą wam zrozumieć dlaczego społeczność linuksowa jest niewyczerpanym źródłem tak dobrego oprogramowania; być może sprawi też, że sami staniecie się bardziej twórczy. Poczta musi dojść

Od 1993 roku zajmowałem się techniczną stroną obsługi wolnodostępnego ISP{1}, zwanego Chester County InterLink (CCIL) w West Chester w Pensylwanii. (Byłem jednym z założycieli CCIL i autorem jedynego w swoim rodzaju programu BBS dla wielu użytkowników, z którym można się zapoznać telnetując się do locke.ccil.org; dzisiaj obsługuje ono niemal trzy tysiące użytkowników na dziewiętnastu liniach). Dzięki tej pracy miałem zapewniony 24-godzinny dostęp do Internetu; w praktyce było to nie tyle udogodnienie, co wymóg!

Przyzwyczaiłem sie więc do natychmiastowego otrzymywania poczty elektronicznej. Z powodów zbyt złożonych, by je tutaj wymieniać, trudno było nawiązać połączenie SLIP{6} między moim komputerem w domu (snark.thyrsus.com) a CCIL. Kiedy mi się w końcu udało, ciągłe logowanie się do locke w celu odczytania poczty stało się denerwujące. Chciałem jedynie, żeby moja poczta znalazła się na snarku, o czym mógłbym być powiadamiany i pokierować nią dalej używając narzędzi znajdujących się na mojej maszynie.

Zwykłe przekazywanie poczty przy użyciu sendmaila{7} nie wystarczało, ponieważ mój komputer nie zawsze jest widoczny w sieci i nie ma statycznego adresu IP{8}. Potrzebowałem programu, który połączyłby się z locke przez SLIP, pobrał pocztę i dostarczył ją do mojego komputera. Wiedziałem, że istnieją tego typu narzędzia i że większość z nich używała prostego protokołu zwanego POP (Post Office Protocol, protokół pocztowy). Oczywiście do systemu operacyjnego locke, BSD/OS, dołączono serwer POP3.

Potrzebowałem klienta POP3. Zacząłem więc szukać w Internecie i znalazłem. Szczerze mówiąc znalazłem trzy czy cztery takie narzędzia. Przez pewien czas używałem pop-perl, jednak brakowało mu niezbędnej funkcji: zdolności podmiany adresów w taki sposób, by można było bez problemów odpowiadać na listy.

Na czym polegał problem? Załóżmy, że otrzymałem list od użytkownika z locke o nazwie "joe". Pobierałem pocztę z locke, lecz kiedy próbowałem na nią odpowiedzieć, mój program pocztowy próbował radośnie przekazać ją nieistniejącemu "joe" na snarku. Ręczna edycja adresów na "@ccil.org" wkrótce stała się uciążliwa.

Było to oczywiście coś, co komputer powinien robić za mnie, jednak żaden z istniejących klientów POP nie wiedział jak! W ten sposób doszliśmy do pierwszej lekcji:

• Dobrej jakości praca nad programem rozpoczyna się od tego, że programista drapie się tam, gdzie go swędzi. Może się to wydawać oczywiste (w końcu istnieje stare przysłowie "potrzeba matką wynalazku"), jednak zbyt często programiści spędzają życie harując przy tworzeniu programów, których ani nie potrzebują, ani nie kochają. Natomiast w świecie linuksowym sprawy mają się inaczej, co może wyjaśniać dlaczego średnia jakość oprogramowania powstającego w społeczności linuksowej jest tak wysoka. Czyżbym powinien w świetle powyższego od razu rzucić się w wir pracy nad nowym klientem POP3, który skutecznie konkurowałby z istniejącymi? Nigdy w życiu! Uważnie zbadałem istniejące narzędzia POP, którymi dysponowałem, zadając sobie pytanie: "które z nich najbardziej odpowiada moim potrzebom"? Bowiem

• Dobrzy programiści wiedzą co pisać. Wielcy wiedzą co przepisać (i powtórnie wykorzystać). I chociaż nie uważam się za wielkiego programistę, staram się takowych naśladować. Ważną cechą wielkich jest konstruktywne lenistwo. Wiedzą oni, że piątkę dostaje się nie za wysiłek, lecz za rezultat, zaś o wiele łatwiej jest zacząć od dobrego choć częściowego rozwiązania niż od zera.

  Weźmy Linusa Torvaldsa: nie próbował on napisać Linuksa od zera. Skorzystał natomiast z kodu i idei będących częścią Miniksa, miniaturowego systemu uniksowego dla procesorów 386{9}. W końcu całkowicie pozbyto się lub przepisano kod Miniksa, jednak dopóki to nie nastąpiło, był on kołyską dziecka, które później wyrosło na Linuksa.

  Mając to na uwadze zacząłem się rozglądać za istniejącym, dobrze napisanym narzędziem POP, które mógłbym wykorzystać za podstawę rozwoju swojego kodu.

  Uniksowa tradycja dzielenia się kodem zawsze była przychylna korzystaniu z kodu innych (dlatego właśnie Unix stał się podstawą projektu GNU, mimo poważnych zastrzeżeń w stosunku do samego systemu operacyjnego). Społeczność linuksowa przejęła tą tradycję i niemal dotarła do jej technologicznych granic: istnieją terabajty ogólnodostępnych aplikacji. Dlatego szukanie prawie-dobrego-programu ma większe szanse zakończyć się sukcesem w świecie linuksowym niż gdziekolwiek indziej.

  Tak też było i w moim przypadku. Łącznie z programami, które znalazłem wcześniej, po drugim poszukiwaniu miałem już dziewięciu kandydatów: fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail oraz upop. Najpierw zabrałem się za "fetchpop", napisanego przez Seung-Hong Oh. Dołączyłem do niego przepisywanie nagłówków swojego autorstwa oraz wiele innych ulepszeń, które autor zamieścił w wersji 1.9 programu.

  Jednak kilka tygodni później wpadł mi do ręki kod programu "popclient" Carla Harrisa i okazało się, że mam problem. Fetchpop, mimo kilku świetnych pomysłów (np. tryb demona), radził sobie jedynie z protokołem POP3 i był napisany w dość amatorski sposób (Seung-Hong był zdolnym lecz niedoświadczonym programistą i obie te cechy widać było w kodzie). Kod Carla był lepszy, jego program był solidnie i profesjonalnie napisany, jednak brakowało mu wielu istotnych i niełatwych do zaimplementowania funkcji fetchpopa (łącznie z tymi, które sam napisałem).

  Przesiąść się czy zostać? Przesiadając się pozbyłbym się kodu, który stworzyłem, za to uzyskałbym lepsze podstawy dla rozwoju kodu.

  Zdecydowałem się przesiąść z bardzo praktycznego powodu: popclient obsługiwał wiele protokołów. POP3 jest najpopularniejszym z protokołów wykorzystywanych w serwerach poczty elektronicznej, lecz bynajmniej nie jedynym. Zarówno fetchpop jak i pozostali konkurenci popclienta nie obsługiwały takich protokołów jak POP2, RPOP czy APOP, a już wtedy świtało mi w głowie, by dla zabawy dodać obsługę IMAP (Internet Message Access Protocol, niedawno zaprojektowany i najpotężniejszy protokół pocztowy).

  Miałem jednak również bardziej teoretyczne powody by myśleć, że taka przesiadka nie będzie zła; chodzi mianowicie coś, czego nauczyłem się na długo przed powstaniem Linuksa.

• "Pomyśl o tym, by się go pozbyć; i tak to zrobisz" (Fred Brooks, The Mythical Man-Month, Rozdział 11. W Polsce książka ta została wydana przez WNT pod tytułem "Mityczny osobomiesiąc. Eseje o inżynierii oprogramowania").

  Innymi słowy: często dzieje się tak, że nie rozumie się problemu do chwili, kiedy po raz pierwszy zaimplementuje się jego rozwiązanie. Natomiast za drugim razem być może rozumie się go na tyle, by zrobić to dobrze. Jeśli więc chce się zrobić to dobrze, należy być przygotowanym na rozpoczęcie prac od samego początku, przynajmniej raz.

  Pomyślałem sobie -- cóż, zmiany wprowadzone w fetchpopie były moją pierwszą próbą. Przesiadłem się więc.

  Po wysłaniu Carlowi Harrisowi pierwszego zbioru łat do popclienta okazało się, że autor praktycznie przestał się interesować swoim programem. Kod był nieco zakurzony, z niektórych miejsc wychodziły pluskwy. Chciałem wprowadzić wiele zmian, więc szybko doszliśmy do wniosku, że naturalną koleją rzeczy będzie przejęcie przeze mnie opieki nad programem.

  Niezauważalnie projekt rozwinął się. Nie byłem już osobą zastanawiającą się nad wprowadzeniem niewielkich zmian do istniejącego klienta POP. Stałem się opiekunem całego projektu i czułem, że pączkujące w mojej głowie pomysły prawdopodobnie zapoczątkują znaczące zmiany.

  Tak właśnie ewoluuje projekt w kulturze, która zachęca do dzielenia się kodem źródłowym. Postępowałem wedle następującej zasady:

• Jeśli masz odpowiednie nastawienie, spotkają cię interesujące problemy.

  Jednak ważniejsza była postawa Carla Harrisa. Zrozumiał on bowiem, że

• Kiedy tracisz zainteresowanie programem, twoim ostatnim obowiązkiem jest przekazać go kompetentnemu następcy.

  Nie było nawet potrzeby dyskusji; Carl i ja zdawaliśmy sobie sprawę z tego, że naszym wspólnym celem jest znalezienie najlepszego rozwiązania. Pozostawało jedynie wyjaśnić, czy projekt będzie bezpieczny w moich rękach. Kiedy udowodniłem że tak, Carl szybko i z wdziękiem przekazał mi prowadzenie projektu. Mam nadzieje, że postąpię tak samo, kiedy przyjdzie moja kolej. Jak ważni są użytkownicy

  W ten sposób odziedziczyłem popclienta. Co jest równie ważne, odziedziczyłem też użytkowników tego programu. Użytkownicy są czymś wspaniałym, nie tylko dlatego, że pokazują, iż służycie im w potrzebie, że zrobiliście coś dobrego. Jeśli się ich odpowiednio urobi, mogą pomóc w rozwoju projektu.

  Kolejną zaletą tradycji uniksowej, która w Linuksie osiągnęła swoje szczęśliwe ekstremum jest fakt, że wielu użytkowników jest również hakerami. Ponieważ kod źródłowy jest dostępny, mogą być skutecznymi hakerami, dzięki czemu okres odpluskwiania może ulec znacznemu skróceniu. Wystarczy ich nieco zachęcić, a będą badać przyczyny problemów, sugerować możliwe rozwiązania oraz pomagać w rozwoju kodu o wiele szybciej, niż nastąpiłoby to bez ich pomocy.

• Najkrótszą i najłatwiejszą drogą w kierunku szybkiego rozwoju kodu i efektywnego jego odpluskwiania jest traktowanie użytkowników jako osób uczestniczących w projekcie.

  Nietrudno zlekceważyć prawdziwość tego stwierdzenia. Chyba my wszyscy, żyjący w świecie open source, nie potrafiliśmy docenić jak dobrze projekt może się rozwijać wraz z liczbą użytkowników i wbrew rosnącej złożoności systemu; dopiero Linus Torvalds otworzył nam na to oczy.

  W mojej opinii najzmyślniejszą i najbardziej konsekwentną sztuczką Linusa nie było stworzenie jądra Linuksa, lecz wynalezienie modelu rozwoju tego systemu. Kiedy pewnego razy wyraziłem tę opinię w jego obecności, uśmiechnął się i cicho powiedział to, co zwykł często powtarzać: "W rzeczywistości jestem bardzo leniwą osobą, która lubi, by przypisywano jej to, co robią inni". Leniwy jak lis. Lub, jak to określił Robert Heinlen opisując jedną ze stworzonych przez siebie postaci, "zbyt leniwy by zawieść".

  Patrząc wstecz można zauważyć pewien precedens dla metod i sukcesu Linuksa w rozwoju biblioteki języka GNU Emacs Lisp oraz w archiwach z programami w Lispie. W przeciwieństwie do jądra Emacsa napisanego w C oraz innych narzędzi GNU, które tworzono w stylu przypominającym budowę katedry, ewolucja zbioru kodu Lispa była bardziej płynna i kierowana przez samych użytkowników. Pomysły i prototypy były często przepisywane trzy czy cztery razy, zanim przybrały ostateczną, stabilną formę. Nierzadkim zjawiskiem była luźna współpraca a` la Linux, którą umożliwił Internet.

  Moim pierwszym najbardziej udanym hackiem przed fetchmailem był prawdopodobnie tryb kontroli wersji w Emacsie, Emacs VC. Powstał on dzięki współpracy z trzema innymi osobami, z których do dziś poznałem tylko jedną (Richarda Stallmana, autora Emacsa i założyciela Free Software Foundation). Był to interfejs do takich programów jak SCCS, RCS, a później również CVS{10}, dzięki któremu można było dokonywać operacji związanych z kontrolą wersji przy pomocy skrótów klawiszowych. Kod ten rozwiną się z niewielkiego, topornego trybu sccs.el, który napisał ktoś inny. Udało nam się napisać VC dlatego, że w przeciwieństwie do samego Emacsa, kod Emacs Lisp mógł bardzo szybko przejść przez fazy "udostępnienia wersji", "testów" i "ulepszeń".

  Jednym z elementów polityki FSF były próby prawnego związania kodu z GPL. Niespodziewanie okazało się, że przez to trudniej jest korzystać z bazarowego trybu rozwoju, ponieważ FSF wymaga przepisania praw autorskich w przypadku dostarczenia kodu przekraczającego dwadzieścia linii, aby nie można go było zakwestionować z punktu widzenia prawa autorskiego. Dla ludzi korzystających z licencji BSD i MIT X Consortium problem ten nie istnieje: nie próbują oni zastrzec praw, które ktoś mógłby kiedyś zakwestionować{11}. Udostępniaj nowe wersje wcześnie i często

  Wczesne i częste udostępnianie nowych wersji jest kluczowym fragmentem linuksowego modelu rozwoju. Wielu programistów (w tym i ja) wierzyło, że tego typu praktyki gorzej się sprawdzają w wielkich niż małych projektach, ponieważ wczesne wersje są niemal z definicji zapluskwione, a nie jest naszą intencją nadwerężanie cierpliwości użytkowników.

  Przekonanie to wzmacniało zaangażowanie w styl rozwoju przypominający budowę katedry. Jeśli głównym celem jest troska o jak najmniejszą ilość błędów, nowe wersje udostępnia się nie częściej niż raz na pół roku, pracując w międzyczasie jak wół nad odpluskwianiem programu. W ten sposób powstało jądro Emacsa napisane w języku C. Inaczej było z biblioteką Lispa, ponieważ istniały archiwa z kodem w tym języku poza kontrolą FSF, gdzie można było znaleźć nowe i rozwojowe wersje kodu, niezależnie od cyklu udostępniania nowych wersji Emacsa.

  Najważniejszym z nich było archiwum elispa stanu Ohio, w którym można było znaleźć zalążek atmosfery oraz wiele cech dzisiejszych, ogromnych archiwów linuksowych. Jednak niewielu z nas zastanawiało się zbytnio nad tym, co robiliśmy, ani nad problemami wypływającymi z modelu rozwoju przyjętego przez FSF, których istnienie sugerowała sama obecność tego archiwum. W okolicach 1992 roku podjąłem poważniejszą próbę formalnego włączenia sporej części kodu do oficjalnej biblioteki Emacs Lispa. Napotkałem na problemy natury politycznej i w większości mi się nie udało.

  Jednakże rok później, kiedy Linux stawał się coraz bardziej widoczny, stało się jasne, że wokół niego dzieje się coś innego i zdrowszego. Otwarta polityka rozwoju, którą przyjął Linus, stała w jaskrawej opozycji do budowania katedr. Archiwa sunsite i tsx-11 rozkwitały, powstawały nowe dystrybucje. Wszystko to spowodowała niespotykana częstotliwość, z jaką ukazywały się nowe wersje jądra systemu.

  Linus traktował swoich użytkowników jako osoby uczestniczące w projekcie w najbardziej skuteczny sposób:

• Udostępniaj nowe wersje wcześnie i często. I słuchaj swoich klientów.

  Innowacja Linusa polegała nie tyle na prowadzeniu projektu w ten sposób (tego typu model istniał w tradycji uniksowej na długo wcześniej), co na ekspansji do poziomu intensywności odpowiadającej złożoności projektu, który rozwijał. W tych wczesnych latach (okolice roku 1991) zdarzało mu się wypuszczać nowe wersje jądra częściej niż raz dziennie! Ten model sprawował się dobrze, ponieważ Linus rozwijał bazę programistów i bardziej niż ktokolwiek inny wykorzystywał Internet jako narzędzie ułatwiające współpracę.

  Na czym polegał mechanizm tego typu współpracy? Czy było to coś, co mógłbym wykorzystać, czy raczej miało związek z niepowtarzalnym geniuszem Linusa Torvaldsa? Wydawało mi się, że nie. To prawda, Linus jest całkiem niezłym hakerem (ilu z nas dałoby radę zaprojektować kompletne jądro systemu operacyjnego nadające się do pracy?). Linux nie przedstawiał jednak żadnego zadziwiającego skoku koncepcyjnego. Linus nie jest (przynajmniej na razie) geniuszem innowacji tak jak, dajmy na to, Richard Stallman czy James Gosling (od NeWS i Javy). Uważam natomiast Linusa za geniusza jeśli chodzi o tworzenie oprogramowania, posiadającego szósty zmysł pomagający unikać błędów i ślepych zaułków, oraz prawdziwy talent w znajdowaniu wymagającej minimum wysiłku ścieżki z punktu A do punktu B. Cały projekt Linuksa wręcz oddycha tą właściwością i odzwierciedla podejście Linusa, które jest w istocie konserwatywne i opiera się na upraszczaniu projektu.

  Jeśli więc częste udostępnianie nowych wersji oraz maksymalne wykorzystanie Internetu jako medium nie było przypadkowe, lecz stanowiło integralną część geniusza Linusa, który polegał na poznaniu linii najmniejszego oporu, to co w takim razie rozwijał do granic możliwości? Co raz za razem wydobywał z tej maszynerii?

  Jeśli postawić pytanie w ten sposób, odpowiedź staje się oczywista. Linus stale stymulował i nagradzał swoich hakerów-użytkowników: stymulował wizją zadowalającego ego fragmentu akcji, nagradzał widokiem ciągłych (nawet codziennych) ulepszeń projektu.

  Bezpośrednim celem Linusa było maksymalne zwiększenie osobogodzin poświęcanych na odpluskwianie i rozwój jądra Linuksa, nawet kosztem potencjalnej niestabilności kodu i zmniejszenia zapału użytkowników w sytuacji, gdyby jakiś poważny błąd okazał się niemożliwy do wychwycenia. Linus zachowywał się jak gdyby wierzył, że:

• Jeśli tylko środowisko użytkowników i beta testerów{12} będzie odpowiednio duże, niemal każdy problem zostanie szybko zdefiniowany i znajdzie się rozwiązanie.

  Mówiąc mniej formalnie, "Gdzie wiele oczu, tam łatwo ujrzeć pluskwy". Nazwałem to stwierdzenie "Prawem Linusa".

  Na początku zawierało ono sformułowanie mówiące, że każdy problem "stanie się dla kogoś jasny". Linus nie zgodził się mówiąc, że osoba, która rozumie i rozwiązuje problem niekoniecznie jest, a nawet zwykle nie jest osobą, która pierwsza go opisała. "Ktoś znajduje problem", powiedział, "a ktoś inny go rozumie. Zaryzykuję stwierdzenie, że znalezienie go jest większym wyzwaniem". Jednak najistotniejsze jest to, że obie rzeczy zazwyczaj dzieją się bardzo szybko.

  Wydaje mi się, że na tym właśnie polega różnica między stylem katedry i bazaru. Z punktu widzenia budowniczego katedr, problemy związane z błędami i programowaniem są czymś głębokim, niełatwym do rozwiązania i nudnym. Trzeba miesięcy uważnych badań prowadzonych przez kilku programistów by mieć pewność, że wszystkie zostały usunięte. Stąd długie okresy między kolejnymi wersjami i nieuniknione rozczarowanie, kiedy okazuje się, że długo oczekiwana wersja nie jest doskonała.

  Natomiast z punktu widzenia bazaru pluskwy uważa się za zjawisko płytkie, a przynajmniej okazujące się czymś płytkim, kiedy tysiące zapalonych programistów rzuca się na każdą nowa wersję. Dlatego wersje te ukazują się często, aby zwiększyć liczbę poprawek{13}, czego dobroczynnym skutkiem ubocznym są mniejsze straty w razie wystąpienia przypadkowego błędu.

  I o to właśnie chodzi. To wszystko. Gdyby "prawo Linusa" nie działało, wtedy każdy złożony system, taki jak jądro Linuksa, który hakowało tyle rąk ile jądro Linuksa, powinien w pewnym momencie zawalić się pod ciężarem nieprzewidzianych problemów z zależnościami i nieodkrytych "głębokich" błędach. Jeśli jednak prawo to działa, wyjaśniałoby to relatywnie niską ilość błędów w jądrze Linuksa.

  Być może nie powinno to nikogo zbytnio dziwić. Socjologowie już dawno odkryli, że na przeciętnej opinii obserwatorów o równie wysokim (lub niskim) stopniu wiedzy można polegać o wiele bardziej, niż na opinii pojedynczego, losowo wybranego obserwatora. Nazywa się to "metodą delficką".

  Wydawać by się mogło, że Linus zademonstrował, iż efekt ten ma miejsce nawet w przypadku odpluskwiania systemu operacyjnego: że efekt Delphi może zredukować złożoność nawet w tak skomplikowanym projekcie, jakim jest jądro systemu operacyjnego.

  Jestem wdzięczny Jeffowi Dutky za zwrócenie uwagi na fakt, że Prawo Linusa można przeformułować jako "Odpluskwianie można przeprowadzać równolegle". Jeff zauważył, że choć proces odpluskwiania wymaga kontaktu osób odpluskwiających z koordynującym programistą, to jednak nie jest potrzebna specjalna koordynacja działań między poszukiwaczami błędów. Dlatego też odpluskwianie nie pada ofiarą gwałtownie rosnącej złożoności i kosztów zarządzania, które sprawiają, że rosnąca liczba programistów przynosi problemy.

  Teoretyczna utrata wydajności, związana z powielaniem tej samej pracy przez różne osoby szukające błędów, w praktyce nigdy nie zaistniała w świecie linuksowym. Jednym ze skutków polityki częstego udostępniania nowych wersji jest minimalizacja tego typu powielania pracy dzięki szybkiemu dołączaniu otrzymanych poprawek do nowej wersji.

  Brooks mimochodem zwrócił uwagę na inny fakt, mający związek z uwagą Jeffa: "Całkowity koszt utrzymywania powszechnie używanego programu to przeciętnie około 40% kosztu jego rozwoju lub więcej. Co ciekawe, koszt ten w dużej mierze zależy od liczby użytkowników. Większa liczba użytkowników znajdzie więcej błędów" (nacisk pochodzi ode mnie -ESR ).

  Im więcej użytkowników, tym więcej błędów zostanie odkrytych, ponieważ nowi użytkownicy wnoszą ze sobą różne podejścia do programu. Efekt ten zwiększa się, kiedy użytkownicy są programistami. Każdy podchodzi do problemu określenia błędu z nieco inną percepcją i zestawem narzędzi analitycznych, widzi problem pod innym kątem. Prawdopodobnie "efekt Delphi" działa właśnie dzięki temu zróżnicowaniu. Jeśli zaś chodzi o odpluskwianie, zróżnicowanie pomaga zmniejszyć prawdopodobieństwo dublowania pracy innych.

  Tak wiec większa liczba beta testerów może nie zmniejsza "głębokości" błędu z punktu widzenia programisty, zwiększa jednak prawdopodobieństwo, że czyjś zestaw narzędzi zostanie dopasowany do problemu tak, że dla danej osoby błąd stanie się płytki.

  Linus nie wkłada jednak wszystkich jajek do jednego koszyka: na wypadek, gdyby w kodzie miały się pojawić poważne błędy, wersje jądra Linuksa są numerowane w taki sposób, że potencjalni użytkownicy mają wybór między ostatnią wersją oznaczoną jako "stabilna" a najnowszą funkcjonalnością i potencjalnymi błędami. Większość hakerów linuksowych nie naśladuje tej taktyki, choć być może powinni; sam fakt, że istnieją dwie wersje sprawia, że obie są bardziej atrakcyjne.

  Kiedy róża nie jest różą?

  Po zbadaniu zachowania Linusa i sformułowaniu teorii wyjaśniającej jego sukces, podjąłem świadomą decyzję, by przetestować tę teorię na moim nowym (w istocie o wiele mniej ambitnym i skomplikowanym) projekcie.

  Przede wszystkim jednak uporządkowałem i uprościłem kod popclienta. Implementacja Carla Harrisa była bardzo solidna, jednak charakteryzowała się wysokim stopniem niepotrzebnej złożoności, właściwej wielu programującym w C. Dla Harrisa kod był rzeczą centralną, zaś struktury danych - jedynie jego podporą. Dlatego też popclient miał piękny kod, jednak projekt struktur danych został przygotowany naprędce i był raczej niezgrabny (przynajmniej z punktu widzenia starego hakera LISP-a).

  Był jednak jeszcze jeden argument za przepisaniem programu, poza polepszeniem jakości kodu struktur danych. Zależało mi bowiem na przekształcenie go w coś, co mógłbym całkowicie zrozumieć. Przyjęcie na siebie odpowiedzialności za poprawianie błędów w programie, którego się nie rozumie, nie jest zabawne.

  Następnie przez około miesiąc realizowałem założenia wynikające z projektu Carla. Pierwszą poważną zmianą z mojej strony było dodanie obsługi IMAP. W tym celu przekształciłem kod odpowiedzialny za obsługę protokołu w ogólny sterownik oraz trzy tablice definiujące metody (dla POP2, POP3 i IMAP). Ta zmiana jak i poprzednie przedstawia ogólną zasadę, którą warto zapamiętać - tyczy się to zwłaszcza osób programujących w językach takich jak C, gdzie zwykle nie istnieje dynamiczne określanie typów:

• Zręcznie zaprojektowane struktury danych i bezładny kod działają znacznie lepiej, niż odwrotna kombinacja.

  Brooks, rozdział 9: "Pokaż mi swój [kod] i ukryj [struktury danych], a twój program pozostanie dla mnie tajemnicą. Pokaż mi swoje [struktury danych], a kod nie będzie mi potrzebny - stanie się czymś oczywistym.

  W rzeczywistości mówił o "diagramach" i "tablicach". Biorąc jednak pod uwagę trzydziestoletni skok technologiczno-kulturowy, można stwierdzić, że chodzi niemal o to samo.

  Wtedy właśnie (na początku wrześnie 1996, około sześć tygodni od punktu zerowego) zacząłem myśleć o zmianie nazwy programu; w końcu nie był to już jedynie klient POP. Wahałem się jednak, ponieważ w projekcie programu nie było nic naprawdę nowego. Moja wersja popclienta musiała jeszcze zapracować na swoją własną tożsamość.

  Radykalna zmiana nastąpiła wtedy, kiedy nauczyłem fetchmaila przekazywać pobraną pocztę do portu SMTP{14}. Powrócę do tej kwestii za chwilę, wcześniej jednak odpowiem na mogące się nasunąć pytanie: wspomniałem wcześniej, że wykorzystam swój projekt by przetestować swoją teorię na temat taktyki Linusa Torvaldsa. W jaki sposób to uczyniłem? Otóż skorzystałem z kilku możliwości:

  • Udostępniałem nowe wersje wcześnie i często (niemal nigdy rzadziej niż raz na dziesięć dni; w okresach intensywnego rozwoju - codziennie).
  • Lista beta-testerów rosła, ponieważ dodawałem do niej każdego, kto skontaktował się ze mną w sprawie fetchmaila.
  • Przy okazji udostępnienia każdej nowej wersji wysyłałem na listę beta-testerów przyjacielskie zawiadomienia, zachęcając ich do wzięcia udziału w dalszym rozwoju programu.
  • Słuchałem testerów wersji beta, pytając ich o zdanie przy podejmowaniu decyzji dotyczących zmian projektowych i głaszcząc ich za każdym razem, kiedy odpowiadali czy przysyłali poprawki.

  Skutek tych niewyszukanych działań był natychmiastowy: od samego początku otrzymywałem raporty o błędach w takiej jakości, za którą większość programistów dałoby sie zabić, często z dołączonym rozwiązaniem. Krytyka, którą otrzymywałem, była przemyślana; otrzymywałem również listy od fanów i inteligentne propozycje zmian. Prowadzi nas to do następnej konkluzji:

• Jeśli traktujesz swoich beta-testerów jak swój największy skarb, staną się twoim największym skarbem.

  Interesującym wskaźnikiem odzwierciedlającym sukces fetchmaila jest sama wielkość listy dyskusyjnej poświęconej wersjom beta projektu, fetchmail-friends. W chwili, kiedy piszę te słowa, liczy ona 249 członków, zaś każdego tygodnia dołącza dwóch-trzech nowych.

  Przygotowując do wydania pod koniec maja 1997 roku kolejną wersję tego tekstu stwierdziłem, że lista traci członków z interesującego powodu: otóż wiele osób prosiło mnie o usunięcie z listy, ponieważ fetchmail działał im tak dobrze, że nie musieli śledzić już wiadomości na liście! Być może jest to po prostu normalna faza rozwoju dojrzałego projektu rozwijanego w bazarowym stylu. Popclient przekształca się w fetchmaila

  Prawdziwy przełom nastąpił kiedy Harry Hochheiser podesłał mi zalążek kodu służącego do przekazywania poczty do portu SMTP na maszynie lokalnej. Niemal od razu zdałem sobie sprawę z faktu, że wykorzystanie tej metody dostarczania poczty sprawi, iż wszystkie inne staną się niemal przestarzałe.

  Przez wiele tygodni stopniowo modyfikowałem fetchmaila mając jednak odczucie, że projekt interfejsu jest użyteczny lecz niezgrabny: brakowało mu elegancji, zaś wszelkiego rodzaju opcje wystawały na wszystkie strony. Szczególnie irytowały mnie opcje służące do przekazywania pobranej poczty do pliku skrzynki lub na standardowe wyjście, nie wiedziałem jednak dlaczego.

  Kiedy pomyślałem o przekazywaniu poczty przez SMTP zdałem sobie sprawę, że popclient próbował zrobić zbyt wiele rzeczy na raz. Został zaprojektowany jako program do przekazywania poczty (MTA), ale i jako program do lokalnego dostarczania poczty (MDA). Dzięki SMTP mógłby przestać być MDA i stać się czystym MTA, przekazując pocztę innym programom, które zajęłyby się lokalnym dostarczaniem, tak jak to czyni sendmail.

  Po co męczyć się ze skomplikowaną konfiguracją programu do dostarczania poczty czy ustawianiem trybu "zablokuj-i-dopisuj" na pliku skrzynki pocztowej, kiedy istnieje niemal stuprocentowa gwarancja, że na każdej platformie z obsługą TCP/IP będziemy mieli do dyspozycji port 25? Szczególnie jeśli pobierana poczta ma wyglądać jak zwykła poczta nadana przez nadawcę przy użyciu SMTP - o co zresztą nam właśnie chodzi.

  Z powyższego płynie kilka wniosków: po pierwsze, pomysł na przekazywanie poczty przez SMTP był największą pojedynczą zapłatą, którą otrzymałem próbując świadomie naśladować metody Linusa. Użytkownik poddał mi wspaniały pomysł, do mnie należało jedynie zrozumienie jego implikacji.

• Najlepsze, co może nas spotkać oprócz własnych dobrych pomysłów, to słuchanie dobrych pomysłów użytkowników. Czasem to drugie jest lepsze.

  Co ciekawe, można się szybko zorientować, że jeśli będziemy absolutnie prawdomówni w kwestii nikłości własnego wkładu i ogromnego znaczenia wkładu innych, ludzie uznają, że wszelkie innowacje są naszym dziełem i przez skromność pomniejszamy rolę swojego wrodzonego geniuszu. Widać to jasno na przykładzie Linusa!

  (Kiedy przedstawiłem ten esej na konferencji poświęconej Perlowi{15} w sierpniu 1997 roku i dotarłem do tego miejsca, Larry Wall, który siedział w pierwszym rzędzie, wydał z siebie religijny okrzyk: "Mów więcej, bracie!". Zebrani wybuchnęli śmiechem wiedząc dobrze, że twórca Perla również korzystał z tej zasady.)

  Po kilu tygodniach prowadzenia projektu w tym duchu, zacząłem otrzymywać pochwały nie tylko od użytkowników popclienta, lecz również od innych ludzi, którzy się o nim dowiedzieli. Skrzętnie ukryłem część tych e-maili; powrócę do nich kiedyś, kiedy zacznę zastanawiać się nad sensem życia. :-)

  Dochodzą tu jednak jeszcze dwie bardziej fundamentalne lekcje, odnoszące się do wszelkiego rodzaju projektów.

• Często najbardziej uderzające i nowatorskie rozwiązania mają u swych źródeł zrozumienie, że pierwotne postrzeganie natury problemu było błędne.

  Próbowałem rozwiązać niewłaściwy problem, kontynuując prace nad popclientem, będącym połączeniem MTA/MDA, zawierającym wszelkiego typu wymyślne sposoby dostarczania poczty. Projekt fetchmaila musiał zostać przemyślany od początku: program ten powinien być czystym MTA, częścią normalnej ścieżki poczty internetowej, używającej protokołu SMTP.

  Kiedy prowadząc projekt dotrze się do ściany, kiedy trudno jest myśleć o następnej łacie, wtedy nadchodzi czas by zapytać samego siebie - nie o to, czy zna się właściwą odpowiedź, ale czy zadaje się właściwe pytanie. Być może trzeba przeformułować problem.

  Cóż, przeformułowałem swój problem. Rzecz jasna, należało (1) dołączyć przekazywanie SMTP do ogólnego sterownika, (2) uczynić ten tryb domyślnym, oraz (3) ostatecznie pozbyć się wszystkich innych sposobów dostarczania poczty, szczególnie "dostarcz-do-pliku" oraz "dostarcz-na-standardowe-wyjście".

  Wahałem się przed uczynieniem tego ostatniego kroku, obawiając się, że sprawię przykrość starym użytkownikom popclienta, polegającym na alternatywnych metodach dostarczania poczty. Teoretycznie mogli od razu zacząć korzystać z plików .forward (i ich odpowiedników, jeśli korzystali z MTA innych niż sendmail), by uzyskać ten sam efekt. W praktyce tego typu przejście mogło sprawiać problemy.

  Jednakże kiedy to uczyniłem, korzyści okazały się ogromne. Zniknęły najbardziej nieociosane fragmenty kodu sterownika. Konfiguracja stała się o niebo łatwiejsza - koniec z chodzeniem po omacku w poszukiwaniu systemowego MDA i skrzynki użytkownika, koniec ze zmartwieniami o obsługę blokowania plików przez system operacyjny użytkownika.

  W ten sposób zniknęła również jedyna możliwość utraty poczty. Jeśli użytkownik wybrał dostarczanie do pliku, a dysk został zapełniony, poczta ginęła. Tego typu wypadki nie mogą mieć miejsca jeśli korzysta się z przekazywania SMTP, ponieważ program nasłuchujący na porcie SMTP nie zwróci OK {16} dopóki wiadomość nie zostanie przekazana, lub chociaż umieszczona w kolejce do dostarczenia.

  Wzrosła również wydajność (chociaż niełatwo to zauważyć przy pojedynczym uruchomieniu fetchmaila). Innym, mniej istotnym pożytkiem było zmniejszenie rozmiaru strony podręcznika man{17}.

  Później byłem zmuszony przywrócić dostarczanie przez MDA, by obsłużyć dostarczanie poczty w pewnych niejasnych sytuacjach związanych z dynamicznym SLIP. Znalazłem na to jednak o wiele prostszy sposób.

  Morał? Nie należy się wahać wyrzucić przestarzałą funkcjonalność, jeśli można to zrobić bez straty efektywności. Antoine de Saint Exupery (który był lotnikiem i konstruktorem samolotów, kiedy akurat nie pisał książek dla dzieci), powiedział:

• "Doskonałość projektu osiąga się nie wtedy, kiedy nie ma co dodać, lecz raczej kiedy nie ma co odjąć".

  Kiedy kod staje się lepszy i prostszy, wtedy wie się, że jest właściwy. W międzyczasie projekt fetchmaila uzyskał swoją własną tożsamość, różną od swojego przodka - popclienta.

  Przyszła pora na zmianę nazwy. Nowy projekt bardziej przypominał sendmaila niż stary popclient; obydwa są MTA, ale tam, gdzie sendmail wysyła ("send") i dostarcza, tam nowy popclient pobiera ("fetch"), a później dostarcza. Tak więc dwa miesiące później nazwałem go fetchmail.

  Z historii tej wynika jeszcze jeden, bardziej ogólny wniosek dotyczący pojawienia się kodu SMTP w fetchmailu. Nie tylko odpluskwianie{18} jest procesem równoległym, jest nim również rozwój, oraz (do pewnego - być może zaskakującego - stopnia) także eksploracja przestrzeni projektowej. Kiedy tryb rozwoju szybko staje się iteracyjny, rozwój i ulepszenia mogą stać się szczególnymi przypadkami odpluskwiania - naprawiania "błędów przeoczenia" w pierwotnej funkcjonalności czy koncepcji oprogramowania.

  Nawet na wyższym poziomie projektowym, pomysły wielu programistów badających w różnych miejscach przestrzeń projektową w pobliżu produktu mogą mieć dużą wartość. Warto zwrócić uwagę na to, w jaki sposób kałuża znajduje swoje ujście, albo jeszcze lepiej - jak mrówki szukają pożywienia: eksploracja odbywa się przez rozproszenie, po czym następuje eksploatacja za pośrednictwem skalowalnego mechanizmu komunikacji. System ten funkcjonuje bardzo dobrze; członek eskorty może znaleźć skarb, którego nie zauważył główny programista z powodu skupiania się zbyt blisko - tak jak to miało miejsce z Harry Hochheiserem i ze mną. Fetchmail dorasta

  Miałem więc przejrzysty i nowatorski projekt, dobrze działający kod, którego używałem na co dzień oraz rozwijającą się listę użytkowników wersji beta. Stopniowo zacząłem sobie zdawać sprawę, że nie uczestniczę już w trywialnym, osobistym projekcie hackerskim, z którego być może skorzystałoby klika innych osób. Miałem w swoich rękach program, którego potrzebuje każdy haker z uniksem i połączeniem pocztowym SLIP/PPP.

  Wraz z dodaniem funkcjonalności SMTP, fetchmail wysunął się przed konkurencję, mając szansę stać się "przebojem w swojej kategorii", jednym z tych klasycznych programów, które wypełniają swoją niszę do tego stopnia, że alternatywne rozwiązania są nie tyle pomijane co niemal zapomniane.

  Nie wydaje mi się, by można było zaplanować tego typu rezultat. Trzeba być weń wciągniętym przez idee tak silne, że rezultaty wydają się nieuniknione, naturalne, by nie rzec przepowiedziane. Istnieje tylko jeden sposób, by wypróbować te pomysły: trzeba mieć ich dużo, albo umieć posłużyć się inżynierskim osądem, prowadząc dobre pomysły innych poza granice wyznaczone im przez ich twórców.

  Andy Tanenbaum pierwszy wpadł na pomysł, by zbudować prosty, natywny system uniksowy dla komputerów IBM PC, który mógłby wykorzystać w nauczaniu (Minix). Linus Torvalds popchnął koncepcję Miniksa prawdopodobnie dalej, niż Andrew przewidział - a rezultat przerodził sie w coś wspaniałego. W podobny sposób, lecz na mniejszą skalę, wziąłem pewne pomysły od Carla Harrisa i Harry'ego Hochheisera i nadałem im rozpędu. Żaden z nas nie był "oryginalny" w romantyczny sposób, w jaki zwykle postrzega się geniusz. Jednakże większość tego, co dzieje się w nauce, inżynierii czy rozwoju oprogramowania, nie dokonuje się za sprawą geniuszu, bez względu na to, co mówi hakerska mitologia.

  Rezultaty były bardzo ekscytujące - szczerze mówiąc był to sukces, o jakim marzy każdy haker! Wniosek był jeden: powinienem podwyższyć poprzeczkę. By uczynić fetchmaila tak dobrym programem, jakim mógłby być, powinienem dołączyć i dbać o funkcjonalność potrzebną ludziom znajdującym się poza moim polem percepcji - cały czas starając się, by program zachował swoją siłę i prostotę.

  Pierwszą i najważniejszą funkcjonalnością, którą dopisałem, kiedy zdałem sobie sprawę z tego faktu, była obsługa multidrop - możliwości pobierania poczty ze skrzynek, w których zgromadzona została poczta dla grupy użytkowników, by następnie przekazać ją indywidualnym odbiorcom.

  Zdecydowałem się dodać obsługę multidrop częściowo z powodu nagabywań użytkowników, jednak głównym powodem było przekonanie, że fakt ten przyczyni się do eliminacji błędów z ówczesnego kodu single-drop, zmuszając mnie do rozwiązania problemu na wyższym poziomie abstrakcji. Tak tez się stało. Parsowanie adresów zgodnie z RFC 822 (http://info.internet.isi.edu:80/in-notes/rfc/files/rfc822.txt) zajęło mi naprawdę dużo czasu, nie dlatego, że którykolwiek fragment był trudny, lecz z powodu przeładowania mnóstwem wzajemnie zależnych szczegółów.

  Wprowadzenie adresowania maildrop okazało się jednak bardzo trafną decyzja projektową. W ten sposób dowiedziałem się, że:

  Każde narzędzie powinno być użyteczne w przewidziany sposób, jednak naprawdę wielkie narzędzie znajduje nieprzewidziane zastosowania.

  Nieprzewidzianym zastosowaniem funkcjonalności multidrop w fetchmailu okazała się możliwość uruchomienia list pocztowych, przy czym zarówno lista, jak i dopełnianie aliasów{19} odbywało się po stronie klienta połączenia internetowego, co oznacza, że osoba posiadająca komputer osobisty i łącząca się z Internetem za pośrednictwem swojego ISP, może zarządzać listą dyskusyjną bez potrzeby stałego dostępu do konta ISP.

  Inną ważną funkcjonalnością, której domagali się moi beta testerzy, była obsługa ośmiobitowego MIME (Multipurpose Internet Mail Extension{20}). Nie było to zbyt trudne, ponieważ dbałem o to, bym mój kod był czysty pod względem operacji ośmiobitowych - nie dlatego, że przewidziałem dodanie tej funkcjonalności, lecz ponieważ stosowałem się do następującej reguły:

  15. Pisząc jakiekolwiek oprogramowanie pełniące rolę pośrednika, należy podjąć wysiłki, by nie naruszać strumienia danych i *nigdy* nie odrzucać żadnej informacji, chyba, że program zostanie do tego zmuszony przez odbiorcę.

  Gdybym nie przestrzegał tej zasady, implementacja ośmiobitowej obsługi MIME byłaby trudna i pełna błędów. Ponieważ jednak było inaczej, wystarczyło mi tylko poczytać o standardzie MIME w RFC 1652 (http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1652.txt) i dodać trywialny fragment związany z logiką generowania nagłówków.

  Niektórzy europejscy użytkownicy męczyli mnie, bym dodał opcje ograniczającą liczbę wiadomości otrzymanych podczas jednej sesji (dzięki czemu mogliby kontrolować opłaty za korzystanie z drogich linii telekomunikacyjnych). Dość długo się temu opierałem i wciąż nie jestem z tego powodu zbyt szczęśliwy. Jeśli jednak pisze się dla innych, trzeba słuchać swoich klientów - fakt, że nie płacą, niczego nie zmienia. Jeszcze kilka lekcji płynących z tworzenia fetchmaila

  Zanim wrócimy do ogólnych kwestii związanych z inżynierią oprogramowania, warto zatrzymać się chwilę nad kilkoma bardziej specyficznymi lekcjami, których nauczyło mnie doświadczenie w pracy nad fetchmailem. Czytelnik nie zaznajomiony z kwestiami technicznymi może spokojnie ominąć ten fragment.

  Składnia plików kontroli rc{20} zawiera opcjonalne "szumy" w postaci słów kluczowych, które są ignorowane przez parser. Przypominająca język angielski składnia, którą się dzięki temu uzyskuje, jest o wiele bardziej czytelna niż tradycyjne, zbite pary "słowo kluczowe - wartość", które można uzyskać po zredukowaniu ich do prostszej postaci.

  Składnia ta powstała w wyniku nocnego eksperymentu, kiedy zauważyłem, że deklaracje w plikach rc zaczęły przypominać mini-język złożony ze zdań rozkazujących (z tego tez powodu zamieniłem występujące w popcliencie słowo kluczowe "server" na "poll").

  Uważałem, że jeśli ten mini-język będzie bardziej przypominał angielski, łatwiej będzie go używać. Wspomnę, że chociaż jestem zwolennikiem szkoły projektowania "spraw, by był to język", która przejawia się w takich przykładach jak Emacs, HTML czy wiele silników bazodanowych, to zazwyczaj nie jestem wielkim fanem składni "przypominających język angielski".

  Tradycyjnie programiści maja tendencję do faworyzowania bardzo precyzyjnych składni kontrolujących, nie mających żadnych zbędnych elementów. Jest to kulturowa spuścizna po czasach, kiedy zasoby komputerowe były drogie, stąd też faza parsowania musiała być tak tania i prosta, jak to tylko możliwe. Język angielski, ze swoją 50-procentową redundancją, zdawał się być wtedy bardzo nieodpowiednim przykładem.

  Unikam angielskopodobnych składni nie z tego powodu; przytaczam ten argument tylko po to, by go obalić. Mając tanie cykle procesora i sprzęt, zwięzłość nie powinna być celem samym w sobie. Dziś o wiele ważniejsze jest, by język był zrozumiały dla ludzi, niż tani dla komputera.

  Istnieją jednak dobre powody, by być ostrożnym w tej kwestii. Pierwszym jest koszt złożoności fazy parsowania - nie ma sensu doprowadzać jej do punktu, kiedy zacznie być znaczącym źródłem błędów i kłopotów użytkowników. Następny powód to fakt, że próba uczynienia składni bardziej angielską często wymaga od programisty, by "angielski", którym mówi program stał się zupełnie bezkształtny do tego stopnia, że powierzchowne podobieństwo do języka naturalnego byłoby równie mylące, jak tradycyjna składnia (widać to na przykładzie wielu tzw. "języków czwartej generacji" i komercyjnych języków zapytywania baz danych).

  Składnia kontrolująca fetchmaila zdaje się unikać tych pułapek, ponieważ domena językowa jest bardzo ograniczona. Nie jest to żadną miarą język ogólnego zastosowania; rzeczy, których dotyczy, nie są bardzo skomplikowane, nie jest więc łatwo się pomylić poruszając się mentalnie między niewielkim podzbiorem angielskiego a rzeczywistym językiem kontrolującym. Myślę, że wypływa z tego bardziej ogólny wniosek:

  Jeśli kompletność języka nie zbliża się do poziomu Turinga, dodatki składniowe mogą bardzo pomóc.

  Kolejna lekcja dotyczy "bezpieczeństwa przez ukrywanie"{21}. Niektórzy użytkownicy fetchmaila prosili mnie, bym wprowadził szyfrowanie haseł przechowywanych w pliku rc, aby węszyciele nie mogli ich przypadkiem podejrzeć.

  Nie uczyniłem tego, ponieważ nie jest to żadna ochrona. Każdy, kto uzyskał uprawnienia do odczytu pliku rc, będzie mógł uruchomić fetchmaila jako właściciel pliku; jeśli zaś zależałoby im na haśle, mogliby zbudować dekoder na bazie kodu deszyfrującego w samym fetchmailu.

  Jedynym skutkiem szyfrowania haseł w pliku .fetchmailrc byłoby złudne poczucie bezpieczeństwa u ludzi, którzy nie przemęczają się myśleniem. Ogólna reguła brzmi:

  System bezpieczeństwa jest tak silny, jak silna jest jego tajemnica. Należy się wystrzegać pseudo-tajemnic. Niezbędne warunki bazarowego stylu

  Osoby, które pierwsze przeczytały ten esej oraz jego pierwsi testerzy wciąż zadawali pytania dotyczące warunków niezbędnych do tego, by rozwój projektów w bazarowym stylu był udany, włączając w to kwalifikacje lidera projektu jak również stan kodu w chwili jego upublicznienia i podjęcia próby zbudowania wspólnoty deweloperskiej.

  Jest całkiem jasne, że nie można od samego początku tworzyć w bazarowym stylu[4]. Można testować, odpluskwiać i ulepszać program w bazarowym stylu, lecz bardzo trudno w ten sposób zapoczątkować projekt. Linus nie próbował. Ja też nie. Rodząca się społeczność deweloperska potrzebuje mieć rozrywkę w postaci czegoś, co można by uruchomić, przetestować.

  Kiedy rozpoczyna się budowanie społeczności, trzeba być gotowym do przedstawienia możliwej do zaakceptowania obietnicy. Program nie musi działać nadzwyczajnie dobrze - może być toporny, zapluskwiony, nieskończony i źle udokumentowany. Musi jednak uczynić dwie rzeczy: (a) uruchomić się, (b) przekonać potencjalnych deweloperów, że można go będzie przekształcić w coś naprawdę uporządkowanego w możliwej do przewidzenia przyszłości.

  Zarówno Linux jak fetchmail pojawiły się po raz pierwszy szerszemu gronu odbiorców z silnie zaznaczonym i atrakcyjnym rysem projektowym. Wielu ludzi rozmyślających nad przedstawionym przeze mnie modelem bazarowym słusznie uważało ten fakt za bardzo istotny, wnioskując z tego, że lider projektu musi posiadać wiele intuicji projektowej i być bardzo bystrą osobą.

  Jednakże Linus zapożyczył projekt z UNIX-a. Mój pochodzi od swojego przodka, popclienta (chociaż później uległ sporym zmianom, o wiele większym, niż - biorąc pod uwagę proporcje - Linux). Czy lider/koordynator projektu powstającego w bazarowym stylu naprawdę musi mieć nadzwyczajny talent projektowy, czy też może polegać na takim talencie u innych?

  Ja uważam, że koordynator nie musi być autorem błyskotliwych pomysłów projektowych, jednakże absolutnie konieczne jest, by potrafił rozpoznać dobre pomysły projektowe u innych.

  Zarówno proces powstawania Linuksa jak i fetchmaila ustanowią dowód na poparcie tej tezy. Linus, nie będąc nadzwyczajnie oryginalnym projektantem (jak to już było omawiane), wykazał niebywałą zdolność rozpoznawania dobrych projektów i integracji ich z jądrem Linuksa. Co się tyczy fetchmaila - opisałem już, w jaki sposób do fetchmaila przeniknął najważniejszy pojedynczy pomysł projektowy (SMTP).

  Pierwsi odbiorcy tego eseju sprawili mi komplement sugerując, że mam tendencje do niedoceniania oryginalności projektowej w aplikacjach bazarowych, ponieważ sam jej dużo posiadam, więc przyjmuję ją jak rzecz oczywistą. Być może jest w tym trochę prawdy; projektowanie (w przeciwieństwie do kodowania czy debugowania) jest moją najsilniejszą stroną.

  Jednakże problem z bystrością i oryginalnością w projektowaniu oprogramowania polega na tym, że po pewnym czasie stają się przyzwyczajeniem: odruchowo tworzy się ładne i skomplikowane rzeczy, podczas gdy powinno się tworzyć programy uporządkowane i proste. Niektóre moje projekty upadły, ponieważ popełniłem ten właśnie błąd - jednak przy tworzeniu fetchmaila udało mi się go nie popełnić.

  Wierze więc, że projekt fetchmaila zakończył się sukcesem częściowo dlatego, że hamowałem swoje zapędy do bystrości; stoi to w sprzeczności (przynajmniej) z tezą, że oryginalność projektowa jest najistotniejsza, jeśli chce się stworzyć udany projekt bazarowy. Weźmy teraz pod uwagę Linuksa: załóżmy, że Linus Torvalds próbowałby wdrożyć nowatorskie pomysły projektowe podczas tworzenia jądra; czy w ogóle wydaje się prawdopodobne, że powstałe w wyniku tego jądro byłoby tak stabilne i udane jak to, które mamy?

  Pewien podstawowy poziom umiejętności programowania i projektowania jest niezbędny, jednak wydaje mi się, że każdy, kto poważnie myśli o rozpoczęciu projektu bazarowego, znajduje sie powyżej tego minimum. Wewnętrzny reputacyjny rynek społeczności open source wywiera subtelny nacisk na programistów, by nie rozpoczynali projektów, do których prowadzenia nie są wystarczająco kompetentni. Wydaje się, że jak dotąd mechanizm ten działał całkiem nieźle.

  Istnieje jeszcze jedna umiejętność, zwykle nie kojarzona z rozwojem oprogramowania, którą uważam za równie ważną co talent projektowy - a być może jest nawet ważniejsza. Lider czy koordynator projektu bazarowego musi posiadać umiejętność komunikowania się i współpracy z ludźmi.

  Powinno być to jasne: aby stworzyć wspólnotę deweloperską, trzeba przyciągnąć ludzi, zainteresować ich tym, co się robi i być zadowolonym z ilości pracy, którą wykonują. Sprawy techniczne są bardzo ważnym czynnikiem, jednak w żadnym wypadku nie decydują o całości. Liczy się również osobowość.

  Nie przypadkiem Linus jest miłym facetem, lubianym i budzącym chęć pomocy. Nieprzypadkowo jestem energetycznym ekstrawertykiem, czerpiącym radość z tłumem ludzi, którego sposób mówienia i odruchy przypominają komika rozbawiającego publiczność. Aby bazarowy model działał, bardzo pomocna jest choć skromna umiejętność oczarowywania ludzi. Społeczny kontekst oprogramowania open source

  Napisano: najlepsze hakerskie projekty powstają jako osobiste rozwiązania codziennych problemów autora, zaś rozprzestrzeniają się ponieważ okazuje się, że na problem ten uskarża sie większa klasa użytkowników. Tym samym wracamy do reguły 1, którą można sformułować inaczej, być może czyniąc ją bardziej użyteczną:

  Aby rozwiązać interesujący problem, należy zacząć od znalezienia problemu, który nas osobiście interesuje.

  Tak było z Carlem Harrisem i przodkiem popclientem, tak też było i ze mną i fetchmailem. Ale to rzecz zrozumiała od dłuższego czasu. Interesującym procesem, którym zainteresowania domagają się historie powstania Linuksa i fetchmaila, jest następna faza - ewolucja oprogramowania w obecności licznej i aktywnej społeczności użytkowników i programistów.

  W książce Mityczny osobomiesiąc Fred Brooks zauważył, że czas programistyczny nie jest skalowalny: dodawanie programistów do projektu sprawia, że prace trwają dłużej. Brooks argumentował twierdząc, że koszty złożoności i komunikacji rosną kwadratowo w stosunku do liczby programistów, zaś prace nad projektem przebiegają jedynie liniowo. Teza ta została nazwana "Prawem Brooksa" i jest powszechnie uznawana za truizm. Jeśli jednak prawo Brooksa oddawałoby całość sytuacji, powstanie Linuksa nie byłoby możliwe.

  W klasycznym dziele Geralda Weinberga, Psychologii programowania komputerów , możemy odnaleźć coś, co -- patrząc z perspektywy czasu -- możemy uznać za istotną poprawkę do Prawa Brooksa. Przy okazji rozważań na temat "programowania pozbawionego ego", Winberg zauważył, że w firmach, w których programiści nie mieli zaborczego nastawienia do własnego kodu, zachęcając innych do szukania błędów i możliwości rozwoju, postępy były czynione o wiele szybciej niż gdzie indziej.

  Analiza Weinberga nie uzyskała szerokiej akceptacji prawdopodobnie ze względu na używaną przez niego terminologię - nazwanie hakerów internetowych "tymi, którzy nie mają ego" wywołuje uśmiech na twarzy. Wydaje mi się jednak, że jego teza jest dziś bardziej przekonywująca niż kiedykolwiek.

  Historia UNIX-a powinna przygotować nas na to, czego dzisiaj uczymy się z Linuksa (i co zweryfikowałem doświadczalnie na mniejszą skalę, świadomie kopiując metody Linusa[5]). Chodzi mianowicie o to, że choć samo programowanie jest czynnością wykonywaną samotnie, to jednak naprawdę wspaniałe pomysły programistyczne powstają dzięki wykorzystaniu uwagi i potęgi mózgów całych społeczności. Programista, który potrafi korzystać jedynie ze swojego mózgu w zamkniętym projekcie będzie zawsze w tyle za tym, który potrafi stworzyć otwarty, ewolucyjny kontekst, w którym odzew związany z eksploracją przestrzeni projektowej, przesyłane fragmenty kodu, wyłapane błędy i inne ulepszenia pochodzą od setek (a być może i tysięcy) ludzi.

  Jednakże wiele czynników obecnych w tradycyjnym świecie uniksowym nie pozwalało rozwinąć tego podejścia do granic możliwości. Jednym z nich były ograniczenia prawne zawarte w wielu licencjach, tajemnice handlowe i komercyjne interesy; innym (spoglądając wstecz) był niedostateczny poziom rozwoju Internetu. Zanim pojawił sie tani Internet, istniały pewne geograficznie ściśnięte wspólnoty, których kultura sprzyjała Weinbergowemu "programowaniu bez ego", zaś programista mógł z łatwością przyciągnąć wielu utalentowanych kibiców i deweloperów. Bell Labs, Labolatorium Sztucznej Inteligencji MIT, Uniwersytet Kalifornijski Berkeley - instytucje te stały się źródłem legendarnych innowacji, których siłę odczuwamy do dziś.

  Linux był pierwszym projektem, w którym uczyniono świadomy i udany wysiłek, by skorzystać z zasobów talentów całego świata. Nieprzypadkowo początkowy okres rozwoju Linuksa zbiegł się z narodzinami World Wide Web, zaś dzieciństwo Linuksa zakończyło się w latach 1993-94, a więc w tym samym okresie, w którym powstał biznes dostawców usług internetowych i nastąpiła eksplozja ogólnego zainteresowania Internetem. Linus był pierwszą osobą, która nauczyła się grać według nowych zasad, które wyznaczył powszechny dostęp do Internetu.

  Podczas gdy tani Internet był niezbędnym warunkiem umożliwiającym ewolucję modelu linuksowego, nie wydaje mi się, by był to jedyny warunek. Innym istotnym czynnikiem był rozwój stylu prowadzenia projektu oraz zestaw zwyczajów towarzyszących współpracy, które pozwalały programistom przyciągnąć innych programistów i uzyskać maksimum mocy, którą oferowało nowe medium.

  Na czym jednak polega ów styl prowadzenia projektów i o jakich zwyczajach mowa? Nie można ich stworzyć na związkach, które opierają się na władzy, a nawet jeśli by to było możliwe, przewodnictwo oparte na przymusie nie przyniosłoby rezultatów, którymi dziś dysponujemy. Na poparcie tej tezy Weinberg przytacza cytat z autobiografii dziewiętnastowiecznego rosyjskiego anarchisty Piotra Aleksjewicza Kroppotkina, Wspomnienia rewolucjonisty:

  Będąc wychowany w rodzinie właścicieli ziemskich, wszedłem w dorosłe życie - podobnie jak wszyscy młodzi mężczyźni w tamtych czasach - silnie wierząc w konieczność rozkazywania, łajania, karania i tak dalej. Kiedy jednak na samym początku musiałem zająć się poważnymi przedsięwzięciami i pracować z [wolnymi] ludźmi, kiedy każda pomyłka groziła poważnymi konsekwencjami, zacząłem zdawać sobie sprawę z różnicy pomiędzy działaniem w oparciu o władzę i dyscyplinę a działaniem na bazie wzajemnego zrozumienia. To pierwsze świetnie zdaje egzamin podczas marszu wojskowego, jednak w prawdziwym życiu nie ma żadnej wartości, zaś cel może zostać osiągnięty tylko dzięki sporemu wysiłkowi wielu osób, których dobra wola zbiega się w jednym punkcie.

  Projekt taki jak Linux wymaga właśnie "wysiłku wielu osób, których dobra wola zbiega się w jednym punkcie", zaś wykorzystanie "zasady władzy" wśród ochotników w anarchistycznym pochodzie zwanym Internetem efektywnie zastosować się nie da. Aby efektywnie działać i konkurować, hakerzy pragnący prowadzić współpracujące ze sobą projekty muszą się nauczyć w jaki sposób rekrutować i napełniać entuzjazmem wspólnoty interesów, jak to mgliście sugeruje "zasada zrozumienia" Kropotkina. Muszą się nauczyć Prawa Linusa[6].

  Wcześniej omawiałem "efekt Delphi" jako możliwe wyjaśnienie Prawa Linusa, jednakże od razu narzucają się jeszcze bardziej przekonywujące analogie do systemów adaptacyjnych w biologii i ekonomii. Świat linuksowy pod wieloma względami przypomina gospodarkę wolnorynkową lub ekosystem, zbiór samolubnych czynników próbujących zmaksymalizować użyteczność produktu, dzięki czemu powstaje samoregulujący się, spontaniczny porządek, większy i bardziej skuteczny niż zdołałoby osiągnąć centralne planowanie. Tutaj właśnie należy szukać "zasady zrozumienia".

  "Funkcja użytkowa", eksplorowana przez linuksowych hakerów nie ma klasycznych podstaw ekonomicznych, jest natomiast niematerialną nagrodą w postaci zadowolenia własnego ego oraz reputacji w środowisku hakerskim. (Można nazwać ich motywację "altruistyczną", ignorując fakt, że sam altruizm oferuje altruiście jakąś formę zadowolenia ego). Działające w ten sposób kultury ochotników nie są niczym niezwykłym: przez długi czas uczestniczyłem w życiu wspólnoty fanów science fiction, która w przeciwieństwie do społeczności hakerskiej już dawno uznała "egoboo" (podbudowywanie ego, czyli polepszanie własnej reputacji wśród innych fanów) za podstawową motywację dobrowolnej działalności.

  Linus dobrze uchwycił "zasadę dzielonego zrozumienia" Kropotkina. Quasi-ekonomiczne spojrzenie na świat linuksowy pozwala nam ujrzeć, jak praktycznie wykorzystał swoją wiedzę.

  Możemy uznać metodę Linusa za sposób na stworzenie wydajnego rynku "egoboo" - ścisłego związania samolubnych tendencji w celu dotarcia do trudnego celu, który można osiągnąć jedynie dzięki trwałej współpracy. Pracując nad fetchmailem pokazałem (choć na mniejszą skalę), że jego metody można z dobrym skutkiem naśladować. Być może nawet robiłem to nieco bardziej systematycznie i świadomie niż on.

  Wielu ludzi (szczególnie ci, którzy z powodów politycznych nie ufają wolnym rynkom) wyobraża sobie wspólnotę kierujących się swoim osądem egoistów za pofragmentowaną, zaborczą, marnotrawną, skrywającą swoje sekrety i wrogą kulturę. Jednakże kłam tego typu oczekiwaniom w bardzo oczywisty sposób zadaje choćby zadziwiające bogactwo, jakość i głębia linuksowej dokumentacji. Należy podchodzić do tego faktu z szacunkiem zważywszy na fakt, że programiści nienawidzą pisać dokumentacji. W takim razie jak to się dzieje, że linuksowi hakerzy generują jej takie ilości? Widocznie wolnorynkowe linuksowe egoboo lepiej potrafi wytworzyć szlachetne zachowania, nakierowane na pomoc innym, niż wysoko opłacane firmy dokumentacyjne komercyjnych producentów oprogramowania.

  Zarówno projekt fetchmaila jak i jądra Linuksa pokazują, że we właściwy sposób nagradzając ega wielu innych hakerów, silny programista / koordynator może wykorzystać Internet w celu uzyskania korzyści w postaci dużej liczby współpracowników, nie pozwalając równocześnie, by projekt popadł w chaotyczny bałagan. Tak więc w opozycji do prawa Brooksa proponuję co następuje:

  Zakładając, że koordynator projektu dysponuje medium przynajmniej tak dobrym jak Internet i potrafi zarządzać projektem bez stosowania przymusu, wiele głów ma z pewnością większą wartość niż jedna.

  Uważam, że przyszłość oprogramowania open source będzie coraz bardziej należała do ludzi, którzy umieją grać w grę Linusa, ludzi, którzy porzucili katedrę na rzecz bazaru. Nie znaczy to, że błyskotliwość i wizja jednostki nie będą miały znaczenia, przeciwnie - najwyższej jakości oprogramowanie open source będzie należało do tych, którzy zaczynają od własnej wizji i pomysłowości, a następnie wzmacniają, tworząc wspólnoty interesu złożone z ochotników.

  Być może jest to przyszłość nie tylko oprogramowania open source: żaden programista zamkniętego oprogramowania nie może równać się z zasobami talentów, którymi dysponuje wspólnota linuksowa w celu rozwiązywania problemów. Niewielu mogłoby sobie pozwolić na zatrudnienie ponad dwustu (1999: sześciuset) programistów, którzy dołożyli swój fragment kodu do fetchmaila!

  Być może kultura open source zwycięży kiedyś nie dlatego, że współpraca jest rzeczą moralnie właściwą, albo że "ukrywanie"{23} oprogramowania jest moralnie złe (zakładając, że się w nie wierzy - ani ja, ani Linus nie wierzymy), ale dlatego, że świat zamkniętych źródeł nie może wygrać ewolucyjnego wyścigu zbrojeń ze wspólnotami open source, które mogą poświęcić rząd wielkości więcej czasu specjalistów na rozwiązywanie problemów. O zarządzaniu i linii Maginota

  Pierwotna wersja tego eseju kończyła sie powyższą wizją - wizją tłumów programistów-anarchistów połączonych siecią, pokonujących i przejmujących hierarchiczny świat zamkniętego oprogramowania.

  Nie udało mi się jednak przekonać wielu sceptyków, zaś zadawane przez nich pytania zasługują na uwagę. Większość zastrzeżeń w stosunku do bazarowego modelu sprowadzało się do stwierdzenia, że jego protagoniści nie doceniają zwiększającego produktywność efektu konwencjonalnego zarządzania.

  Tradycyjni menedżerowie odpowiedzialni za zarządzanie projektami programistycznymi często wysuwają zastrzeżenie, że przypadkowość w formowaniu się, przemianach i zaniku grup projektowych w świecie open source niweluje znaczną część widocznej przewagi liczebnej, którą społeczność open source ma nad którymkolwiek pojedynczym programistą zamkniętego projektu. Twierdzą, że w procesie rozwoju oprogramowania najbardziej liczy się ciągły wysiłek oraz spełnienie oczekiwań klientów, którzy liczą na ciągły rozwój produktu, a nie tylko to, ilu ludzi wrzuciło kość do garnka, by się ugotowała.

  Z pewnością jest cos w tym rozumowaniu; zresztą więcej na temat teorii mówiącej o kluczowej roli wartości oczekiwanych usług dla gospodarki produkcji oprogramowania można znaleźć w innym eseju w tej książce - w Magicznym Kotle

  W rozumowaniu tym tkwi jednak pewien błąd: zakłada ono, że proces rozwoju oprogramowania open source nie potrafi zapewnić takiego ciągłego wysiłku. Jednakże mamy przykłady projektów open source, które przez długi czas utrzymywały spójną wizję i wspólnotę programistów, nie potrzebując struktur ani kontroli instytucjonalnej, tak istotnych w konwencjonalnym zarządzaniu. Rozwój edytora GNU Emacs jest niezwykłym i pouczającym przykładem - w ciągu ponad piętnastu lat wchłonął wysiłki setek programistów, przy zachowaniu spójnej wizji architektonicznej, mimo tego, że tylko jedna osoba (autor Emacsa) była aktywna przez cały ten czas, zaś rotacja był spora. Żaden zamknięty edytor nie może pochwalić się podobną długowiecznością.

  W związku z tym można sie pokusić o zakwestionowanie zalet tradycyjnego zarządzania rozwojem oprogramowania, w oderwaniu od reszty argumentów w dyskusji katedra - bazar. Jeśli jest możliwe, by GNU Emacs przez ponad piętnaście lat zachował spójną wizję architektoniczną, by system operacyjny Linux nie zmienił jej w ciągu ośmiu lat, mimo ogromnych przemian sprzętowych i technologicznych, jeśli istnieją (a rzeczywiście istnieją) projekty open source trwające ponad pięć lat - mamy wszelkie prawo się dziwić, co otrzymujemy w zamian za ogromne koszty stałe związane z tradycyjnym, konwencjonalnym sposobem zarządzania procesem rozwoju oprogramowania.

  Cokolwiek by to nie było, na pewno nie jest to zakończenie projektu w terminie, zmieszczenie się w budżecie czy spełnienie wszystkich wymagań specyfikacji; rzadko który ze "sterowanych" projektów spełnia choćby jeden z wymienionych warunków, co dopiero wszystkie trzy. Nie jest to również zdolność do przystosowania się do zmian technologicznych i gospodarczych w czasie pracy nad projektem: społeczności open source wychodzi oto o wiele lepiej (co można łatwo zweryfikować porównując np. trzydziestoletnia historię Internetu z krótkotrwałymi projektami komercyjnych technologii sieciowych, lub też koszt przejścia z 16-bitowego do 32-bitowego kodu w Microsoft Windows z niemal bezwysiłkową migracją Linuksa w tym samym okresie - nie tylko po linii rozwojowej Intela, lecz również w kilkunastu innych architekturach sprzętowych, włączając w to 64-bitowe procesory Alpha).

  Ludziom wydaje się, że tradycyjny model zapewnia jedną rzecz: ktoś bierze na siebie odpowiedzialność i można od niego uzyskać rekompensatę, jeśli projekt nie wypali. Jest to jednak iluzja, ponieważ większość licencji na oprogramowanie nie zawiera w sobie gwarancji handlowych, nie wspominając o gwarancji działania, zaś przypadki odzyskania pieniędzy za niedziałające oprogramowanie są coraz rzadsze. A jeśli nawet byłyby częste, zadowolenie płynące z poczucia, że można kogoś ścigać na drodze sądowej to niezrozumienie istoty rzeczy. Nie zależy nam na procesach sądowych - chcemy mieć działające oprogramowanie.

  Cóż więc otrzymujemy w zamian za koszt stałe związane z tradycyjnym zarządzaniem rozwojem oprogramowania?

  Aby uzyskać odpowiedź na to pytanie, musimy najpierw uświadomić sobie zadania, które - w ich mniemaniu - spełniają menedżerowie projektów programistycznych. Znana mi kobieta, która wydaje się bardzo dobra w swoim fachu, uważa, że zarządzanie projektami programistycznymi polega na wypełnianiu pięciu funkcji:

  • Zdefiniowanie celów i pilnowanie, by wszyscy zmierzali w tym samym kierunku.
  • Monitorowanie i pilnowanie, by nie pominięto najistotniejszych szczegółów.
  • Motywowanie innych do wykonywanie nudnej, lecz nieuniknionej pracy.
  • Organizacja pracy ludzi w celu uzyskania najlepszych rezultatów.
  • Organizacja zasobów niezbędnych dla utrzymania projektu.

  Wszystkie z wymienionych celów wydają się znaczące, jednak w modelu open source i otaczającym go kontekście społecznym stają się dziwnie mało istotne. Omówimy każdy z nich, zaczynając od ostatniego.

  Moja znajoma twierdzi, że spora część tego, co przypada na organizację zasobów ma naturę obronną: mając już ludzi, komputery i przestrzeń biurową, należy ich bronić przed menedżerami tego samego szczebla mającymi na nie ochotę, oraz tymi wyżej w hierarchii, próbującymi jak najbardziej wykorzystać ograniczone zasoby.

  Jednakże deweloperzy projektów open source są ochotnikami: wybrali sami siebie według zainteresowań i możliwości pracy nad projektami (co zazwyczaj ma również miejsce nawet wtedy, kiedy płaci im się pensję za pracę nad projektami open source). Etos ochotnika pozwala automatycznie zadbać o aspekt "ataku" w organizacji zasobów: każdy kładzie na stół własne zasoby. Nie ma natomiast potrzeby (a jeśli jest, to niewielka), by osoba koordynująca projekt "bawiła się w obronę" w konwencjonalnym znaczeniu.

  Tak czy inaczej w świecie tanich komputerów PC i szybkich łączy internetowych coraz wyraźniej widać, że jedynym ograniczeniem związanym z zasobami jest uwaga utalentowanych osób. Projekty open source powstają nie z chęci zdobycia maszyn, łączy czy przestrzeni biurowej, zaś upadają jedynie wtedy, kiedy programiści przestają się nimi interesować.

  Z tego też powodu podwójne znaczenie ma fakt, że hakerzy open source organizują się sami, dobierając się w taki sposób, by osiągnąć maksimum produktywności, zaś środowisko dokonuje bezlitosnej selekcji kierując się kryterium kompetencji. Moja znajoma, znająca zarówno świat open source jak i duże, zamknięte projekty, uważa że open source zawdzięcza swój sukces częściowo temu, że jego kultura akceptuje jedynie najbardziej utalentowane 5 procent populacji programistów. Większość czasu upływa jej na organizowaniu pozostałych 95 procent, więc może bezpośrednio zaświadczyć o dobrze znanej, stukrotnej różnicy w produktywności między najzdolniejszymi a jedynie kompetentnymi programistami.

  Ustalenie tej różnicy zawsze wywoływało niezręczne pytanie: czy nie byłoby lepiej pojedynczym projektom, jak również całemu światu programistycznemu, gdyby pozbyć się ponad 50 procent najmniej kompetentnych? Rozsądni menedżerowie już dawno zrozumieli, że gdyby jedyną funkcją konwencjonalnego zarządzania projektami programistycznymi była przemiana rezultatów pracy najmniej zdolnych z czystej straty w marginalny zysk, gra mogłaby nie być warta świeczki.

  Sukces odniesiony przez społeczność open source uczynił to pytanie jeszcze bardziej wyraźnym, dostarczając jasnych dowodów na to, że często taniej i efektywniej jest dokonać rekrutacji ochotników z Internetu niż zarządzać budynkami pełnymi ludzi, którzy woleliby robić co innego. W ten sposób doszliśmy do kwestii motywacji. Często można usłyszeć odpowiednik wypowiedzi mojej znajomej: tradycyjne zarządzanie projektami jest niezbędne, by zrekompensować kiepsko umotywowanych programistów, którzy w przeciwnym wypadku nie byliby w stanie wytworzyć dobrych rezultatów.

  Podobnym wypowiedziom towarzyszy często stwierdzenie, że społeczność open source potrafi pracować jedynie nad projektami, które są "sexy" lub technicznie atrakcyjne; cała reszta pozostanie niezrobiona (lub zrobiona kiepsko), chyba, że wykona ją drużyna zdyscyplinowanych, pragnących zarobić gryzipiórków, poganianych biczem stojących nad nimi menedżerów. Swoje obiekcje natury psychologicznej i społecznej w stosunku do tego typu twierdzeń przedstawiłem w Homesteading the Noosphere. Jednak dla celów niniejszych rozważań, uznanie tego stwierdzenia za prawdziwe będzie miało bardziej interesujące implikacje.

  Jeśli konwencjonalny, zamknięty, silnie sterowany styl rozwoju oprogramowania broni się jedynie swego rodzaju linią Maginota - linią problemów prowadzących do nudy, to obrona ta będzie miała sens w każdej dziedzinie zastosowań tak długo, jak problemy te będą uznawane za nudne i nikt nie znajdzie sposobu, by je obejść. jednak w chwili, kiedy pojawi się konkurencja open source dla "nudzącego" programu, klienci zorientują się, że ktoś w końcu zabrał się za rozwiązywanie danego problemu z powodu fascynacji samym problemem, co w programowaniu jak i innych dziedzinach pracy twórczej, okazuje się o wiele lepszym czynnikiem motywacyjnym niż same pieniądze.

  Dlatego korzystanie z konwencjonalnego zarządzania jedynie w celu motywowania zespołu jest być może dobrą taktyką, ale złą strategią - krótkoterminowym zwycięstwem, lecz na dłuższą metę pewną stratą.

  Jak dotąd konwencjonalne zarządzanie rozwojem projektów wydaje się być na gorszej pozycji w stosunku do open source z dwóch powodów (organizacji zasobów i pracy ludzi), zaś jeśli chodzi o trzeci punkt (motywację), dni tradycyjnych poglądów na ten temat są policzone. Biednemu, wciąż atakowanemu konwencjonalnemu zarządzaniu nie przyjdzie w sukurs kwestia monitorowania, bowiem najsilniejszym argumentem społeczności open source jest tryumf zdecentralizowanej weryfikacji przez osoby współpracujące nad wszelkimi konwencjonalnymi metodami, mającymi zapewnić brak pomyłek w szczegółach.

  Czy więc definiowanie celów zdoła usprawiedliwić koszty stałe związane z konwencjonalnym zarządzaniem projektami programistycznymi? Być może; jednak by tak stwierdzić, musielibyśmy mieć dobry powód by wierzyć, że komitetom zarządzającym i korporacyjnym wytycznym lepiej udaje się zdefiniować wartościowe, wspólne cele, niż liderom projektów i plemiennej starszyźnie, którzy spełniają analogiczną rolę w świecie open source. A tego typu stwierdzenie byłoby bardzo trudno obronić. I to nie ze względu na przewagę open source (długowieczność Emacsa, talent Linusa Torvaldsa do mobilizacji tłumów deweloperów pod hasłem "dominacji nad światem"), a raczej z powodu widocznej słabości konwencjonalnych mechanizmów definiowania celów projektów programistycznych.

  Jednym z najbardziej znanych truizmów w inżynierii oprogramowania jest fakt, że 60-75% konwencjonalnych projektów programistycznych albo nie zostaje zakończonych, albo zostaje odrzuconych przez grupy docelowych użytkowników. Jeśli statystyki są choć w przybliżeniu prawdziwe (a nigdy nie spotkałem doświadczonego menedżera, który próbowałby je podważać), to przed większością projektów stawia się cela, które są albo (a) nierealistyczne, lub (b) po prostu błędne. Głównie z tego powodu w dzisiejszym świecie inżynierii oprogramowania samo wyrażenie "komitet zarządzający" potrafi wywołać u odbiorcy ciarki na całym ciele, nawet (albo szczególnie wtedy), kiedy słuchaczem jest menedżer. Czasy, kiedy tylko programiści zrzędzili z tego powodu, nalezą już do przeszłości; komiksy z Dilbertem wiszą obecnie nad biurkami dyrektorów. Nasza odpowiedź udzielona menedżerowi zarządzającymi projektami w tradycyjny sposób jest prosta: jeśli społeczność open source rzeczywiście nie doceniła wartość konwencjonalnego zarządzania projektami, dlaczego tak wielu z was ma tak niskie mniemanie o stosowanych przez was procesach? I ponownie istnienie społeczności open source znacznie zwiększa ciężar tego pytania, ponieważ praca nad projektami open source nas bawi. Nasza kreatywna zabawa w zawrotnym tempie zdobywa rynek i umysły i okazuje się sukcesem technologicznym. Udowadniamy, że potrafimy tworzyć lepsze oprogramowanie, zaś radość jest atutem. Dwa i pół roku po napisaniu pierwszej wersji tego eseju nie zakończę go wizją świata zdominowanego przez open source - najbardziej radykalną myślą, którą wówczas mógł stworzyć mój umysł: wizję tę bowiem akceptuje już wielu statecznych ludzi w garniturach. Zamiast owej wizji chciałbym przedstawić głębszą lekcję dotyczącą oprogramowania (a prawdopodobnie i wszelkiej pracy - twórczej czy zawodowej). Ludzie zazwyczaj znajdują przyjemność w zadaniach, które znajdują się w sferze "optymalnego wyzwania": nie zbyt łatwych, by się nie zanudzić - nie zbyt trudnych, by można było osiągnąć cel. Szczęśliwy programista to taki, który nie jest ani niewykorzystywany, a nie nie przytłoczony ciężarem źle sformułowanych celów i stresującego tarcia tworzącego się w procesie tworzenia. Radość źródłem wydajności.

  Dlatego odnoszenie się do własnego procesu pracy z uczuciem strachu i obrzydzenia (nawet w sposób oderwany i ironiczny, który sugeruje rozwieszanie komiksów z Dilbertem) powinno się uważać za znak, że proces ten zakończył się niepowodzeniem. Radość, humor i poczucie zabawy są prawdziwymi atutami - nie przypadkiem wspomniałem wcześniej o "szczęśliwych zastępach" programistów; nie bez znaczenia jest fakt, że maskotką Linuksa jest figlarny pingwin o dziecięcej buzi.

  Zrozumienie przez nas faktu, że zabawa jest najbardziej wydajnym ekonomicznie sposobem pracy twórczej, może sie okazać jedną z najważniejszych konsekwencji sukcesu open source. Epilog: Netscape wychodzi na bazar

  To dziwne odczucie - uświadomić sobie, że pomaga się tworzyć historię...

  22 stycznia 1998 roku, około 7 miesięcy po pierwszej publikacji Katedry i bazaru, Netscape Communications ogłosił plan udostępnienia źródeł Netscape Communicatora (http://www.netscape.com/newsref/pr/newsrelease558.html). Dowiedziałem się o tym dopiero w chwili ogłoszenia.

  Wkrótce po tym otrzymałem e-maila od Erica Hahna, wiceprezesa i szefa działu technologii w Netscape, w którym przeczytałem: "Przede wszystkim chciałbym w imieniu wszystkich tu w Netscape podziękować Panu za pomoc w dotarciu do miejsca, w którym się znajdujemy. Pana myśl i eseje były główną inspiracją naszej decyzji".

  Tydzień później odwiedziłem Krzemową Dolinę na zaproszenie Netscape, by uczestniczyć w jednodniowej konferencji strategicznej (4 lutego 1998 roku) wraz z kluczowymi postaciami z kadry zarządzającej i technicznej firmy. Wspólnie ustaliliśmy strategie udostępniania źródeł i licencję. Kilka dni później napisałem co następuje:

  Niedługo dane nam będzie dzięki Netscape przejść prawdziwy, znaczący test modelu bazarowego w świecie komercyjnym. Kultura open source stoi dziś w obliczu niebezpieczeństwa; jeśli projekt Netscape nie wypali, koncepcja open source może zostać tak zdyskredytowana, że świat biznesu nie dotknie jej przez następne 10 lat. Z drugiej strony test ten jest również dla nas wielką okazją. Początkowe reakcje na Wall Street i gdzie indziej były ostrożnie pozytywne. Nam tez dano możliwość wykazania się. Jeśli Netscape uda się dzięki temu ruchowi zdobyć znaczący segment rynku, może to być początek długo oczekiwanej rewolucji wśród producentów oprogramowania. Następny rok zapowiada się bardzo pouczająco i ciekawie.

  Tak tez się stało. Kiedy piszę ten tekst w połowie roku 1999, rozwój projektu, który później nazwano Mozillą, został uznany za udany. Udało się osiągnąć pierwotny cel Netscape, polegający na przeciwstawieniu się monopolowi Microsoftu na rynku przeglądarek internetowych. Odniesiono też kilka sporych sukcesów (zwłaszcza w związku z udostępnieniem silnika renderującego następnej generacji, Gecko).

  Nie udało się jednak zjednoczyć tyle grupowego wysiłku z zewnątrz Netscape, na ile liczyli twórcy projektu Mozilla. Problem leżał w tym, że przez długi czas dystrybucja Mozilli łamała jedną z podstawowych zasad modelu bazarowego: nie udostępnili niczego, co potencjalni współtwórcy mogliby łatwo uruchomić i obejrzeć w działaniu. (Ponad rok po udostępnieniu pierwszej wersji zbudowanie Mozilli ze źródeł wymagało licencji na komercyjna bibliotekę Motif.)

  Najgorsze (z punktu widzenia świata zewnętrznego) jest to, że zespół rozwijający Mozillę ma udostępnić przeglądarkę internetową dobrej jakości, zaś jedna z głównych osób uczestniczących w projekcie wywołała pewną sensację swoją rezygnacją, narzekając na złe zarządzanie i utracone możliwości. "Open source", jak słusznie zauważyła, "nie jest magiczną różdżką".

  I nie powinno być. Długoterminowe prognozy dotyczące rozwoju Mozilli wyglądają teraz (sierpień 1999) nieco lepiej niż w chwili rezygnacji Jamie Zawinsky'ego - miał on jednak rację mówiąc, że otwarcie się niekoniecznie ochroni istniejące projekty cierpiące z powodu źle określonych celów, bałaganiarskiego kodu i innych chronicznych dolegliwości znanych inżynierii oprogramowania. Mozilla jest przykładem tego, że projekt open source może się udać lub nie.

  W międzyczasie idea open source odniosła duży sukces i znalazła wielu zwolenników na całym świecie. W 1998 i pod koniec 1999 byliśmy świadkami eksplozji zainteresowania modelem rozwoju open source, który to trend zarówno kierował jak i był kierowany sukcesem systemu operacyjnego Linux. Trend, który zapoczątkowała Mozilla, rozwija się w coraz szybszym tempie.

  Tłumaczenie: Artur Skura, kwiecień 2001 r.

  Korekta: Little Snake

{1} hack -- (inteligentna) sztuczka (programistyczna); bardzo specyficzne słowo, używanie niemal wyłącznie w kulturze hakerskiej. Jako rzeczownik oznacza sztuczkę programistyczną, sprytne rozwiązanie w kodzie źródłowym programu; czasownik odnosi się do programowania, jednak nie chodzi tu o bezmyślne wpisywanie kodu, lecz wysokiej jakości pracę twórczą.

{2} GNU - skrót od "GNU is Not Unix", projekt całkowicie darmowego systemu operacyjnego zgodnego z systemem UNIX, rozpoczęty przez Richarda M. Stallmana w 1983 roku. Większość oprogramowania rozprowadzanego wraz z Linuksem stanowi część projektu GNU. Programy tworzone w ramach projektu GNU są udostępniane na licencji GPL (GNU Public License), dzięki której użytkownicy mogą swobodnie używać, modyfikować i rozpowszechniać zmodyfikowane kopie programów. Więcej informacji o projekcie GNU można uzyskać na stronach http://www.gnu.org.

{3} nethack - bodaj najpopularniejsza tekstowa gra przygodowa.

{4} Emacs - jeden z dwóch najpopularniejszych edytorów tekstowych dla systemów uniksowych (w tym Linuksa). Zaprojektowany przez Richarda M. Stallmana i będący częścią projektu GNU, Emacs stał się popularny dzięki niespotykanej elastyczności, licznym ułatwieniom dla programistów i przyjaznemu interfejsowi.

{5} ISP - Internet Service Provider, firma lub instytucja oferująca dostęp do Internetu.

{6} SLIP - Serial Line Internet Protocol, protokół odpowiedzialny za przesyłanie pakietów IP przez port szeregowy, a więc również przez modem. Obecnie używa się do tego celu protokołu PPP (Point-to-Point Protocol).

{7} Sendmail - najpopularniejszy uniksowy serwer poczty elektronicznej (MTA).

{8} Adres IP - adres komputera, dzięki któremu jest widoczny w sieci. Statyczny adres IP jest niezmienny, natomiast dynamiczny jest przydzielany zwykle na czas połączenia.

{9} Minix, stworzony w celach edukacyjnych przez prof. A. Tenenbauma, znanego specjalisty od systemów operacyjnych, został niedawno udostępniony na licencji open source. W linuksowych archiwach zachowały się interesujące dyskusje Linusa Torvaldsa z prof. Tenebaumem, m.in. znana wypowiedź "gdyby był Pan moim studentem, za ten projekt dostałby Pan dwóję"...

{10} Wymienione systemy kontroli wersji pomagają programistom w dokumentacji pracy nad programem, unikaniu pomyłek oraz trzymaniu porządku w kodzie. Ostatni z nich, CVS, jest powszechnie stosowany w wielu projektach open source jako narzędzie wspomagające pracę grupową. Dzięki niemu wiele osób może pracować równocześnie nad jednym projektem nie przeszkadzając sobie nawzajem.

{11} Wynika to z założeń projektu GNU, chroniących użytkowników przed próbami zawłaszczenia kodu przez autorów, którzy po pewnym czasie mogliby zmienić zdanie, ich spadkobierców itd.

{12} betatesterzy - osoby testujące wersje oprogramowania zwane "beta", tj. jeszcze nie gotowe, udostępniane w celu eliminacji błędów (praktyka ta jest powszechna wśród wielu producentów oprogramowania, nawet nie mających wiele wspólnego z Open Source, np. Adobe czy Microsoft). Wersje zwane "alfa" to aplikacje w bardzo wczesnym stadium rozwoju, użyteczne zwykle jedynie dla programistów. W świecie Open Source wersje alfa można zwykle rozpoznać po numerze wersji mniejszym od 1 (np. Xdialog 0.12), zaś wersje beta mają często nieparzysty numer podwersji (np. gtk+ 1.3.2, linux 2.3.39).

{13}poprawki - chodzi o tzw. łaty (patches), czyli zapisany w specjalnym formacie plik zawierający różnice między dwoma plikami czy zestawami plików, przy czym najczęściej chodzi o pliki źródłowe. Dzięki "zaaplikowaniu łaty" stary plik staje się identyczny z nowym. Jest to bardzo ekonomiczne rozwiązanie, zwłaszcza w przypadku, kiedy cały kod źródłowy ma ogromne rozmiary, zaś wprowadzane zmiany są niewielkie. Łaty są najpopularniejszą metodą wprowadzania zmian w społeczności Open Source również z tego powodu, że kilka osób może wprowadzić kilka różnych usprawnień do tego samego pliku nie powodując żadnych konfliktów.

{14} SMTP - Simple Mail Transmission Protocol, protokół wykorzystywany do wysyłania poczty (podczas gdy POP czy IMAP służą do odbierania jej). Protokół ten jest szczegółowo opisany w dokumencie RFC 821.

{15} Perl - potężny, skryptowy język programowania, używany przez programistów na całym świecie (również przy budowie serwisów WWW).

{16} OK - kod zwracany przez demona SMTP, jeśli operacja zakończyła się sukcesem. Protokół SMTP (jak i wiele innych protokołów internetowych) przypomina dialogi w języku angielskim. Klient komunikuje się z serwerem począwszy od komunikatu HELO (lub EHLO), zaś serwer odpowiada komunikatem OK lub ERR (po którym opcjonalnie mogą wystąpić inne informacje, wskazujące np. na przyczynę błędu). Dialog ten można ujrzeć wywołując fetchmaila z opcją -v.

{17} man - w systemach uniksowych programom (i nie tylko - dotyczy to również m.in. funkcji systemowych i plików konfiguracyjnych) towarzyszą pliki pomocy, zwane man (od angielskiego manual - podręcznik). I tak chcąc uzyskać pomoc na temat fetchmaila, wystarczy napisać man fetchmail, a wyświetli się strona podręcznika, wyjaśniając a sposób korzystania z fetchmaila.

{18} odpluskwianie (debugging) - proces znajdowania błędów w programie, polegający zazwyczaj na żmudnej analizie kodu, uruchamianiu programu z różnymi parametrami i testowaniu w różnych sytuacjach przy wykorzystaniu różnych narzędzi, zwanych debuggerami.

{19} aliasy - alternatywne nazwy. Serwery pocztowe korzystają zazwyczaj ze specjalnych plików, zawierających symboliczną nazwę (czyli alias) wraz z przypisanymi rzeczywistymi adresami jednego lub więcej użytkowników. Dzięki temu użytkowni jkowal może otrzymywać pocztę wysyłaną na adres Jan.Kowalski@serwer.com. Jeśli użytkowników skojarzonych z danym aliasem jest więcej, powstaje prymitywna lista dyskusyjna, tj. każdy list wysłany na ów adres dociera do wszystkich użytkowników skojarzonych z aliasem.

{20} pliki rc - pliki konfiguracyjne, których nazwa zazwyczaj ma końcówkę rc (w przypadku fetchmaila jest to .fetchmailrc), przechowujące opcje konfiguracyjne

{21} zapewnienie bezpieczeństwa przez niejawność (security by obscurity) - metoda zapewniania bezpieczeństwa polegająca na ukrywaniu ustawień systemowych, konfiguracji itp., próbując wprowadzić atakującego w błąd. Metoda ta jest bardzo nisko oceniana przez ekspertów od zabezpieczeń, zwłaszcza jeśli jest jedynym zabezpieczeniem systemu.

{22} UNIX powstał w Bell Labs (obecie Lucent); Richard Stallman, lider projektu GNU i główny twórca najważniejszego narzędzia używanego przez programistów linuksowych - kompilatora gcc, rozpoczął swoją działalność i przez pewien czas kontynuował ją w Laboratorium AI Massachusetts Institute of Technology; na uniwersytecie Berkeley powstało wiele narzędzi oraz kod różnych usług sieciowych.

{23} ukrywanie/strzeżenie kodu źródłowego oprogramowania (software hoarding) - termin używany przez Richarda Stallmana w stosunku do firm udostępniających jedynie wynikowe, binarne wersje programów. Znaleźć go można np. w słynnym "Hymnie hackerów" ("Hoarders may have piles of money, this is true, hackers, this is true...").