Casne a caste publikovani vykonane prace patri ke kritickym castem vyvojoveho modelu Linuxu. Vetsina vyvojaru, vcetne mne, drive verila, ze je to spatny postup pro vsechny vetsi projekty, protoze prve verze maji temer urcite radu chyb a vy nechcete pokouset trpelivost svych uzivatelu.

Tato vira posilovala obecnou duveru ve styl staveni katedral. Pokud bylo zakladni podminkou, aby uzivatele videli co nejmene chyb, pak je nejlepsi publikovat maximalne jednou za pul roku a drit do umoru na odstranovani chyb v mezidobi. Emacs C byl vyvijen timto zpusobem. Lisp knihovny ale vznikaly rozdilne. Jednalo se o aktivni archivy mimo kontrolu FSF, ve kterych jste mohli nalezt nove a experimentalni verze i v obdobich, kdy samotny Emacs nebyl publikovan.

Nejdulezitejsi z techto archivu, Ohio state elisp archiv, vykazoval ducha a mnoho rysu dnesnich velkych Linuxovych archivu. Ale jen malo z nas tehdy opravdu dusledne premyslelo o tom, co delame, nebo o tom, co samotna jejich existence naznacovala o problemech modelu stavitelu katedral, ktery FSF vyuzival. V roce 1992 jsem se vazne pokousel zahrnout velkou cast Ohio archivu do oficialni Emacs Lisp knihovny, ale narazil jsem na radu politickych problemu a tento pokus byl z velke casti neuspesny.

Ale behem roku, jak se Linux staval znamym, bylo jasne, ze probiha neco jineho a mnohem zdravejsiho. Linusova otevrena vyvojova politika byla presnym protikladem vystavby katedral. Sunsite a tsx-11 archivy prekypovaly, byla rozsirovana rada distribuci. A to vse doprovazela predtim nevidana frekvence publikaci novych verzi jadra systemu.

Linus jednal se svymi uzivateli jako se spolupracovniky tim nejefektivnejsim zpusobem

7. Publikuj brzy. Publikuj casto. A naslouchej svym zakaznikum.

Linusova inovace nespocivala ani tak v tom, ze neco podobneho delal (to uz melo dlouhou tradici ve svete Unixu), ale v tom, ze cely proces prevedl do rozmeru a slozitosti samotneho Linuxu. V teto ranne epose (okolo roku 1991), byly bezne publikace noveho jadra i nekolikrat denne. Protoze si kultivoval svoji zakladnu spolupracovniku a vyuzival Internet pro spolupraci vice nez kdokoliv jiny, tak vse pracovalo.

Ale jak to vsechno mohlo pracovat? A bylo to neco, co jsem ja sam mohl kopirovat nebo vse spocivalo na nenapodobitelne genialite Linuse Torvalda?

Ja si to nemyslel. Je pravda, ze Linus je zatracene dobry programator, vzdyt kolik z nas by dokazalo vytvaret cele jadro operacniho systemu v produkcni kvalite? Ale Linux nepredstavoval zadny ohromny koncepcni skok vpred. Linus neni, tedy alespon zatim, inovacni genius designu, takovy, jako je treba Richard Stallman nebo James Gosling (NeWS, Java). Linus ma spise inzenyrsky genius, ma sesty smysl pro obchazeni chyb a slepych ulicek, ma opravdovy cit pro nalezeni nejmene namahave cesty z bodu A do bodu B. Ovsem, celkovy design Linuxu v sobe nese tuto kvalitu a odrazi Linusuv ve sve podstate konzervativni a zjednodusujici pristup.

Takze, pokud rychle publikovani a vyuzivani Internetu nebylo nahodne, ale predstavovalo integralni soucast Linusova inzenyrskeho genia pro nalezeni nejsnazsi cesty, co se snazil maximalizovat? Co dostaval z celeho soustroji?

Pokud je otazka polozena takto, sama nabizi odpoved. Linus udrzoval sve uzivatele/spoluautory neustale stimulovane a odmenovane. Stimulovane tim, ze maji neustale pred sebou nejakou uspokujici praci, odmenovane tim, ze vidi neustala (dokonce denni) vylepseni sve prace.

Linus se pokousel maximalizovat pocet hodin, ktere jsou venovany na odstranovani chyb a na rozvoj, ackoliv hrozilo mozne riziko nestability kodu a vyhoreni uzivatelske baze, pokud by se nejaka vazna chyba ukazala neodstranitelnou.Linus se choval tak, jako by veril v neco jako:

8. Pokud mate dostatecne velkou zakladnu spolupracovniku a testovatelu, temer kazdy problem bude rychle charakterizovan a jeho reseni bude pro nekoho jednoduche

Nebo, mene formalne "Pokud mate dostatek oci, vsechny chyby jsou pruhledne". Ja to nazyvam Linusovym zakonem.

Ma puvodni formulace tohoto jevu znela: kazdy problem bude pro nekoho resitelny. Linus ovsem upozornil, ze clovek, ktery problemu porozumel a vyresil ho, nemusi byt a vetsinou nebyva ten, kdo jej prvni charakterizoval. Linus rika: "Nekdo nalezne problem a nekdo jiny mu rozumi. A ja dokonce tvrdim, ze nalezt problem je narocnejsi". Dulezite ale je, ze nalezeni i vyreseni vetsinou probehne rychle.

V tom je, myslim, zakladni rozdil mezi stylem stavitelu katedral a stylem trziste. Z pohledu stavitelu katedral, programove chyby a vyvojove problemy jsou narocne a komplikovane jevy. Trva mesice pecliveho zkoumani nekolika zasvecenych, nez ziskate jistotu, ze jste vse vyhladili. Proto dlouhe intervaly mezi publikacemi a nevyhnutelna zklamani, ze dlouho ocekavany program neni zdaleka dokonaly.

Z pohledu trziste naopak predpokladate, ze chyby jsou obvykle snadno resitelne, nebo alepon, ze se takovymi rychle stanou, kdyz se na ne zameri tisice dychtivych spolupracovniku, nedockave ocekavajicich dalsi verzi. Proto publikujete casto, abyste ziskali vice oprav a jako prospesny vedlejsi efekt ztracite mene, pokud obcas dojde k nejakemu problemu.

A to je vse. To opravdu staci. Pokud je "Linusuv zakon" nepravdivy, potom jakykoliv system tak komplexni, jako je jadro Linuxu, na kterem se spolupodilelo tolik autoru, by se musel v nejaky okamzik zhroutit pod tihou nepredvidanych spatnych interakci a nenalezenych, hluboko ukrytych chyb. Pokud je ale pravdivy, pak postacuje na vysvetleni, proc Linux obsahuje tak malo programovych chyb.

A mozna by to ani nemelo byt takove prekvapeni. Sociologove jiz pred lety objevili, ze prumerny nazor velkeho mnozstvi stejne dobrych (nebo spatnych) pozorovatelu je podstatne spolehlivejsi nez nazor jakekohokoliv nahodne zvoleneho pozorovatele. To se nazyva Delphi efektem. Zda se, ze Linus prokazal, ze tento jev se tyka i tvorby operacniho systemu, ze Delphi efekt dokaze zkrotit i tak komplexni zalezitost, jako je konstrukce jadra OS..

Jsem vdecen Jeffovi Dutky <dutky@wam.umd.edu>, ktery upozornil na to, ze Linusuv zakon muze byt prelozen jako "debugovani je paralizovatelne". Jeff si vsiml, ze ackoliv odstranovani chyb vyzaduje, aby jednotlivi spolupracovnici komunikovali s nejakym koordinatorem, nevyzaduje vyznamnou spolupraci mezi jednotlivymi spolupracovniky. Proto nepada za obet kvadratickemu zvysovani komplexity a narokum na administraci, ktera v jinych pripadech znesnadnuje zapojeni vice vyvojaru.

Ve skutecnosti se teoreticka ztrata ucinnosti zpusobena duplikaci prace nezda byt problemem ve svete Linuxu. Jeden z vysledku casneho a casteho publikovani je fakt, ze pripadne duplikace jsou brzy odhaleny.

Brooks dokonce ucinil nasledujici pozorovani: "Celkova cena udrzby bezne pouzivaneho programu je okolo 40 % nebo i vice z ceny jeho vyvoje. Je prekvapujici, ze tato cena je znacne ovlivnena poctem uzivatelu. Vice uzivatelu nalezne vice chyb.

Vice uzivatelu nalezne vice chyb, nebot s poctem uzivatelu pribyva zpusobu, kterym jsou programy testovany. Tento efekt je zesilen, pokud se uzivatele zaroven podileji na vyvoji programu. Kazdy z nich vnima problemy pri detekci chyb z jineho uhlu pohledu. Delphi efekt funguje, jak se zda, prave diky teto rozmanitosti. Ve specifickem kontextu odhalovani chyb tento styl rovnez snizuje mnozstvi duplikatnich cinnosti.

Takze s pribyvajicim poctem testovatelu se sice nemusi zmensit komplexita te nejobtiznejsi chyby z pohledu vyvojare, ale stoupa sance, ze nekomu jinemu se podari chybu odhalit.

Linus je take obezretny. V pripade, ze se vyskytnou vazne problemy, Linuxove jadro je cislovano takovym zpusobem, ze potencialni uzivatel muze budto pouzivat posledni verzi, ktera je oznacena jako stabilni, a nebo sledovat vyvoj a mit nove moznosti, ale to vse za cenu rizika chyb v programu. Tuto taktiku jeste neuplatnuje vetsina Linuxovych hackeru, ale asi by mela. Dostupnost obou alternativ prispiva k atraktivite programu..