Hoe is Linux tot stand gekomen? The Processes Behind Managing 13,500 Developers

U hebt vandaag waarschijnlijk Linux gebruikt – zeker als u geen iPhone hebt. En als u vandaag op het web hebt gesurft, is de kans groot dat de website die u hebt bezocht ook door Linux werd bediend.

Linux is een besturingssysteem, maar in tegenstelling tot software als Microsoft Windows en macOS, is Linux ontwikkeld door een zelfgeorganiseerde gemeenschap van vrijwilligers.

In de loop der tijd, met de inzet van meer dan 10.000 ontwikkelaars en evoluerende processen om de omvang van het werk te beheren, is de Linux-kernel uitgegroeid tot meer dan 20.000.000 regels code in totaal. Het vormt de stabiele basis voor…

• Iedere Android telefoon en tablet op de planeet
• 66% van alle servers ter wereld
• 100% van de top 500 supercomputers

Deze technologie is niet ontstaan uit een georkestreerd team met een dik beleidsboek en managementlagen. Het kwam voort uit een paar zorgvuldig gekozen en cultureel ingebedde beleidslijnen, en een gedeelde missie.

In dit bericht kijk ik hoe een technologie die zo essentieel, complex en belangrijk is, zo effectief geproduceerd kon worden zonder traditionele managementstructuur. Maar eerst…

Waarom is de Linux kernel zo indrukwekkend?

Een kernel is de kern van een besturingssysteem. Het is de orkestrator van alle andere softwareprocessen op uw computer of smartphone, het verdeelt de bronnen en biedt een manier voor de hardware en software om te communiceren.

In de woorden van G. Pascal Zachary, kan de kernel van een besturingssysteem worden vergeleken met “een chef van het huishoudelijk personeel die zo ijverig was dat hij de familie boven op elk moment bediende, dag en nacht op afroep, elk verzoek afhandelend”. De kernel houdt de machine draaiende, wat hij ook tegenkomt. Het was een essentiële sprong van de wereld waarin computers slechts één applicatie tegelijk konden draaien, naar de wereld die we vandaag de dag kennen.

De Linux kernel, gebaseerd op UNIX, werd in het begin van de jaren negentig ontwikkeld door Linus Torvalds.

In 1991 had Torvalds de eerste versie vrijgegeven – slechts 10.000 regels code – en de software-ontwikkelingsgemeenschap opgewonden gemaakt met de bescheiden e-mailaankondiging hierboven.

Gemotiveerd door de samenwerkingskracht van internet voor de eerste keer in de geschiedenis, droegen ontwikkelaars hun eigen codeervaardigheden en testtijd gratis bij terwijl de gebruikersbasis van de kernel in omvang explodeerde. Als ze bereid waren te experimenteren, konden gebruikers proberen een patch in elkaar te flansen als ze ontdekten dat iets niet werkte, en konden ze bespreken hoe ze de software konden verbeteren.

Zoals Eric S. Raymond beschrijft in zijn boek over vroege open source software, The Cathedral and The Bazaar, groeide Linus Torvalds’ management van kernelontwikkelaars uit tot een efficiënte, zelforganiserende organisatie die meer dan in staat was om misschien wel een van de meest complexe en wijdst gebruikte stukken software op aarde te produceren.

In dit stuk kijk ik naar de processen en het beleid die zijn ontstaan als noodzakelijke ondersteuning voor het Linux kernel project zoals het zich in de loop der jaren heeft ontwikkeld.

Hoe, zonder formele procedure, als 21-jarige student computerwetenschappen, leidde Torvalds het kernelproject naar de hoogten die het bereikte…

…En wat is er eigenlijk zo moeilijk aan het managen van ontwikkelaars?

Volgens onderzoek van Geneca gelooft meer dan 75% van bedrijfs- en IT-managers dat hun softwareprojecten gedoemd zijn te mislukken. De moeilijkheid van het produceren van betrouwbare software en het managen van degenen die dat doen, heeft talloze managementboeken, productiviteitsstudies en leiderschapsraamwerken voortgebracht.

“De pure complexiteit van software betekent dat het onmogelijk is om elk pad te testen”, schrijft Kynetix CEO Paul Smyth op Finextra. “Een softwareapplicatie is als een ijsberg – 90% ervan is niet zichtbaar. De grootste complexiteit van de applicatie ligt onder de waterlijn”.

Elk softwareproject van significante omvang, of dat nu een CRM is of een besturingssysteem zoals Microsoft Windows, is te groot om in het hoofd van één persoon te passen. Het vereist de gedeelde kennis en samenwerking van vele medewerkers. Dit betekent dat ontwikkelaars aan gespecialiseerde onderdelen van de toepassing werken terwijl ze moeten begrijpen hoe hun werk het geheel beïnvloedt.

“No one mind can comprehend it all”, merkte de manager van een team van 250 Microsoft softwareontwikkelaars op terwijl ze een besturingssysteem vanaf nul aan het bouwen waren, volgens G. Zachary in Show stoppers! een boek dat het verhaal vertelt van een team van Microsoft software ontwikkelaars die raceten om Windows NT te voltooien in 1993.

Hoe groter het project, hoe langzamer veranderingen kunnen worden doorgevoerd. Onderzoek van Steve McConnell bewijst dit, door te vinden dat code 5-10x langzamer wordt geschreven op projecten van meer dan 10.000.000 regels. Verder bleek uit een studie van Microsofts ontwikkelingspraktijken dat er ruwweg 10-20 bugs zijn voor elke 1.000 regels code.

Ondanks de grootte van het project en het aantal bijdragers, gaat de ontwikkeling van de Linux kernel snel en zijn grote, enthousiaste gebruikersgroep vangt bugs op en schrijft patches om snel verbeteringen te verschepen.

In de vroege ontwikkelingsdagen – rond 1991 – was het niet ongebruikelijk voor Torvalds om meer dan één nieuwe kernel per dag uit te brengen. Nu, in een meer volwassen stadium en afhankelijk van 80% van de smartphones en de meerderheid van de internetservers, is de gewenste releaseperiode 8 tot 12 weken. Elke release krijgt de kernel gemiddeld 10.000 patches van 2.000 ontwikkelaars – die allemaal worstelen met meer dan 20.000.000 regels code.

Wat zijn de managementtechnieken en -processen die nodig zijn om dit niveau van samenwerking en productiviteit te orkestreren? Nou, die zijn niet geschreven door een afdelingshoofd of een schrijver van bedrijfsboeken. Ze zijn op organische wijze tot stand gekomen, onder leiding van de “welwillende dictator” van het project, Linus Torvalds.

Zelfs in zijn ontluikende vorm werd er aan de Linux-kernel meegewerkt door honderden vrijwilligers die hun werk rechtstreeks ter beoordeling aan Torvalds voorlegden. Hoe beheerde een slechtgehumeurde, asociale hacker bijna twee decennia lang geschillen, bijdragen en communicatie tussen duizenden ontwikkelaars?

Hoe beleid, processen en 15.000.000 regels code worden gedocumenteerd

In tegenstelling tot een traditionele organisatie worden nieuwe kernelontwikkelaars niet strikt ‘onboarded’ in de gemeenschap, maar wordt van hen verwacht dat ze de inleidende documentatie volledig hebben gelezen en begrepen. De focus van het kernelproject op documentatie was noodzakelijk vanwege zowel de technische complexiteit als het grote aantal ontwikkelaars.

Er zijn talloze FAQ’s, how-to’s en aan de slag-gidsen te vinden in de documentatiebewaarplaats van de kernel, en nog meer in wiki’s die zijn gemaakt en worden onderhouden door kernelontwikkelaars over de hele wereld.

De manier waarop documentatie wordt geschreven en verbeterd, weerspiegelt de manier waarop de kernel wordt ontwikkeld: gezamenlijk, open en incrementeel.

Door gebruik te maken van de ogen en specialisaties van een enorme groep mensen, kan de documentatie veel efficiënter worden gemaakt, getest en nagelezen dan wanneer dit door een kleiner, toegewijd team zou worden gedaan. Om de Wet van Linus om te buigen in termen die een redacteur beter zou begrijpen: met genoeg ogen zijn alle typefouten voor de hand liggend.

Naast materiaal voor technische ondersteuning heeft de kernelontwikkelingsgemeenschap ook een bibliotheek met procesdocumentatie gemaakt, bedoeld om de menselijke kant van samenwerking te vergemakkelijken.

Op de indexpagina van “A guide to the Kernel Development Process” staat een paragraaf die luidt:

“Het doel van dit document is om ontwikkelaars (en hun managers) te helpen met een minimum aan frustratie samen te werken met de ontwikkelgemeenschap. Het is een poging om te documenteren hoe deze gemeenschap werkt op een manier die toegankelijk is voor mensen die geen grondige kennis hebben van Linux-kernelontwikkeling (of vrije softwareontwikkeling in het algemeen).”

Niemand wordt geboren met een aangeboren kennis van het versiecontrolesysteem git, of hoe je een patch moet indienen bij een mailinglijst. Daarom moet het ontwikkelproces worden gedocumenteerd – dezelfde basisinformatie aan één persoon tegelijk uitleggen is niet schaalbaar!

Hoe de communicatie tussen 1000 ontwikkelaars wordt beheerd

Discussies tussen ontwikkelaars vonden in het openbaar plaats, op de kernelontwikkelingsmailinglijsten. Tot op de dag van vandaag wordt nog steeds de voorkeur gegeven aan e-mail vanwege de eenvoud ervan. Deze mailinglijsten werden gearchiveerd en georganiseerd, en vormden zo een geheel van levende documentatie en geschiedenis.

Het effect van communiceren in het openbaar heeft een vergelijkbaar effect als de voordelen van het gebruik van een tool als Slack vandaag de dag – alle informatie wordt veilig en doorzoekbaar gemaakt, in plaats van te verdampen. Om een dergelijke stortvloed aan informatie te beheren, heeft het kernelproject echter een communicatiebeleid ontwikkeld en als onderdeel van de documentatie verspreid.

Communicatie en samenwerking op een dergelijke schaal was vóór het internet niet mogelijk, dus vroege projecten zoals dit moesten snelle en effectieve oplossingen schrijven en verspreiden voor problemen op het gebied van gemeenschapsbeheer, etiquette en codepresentatie.

De kerneldocumentatie bevat regels voor het indienen van patches, zodat het voor anderen eenvoudiger wordt om bijgedragen code te beoordelen, te bewerken en te testen. Dit betekent dat patches in platte tekst gemaild moeten worden, niet als bijlage. Patches mogen slechts één keer per e-mail worden verzonden en moeten voldoen aan specifieke richtlijnen voor de coderingsstijl:

Deze strikte standaardisatie is absoluut noodzakelijk voor een project zo groot als de kernel, net zoals het noodzakelijk is voor projecten van elke omvang. Het helpt fouten te verminderen in een ruimte waar een enkele fout een rimpeleffect kan hebben dat in de toekomst instabiele code produceert, of de tijd van vele testers en ontwikkelaars verspilt.

Hoe kritieke beslissingen (niet) worden genomen

Om Torvalds te citeren:

“De naam van het spel is om te vermijden dat je een beslissing moet nemen. In het bijzonder, als iemand tegen je zegt “kies (a) of (b), we hebben je echt nodig om hierover te beslissen”, dan zit je als manager in de problemen. De mensen aan wie je leiding geeft kunnen maar beter de details beter kennen dan jij, dus als ze naar jou komen voor een technische beslissing, ben je de klos. Je bent duidelijk niet bekwaam om die beslissing voor hen te nemen.” – Linux Kernel Development Documentation

Naast het vermijden van een managementhiërarchie had het Linux-project duidelijke regels en documentatie die hielpen beslissingen te nemen zonder de noodzaak van discussie, debat of (vele) mailing list flame wars. Een blik op de archieven leert je dat het deel van de flame war niet altijd mogelijk is, maar wat wel mogelijk is, is het creëren van beleid dat de last van het nemen van beslissingen wegneemt.

“Dus de sleutel tot het vermijden van grote beslissingen wordt om gewoon te vermijden dingen te doen die niet ongedaan kunnen worden gemaakt. Laat je niet in een hoek drijven waaruit je niet kunt ontsnappen. Een in het nauw gedreven rat kan gevaarlijk zijn – een in het nauw gedreven manager is gewoon zielig.”

Show Stoppers! onthult dat de filosofie van Bill Gates vergelijkbaar is. Hij “bewonderde programmeurs en gaf ze steevast de leiding over projecten, waar ze zowel konden managen als programmeren om te voorkomen dat professionele managers, zonder programmeerervaring of met verouderde kennis, het voor het zeggen kregen”.

Hoe bijdragers georiënteerd zijn rond een sterk gemeenschappelijk doel

In het geval van Linux, zoals bij veel populaire open source projecten, is de kernel niet ontstaan nadat hij gezamenlijk was ontworpen door een grote groep bijdragers; in plaats daarvan werd hij incrementeel verbeterd zonder beslissingen te nemen die de sterke basis van het werk tot dan toe zouden destabiliseren. Dit sluit goed aan bij Torvalds’ filosofie over besluitvorming in management, maar ook bij een filosofie die in de code zelf is ingebed.

Linux is gebaseerd op UNIX, wat een eerder besturingssysteem is dat is ontworpen rond een set zen-achtige principes. Zoals expliciet vermeld in de UNIX-filosofie:

“Ontwerp en bouw software, zelfs besturingssystemen, om in een vroeg stadium te worden uitgeprobeerd, idealiter binnen enkele weken. Aarzel niet om de onhandige onderdelen weg te gooien en opnieuw te bouwen.”

Zowel Torvalds als Raymond (die het succes van Torvalds’ community-vorming wilde repliceren) ontdekten dat vroeg en vaak uitbrengen hielp om bijdragers te verzamelen rond een spannend, groeiend project waarin ze een toekomst zien. Raymond bracht het terug tot twee belangrijke dingen die een project niet mag nalaten wanneer het in de wereld wordt vrijgegeven:

1. Run
2. Overtuig potentiële mede-ontwikkelaars (gebruikers) dat het project kan worden ontwikkeld tot iets groots binnenkort

Het is met deze zelfde principes dat veel van de huidige startups starten – Process Street inbegrepen:

Hierboven is Process Street in 2014. Meld u aan voor een account om te zien hoe ver we zijn gekomen.

Is dit een herhaalbaar proces?

Op het eerste gezicht lijkt het plotselinge samenkomen van een van de meest ingewikkelde menselijke creaties op alchemie. Maar door de onderdelen uit elkaar te halen is het gemakkelijker een onderliggend proces te zien. Ten tijde van het schrijven van The Cathedral and The Bazaar, was Eric S. Raymond tegelijkertijd bezig met de ontwikkeling van een open source email client. Door het open source te maken, probeerde Raymond de betrokkenheid van de gemeenschap en het uiteindelijke succes van het kernelproject te evenaren.

Veel van de basisprincipes van het Bazaar-model, zoals hij het noemde, zullen iedereen in de startup-wereld onmiddellijk bekend voorkomen:

• Elk goed stuk software begint met het krabben van de persoonlijke jeuk van een ontwikkelaar.
• Het behandelen van je gebruikers als mede-ontwikkelaars is je minst-lastige route naar snelle code verbetering en effectief debuggen.
• Release vroeg. Breng vaak uit. En luister naar uw klanten.
• Gezien het aantal bètatesters en mede-ontwikkelaars groot genoeg is, zal bijna elk probleem snel worden gekarakteriseerd en zal de oplossing voor de hand liggen.
• Als u uw bètatesters behandelt alsof ze uw meest waardevolle bron zijn, zullen ze reageren door uw meest waardevolle bron te worden.
• Het op één na beste ding om goede ideeën te hebben, is het herkennen van goede ideeën van uw gebruikers. Soms is het laatste beter.
• Vaak komen de meest opvallende en innovatieve oplossingen voort uit de realisatie dat je concept van het probleem verkeerd was.
• Om een interessant probleem op te lossen, begin met het vinden van een probleem dat interessant voor je is.
• Mits de ontwikkelcoördinator een communicatiemiddel heeft dat minstens zo goed is als internet, en weet hoe hij zonder dwang leiding moet geven, zijn vele hoofden onvermijdelijk beter dan één.

Kortom, het is een herhaalbaar proces. En een die met succes is overgenomen uit de wereld van open source in de startup-mentaliteit. Het manifesteert zich in agile, lean, six sigma, en de attitudes en het beleid dat startups vandaag de dag hebben ontwikkeld. Hoewel het niet vaak in hetzelfde gesprek wordt genoemd, heeft de methodologie die zich rond de vroege besturingssystemen ontwikkelde, veel gemeen met het huidige idee van itereren op een minimaal levensvatbaar product.