Časné a časté publikování vykonané práce patří ke kritickým částem vývojového modelu Linuxu. Většina vývojářů, včetně mne, dříve věřila, že je to špatný postup pro všechny větší projekty, protože prvé verze mají téměř určitě řadu chyb a vy nechcete pokoušet trpělivost svých uživatelů.

Tato víra posilovala obecnou důvěru ve styl stavění katedrál. Pokud bylo základní podmínkou, aby uživatelé viděli co nejméně chyb, pak je nejlepší publikovat maximálně jednou za půl roku a dřít do úmoru na odstraňování chyb v mezidobí. Emacs C byl vyvíjen tímto způsobem. Lisp knihovny ale vznikaly rozdílně. Jednalo se o aktivní archivy mimo kontrolu FSF, ve kterých jste mohli nalézt nové a experimentální verze i v obdobích, kdy samotný Emacs nebyl publikován.

Nejdůležitější z těchto archívů, Ohio state elisp archív, vykazoval ducha a mnoho rysů dnešních velkých Linuxových archívů. Ale jen málo z nás tehdy opravdu důsledně přemýšlelo o tom, co děláme, nebo o tom, co samotná jejich existence naznačovala o problémech modelu stavitelů katedrál, který FSF využíval. V roce 1992 jsem se vážně pokoušel zahrnout velkou část Ohio archívu do oficiální Emacs Lisp knihovny, ale narazil jsem na řadu politických problémů a tento pokus byl z velké části neúspěšný.

Ale během roku, jak se Linux stával známým, bylo jasné, že probíhá něco jiného a mnohem zdravějšího. Linusova otevřená vývojová politika byla přesným protikladem výstavby katedrál. Sunsite a tsx-11 archívy překypovaly, byla rozšiřována řada distribucí. A to vše doprovázela předtím nevídaná frekvence publikací nových verzí jádra systému.

Linus jednal se svými uživateli jako se spolupracovníky tím nejefektivnějším způsobem

7. Publikuj brzy. Publikuj často. A naslouchej svým zákazníkům.

Linusova inovace nespočívala ani tak v tom, že něco podobného dělal (to už mělo dlouhou tradici ve světě Unixu), ale v tom, že celý proces převedl do rozměrů a složitosti samotného Linuxu. V této ranné epoše (okolo roku 1991), byly běžné publikace nového jádra i několikrát denně. Protože si kultivoval svoji základnu spolupracovníků a využíval Internet pro spolupráci více než kdokoliv jiný, tak vše pracovalo.

Ale jak to všechno mohlo pracovat? A bylo to něco, co jsem já sám mohl kopírovat nebo vše spočívalo na nenapodobitelné genialitě Linuse Torvalda?

Já si to nemyslel. Je pravda, že Linus je zatraceně dobrý programátor, vždyť kolik z nás by dokázalo vytvářet celé jádro operačního systému v produkční kvalitě? Ale Linux nepředstavoval žádný ohromný koncepční skok vpřed. Linus není, tedy alespoň zatím, inovační genius designu, takový, jako je třeba Richard Stallman nebo James Gosling (NeWS, Java). Linus má spíše inženýrský génius, má šestý smysl pro obcházení chyb a slepých uliček, má opravdový cit pro nalezení nejméně namáhavé cesty z bodu A do bodu B. Ovšem, celkový design Linuxu v sobě nese tuto kvalitu a odráží Linusův ve své podstatě konzervativní a zjednodušující přístup.

Takže, pokud rychlé publikování a využívání Internetu nebylo náhodné, ale představovalo integrální součást Linusova inženýrského genia pro nalezení nejsnažší cesty, co se snažil maximalizovat? Co dostával z celého soustrojí?

Pokud je otázka položena takto, sama nabízí odpověď. Linus udržoval své uživatele/spoluautory neustále stimulované a odměňované. Stimulované tím, že mají neustále před sebou nějakou uspokující práci, odměňované tím, že vidí neustálá (dokonce denní) vylepšení své práce.

Linus se pokoušel maximalizovat počet hodin, které jsou věnovány na odstraňování chyb a na rozvoj, ačkoliv hrozilo možné riziko nestability kódu a vyhoření uživatelské báze, pokud by se nějaká vážná chyba ukázala neodstranitelnou.Linus se choval tak, jako by věřil v něco jako:

8. Pokud máte dostatečně velkou základnu spolupracovníků a testovatelů, téměř každý problém bude rychle charakterizován a jeho řešení bude pro někoho jednoduché

Nebo, méně formálně "Pokud máte dostatek očí, všechny chyby jsou průhledné". Já to nazývám Linusovým zákonem.

Má původní formulace tohoto jevu zněla: každý problém bude pro někoho řešitelný. Linus ovšem upozornil, že člověk, který problému porozuměl a vyřešil ho, nemusí být a většinou nebývá ten, kdo jej první charakterizoval. Linus říká: "Někdo nalezne problém a někdo jiný mu rozumí. A já dokonce tvrdím, že nalézt problém je náročnější". Důležité ale je, že nalezení i vyřešení většinou proběhne rychle.

V tom je, myslím, základní rozdíl mezi stylem stavitelů katedrál a stylem tržiště. Z pohledu stavitelů katedrál, programové chyby a vývojové problémy jsou náročné a komplikované jevy. Trvá měsíce pečlivého zkoumání několika zasvěcených, než získáte jistotu, že jste vše vyhladili. Proto dlouhé intervaly mezi publikacemi a nevyhnutelná zklamání, že dlouho očekávaný program není zdaleka dokonalý.

Z pohledu tržiště naopak předpokládáte, že chyby jsou obvykle snadno řešitelné, nebo alepoň, že se takovými rychle stanou, když se na ně zaměří tisíce dychtivých spolupracovníků, nedočkavě očekávajících další verzi. Proto publikujete často, abyste získali více oprav a jako prospěšný vedlejší efekt ztrácíte méně, pokud občas dojde k nějakému problému.

A to je vše. To opravdu stačí. Pokud je "Linusův zákon" nepravdivý, potom jakýkoliv systém tak komplexní, jako je jádro Linuxu, na kterém se spolupodílelo tolik autorů, by se musel v nějaký okamžik zhroutit pod tíhou nepředvídaných špatných interakcí a nenalezených, hluboko ukrytých chyb. Pokud je ale pravdivý, pak postačuje na vysvětlení, proč Linux obsahuje tak málo programových chyb.

A možná by to ani nemělo být takové překvapení. Sociologové již před lety objevili, že průměrný názor velkého množství stejně dobrých (nebo špatných) pozorovatelů je podstatně spolehlivější než názor jakékohokoliv náhodně zvoleného pozorovatele. To se nazývá Delphi efektem. Zdá se, že Linus prokázal, že tento jev se týká i tvorby operačního systému, že Delphi efekt dokáže zkrotit i tak komplexní záležitost, jako je konstrukce jádra OS..

Jsem vděčen Jeffovi Dutky <dutky@wam.umd.edu>, který upozornil na to, že Linusův zákon může být přeložen jako "debugování je paralelizovatelné". Jeff si všiml, že ačkoliv odstraňování chyb vyžaduje, aby jednotliví spolupracovnící komunikovali s nějakým koordinátorem, nevyžaduje významnou spolupráci mezi jednotlivými spolupracovníky. Proto nepadá za oběť kvadratickému zvyšování komplexity a nárokům na administraci, která v jiných případech znesnadňuje zapojení více vývojářů.

Ve skutečnosti se teoretická ztráta účinnosti způsobená duplikací práce nezdá být problémem ve světě Linuxu. Jeden z výsledků časného a častého publikování je fakt, že případné duplikace jsou brzy odhaleny.

Brooks dokonce učinil následující pozorování: "Celková cena údržby běžně používaného programu je okolo 40 % nebo i více z ceny jeho vývoje. Je překvapující, že tato cena je značně ovlivněna počtem uživatelů. Více uživatelů nalezne více chyb.

Více uživatelů nalezne více chyb, neboť s počtem uživatelů přibývá způsobů, kterým jsou programy testovány. Tento efekt je zesílen, pokud se uživatelé zároveň podílejí na vývoji programu. Každý z nich vnímá problémy při detekci chyb z jiného úhlu pohledu. Delphi efekt funguje, jak se zdá, právě díky této rozmanitosti. Ve specifickém kontextu odhalování chyb tento styl rovněž snižuje množství duplikátních činností.

Takže s přibývajícím počtem testovatelů se sice nemusí zmenšit komplexita té nejobtížnější chyby z pohledu vývojáře, ale stoupá šance, že někomu jinému se podaří chybu odhalit.

Linus je také obezřetný. V případě, že se vyskytnou vážné problémy, Linuxové jádro je číslováno takovým způsobem, že potenciální uživatel může buďto používat poslední verzi, která je označena jako stabilní, a nebo sledovat vývoj a mít nové možnosti, ale to vše za cenu rizika chyb v programu. Tuto taktiku ještě neuplatňuje většina Linuxových hackerů, ale asi by měla. Dostupnost obou alternativ přispívá k atraktivitě programu..