Hvordan blev Linux skabt? Processerne bag ledelsen af 13.500 udviklere

Du har sikkert brugt Linux i dag – især hvis du ikke har en iPhone. Og hvis du har surfet på nettet i dag, er der en stor chance for, at det websted, du besøgte, også blev serveret af Linux.

Linux er et styresystem, men i modsætning til software som Microsoft Windows og macOS blev Linux udviklet af et selvorganiseret fællesskab af frivillige.

Med tiden er Linux-kernen med over 10.000 udviklers indsats og udviklende processer til at styre omfanget af arbejdet vokset til i alt over 20.000.000.000 linjer kode. Den danner det stabile fundament for…

• Alle Android-telefoner og -tabletter på planeten
• 66% af verdens servere
• 100% af de 500 største supercomputere

Denne teknologi er ikke kommet fra et orkestreret team med en tyk politikbog og lag af ledelse. Den kom fra nogle få nøje udvalgte og kulturelt indlejrede politikker og en fælles mission.

I dette indlæg ser jeg på, hvordan en teknologi, der er så væsentlig, kompleks og vigtig, kunne være blevet produceret så effektivt uden traditionel ledelsesstruktur. Men først…

Hvorfor er Linux-kernen så imponerende?

En kerne er selve kernen i et styresystem. Det er orkestratoren for alle andre softwareprocesser på din computer eller smartphone, der fordeler ressourcerne og giver hardware og software mulighed for at kommunikere.

Med G. Pascal Zachary’s ord kan et operativsystems kerne sammenlignes med “en chef for husholdningens personale, der var så flittig, at han til enhver tid betjente familien ovenpå, nat og dag på tilkald, og håndterede enhver anmodning”. Kernen sørger for, at maskinen kører, uanset hvad den støder på. Det var et afgørende spring fra den verden, hvor computere kun kunne køre ét program ad gangen, til den verden, vi kender i dag.

Linux-kernen, der er baseret på UNIX, blev udviklet i begyndelsen af 1990’erne af Linus Torvalds.

I 1991 havde Torvalds frigivet den første version – blot 10.000 linjer kode – og udløste begejstring i softwareudviklingsmiljøet med den ydmyge e-mail-meddelelse, der ses ovenfor.

Med hjælp fra internettets samarbejdskraft bidrog udviklerne for første gang i historien med deres egne kodningsevner og testtid gratis, da kernelbrugerbasen eksploderede i størrelse. Hvis de var villige til at eksperimentere, kunne brugerne prøve at stykke en patch sammen, hvis de fandt ud af, at noget var i stykker, og diskutere, hvordan softwaren kunne forbedres.

Som Eric S. Raymond ser på i sin bog om tidlig open source-software, The Cathedral and The Bazaar, voksede Linus Torvalds’ ledelse af kerneudviklere til at være effektiv, selvorganiserende og mere end i stand til at producere et af de nok mest komplekse og mest anvendte stykker software på planeten.

I dette stykke ser jeg på de processer og politikker, der er opstået som nødvendig støtte for Linux-kernelprojektet, efterhånden som det har udviklet sig gennem årene.

Hvordan kunne Torvalds som 21-årig datalogistuderende uden formelle processer styre kerneprojektet til de højder, det nåede…

…Og hvad er der egentlig så svært ved at lede udviklere?

Ifølge en undersøgelse fra Geneca mener over 75 % af erhvervs- og it-cheferne, at deres softwareprojekter er dømt til at mislykkes. Vanskeligheden ved at producere pålidelig software og lede dem, der laver den, har affødt utallige ledelsesbøger, produktivitetsundersøgelser og ledelsesrammer.

“Softwares blotte kompleksitet betyder, at det er umuligt at teste alle veje”, skriver Kynetix’ administrerende direktør Paul Smyth på Finextra. “En softwareapplikation er som et isbjerg – 90 % af den er ikke synlig. Den største kompleksitet i applikationen ligger under vandlinjen”.

Alle softwareprojekter af betydelig størrelse, uanset om det er et CRM eller et operativsystem som Microsoft Windows, er for store til at kunne rummes i en enkelt persons hoved. Det kræver delt viden og samarbejde fra mange bidragydere. Det betyder, at udviklerne arbejder på specialiserede dele af applikationen, samtidig med at de skal forstå, hvordan deres arbejde påvirker helheden.

“No one mind can comprewn it all”, bemærkede lederen af et team på 250 Microsoft-softwareudviklere, mens de var i gang med at bygge et operativsystem fra bunden, ifølge G. Zachary i Show stoppers!, en bog, der fortæller historien om et hold af Microsofts softwareudviklere, der kørte om kap for at færdiggøre Windows NT i 1993.

Jo større projektet er, desto langsommere kan ændringer gennemføres. Det beviser en undersøgelse fra Steve McConnell, der har fundet ud af, at kode skrives 5-10 gange langsommere på projekter på over 10.000.000 linjer. Desuden viste en undersøgelse af Microsofts udviklingspraksis, at der er omkring 10-20 fejl for hver 1.000 linjer kode.

Trods projektets størrelse og antallet af bidragydere sker udviklingen af Linux-kernen hurtigt, og dets store, entusiastiske brugergruppe opfanger fejl og skriver patches for hurtigt at sende forbedringer.

I de tidlige udviklingsdage – omkring 1991 – var det ikke uhørt, at Torvalds udgav mere end én ny kerne om dagen. Nu, i et mere modent stadie, hvor 80 % af smartphones og størstedelen af internetserverne er afhængige af den, er den ønskede udgivelsesperiode 8-12 uger. Hver udgivelse får kernen i gennemsnit 10.000 patches fra 2.000 udviklere – alle kæmper med over 20.000.000 linjer kode.

Hvilke ledelsesteknikker og -processer er nødvendige for at orkestrere et sådant niveau af samarbejde og produktivitet? Tja, de er ikke blevet skrevet op af en afdelingsleder eller en forretningsbogsforfatter. De udviklede sig organisk med vejledning fra projektets “velvillige diktator”, Linus Torvalds.

Selv i sin spæde form blev Linux-kernen udarbejdet af hundredvis af frivillige, som indsendte deres arbejde direkte til Torvalds til gennemsyn. Hvordan håndterede en dårligt stemt, asocial hacker tvister, bidrag og kommunikation mellem tusindvis af udviklere i næsten to årtier?

Hvordan politik, proces og 15.000.000 linjer kode dokumenteres

I modsætning til en traditionel organisation bliver nye kerneudviklere ikke strengt “onboarded” ind i fællesskabet, men forventes i stedet at have læst og forstået den indledende dokumentation fuldt ud. Kernel-projektets fokus på dokumentation var en nødvendighed både på grund af den tekniske kompleksitet og det store antal udviklere.

Der findes utallige FAQ’er, how-tos og vejledninger til at komme i gang i kernens dokumentationsarkiv og endnu flere i wikier, der er oprettet og vedligeholdt af kernel-udviklere over hele verden.

Den måde, som dokumentationen skrives og forbedres på, afspejler den måde, som kernen udvikles på; i samarbejde, åbent og gradvist.

Gennem at udnytte øjnene og specialiseringerne fra en stor gruppe mennesker kan dokumentationen udarbejdes, testes og korrekturlæses langt mere effektivt, end hvis den blev udført af et mindre, dedikeret team. For at bøje Linus’ lov til termer, som en indholdsredaktør måske bedre kan forstå: med nok øjne er alle stavefejl indlysende.

Suden materiale til teknisk support har kerneudviklingsfællesskabet skabt et bibliotek med procesdokumentation, der er designet til at udjævne den menneskelige side af samarbejdet.

På indekssiden af “A guide to the Kernel Development Process” lyder et afsnit:

“Formålet med dette dokument er at hjælpe udviklere (og deres ledere) med at arbejde sammen med udviklingsfællesskabet med et minimum af frustrationer. Det er et forsøg på at dokumentere, hvordan dette fællesskab arbejder på en måde, der er tilgængelig for dem, der ikke er intimt fortrolige med Linux-kerneludvikling (eller faktisk fri softwareudvikling generelt).”

Ingen er født med en medfødt viden om git-versionskontrolsystemet, eller hvordan man indsender en patch til en postliste. Det er derfor, at udviklingsprocessen skal dokumenteres – at forklare de samme grundlæggende oplysninger til én person ad gangen er ikke skalerbart!

Hvordan kommunikationen mellem 1000-vis af udviklere håndteres

Samtaler mellem udviklere foregik ude i det åbne rum, på mailinglisterne for kerneudvikling. Den dag i dag er e-mail stadig det foretrukne værktøj på grund af sin enkelhed. Disse postlister blev arkiveret og organiseret og udgjorde en samling levende dokumentation og historie.

Effekten af at kommunikere offentligt har en effekt, der svarer til fordelene ved at bruge et værktøj som Slack i dag – enhver information bliver gjort sikker og søgbar i stedet for at fordampe. For at kunne håndtere en sådan brandslange af information udviklede kernel-projektet imidlertid en kommunikationspolitik og distribuerede den som en del af dokumentationen.

Kommunikation og samarbejde i en sådan skala var ikke muligt før internettet, så tidlige projekter som dette var nødt til at skrive og distribuere hurtige og effektive løsninger på problemer med fællesskabsstyring, etikette og præsentation af kode.

Kerneldokumentationen indeholder regler for indsendelse af patches, så det bliver lettere for andre at gennemgå, redigere og teste kode, der er bidraget med. Det betyder, at patches skal sendes pr. e-mail i almindelig tekst og ikke som vedhæftede filer. Patches skal begrænses til én gang pr. e-mail og overholde specifikke retningslinjer for kodningsstil:

Denne rigide standardisering er absolut nødvendig for et projekt så stort som kernen, ligesom det er for projekter af enhver størrelse. Den er med til at reducere fejl i et rum, hvor en enkelt fejl kan have en bølgeeffekt, der giver ustabil kode i fremtiden eller spilder mange testeres og udvikleres tid.

Hvordan kritiske beslutninger (ikke) træffes

For at citere Torvalds:

“The name of the game is to avoid to having to make a decision. Især hvis nogen siger til dig: “Vælg (a) eller (b), vi har virkelig brug for, at du beslutter dig for dette”, så er du i problemer som leder. De mennesker, du leder, må hellere kende detaljerne bedre end dig, så hvis de kommer til dig for at få en teknisk beslutning, er du på røven. Du er tydeligvis ikke kompetent til at træffe den beslutning for dem.” – Linux Kernel Development Documentation

Selvom man undgik et ledelseshierarki, havde Linux-projektet klare regler og dokumentation, der hjalp med at træffe beslutninger uden behov for diskussion, debat eller (mange) flame wars på postlister. Et kig i arkiverne vil vise dig, at flame war-delen ikke altid er mulig, men det, der er muligt, er at skabe en politik, der ophæver beslutningsbyrden.

“Således bliver nøglen til at undgå store beslutninger til bare at undgå at gøre ting, der ikke kan gøres om. Lad dig ikke føre ind i et hjørne, som du ikke kan slippe ud af. En rotte i et hjørne kan være farlig – en manager i et hjørne er bare ynkelig.”

Show Stoppers! afslører, at Bill Gates’ filosofi er tilsvarende. Han “beundrede programmører og satte dem uvægerligt til at lede projekter, hvor de både kunne lede og programmere for at undgå en situation, hvor professionelle ledere, der enten ikke havde nogen programmeringserfaring eller havde forældet viden, havde magten”.

Hvordan bidragyderne er orienteret omkring et stærkt fælles mål

I tilfældet Linux, som det er tilfældet med mange populære open source-projekter, opstod kernen ikke efter at være blevet designet i fællesskab af en stor gruppe bidragydere; den blev snarere forbedret gradvist uden at træffe beslutninger, der destabiliserer det stærke grundlag for arbejdet indtil nu. Dette hænger godt sammen med Torvalds’ filosofi om beslutningstagning i ledelsen, men også med en filosofi, der er indlejret i selve koden.

Linux er baseret på UNIX, som er et tidligere styresystem, der er designet omkring et sæt zen-lignende principper. Som det udtrykkeligt fremgår af UNIX-filosofien:

“Design og byg software, selv styresystemer, der skal afprøves tidligt, ideelt set inden for få uger. Tøv ikke med at smide de klodsede dele væk og genopbygge dem.”

Både Torvalds og Raymond (som forsøgte at gentage Torvalds’ succes med at opbygge et fællesskab) fandt ud af, at det at udgive tidligt og ofte var med til at samle bidragyderne om et spændende, voksende projekt, som de kan se en fremtid i. Raymond kogte det ned til to vigtige ting, som et projekt ikke må undlade at gøre, når det frigives til verden:

1. Run
2. Overbevis potentielle medudviklere (brugere) om, at projektet snart kan udvikles til noget stort

Det er med de samme principper, at mange af nutidens startups lanceres – Process Street inkluderet:

Overst ses Process Street i 2014. Tilmeld dig en konto for at se, hvor langt vi er kommet.

Er dette en proces, der kan gentages?

Op overfladen virker den pludselige sammenføjning af en af de mest indviklede menneskelige skabelser som alkymi. Men ved at skille komponenterne ad er det lettere at se en underliggende proces. På det tidspunkt, hvor Eric S. Raymond skrev The Cathedral and The Bazaar, var han samtidig i gang med udviklingen af en open source-e-mailklient. Ved at open source-klienten forsøgte Raymond at gentage kerneprojektets engagement i fællesskabet og dets endelige succes.

Mange af de grundlæggende principper i Bazaar-modellen, som han opfandt den, vil være umiddelbart velkendte for alle i startup-verdenen:

• Alle gode softwareværker starter med at kradse en udviklers personlige kløe.
• Behandle dine brugere som medudviklere er din mindst besværlige vej til hurtig kodeforbedring og effektiv fejlfinding.
• Release tidligt. Udgiv ofte. Og lyt til dine kunder.
• Givet en tilstrækkelig stor base af betatestere og medudviklere vil næsten alle problemer hurtigt blive karakteriseret, og løsningen vil være indlysende for nogen.
• Hvis du behandler dine betatestere som om de er din mest værdifulde ressource, vil de reagere ved at blive din mest værdifulde ressource.
• Det næstbedste ved at have gode ideer er at genkende gode ideer fra dine brugere. Nogle gange er sidstnævnte bedre.
• Ofte kommer de mest markante og innovative løsninger ved at indse, at din opfattelse af problemet var forkert.
• For at løse et interessant problem skal du starte med at finde et problem, der er interessant for dig.
• Så længe udviklingskoordinatoren har et kommunikationsmedie, der er mindst lige så godt som internettet, og ved, hvordan man leder uden tvang, er mange hoveder uundgåeligt bedre end ét.

Kort sagt er det en gentagelig proces. Og en, der med succes er blevet overtaget fra open source-verdenen til startup-mentaliteten. Den manifesterer sig i agile, lean, six sigma og de holdninger og den politik, som startups i dag har udviklet. Selv om det ikke ofte nævnes i samme samtale, deler den metodologi, der udviklede sig omkring tidlige operativsystemer, meget med nutidens idé om at iterere på et minimum viable product.