Ge ut tidigt, ge ut ofta

Tidiga och frekventa utgåvor är en kritisk del i Linux utvecklingsmodell. De flesta utvecklare (jag med) trodde att detta var en dålig princip för större projekt än trivialt små. Detta eftersom tidiga versioner nästan per definition är behäftade med fel, och man ju inte vill fresta på användarnas tålamod. Detta tänkesätt befäste en allmän anslutning till katedralbyggarstilen. Om det överskuggande målet är att användarna skall se så få buggar som möjligt, då ger man ut en ny version var sjätte månad eller så och sliter som en hund inför utgåvorna. Emacs C kärna utvecklade på detta sätt. Men inte Lisp biblioteket, eftersom det fanns aktiva Lisp arkiv utanför FSFs kontroll, där man kunde hitta nyutvecklad kod oberoende av Emacs utgåvocykler. [QR].

Det viktigaste av dessa, 'the Ohio State elisp archive', föregrep andan och många av egenheterna i dagens stora Linuxarkiv. Men inte många av oss tänkte då så mycket på detta och på att blotta existensen av dessa arkiv antydde problem med FSFs katedralbyggarstil till utvecklingsmodell.

Jag försökte omkring 1992 få en stor del av Ohio-koden formellt inkorporerad i Emacs officiella Lisp biblioteket. Men jag stötte på svårigheter av politisk natur och misslyckades.

Ett år senare, när Linux började synas lite varstans, stod det klart att något annat och med större livskraft pågick därute. Linus öppna utvecklingsfilosofi var något helt annorlunda än katedralbyggande. Linux internetarkiv började blomma ut, många distributioner flöt omkring. Och allt detta drevs med en utgåvofrekvens som ingen dittills ens hade hört talas om.

Linus behandlade sina användare som medutvecklare på bästa tänkbara sätt.

7. Ge ut tidigt. Ge ut ofta. Och lyssna till dina kunder.

Linus innovation var kanske inte så mycket att göra snabba utgåvecykler och att ta till sig återkoppling från användarna, (sådant hade länge varit tradition inom Unix-världen), men att skala detta till en intensitetsnivå som matchade komplexiteten i det som han utvecklade. I början, omkring 1991, var det inte otänkbart för honom att ge ut en ny linuxkärna mer än en gång om dagen! Eftersom han gödde sin bas av medutvecklare och utnyttjade Internets kommunikationspotential till gränsen, så fungerade detta.

Men hur fungerade det? Och var det något jag kunde ta efter, eller berodde det på någon unik begåvning hos Linus Torvalds?

Jag trodde inte det. Det skall erkännas att Linus är en suverän hackare. Hur många av oss skulle kunna konstruera ett helt operativsystem med produktions-kvalitet utifrån nästan ingenting? Men Linux var inget jättekliv framåt vad avser fundamentalt nytänkande. Linus är inte (eller, inte ännu) ett innovativt geni på samma sätt som t.ex. Richard Stallman eller James Gosling (för NeWS och Java) är. Snarare verkar Linus mer vara genialisk i konsten att implementera, med ett sjätte sinne för att undvika buggar och återvändsgränder, och med speciell förmåga att hitta lättaste vägen mellan A och B. Ja, faktiskt, hela Linux konstruktion andas denna egenskap och avspeglar Linus konservativa och förenklande sätt att konstruera.

Så om snabb utgivning och utnyttjande av Internet till det yttersta inte var tillfälligheter utan var väsentliga delar av Linus ingenjörsmässiga insikt om den lättaste vägen, vad var det som han lyckades maximera? Vad var det som han vevade fram ur maskineriet?

Med frågan så ställd, besvarar den sig själv. Linus höll sina hackare/användare ständigt stimulerade och belönade - stimulerade av känslan att vara delaktiga, belönade av att deras arbete ledde framåt. Linus kunde på så sätt maximera antalet mantimmar som ägnades åt avlusning och utvecklingsarbete, även om det skedde med risk för instabil kod och att användarna brände ut sig om någon allvarlig felaktighet skulle visa sig vara omöjlig att rätta till. Linus betedde sig som om han trodde så här:

8. Med tillräckligt många betatestare och medutvecklare blir varje problem kvickt identifierat och dess lösning blir alltid självklar för någon.

Eller med andra ord:

"Med tillräckligt många ögon, blir alla buggar synliga" Jag dubbar detta till "Linus Lag".

Min ursprungliga formulering av detta var att varje problem "kommer att vara uppenbart för någon". Linus invände att den person som förstår och löser problemet inte nödvändigtvis, ja till och med inte vanligtvis, är den person som först formulerar det. "någon hittar problemet," säger han, "och någon annan förtår det. Och jag blir bemärkt för att säga att hitta det är den stora utmaningen." Men grejen är den att båda sakerna tenderar att ske snabbt.

Här har vi, tänker jag, kärnpunkten som skiljer katetralbyggar- och basarmodellen. I katedralbyggarens syn på programmering är buggar knepiga, lömska och djupa fenomen. Det tar månader av granskning av ett antal utvalda kvalificerade experter för att man skall känna tilltro till att alla fel är borta. Alltså långa intervall mellan utgåvorna och en oundviklig besvikelse när det visar sig att den länge efterlängtade utgåvan trots allt inte är perfekt.

Basarmodellens utgångspunkt, å andra sidan, är den att buggar och fel är ytliga fenomen - eller, åtminstone, att de kvickt blir ytliga när de exponeras inför tusentals ivriga medutvecklare som hänger på låset inför varje ny utgåva. Följaktligen ger man ut ofta i syfte att få många korrigeringar, och som sidoeffekt så har man inte så mycket att förlora även om det skulle hända att ett och annat klantverk smiter ut.

Och det är grejen. Det räcker. Om "Linus lag" är fel, så skulle varje system så komplicerat, och där så många fingrar har petat, som Linuxkärnan, vid något tillfälle ha kollapsat under trycket av oförutsedda dåliga kopplingar och oupptäckta "djupa" fel. Om det är sant, å andra sidan, kan det förklara Linux relativa frihet från buggar och dess tillförlitlighet med månader och år mellan haverierna.

Men det kanske inte är någon stor överraskning. Sociologer har sedan länge observerat att medelvärdet av uppfattningen hos ett stort antal observatörer av lika expertis (eller lika okunniga) är bra mycket mer tillförlitligt än uppfattningen hos en enda slumpvis utvald observatör. De kallar detta för "Delphi effekten". Det verkar som om Linus har visat att detta är tillämpligt även då det gäller att avlusa ett operativsystem. Att Delphi effekten kan tämja komplexiteten på den nivå som utvecklingen av kärnan i ett operativsystem kräver.

En speciell egenhet i Linuxfallet som klart hjälper upp situationen vid sidan om Delphieffekten är att de som deltar i ett givet projekt själva väljer att deltaga. Bidragen kommer inte från slumpvist utvalda människor, utan från sådana som är tillräckligt intresserade för att använda programvaran, lära sig hur den fungerar, försöka hitta svar på problem de stöter på och att i praktiken få fram en rimlig lösning. En som passerar alla dessa filter har sannolikt möjlighet att bidra med något användbart.

Jag är tack skyldig min vän Jeff Dutky (dutky@wam.umd.edu) för hans påpekande att Linus lag kan formuleras: "Avlusning är parallelliserbart". Jeff noterar, att även om avlusningsarbetet kräver att deltagarna kommunicerar med en koordinator, så krävs ingen omfattande kommunikation mellan deltagarna. De blir alltså inte offer för någon kvadratisk komplexitets- och ledningskostnad, som eljest kan göra det problematiskt att lägga till fler medutvecklare.

Den teoretiska effektivitetsförlusten med att avlusningsarbetet dubbleras tycks i praktiken inte vara något problem i Linuxvärlden. En konsekvens av 'ge-ut-tidigt-och-ofta-metoden' är att dubbelarbetet minimeras genom att rättade buggar återkopplas snabbt [JH].

Även Brooks (författaren till "The Mythical Man-Month") gjorde en iakttagelse av samma slag som Jeffs. "Kostnaden att underhålla ett program med stor spridning är typiskt 40 procent eller mer av utvecklingskostnaden." Märkvärdigt nog påverkas den starkt av antalet användare. "Fler användare hittar fler fel."

Fler användare hittar fler buggar därför att fler användare betyder fler sätt att belasta programmet. Detta gäller speciellt om användarna är medutvecklare. Var och en närmar sig problemet med sitt eget annorlunda sätt att tänka och med sina egna verktyg. Han får sitt eget perspektiv på problemet. "Delphi effekten" verkar fungera med precision just på grund av denna variation. När det gäller att avlusa program tenderar denna variation kompensera den förlust som orsakas av dubbelarbete.

Så att lägga till fler betatestare måhända inte minskar svårighetsgraden i den knepigaste buggen som utvecklaren ser den, men det ökar sannolikheten att någons verktyg råkar stämma med problemet och att felet på så sätt blir enkelt just för honom.

Men Linus garderar sig också. Skulle det hända att det finns allvarliga fel, så är Linuxkärnans versioner numrerade så att användaren kan välja om han vill använda den senaste stabila versionen, eller om han vill köra en utvecklingsversion på frontlinjen och riskera att stöta på problem med nya finesser. Denna taktik används ännu inte av alla Linux hackare, även om de kanske borde göra det. Det faktum att båda möjligheterna finns gör dem också båda mer attraktiva [HBS].