Hur skapades Linux? Processerna bakom hanteringen av 13 500 utvecklare

Du har förmodligen använt Linux idag – särskilt om du inte har en iPhone. Och om du surfar på webben idag är chansen stor att den webbplats du besökte också serverades av Linux.

Linux är ett operativsystem, men till skillnad från programvaror som Microsoft Windows och macOS utvecklades Linux av ett självorganiserat samhälle av frivilliga.

Med tiden har Linuxkärnan med hjälp av mer än 10 000 utvecklare och utvecklande processer för att hantera omfattningen av arbetet vuxit till sammanlagt mer än 20 000 000 000 rader kod. Den utgör den stabila grunden för…

• Alla Android-telefoner och surfplattor på planeten
• 66% av världens servrar
• 100% av de 500 främsta superdatorerna

Den här tekniken kom inte från ett orkestrerat team med en tjock policysamling och flera ledningsnivåer. Den kom från ett fåtal noggrant utvalda och kulturellt förankrade riktlinjer och ett gemensamt uppdrag.

I det här inlägget tittar jag på hur en teknik som är så väsentlig, komplex och viktig kan ha producerats så effektivt utan traditionell ledningsstruktur. Men först…

Varför är Linuxkärnan så imponerande?

En kärna är själva kärnan i ett operativsystem. Det är orkestratorn för alla andra mjukvaruprocesser på din dator eller smartphone, som delar upp resurserna och tillhandahåller ett sätt för hårdvara och mjukvara att kommunicera.

Med G. Pascal Zacharys ord kan ett operativsystems kärna liknas vid ”en chef för hushållspersonalen som var så flitig att han betjänade familjen uppe på övervåningen när som helst, natt och dag på jour, och hanterade alla förfrågningar”. Kärnan håller maskinen igång, oavsett vad den stöter på. Det var ett viktigt språng från den värld där datorer bara kunde köra ett program i taget till den värld vi känner till idag.

Linuxkärnan, som bygger på UNIX, utvecklades i början av 1990-talet av Linus Torvalds.

1991 hade Torvalds släppt den första versionen – bara 10 000 rader kod – och väckte uppståndelse i mjukvaruutvecklingsgemenskapen med det ödmjuka e-postmeddelande som syns ovan.

Med hjälp av Internets samarbetsförmåga bidrog utvecklare för första gången i historien med sina egna kodningskunskaper och sin testtid gratis, och användarbasen för Linuxkärnan exploderade i storlek. Om de var villiga att experimentera kunde användarna försöka pussla ihop en patch om de upptäckte att något var trasigt och diskutera hur programvaran kunde förbättras.

Som Eric S. Raymond beskriver i sin bok om tidig programvara med öppen källkod, The Cathedral and The Bazaar, växte Linus Torvalds ledning av kärnutvecklare till att bli effektiv, självorganiserande och mer än duglig för att producera en av de mest komplexa och mest använda programvarorna på planeten.

I den här artikeln tittar jag på de processer och riktlinjer som har uppstått som nödvändigt stöd för Linuxkärnprojektet när det har utvecklats under åren.

Hur Torvalds, utan formell process, som 21-årig datavetenskapsstudent, styrde kärnprojektet till de höjder det nådde…

…Och vad är det som är så svårt med att leda utvecklare, förresten?

Enligt forskning från Geneca tror över 75 procent av affärs- och IT-cheferna att deras mjukvaruprojekt är dömda att misslyckas. Svårigheten att producera tillförlitlig programvara och hantera dem som gör det har gett upphov till otaliga ledarskapsböcker, produktivitetsstudier och ledarskapsramar.

”Mjukvarans komplexitet innebär att det är omöjligt att testa alla vägar”, skriver Kynetix vd Paul Smyth på Finextra. ”En programvaruapplikation är som ett isberg – 90 procent av den är inte synlig. Den största komplexiteten i applikationen ligger under vattenlinjen.”

Varje mjukvaruprojekt av betydande storlek, oavsett om det är ett CRM eller ett operativsystem som Microsoft Windows, är för stort för att rymmas i en enda persons huvud. Det kräver delad kunskap och samarbete från många bidragsgivare. Detta innebär att utvecklarna arbetar med specialiserade delar av applikationen samtidigt som de måste förstå hur deras arbete påverkar helheten.

”No one mind can comprehend it all”, anmärkte chefen för ett team med 250 Microsoft-programvaruutvecklare när de byggde ett operativsystem från grunden, enligt G. Zachary i Show stoppers!, en bok som berättar historien om ett team av Microsofts mjukvaruutvecklare som tävlade om att färdigställa Windows NT 1993.

Jo större projektet är, desto långsammare kan förändringar genomföras. Forskning från Steve McConnell bevisar detta och visar att kod skrivs 5-10 gånger långsammare i projekt med mer än 10 000 000 rader. Vidare visade en studie av Microsofts utvecklingsrutiner att det finns ungefär 10-20 buggar för varje 1 000 rader kod.

Trots projektets storlek och antalet bidragsgivare sker utvecklingen av Linuxkärnan snabbt och dess stora, entusiastiska användarbas fångar upp buggar och skriver patchar för att snabbt leverera förbättringar.

Under de tidiga utvecklingsdagarna – runt 1991 – var det inte ovanligt att Torvalds släppte mer än en ny kärna per dag. Nu, i ett mer moget skede och med 80 procent av smarttelefonerna och majoriteten av internetservrarna, är den önskade utgivningsperioden 8-12 veckor. Varje utgåva får kärnan se i genomsnitt 10 000 patchar från 2 000 utvecklare – alla brottas med över 20 000 000 rader kod.

Vilka förvaltningstekniker och processer krävs för att orkestrera denna nivå av samarbete och produktivitet? Tja, de har inte skrivits upp av en avdelningschef eller en affärsboksförfattare. De utvecklades organiskt, med vägledning från projektets ”välvilliga diktator”, Linus Torvalds.

Även i sin begynnande form samarbetade hundratals frivilliga med Linuxkärnan och lämnade in sitt arbete direkt till Torvalds för granskning. Hur hanterade en dåligt stämd, asocial hackare tvister, bidrag och kommunikation mellan tusentals utvecklare i nästan två decennier?

Hur policy, process och 15 000 000 rader kod dokumenteras

Till skillnad från en traditionell organisation blir nya utvecklare av kärnan inte strikt ”onboarded” in i gemenskapen utan förväntas i stället ha läst och förstått den inledande dokumentationen till fullo. Kärnprojektets fokus på dokumentation var en nödvändighet både på grund av den tekniska komplexiteten och det stora antalet utvecklare.

Enormt många FAQ:s, how-tos och guider för att komma igång finns i kärnans dokumentationsarkiv, och ännu fler i wikis som skapats och underhålls av kärnutvecklare runt om i världen.

Det sätt på vilket dokumentationen skrivs och förbättras återspeglar det sätt på vilket kärnan utvecklas; i samarbete, öppet och stegvis.

Då dokumentationen kan skapas, testas och korrekturläsas mycket effektivare genom att utnyttja ögonen och specialiseringarna hos en stor grupp människor, än om den görs av ett mindre, dedikerat team. För att böja Linus lag i termer som en innehållsredaktör kanske bättre förstår: med tillräckligt många ögon är alla stavfel uppenbara.

Som material för tekniskt stöd har kärnutvecklingsgemenskapen skapat ett bibliotek med processdokumentation som är utformad för att underlätta den mänskliga sidan av samarbetet.

På indexsidan för ”A guide to the Kernel Development Process” står det i ett stycke:

”Syftet med det här dokumentet är att hjälpa utvecklare (och deras chefer) att arbeta med utvecklingsgemenskapen med ett minimum av frustration. Det är ett försök att dokumentera hur denna gemenskap arbetar på ett sätt som är tillgängligt för dem som inte är intimt bekanta med utveckling av Linuxkärnan (eller, faktiskt, utveckling av fri programvara i allmänhet).”

Ingen föds med en medfödd kunskap om versionshanteringssystemet git, eller hur man skickar in en patch till en sändlista. Det är därför utvecklingsprocessen måste dokumenteras – att förklara samma grundläggande information för en person i taget är inte skalbart!

Hur kommunikationen mellan 1000-tals utvecklare hanteras

Samtalen mellan utvecklare skedde ute i det fria, i sändlistorna för kärnutveckling. Än idag är e-post fortfarande det föredragna verktyget på grund av dess enkelhet. Dessa sändlistor arkiverades och organiserades och utgjorde en samling levande dokumentation och historia.

Effekten av att kommunicera offentligt har en effekt som liknar fördelarna med att använda ett verktyg som Slack i dag – all information görs säker och sökbar, i stället för att förångas. För att hantera en sådan brandslang av information utvecklade dock kärnprojektet en kommunikationspolicy och distribuerade den som en del av dokumentationen.

Kommunikation och samarbete i en sådan skala var inte möjligt före internet, så tidiga projekt som detta behövde skriva och distribuera snabba och effektiva lösningar för problem med community management, etikett och kodpresentation.

Kärndokumentationen innehåller regler för hur man skickar in patchar, så att det blir lättare för andra att granska, redigera och testa bidragande kod. Detta innebär att patchar måste skickas via e-post i ren text, inte som bifogade filer. Patchar måste hållas till en gång per e-post och följa specifika riktlinjer för kodningsstil:

Denna rigida standardisering är absolut nödvändig för ett så stort projekt som kärnan, liksom det är för projekt av alla storlekar. Den bidrar till att minska fel i ett utrymme där ett enda fel kan ha en spridningseffekt som ger instabil kod i framtiden, eller slösar tid på många testare och utvecklare.

Hur kritiska beslut (inte) fattas

För att citera Torvalds:

”The name of the game is to avoid having to make a decision. Särskilt om någon säger till dig ”välj (a) eller (b), vi behöver verkligen att du bestämmer dig för detta” är du illa ute som chef. De personer som du leder måste känna till detaljerna bättre än du, så om de kommer till dig för att fatta ett tekniskt beslut är du körd. Du är uppenbarligen inte kompetent att fatta det beslutet åt dem.” – Dokumentation för utveckling av Linuxkärnan

Som att undvika en chefshierarki hade Linuxprojektet tydliga regler och dokumentation som hjälpte till att fatta beslut utan att det behövdes diskussioner, debatter eller (många) flamkrig på e-postlistor. En titt i arkiven kommer att visa att flamkrigsdelen inte alltid är möjlig, men det som är möjligt är att skapa en policy som förnekar beslutsbördan.

”Nyckeln till att undvika stora beslut blir alltså att bara undvika att göra saker som inte kan göras ogjorda. Låt dig inte föras in i ett hörn som du inte kan fly från. En råtta i ett hörn kan vara farlig – en chef i ett hörn är bara ömklig.”

Show Stoppers! avslöjar att Bill Gates filosofi är liknande. Han ”beundrade programmerare och gav dem undantagslöst ansvaret för projekt, där de kunde både leda och programmera för att undvika en situation där professionella chefer, med antingen ingen programmeringserfarenhet eller föråldrad kunskap, hade makten”.

Hur bidragsgivarna är orienterade kring ett starkt gemensamt mål

I fallet Linux, som det är med många populära projekt med öppen källkod, uppstod inte kärnan efter att ha utformats i samarbete av en stor grupp bidragsgivare, utan den förbättrades snarare stegvis utan att man fattade beslut som destabiliserade den starka basen av arbetet så långt. Detta stämmer väl överens med Torvalds filosofi om beslutsfattande i ledningen, men också med en filosofi som är inbäddad i själva koden.

Linux bygger på UNIX, som är ett tidigare operativsystem som utformades kring en uppsättning zen-liknande principer. Som uttryckligen anges i UNIX-filosofin:

”Utforma och bygga programvara, även operativsystem, för att kunna prövas tidigt, helst inom några veckor. Tveka inte att kasta bort de klumpiga delarna och bygga om dem.”

Både Torvalds och Raymond (som försökte replikera framgången med Torvalds’ samhällsbyggande) fann att ett tidigt och ofta släppt projekt hjälpte till att samla bidragsgivarna kring ett spännande, växande projekt som de kan se en framtid i. Raymond kokade ner det till två viktiga saker som ett projekt inte får misslyckas med när det släpps ut i världen:

1. Run
2. Övertyga potentiella medutvecklare (användare) om att projektet kan utvecklas till något stort snart

Det är med samma principer som många av dagens nystartade företag startar – Process Street inkluderat:

Ovanför är Process Street år 2014. Registrera dig för ett konto för att se hur långt vi har kommit.

Är detta en process som kan upprepas?

Ovanpå ytan verkar det plötsliga sammanfogandet av en av de mest intrikata mänskliga skapelserna som alkemi. Men genom att plocka isär komponenterna är det lättare att se en underliggande process. När Eric S. Raymond skrev The Cathedral and The Bazaar drev han samtidigt utvecklingen av en e-postklient med öppen källkod. Genom att använda öppen källkod försökte Raymond replikera det samhällsengagemang och den slutliga framgången för kärnprojektet.

Många av de grundläggande principerna i Bazaarmodellen, som han myntade den, kommer omedelbart att vara bekanta för alla i den nystartade världen:

• Varje bra programvaruverk börjar med att klia på en utvecklares personliga klåda.
• Att behandla användarna som medutvecklare är den enklaste vägen till snabba kodförbättringar och effektiv felsökning.
• Släpp ut tidigt. Släpp ofta. Och lyssna på dina kunder.
• Genom en tillräckligt stor bas av betatestare och medutvecklare kommer nästan alla problem att karakteriseras snabbt och lösningen att vara uppenbar för någon.
• Om du behandlar dina betatestare som om de är din mest värdefulla resurs kommer de att reagera genom att bli din mest värdefulla resurs.
• Näst bästa sättet att ha goda idéer är att känna igen goda idéer från dina användare. Ibland är det senare bättre.
• Ofta kommer de mest slående och innovativa lösningarna från att du inser att din uppfattning om problemet var fel.
• För att lösa ett intressant problem, börja med att hitta ett problem som är intressant för dig.
• Förutsatt att utvecklingssamordnaren har ett kommunikationsmedel som är minst lika bra som Internet och vet hur man leder utan tvång är många huvuden oundvikligen bättre än ett.

Kort sagt är det en process som kan upprepas. Och en som med framgång har övertagits från världen av öppen källkod till startup-mentaliteten. Den manifesteras i agila, lean, six sigma och de attityder och den politik som startups idag har utvecklat. Även om det inte ofta nämns i samma konversation har den metodik som utvecklades kring tidiga operativsystem mycket gemensamt med dagens idé om att iterera på en minimum viable product.