Tag Archives: software development

Elevator pitch Open Source Software

Het overkomt me nog wel eens dat me gevraagd wordt waarom bedrijven en organisaties voor Open Source Software moeten kiezen. Ik denk daarom al langere tijd na over een “elevator pitch”. Veelal is het sentiment namelijk dat Open Source Software geen doel op zich moet zijn en dat de beste tool voor de job gekozen moet worden. Maar is dat voldoende?

Fysieke wereld

Wij mensen leven in een fysieke wereld en zijn gewend aan de wetmatigheden die daar gelden. Zo weten we bijvoorbeeld dat wanneer we iets delen in de fysieke wereld (bijvoorbeeld een taart), dat iedereen met wie we delen een stukje krijgt. We weten ook dat wanneer we met steeds meer mensen delen de stukken steeds kleiner worden. Consequentie hiervan is dat er dus sprake is van een afnemend nut.

Voor de duidelijkheid, dit is geen betoog tegen delen 
in de fysieke wereld, want ook daarvoor geldt, wie deelt 
heeft meer!

Digitaal delen is vermenigvuldigen

Tegenwoordig hebben we steeds meer zaken digitaal, zoals muziek, foto’s film, teksten (boeken) en software. In  tegenstelling tot delen in de fysieke wereld, krijgt iedereen met wie we digitale content delen het geheel. Je kan daarom stellen: “digitaal delen is vermenigvuldigen”.elevator_pitch_oss

Voor onze discussie over nut geldt dan dat iedere kopie evenveel nut geeft. In de figuur is e.e.a. grafisch weergegeven. Overigens gaat het hier (op de verticale as) om nut, niet om de prijs die je daar eventueel voor betaald.

 

 

Digitale content veroudert en slijt niet. Leveranciers van film, 
muziek en software bedenken daarom constructies om klanten telkens opnieuw 
te laten betalen. Een voorbeeld hiervan zijn Spotify en Netflix abonnementen 
of een "software assurance" waarvan de geldigheid na 3 jaar verloopt. 
Hiermee "slijt" digitale content en moet er periodiek opnieuw voor betaald 
worden. Feitelijk betreft dit huur. Gesteld kan worden dat men probeert
wetmatigheden van de fysieke wereld toe te passen op de content in
de digitale wereld. Hiermee wil ik niet zeggen dat het toch geen 
"goede deal" kan zijn. Zowel Spotify als Netflix leveren additionele
diensten zoals de mogelijkheid afspeellijsten te maken of het attent
maken op nieuwe content.

Open Source Software

Bij Open Source Software wordt iedereen in staat gesteld de content aan te passen en te verbeteren. Je kan stellen dat het nut toeneemt naar mate je deze met meer mensen deelt.

Vaak wordt gesteld dat slechts maar een heel klein percentage 
mensen een bijdrage (verbetering) levert aan open source 
software. Dat mag het geval zijn, maar zelfs een klein percentage 
levert uiteindelijk voor iedereen veel op, mits we met voldoende
mensen delen! M.a.w. hier loont het zich juist om met zoveel
mogelijk mensen te delen.

 Conclusie

Het delen van digitale content is een ander proces dan delen in de fysieke wereld. In plaats van een deel krijgt iedereen een volledige kopie. Digitaal delen is daarom vermenigvuldigen. Zodra de mensen met wie je deelt in staat zijn de content te verbeteren (zoals dat bij open source software het geval is) neemt het nut zelfs toe. Voor bedrijven en organisaties betekent dit investeren in de toekomst in plaats van betalen voor het verleden.

Natuurlijk leveren ook fabrikanten van commerciële software nieuwe versies. 
Je kan dit in de grafieken voorstellen als een nieuwe lijn, zij het dat die 
op een hoger punt (meer nut) begint. Software die volgens het huur 
principe wordt verkocht kan je voorstellen als een lijn die op een bepaald 
tijdstip ophoudt te bestaan.

 

Code management en open source met GIT

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