Posty napisane przez Bernard

ROZDZIAŁ TRZECI

Jak zorganizować rój: Zarządzanie stadem kotów

Choć rój składa się w przeważającej części z luźno powiązanych ze sobą aktywistów, to w jego środku znajduje się centralna grupa ludzi - szkielet roju - która wymaga nieco bardziej formalnej organizacji. Ten szkielet trzeba zbudować naprawdę starannie, zwracając uwagę na dostępną wiedzę o zachowaniach grupowych ludzi. Bez szkieletu, rój nie ma rdzenia, wokół którego mógłby się... roić.

Podczas gdy poprzedni rozdział był o pierwszych sześciu do ośmiu dniach życia roju, ten rozdział jest o pierwszych sześciu do ośmiu tygodniach.

Budując ten szkielet ludzi kontaktowych, oficerów roju, musisz przede wszystkim znać granice wielkości grupy, które po ich osiągnięciu uniemożliwiają dalszy wzrost, i dzielić grupy, które osiągają te wielkości, na mniejsze podgrupy.

Ponadto należy wiedzieć, że każda organizacja kopiuje praktyki i zachowania swojego założyciela. Oznacza to, że rój będzie zachowywał się dokładnie tak samo jak ty, pomimo twoich nieustannych wysiłków, aby nauczyć go dobrych manier. Jedynym sposobem na to, by rój zachowywało się przyzwoicie, jest samemu zachowywać się przyzwoicie. Do tej obserwacji wrócimy w dalszej części tego rozdziału.

TRZY MAGICZNE WIELKOŚCI GRUP

Garstka ludzi tworzących szkielet roju będzie przypominać tradycyjną organizację hierarchiczną. Należy jednak pamiętać, że w przeciwieństwie do korporacji czy innych tradycyjnych organizacji, celem tego szkieletu nie jest zarządzanie czy kontrolowanie mas. Jego celem i funkcją jest raczej wspieranie pozostałych 95 procent organizacji - roju - w którym ludzie podejmują własne decyzje w oparciu o wyznawane przez ciebie wartości i zwracają się do szkieletu tylko wtedy, gdy potrzebują pomocy, wsparcia lub zasobów.

Jednak, aby zbudować efektywny szkielet, konieczne jest zrozumienie ludzkiej psychiki w kontekście optymalnej wielkości grupy i teorii organizacji.

W każdej organizacji można łatwo zauważyć, że grupy robocze większe niż siedem osób rozpadają się na dwie mniejsze grupy. Istnieje kilka teorii, dlaczego tak się dzieje, ale najpopularniejsza z nich mówi, że ma to związek z ilością wysiłku, jaki trzeba włożyć w utrzymanie i pielęgnowanie relacji w grupie roboczej. Dla zobrazowania posłużmy się przykładem.

W grupie dwóch osób istnieje tylko jedna relacja, którą grupa musi pielęgnować.

W grupie trzech osób istnieją trzy relacje (między A i B, między B i C oraz między A i C).

Diagram 1. Liczba związków w poszczególnych grupach wielkościowych

W grupie pięciu osób naraz, istnieje 4+3+2+1 = dziesięć relacji. A jeśli zwiększymy liczebność grupy do krytycznej granicy siedmiu osób, grupa będzie musiała utrzymywać dwadzieścia jeden relacji interpersonalnych, aby jej członkowie mogli współpracować.

Jak wynika z tych obliczeń, złożoność społeczna grupy rośnie znacznie szybciej niż wielkość samej grupy. Od pewnej wielkości grupa traci skuteczność, ponieważ musi wkładać tyle wysiłku w utrzymanie wewnętrznej harmonii, że nie ma już energii na rzeczywistą pracę.

Kiedy dodamy do grupy ósmego członka, liczba relacji do utrzymania wzrośnie z 21 do 28. Tak więc, mimo że dodanie ósmego członka zwiększy wydajność pracy o 14 procent w porównaniu z grupą siedmioosobową, grupa będzie musiała poświęcić o 33 procent więcej swojej łącznej wydajności pracy na własne utrzymanie, na utrzymanie 28 relacji zamiast 21. W tym momencie, a czasami po dołączeniu dziewiątego członka, grupa się rozpada.

Wynika z tego jasno, że rusztowanie musi być tak skonstruowane, aby w ścisłym układzie nie pracowało ze sobą więcej niż siedem osób.

Robimy to klasycznie, planując schemat organizacji w taki sposób, aby w żadnym układzie nie współpracowało z nikim więcej niż sześć innych osób. Oznacza to, że każdy obszar geograficzny (np. stan, hrabstwo, miasto itp.) w schemacie organizacyjnym musi być podzielony na co najwyżej sześć mniejszych obszarów, którymi będą zajmować się różni ludzie.

Na razie tego typu oficera roju będziemy nazywać dowódcą obszaru. Może to być lider stanowy, lider miejski, lider okręgowy - wielkość obszaru nie ma znaczenia - ale obowiązki zawsze będą zasadniczo takie same.

(Zapewne pamiętacie, że zapoczątkowaliśmy rój dzieląc go na podkategorie geograficzne i pozwalając liderom geograficznym wyłonić się w drodze samoorganizacji).

W każdym rejonie geograficznym, oprócz szefa rejonu, będziemy mieli prawdopodobnie czterech oficerów operacyjnych i jednego lub dwóch zastępców szefa. (Do tych koncepcji i przykładowego schematu organizacyjnego wrócimy w dalszej części rozdziału). To znów daje w sumie grupę składającą się z co najwyżej siedmiu osób.

Tak więc głównym przesłaniem poprzednich kilku akapitów jest to, że żaden kierownik rejonu nie powinien pracować bezpośrednio z więcej niż sześcioma osobami w jednej strukturze. Oznacza to, że w powyższym szkielecie zbudujemy szereg mini-piramid organizacyjnych, które zawsze będą składały się z (co najwyżej) siedmiu osób, a każdy kierownik obszaru będzie zarówno członkiem podstawy jednej piramidy, jak i stanie na szczycie innej piramidy, bezpośrednio podległej poprzedniej, jak pokazano na schemacie 2..

cz-chap03-mgt-pyramids.svg

Schemat 2. Piramidy organizacyjne

Tak więc najmniejszą z trzech magicznych wielkości grup społecznych jest siedem, a
największa z nich to 150.

Nie ma żadnego związku między tymi liczbami. Liczba siedem wydaje się wynikać z praktycznego ograniczenia wysiłku potrzebnego do zapewnienia spójności grupy, jak wyjaśniono wcześniej. Nieco bardziej tajemnicza liczba 150 wydaje się być limitem wynikającym z budowy naszego mózgu.

Liczba 150 pojawia się w wielu miejscach w organizacyjnej historii ludzkości. Jest to nasz maksymalny rozmiar plemienia. W danym przedziale czasowym jesteśmy w stanie poznać z imienia i nazwiska właśnie tyle osób i utrzymać z nimi choćby najluźniejsze możliwe więzi.

Antropolodzy, którzy porównywali wielkość kory szarej w ludzkim mózgu z wielkością mózgów innych naczelnych i wielkością ich grup, uważają tę liczbę za ograniczenie biologiczne.

Granica ta znana jest również jako Liczba Dunbara lub Granica Dunbara, po brytyjskim antropologu Robinie Dunbarze, który pierwszy ją opisał.

Jeśli pracujesz w firmie zatrudniającej mniej niż 150 pracowników, prawdopodobnie znasz ich wszystkich z imienia i nazwiska - lub przynajmniej mógłbyś ich zapamiętać. W większej firmie zaczynasz już zwracać się do anonimowych osób po nazwie stanowiska, zamiast zwracać się do nich po imieniu. Pójdziesz "do kogoś z działu wsparcia technicznego" zamiast "porozmawiać z Marysią lub Davidem".

Firmy, organizacje i kultury odnoszące największe sukcesy wiedzą aż za dobrze o tym ludzkim ograniczeniu. Weźmy na przykład Amiszów, kiedy ich osada zaczyna zbliżać się do 150 osób, dzielą ją na dwie części. Firma Gore and Associates - najbardziej znana jako producent tkaniny Gore-Tex - nigdy nie zatrudnia więcej niż 150 osób w jednej fabryce. Podobnych przykładów jest o wiele więcej.

Implikacje dla budowania twojej organizacji są takie same jak dla każdej innej organizacji odnoszącej sukcesy: musisz wiedzieć, że grupy większe niż 150 osób tracą więzi społeczne niezbędne do efektywnej współpracy i, co najważniejsze, do czerpania z niej satysfakcji.

Z drugiej strony, prawdopodobnie nie będziesz miał żadnej tak dużej grupy. Z drugiej strony, należy uważać na nieformalne grupy, które nieuchronnie będą się tworzyć i po osiągnięciu tej granicy mogą utrudniać dalszy rozwój roju.

W szczególności należy zwrócić uwagę na początkowy i poziomy zespół ludzi, którzy zbierają się na kanale czatowym lub innym podobnym miejscu zwanym prawdopodobnie "czat o wszystkim, co jest związane z rojem". Po dotarciu do 150 osób, ta samoistnie uformowana grupa uderzy w niewidzialną barierę, której nikt nie zauważy, jeśli nie będzie wiedział o tych mechanizmach. Kiedy to się stanie, dalszy rozwój roju zostanie zatrzymany, ponieważ nie będzie już więcej osób, które mogą być społecznie zintegrowane z tym początkowym kanałem czatu.

Dlatego twoim zadaniem jest upewnienie się, że wszędzie istnieją społeczne sub-roje, które mogą przyciągnąć i zatrzymać nowych ludzi, a nie tylko jeden centralny kanał czatu. Nawet te pod-roje będą miały maksymalną wielkość 150 osób.

Gdy rój osiągnie 150 osób, trzeba zacząć dzielić go na mniejsze grupy.

Wreszcie, trzecia magiczna wielkość grupy to trzydzieści osób. Jest to grupa, która znajduje się pomiędzy ścisłą grupą roboczą a grupą osób, które znamy z imienia, ale nie wiemy o nich wiele więcej: w grupie trzydziestu osób pamiętamy więcej niż tylko imiona, znamy kilka zainteresowań i ciekawostek o innych członkach grupy, ale nie możemy z nimi wszystkimi blisko współpracować. Można o niej myśleć jak o rozszerzonej rodzinie.

Prawdopodobnie spotkasz się z kilkoma formalnymi grupami składającymi się z około trzydziestu członków, takimi jak zbiorcza grupa wszystkich oficerów lub liderów dla danej działalności lub obszaru geograficznego, ale generalnie powinieneś starać się tworzyć grupy siedmioosobowe. Jeśli w trakcie obserwacji codziennej współpracy kilku takich grup zauważysz, że niektóre z nich współpracują ze sobą ściślej niż inne, powinieneś pamiętać o limicie liczebności trzydziestu członków. Na przykład, jeśli grupa, która koordynuje wszystkie prace w mieście pod każdym względem, zaczyna zbliżać się do 35 członków, to grupa ta uniemożliwia dalszy rozwój roju i powinna zostać podzielona na dwie części, aby umożliwić dalszy rozwój: podzielone grupy mogą wtedy, na przykład, zająć się oddzielnie północną i południową częścią miasta.

Po przeczytaniu poprzednich paragrafów zrozumiecie, dlaczego w rozdziale 2 podzieliliśmy rój według obszarów geograficznych i staraliśmy się, aby nie było więcej niż trzydzieści obszarów. W pierwszym szeregu stoicie wy, jako założyciele roju i komunikujecie się bezpośrednio z (najwyżej) trzydziestoma liderami terenowymi.

Jeśli to zrobiliście, to trzy do czterech tygodni po uformowaniu się roju jest idealnym momentem, aby umieścić kolejną pośrednią warstwę oficerów pomiędzy wami a tymi trzydziestoma liderami, tak abyście komunikowali się bezpośrednio z pięcioma lub sześcioma nowymi liderami terenowymi, a każdy z nich dalej komunikował się z pięcioma lub sześcioma pierwotnymi liderami terenowymi.

Podsumujmy więc najważniejsze rzeczy: utrzymujmy wielkość sformalizowanych, szkieletowych grup roboczych na poziomie około siedmiu osób. Jeśli kilka grup współpracuje ze sobą, staraj się utrzymać całkowitą liczebność grupy, tak by nie przekraczała liczby trzydziestu osób. Wreszcie, należy mieć na uwadze, że grupy nieformalne w roju mogą mieć wielkość zbliżoną do 150 osób. Jeśli tak się stanie, podejmij kroki w celu podzielenia ich na mniejsze podgrupy.

(Po raz pierwszy dowiedziałem się o różnicach w funkcjonowaniu grup o tych trzech wielkościach - siedmiu, trzydziestu i 150 - podczas wojskowego szkolenia oficerskiego, kiedy byłem w wieku dwudziestu kilku lat. Nieprzypadkowo liczby te odpowiadają wielkości drużyny, plutonu i kompanii. Od tego czasu spotkałem się z tą magiczną wielkością grupy na prawie każdym kursie przywództwa i seminarium na temat zarządzania, w taki czy inny sposób. Co jednak najważniejsze, wszystkie moje doświadczenia w budowaniu rojów potwierdzają ich znaczenie).

RADZENIE SOBIE Z OSOBAMI ŁAKNĄCYMI UWAGI

Kiedy rój osiągnie pierwsze sukcesy, kilka osób będzie próbowało się przyłączyć, nie dlatego, że są przychylni celom organizacji, ale dlatego, że chcą być w centrum uwagi, a popularność roju może to pozornie zapewnić.

Ponieważ rój jest otwarty, nie możesz trzymać takich ludzi z dala od siebie - ale możesz odmówić im przestrzeni i źródeł uwagi, których pożądają. Mogą być one trudne do wykrycia, ale jedną rzeczą, którą mają wspólnego jest to, że zamiast próbować budować sam rój wraz z ludźmi, którzy nie są jeszcze tak sławni, żądają uwagi od ciebie osobiście. Przekonasz się również, że myślą oni głównie o statusie i hierarchii, podczas gdy inni ludzie są głównie zainteresowani załatwianiem spraw i zmienianiem świata.

Kilka szczególnie bystrych osób będzie ciężko pracowało przez pierwsze kilka tygodni na rzecz celów roju, a następnie spróbuje zwrócić na siebie uwagę dzięki swojej wiarygodności. Kiedy tak się dzieje, przejrzystość roju jest najlepszym możliwym lekarstwem, ponieważ ludzie ci typowo wykorzystują fakt, że inni nie weryfikują faktycznego przebiegu zdarzeń, które ktoś im opowiada.

Ta faza budowania roju jest nieunikniona i trudna do pokonania, ale możesz być pewien, że tak długo jak rój pozostaje otwarty i przejrzysty, tego rodzaju ludzie nie będą w stanie wykorzystać go dla swojej osobistej popularności. W końcu zawsze zostają wyrzuceni, czasem z wielkim hałasem.

Po południu 2 stycznia 2006 roku.

Po lunchu mój szef, prezes zarządu, wręcza mi telefon bezprzewodowy. "Rick, do ciebie Mia" - powiedział, gdy mówił. Mia? Myślę sobie. Nie znam żadnej Mii.

"Rick Falkvinge? Witam. Mówi Mia Carron z Aftonbladet. Dowiedzieliśmy się, że to ty stoisz za tą nową Partią Piratów, o której wszyscy dziś mówią - powiedział głos.

Nawet nie wiem, co powiedzieć. Aftonbladet? I oni do mnie dzwonią? ... Co powiedziała: "ten, o którym wszyscy dziś mówią"? Doszedłem do siebie na tyle, że zdałem sobie sprawę, że nie mogę o tym mówić w godzinach pracy, ale mogę dziś wyjść trochę wcześniej. "Czy mogę do ciebie oddzwonić o 15:00?" Pytam.

Jesteśmy umówieni. W drodze z pracy do domu przeprowadzam swój pierwszy wywiad dla gazety, który kompletnie mnie zaskoczył.

"A więc jest pan przewodniczącym partii?" pyta reporter.

"Hmm, chyba tak...", odpowiadam bez zastanowienia. "Jeszcze nie do końca przyzwyczaiłem się do tej roli".

Kiedy wracam tego dnia do domu z pracy, wywiad jest już opublikowany na stronie internetowej Aftonbladet wraz z ankietą. 61 procent ankietowanych stwierdziło, że w przyszłości może zagłosować na Partię Piratów. Potrzebujemy 4 procent, aby odnieść sukces. W ankiecie zagłosowało już ponad 50 tysięcy osób, więc nie jest to tylko błąd statystyczny. Czuję, jak adrenalina wyostrza moje zmysły.

Gra się rozpoczeła.

PIERWSZE ZADANIE ROJU

Gdy rój zorganizuje się w grupy według obszarów geograficznych, należy natychmiast dać mu zadanie, które pomoże mu się odpowiednio uformować. Jeśli po prostu powiesz ludziom, żeby odwiedzili forum i nic więcej się nie wydarzy, stracą zainteresowanie w ciągu tygodnia. Przecież to są ludzie, którzy własną pracą chcieli pomóc rojowi w osiągnięciu sukcesu, pamiętasz?

Dlatego, aby cała organizacja mogła okrzepnąć, musi być zadanie, nad którym trzeba natychmiast zacząć pracować. W przypadku szwedzkiej Partii Piratów zadanie to polegało na zebraniu 2000 podpisów popierających rejestrację partii w Urzędzie Wyborczym. Musi to być zadanie, które wygląda na trudne, ale może być wykonane przez sto lub więcej osób; musi to być zadanie, które zapewni wewnętrzną konkurencję między trzydziestoma grupami regionalnymi; i musi to być zadanie, w którym korzyści z wykonania go przez cały rój są oczywiste dla wszystkich. W przypadku partii politycznej, każdy rozumie korzyści płynące z rejestracji w Biurze Wyborczym; będziesz musiał przygotować podobne zadanie, które prowadzi do takiego celu.

Dzięki temu rój nauczy się współpracować w ciągu pierwszych czterech tygodni swojego istnienia, jednocześnie wykonując zadanie w sposób zdecentralizowany. Powinieneś regularnie, co najmniej raz dziennie, aktualizować ogólny postęp w realizacji zadania.

Organizacja w formie roju nie polega na przesyłaniu raportów między polami schematu organizacyjnego. Rój to ludzie, którzy znają innych ludzi i postanowili pracować razem. Dlatego nadrzędnym celem wszystkich twoich działań na tym etapie powinno być zapoznanie ludzi ze sobą.

Zachęć ludzi do zebrania się razem i wyjaśnij wszystkim, że to nie ma być formalne spotkanie. Za wszelką cenę unikaj formalnych spotkań protokolarnych, a zamiast tego spotykaj się przy piwie, pizzy i dobrej zabawie. Skup się na stwarzaniu innym możliwości poznawania nowych ludzi i spraw, by nowi członkowie grupy czuli się mile widziani.

Kiedy te spotkania będą już regularne, jeszcze ważniejsze będzie, aby nowi uczestnicy czuli się mile widziani. Można to zrobić na przykład w ten sposób, że na początku każdego spotkania każdy przedstawi się krótko i powie coś o sobie, np. co pobrał lub czym się podzielił ostatnim razem: "Cześć, mam na imię Rick i mam 40 lat. Jestem znany głównie z tego, że założyłem brzydką stronę internetową. Ostatnio pobrałem instalator Ubuntu Linux." To bardzo pomaga nowym, gdy wszyscy się przedstawiają, a także jest to świetna zachęta dla nich, by się przedstawiali, tak by stali bywalcy pamiętali ich imiona. Ponadto liderzy rejonu będą musieli zwracać szczególną uwagę na nowo przybyłych na każde spotkanie i osobiście witać ich z powrotem na następnym spotkaniu.

Cała organizacja składa się wyłącznie z relacji międzyludzkich. Za każdym razem, gdy powstaje nowa relacja, organizacja się rozrasta.

Cała organizacja składa się tylko z relacji międzyludzkich.

JAK PRZETRWAĆ POCZĄTKOWY SZOK

Kiedy Twoja inicjatywa trafi na podatny grunt i będzie na tyle interesująca, że wywoła rozgłos, rozgłos ten nie będzie podobny do niczego, co widziałeś wcześniej. Może się to zdarzyć na wiele sposobów - cała sprawa może się rozprzestrzeniać jako marketing szeptany, może pojawić się jako duży artykuł w starych mediach lub najczęściej trafi na pierwszą stronę sieci społecznościowej (lub kilku takich sieci jednocześnie).

Kiedy to się stanie, przejdziesz od samotności do grona setek ludzi, którzy w wolnym czasie będą chcieli pomóc ci w twoim projekcie. Ale ich uwaga nie będzie trwać długo; musisz reagować. Jeśli się nie odezwiesz, po prostu wzruszają ramionami i zapominają o projekcie w czasie krótszym niż dwadzieścia cztery godziny.

Aby zatrzymać te setki osób, musisz zaoferować im jakiś punkt zaczepienia - coś prostego, wystarczy strona rejestracyjna lub forum. Oczywiście, ten punkt musi być gotowy do pracy, w momencie kiedy zaczniesz, inaczej stracisz wielu aktywistów.

Mówi się, że jednym z najtrudniejszych kroków, jakie można podjąć w trakcie prowadzenia działalności gospodarczej jest zatrudnienie pierwszego pracownika i rozwój firmy z jednej osoby do dwóch. W przypadku roju wszystko dzieje się w zupełnie innej skali. Tutaj przechodzimy od jednej osoby - ciebie jako założyciela - do trzystu lub więcej w krótkim czasie.

Nie trzeba dodawać, że może to być dość skomplikowane i masz co najwyżej dwadzieścia cztery godziny, aby opanować sytuację lub stracisz szansę na zbudowanie roju wokół swojego pomysłu. Co gorsza, nie masz szans zrobić tego sam. Po prostu nie masz szansy, aby udzielić sensownych instrukcji trzystu osobom, zanim stracą zainteresowanie.

Na szczęście rój może to zrobić za ciebie, jeśli mu na to pozwolisz. I to jest to, co musisz zrobić.

Pierwszym zadaniem roju będzie samoorganizacja, a w tym jest naprawdę dokonały. Ale to ty musisz stworzyć strukturę i wyraźnie dać zadanie rojowi, aby się zorganizował.

To właśnie tutaj częściowo wkracza tradycyjna teoria organizacji.

Początkowo możesz koordynować nie więcej niż trzydzieści grup, więc stwórz forum dyskusyjne z nie więcej niż taką ilością podrozdziałów. Prawdopodobnie będziesz chciał, aby ludzie agitowali na rzecz celów twojego roju na ulicach tak szybko, jak to możliwe, więc opłaca się podzielić rój według obszarów geograficznych i podzielić na nie więcej niż trzydzieści obszarów. (Większość krajów jest administracyjnie podzielona na hrabstwa, stany itp. Jeśli planujesz założyć ruch ogólnoeuropejskiego, zauważysz, że cała Unia Europejska, łącznie z kilkoma otaczającymi ją krajami, zmieści się w limicie trzydziestu państw. Gorzej jest ze Stanami Zjednoczonymi, bo one składają się w sumie z 50 stanów, a więc cała Ameryka Północna jest problemem. Po prostu wybierz jakiś sposób na podzielenie jej na nie więcej niż trzydzieści części).

Twoje forum dyskusyjne może przybierać różne formy. Może to być tradycyjne forum internetowe, może to być wiki, może to być etherpad, może to być jakikolwiek rodzaj przestrzeni masowej współpracy, gdzie ludzie mogą przychodzić bez zaproszenia i od razu wkraczać do akcji. Ja wolę tradycyjne forum, ponieważ jego zasady są dobrze znane.

Musisz również oszacować wielkość grup na podstawie liczby zarejestrowanych osób. Postaraj się tak dobrać rozkład geograficzny, aby typowa grupa liczyła około siedmiu członków, a żadna grupa nie miała więcej niż trzydzieści osób. Nie ogłaszaj jednak tego, bo doprowadzi to do niepotrzebnej dyskusji: po prostu ułóż grupy tak, aby utworzyć taki podział.

Jeśli podczas pierwszej fali dołączy do was ponad tysiąc osób, co może się zdarzyć, to trzydzieści grup po trzydzieści osób nie wystarczy: taka struktura może pomieścić maksymalnie 30×30=900 osób. W tym rzadkim przypadku trzeba będzie przekroczyć limit trzydziestu osób na grupę i w niektórych grupach umieścić nawet do 150 osób. Jest to jednak rzadki przypadek i prawdopodobnie nie będziesz musiał się z nim zmagać.

(Magiczne liczby siedem, trzydzieści i 150 są głęboko zakorzenione w ludzkim myśleniu społecznym - są częścią naszego wrodzonego programowania. O tym, jak ludzie zachowują się w tak dużych grupach, porozmawiamy w następnym rozdziale).

Po ustaleniu początkowej struktury, musisz powiedzieć wszystkim, aby udali się do swoich grup i poznali innych członków. Powiedz im, aby przedstawili się sobie nawzajem i wybrali lidera dla całej grupy. Na razie możesz spokojnie pominąć instrukcje dotyczące wyboru lidera; każda grupa wymyśli swój własny sposób, z których każdy będzie miał legitymację w swojej grupie, i nic innego nie ma w tym momencie znaczenia.

Nie ma wątpliwości, że niektóre podgrupy będą chciały ruszyć do przodu i poznać wszystkie odpowiedzi na pytania dotyczące życia, wszechświata i wszystkiego - ale w tym momencie priorytetem jest stworzenie podstawowej struktury, która umożliwi dalsze wchłanianie kolejnych aktywistów do roju. Nie powinieneś jednak mówić ludziom, którzy szarżują do przodu, żeby się wstrzymali i czekali (więcej o tym w dalszych rozdziałach); po prostu upewnij się, że liderzy zostaną wybrani.

Kiedy grupy wybiorą już swoich liderów, skontaktuj się z nimi osobiście - w formie rozmowy telefonicznej lub wideokonferencji, ale najlepiej przy piwie lub kawie, jeśli mieszkacie blisko siebie - przedstaw się i poznaj ich nieco lepiej. Wkrótce będziesz z nimi blisko współpracował, więc powinieneś poznać ich jako ludzi i kolegów, a jednocześnie pozwolić im poznać ciebie jako osobę i współpracownika.

Następnie należy założyć subforum, w którym liderzy grup będą mogli dyskutować między sobą i z tobą. Pozwól innym przeczytać tę sekcję. Nie próbuj niczego ukrywać; zamiast tego pozwól innym obserwować stopniowy wzrost twojego roju.

Proces ten potrwa kilka dni, ale pozwoli uruchomić rój na wszystkich poziomach. W końcu będziecie mieli małe grupy entuzjastów, którzy mieszkają w miarę blisko siebie i mają pełnoprawnych przywódców - przynajmniej z ich punktu widzenia. Ty i trzydziestu liderów tworzycie początkową piramidę zespołu zarządzającego w strukturze oficerów, ludzi kontaktowych roju. Wasze grupy razem dokładnie pokrywają całą przestrzeń, którą chcecie zająć.

(Po kilku tygodniach okaże się, że będziesz musiał dodać pośrednią warstwę oficerów pomiędzy tobą a tymi trzydziestoma liderami - kilku liderów straci zainteresowanie i przestanie się meldować, a ty tego nie zauważysz, ponieważ nie możesz śledzić tak wielu osób, chyba że oni sami się u ciebie zameldują. Tak więc w miarę jak rój będzie się rozrastać, będziesz musiał dodać warstwę pośrednią pięciu lub sześciu osób pomiędzy tobą a trzydziestoma osobami. Ale nie martwcie się o to na tym etapie - to temat na kolejny rozdział, a ten pojawi się już za kilka tygodni).

ROZDZIAŁ DRUGI

Założenie roju

Założenie stada to burzliwy moment, w którym setki lub tysiące nowych współpracowników mogą dołączyć do ciebie w mniej niż jeden dzień. W bardzo krótkim czasie musisz okazać im swoją wdzięczność za zainteresowanie, bo inaczej znowu je stracą.

Ok, więc masz prowokacyjny pomysł. Zrobiłeś obliczenia. Wszystko wygląda na gotowe do pracy. Jak więc zgromadzić rój wokół tego pomysłu?

Tradycyjne podejście polegałoby na przyciągnięciu uwagi za pomocą kampanii reklamowej. Ale jeśli chcesz założyć rój, powiem ci trzy słowa o prowadzeniu kampanii reklamowej: zapomnij o tym. Jeśli twój pomysł nie wzbudza entuzjazmu sam w sobie, to żadna ilość reklam nie zmieni was w oddolnych aktywistów, których potrzebujesz, aby założyć rój.

Z drugiej strony, aby utworzyć rój, wystarczy zaproponować pomysł, który jest na tyle atrakcyjny, że ludzie mogą i chcą w nim uczestniczyć. Nie musisz wydawać dziesięciu milionów na kampanię reklamową. Możesz po prostu wspomnieć o tym pomyśle mimochodem na jakimś zaściankowym kanale czatu.

Jestem pewien, że ludzie zajmujący się tradycyjnym marketingiem uważają to za absurd. Ale właśnie w ten sposób stworzyłem markę, która obecnie jest rozpoznawalna w branży IT na całym świecie i jest obecna w ponad 70 krajach.

Kiedy założyłem Partię Piratów w Szwecji, uruchomiłem stronę internetową partii i napisałem dwie linijki na głównym czacie serwera wymiany plików. Miało to miejsce 1 stycznia 2006 roku o godzinie 20:30 CET.

Spójrz, Partia Piratów uruchomiła stronę internetową w nowy rok.
http://www.piratpartiet.se/

Strona miała surowy i nieoszlifowany manifest, ale wydawała się wiarygodna, osiągalna, zachęcała ludzi do udziału i obiecywała zmianę świata. Sama strona była równie prymitywna i pozbawiona wodotrysków - co jest typowe dla procesu prób i błędów w roju, najpierw tworzysz surowy fundament, a potem na nim budujesz:

I to wszystko. Te dwie linijki zapowiadające mało estetyczną stronę to cała promocja, jaką zrobiłem. W ciągu następnych dwóch dni stronę odwiedziło trzy miliony użytkowników. (Szwecja ma dziewięć milionów mieszkańców). Nawet media szybko to podchwyciły. Na całym świecie. Trzeciego dnia moje zdjęcie znalazło się w pakistańskiej gazecie.

Twój pomysł musi być konkretny, możliwy do zrealizowania, ambitny i zachęcać innych do udziału.

Chodzi mi o to, że jeśli zastanawiasz się, jak zgromadzić wokół swojego pomysłu cały rój, nie martw się o promocję.

Szeptanie jest o wiele bardziej skuteczne niż jakakolwiek kampania reklamowa, ale aby to zrobić, twój pomysł - a raczej jego prezentacja - musi spełniać cztery warunki: musi być konkretny, musi być osiągalny, musi zachęcać do uczestnictwa i musi być ambitny.

Konkretny: Musisz opublikować podział na zadania oraz kiedy i jak planujesz je wykonać.

Osiągalny: po przedstawieniu swojego śmiałego celu, musisz przedstawić go jako wyraźnie osiągalny. Jeśli nikt nie zrobił tego przed tobą, dostaniesz dodatkowe punkty.

Zachęcający do uczestnictwa: Twój pomysł musi umożliwiać zaangażowanie wszystkich zainteresowanych nim odbiorców, dla których będzie to oczywiste od razu po usłyszeniu o projekcie.

Ambitny: Na koniec, musisz postawić sobie za cel zmienić cały świat na lepsze - lub przynajmniej sprawić, by życie dla wielu ludzi stało się znacznie atrakcyjniejsze.

Jeśli Twój pomysł przejdzie przez te cztery punkty, rój wyłoni się sam. Dość szybko, sądząc po około 20 przypadkach, które widziałem osobiście. Bardzo szybko. I odwrotnie, jeśli te cztery składniki nie są wystarczająco dobre, żadna ilość marketingu czy krzykliwych reklam nie przyciągnie armii wolontariuszy, których potrzebujesz.

Przyjrzyjmy się kilku przykładowym projektom. Widziałem mnóstwo przykładów wszystkich trzech typów.

PRZYKŁAD ZŁEJ PROPOZYCJI PROJEKTU
O rany, zaczynam nowy projekt t0talnie po to, żeby się z tego cieszyć!!!11!!!jeden!!!sześć!!!11 lololol. Jak to zrobić?

INNY RÓWNIE ZŁY PRZYKŁAD
Staramy się osiągnąć synergię pomiędzy zorientowanymi na wyniki działaniami związanymi z dynamicznym wywiadem biznesowym i konkurencyjnymi mediami społecznościowymi. W szczególności poszukujemy ścieżki opłacalnego sukcesu w przewidywalności jakości i statycznej satysfakcji klienta mierzonej liczbą wykorzystanych kuponów i otrzymanych poleceń. Środkiem do osiągnięcia synergii będzie dążenie do interakcji z docelowymi konsumentami - respondentami w zakresie komunikacji społecznej pomiędzy markami oraz ze studenckimi grupami zawodowymi w celu zbadania potencjalnych przychodów z tworzenia sieci. Projekt ma na celu zwiększenie kwartalnego zysku brutto nawet o dwa procent.

LEPSZY PRZYKŁAD
Wypowiemy politykom ogólnoświatową wojnę, w odpowiedzi na toczoną przez nich ofensywę przeciwko anonimowości w sieci, uruchamiając milion anonimizujących węzłów wyjściowych TOR-a i wprowadzając klienta TOR-a do podstawowej instalacji przeglądarek używanych przez co najmniej 25 procent użytkowników na całym świecie.

Zrobimy to w siedmiu etapach, zwiększając liczbę węzłów wyjściowych TOR pięciokrotnie co sześćdziesiąt dni. Uczestnicy każdego etapu zobowiążą się do zwerbowania pięciu swoich znajomych do kolejnego etapu i zmieniania świata. Zapewnimy globalną rozpoznawalność w sieci dla najlepszych współpracowników.

W połowie projektu, w czwartym etapie, przekonamy twórców Firefoksa i Chrome do wbudowania klienta TOR w ich przeglądarki. Jeśli to zostanie zrealizowane i opublikowane w piątym etapie, każdy, kto tego chce, może być całkowicie  anonimowy.

Zmieniajmy świat na lepsze i sprawmy, by zacofani politycy nie mogli wsadzić dżina z powrotem do butelki. Chcesz wziąć udział w pierwszym etapie? Zapisz się TUTAJ (link).

Teraz musimy wrócić do samych celów. Chcemy zgromadzić dziesiątki tysięcy pełnych pasji aktywistów wokół idei zmieniania świata. Sam pomysł nie wystarczy; pomysł i konkretny plan muszą napełniać ludzi entuzjazmem.

Więc nie martw się o promocję. Wspomnij o swoim pomyśle i planie w kilku miejscach, w których zazwyczaj gromadzą się potencjalni aktywiści. To w zupełności wystarczy. Jeśli pomysł jest dobry, ludzie podchwycą go i opowiedzą o nim swoim znajomym. Teraz rozprzestrzeni się jak lawina. Ale jeśli sam pomysł nie wzbudzi w ludziach ekscytacji, żadna ilość reklam tego nie zmieni.

Jeśli Twój pomysł jest wartościowy, ludzie mogą się zaangażować, zmienić świat i widzą jasną ścieżkę do celu, wtedy będziesz miał pierwszą falę setek wolontariuszy w mniej niż jeden dzień. W mediach elektronicznych, w których ogłaszasz swoją obecność, setki ludzi wyciągnie do ciebie rękę, uniesie dłoń i powie: "Tutaj, użyj moich rąk! Chcę być częścią tego projektu! Daj mi coś do zrobienia!"

Twój pomysł nie musi być wyszukany. Najważniejsze to zrobić pierwszy krok, zacząć rekrutować ludzi i ruszyć w kierunku swojego celu. Jeśli zwrócisz większą uwagę na polerowanie pomysłu, a nie jego zalet, może to przynieść efekt odwrotny do zamierzonego, ponieważ ludzie będą wtedy postrzegać twój pomysł jako korporacyjny chwyt.

To prowadzi nas do kolejnego problemu: jak zająć się tymi setkami ludzi, póki są jeszcze zainteresowani. Wszyscy oni skontaktują się z Tobą osobiście, a po prostu nie jest w twojej mocy, abyś fizycznie był w stanie udzielić im wszystkim instrukcji.

WIĘC MASZ PROWOKACYJNY POMYSŁ?

Prawdopodobnie czytasz tę książkę, ponieważ masz w głowie jeden lub więcej prowokacyjnych pomysłów i szukasz sposobu na ich realizację. Więc tutaj zaczyna się nudna część ich realizacji: czy zrobiłeś obliczenia?

We wszystkich rojach chodzi o ilość. Ilość osób. Podobnie jak w przypadku mrówek z puszczy amazońskiej, chodzi o to, by przytłoczyć przeciwnika przewagą liczebną poprzez lepszą zdolność do organizowania i ukierunkowania energii ochotników - twoja sprawność organizacyjna może sprawić, że zawsze będziesz o wiele potężniejszy od swoich przeciwników, kiedykolwiek i gdziekolwiek zdecydujesz się stawić im czoła, tak jak mrówki przytłaczają swoich przeciwników dzięki zdolności do szybkiego kierowania i przemieszczania swojej lokalnej przewagi liczebnej.

Jest to więc pierwsza przeszkoda, którą musi pokonać twój pomysł. Czy ten pomysł angażuje wystarczająco dużo ludzi i czy wystarczająco dużo z nich będzie wystarczająco entuzjastycznych, aby przyczynić się do pokonania masy krytycznej? Czy można określić tę masę krytyczną, a jeśli tak, to ile osób musi się przyłączyć, aby twój pomysł odniósł sukces?

Jak widać, w tym miejscu robi się nieco tradycyjnie. Musimy określić kryterium sukcesu dla tego pomysłu. Jakie wydarzenie stanowi sukces i co należy zrobić, aby go osiągnąć?

Dla nowej partii politycznej, jaką jest szwedzka Partia Piratów, kryterium sukcesu jest łatwe do zdefiniowania: bycie wybranym. Oczywiście na drodze do tego celu trzeba zrobić wiele małych kroków, a po jego osiągnięciu jeszcze wiele innych (np. utrzymać się w parlamencie). Jest to jednak konkretny cel, nad którym można pracować.

Przyjrzyjmy się teraz, na jakim byliśmy etapie.

Potrzebowalibyśmy wartościowych działaczy i dużej liczby wyborców. Polityka to w końcu tylko gra liczbowa. Jest to sport uprawiany dla widzów.

W przypadku Partii Piratów, wymiana plików dostarczyła nam danych o liczbie zwolenników. W 2006 roku w Szwecji około 1,2 miliona obywateli - wyborców - dzieliło się kulturą i wiedzą z naruszeniem monopolu praw autorskich, nie widzieli w tym nic złego, a władza państwowa aktywnie ich za to prześladowała.

Aby zostać wybranym do parlamentu, potrzeba 225 000 głosów. Oznacza to, że gdyby choć jedna czwarta tak prześladowanych ludzi zdenerwowała się na tyle, by sprzeciwić się takiemu traktowaniu, Partia Piratów dostałaby się do parlamentu. To był nasz cel, który ogłosiliśmy na naszej stronie internetowej już pierwszego dnia: 225,000 głosów. To było realistyczne, osiągalne, każdy mógł się zaangażować i zmieniło by to świat.

Oczywiście inne czynniki społeczne odegrały rolę w tym sporze, a wspólnym mianownikiem była swoboda wypowiedzi oraz wolność w Internecie. Ale kiedy zaczynasz mówić o abstrakcyjnych pojęciach, zanudzasz swoich potencjalnych wolontariuszy na śmierć. Aby rój urósł do masy krytycznej, będziemy potrzebowali jak najszerszego zasięgu rekrutacji i pomysłów, które ludzie będą mogli łatwo odnieść do swojego codziennego życia.

Po dołączeniu do roju, aktywiści będą starali się dokładnie zrozumieć te idee. Jest to niezbędne. Ogólny wymiar przesłania roju musi być na tyle duży, aby przyciągnąć wystarczającą liczbę osób i tym samym osiągnąć sukces.

Twój pomysł musi dać się w ten sposób przełożyć na liczby. Ile osób potrzeba do osiągnięcia sukcesu na minimalnym poziomie zaangażowania, który odpowiada oddaniu głosu w wyborach, kupieniu produktu lub podpisaniu petycji?

Musisz zidentyfikować grupę ludzi, na których twój prowokacyjny pomysł będzie miał pozytywny wpływ, oszacować wielkość tej grupy i zgadnąć, ilu ludzi z tej grupy może dołączyć do roju choćby na minimalnym poziomie aktywności.

Ale pamiętajmy, o jakich rzędach wielkości liczby osób mówimy. W jednym roju są zazwyczaj setki tysięcy, a czasem miliony ludzi. Są tysiące ludzi, którzy pomagają organizacji w swoim wolnym czasie, a może - tylko być może - jedna lub dwie osoby koordynują to wszystko w pełnym wymiarze godzin.

Oczywiście, aby odnieść sukces, twój rój może wymagać zaangażowania znacznie mniejszej liczby osób niż milion. Musisz o tym wiedzieć. Ale przynajmniej musisz oszacować te liczby tak dokładnie, jak to tylko możliwe.

To trudne, bo najdokładniejsze prognozy są wszystkim na czym możesz polegać. Na przykład Partia Praw Kobiet w Szwecji - już teraz jednym z najbardziej równouprawnionych krajów na świecie - ma potencjał, by dotrzeć do połowy wszystkich wyborców. Ale czy w ogóle możliwe jest zmobilizowanie wystarczającej liczby ludzi wokół idei jeszcze większej równości płci? (Niektórzy próbowali, ale okazało się to niemożliwe).

Dla porównania, w 2009 roku, trzy lata po założeniu, szwedzka Partia Piratów otrzymała 225 915 głosów w wyborach do Parlamentu Europejskiego, zdobywając dwa mandaty parlamentarne. Moje pierwotne szacunki, mówiące o 225 tysiącach głosów, spełniły się więc dokładnie.

Dlatego w dalszej części książki przyjrzymy się z bliska twojemu pomysłowi na utworzenie roju i porozmawiamy o tym, co trzeba zrobić, aby go zrealizować, tak jak w przypadku szwedzkiej Partii Piratów, która zrobiła to z powodzeniem i zaczęła zmieniać świat.

Po pierwsze, przyjrzymy się momentowi założenia roju i zobaczymy, jak trudny może on być, omówimy, jak zorganizować strukturę koordynatorów - oficerów - tak, aby rój mógł zająć cały obszar, który planujesz zdobyć. Omówimy techniki i procedury dotyczące samego roju, w tym tak praktyczne kwestie jak rozdawanie ulotek i jak nauczyć ludzi robić to skutecznie.

Przyjrzymy się również szczegółowo temu, jak zarządzać codziennymi operacjami roju - będziemy potrzebować jednej części klasycznego zarządzania projektami, jednego dużego kawałka doświadczenia w rozwiązywaniu sporów i jednej części procedur utrzymywania celów, kultury i wartości organizacji w miarę jej rozwoju.

Na koniec przyjrzymy się, jak wykorzystać powstały w ten sposób rój do osiągnięcia wielkich, zmieniających świat rezultatów oraz co się stanie, gdy odniesiesz zbyt duży sukces.

Ale najpierw, wróćmy do tego prowokacyjnego pomysłu, który masz w głowie i przedyskutujmy, jak zacząć go realizować.

1 stycznia 2006 r., godz. 20:30 czasu środkowo europejskiego.

Podczas przerwy świątecznej, w wolnym czasie, pracowałem nad stroną internetową Pirate Party. Jutro będzie normalny dzień pracy i pierwszy dzień nowego roku dobiega końca. Kończę część strony będącą w trakcie tworzenia, zastępuje wszystko co niedokończone etykietą "W przygotowaniu" i wrzucam stronę do Internetu.

Po uruchomieniu tej prymitywnej strony, postanowiłem dyskretnie zwrócić na nią uwagę opinii publicznej. Aby sprawdzić teren, wszedłem na główny czat serwera wymiany plików Ancient Spirit, gdzie rzadko bywam, i napisałem dwie linijki:

"Spójrz, Partia Piratów uruchomiła stronę internetową w nowy rok.
http://www.piratpartiet.se/"

Kiedy zajrzałem na serwer, zobaczyłem pierwszą falę odwiedzających, którzy przyszli natychmiast po tym, jak zamieściłem swoje dwie linijki na czacie, może kilkanaście osób. Potem zaczęła napływać druga fala gości, zaalarmowana o mojej inicjatywie przez kogoś z pierwszej fali. Zaczęły napływać pierwsze elektroniczne podpisy popierające formalną rejestrację partii. Po trzydziestu podpisach i kolejnych dwóch godzinach doszedłem do wniosku, że powinienem być zadowolony z takiego początku, zrobiłem kopię zapasową i poszedłem spać by juro iść do pracy.

Z dnia na dzień, wszystko się wydało i zainteresowanie wzrosło, a ja nic o tym nie wiedziałem.

Następnego dnia, 2 stycznia, poszedłem normalnie do pracy i nie minęło wiele godzin poranka, gdy na liście mailingowej Mensy, na którą się zapisałem, przeczytałem wiadomość: "Czy my przypadkiem nie znamy tego Ricka Falkvinge'a, o którym piszą dziś gazety?".

Zamrugałam z niedowierzaniem. Czekaj, co? "Kto jest dziś w gazetach?"

RÓJ JEST OTWARTY...

Cechą wyróżniającą rój jest otwartość na wszystkich ludzi, którzy chcą uczestniczyć w zadaniach. Właściwie jest to coś więcej niż tylko otwartość - wszyscy ludzie z całego świata są zaproszeni do wybierania zadań z publicznej listy i rozpoczynania ich realizacji bez pytania kogokolwiek o zgodę. Nie ma procedury rekrutacji. Każdy, kto chce przyczynić się do osiągnięcia celu na swój sposób i w miarę swoich możliwości, ma do tego prawo. Stanowi to wyraźny kontrast w stosunku do procesu rekrutacji w tradycyjnych organizacjach, gdzie ludzie muszą zdać jakiś egzamin przed rozpoczęciem pracy.

Zaletą tego podejścia jest to, że zasoby roju nie są marnowane na stawianie barier, aby utrzymać ludzi na zewnątrz, ale są wykorzystywane do angażowania nowych ludzi. Przyznaję, że jeśli nikt nikomu nie mówi, co ma robić, to kilka osób będzie dublować pracę nad tym samym zadaniem - ale w rezultacie powstanie kilka różnych rozwiązań, które będą wypróbowywane niezależnie od siebie, a rój szybko nauczy się, które z nich działają, a które nie. Praca będzie wtedy wykonywana poprzez iteracyjny, ewolucyjny proces prób i błędów, stale dostosowując się i ulepszając bez konieczności nadzorowania przez kogokolwiek.

Otwartość i życzliwość w stosunku do nowo przybyłych jest kluczową cechą roju.

…I JAWNY

Rój jest nie tylko otwarty, jego cechą charakterystyczną jest przejrzystość. Nie ma w nim praktycznie żadnych tajemnic. Dla osób wywodzących się z tradycyjnych organizacji może to być zdumiewająca koncepcja.

Wszystko jest domyślnie przejrzyste. Dokumentacja księgowa jest publicznie dostępna dla każdego. Dyskusje na temat strategii i taktyki są publiczne i dostępne dla wszystkich (i każdy może w nich uczestniczyć). Spory są rozstrzygane na oczach opinii publicznej. A to dlatego, że wszystkie dyskusje odbywają się w miejscach, gdzie wszyscy mogą je zobaczyć.

To zapewnia wzajemne zaufanie. Ponieważ każdy może przeczytać wszystkie informacje i dyskusje z całej organizacji, tworzy to bardzo silne poczucie przynależności.

Zapewnia to również bardzo skuteczną ochronne przed plotkami. Jest to szczepionka przeciwko nieufności, ponieważ nieufność wymaga braku informacji, a ludzie wyciągają własne wnioski z niepełnych danych.

Co więcej, przejrzystość skutecznie zapobiega skandalom: w szwedzkiej Partii Piratów kilkakrotnie zdarzyło się, że media dowiedziały się o konflikcie i próbowały nadać mu sensacyjny charakter, który zatopiłby normalną organizację - ale ponieważ każdy czytający artykuły mógł sięgnąć bezpośrednio do źródła i przeczytać oryginalną rozmowę, nie było żadnych plotek typu "on powiedział to, ona powiedziała tamto". Kiedy wszystko jest tak przejrzyste, kontrowersje nie wymykają się spod kontroli.

Oczywiście, nie oznacza to, że każda debata przy kawie czy piwie musi być nagrywana. Byłoby to zbyt pracochłonne, a i tak nie dałoby się tego wyegzekwować. Oznacza to jednak, że ludziom nie uniemożliwia się dostępu do informacji, które są dostępne dla innych ludzi - tak więc, gdy dyskusje są prowadzone online, są one rejestrowane i możliwe do odczytania.

"Strzeżcie się tych, którzy odmówiliby wam dostępu do informacji, ponieważ w swoich umysłach uważają się za waszych panów".
— Komisarz Pravin Lal

W nielicznych przypadkach, gdy coś jest utajnione, jest to w interesie ochrony prywatności członków roju i każdy może łatwo dowiedzieć się, jakie konkretne informacje są utajnione - a co ważniejsze, dlaczego są utajnione i kto je zna.

Przykładem uzasadnionej tajemnicy w roju może być tożsamość darczyńców, w celu ochrony ich i uniknięcia konfliktu interesów, ponieważ ludzie staraliby się, świadomie lub nieświadomie, zadowolić najbardziej hojnych darczyńców, zamiast realizować główne cele organizacji. Osoba odpowiedzialna za konto bankowe znałaby tożsamość darczyńców, ale byłaby zobowiązana zachować ją dla siebie.

Wreszcie, pełna przejrzystość eliminuje problem tradycyjnych struktur hierarchicznych, w których, jeśli każde ogniwo w łańcuchu dowodzenia stanowi barierę informacyjną, ktoś pośrodku może świadomie lub nieświadomie przekłamywać informacje przekazywane w jedną lub drugą stronę. Dzięki temu, że wszystkie informacje są dostępne dla wszystkich, nikt nie ma możliwości zniekształcenia ich przed częścią organizacji. Podobnie w stadzie, nikt nie mówi za innych, bo każdy może mówić za siebie. Zapobiega to tworzeniu się frakcji, ponieważ nie ma tradycyjnych menedżerów średniego szczebla, którzy mogliby wyznaczać własne cele, sprzeczne z celami reszty roju.

CZĘŚĆ I
ZBUDOWAĆ RÓJ

ROZDZIAŁ PIERWSZY

Zrozumieć rój

W tej chwili, gdzieś, luźno powiązana grupa aktywistów skutecznie roznosi bogatą, ustabilizowaną organizację doprowadzając ją do szaleństwa, i świetnie się przy tym bawi. Bogate organizacje z dużą ilością zasobów są przyzwyczajone do życia według złotej zasady - "kto ma złoto, ten ustala zasady". Nowe sposoby organizowania się nie tylko łamią stare zasady, ale wręcz rozrywają je na strzępy - zaskoczeni menedżerowie po prostu gapią się w osłupieniu, jak banda biednych, niechlujnych, niezorganizowanych aktywistów pokonuje ich bogatą, dobrze zarządzaną organizację.

W dniu 7 czerwca 2009 r. szwedzka Partia Piratów zdobyła 225 915 głosów w wyborach do Parlamentu Europejskiego, stając się najbardziej popularną partią w najbardziej pożądanej grupie demograficznej poniżej trzydziestki. Cały budżet naszej kampanii wynosił 50 000 euro. Nasi konkurenci wydali 6 mln euro. Wydaliśmy mniej niż 1 procent ich budżetu, a i tak ich pokonaliśmy, co oznacza ponad dwa rzędy wielkości lepszy stosunek jakości do ceny. Wszystko to zawdzięczamy działaniu w formie roju, a praktyki te można zaadaptować do niemal każdej zorganizowanej działalności na dużą skalę. Ta książka opisuje nasz sekretny przepis.

Organizacja w stylu roju to zdecentralizowana grupa współpracujących ze sobą wolontariuszy, która z zewnątrz wygląda jak tradycyjna organizacja hierarchiczna. U jego narodzin leży mała centralna grupa, która tworzy szkielet osób kontaktowych, umożliwiając w ten sposób dużej liczbie ochotników współpracę nad wspólnym celem w liczbie, która po prostu nie była osiągalna przed pojawieniem się Internetu.

Praca z rojem wymaga robienia wielu rzeczy zupełnie odwrotnie niż uczy się tego w typowych szkołach biznesu. Musisz zrezygnować z kontroli nad swoją marką i jej promocją. Musisz oddać władzę do tego stopnia, że w zasadzie każdy może podjąć prawie każdą decyzję dla całej organizacji. Musisz zaakceptować i wykorzystać fakt, że ludzie w organizacji będą robić to, co chcą robić, a jedynym sposobem, aby ich poprowadzić, będzie zainspirowanie ich do tego, aby chcieli iść tam, gdzie ty chcesz zabrać organizację jako całość.

Tylko wtedy, gdy zrezygnujesz z kontroli, tej samej kontroli, której organizacje i menedżerowie trzymali się przez wieki, możesz w pełni wykorzystać zalety roju: tę samą efektywność kosztową i błyskawiczne działanie, które szwedzka Partia Piratów miała nad swoimi konkurentami. Ta książka nauczy cię tych praktyk, od samego założenia roju, poprzez jego rozwój i bieżące utrzymanie, aż po osiąganie wyników. Nie znajdziesz tu teorii psychologii czy socjologii, która leży u podstaw tego wszystkiego - tylko doświadczenia i praktyki, które sprawdziły się w praktyce.

Kiedy założyłem rój Szwedzkiej Partii Piratów, umieściłem krótki manifest na dość brzydkiej stronie internetowej i tylko raz wspomniałem o linku do niego na czacie w serwisie wymiany plików. To była cała promocja, następnego dnia impreza liczyła setki aktywistów. Najważniejszy jest czas, kontekst wiadomości i społeczny - ale jeśli masz wszystkie trzy, twój początkowy rój będzie przyciągał jak pszczoły do miodu w ciągu kilku godzin. Ważne będzie również dalsze jego utrzymywanie i rozbudowywanie, ale to kolejne zadanie. Przejdziemy przez wszystkie zadania w kolejności.

Opisując koncepcję roju, myślisz o całkowicie zdecentralizowanych, mglistych grupach ludzi, takich jak Anonymous czy ruch Occupy Wall Street. Ale podczas gdy te roje podzielają wartości, nie podzielają kierunku ani praktyk. Dlatego ich sukcesy są ograniczone do małych projektów angażujących stosunkowo niewielką liczbę osób w stosunkowo krótkim czasie, mimo że każdy taki mały projekt stopniowo buduje świadomość marki Anonymous i Occupy.

Słaba spójność marek Anonimowych i Occupy może być częściowo przypisana ich decyzji o działaniu bez liderów. Chociaż to dało im odporność, ponieważ ich przeciwnicy nie mogą atakować żadnego lidera, stracili kierunek i cele. Z mojego doświadczenia wynika, że zaangażowanie znane ze społeczności internetowych w połączeniu z silnym przywództwem sprawdzają się znacznie lepiej w osiąganiu globalnych zmian niż praca bez liderów pod wspólnym szyldem.

Nauczyłem się niektórych z tych technik podczas mojego szkolenia oficerskiego w armii i nauczyłem się jeszcze więcej poprzez uczestnictwo w wielu społecznościach internetowych. Ale tajemną receptę na sekret efektywności kosztowej roju poznałem dopiero wtedy, gdy połączyłem ze sobą moje oficerskie szkolenie na temat utrzymywania silnych wartości grupowych, zmieszałem je z silnymi wartościami partycypacyjnymi sieci i tanią internetową komunikacją masową oraz dodałem szczyptę doświadczenia w zarządzaniu z czasów gorączki internetowej przełomu wieków.

Era gorączki internetowej była dość szczególna dla menedżerów IT. Jeśli Twoim ludziom nie spodobało się coś, co powiedziałeś na porannym spotkaniu, wymaszerowaliby z budynku z uśmiechem i mieliby nową pracę przed lunchem. Twoja wypłata była dla nich o wiele bardziej zastępowana niż oni byli dla ciebie jako pracownicy. Oni po prostu nie pracowali dla pieniędzy.

Dlatego to doświadczenie można przenieść na pracę z wolontariuszami, gdzie nikt nie pracuje za pieniądze (bo nikt ich nie dostaje). Kluczem jest przywództwo i nagradzanie pozytywnych zachowań.

Prawdopodobnie najważniejszą rzeczą jest to, że w roju zawsze kładzie się nacisk na to, co każdy może zrobić, a nigdy na to, czego nie wolno lub wymaga się od ludzi.

W roju zawsze kładzie się nacisk na to, co każdy może zrobić.

To zupełnie inaczej niż w tradycyjnych korporacjach i instytucjach demokratycznych, gdzie nacisk kładzie się na to, co ludzie muszą robić i jakich granic nie wolno im przekroczyć. Ta różnica jest jednym z powodów, dla których rój może być tak efektywny: każdy może wybrać z listy wartościowych zadań ( które przybliżą rój do celu ) to, co lubi robić cały czas - i nikt nie będzie mówił ludziom, jak należy, a jak nie należy tego robić.

Ludzie inspirują się nawzajem. Aktywiści nie podlegają przełożonym. Ponieważ aktywiści stale komunikują się ze wszystkimi, udane projekty szybko rozprzestrzeniają się na resztę roju. Organizacja wyciąga wnioski z mniej udanych projektów i idzie dalej, nie obwiniając nikogo.

Jeśli chcesz objąć przywództwo w roju, musisz wstać i powiedzieć: "Zrobię X, ponieważ uważam, że dzięki temu osiągnę Y. Każdy, kto chce mi pomóc z X, jest mile widziany." Każdy w roju może to powiedzieć i wszyscy są do tego zachęcani. W ten sposób szybko tworzy się nieformalna, ale bardzo silna struktura przywódcza, w której ludzie wypełniają role maksymalizujące ich wpływ na osiąganie celów roju - wszystko to dzieje się spontanicznie, bez centralnego planowania czy schematów organizacyjnych.

Rój jest prowadzony z pierwszej linii frontu. Kiedy ktoś przejmuje inicjatywę, zazwyczaj dostaje wolną rękę.

Wniosek jest taki, że rój różni się od tradycyjnych organizacji szybkością działania, niemal zerowymi kosztami operacyjnymi i dużą liczbą oddanych wolontariuszy. Z wnętrza roju tradycyjne organizacje i instytucje demokratyczne wydają się działać w ślimaczym tempie. Również dlatego rój może zmienić świat: pod względem jakości i ilości wykonanej pracy oraz efektywności wykorzystania zasobów pozostawia tradycyjne organizacje daleko w tyle.

STRATEGIA ROJU
Rick Falkvinge

To jest wersja 1.2 (pierwsze wydanie, trzecia wersja) książki "STRATEGIA ROJU" (eng. Swarmwise). Różnice w stosunku do pierwszego i drugiego wydania są głównie kosmetyczne.

Możesz kopiować tę książkę do woli i dzielić się jej kopiami z przyjaciółmi i nieznajomymi, pod warunkiem, że podasz autora i nie będziesz ich sprzedawać. W rzeczywistości, dzielenie się kopiami z przyjaciółmi jest nie tylko dozwolone, ale wręcz wymagane. Jeśli książka Ci się spodoba, dlaczego nie miałbyś się nią podzielić z przyjaciółmi?

Formalnie, książka ta podlega monopolowi na kopiowanie do 1 stycznia 2034 roku - dwadzieścia lat po publikacji. W tym czasie jest on publikowany na licencji Creative Commons Uznanie autorstwa - Użycie niekomercyjne 3.0, co oznacza dokładnie to, co napisano powyżej o swobodnym udostępnianiu. Są to te same terminy, które autor zaproponował w swojej poprzedniej książce "The Case for Copyright Reform". Wyłączne prawa handlowe należą do autora przez dwadzieścia lat.
Copyright 2013 Rick Falkvinge
Tłumaczenie 2021 Bernard Pyszkiewicz

"Waszym najcenniejszym kapitałem nie są wasi pracownicy" - powiedziałem dyrektorowi.

"Twoim najcenniejszym zasobem są tysiące ludzi, którzy chcą dla ciebie pracować za darmo, a ty im na to nie pozwalasz".

29 grudnia 2005 roku, po południu, w porze herbaty.

Dzwonię do mojego starego przyjaciela Rickarda "Richie" Olssona, który od dawna zna mojego ducha przedsiębiorczości. Dawno temu dzieliliśmy nawet mieszkanie, gdzie praktycznie codziennie musiał znosić moje szalone pomysły. Mam nowy pomysł i chcę, żeby on pierwszy się o nim dowiedział i przedstawił mi swoją opinię.

"Hej, Richie, pamiętasz ten projekt, który był wielką sensacją jakiś czas temu? Zastanawiam się nad czymś. Mam w przygotowaniu nowy projekt, który ma potencjał, aby przyciągnąć dużo uwagi - więcej niż, powiedzmy, Pirate Bay."

Z drugiej strony rozległo się głębokie westchnienie.

"Co tym razem znowu wpadło ci do głowy?".

Poniżej umieszczam tłumaczenie na polski by być może po opracowaniu na jego podstawie podcast/filmu uczynić idę ROJU rozpoznawalną wśród piratów w Polsce.

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

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.

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.

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.

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.

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.

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.

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.

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.

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