Katedra i Bazar [The Cathedral and the Bazzar] (1999) Eric Raymond

Essej na temat sposobów tworzenia oprogramowania - opisujący efekty sieciowe oraz mądrość tłumu "crowdwisdom".
Praktycznie pierwsza pozycja opisująca duch ruchu open/free source.

Polskie tłumaczenie online http://www.mkgajwer.jgora.net/katedra.html

Wersja angielska : http://users.ece.utexas.edu/~perry/education/382v-s08/papers/raymond.pdf

http://www.catb.org/esr/writings/cathedral-bazaar/cathedral-bazaar/

Permission is granted to copy, distribute and/or modify this document under the terms of the Open Publication License, version 2.0.

https://en.wikipedia.org/wiki/Open_Publication_License

ver. 1.0
http://opencontent.org/openpub/

Abstrakt

Analizuję udany projekt open-source, fetchmail, który został uruchomiony jako celowy test zaskakujących teorii na temat inżynierii oprogramowania sugerowanych przez historię Linuksa. Omawiam te teorie w kontekście dwóch fundamentalnie różnych stylów rozwoju, modelu "katedry" stosowanego przez większość świata komercyjnego i modelu "bazaru" w świecie Linuksa. Pokazuję, że modele te wywodzą się z przeciwstawnych założeń dotyczących natury zadania usuwania błędów w oprogramowaniu. Następnie, na podstawie doświadczeń z Linuksem, przytaczam argumenty na rzecz tezy, że ``Gdy ma się wystarczająco dużo oczu, wszystkie błędy są płytkie'', sugeruję produktywne analogie z innymi samonaprawiającymi się systemami samolubnych agentów i kończę badaniem implikacji tego spostrzeżenia dla przyszłości oprogramowania.

Katedra i Bazar

Linux jest wywrotowy. Kto by pomyślał nawet pięć lat temu (1991), że światowej klasy system operacyjny może powstać jak za dotknięciem czarodziejskiej różdżki z pracy na pół etatu kilku tysięcy programistów rozproszonych po całej planecie, połączonych jedynie wątłymi nićmi Internetu?

Na pewno nie ja. Gdy Linux pojawił się na moim ekranie na początku 1993 roku, byłem już od dziesięciu lat zaangażowany w rozwój Uniksa i oprogramowania open source. Byłem jednym z pierwszych współtwórców GNU w połowie lat osiemdziesiątych. Udostępniłem w sieci sporą ilość oprogramowania open-source, rozwijając lub współtworząc kilka programów (nethack, tryby VC i GUD w Emacsie, xlife i inne), które do dziś są w powszechnym użyciu. Wydawało mi się, że wiem jak to się robi.

Linux obalił wiele z tego, co wydawało mi się, że wiem. Przez lata głosiłem uniksową ewangelię małych narzędzi, szybkiego prototypowania i programowania ewolucyjnego. Ale wierzyłem też, że istnieje pewna krytyczna złożoność, powyżej której wymagane jest bardziej scentralizowane podejście a priori. Wierzyłem, że najważniejsze oprogramowanie (systemy operacyjne i naprawdę duże narzędzia, takie jak edytor Emacs) muszą być budowane jak katedry, starannie tworzone przez pojedynczych czarodziejów lub małe grupy magów pracujących we wspaniałej izolacji, z żadną betą, która nie zostanie wydana przed czasem.

Styl rozwoju Linusa Torvaldsa - wydawać wcześnie i często, delegować wszystko, co się da, być otwartym aż do granic rozwiązłości - był zaskoczeniem. Nie było tu cichego, pełnego czci budowania katedry - raczej społeczność Linuksa wydawała się przypominać wielki, bulgoczący bazar różnych programów i podejść (trafnie symbolizowany przez strony archiwalne Linuksa, które przyjmowały zgłoszenia od każdego), z którego spójny i stabilny system mógł się wyłonić tylko dzięki serii cudów.

Fakt, że ten bazarowy styl wydawał się działać, i to działać dobrze, był dla mnie wyraźnym szokiem. W miarę jak się uczyłem, ciężko pracowałem nie tylko nad poszczególnymi projektami, ale także nad próbą zrozumienia, dlaczego świat Linuksa nie tylko nie rozpadł się w chaosie, ale wydawał się rosnąć w siłę z prędkością ledwie wyobrażalną dla budowniczych katedr.

W połowie 1996 roku wydawało mi się, że zaczynam rozumieć. Przypadek podsunął mi doskonały sposób na przetestowanie mojej teorii, w postaci projektu open-source, który mogłem świadomie próbować prowadzić w stylu bazarowym. Tak też zrobiłem - i był to znaczący sukces.

To jest historia tego projektu. Wykorzystam ją do zaproponowania kilku aforyzmów na temat efektywnego rozwoju open-source. Nie wszystkie z nich są rzeczami, których po raz pierwszy nauczyłem się w świecie Linuksa, ale zobaczymy jak świat Linuksa nada im szczególny sens. Jeśli mam rację, pomogą wam one zrozumieć, co dokładnie sprawia, że społeczność linuksowa jest taką fontanną dobrego oprogramowania - i, być może, pomogą wam stać się bardziej produktywnymi.

Poczta musi się przedostać

Od 1993 roku zajmowałem się techniczną stroną małego dostawcy bezpłatnego dostępu do Internetu o nazwie Chester County InterLink (CCIL) w West Chester, w Pensylwanii. Byłem współzałożycielem CCIL i napisałem nasze unikalne, wieloużytkownikowe oprogramowanie tablicy ogłoszeń - możesz je sprawdzić, telnetując na locke.ccil.org. Dziś obsługuje ono prawie trzy tysiące użytkowników na trzydziestu liniach. Praca pozwalała mi na całodobowy dostęp do sieci poprzez linię 56K CCIL - w rzeczywistości, praca praktycznie tego wymagała!

Przyzwyczaiłem się już do natychmiastowej poczty internetowej. Irytowała mnie konieczność okresowego telnetowania się do locke'a, aby sprawdzić pocztę. Chciałem, aby moja poczta była dostarczana do snarka (mój domowy system), dzięki czemu byłbym powiadamiany o jej nadejściu i mógłbym ją obsługiwać za pomocą wszystkich moich lokalnych narzędzi.

Internetowy protokół przekazywania poczty, SMTP (Simple Mail Transfer Protocol), nie byłby odpowiedni, ponieważ działa najlepiej, gdy maszyny są podłączone na stałe, podczas gdy moja osobista maszyna nie zawsze jest w Internecie i nie ma statycznego adresu IP. To, czego potrzebowałem, to program, który sięgałby przez moje przerywane połączenie dialup i wyciągał moją pocztę, aby dostarczyć ją lokalnie. Wiedziałem, że takie rzeczy istnieją i że większość z nich używa prostego protokołu aplikacji zwanego POP (Post Office Protocol). POP jest obecnie powszechnie obsługiwany przez większość popularnych klientów pocztowych, ale w tamtym czasie nie był wbudowany w czytnik poczty, którego używałem.

Potrzebowałem klienta POP3. Poszedłem więc do Internetu i znalazłem jednego. Właściwie to znalazłem trzy lub cztery. Używałem jednego z nich przez jakiś czas, ale brakowało mu czegoś, co wydawało się oczywiste - możliwości zhakowania adresów w pobranej poczcie, tak by odpowiedzi działały poprawnie.

Problem był następujący: załóżmy, że ktoś o imieniu `joe' na locke wysłał mi maila. Jeśli pobrałbym pocztę na snark, a następnie spróbowałbym na nią odpowiedzieć, mój mailer próbowałby wysłać ją do nieistniejącego "Joe" na snark. Ręczne edytowanie adresów odpowiedzi w celu dodania <@ccil.org> szybko stało się poważnym bólem.

Było to coś, co komputer powinien robić za mnie. Ale żaden z istniejących klientów POP nie wiedział jak! I w ten sposób dochodzimy do pierwszej lekcji:

1. Każde dobre oprogramowanie zaczyna się od zaspokojenia osobistych potrzeb programisty.

Być może powinno to być oczywiste (od dawna mówi się, że ``konieczność jest matką wynalazku''), ale zbyt często programiści spędzają dni na płatnej pracy nad programami, których ani nie potrzebują, ani nie kochają. Ale nie w świecie Linuksa - co może wyjaśniać dlaczego średnia jakość oprogramowania tworzonego w społeczności Linuksa jest tak wysoka.

Tak więc, czy od razu rzuciłem się w wir kodowania zupełnie nowego klienta POP3 aby konkurować z istniejącymi? Nie w życiu! Przyjrzałem się uważnie narzędziom POP, które miałem pod ręką, zadając sobie pytanie ``Które z nich jest najbliższe temu, czego chcę? Ponieważ:

2. Dobrzy programiści wiedzą, co pisać. Wielcy wiedzą, co przepisać (i ponownie wykorzystać).

Chociaż nie twierdzę, że jestem świetnym programistą, staram się go naśladować. Ważną cechą tych świetnych jest konstruktywne lenistwo. Wiedzą, że szóstkę dostaje się nie za wysiłek, ale za wyniki, i że prawie zawsze łatwiej jest zacząć od dobrego rozwiązania częściowego niż od niczego.

Linus Torvalds, na przykład, nie próbował napisać Linuksa od zera. Zamiast tego zaczął od ponownego wykorzystania kodu i pomysłów z Minixa, malutkiego, uniksopodobnego systemu operacyjnego dla klonów PC. Ostatecznie cały kod Minixa zniknął lub został całkowicie przepisany, ale póki istniał, stanowił rusztowanie dla niemowlęcia, które ostatecznie stało się Linuksem.

W tym samym duchu poszukałem istniejącego narzędzia POP, które było w miarę dobrze zakodowane, aby wykorzystać je jako bazę do rozwoju.

Tradycja dzielenia się źródłami w świecie Uniksa zawsze była przyjazna dla ponownego użycia kodu (to dlatego projekt GNU wybrał Uniksa jako bazowy system operacyjny, pomimo poważnych zastrzeżeń co do samego systemu). Świat Linuksa wykorzystał tę tradycję niemal do granic możliwości technologicznych; ma terabajty ogólnie dostępnych otwartych źródeł. Więc spędzanie czasu na szukaniu prawie-dobrego-dostatecznego dla kogoś innego jest bardziej prawdopodobne, aby dać ci dobre wyniki w świecie Linuksa niż gdziekolwiek indziej.

I tak było w moim przypadku. Z tych, które znalazłem wcześniej, moje drugie wyszukiwanie dało w sumie dziewięciu kandydatów - fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail i upop. Pierwszym, na którym się zdecydowałem był `fetchpop' autorstwa Seung-Hong Oh. Umieściłem w nim moją funkcję przepisywania nagłówków i wprowadziłem różne inne ulepszenia, które autor zaakceptował w swoim wydaniu 1.9.

Kilka tygodni później natknąłem się jednak na kod popclienta autorstwa Carla Harrisa i odkryłem, że mam problem. Chociaż fetchpop miał kilka dobrych, oryginalnych pomysłów (takich jak tryb background-daemon), mógł obsługiwać tylko POP3 i był raczej amatorsko zakodowany (Seung-Hong był w tym czasie bystrym, ale niedoświadczonym programistą, i obie te cechy były widoczne). Kod Carla był lepszy, całkiem profesjonalny i solidny, ale jego programowi brakowało kilku ważnych i raczej trudnych do zaimplementowania funkcji fetchpopa (w tym tych, które sam zakodowałem).

Zostać czy zmienić? Gdybym się przesiadł, wyrzuciłbym kodowanie, które już zrobiłem, w zamian za lepszą bazę programistyczną.

Praktycznym motywem do zmiany była obecność obsługi wielu protokołów. POP3 jest najczęściej używanym z protokołów serwerów pocztowych, ale nie jedynym. Fetchpop i pozostała konkurencja nie obsługiwały POP2, RPOP ani APOP, a ja już miałem mgliste myśli o dodaniu IMAP (Internet Message Access Protocol, najnowszy i najpotężniejszy protokół pocztowy) tak dla zabawy.

Ale miałem też bardziej teoretyczny powód, by myśleć, że przełączanie może być równie dobrym pomysłem, coś, czego nauczyłem się na długo przed Linuksem.

3. Zaplanuj wyrzucenie jednego; i tak to zrobisz. (Fred Brooks, The Mythical Man-Month, rozdział 11)

Lub, mówiąc inaczej, często nie rozumiesz problemu aż do momentu, gdy po raz pierwszy wdrożysz rozwiązanie. Za drugim razem być może wiesz już wystarczająco dużo, aby zrobić to dobrze. Więc jeśli chcesz zrobić to dobrze, bądź gotowy zacząć od nowa przynajmniej raz [JB].

Cóż (powiedziałem sobie), zmiany w fetchpop były moją pierwszą próbą. Więc zmieniłem.

Po wysłaniu mojego pierwszego zestawu poprawek do popclienta do Carla Harrisa 25 czerwca 1996, dowiedziałem się, że w zasadzie stracił zainteresowanie popclientem jakiś czas wcześniej. Kod był nieco zakurzony, z wiszącymi drobnymi błędami. Miałem wiele zmian do wprowadzenia i szybko zgodziliśmy się, że logiczną rzeczą, którą powinienem zrobić, jest przejęcie programu.

Bez mojego zauważenia, projekt uległ eskalacji. Nie rozważałem już tylko drobnych poprawek do istniejącego klienta POP. Zacząłem zajmować się utrzymaniem całego klienta, a w mojej głowie kłębiły się pomysły, o których wiedziałem, że prawdopodobnie doprowadzą do poważnych zmian.

W kulturze oprogramowania, która zachęca do dzielenia się kodem, jest to naturalny sposób na ewolucję projektu. Działałem zgodnie z tą zasadą:

4. Jeśli masz właściwe nastawienie, interesujące problemy same cię znajdą.

Ale postawa Carla Harrisa była jeszcze ważniejsza. Rozumiał on, że

5. Kiedy tracisz zainteresowanie jakimś programem, twoim ostatnim obowiązkiem wobec niego jest przekazanie go kompetentnemu następcy.

Bez konieczności dyskutowania o tym, Carl i ja wiedzieliśmy, że mamy wspólny cel, jakim jest posiadanie najlepszego rozwiązania. Jedynym pytaniem dla każdego z nas było to, czy będę w stanie stwierdzić, że jestem bezpieczną parą rąk. Kiedy już to zrobiłem, działał z wdziękiem i dyspozycyjnością. Mam nadzieję, że zrobię to równie dobrze, gdy nadejdzie moja kolej.

Znaczenie posiadania użytkowników

I tak odziedziczyłem popclienta. Co równie ważne, odziedziczyłem bazę użytkowników popclienta. Użytkownicy to wspaniała rzecz, którą warto mieć, i to nie tylko dlatego, że pokazują, że zaspokajasz potrzebę, że zrobiłeś coś dobrze. Odpowiednio pielęgnowani, mogą stać się współtwórcami.

Inną mocną stroną tradycji Uniksa, którą Linux doprowadza do szczęśliwego ekstremum, jest to, że wielu użytkowników to także hakerzy. Ponieważ kod źródłowy jest dostępny, mogą oni być efektywnymi hakerami. Może to być niezwykle przydatne dla skrócenia czasu debugowania. Przy odrobinie zachęty, użytkownicy zdiagnozują problemy, zasugerują poprawki i pomogą ulepszyć kod o wiele szybciej, niż ty sam mógłbyś to zrobić.

6. Traktowanie użytkowników jak współtwórców jest najmniej kłopotliwą drogą do szybkiego ulepszania kodu i efektywnego debugowania.

Potęga tego efektu jest łatwa do niedocenienia. W rzeczywistości, prawie wszyscy w świecie open-source drastycznie nie docenialiśmy tego, jak dobrze będzie się on skalował wraz z liczbą użytkowników i złożonością systemu, dopóki Linus Torvalds nie pokazał nam, że jest inaczej.

W rzeczywistości uważam, że najsprytniejszym i najbardziej znaczącym posunięciem Linusa nie było zbudowanie samego jądra Linuksa, ale raczej wynalezienie przez niego modelu rozwoju Linuksa. Kiedy kiedyś wyraziłem tę opinię w jego obecności, uśmiechnął się i cicho powtórzył coś, co często powtarzał: ``Jestem w zasadzie bardzo leniwą osobą, która lubi przypisywać sobie zasługi za rzeczy, które inni ludzie faktycznie robią.'' Leniwy jak lis. Lub, jak Robert Heinlein napisał o jednym ze swoich bohaterów, zbyt leniwy, by ponieść porażkę.

Patrząc z perspektywy czasu, jeden z precedensów metod i sukcesu Linuksa można dostrzec w rozwoju biblioteki GNU Emacs Lisp i archiwów kodu Lisp. W przeciwieństwie do stylu budowania katedry w rdzeniu C Emacsa i większości innych narzędzi GNU, ewolucja puli kodu Lispa była płynna i bardzo sterowana przez użytkowników. Pomysły i prototypy były często przepisywane trzy lub cztery razy, zanim osiągnęły stabilną formę końcową. A luźno powiązana współpraca, możliwa dzięki Internetowi, jak w Linuksie, była częsta.

W rzeczy samej, moim najbardziej udanym pojedynczym dziełem poprzedzającym fetchmail był prawdopodobnie tryb VC (kontroli wersji) Emacsa. Była to linuksowa współpraca mailowa z trzema innymi osobami, z których tylko jedną (Richarda Stallmana, autora Emacsa i założyciela Fundacji Wolnego Oprogramowania) spotkałem do dziś. Był to front-end dla SCCS, RCS, a później CVS z poziomu Emacsa, który oferował ``one-touch'' - operacje kontroli wersji. Wyewoluował z malutkiego, prymitywnego trybu sccs.el napisanego przez kogoś innego. Rozwój VC zakończył się sukcesem, ponieważ, w przeciwieństwie do samego Emacsa, kod Emacsa Lispa mógł bardzo szybko przechodzić przez kolejne generacje wydań/testów/ulepszeń.

Historia Emacsa nie jest wyjątkowa. Istniały już inne produkty programowe o dwupoziomowej architekturze i dwupoziomowej społeczności użytkowników, które łączyły w sobie rdzeń w trybie katedry i zestaw narzędzi w trybie bazaru. Jednym z nich jest MATLAB, komercyjne narzędzie do analizy i wizualizacji danych. Użytkownicy MATLABa i innych produktów o podobnej strukturze niezmiennie donoszą, że akcja, ferment, innowacje mają miejsce głównie w otwartej części narzędzia, gdzie duża i zróżnicowana społeczność może majstrować przy nim.

Wydawaj wcześnie, wydawaj często

Wczesne i częste wydania są krytyczną częścią modelu rozwoju Linuksa. Większość programistów (włączając mnie) wierzyła, że jest to zła polityka dla większych niż trywialne projektów, ponieważ wczesne wersje są prawie z definicji błędne, a nie chcesz nadwyrężać cierpliwości swoich użytkowników.

To przekonanie wzmocniło ogólne przywiązanie do stylu budowania katedry. Gdyby nadrzędnym celem było, aby użytkownicy widzieli jak najmniej błędów, to dlaczego wtedy wydawalibyśmy wersję tylko co sześć miesięcy (lub rzadziej) i pracowali jak pies nad debugowaniem pomiędzy wydaniami. Rdzeń Emacsa C został opracowany w ten sposób. Biblioteka Lispa, w efekcie, nie była - ponieważ istniały aktywne archiwa Lispa poza kontrolą FSF, gdzie można było znaleźć nowe i rozwojowe wersje kodu, niezależnie od cyklu wydawniczego Emacsa [QR].

Najważniejsze z nich, archiwum Ohio State Emacs Lisp, antycypowało ducha i wiele cech dzisiejszych dużych archiwów Linuksa. Ale niewielu z nas tak naprawdę myślało bardzo intensywnie o tym, co robimy, albo o tym, co samo istnienie tego archiwum sugeruje na temat problemów w modelu rozwoju FSF opartym na budowaniu katedry. Około 1992 roku podjąłem jedną poważną próbę, aby wiele kodu Ohio zostało formalnie włączone do oficjalnej biblioteki Emacsa Lispa. Wpadłem w kłopoty polityczne i w dużej mierze mi się to nie udało.

Ale rok później, gdy Linux stał się szeroko widoczny, stało się jasne, że dzieje się tam coś innego i znacznie zdrowszego. Otwarta polityka rozwoju Linusa była przeciwieństwem budowania katedry. Internetowe archiwa Linuksa rozrastały się, na rynku pojawiały się różne dystrybucje. A wszystko to było napędzane przez niespotykaną dotąd częstotliwość wydawania podstawowych wersji systemu.

Linus traktował swoich użytkowników jak współtwórców w najbardziej efektywny z możliwych sposobów:

7. Wydawaj wcześnie. Wypuszczaj często. I słuchaj swoich klientów.

Innowacyjność Linusa polegała nie tyle na szybkich wydaniach zawierających wiele informacji zwrotnych od użytkowników (coś takiego było tradycją w świecie Uniksa przez długi czas), ale na skalowaniu tego do poziomu intensywności, który odpowiadał złożoności tego, co rozwijał. W tych wczesnych czasach (około 1991 roku) nie było niczym niezwykłym, że wydawał nowe jądro więcej niż raz dziennie! Ponieważ kultywował swoją bazę programistów i wykorzystał Internet do współpracy mocniej niż ktokolwiek inny, to zadziałało.

Ale jak to działało? I czy było to coś, co mógłbym powielić, czy też polegało to na jakimś unikalnym geniuszu Linusa Torvaldsa?

Nie sądziłem, że tak. Przyznaję, Linus jest cholernie dobrym hakerem. Ilu z nas potrafiłoby stworzyć od podstaw całe jądro systemu operacyjnego o jakości produkcyjnej? Ale Linux nie reprezentował jakiegoś niesamowitego, konceptualnego skoku naprzód. Linus nie jest (a przynajmniej jeszcze nie jest) innowacyjnym geniuszem projektowania w sposób, w jaki są, powiedzmy, Richard Stallman lub James Gosling (z NeWS i Java). Raczej Linus wydaje mi się być geniuszem inżynierii i implementacji, z szóstym zmysłem do unikania błędów i ślepych zaułków rozwoju oraz prawdziwym talentem do znajdowania ścieżki od punktu A do punktu B przy minimalnym wysiłku.

Więc, jeśli szybkie wydania i wykorzystanie medium Internetu do maksimum nie były przypadkiem, ale integralną częścią inżynierskiego geniuszu Linusa, który dostrzegł ścieżkę minimalnego wysiłku, co on maksymalizował? Co on wydobywał z maszyny?

Mówiąc w ten sposób, pytanie samo się nasuwa. Linus utrzymywał swoich hakerów/użytkowników w stanie ciągłej stymulacji i nagrody - stymulacji poprzez perspektywę posiadania satysfakcjonującego ego kawałka akcji, nagrody poprzez widok ciągłych (nawet codziennych) ulepszeń w ich pracy.

Linus bezpośrednio dążył do maksymalizacji liczby osobogodzin poświęconych na debugowanie i rozwój, nawet za cenę możliwej niestabilności kodu i wypalenia się bazy użytkowników, jeśli jakikolwiek poważny błąd okazał się nie do pokonania. Linus zachowywał się tak, jakby w coś takiego wierzył:

8. Biorąc pod uwagę wystarczająco dużą bazę beta-testerów i współtwórców, prawie każdy problem zostanie szybko scharakteryzowany, a poprawka będzie dla kogoś oczywista.

Lub, mniej formalnie, ``Gdy ma się wystarczająco dużo oczu, wszystkie błędy są płytkie''. Ja to nazywam: Prawo Linusa''.

Moim oryginalnym sformułowaniem było, że każdy problem ``będzie dla kogoś przejrzysty''. Linus zaprzeczył, że osoba, która rozumie i rozwiązuje problem nie jest koniecznie lub nawet zazwyczaj osobą, która pierwsza go scharakteryzowała. Ktoś znajduje problem'', mówi, ''a ktoś inny go rozumie. I zapiszę się w protokole jako osoba, która mówi, że znalezienie go jest większym wyzwaniem. Ta poprawka jest ważna; zobaczymy jak w następnej sekcji, kiedy będziemy bardziej szczegółowo analizować praktykę debugowania. Ale kluczowym punktem jest to, że obie części procesu (znajdowanie i naprawianie) mają tendencję do szybkiego działania.

Myślę, że w prawie Linusa tkwi podstawowa różnica pomiędzy stylami budowania katedry i bazaru. W stylu budowania katedry błędy i problemy programistyczne są podstępnymi, podstępnymi, głębokimi zjawiskami. Potrzeba miesięcy analizowania przez dedykowaną garstkę osób, aby nabrać pewności, że udało się je wszystkie usunąć. Stąd długie odstępy między kolejnymi wydaniami i nieuniknione rozczarowanie, gdy długo oczekiwane wydania nie są doskonałe.

Z drugiej strony, w podejściu bazarowym zakładasz, że błędy są zazwyczaj płytkimi zjawiskami - lub przynajmniej, że stają się płytkie dość szybko, gdy są wystawione na działanie tysiąca chętnych współtwórców, którzy pracują nad każdym nowym wydaniem. W związku z tym wydajesz często, aby uzyskać więcej poprawek, a jako korzystny efekt uboczny masz mniej do stracenia, jeśli sporadyczny błąd wydostanie się przez drzwi.

I to jest to. To wystarczy. Jeśli ''Prawo Linusa'' jest fałszywe, to każdy system tak złożony jak jądro Linuksa, hakowany przez tak wiele rąk jak tamto jądro, powinien w pewnym momencie załamać się pod ciężarem nieprzewidzianych złych interakcji i nieodkrytych ``głębokich'' błędów. Jeśli to prawda, z drugiej strony, jest to wystarczające wyjaśnienie względnego braku bugów w Linuksie i jego ciągłego działania przez miesiące, a nawet lata.

Być może nie powinno to być aż taką niespodzianką. Socjologowie lata temu odkryli, że uśredniona opinia masy równie biegłych (lub równie ignoranckich) obserwatorów jest bardziej wiarygodnym prognostykiem niż opinia jednego losowo wybranego obserwatora. Nazwali to efektem Delphi. Wygląda na to, że Linus pokazał, że ma to zastosowanie nawet do debugowania systemu operacyjnego - że efekt Delphi może poskromić złożoność rozwoju nawet na poziomie złożoności jądra systemu operacyjnego. [CV]

Jedną ze szczególnych cech sytuacji w Linuksie, która wyraźnie wspomaga efekt Delphi, jest fakt, że osoby współtworzące dany projekt są samodzielnie wybierane. Jeden z pierwszych respondentów zauważył, że wkład nie pochodzi z przypadkowej próbki, ale od ludzi, którzy są wystarczająco zainteresowani, by używać oprogramowania, dowiedzieć się, jak ono działa, próbować znaleźć rozwiązanie napotkanych problemów i rzeczywiście stworzyć pozornie sensowną poprawkę. Jest bardzo prawdopodobne, że każdy, kto przejdzie wszystkie te filtry, może wnieść coś użytecznego.

Prawo Linusa można przeformułować jako ``Debugowanie jest równoległe''. Chociaż debugowanie wymaga, aby debugger komunikował się z jakimś koordynującym programistą, nie wymaga znaczącej koordynacji pomiędzy debuggerami. Dzięki temu nie pada ofiarą tej samej kwadratowej złożoności i kosztów zarządzania, które sprawiają, że dodawanie programistów jest problematyczne.

W praktyce, teoretyczna utrata wydajności spowodowana powielaniem pracy przez debuggerów prawie nigdy nie wydaje się być problemem w świecie Linuksa. Jednym z efektów polityki ``wydawaj wcześnie i często'' jest zminimalizowanie takiego powielania poprzez szybkie propagowanie poprawek [JH].

Brooks (autor The Mythical Man-Month) poczynił nawet pewną obserwację związaną z tym: Całkowity koszt utrzymania powszechnie używanego programu wynosi zazwyczaj 40 procent lub więcej kosztu jego opracowania. Zaskakująco ten koszt jest silnie uzależniony od liczby użytkowników. Więcej użytkowników znajduje więcej błędów. [podkreślenie dodane].

Więcej użytkowników znajduje więcej błędów, ponieważ dodanie większej liczby użytkowników powoduje więcej różnych sposobów obciążania programu. Ten efekt jest wzmocniony, gdy użytkownicy są współtwórcami. Każdy z nich podchodzi do zadania charakteryzacji błędów z nieco innym zestawem percepcyjnym i analitycznym, innym spojrzeniem na problem. Efekt Delphi'' wydaje się działać właśnie dzięki temu zróżnicowaniu. W specyficznym kontekście debugowania, zróżnicowanie ma również tendencję do zmniejszania duplikacji wysiłków.

Tak więc dodanie większej ilości beta-testerów może nie zmniejszyć złożoności obecnego ``najgłębszego'' błędu z punktu widzenia dewelopera, ale zwiększa prawdopodobieństwo, że czyjś zestaw narzędzi zostanie dopasowany do problemu w taki sposób, że błąd będzie dla tej osoby płytki.

Linus również stawia na swoim. W przypadku pojawienia się poważnych błędów, wersje jądra Linuksa są numerowane w taki sposób, że potencjalni użytkownicy mogą dokonać wyboru, albo uruchomić ostatnią wersję oznaczoną jako ``stabilna'', albo jechać na krawędzi i ryzykować błędy w celu uzyskania nowych funkcji. Ta taktyka nie jest jeszcze systematycznie naśladowana przez większość hakerów Linuksa, ale być może powinna być; fakt, że każdy z tych wyborów jest dostępny, czyni oba bardziej atrakcyjnymi. [HBS]

Jak wiele gałek ocznych poskramia złożoność

Jedną rzeczą jest zaobserwowanie na dużym obszarze, że styl bazarowy znacznie przyspiesza debugowanie i ewolucję kodu. Inną jest zrozumienie dokładnie jak i dlaczego tak się dzieje na poziomie mikro, w codziennym zachowaniu programistów i testerów. W tej części (napisanej trzy lata po oryginalnym artykule, z wykorzystaniem spostrzeżeń programistów, którzy przeczytali go i ponownie przeanalizowali swoje własne zachowanie) przyjrzymy się dokładnie faktycznym mechanizmom. Nietechnicznie uzdolnieni czytelnicy mogą spokojnie przejść do następnej sekcji.

Jednym z kluczy do zrozumienia jest uświadomienie sobie dokładnie, dlaczego rodzaj raportu o błędzie, który zwykle zgłaszają użytkownicy nieświadomi źródła, nie jest zbyt użyteczny. Użytkownicy nieświadomi źródła mają tendencję do zgłaszania tylko objawów powierzchniowych; biorą swoje środowisko za pewnik, więc (a) pomijają krytyczne dane tła, i (b) rzadko zawierają wiarygodną receptę na odtworzenie błędu.

Podstawowym problemem jest tu niedopasowanie modeli mentalnych testera i dewelopera programu; testera, patrzącego z zewnątrz, i dewelopera, patrzącego od wewnątrz. W rozwoju zamkniętego oprogramowania obaj tkwią w tych rolach, mają tendencję do mówienia obok siebie i uważają się za głęboko sfrustrowanych.

Rozwój oparty na otwartym kodzie źródłowym przerywa tę więź, czyniąc znacznie łatwiejszym dla testera i dewelopera rozwijanie wspólnej reprezentacji opartej na rzeczywistym kodzie źródłowym i efektywne komunikowanie się na jego temat. Praktycznie, istnieje ogromna różnica w dźwigni dla dewelopera pomiędzy rodzajem raportu o błędzie, który po prostu zgłasza zewnętrznie widoczne symptomy, a rodzajem, który zahacza bezpośrednio o mentalną reprezentację programu opartą na kodzie źródłowym.

Większość błędów, przez większość czasu, jest łatwa do złapania, biorąc pod uwagę nawet niekompletną, ale sugestywną charakterystykę ich warunków błędu na poziomie kodu źródłowego. Kiedy ktoś z twoich beta-testerów może wskazać, "jest problem z granicą w linii nnn", lub nawet po prostu "w warunkach X, Y i Z, ta zmienna się przewraca", szybkie spojrzenie na obraźliwy kod często wystarcza, aby określić dokładny sposób awarii i wygenerować poprawkę.

Tak więc, znajomość kodu źródłowego przez obie strony znacznie poprawia zarówno dobrą komunikację, jak i synergię pomiędzy tym, co zgłasza beta-tester, a tym, co wie główny deweloper (deweloperzy). To z kolei oznacza, że czas głównego dewelopera jest dobrze chroniony, nawet przy wielu współpracownikach.

Inną cechą metody open-source, która oszczędza czas programistów, jest struktura komunikacji w typowych projektach open-source. Powyżej użyłem terminu "core developer"; odzwierciedla to rozróżnienie pomiędzy rdzeniem projektu (zazwyczaj dość małym; pojedynczy core developer jest powszechny, a jeden do trzech jest typowy) a aureolą projektu złożoną z beta-testerów i dostępnych współpracowników (która często liczy się w setkach).

Podstawowym problemem, który rozwiązuje tradycyjna organizacja rozwoju oprogramowania, jest prawo Brooka: "Dodawanie kolejnych programistów do opóźnionego projektu sprawia, że staje się on późniejszy". Mówiąc bardziej ogólnie, Prawo Brooksa przewiduje, że złożoność i koszty komunikacji w projekcie rosną wraz z kwadratem liczby programistów, podczas gdy wykonana praca rośnie liniowo.

Prawo Brooksa opiera się na doświadczeniu, że błędy mają tendencję do skupiania się na interfejsach pomiędzy kodem napisanym przez różnych ludzi, a koszty komunikacji/koordynacji w projekcie mają tendencję do zwiększania się wraz z liczbą interfejsów pomiędzy ludźmi. Tak więc, problemy skalują się wraz z liczbą ścieżek komunikacyjnych pomiędzy programistami, która skaluje się jako kwadrat liczby programistów (dokładniej, zgodnie ze wzorem N*(N - 1)/2, gdzie N jest liczbą programistów).

Analiza Prawa Brooksa (i wynikający z niej strach przed dużymi liczbami w grupach programistycznych) opiera się na ukrytym założeniu: że struktura komunikacji w projekcie jest koniecznie grafem skończonym, że każdy rozmawia z każdym innym. Ale w projektach open-source, programiści halo pracują nad tym, co w efekcie jest oddzielnymi, równoległymi podzadaniami i wchodzą ze sobą w bardzo niewielką interakcję; zmiany kodu i raporty o błędach przepływają przez grupę podstawową i tylko w obrębie tej małej grupy podstawowej płacimy pełny koszt Brooksa. [SU]

Istnieje jeszcze więcej powodów, dla których raportowanie błędów na poziomie kodu źródłowego ma tendencję do bycia bardzo wydajnym. Koncentrują się one wokół faktu, że pojedynczy błąd może często mieć wiele możliwych objawów, manifestujących się w różny sposób w zależności od szczegółów wzorca użytkowania i środowiska użytkownika. Takie błędy są zazwyczaj dokładnie tym rodzajem złożonych i subtelnych błędów (takich jak błędy dynamicznego zarządzania pamięcią lub nondeterministyczne artefakty okna przerwań), które są najtrudniejsze do odtworzenia na własną rękę lub do określenia za pomocą analizy statycznej, a które robią najwięcej, by stworzyć długoterminowe problemy w oprogramowaniu.

Tester, który prześle wstępną charakterystykę na poziomie kodu źródłowego takiego błędu z wieloma objawami (np. "Wygląda mi na to, że jest okno w obsłudze sygnału w pobliżu linii 1250" lub "Gdzie wyzerowałeś ten bufor?") może dać programiście, który w innym przypadku jest zbyt blisko kodu, by to dostrzec, krytyczną wskazówkę dotyczącą pół tuzina różnych objawów. W przypadkach takich jak ten, może być trudne lub nawet niemożliwe, aby wiedzieć, które zewnętrznie widoczne niewłaściwe zachowanie zostało spowodowane dokładnie przez który błąd - ale przy częstych wydaniach, nie ma potrzeby, aby to wiedzieć. Inni współpracownicy prawdopodobnie szybko dowiedzą się, czy ich błąd został naprawiony, czy nie. W wielu przypadkach, raporty błędów na poziomie źródła spowodują, że błędne zachowanie zostanie usunięte bez przypisania go do jakiejkolwiek konkretnej poprawki.

Złożone błędy wieloobjawowe mają również tendencję do posiadania wielu ścieżek śladu od objawów powierzchniowych z powrotem do rzeczywistego błędu. To, którą z tych ścieżek może śledzić dany programista lub tester, może zależeć od subtelności środowiska tej osoby i może się zmieniać w nieoczywisty, deterministyczny sposób w czasie. W efekcie każdy programista i tester, szukając etiologii symptomu, pobiera próbki z półlosowego zbioru przestrzeni stanów programu. Im bardziej subtelny i złożony błąd, tym mniej prawdopodobne jest, że umiejętności będą w stanie zagwarantować trafność tej próbki.

W przypadku prostych i łatwych do odtworzenia błędów akcent będzie położony raczej na "pół" niż na "losowość"; umiejętności debugowania i zażyłość z kodem i jego architekturą będą miały duże znaczenie. Ale w przypadku złożonych błędów, akcent będzie położony na "losowość". W tych okolicznościach wiele osób prowadzących ślady będzie znacznie bardziej efektywnych niż kilka osób prowadzących ślady sekwencyjnie - nawet jeśli te kilka osób ma znacznie wyższy średni poziom umiejętności.

Efekt ten będzie znacznie wzmocniony, jeśli trudność śledzenia ścieżek od różnych objawów powierzchniowych do błędu różni się znacząco w sposób, który nie może być przewidziany przez spojrzenie na objawy. Pojedynczy programista próbkujący te ścieżki sekwencyjnie, będzie równie prawdopodobne, że wybierze trudną ścieżkę za pierwszym podejściem, jak i łatwą. Z drugiej strony, załóżmy, że wiele osób próbuje ścieżek równolegle podczas wykonywania szybkich wydań. Wtedy jest prawdopodobne, że jedna z nich natychmiast znajdzie najłatwiejszą ścieżkę i znajdzie błąd w znacznie krótszym czasie. Opiekun projektu zauważy to, wyśle nowe wydanie, a inni ludzie próbujący prześledzić ten sam błąd będą mogli się zatrzymać, zanim spędzą zbyt wiele czasu na swoich trudniejszych ścieżkach [RJ].

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

Po przestudiowaniu zachowania Linusa i stworzeniu teorii, dlaczego odniósł sukces, podjąłem świadomą decyzję o przetestowaniu tej teorii na moim nowym (co prawda znacznie mniej złożonym i ambitnym) projekcie.

Ale pierwszą rzeczą, jaką zrobiłem, była reorganizacja i znaczne uproszczenie popclienta. Implementacja Carla Harrisa była bardzo solidna, ale wykazywała pewien rodzaj niepotrzebnej złożoności wspólnej dla wielu programistów C. Traktował on kod jako centralny, a struktury danych jako wsparcie dla kodu. W rezultacie kod był piękny, ale projekt struktury danych ad-hoc i raczej brzydki (przynajmniej według wysokich standardów tego weterana LISP hackera).

Miałem jednak inny cel do przepisania oprócz poprawy kodu i projektu struktury danych. To było ewoluowanie go w coś, co całkowicie rozumiałem. Nie jest fajnie być odpowiedzialnym za naprawianie błędów w programie, którego nie rozumiesz.

Przez pierwszy miesiąc lub coś koło tego, po prostu śledziłem implikacje podstawowego projektu Carla. Pierwszą poważną zmianą, jakiej dokonałem, było dodanie obsługi IMAP. Dokonałem tego poprzez reorganizację maszyn protokołów w ogólny sterownik i trzy tablice metod (dla POP2, POP3 i IMAP). Ta i poprzednie zmiany ilustrują ogólną zasadę, o której dobrze jest pamiętać, zwłaszcza w językach takich jak C, które naturalnie nie mają dynamicznego typowania:

9. Inteligentne struktury danych i głupi kod działają o wiele lepiej niż na odwrót.

Brooks, rozdział 9: ``Pokaż mi swój schemat blokowy i ukryj swoje tabele, a ja nadal będę zakłopotany. Pokaż mi swoje tabele, a ja zazwyczaj nie będę potrzebował twojego schematu blokowego; to będzie oczywiste. Po uwzględnieniu trzydziestu lat zmian terminologicznych/kulturowych, jest to ten sam punkt.

W tym momencie (początek września 1996, około sześć tygodni od zera) zacząłem myśleć, że zmiana nazwy może być w porządku - w końcu to już nie był tylko klient POP. Wahałem się jednak, ponieważ w projekcie nie było jeszcze nic prawdziwie nowego. Moja wersja popclienta nie miała jeszcze własnej tożsamości.

Zmieniło się to radykalnie, gdy popclient nauczył się przekazywać pobraną pocztę na port SMTP. Przejdę do tego za chwilę. Ale najpierw: powiedziałem wcześniej, że postanowiłem użyć tego projektu do sprawdzenia mojej teorii na temat tego, co Linus Torvalds zrobił dobrze. Jak (możecie zapytać) tego dokonałem? W następujący sposób:

Wydawałem wcześnie i często (prawie nigdy nie rzadziej niż co dziesięć dni; w okresach intensywnego rozwoju, raz dziennie).

Rozwijałem listę beta dodając do niej każdego, kto skontaktował się ze mną w sprawie fetchmaila.

Wysyłałem czatowe ogłoszenia na listę betatesterów za każdym razem, gdy publikowałem, zachęcając ludzi do udziału.

I słuchałem moich beta-testerów, pytając ich o decyzje projektowe i głaszcząc ich za każdym razem, gdy przysyłali poprawki i opinie.

Zysk z tych prostych działań był natychmiastowy. Od początku projektu otrzymywałem zgłoszenia błędów o jakości, za którą większość programistów zabiłaby z zachwytu, często z dołączonymi dobrymi poprawkami. Dostawałem przemyślaną krytykę, dostawałem listy od fanów, dostawałem inteligentne sugestie dotyczące funkcji. Co prowadzi do:

10. Jeśli traktujesz swoich beta-testerów tak, jakby byli Twoim najcenniejszym zasobem, odpowiedzą Ci tym samym, stając się Twoim najcenniejszym zasobem.

Interesującą miarą sukcesu programu fetchmail jest sama wielkość listy beta-testerów projektu, fetchmail-friends. W czasie ostatniej rewizji tego dokumentu (listopad 2000 r.) lista ta ma 287 członków i dodaje się do niej dwóch lub trzech tygodniowo.

Właściwie, kiedy dokonywałem przeglądu pod koniec maja 1997 roku, stwierdziłem, że lista zaczyna tracić członków z wysokiego poziomu bliskiego 300 z ciekawego powodu. Kilka osób poprosiło mnie o wypisanie ich z listy, ponieważ fetchmail działa dla nich tak dobrze, że nie potrzebują już widzieć ruchu na liście! Być może jest to część normalnego cyklu życia dojrzałego projektu w stylu bazaru.

Popclient staje się Fetchmailem

Prawdziwym punktem zwrotnym w projekcie było przesłanie mi przez Harry'ego Hochheisera jego kodu do przekierowywania poczty na port SMTP maszyny klienckiej. Niemal natychmiast zdałem sobie sprawę, że niezawodna implementacja tej funkcji sprawi, że wszystkie inne sposoby dostarczania poczty staną się niemal przestarzałe.

Przez wiele tygodni poprawiałem fetchmail raczej przyrostowo, mając wrażenie, że interfejs jest dobry, ale nieelegancki i zawiera zbyt wiele zbędnych opcji. Szczególnie przeszkadzały mi opcje zrzucania pobranej poczty do pliku skrzynki pocztowej lub na standardowe wyjście, ale nie mogłem zrozumieć dlaczego.

(Jeśli nie interesują cię techniczne aspekty poczty internetowej, możesz spokojnie pominąć dwa następne akapity).

Kiedy pomyślałem o przekierowaniu SMTP, zauważyłem, że popclient próbował robić zbyt wiele rzeczy. Został zaprojektowany zarówno jako agent transportu poczty (MTA), jak i lokalny agent dostarczania (MDA). Dzięki przekazywaniu SMTP mógł się wycofać z roli MDA i stać się czystym MTA, przekazując pocztę innym programom do lokalnego doręczenia, tak jak robi to sendmail.

Po co zawracać sobie głowę całą złożonością konfiguracji agenta dostarczającego pocztę lub ustawianiem lock-and-append na skrzynce pocztowej, skoro port 25 jest niemal gwarantowany na każdej platformie z obsługą TCP/IP? Zwłaszcza, że oznacza to, że pobierana poczta będzie wyglądała jak normalna poczta SMTP inicjowana przez nadawcę, czyli tak naprawdę to, o co nam chodzi.

(Powrót do wyższego poziomu....)

Nawet jeśli nie śledziłeś poprzedniego technicznego żargonu, jest tu kilka ważnych lekcji. Po pierwsze, koncepcja przekierowania SMTP była największą pojedynczą korzyścią, jaką odniosłem ze świadomych prób naśladowania metod Linusa. Użytkownik podsunął mi ten wspaniały pomysł - wszystko co musiałem zrobić, to zrozumieć jego implikacje.

11. Następną najlepszą rzeczą do posiadania dobrych pomysłów jest dostrzeganie dobrych pomysłów od swoich użytkowników. Czasami to drugie jest lepsze.

Co ciekawe, szybko przekonasz się, że jeśli będziesz całkowicie i z autoironią mówił prawdę o tym, jak wiele zawdzięczasz innym ludziom, świat będzie traktował Cię tak, jakbyś sam dokonał każdej części wynalazku i był po prostu skromny, jeśli chodzi o Twój wrodzony geniusz. Wszyscy widzimy jak dobrze zadziałało to w przypadku Linusa!

(Kiedy wygłosiłem swoją mowę na pierwszej konferencji Perla w sierpniu 1997, hacker Larry Wall siedział w pierwszym rzędzie. Gdy doszedłem do ostatniej linijki, zawołał w stylu religijnego odrodzenia, ``Powiedz to, powiedz to, bracie! Cała publiczność śmiała się, ponieważ wiedzieli, że to zadziałało również na wynalazcę Perla).

Po kilku tygodniach prowadzenia projektu w tym samym duchu, zacząłem otrzymywać podobne pochwały nie tylko od moich użytkowników, ale także od innych ludzi, do których słowo wyciekło. Schowałem trochę tych maili; zajrzę do nich kiedyś ponownie, jeśli zacznę się zastanawiać, czy moje życie było warte zachodu :-).

Ale są tu jeszcze dwie fundamentalne, niepolityczne lekcje, które są ogólne dla wszystkich rodzajów projektowania.

12. Często najbardziej uderzające i innowacyjne rozwiązania powstają w wyniku uświadomienia sobie, że twoja koncepcja problemu była błędna.

Próbowałem rozwiązać niewłaściwy problem, kontynuując rozwój popclienta jako połączonego MTA/MDA z różnego rodzaju dziwnymi lokalnymi trybami dostarczania. Projekt Fetchmaila musiał być przemyślany od podstaw jako czysty MTA, część normalnej ścieżki poczty internetowej mówiącej SMTP.

Kiedy natrafisz na ścianę w rozwoju - kiedy trudno Ci myśleć o czymś więcej niż tylko o kolejnej poprawce - często jest to czas, aby zapytać nie o to, czy masz właściwą odpowiedź, ale czy zadajesz właściwe pytanie. Być może problem wymaga przeformułowania.

Cóż, przeformułowałem swój problem. Najwyraźniej, właściwą rzeczą do zrobienia było (1) włamanie obsługi przekierowania SMTP do sterownika generycznego, (2) uczynienie go trybem domyślnym i (3) ostateczne wyrzucenie wszystkich innych trybów dostarczania, szczególnie opcji deliver-to-file i deliver-to-standard-output.

Wahałem się nad krokiem 3 przez jakiś czas, obawiając się, że zdenerwuję długoletnich użytkowników popclienta zależnych od alternatywnych mechanizmów dostarczania. W teorii, mogliby oni natychmiast przełączyć się na pliki .forward lub ich odpowiedniki bez wysyłania poczty, aby uzyskać te same efekty. W praktyce takie przejście mogłoby być niechlujne.

Ale kiedy już to zrobiłem, korzyści okazały się ogromne. Zniknęły najcięższe części kodu sterownika. Konfiguracja stała się radykalnie prostsza - nie trzeba było już błagać o systemowe MDA i skrzynkę użytkownika, ani martwić się o to, czy bazowy system operacyjny obsługuje blokowanie plików.

Zniknął też jedyny sposób na utratę poczty. Jeśli określiłeś dostawę do pliku i dysk się zapełnił, twoja poczta przepadała. Nie może się to zdarzyć z przekazywaniem SMTP, ponieważ Twój listener SMTP nie zwróci OK, jeśli wiadomość nie może być dostarczona lub przynajmniej spakowana do późniejszego dostarczenia.

Poprawiła się także wydajność (choć nie na tyle byś to zauważył podczas jednego uruchomienia). Kolejną niebagatelną korzyścią z tej zmiany było to, że strona manuala stała się o wiele prostsza.

Później musiałem przywrócić dostarczanie przez lokalne MDA, aby umożliwić obsługę pewnych niejasnych sytuacji związanych z dynamicznym SLIP. Znalazłem jednak znacznie prostszy sposób na zrobienie tego.

Morał? Nie wahaj się wyrzucić zbędnych funkcji, jeśli możesz to zrobić bez utraty efektywności. Antoine de Saint-Exupéry (który był lotnikiem i projektantem samolotów, kiedy nie pisał klasycznych książek dla dzieci) powiedział:

13. Doskonałość (w projektowaniu) osiąga się nie wtedy, gdy nie ma już nic do dodania, ale raczej wtedy, gdy nie ma już nic do zabrania.

Kiedy twój kod staje się zarówno lepszy, jak i prostszy, to właśnie wtedy wiesz, że jest właściwy. A w trakcie tego procesu projekt fetchmaila zyskał własną tożsamość, inną od rodowego popclienta.

Nadszedł czas na zmianę nazwy. Nowy projekt wyglądał dużo bardziej jak dual sendmaila niż stary popclient; oba są MTA, ale tam, gdzie sendmail pcha i dostarcza, nowy popclient ciągnie i dostarcza. Tak więc po dwóch miesiącach od uruchomienia zmieniłem nazwę na fetchmail.

Z tej historii wynika bardziej ogólna lekcja na temat tego, jak dostarczanie SMTP trafiło do fetchmaila. Nie tylko debugowanie jest równoległe; rozwój i (być może w zaskakującym stopniu) eksploracja przestrzeni projektowej również. Jeśli Twój tryb rozwoju jest szybko iteracyjny, rozwój i ulepszanie mogą stać się specjalnymi przypadkami debugowania - poprawiania "błędów przeoczenia" w oryginalnych możliwościach lub koncepcji oprogramowania.

Nawet na wyższym poziomie projektowania bardzo cenne może być posiadanie wielu współtwórców losowo spacerujących po przestrzeni projektowej w pobliżu Twojego produktu. Rozważmy sposób, w jaki kałuża wody znajduje odpływ, lub lepiej, jak mrówki znajdują pożywienie: eksploracja zasadniczo przez dyfuzję, a następnie eksploatacja, w której pośredniczy skalowalny mechanizm komunikacji. Działa to bardzo dobrze; tak jak w przypadku Harry'ego Hochheisera i mnie, jeden z Twoich konkurentów może znaleźć w pobliżu ogromną wygraną, którą Ty byłeś po prostu zbyt blisko skupiony, aby ją dostrzec.

Fetchmail rośnie w siłę

Miałem zgrabny i innowacyjny projekt, kod, o którym wiedziałem, że działa dobrze, ponieważ używałem go na co dzień, oraz rosnącą listę użytkowników wersji beta. Stopniowo docierało do mnie, że nie zajmuję się już banalnym, osobistym hackowaniem, które może przydać się kilku innym osobom. Miałem moje ręce na program, który każdy haker z Unix box i SLIP/PPP połączenia pocztowego naprawdę potrzebuje.

Z funkcją przekierowania SMTP, wysunął się on wystarczająco daleko przed konkurencję, aby potencjalnie stać się ``zabójcą kategorii'', jednym z tych klasycznych programów, które wypełniają swoją niszę tak kompetentnie, że alternatywy są nie tylko odrzucane, ale prawie zapomniane.

Myślę, że nie można tak naprawdę celować lub planować takiego wyniku. Trzeba zostać wciągniętym przez idee projektowe tak potężne, że potem rezultaty wydają się nieuniknione, naturalne, wręcz przesądzone. Jedynym sposobem, aby spróbować takich pomysłów, jest posiadanie wielu pomysłów - lub posiadanie inżynierskiego osądu, aby przenieść dobre pomysły innych ludzi poza to, co ich autorzy myśleli, że mogą osiągnąć.

Andy Tanenbaum miał oryginalny pomysł zbudowania prostego, natywnego Uniksa dla komputerów IBM PC, do wykorzystania jako narzędzie dydaktyczne (nazwał go Minix). Linus Torvalds popchnął koncepcję Minixa dalej, niż Andrew prawdopodobnie myślał, że może się udać - i wyrosła ona na coś wspaniałego. W ten sam sposób (choć na mniejszą skalę), wziąłem pewne pomysły Carla Harrisa i Harry'ego Hochheisera i mocno je popchnąłem. Żaden z nas nie był "oryginalny" w romantyczny sposób, jaki ludzie uważają za geniusz. Ale wtedy, większość nauki, inżynierii i rozwoju oprogramowania nie jest robiona przez oryginalnych geniuszy, mitologia hakerska jest przeciwna.

Rezultaty były całkiem niezłe - w rzeczywistości, po prostu rodzaj sukcesu, dla którego każdy haker żyje! I oznaczały, że będę musiał jeszcze bardziej podnieść swoje standardy. Aby uczynić fetchmail tak dobrym, jak to było możliwe, musiałem pisać nie tylko dla własnych potrzeb, ale również włączać i wspierać funkcje niezbędne dla innych, ale znajdujące się poza moją orbitą. I zrobić to, zachowując prostotę i solidność programu.

Pierwszą i zdecydowanie najważniejszą funkcją, którą napisałem po uświadomieniu sobie tego faktu, była obsługa multidropów - możliwość pobierania poczty ze skrzynek, które gromadziły całą pocztę dla grupy użytkowników, a następnie kierowania każdej z nich do poszczególnych odbiorców.

Zdecydowałem się dodać obsługę multidrop częściowo dlatego, że niektórzy użytkownicy domagali się jej, ale głównie dlatego, że myślałem, iż usunie ona błędy z kodu single-drop, zmuszając mnie do zajęcia się adresowaniem w pełnej ogólności. I tak się stało. Doprowadzenie do poprawnego działania parsowania adresów w RFC 822 zajęło mi wyjątkowo dużo czasu, nie dlatego, że jakikolwiek pojedynczy element jest trudny, ale dlatego, że wymagało to mnóstwa współzależnych i skomplikowanych szczegółów.

Ale adresowanie wielopunktowe okazało się również doskonałą decyzją projektową. Oto skąd wiedziałem:

14. Każde narzędzie powinno być użyteczne w oczekiwany sposób, ale naprawdę świetne narzędzie nadaje się do zastosowań, których nigdy się nie spodziewałeś.

Nieoczekiwanym zastosowaniem multidropowego fetchmaila jest uruchamianie list mailingowych z zachowaniem listy i rozszerzaniem aliasów po stronie klienta połączenia internetowego. Oznacza to, że ktoś korzystający z osobistej maszyny poprzez konto ISP może zarządzać listą mailingową bez ciągłego dostępu do plików aliasów ISP.

Inną ważną zmianą, której domagali się moi beta-testerzy, była obsługa 8-bitowych rozszerzeń MIME (Multipurpose Internet Mail Extensions). Było to dość łatwe do zrobienia, ponieważ uważałem, żeby kod był 8-bitowy (to znaczy, żeby nie wciskać ósmego bitu, nieużywanego w zestawie znaków ASCII, do przenoszenia informacji w programie). Nie dlatego, że przewidywałem zapotrzebowanie na tę cechę, ale raczej w posłuszeństwie innej zasadzie:

15. Pisząc oprogramowanie bramowe jakiegokolwiek rodzaju, staraj się jak najmniej zakłócać strumień danych - i nigdy nie wyrzucaj informacji, chyba że zmusi cię do tego odbiorca!

Gdybym nie przestrzegał tej zasady, obsługa 8-bitowego MIME byłaby trudna i zabugowana. W rzeczywistości wystarczyło tylko przeczytać standard MIME (RFC 1652) i dodać trywialną logikę generowania nagłówków.

Niektórzy europejscy użytkownicy namawiali mnie do dodania opcji ograniczenia liczby wiadomości pobieranych w czasie sesji (aby mogli kontrolować koszty związane z ich drogimi sieciami telefonicznymi). Długo się temu opierałem i nadal nie jestem z tego powodu w pełni zadowolony. Ale jeśli piszesz dla świata, musisz słuchać swoich klientów - to się nie zmieni tylko dlatego, że nie płacą ci w pieniądzach.

Kilka dodatkowych lekcji z programu Fetchmail

Zanim wrócimy do ogólnych zagadnień związanych z inżynierią oprogramowania, warto zastanowić się nad kilkoma konkretnymi lekcjami płynącymi z doświadczenia z programem Fetchmail. Czytelnicy nietechniczni mogą bezpiecznie pominąć tę sekcję.

Składnia pliku rc (control) zawiera opcjonalne słowa kluczowe `noise', które są całkowicie ignorowane przez parser. Składnia przypominająca angielską, na którą one pozwalają, jest znacznie bardziej czytelna niż tradycyjne, krótkie pary słowo kluczowe-wartość, które otrzymujemy po usunięciu ich wszystkich.

Zaczęło się to jako eksperyment późno w nocy, kiedy zauważyłem, jak bardzo deklaracje w pliku rc zaczynają przypominać imperatywny minilanguage. (To jest również powód dla którego zmieniłem oryginalne słowo kluczowe popclient ''server'' na ``poll'').

Wydawało mi się, że próba upodobnienia tego imperatywnego minjęzyka do angielskiego może sprawić, że będzie on łatwiejszy w użyciu. Teraz, chociaż jestem przekonanym zwolennikiem szkoły projektowania ''make it a language'', czego przykładem jest Emacs i HTML oraz wiele silników baz danych, nie jestem wielkim fanem składni ``English-like''.

Tradycyjnie programiści mają tendencję do faworyzowania składni kontrolnych, które są bardzo precyzyjne i zwarte i nie mają żadnej redundancji. Jest to spuścizna kulturowa z czasów, gdy zasoby obliczeniowe były drogie, więc etapy parsowania musiały być tak tanie i proste jak to tylko możliwe. Angielski, z około 50% redundancją, wyglądał wtedy na bardzo nieodpowiedni model.

Nie jest to mój powód, dla którego zwykle unikam składni podobnych do angielskiej; wspominam o tym tutaj tylko po to, aby to zburzyć. Z tanimi cyklami i rdzeniem, krotność nie powinna być celem samym w sobie. W dzisiejszych czasach ważniejsze jest, by język był wygodny dla człowieka, niż by był tani dla komputera.

Istnieją jednak powody, dla których warto być ostrożnym. Jednym z nich jest koszt złożoności etapu parsowania - nie chcesz podnieść go do punktu, w którym sam w sobie jest znaczącym źródłem błędów i dezorientacji użytkownika. Innym jest to, że próba uczynienia języka o składni podobnej do angielskiej często wymaga, by ''angielski'', którym się posługuje, był poważnie wygięty, tak bardzo, że powierzchowne podobieństwo do języka naturalnego jest tak mylące, jak byłaby tradycyjna składnia. (Widać ten zły efekt w wielu tak zwanych ``czwartej generacji'' i komercyjnych językach zapytań do baz danych).

Składnia kontrolna fetchmaila wydaje się unikać tych problemów, ponieważ domena języka jest bardzo ograniczona. Nigdzie nie jest to język ogólnego przeznaczenia; rzeczy, które mówi po prostu nie są bardzo skomplikowane, więc istnieje niewielki potencjał dezorientacji w poruszaniu się mentalnie pomiędzy małym podzbiorem języka angielskiego a rzeczywistym językiem kontroli. Myślę, że może tu być szersza lekcja:

16. Kiedy twój język nie jest nigdzie w pobliżu Turing-complete, cukier syntaktyczny może być twoim przyjacielem.

Kolejna lekcja dotyczy bezpieczeństwa przez ukrycie. Niektórzy użytkownicy fetchmaila poprosili mnie o zmianę oprogramowania tak, aby przechowywało hasła zaszyfrowane w pliku rc, dzięki czemu szperacze nie mogliby ich przypadkowo zobaczyć.

Nie zrobiłem tego, ponieważ w rzeczywistości nie dodaje to ochrony. Każdy, kto uzyskał uprawnienia do czytania twojego pliku rc, będzie mógł uruchomić fetchmail jako ty i tak - a jeśli to twoje hasło będzie mu potrzebne, będzie mógł wyrwać niezbędny dekoder z samego kodu fetchmaila, aby je zdobyć.

Wszystko, co zrobiłoby szyfrowanie hasła .fetchmailrc, to danie fałszywego poczucia bezpieczeństwa ludziom, którzy nie myślą zbyt intensywnie. Ogólną zasadą jest tutaj:

17. System bezpieczeństwa jest tylko tak bezpieczny, jak jego sekret. Uważaj na pseudo-tajemnice.

Niezbędne warunki wstępne dla stylu bazarowego

Wcześni recenzenci i testowi odbiorcy tego eseju konsekwentnie zadawali pytania dotyczące warunków wstępnych udanego rozwoju w stylu bazarowym, w tym zarówno kwalifikacji lidera projektu, jak i stanu kodu w momencie upublicznienia i rozpoczęcia próby zbudowania społeczności współtwórców.

Jest dość jasne, że nie da się kodować od podstaw w stylu bazarowym [IN]. Można testować, debugować i ulepszać w stylu bazarowym, ale bardzo trudno byłoby rozpocząć projekt w trybie bazarowym. Linus tego nie próbował. Ja też nie. Twoja rodząca się społeczność programistów musi mieć coś, co da się uruchomić i przetestować, aby się tym bawić.

Kiedy zaczynasz budować społeczność, musisz być w stanie przedstawić wiarygodną obietnicę. Twój program nie musi działać szczególnie dobrze. Może być prymitywny, zabugowany, niekompletny i słabo udokumentowany. To, czego nie może nie robić, to (a) działać i (b) przekonać potencjalnych współtwórców, że w przewidywalnej przyszłości może zostać rozwinięty w coś naprawdę fajnego.

Zarówno Linux, jak i fetchmail zostały upublicznione z silnymi, atrakcyjnymi podstawowymi projektami. Wiele osób myślących o modelu bazarowym w sposób, w jaki go przedstawiłem, prawidłowo uznało to za kluczowe, a następnie wyciągnęło z tego wniosek, że wysoki stopień intuicji projektowej i sprytu u lidera projektu jest niezbędny.

Ale Linus wziął swój projekt z Uniksa. Ja swój początkowo zaczerpnąłem od przodka Popclienta (choć później bardzo się on zmienił, proporcjonalnie rzecz biorąc znacznie bardziej niż Linux). Czy więc lider/koordynator działań w stylu bazarowym naprawdę musi mieć wyjątkowy talent projektowy, czy też może sobie poradzić dzięki wykorzystaniu talentu projektowego innych?

Myślę, że nie jest konieczne, aby koordynator był w stanie tworzyć projekty o wyjątkowej błyskotliwości, ale jest absolutnie konieczne, aby był w stanie rozpoznać dobre pomysły projektowe innych.

Zarówno projekt Linux, jak i fetchmail są tego dowodem. Linus, choć nie jest (jak już wcześniej wspomniano) spektakularnie oryginalnym projektantem, wykazał się potężnym talentem do rozpoznawania dobrego projektu i integrowania go z jądrem Linuksa. Opisałem już, w jaki sposób pojedynczy najpotężniejszy pomysł na projekt w programie fetchmail (przekierowanie SMTP) pochodzi od kogoś innego.

Pierwsi odbiorcy tego eseju pochwalili mnie, sugerując, że mam skłonność do niedoceniania oryginalności projektów bazarowych, ponieważ sam mam jej dużo i dlatego uważam ją za coś oczywistego. Być może jest w tym trochę prawdy; projektowanie (w przeciwieństwie do kodowania czy debugowania) jest z pewnością moją najmocniejszą stroną.

Ale problem z byciem sprytnym i oryginalnym w projektowaniu oprogramowania polega na tym, że staje się to nawykiem - zaczynasz odruchowo robić rzeczy ładne i skomplikowane, kiedy powinieneś trzymać je solidne i proste. Zdarzało mi się, że projekty rozpadały się, ponieważ popełniałem ten błąd, ale udało mi się tego uniknąć w przypadku fetchmaila.

Wierzę więc, że projekt fetchmail odniósł sukces częściowo dlatego, że powstrzymałem swoją tendencję do bycia sprytnym; to przemawia (przynajmniej) przeciwko oryginalności projektu, która jest niezbędna dla udanych projektów bazarowych. Rozważmy też Linuksa. Przypuśćmy, że Linus Torvalds próbował wprowadzić fundamentalne innowacje w projektowaniu systemu operacyjnego podczas jego rozwoju; czy wydaje się w ogóle prawdopodobne, że powstałe w ten sposób jądro byłoby tak stabilne i udane jak to, które mamy?

Oczywiście wymagany jest pewien podstawowy poziom umiejętności projektowania i kodowania, ale spodziewam się, że prawie każdy, kto poważnie myśli o rozpoczęciu wysiłku na bazarze, będzie już powyżej tego minimum. Wewnętrzny rynek reputacji w społeczności open-source wywiera subtelną presję na ludzi, by nie podejmowali wysiłków rozwojowych, do których nie mają kompetencji. Jak dotąd wydaje się, że działa to całkiem dobrze.

Jest jeszcze jeden rodzaj umiejętności, które nie są zwykle kojarzone z tworzeniem oprogramowania, a które moim zdaniem są równie ważne jak spryt projektowy w projektach bazarowych - a może nawet ważniejsze. Koordynator lub lider projektu bazarowego musi mieć dobre umiejętności komunikacyjne.

To powinno być oczywiste. Aby zbudować społeczność programistów, musisz przyciągnąć ludzi, zainteresować ich tym, co robisz i sprawić, by byli zadowoleni z ilości pracy, którą wykonują. Techniczny skwierczenie przejdzie długą drogę, aby to osiągnąć, ale to daleko nie jest cała historia. Osobowość, którą prezentujesz, również ma znaczenie.

Nie jest przypadkiem, że Linus jest miłym facetem, który sprawia, że ludzie go lubią i chcą mu pomagać. Nie jest przypadkiem, że jestem energicznym ekstrawertykiem, który lubi pracować z tłumem i ma pewne predyspozycje i instynkt komika stand-upowego. Aby model bazaru zadziałał, bardzo pomocne jest posiadanie choć odrobiny umiejętności czarowania ludzi.

Społeczny kontekst oprogramowania open source

To jest naprawdę napisane: najlepsze hacki zaczynają się jako osobiste rozwiązania codziennych problemów autora i rozprzestrzeniają się, ponieważ problem okazuje się być typowy dla dużej klasy użytkowników. To prowadzi nas z powrotem do kwestii zasady 1, powtórzonej w być może bardziej użyteczny sposób:

18. Aby rozwiązać interesujący problem, zacznij od znalezienia problemu, który jest dla Ciebie interesujący.

Tak było z Carlem Harrisem i jego rodowodowym popclientem, tak było ze mną i fetchmailem. Ale to już było rozumiane od dawna. Interesującym punktem, na którym historie Linuksa i fetchmaila zdają się wymagać, abyśmy się skupili, jest następny etap - ewolucja oprogramowania w obecności dużej i aktywnej społeczności użytkowników i współtwórców.

W książce The Mythical Man-Month Fred Brooks zauważył, że czas programisty nie jest zamienny; dodanie programistów do spóźnionego projektu programistycznego sprawia, że staje się on późniejszy. Jak widzieliśmy wcześniej, argumentował on, że złożoność i koszty komunikacji w projekcie rosną wraz z kwadratem liczby programistów, podczas gdy wykonana praca wzrasta tylko liniowo. Prawo Brooksa jest powszechnie uważane za truizm. Ale w tym eseju przeanalizowaliśmy wiele sposobów, w jaki proces rozwoju oprogramowania open source fałszuje stojące za nim założenia - i, empirycznie, gdyby Prawo Brooksa było całym obrazem, Linux byłby niemożliwy.

Klasyczna The Psychology of Computer Programming Geralda Weinberga dostarczyła tego, co z perspektywy czasu możemy uznać za istotną poprawkę do Brooksa. W swojej dyskusji na temat ''bez-egoless programming'', Weinberg zauważył, że w sklepach, gdzie programiści nie są terytorialni w stosunku do swojego kodu i zachęcają innych ludzi do szukania w nim błędów i potencjalnych ulepszeń, ulepszenia następują dramatycznie szybciej niż gdzie indziej. (Ostatnio, technika "programowania ekstremalnego" Kenta Becka, polegająca na rozmieszczeniu programistów w parach, którzy patrzą sobie nawzajem przez ramię, może być postrzegana jako próba wymuszenia tego efektu).

Wybór terminologii przez Weinberga być może sprawił, że jego analiza nie zyskała akceptacji, na jaką zasługiwała - trzeba się uśmiechnąć na myśl o opisywaniu hakerów internetowych jako "bezegoistycznych". Myślę jednak, że jego argumentacja jest dziś bardziej przekonująca niż kiedykolwiek.

Metoda bazaru, wykorzystując pełną moc efektu ``bezegoless programming'', silnie łagodzi efekt Prawa Brooksa. Zasada stojąca za Prawem Brooksa nie jest uchylona, ale biorąc pod uwagę dużą populację deweloperów i tanią komunikację, jego efekty mogą być tłumione przez konkurencyjne nieliniowości, które nie są w inny sposób widoczne. Przypomina to związek między fizyką newtonowską i einsteinowską - starszy system jest nadal ważny przy niskich energiach, ale jeśli przesuniesz masę i prędkość wystarczająco wysoko, otrzymasz niespodzianki, takie jak eksplozje jądrowe lub Linux.

Historia Uniksa powinna była nas przygotować na to, czego uczymy się od Linuksa (i co zweryfikowałem eksperymentalnie na mniejszą skalę, celowo kopiując metody Linusa [EGCS]). To znaczy, podczas gdy kodowanie pozostaje zasadniczo samotnym zajęciem, naprawdę wspaniałe hacki powstają dzięki zaprzęgnięciu uwagi i siły umysłowej całych społeczności. Programista, który używa tylko swojego własnego mózgu w zamkniętym projekcie, pozostanie w tyle za programistą, który wie jak stworzyć otwarty, ewolucyjny kontekst, w którym informacje zwrotne badające przestrzeń projektową, wkład w kod, wykrywanie błędów i inne ulepszenia pochodzą od setek (może tysięcy) ludzi.

Jednak tradycyjny świat Uniksa został powstrzymany przed doprowadzeniem tego podejścia do ostateczności przez kilka czynników. Jednym z nich były ograniczenia prawne związane z różnymi licencjami, tajemnicami handlowymi i interesami handlowymi. Innym (patrząc z perspektywy czasu) było to, że Internet nie był jeszcze wystarczająco dobry.

Przed tanim Internetem istniały pewne geograficznie zwarte społeczności, w których kultura zachęcała do ``bezegoistycznego'' programowania Weinberga, a programista mógł łatwo przyciągnąć wielu wykwalifikowanych kiboli i współtwórców. Bell Labs, laboratoria MIT AI i LCS, UC Berkeley - te miejsca stały się domem dla innowacji, które są legendarne i wciąż silne.

Linux był pierwszym projektem, w którym świadomie i z powodzeniem starano się wykorzystać cały świat jako rezerwuar talentów. Nie sądzę, że to zbieg okoliczności, że okres dojrzewania Linuksa zbiegł się z narodzinami World Wide Web, i że Linux wyszedł z okresu niemowlęctwa w tym samym okresie 1993-1994, w którym nastąpił rozkwit branży dostawców usług internetowych i eksplozja zainteresowania Internetem w głównym nurcie. Linus był pierwszą osobą, która nauczyła się grać według nowych zasad, które umożliwił wszechobecny dostęp do Internetu.

Podczas gdy tani Internet był warunkiem koniecznym do rozwoju modelu Linuksa, uważam, że sam w sobie nie był warunkiem wystarczającym. Innym istotnym czynnikiem było wypracowanie stylu przywództwa i zestawu zwyczajów współpracy, które pozwoliłyby programistom przyciągnąć współtwórców i uzyskać maksymalny efekt dźwigni z tego medium.

Ale czym jest ten styl przywództwa i czym są te zwyczaje? Nie mogą one opierać się na relacjach władzy - a nawet gdyby tak było, przywództwo z użyciem przymusu nie przyniosłoby takich rezultatów, jakie widzimy. Weinberg cytuje autobiografię dziewiętnastowiecznego rosyjskiego anarchisty Piotra Aleksiejewicza Kropotkina "Wspomnienia rewolucjonisty", aby uzyskać dobry efekt w tym temacie:

Wychowawszy się w rodzinie pańszczyźnianej, wszedłem w aktywne życie, jak wszyscy młodzi mężczyźni moich czasów, z wielką wiarą w konieczność dowodzenia, rozkazywania, besztania, karania i tym podobnych. Kiedy jednak, na wczesnym etapie, musiałem zarządzać poważnymi przedsięwzięciami i mieć do czynienia z [wolnymi] ludźmi, a każdy błąd prowadził od razu do poważnych konsekwencji, zacząłem doceniać różnicę między działaniem na zasadzie rozkazu i dyscypliny a działaniem na zasadzie wspólnego zrozumienia. Ta pierwsza sprawdza się znakomicie na paradzie wojskowej, ale jest nic nie warta w prawdziwym życiu, a cel można osiągnąć jedynie poprzez ciężki wysiłek wielu zbiegających się woli.

Ciężki wysiłek wielu zbieżnych woli'' jest dokładnie tym, czego wymaga projekt taki jak Linux - a `zasada dowodzenia'' jest praktycznie niemożliwa do zastosowania wśród ochotników w anarchistycznym raju, który nazywamy Internetem. Aby działać i konkurować efektywnie, hakerzy, którzy chcą prowadzić wspólne projekty muszą nauczyć się jak rekrutować i energetyzować efektywne wspólnoty interesów w sposób niejasno sugerowany przez "zasadę zrozumienia" Kropotkina. Muszą nauczyć się korzystać z Prawa Linusa.[SP]

Wcześniej odniosłem się do ''efektu Delphi'' jako możliwego wyjaśnienia Prawa Linusa. Ale mocniejsze analogie do systemów adaptacyjnych w biologii i ekonomii również nieodparcie nasuwają się same. Świat Linuksa zachowuje się pod wieloma względami jak wolny rynek lub ekologia, zbiór samolubnych agentów starających się zmaksymalizować użyteczność, którzy w tym procesie wytwarzają samonaprawiający się spontaniczny porządek, bardziej rozbudowany i wydajny niż jakakolwiek ilość centralnego planowania mogłaby to osiągnąć. Tutaj, then, jest miejsce szukać ``zasady zrozumienia''.

Funkcja użyteczności'', którą maksymalizują hakerzy Linuksa nie jest klasycznie ekonomiczna, ale jest niematerialną satysfakcją ich własnego ego i reputacją wśród innych hakerów. (Można nazwać ich motywację ``altruistyczną'', ale to ignoruje fakt, że altruizm jest sam w sobie formą zaspokojenia ego altruisty). Kultury wolontariatu, które działają w ten sposób, nie są właściwie rzadkością; jedną z innych, w której od dawna uczestniczę, jest fandom science fiction, który w przeciwieństwie do hackerskiego od dawna wyraźnie uznaje ''egoboo'' (podbijanie ego, czyli poprawianie swojej reputacji wśród innych fanów) za podstawową siłę napędową działalności wolontariackiej.

Linus, poprzez udane pozycjonowanie siebie jako strażnika projektu, w którym rozwój jest w większości dokonywany przez innych, oraz podtrzymywanie zainteresowania projektem aż do momentu, gdy stał się on samowystarczalny, wykazał się doskonałym zrozumieniem Kropotkinowskiej "zasady wspólnego zrozumienia". To quasi-ekonomiczne spojrzenie na świat Linuksa pozwala nam zobaczyć jak to zrozumienie jest stosowane.

Możemy postrzegać metodę Linusa jako sposób na stworzenie efektywnego rynku ``egoboo''- aby połączyć egoizm poszczególnych hakerów tak mocno jak to tylko możliwe z trudnymi celami, które mogą być osiągnięte tylko poprzez trwałą współpracę. Dzięki projektowi fetchmail pokazałem (choć na mniejszą skalę), że jego metody mogą być powielane z dobrym skutkiem. Być może nawet zrobiłem to nieco bardziej świadomie i systematycznie niż on.

Wielu ludzi (zwłaszcza tych, którzy politycznie nie ufają wolnym rynkom) spodziewałoby się, że kultura samokierujących się egoistów będzie rozdrobniona, terytorialna, rozrzutna, skryta i wroga. Ale to oczekiwanie jest wyraźnie sfalsyfikowane przez (żeby podać tylko jeden przykład) oszałamiającą różnorodność, jakość i głębię dokumentacji Linuksa. Uświęconym faktem jest, że programiści nienawidzą dokumentować; jak to się więc dzieje, że hakerzy Linuksa generują tak wiele dokumentacji? Najwyraźniej linuksowy wolny rynek egoboo działa lepiej w celu wytworzenia cnotliwego, ukierunkowanego na innych zachowania niż masowo finansowane sklepy z dokumentacją komercyjnych producentów oprogramowania.

Zarówno projekt fetchmail, jak i projekt jądra Linuksa pokazują, że poprzez odpowiednie nagradzanie ego wielu innych hakerów, silny programista/koordynator może wykorzystać Internet do uchwycenia korzyści płynących z posiadania wielu współtwórców, bez popadania projektu w chaotyczny bałagan. Tak więc do Prawa Brooksa kontrproponuję następujące stwierdzenie:

19: Pod warunkiem, że koordynator rozwoju ma medium komunikacyjne co najmniej tak dobre jak Internet i wie, jak przewodzić bez przymusu, wiele głów jest nieuchronnie lepszych niż jedna.

Myślę, że przyszłość oprogramowania o otwartym kodzie źródłowym będzie w coraz większym stopniu należeć do ludzi, którzy wiedzą jak grać w grę Linusa, ludzi, którzy porzucają katedrę i przyjmują bazar. Nie oznacza to, że indywidualna wizja i błyskotliwość nie będą już miały znaczenia; myślę raczej, że przewaga oprogramowania open-source będzie należała do ludzi, którzy zaczną od indywidualnej wizji i błyskotliwości, a następnie wzmocnią je poprzez efektywne budowanie dobrowolnych wspólnot interesów.

Być może to nie jest tylko przyszłość oprogramowania z otwartym kodem źródłowym. Żaden twórca oprogramowania o zamkniętym kodzie źródłowym nie może się równać z pulą talentów, jakie społeczność linuksowa może wnieść do danego problemu. Bardzo niewielu mogłoby sobie pozwolić nawet na zatrudnienie ponad 200 (1999: 600, 2000: 800) osób, które przyczyniły się do powstania fetchmaila!

Być może w końcu kultura otwartego oprogramowania zatriumfuje nie dlatego, że współpraca jest moralnie słuszna lub że "złodziejstwo oprogramowania" jest moralnie złe (zakładając, że wierzysz w to drugie, w co nie wierzę ani Linus, ani ja), ale po prostu dlatego, że świat zamkniętego oprogramowania nie może wygrać ewolucyjnego wyścigu zbrojeń ze społecznościami otwartego oprogramowania, które mogą poświęcić o rzędy wielkości więcej czasu na rozwiązanie problemu.

O zarządzaniu i Linii Maginota

Oryginalny artykuł Cathedral and Bazaar z 1997 roku kończył się powyższą wizją - szczęśliwych, połączonych w sieć hord programistów/anarchistów, które prześcigną i przytłoczą hierarchiczny świat konwencjonalnego, zamkniętego oprogramowania.

Wielu sceptyków nie było jednak przekonanych, a pytania, które podnoszą, zasługują na uczciwe zaangażowanie. Większość zastrzeżeń wobec argumentu bazaru sprowadza się do twierdzenia, że jego zwolennicy nie docenili zwiększającego produktywność efektu konwencjonalnego zarządzania.

Tradycyjnie myślący menedżerowie zajmujący się rozwojem oprogramowania często zarzucają, że przypadkowość, z jaką grupy projektowe tworzą się, zmieniają i rozwiązują w świecie open-source, neguje znaczną część pozornej przewagi liczebnej, jaką społeczność open-source ma nad każdym pojedynczym deweloperem z zamkniętym kodem źródłowym. Zauważyliby, że w rozwoju oprogramowania naprawdę liczy się trwały wysiłek w czasie i stopień, w jakim klienci mogą oczekiwać ciągłych inwestycji w produkt, a nie tylko to, ile osób wrzuciło kość do garnka i pozostawiło ją, by się dusiła.

Jest coś w tym argumencie, aby być pewnym; w rzeczywistości rozwinąłem pomysł, że oczekiwana przyszła wartość usług jest kluczem do ekonomii produkcji oprogramowania w eseju Magiczny kocioł.

Ale ten argument ma też poważny ukryty problem; jego ukryte założenie, że rozwój open-source nie może zapewnić takiego trwałego wysiłku. W rzeczywistości istniały projekty o otwartym kodzie źródłowym, które utrzymywały spójny kierunek i efektywną społeczność opiekunów przez dość długi okres czasu, bez struktur motywacyjnych czy kontroli instytucjonalnej, które konwencjonalne zarządzanie uważa za niezbędne. Rozwój edytora GNU Emacs jest skrajnym i pouczającym przykładem; wchłonął on wysiłki setek współpracowników przez 15 lat w jednolitą wizję architektoniczną, pomimo dużej rotacji i faktu, że tylko jedna osoba (jego autor) była stale aktywna przez cały ten czas. Żaden edytor o zamkniętym kodzie źródłowym nie dorównał temu rekordowi długowieczności.

To sugeruje powód do kwestionowania zalet konwencjonalnie zarządzanego rozwoju oprogramowania, który jest niezależny od reszty argumentów na temat trybu katedralnego i bazarowego. Jeżeli jest możliwe, żeby GNU Emacs wyrażał spójną wizję architektoniczną przez 15 lat, albo żeby system operacyjny taki jak Linux robił to samo przez 8 lat gwałtownie zmieniającego się sprzętu i technologii platformy, i jeżeli (jak to rzeczywiście ma miejsce) było wiele dobrze zaprojektowanych projektów open source trwających dłużej niż 5 lat - to mamy prawo zastanawiać się, co, jeżeli cokolwiek, kupuje nam ogromny narzut konwencjonalnie zarządzanego rozwoju.

Cokolwiek to jest, z pewnością nie obejmuje niezawodnej realizacji w terminie, budżetu lub wszystkich cech specyfikacji; jest to rzadki `zarządzany' projekt, który spełnia nawet jeden z tych celów, nie mówiąc już o wszystkich trzech. Nie wydaje się również, aby była to zdolność do adaptacji do zmian w technologii i kontekście ekonomicznym w czasie trwania projektu; społeczność open-source okazała się o wiele bardziej skuteczna w tym względzie (co można łatwo sprawdzić, na przykład, porównując 30-letnią historię Internetu z krótkimi okresami połowicznego rozpadu prawnie zastrzeżonych technologii sieciowych lub koszt przejścia z 16-bitowego na 32-bitowy system Microsoft Windows z niemal bezwysiłkową migracją Linuksa w górę w tym samym okresie, nie tylko wzdłuż linii rozwoju Intela, ale na ponad tuzin innych platform sprzętowych, w tym 64-bitową Alfę).

Wiele osób uważa, że tryb tradycyjny daje ci kogoś, kogo możesz pociągnąć do odpowiedzialności prawnej i potencjalnie odzyskać odszkodowanie, jeśli projekt pójdzie źle. Ale to złudzenie; większość licencji na oprogramowanie jest napisana tak, by zrzec się nawet gwarancji przydatności handlowej, nie mówiąc już o wydajności - a przypadki skutecznego odzyskania odszkodowania za niewydolność oprogramowania są niezwykle rzadkie. Nawet gdyby były powszechne, poczucie komfortu z powodu posiadania kogoś, kogo można pozwać, mijałoby się z celem. Nie chcieliście być w sądzie; chcieliście mieć działające oprogramowanie.

Więc po co kupuje się cały ten narzut na zarządzanie?

Aby to zrozumieć, musimy zrozumieć, co menedżerowie ds. rozwoju oprogramowania uważają, że robią. Kobieta, którą znam i która wydaje się być bardzo dobra w tej pracy, mówi, że zarządzanie projektem oprogramowania ma pięć funkcji:

Definiowanie celów i utrzymywanie wszystkich w tym samym kierunku.

Monitorowanie i upewnianie się, że kluczowe szczegóły nie zostaną pominięte

Motywowanie ludzi do wykonywania nudnej, ale koniecznej pracy

Organizowanie rozmieszczenia ludzi w celu uzyskania najlepszej produktywności

Zebranie zasobów potrzebnych do utrzymania projektu.

Wszystkie te cele wydają się być godne uwagi, ale w modelu open source i w otaczającym go kontekście społecznym, mogą zacząć wydawać się dziwnie nieistotne. Zajmiemy się nimi w odwrotnej kolejności.

Mój przyjaciel donosi, że wiele działań związanych z zarządzaniem zasobami ma charakter defensywny; kiedy już masz swoich ludzi, maszyny i przestrzeń biurową, musisz bronić ich przed innymi menedżerami rywalizującymi o te same zasoby, a także przed wyższymi rangą, próbującymi jak najefektywniej wykorzystać ograniczoną pulę.

Ale programiści open-source są wolontariuszami, samodzielnie wybranymi zarówno ze względu na zainteresowanie, jak i zdolność do wnoszenia wkładu w projekty, nad którymi pracują (i pozostaje to generalnie prawdą nawet wtedy, gdy otrzymują wynagrodzenie za hakowanie open source). Etos wolontariusza ma tendencję do dbania o `atak' stronę resource-marshalling automatycznie; ludzie przynoszą swoje własne zasoby do stołu. I jest mało lub nie ma potrzeby, aby menedżer "grał w obronie" w konwencjonalnym sensie.

W każdym razie, w świecie tanich komputerów i szybkich łączy internetowych, stwierdzamy dość konsekwentnie, że jedynym naprawdę ograniczającym zasobem jest wykwalifikowana uwaga. Projekty open-source, kiedy powstają, w zasadzie nigdy nie robią tego z powodu braku maszyn, łączy czy przestrzeni biurowej; umierają tylko wtedy, gdy sami deweloperzy tracą zainteresowanie.

W związku z tym, jest podwójnie ważne, by hakerzy open-source zorganizowali się w celu osiągnięcia maksymalnej produktywności poprzez autoselekcję - a środowisko społeczne bezlitośnie selekcjonuje pod kątem kompetencji. Mój przyjaciel, zaznajomiony zarówno ze światem open source, jak i dużymi, zamkniętymi projektami, uważa, że open source odniosło sukces częściowo dlatego, że jego kultura akceptuje tylko najbardziej utalentowane 5% lub więcej populacji programistów. Spędza ona większość swojego czasu na organizowaniu wdrażania pozostałych 95% i w ten sposób zaobserwowała z pierwszej ręki dobrze znaną różnicę w produktywności pomiędzy najzdolniejszymi programistami a tymi zaledwie kompetentnymi, wynoszącą sto czynników.

Wielkość tej różnicy zawsze rodziła niewygodne pytanie: czy poszczególne projekty i cała dziedzina byłyby lepsze, gdyby nie było w nich więcej niż 50% najmniej zdolnych? Myślący menedżerowie od dawna rozumieli, że jeśli jedyną funkcją konwencjonalnego zarządzania oprogramowaniem byłoby przekształcenie najmniej zdolnych ze straty netto w marginalną wygraną, to gra może nie być warta świeczki.

Sukces społeczności open-source znacznie wyostrza to pytanie, dostarczając twardych dowodów na to, że często taniej i efektywniej jest rekrutować z Internetu samodzielnie wybranych ochotników, niż zarządzać budynkami pełnymi ludzi, którzy woleliby robić coś innego.

Co prowadzi nas zgrabnie do kwestii motywacji. Równoważnym i często słyszanym sposobem na wyrażenie punktu mojego przyjaciela jest to, że tradycyjne zarządzanie rozwojem jest konieczną rekompensatą dla słabo zmotywowanych programistów, którzy w przeciwnym razie nie wykonaliby dobrej pracy.

Ta odpowiedź zwykle idzie w parze z twierdzeniem, że społeczność open-source może polegać tylko na pracy, która jest `seksowna' lub technicznie słodka; wszystko inne pozostanie niezrobione (lub zrobione kiepsko), chyba że zostanie zrobione przez zmotywowanych do zarabiania pieniędzy peonów z menedżerami trzaskającymi nad nimi batem. W Homesteading the Noosphere omawiam psychologiczne i społeczne powody sceptycznego podejścia do tego twierdzenia. Jednak dla obecnych celów, myślę, że bardziej interesujące jest wskazanie implikacji przyjęcia tego twierdzenia za prawdziwe.

Jeśli konwencjonalny, zamknięty, silnie zarządzany styl rozwoju oprogramowania jest naprawdę broniony tylko przez coś w rodzaju Linii Maginota problemów sprzyjających nudzie, to pozostanie on opłacalny w każdym indywidualnym obszarze zastosowań tylko tak długo, jak długo nikt nie uzna tych problemów za naprawdę interesujące i nikt inny nie znajdzie sposobu na ich obejście. Ponieważ w momencie, gdy pojawi się konkurencja open-source dla "nudnego" kawałka oprogramowania, klienci będą wiedzieli, że w końcu zajął się nim ktoś, kto wybrał ten problem do rozwiązania z powodu fascynacji samym problemem - co w oprogramowaniu, jak i w innych rodzajach pracy twórczej, jest o wiele skuteczniejszym motywatorem niż same pieniądze.

Posiadanie konwencjonalnej struktury zarządzania wyłącznie po to, by motywować, jest prawdopodobnie dobrą taktyką, ale złą strategią; krótkoterminowym zwycięstwem, ale w dłuższej perspektywie jeszcze większą porażką.

Jak dotąd, konwencjonalne zarządzanie rozwojem wygląda jak zły zakład przeciwko open source w dwóch kwestiach (zarządzanie zasobami, organizacja) i jak życie na pożyczonym czasie w odniesieniu do trzeciej (motywacja). A biedny, oblężony, konwencjonalny menedżer nie otrzyma żadnej pomocy w kwestii monitorowania; najmocniejszym argumentem społeczności open source jest to, że zdecentralizowana wzajemna weryfikacja przewyższa wszystkie konwencjonalne metody próbujące zapewnić, że szczegóły nie zostaną pominięte.

Czy możemy ocalić definiowanie celów jako uzasadnienie dla nadmiernych kosztów konwencjonalnego zarządzania projektem oprogramowania? Być może, ale żeby to zrobić, musimy mieć dobry powód, by wierzyć, że komitety zarządzające i korporacyjne mapy drogowe są bardziej skuteczne w definiowaniu wartościowych i szeroko podzielanych celów niż liderzy projektów i starszyzna plemienna, którzy pełnią analogiczną rolę w świecie open source.

Na pierwszy rzut oka jest to dość trudny argument. I to nie tyle strona open-source'owa (długowieczność Emacsa, czy zdolność Linusa Torvaldsa do mobilizowania hord programistów mową o "dominacji nad światem") czyni ją trudną. Chodzi raczej o wykazaną okropność konwencjonalnych mechanizmów definiowania celów projektów programistycznych.

Jednym z najbardziej znanych twierdzeń ludowych inżynierii oprogramowania jest to, że 60% do 75% konwencjonalnych projektów oprogramowania albo nigdy nie zostaje ukończonych, albo zostaje odrzuconych przez zamierzonych użytkowników. Jeśli ten przedział jest choć trochę prawdziwy (a nigdy nie spotkałem menedżera z jakimkolwiek doświadczeniem, który by to kwestionował), to więcej projektów niż kiedykolwiek zmierza do celów, które są albo (a) nierealistycznie osiągalne, albo (b) po prostu złe.

To, bardziej niż jakikolwiek inny problem, jest powodem, dla którego w dzisiejszym świecie inżynierii oprogramowania samo wyrażenie "komitet zarządzający" może wywołać dreszcze u słuchacza - nawet (a może zwłaszcza) jeśli słuchacz jest menedżerem. Czasy, kiedy tylko programiści narzekali na ten wzorzec, dawno minęły; teraz nad biurkami menedżerów wiszą kreskówki Dilberta.

Nasza odpowiedź dla tradycyjnego menedżera rozwoju oprogramowania jest więc prosta - jeśli społeczność open-source naprawdę nie doceniła wartości konwencjonalnego zarządzania, dlaczego tak wielu z was okazuje pogardę dla własnego procesu?

Po raz kolejny przykład społeczności open-source znacznie wyostrza to pytanie - ponieważ to, co robimy, sprawia nam przyjemność. Nasza kreatywna gra gromadzi sukcesy techniczne, rynkowe i umysłowe w zdumiewającym tempie. Udowadniamy nie tylko, że potrafimy tworzyć lepsze oprogramowanie, ale że radość jest naszym atutem.

Dwa i pół roku po opublikowaniu pierwszej wersji tego eseju, najbardziej radykalną myślą, jaką mogę zaproponować na zakończenie, nie jest już wizja świata oprogramowania zdominowanego przez oprogramowanie z otwartym kodem źródłowym; to, mimo wszystko, wygląda dziś wiarygodnie dla wielu trzeźwo myślących ludzi w garniturach.

Chcę raczej zasugerować, co może być szerszą lekcją o oprogramowaniu (i prawdopodobnie o każdym rodzaju pracy twórczej lub zawodowej). Ludzkie istoty generalnie czerpią przyjemność z zadania, gdy znajduje się ono w pewnego rodzaju optymalnej strefie wyzwań; nie jest tak łatwe, by było nudne, nie jest też zbyt trudne do osiągnięcia. Szczęśliwy programista to taki, który nie jest ani niedostatecznie wykorzystany, ani obciążony źle sformułowanymi celami i stresującymi tarciami w procesie. Radość przepowiada efektywność.

Odnoszenie się do własnego procesu pracy z lękiem i wstrętem (nawet w wyparty, ironiczny sposób sugerowany przez wieszanie kreskówek Dilberta) powinno być zatem samo w sobie uważane za znak, że proces się nie powiódł. Radość, humor i figlarność są rzeczywiście atutami; nie tylko dla aliteracji napisałem powyżej o "szczęśliwych hordach" i nie jest zwykłym żartem, że maskotką Linuksa jest milutki, neoteniczny pingwinek.

Być może okaże się, że jednym z najważniejszych efektów sukcesu open source będzie nauczenie nas, że zabawa jest najbardziej efektywnym ekonomicznie sposobem pracy twórczej.

Epilog: Netscape wciela się w bazar

To dziwne uczucie, gdy zdajesz sobie sprawę, że pomagasz tworzyć historię....

22 stycznia 1998 roku, około siedem miesięcy po tym, jak po raz pierwszy opublikowałem "Katedrę i bazar", Netscape Communications, Inc. ogłosiła plany przekazania źródła dla Netscape Communicatora. Przed dniem ogłoszenia nie miałem pojęcia, że to się stanie.

Eric Hahn, wiceprezes i dyrektor ds. technologii w Netscape, wysłał mi wkrótce potem e-mail o następującej treści: ``W imieniu wszystkich w Netscape, chcę ci podziękować za pomoc w dotarciu do tego punktu w pierwszej kolejności. Pańskie przemyślenia i pisma były fundamentalną inspiracją dla naszej decyzji".

W następnym tygodniu poleciałem do Doliny Krzemowej na zaproszenie Netscape'a na jednodniową konferencję strategiczną (4 lutego 1998 r.) z niektórymi członkami kierownictwa i ludźmi technicznymi. Wspólnie zaprojektowaliśmy strategię wydawania źródeł i licencję Netscape'a.

Kilka dni później napisałem, co następuje:

Netscape wkrótce dostarczy nam testu modelu bazaru na dużą skalę w świecie komercyjnym. Kultura open-source stoi teraz w obliczu niebezpieczeństwa; jeśli egzekucja Netscape'a nie zadziała, koncepcja open-source może zostać tak skompromitowana, że świat komercyjny nie dotknie jej ponownie przez kolejną dekadę.

Z drugiej strony, jest to również spektakularna szansa. Wstępna reakcja na ten ruch na Wall Street i w innych miejscach była ostrożnie pozytywna. My także dostajemy szansę, by się sprawdzić. Jeśli dzięki temu posunięciu Netscape odzyska znaczny udział w rynku, może to zapoczątkować długo oczekiwaną rewolucję w branży oprogramowania.

Następny rok powinien być bardzo pouczającym i interesującym okresem.

I rzeczywiście tak było. Gdy piszę te słowa w połowie 2000 roku, rozwój tego, co później nazwano Mozillą, okazał się jedynie umiarkowanym sukcesem. Osiągnęła ona pierwotny cel Netscape'a, którym było pozbawienie Microsoftu monopolistycznej blokady na rynku przeglądarek. Osiągnęła również kilka znaczących sukcesów (zwłaszcza wydanie nowej generacji silnika renderującego Gecko).

Jednakże, nie udało jej się jeszcze pozyskać ogromnego wysiłku rozwojowego spoza Netscape'a, na który pierwotnie liczyli założyciele Mozilli. Problemem wydaje się być to, że przez długi czas dystrybucja Mozilli łamała jedną z podstawowych zasad modelu bazarowego: nie zawierała czegoś, co potencjalni współtwórcy mogliby łatwo uruchomić i zobaczyć, jak działa. (Do ponad roku po wydaniu, budowanie Mozilli ze źródeł wymagało posiadania licencji na prawnie zastrzeżoną bibliotekę Motif).

Co najbardziej negatywne (z punktu widzenia świata zewnętrznego), grupa Mozilli nie dostarczyła przeglądarki o jakości produkcyjnej przez dwa i pół roku po rozpoczęciu projektu - a w 1999 roku jeden z szefów projektu wywołał niemałą sensację, podając się do dymisji, narzekając na złe zarządzanie i niewykorzystane szanse. Otwarte źródło", jak słusznie zauważył, "to nie magiczny pył.

I rzeczywiście tak nie jest. Długoterminowe prognozy dla Mozilli wyglądają teraz (w listopadzie 2000 r.) znacznie lepiej niż w czasie, gdy Jamie Zawinski pisał swój list rezygnacyjny - w ciągu ostatnich kilku tygodni nocne wydania w końcu przekroczyły krytyczny próg użyteczności. Ale Jamie miał rację, zwracając uwagę, że otwarcie niekoniecznie uratuje istniejący projekt, który cierpi z powodu źle zdefiniowanych celów, kodu spaghetti czy innych przewlekłych chorób inżynierii oprogramowania. Mozilli udało się jednocześnie dostarczyć przykład tego, jak open source może odnieść sukces i jak może zawieść.

W międzyczasie jednak, idea open source odniosła sukces i znalazła zwolenników gdzie indziej. Od czasu wydania Netscape'a widzieliśmy ogromną eksplozję zainteresowania modelem rozwoju open-source, trend napędzany zarówno przez, jak i napędzający ciągły sukces systemu operacyjnego Linux. Trend, który zapoczątkowała Mozilla, jest kontynuowany w coraz szybszym tempie.

Uwagi

[JB] W Programing Pearls, zauważony aforysta informatyki Jon Bentley komentuje obserwację Brooksa z ''Jeśli planujesz wyrzucić jeden, wyrzucisz dwa''. On jest prawie na pewno rację. Sens obserwacji Brooksa i Bentleya nie polega jedynie na tym, że powinieneś oczekiwać, iż pierwsza próba będzie błędna, ale na tym, że zaczynanie od nowa z właściwym pomysłem jest zwykle bardziej efektywne niż próby ratowania bałaganu.

Przykłady udanego rozwoju open-source, bazarowego, poprzedzającego eksplozję Internetu i niezwiązanego z tradycjami Uniksa i Internetu istnieją. Jednym z takich przykładów był rozwój narzędzia do kompresji info-Zip w latach 1990-1992, przeznaczonego głównie dla maszyn DOS-owych. Innym był system RBBS (również dla DOS-u), który powstał w 1983 roku i rozwinął na tyle silną społeczność, że do dziś (połowa 1999 roku) wydawane są dość regularne wersje, mimo ogromnej przewagi technicznej poczty internetowej i wymiany plików nad lokalnymi BBS-ami. Podczas gdy społeczność info-Zipa opierała się w pewnym stopniu na poczcie internetowej, kultura deweloperów RBBS była w stanie oprzeć na RBBS znaczącą społeczność internetową, która była całkowicie niezależna od infrastruktury TCP/IP.

[CV], że przejrzystość i wzajemna weryfikacja są cenne dla oswajania złożoności rozwoju OS okazuje się, mimo wszystko, nie jest nową koncepcją. W 1965 roku, bardzo wcześnie w historii systemów operacyjnych z podziałem czasu, Corbató i Vyssotsky, współprojektanci systemu operacyjnego Multics, napisali

Oczekuje się, że system Multics będzie publikowany, gdy będzie działał w znacznym stopniu... Taka publikacja jest pożądana z dwóch powodów: Po pierwsze, system powinien wytrzymać publiczną kontrolę i krytykę zgłaszaną dobrowolnie przez zainteresowanych czytelników; po drugie, w dobie rosnącej złożoności, obowiązkiem obecnych i przyszłych projektantów systemów jest uczynienie wewnętrznego systemu operacyjnego tak przejrzystym, jak to tylko możliwe, aby ujawnić podstawowe zagadnienia systemowe.

John Hasler zasugerował interesujące wyjaśnienie faktu, że duplikacja wysiłków nie wydaje się być hamulcem netto dla rozwoju open-source. Proponuje on coś, co nazwę ``Prawie Haslera'': koszty powielonej pracy mają tendencję do skalowania się sub-qadratowo z rozmiarem zespołu - to znaczy, wolniej niż planowanie i koszty ogólne zarządzania, które byłyby potrzebne do ich wyeliminowania.

Twierdzenie to w rzeczywistości nie jest sprzeczne z Prawem Brooksa. Może być tak, że całkowity koszt ogólny złożoności i podatność na błędy skaluje się z kwadratem wielkości zespołu, ale koszty związane z powielaniem pracy są jednak szczególnym przypadkiem, który skaluje się wolniej. Nie jest trudno opracować wiarygodne powody takiego stanu rzeczy, zaczynając od niewątpliwego faktu, że o wiele łatwiej jest uzgodnić granice funkcjonalne pomiędzy kodami różnych programistów, które zapobiegną powielaniu wysiłków, niż zapobiec rodzajom nieplanowanych złych interakcji w całym systemie, które leżą u podstaw większości błędów.

Połączenie Prawa Linusa i Prawa Haslera sugeruje, że w projektach programistycznych istnieją trzy krytyczne reżimy wielkości. W małych projektach (powiedziałbym, że od jednego do co najwyżej trzech programistów) nie jest potrzebna żadna struktura zarządzania bardziej rozbudowana niż wybór głównego programisty. Istnieje też pewien pośredni przedział, w którym koszt tradycyjnego zarządzania jest relatywnie niski, więc korzyści z unikania powielania wysiłków, śledzenia błędów i dopilnowania, by szczegóły nie zostały przeoczone, są dodatnie.

Jednak powyżej tego poziomu, kombinacja Prawa Linusa i Prawa Haslera sugeruje, że istnieje zakres dużych projektów, w którym koszty i problemy związane z tradycyjnym zarządzaniem rosną znacznie szybciej niż oczekiwane koszty związane z powielaniem wysiłków. Nie najmniejszym z tych kosztów jest strukturalna niezdolność do okiełznania efektu wielu oczu, który (jak widzieliśmy) wydaje się wykonywać o wiele lepszą pracę niż tradycyjne zarządzanie w celu upewnienia się, że błędy i szczegóły nie zostaną przeoczone. Tak więc, w przypadku dużych projektów, kombinacja tych praw skutecznie prowadzi do zerowej rentowności netto tradycyjnego zarządzania.

Podział Linuksa na wersję eksperymentalną i stabilną ma jeszcze jedną funkcję, związaną z zabezpieczeniem ryzyka, ale odrębną od niego. Podział ten atakuje inny problem: śmiercionośność terminów. Kiedy programiści są trzymani zarówno wobec niezmiennej listy funkcji, jak i ustalonej daty zakończenia, jakość wychodzi przez okno i prawdopodobnie powstaje kolosalny bałagan. Jestem wdzięczny Marco Iansiti i Alanowi MacCormackowi z Harvard Business School za pokazanie mi dowodów na to, że rozluźnienie jednego z tych ograniczeń może sprawić, że planowanie stanie się wykonalne.

Jednym ze sposobów na zrobienie tego jest ustalenie terminu, ale pozostawienie listy funkcji elastyczną, pozwalającą na ich usunięcie, jeśli nie zostaną ukończone przed terminem. To jest zasadniczo strategia "stabilnej" gałęzi jądra; Alan Cox (opiekun stable-kernel) wydaje wydania w dość regularnych odstępach czasu, ale nie daje żadnych gwarancji co do tego, kiedy poszczególne błędy zostaną naprawione lub jakie funkcje zostaną przeniesione z powrotem z gałęzi eksperymentalnej.

Innym sposobem na zrobienie tego jest ustalenie listy pożądanych funkcji i dostarczanie ich tylko wtedy, gdy są już gotowe. To jest w zasadzie strategia "eksperymentalnej" gałęzi jądra. De Marco i Lister cytowali badania pokazujące, że ta polityka harmonogramowania ("obudź mnie, kiedy to jest zrobione") daje nie tylko najwyższą jakość, ale średnio krótszy czas dostarczenia niż "realistyczne" lub "agresywne" harmonogramowanie.

Podejrzewam (od początku 2000 roku), że we wcześniejszych wersjach tego eseju poważnie nie doceniałem znaczenia polityki "obudź mnie, kiedy to będzie zrobione" dla produktywności i jakości społeczności open-source. Ogólne doświadczenie z pospiesznym wydaniem GNOME 1.0 w 1999 roku sugeruje, że presja na przedwczesne wydanie może zneutralizować wiele korzyści jakościowych, jakie zwykle daje open source.

Może się okazać, że przejrzystość procesu otwartego oprogramowania jest jednym z trzech równorzędnych czynników wpływających na jego jakość, wraz z harmonogramem "obudź mnie, kiedy to będzie zrobione" i samoselekcją programistów.

[SU] Kuszące i nie do końca nietrafne jest postrzeganie organizacji rdzeń-plus-halo charakterystycznej dla projektów open source jako internetowej wersji rekomendacji Brooksa dla rozwiązania problemu N-kwadratowej złożoności, organizacji "zespół chirurgiczny" - ale różnice są znaczące. Konstelacja specjalistycznych ról, takich jak "bibliotekarz kodu", które Brooks przewidział wokół lidera zespołu, tak naprawdę nie istnieje; te role są wykonywane zamiast tego przez generalistów wspomaganych przez zestawy narzędzi, które są nieco bardziej potężne niż te z czasów Brooksa. Ponadto, kultura open source opiera się w dużym stopniu na silnych uniksowych tradycjach modularności, API i ukrywania informacji - żaden z tych elementów nie był częścią recepty Brooksa.

Respondent, który zwrócił mi uwagę na wpływ bardzo różnych długości ścieżek na trudność scharakteryzowania błędu, spekulował, że trudność ścieżek dla wielu symptomów tego samego błędu zmienia się "wykładniczo" (co rozumiem jako rozkład gaussowski lub poissonowski i zgadzam się, że wydaje się to bardzo prawdopodobne). Jeśli eksperymentalnie możliwe jest poznanie kształtu tego rozkładu, byłyby to niezwykle cenne dane. Duże odchylenia od płaskiego rozkładu równych prawdopodobieństw trudności śledzenia sugerowałyby, że nawet samodzielni programiści powinni naśladować strategię bazaru, ograniczając czas, jaki spędzają na śledzeniu danego symptomu, zanim przejdą do innego. Wytrwałość nie zawsze musi być cnotą...

[IN] Kwestią związaną z tym, czy można zaczynać projekty od zera w stylu bazarowym, jest to, czy styl bazarowy jest w stanie wspierać prawdziwie innowacyjną pracę. Niektórzy twierdzą, że przy braku silnego przywództwa, bazar może zajmować się jedynie klonowaniem i ulepszaniem pomysłów, które są już obecne na poziomie inżynierskiego stanu techniki, ale nie jest w stanie przeforsować stanu techniki. Argument ten został chyba najbardziej niesławnie przedstawiony w Dokumentach Halloween, dwóch kompromitujących wewnętrznych memorandach Microsoftu napisanych na temat zjawiska open source. Autorzy porównali rozwój Linuksa jako systemu operacyjnego podobnego do Uniksa do "gonienia za tylnymi światłami" i stwierdzili, że "(gdy projekt osiągnie "parytet" z najnowszym stanem techniki), poziom zarządzania niezbędny do przesunięcia w kierunku nowych granic staje się ogromny".

Istnieją poważne błędy rzeczowe implikowane w tym argumencie. Jeden z nich jest narażony, gdy autorzy Halloween sami później zauważają, że ``często [...] nowe pomysły badawcze są najpierw wdrażane i dostępne na Linuksie, zanim będą dostępne / włączone do innych platform''.

Jeśli przeczytamy ``open source'' dla ''Linux'', zobaczymy, że jest to dalekie od nowego zjawiska. Z historycznego punktu widzenia, społeczność open source nie wymyśliła Emacsa, World Wide Web czy samego Internetu goniąc za tylnymi światłami czy będąc masowo zarządzaną - a obecnie w open source dzieje się tak wiele innowacyjnej pracy, że nie ma w czym wybierać. Projekt GNOME (by wybrać jeden z wielu) pcha do przodu stan techniki w GUI i technologii obiektowej na tyle mocno, że przyciągnął uwagę prasy komputerowej daleko poza społeczność Linuksa. Inne przykłady są niezliczone, co szybko udowodni wizyta na Freshmeat w dowolnym dniu.

Ale bardziej fundamentalny błąd tkwi w ukrytym założeniu, że model katedry (lub model bazaru, lub jakikolwiek inny rodzaj struktury zarządzania) może w jakiś sposób sprawić, że innowacje będą niezawodnie wprowadzane. To nonsens. Gangi nie mają przełomowych spostrzeżeń - nawet ochotnicze grupy bazarowych anarchistów są zazwyczaj niezdolne do prawdziwej oryginalności, nie mówiąc już o korporacyjnych komitetach złożonych z ludzi, którzy mają interes w przetrwaniu jakiegoś status quo ante. Wgląd pochodzi od jednostek. Ich otaczająca machina społeczna może co najwyżej liczyć na to, że będzie reagować na przełomowe spostrzeżenia - odżywiać je, nagradzać i rygorystycznie testować, zamiast je niszczyć.

Niektórzy uznają to za romantyczny pogląd, powrót do przestarzałych stereotypów samotnego wynalazcy. Nie jest tak; nie twierdzę, że grupy nie są zdolne do rozwijania przełomowych spostrzeżeń, kiedy już się wyklują; w istocie, z procesu wzajemnej weryfikacji dowiadujemy się, że takie grupy rozwojowe są niezbędne do uzyskania wysokiej jakości rezultatów. Wskazuję raczej, że każdy taki rozwój grupowy zaczyna się od jednego dobrego pomysłu w głowie jednej osoby - i z konieczności jest przez niego zapoczątkowany. Katedry, bazary i inne struktury społeczne mogą złapać ten piorun i udoskonalić go, ale nie mogą go stworzyć na żądanie.

Dlatego głównym problemem innowacji (w oprogramowaniu, czy gdziekolwiek indziej) jest rzeczywiście to, jak ich nie zgnieść, ale jeszcze bardziej fundamentalnym jest to, jak wyhodować wielu ludzi, którzy mogą mieć wgląd w nie w pierwszej kolejności.

Przypuszczenie, że rozwój w stylu katedry poradziłby sobie z tą sztuczką, ale niskie bariery wejścia i płynność procesu na bazarze już nie, byłoby absurdem. Jeśli to, czego potrzeba, to jedna osoba z jednym dobrym pomysłem, to środowisko społeczne, w którym jedna osoba może szybko przyciągnąć do współpracy setki lub tysiące innych z tym dobrym pomysłem, będzie nieuchronnie przewyższać innowacyjnością każde środowisko, w którym ta osoba musi wykonać polityczną robotę polegającą na sprzedaży hierarchii, zanim będzie mogła pracować nad swoim pomysłem bez ryzyka zwolnienia.

I rzeczywiście, jeśli przyjrzymy się historii innowacji oprogramowania w organizacjach stosujących model katedry, szybko zauważymy, że jest ona raczej rzadka. Wielkie korporacje polegają na badaniach uniwersyteckich w poszukiwaniu nowych pomysłów (stąd niepokój autorów Halloween Documents dotyczący możliwości Linuksa w szybszym przejmowaniu tych badań). Albo wykupują małe firmy zbudowane wokół mózgu jakiegoś innowatora. W żadnym z tych przypadków innowacja nie jest rodzima dla kultury katedralnej; w istocie, wiele tak importowanych innowacji kończy się cichym uduszeniem przez "masowy poziom zarządzania", który tak wychwalają autorzy Halloween Documents.

Jest to jednak uwaga negatywna. Czytelnikowi lepiej przysłuży się pozytywny. Proponuję, jako eksperyment, co następuje:

Wybierzcie kryterium oryginalności, które, jak sądzicie, możecie stosować konsekwentnie. Jeśli twoja definicja jest ``I know it when I see it'', to nie jest problem dla celów tego testu.

Wybierz jakikolwiek system operacyjny o zamkniętym kodzie źródłowym konkurujący z Linuksem, oraz najlepsze źródło informacji o bieżących pracach nad nim.

Obserwuj to źródło i Freshmeat przez jeden miesiąc. Każdego dnia policz liczbę ogłoszeń o wydaniu na Freshmeat, które uważasz za "oryginalną" pracę. Zastosuj tę samą definicję "oryginalności" do ogłoszeń dla tego innego systemu operacyjnego i policz je.

Trzydzieści dni później, zsumuj obie liczby.

W dniu, w którym to napisałem, Freshmeat nosił dwadzieścia dwa ogłoszenia, z których trzy wydają się mogą popchnąć stan techniki w jakimś zakresie, To był wolny dzień dla Freshmeat, ale będę zdumiony, jeśli jakikolwiek czytelnik donosi aż trzy prawdopodobne nowości w miesiącu w każdym zamkniętym kanale źródłowym.

EGCS] Mamy teraz historię projektu, który pod kilkoma względami może stanowić bardziej wyrazisty test przesłanek bazaru niż fetchmail; EGCS, Eksperymentalny System Kompilatorów GNU.

Projekt ten został ogłoszony w połowie sierpnia 1997 roku jako świadoma próba zastosowania pomysłów zawartych we wczesnych publicznych wersjach The Cathedral and the Bazaar. Twórcy projektu czuli, że rozwój GCC, kompilatora Gnu C, uległ stagnacji. Przez około dwadzieścia miesięcy GCC i EGCS były równoległymi produktami - oba czerpały z tej samej populacji programistów internetowych, oba zaczynały od tej samej bazy źródłowej GCC, oba używały prawie tych samych uniksowych narzędzi i środowiska programistycznego. Projekty różniły się tylko tym, że EGCS świadomie próbował stosować taktykę bazaru, którą opisałem wcześniej, podczas gdy GCC zachował organizację przypominającą katedrę, z zamkniętą grupą programistów i rzadkimi wydaniami.

To było tak bliskie kontrolowanemu eksperymentowi jak tylko można było o to prosić, a rezultaty były dramatyczne. W ciągu kilku miesięcy, wersje EGCS znacznie wyprzedziły swoje funkcje: lepsza optymalizacja, lepsze wsparcie dla FORTRANu i C++. Wiele osób uznało, że migawki rozwojowe EGCS są bardziej niezawodne niż najnowsza stabilna wersja GCC, a główne dystrybucje Linuksa zaczęły przechodzić na EGCS.

W kwietniu 1999 roku, Fundacja Wolnego Oprogramowania (oficjalni sponsorzy GCC) rozwiązała oryginalną grupę rozwojową GCC i oficjalnie przekazała kontrolę nad projektem zespołowi sterującemu EGCS.

Oczywiście, krytyka Kropotkina i prawo Linusa podnoszą pewne szersze kwestie dotyczące cybernetyki organizacji społecznych. Inne ludowe twierdzenie inżynierii oprogramowania sugeruje jedno z nich; Prawo Conway'a - powszechnie określane jako ''Jeśli masz cztery grupy pracujące nad kompilatorem, otrzymasz kompilator czteroprzebiegowy''. Oryginalne stwierdzenie było bardziej ogólne: ``Organizacje projektujące systemy są ograniczone do tworzenia projektów, które są kopiami struktur komunikacyjnych tych organizacji''. Moglibyśmy to ująć bardziej zwięźle jako ''Środki determinują cele'', lub nawet ''Proces staje się produktem''.

Warto więc zauważyć, że w społeczności open-source forma organizacyjna i funkcja pokrywają się na wielu poziomach. Sieć jest wszystkim i wszędzie: nie tylko Internet, ale ludzie wykonujący pracę tworzą rozproszoną, luźno powiązaną sieć peer-to-peer, która zapewnia wielokrotną redundancję i bardzo łatwo ulega degradacji. W obu sieciach każdy węzeł jest ważny tylko w takim stopniu, w jakim inne węzły chcą z nim współpracować.

Część peer-to-peer jest niezbędna dla zadziwiającej produktywności społeczności. Punkt Kropotkin próbował zrobić o relacji władzy jest rozwijany dalej przez `Zasada SNAFU': ``Prawdziwa komunikacja jest możliwa tylko między równymi sobie, ponieważ podwładni są bardziej konsekwentnie nagradzani za mówienie swoim przełożonym przyjemnych kłamstw niż za mówienie prawdy''. Kreatywna praca zespołowa całkowicie zależy od prawdziwej komunikacji i dlatego jest bardzo poważnie utrudniona przez obecność relacji władzy. Społeczność open-source, efektywnie wolna od takich relacji władzy, uczy nas na zasadzie kontrastu, jak strasznie dużo kosztują błędy, obniżona produktywność i utracone możliwości.

Co więcej, zasada SNAFU przewiduje w organizacjach autorytarnych postępujący rozdźwięk między decydentami a rzeczywistością, ponieważ coraz więcej informacji przekazywanych tym, którzy podejmują decyzje, staje się przyjemnymi kłamstwami. Łatwo zauważyć, jak to wygląda w konwencjonalnym procesie tworzenia oprogramowania; istnieją silne bodźce dla podwładnych, by ukrywać, ignorować i minimalizować problemy. Kiedy ten proces staje się produktem, oprogramowanie jest katastrofą.