Op 14 juni 2012 gaf Linus Torvalds een presentatie aan het Aalto University Center for Entrepreneurship. Deze bijeenkomst is gefilmd en op Youtube te vinden. Hij vertel hier hoe hij ooit gestart is met Linux en tot welk een fenomeen het inmiddels is uitgegroeid. Het meest interessant vond ik zelf zijn opmerkingen over hoe hij het (Linux) project managed en hoe het georganiseerd is. Naar mijn stellige overtuiging kunnen we hier wel wat van leren.

“How hard can it be?”

Linus heeft van jongs af aan altijd zijn eigen software (tools) geschreven. Dit is zijn passie. Het kon op verschillende manier gemotiveerd zijn, of de hardware was niet ge-support of hij had niet voldoende geld om de juiste software te kopen. Telkens was het resultaat hetzelfde, hij maakte zijn eigen software. Tegen de tijd dat Linus aan de Universiteit van Helsinki studeerde was dit voor hem een tweede natuur geworden. Toen hij hier in aanraking met UNIX kwam en dit veel te duur bleek, besloot hij zijn eigen UNIX te schrijven.

Zoals hij zelf zegt, “How hard can it be?”.

Snel bleek dat dat naast enthousiaste gebruikers er ook commerciële mogelijkheden werden gezien. Byte Magazine bundelde voor een klein bedrag Linux (op floppy’s). Linus had bereikt wat hij wilde, UNIX was zeer laagdrempelig beschikbaar. De commerciële activiteiten van anderen stelde Linus in de gelegenheid zich te beperken tot datgene dat hij graag wilde, programmeren.

Volgens Linus is dit precies wat het ontwikkelen van Open Source software zo aantrekkelijk maakt. Iedereen heeft andere belangen en heeft zijn eigen interesses. Het Linux Open Source project geeft hiervoor ruimte en iedereen kan precies doen waarin hij goed is. Zo is Linus zelf  geïnteresseerd in het optimaliseren van specifieke onderdelen in Linux (aansturing van hardware). De algemene opvatting in de IT industrie is echter dat je geen micro optimalisatie moet doen. Maar als dat nou precies is wat je leuk vind? Het resultaat is dat er buitengewoon goed geoptimaliseerde code in de Linux kernel te vinden is. Alle gebruikers profiteren daarvan.

De waarde van commercie

Linus is van mening dat alle commerciële activiteiten van anderen (bedrijven o.a.) hem in staat stellen zich te concentreren op het programmeerwerk dat hij leuk vindt. Bovendien is Linux daardoor een veel beter gebalanceerd product geworden. Q&A en user interfaces programmeren vindt Linus niet het leukste werk. En nu doen ander mensen (bedrijven) dat, geweldig!

Inmiddels richt Linus zich steeds meer op het managen van het proces rond de ontwikkeling van de Linux kernel. De organisatie hiervan functioneert als een piramide. Linus heeft een klein groepje vertrouwelingen van wie hij code accepteert. Zijn vertrouwelingen richten zich op een (sub-onder) deel van de kernel en organiseren dat precies op dezelfde wijze. Kern van deze organisatie is dat het is gebaseerd op wederzijds vertrouwen en dat kan alleen met een beperkte groep mensen. Deze manier van organiseren is zo ontstaan en blijkt juist te zijn. Er is verder geen (ander) management, logistiek of planning voor nodig.

Software development is geen gepland proces, maar gebaseerd op toeval. Zo is er enkele jaren geleden veel werk verricht om multi core systemen goed en efficient te laten functioneren. Destijds was daar behoefte aan omdat dit een belangrijk was bij grote main frame systemen. Inmiddels jaren verder, profiteren we daar van met onze smart phones die nu ook multi cores hebben. Dit was vooraf niet te plannen of te bedenken geweest.

“Nvidea, Fuck You!”

Ook op een ander punt doorbreekt Linus gevestigde opvattingen. Linus staat niet bekend om zijn beleefde en voorzichtige uitlatingen. Hij is van mening dat beleefd zijn niet helpt. De kans op miscommunicatie is veel te groot. Daarom is Linus direct en recht door zee ook wanneer hij mensen daarmee beledigd (zie bijvoorbeeld “Nvidea, fuck you!” op 50.02 minuten in de video).

De bovenstaande zaken laten me achter met de vraag of we deze lessen / methode van werken ook op andere gebieden kunnen toepassen. Eén succesvol project is nog geen bewijs dat het principe universeel toepasbaar is. Toch heb ik sterk het gevoel dat hier iets waardevols is ontdekt.

Voor iedereen die de video zelf wil bekijken, onderstaand is de link te vinden.

We kennen Linus Torvalds als de maker van Linux. Hij heeft daarnaast ook GIT gemaakt. GIT is een source code management systeem, dat zelf volledig open source is. Het combineert technische eigenschappen en sociale aspecten die het bij uitstek geschikt maken voor open source software projecten.

Dezelfde motivatie die destijds ten grondslag lag aan Linux zette Torvalds er ook nu toe aan om zelf iets te maken. Hij was namelijk ontevreden met hetgeen er al was. In zijn presentatie over GIT bij Google talk laat hij zich dan ook negatief uit over CVS (en in mindere mate over Bittracker). Beiden zijn source code beheer systemen met een voor Torvalds onwerkbare opzet (om verschillende redenen overigens). Het kon en moest beter besloot hij en het GIT-project was geboren. De afkorting GIT staat voor ‘Global Information Tracker’ alhoewel Wikipedia en de home site van GIT daar nog grappige alternatieven voor bieden.

Gedistribueerd

Een van de belangrijkste eisen die Torvalds aan een source code management systeem stelt is dat het gedistribueerd werkt. Dit betekent dat iedereen een eigen versie van de code heeft. De meeste source code management systemen werken daarentegen met een centrale repository (opslag van code) en dat heeft nadelen. De code is daarbij voor alle developers toegankelijk. Daarom zijn er bijvoorbeeld naamconventies nodig zodat code-takken niet dezelfde naam krijgen (ze moeten uniek blijven). Ook zijn er performance problemen. Een vergelijk van twee code-takken (een diff), gaat binnen een centrale repository niet snel genoeg, zeker niet wanneer ook andere developers tegelijkertijd dergelijk bewerkingen uitvoeren. Andere nadelen zijn dat het branchen (aftakken) en mergen (weer samenvoegen) van code-takken erg lastig is. Als laatste noemt Torvalds de noodzaak van security. Een centrale repository heeft een uitgebreide autorisatie nodig. In de praktijk levert dat altijd problemen op.

In het gedistribueerde model van GIT behoren de genoemde problemen tot het verleden. Iedereen heeft een eigen kopie van de code. Het branchen (aftakken) is eenvoudig en er is geen naam conventie nodig. Je kan immers zelf bepalen hoe je een nieuwe code-tak noemt. Ook mergen (samenvoegen) gaat eenvoudig. Performance en security zijn niet langer een issue, je bent immers de enige op het systeem. Code gaat ook niet snel verloren. Meerdere developers hebben een versie van dezelfde code op hun systeem. Tevens doet GIT een checksum (controle op basis van sha) van alle bestanden. Hierdoor komen onbedoelde veranderingen in code bestanden (bijvoorbeeld als gevolg van corruptie van bestanden) meteen aan het licht. De goede performance van GIT leidt tot een andere manier van werken. Doordat bewerkingen op code-takken veel sneller kunnen voer je deze bewerkingen ook makkelijker en dus vaker uit. Omdat daarnaast het branchen (aftakken) van een code-tak zo eenvoudig gaat, nodigt dit developers uit snel nieuwe dingen uit te proberen. Op een centrale repository is dat niet gewenst. Het uiteindelijke resultaat van deze werkwijze is betere code en dat is waar het om gaat.

Als een developer een goed stuk code heeft gemaakt, kan hij dat aan een andere developer geven. Omdat de code-takken makkelijk kunnen mergen (samengevoegd worden), kan het eenvoudig opgenomen worden in het software project. Middels de hiërarchie, die de mensen binnen een software project kennen, wordt bepaald welke code uiteindelijk opgenomen gaat worden. Het is daarmee gebaseerd op het netwerk van vertrouwen dat er tussen de verschillende developers bestaat. Binnen het Linux project is het uiteindelijk Torvalds die bepaalt welke code in de kernel opgenomen wordt.

Bazaar

Naast de technische aspecten interesseert GIT me om nog andere redenen. Het is wederom een mooi voorbeeld van de manier waarop een open source project gestart wordt. Iemand heeft een probleem en zorgt zelf voor een oplossing. Inmiddels werken er vele developers aan GIT mee, blijkbaar voorziet het bij meer mensen in een behoefte.

GIT is naar mijn idee bij uitstek geschikt voor open source software projecten. Het sluit goed aan bij de manier van software ontwikkelen binnen communities. Dit wordt ook wel de bazaar wijze van software ontwikkelen genoemd. Ook past het bij de sociale hiërarchie die binnen open source projecten gebruikelijk is. Commerciële (of defensie gerelateerde) bedrijven zullen mogelijk niet zo blij zijn dat iedere developer de complete code van een software project op zijn laptop mee neemt. Toch kan GIT bijdragen aan kwalitatief betere code, dat is iets dat ook voor deze bedrijven interessant is.

Eigenlijk verbaast het me niet dat juist Linus Torvalds, als grondlegger van het meeste bekende open source project ter wereld (Linux), een source code management systeem bouwt dat bij uitstek geschikt is voor open source projecten. Ik vraag me alleen af wat de marktadoptie is van GIT. Welke bedrijven gaan dit gebruiken?

Dit artikel is verschenen op de site van Computable op 20-01-2011