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ą.