Ugyanez lazábban: elegendő mennyiségű szem mellett minden hiba jelentéktelenné válik. Ezt nevezem Linus törvényének.

Eredetileg úgy fogalmaztam, hogy minden probléma „világos lesz valaki számára”. Linus közbevetette, hogy általában nem, vagy nem feltétlenül az az ember érti a problémát, és ad rá megoldást, aki először felismeri: „Valaki megtalálja a problémát és valaki más pedig megérti. Fel fogják jegyezni rólam, hogy azt mondtam: ráakadni a nagyobb kihívás”. Ez a kiigazítás fontos, a következő fejezetben, ahol a hibakeresés gyakorlatát vizsgáljuk részletesebben, majd kiderül, hogy miért. A lényeg, hogy a folyamat mindkét része (a felfedezés és a javítás) gyorsan megtörténhet.

Szerintem Linus törvényében testesül meg a katedrálisépítő és a bazári stílus mögött lévő legfontosabb különbség. A programozás katedrálisépítő megközelítésében a hibák és fejlesztési problémák ravasz, alattomos, mély jelenségek. A kiválasztott kevesek hónapokig tartó alapos vizsgálatába kerül eljutni a megbízhatóságnak arra fokára, amikor úgy érzik, kigyomlálták őket. Ezért hosszúak a kiadási ciklusok, és ezért az elkerülhetetlen csalódottság, ha a régóta várt kiadás nem tökéletes.

A bazárban viszont feltételezed, hogy a hibák általában felszíni jelenségek, vagy legalábbis elég gyorsan felszíni jelenséggé válnak az egyes kiadásokhoz kapcsolódó ezernyi lelkes társfejlesztő zsivaja mellett. Éppen ezért gyakran készítesz kiadásokat, hogy még több javítást kapj, és mindez azzal a remek mellékhatással jár, hogy sokkal kevesebbet veszítesz, ha alkalmasint valami tákolmány is kikerül az utcára.

Ennyi. Ez már elég. Ha Linus törvénye hamis, akkor bármilyen rendszer, amely a kernelhez hasonlóan bonyolult, és amelyen annyi kéz dolgozott, mint a kernelen, egy ponton össze kellene, hogy omoljon az előre nem látott hibás interakciók és a felfedezetlen mély hibák súlya alatt. Ha viszont a törvény igaz, akkor megfelelő magyarázat lehet a Linux relatív hibátlanságára és a hónapoktól egészen az évekig ívelő folyamatos üzemelési idejére.

Talán ez nem is kell, hogy meglepetést okozzon. Évekkel ezelőtt szociológusok arra jöttek rá, hogy egyformán képzett (vagy egyformán tudatlan) megfigyelőkből álló csoportok véleményének középértéke sokkal megbízhatóbb előrejelzést ad, mint a véletlenszerűen kiválasztott megfigyelők véleményei. A jelenséget Delphoi-effektusnak nevezték el. Úgy tűnik, hogy Linus Torvalds megmutatta, hogy ez még az operációs rendszerek hibakeresésére is érvényes, hogy a Delphoi-effektus elnyomhatja a fejlesztés bonyolultságát, és még egy operációs rendszer magjának komplexitását is megszelídítheti [CV].

A Linux helyzetének egy speciális sajátossága, amely egyértelműen segíti a Delphoi-effektust, az, hogy a projektek munkatársai önkéntesek. Egy korai olvasóm mutatott rá arra, hogy a munkatársak nem véletlen mintából származnak, hanem olyan emberek, akiket érdekel annyira a szoftver használata, hogy megtanulják hogyan működik, és megpróbáljanak megoldást keresni a felmerülő problémákra, sőt nyilvánvalóan elfogadható javításokat is létrehoznak. Aki átjut ezeken a szűrőkön, annak feltehetően vannak hasznos ötletei, amelyekkel hozzájárulhat a munkához.

Linus törvénye úgy is újrafogalmazható, hogy „a hibakeresés párhuzamosítható”. Noha a hibakeresés megköveteli a hibakeresőktől, hogy valamilyen koordináló fejlesztővel kommunikáljanak, nem követeli meg a jelentős koordinációt a hibakeresők között. Ezért nem is esik áldozatául annak a bonyolultságnak és irányítási költségnek, amely az újabb fejlesztők felvételekor jelentkezik [a zárt kódú projektek esetében].

A hibakeresők által duplán elvégzett munkából származó elméleti veszteség a gyakorlatban szinte soha nem gond a Linux világában. A korai és gyakori kiadás irányelvének egyik hatása, hogy a visszajelzésekből származó javításokkal minimalizálja az ilyen jellegű duplikációt [JH].

Brooksnak (a The Mythical Man-Month szerzőjének) ezzel kapcsolatban még egy spontán megfigyelése is van: „Egy széles körben használt program karbantartásának teljes költsége általában a kifejlesztés költségeinek 40 százaléka vagy még több. Meglepő módon ez a költség erősen függ a felhasználók számától. Több felhasználó több hibát talál.”

Több felhasználó több hibát talál, mert több felhasználó többféle módon veszi igénybe a programot. Ezt a hatást erősíti, ha a felhasználók társfejlesztők is. A hibafelismerést mindegyikük másként közelíti meg, némileg különböző módon érzékelve, más eszközökkel elemezve, más szögből. A Delphoi-effektus úgy tűnik, hogy pontosan ezen változatosság miatt működik. A hibakeresés kontextusában a variáció segít az azonos törekvések többszöri előfordulásának csökkentésében is.

Tehát több bétateszterrel nem csökken az éppen legkomolyabbnak tartott hiba mélysége a fejlesztő szemében, de megnő annak a valószínűsége, hogy lesz olyan személy, akinek a tarsolyában benne van a számára viszont könnyű probléma megoldása.

Linus pedig a legjobbat hozhatja ki a helyzetből: ha valóban komoly hibák vannak benne, akkor a kernelt olyan módon számozzák, hogy a potenciális felhasználók eldönthessék, az utolsó stabil változatnál maradnak, vagy vállalják a hibák kockázatát is az új lehetőségek miatt. Ezt a taktikát még nem minden fejlesztő vette át, de talán így a jó, a tény, hogy mindkét választás elérhető, mindkettőt vonzóbbá teszi [HBS].