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”.

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.

Puppet is hot. Ik hoor van veel organisaties dat ze bezig zijn met een implementatie van Puppet of die overwegen. Verschillende van onze klanten zijn bijvoorbeeld bezig met de voorbereiding ervan. Toch is het interessant dat het nu zo populair wordt. Mijn collega’s gebruiken het al jaren voor het beheer van onze systemen. Maar blijkbaar is de tijd er nu ‘rijp’ voor.

Maar wat is Puppet? Het is management software waarmee grote aantallen servers beheerd kunnen worden. Het gaat hierbij zowel om het beheer van configuratie files (zeg maar instellingen van de servers) als het beheer van de geïnstalleerde software (packages). Een typische use case voor Puppet is bijvoorbeeld het beheer van virtuele servers in een cloud. Het kan dan gebruikt worden om snel extra webservers te installeren. In Puppet worden recepten (classes) gemaakt waarin de server feitelijk beschreven is.

Deze recepten kunnen ook dynamisch zijn doordat ze scripts bevatten die situatie afhankelijk software installeren. Zo kan een script testen op welk type hardware de installatie plaats vindt en aan de hand daarvan bepalen welke specifieke software (ten behoeve van ILO, DRAC et cetera) geïnstalleerd moet worden. Op iedere te beheren server draait een server proces (puppet.d) dat met de server communiceert. Deze communicatie is versleuteld en er kan ingesteld worden met welk interval de configuratie van de te beheren server vergeleken wordt met de Puppet server.

Ook kan gebruik gemaakt worden van Facter. Met Facter kan informatie van verschillende servers verzameld worden. Deze informatie kan eventueel samen met variabelen gebruikt worden in de recepten. De recepten zijn overigens te nesten zodat ze hergebruikt kunnen worden. Al met al een krachtig stuk gereedschap dat steeds krachtiger wordt naar mate er meer servers beheerd moeten worden. Een andere sterke kant is dat het volledig command line gebaseerd is. Maar de leercurve van Puppet is stijl. Een (open source) alternatief voor Puppet is CFengine.

Enthousiast

Een interessante vraag is waarom de technisch specialisten er zo enthousiast over zijn. Voor een deel is dit te begrijpen omdat technische mensen niet graag dubbel werk verrichten. Wanneer de eerste server is ingesteld en een tweede geconfigureerd moet worden, begint een technisch specialist na te denken of het niet slimmer kan. Puppet is een manier om het slimmer te doen en daar houden ze van. Natuurlijk moeten de recepten gemaakt worden en zonder twijfel wordt het daar complexer van. Maar bij grote aantallen servers scheelt het veel tijd. Daarnaast is een beetje complexiteit voor een technisch specialist een intellectuele uitdaging.

Een andere reden om Puppet te willen gebruiken is dat ze daarmee controle en overzicht verkrijgen. Middels de recepten zijn de configuraties van alle servers beschreven. Dat scheelt behoorlijk als er gedocumenteerd moet worden, een werkje dat niet altijd even leuk gevonden wordt. Bovendien kan eenvoudig de configuratie van honderden servers aangepast worden. Als technisch specialist ben je daarmee ‘in control’.

Als Puppet gecombineerd wordt met GIT kan er versiebeheer uitgevoerd worden op de configuraties. Het voordeel van dit versiebeheer is dat er een roll back kan worden gedaan naar een ‘oude’ configuratie waarvan bekend is dat die werkte en dat alle wijzigingen gedocumenteerd zijn. Er is precies te zien wie, wanneer, wat, heeft veranderd.

Een nog interessantere vraag is waarom bedrijven vanuit het business perspectief gebruik zouden willen maken van Puppet. It-organisaties zien zich tegenwoordig geconfronteerd met een aantal uitdagingen waarbij Puppet mogelijk kan helpen. Om te beginnen moet alles tegen lagere kosten. Met andere woorden het moet efficiënter. Dit is bij uitstek natuurlijk een gebied waarin Puppet zinvol gereedschap is. Mits goed ingericht kan met weinig mankracht een groot aantal servers worden beheerd.

Praktisch

Doordat alle configuraties beschreven zijn kunnen servers ook snel (fysiek danwel virtueel) opnieuw geïnstalleerd worden. Dit is buitengewoon praktisch wanneer een systeem bijvoorbeeld gehacked is. De enige manier om zeker te zijn dat alle ‘achterdeurtjes’ verwijderd zijn, is een herinstallatie uit te voeren. In Puppet is het gehele systeem beschreven waardoor ook de herinstallatie kan snel worden uitgevoerd. De aangewakkerde aandacht voor security de laatste tijd maakt dit een aantrekkelijke feature.

Indien Puppet gecombineerd wordt met GIT, zoals eerder aangegeven, kan historie worden bewaard. Dit betreft een historie van alle wijzigingen die er op servers hebben plaatsgevonden. Vanuit ITIL – een beheermethodiek die veel toegepast wordt – is dit erg interessant. De gedachte achter ITIL is dat 80 procent van alle verstoringen veroorzaakt worden door wijzigingen. Goede documentatie van alle wijzigingen is een eerste stap richting het beheersen en controleren van het veranderproces. Betere beheersing van het veranderproces leidt tot minder verstoringen. Het is duidelijk wat het belang van minder verstoringen is voor de bedrijfsvoering van organisaties.

Puppet is open source software. Dit maakt de instap bijzonder laagdrempelig. Indien organisaties behoefte hebben aan commerciële support dan kan deze onder andere bij Puppetlabs verkregen worden. Er kan dan gebruikt gemaakt worden van de enterprise edition. Deze betaalde versie heeft naast support ook extra’s die het goed bruikbaar maken binnen bijvoorbeeld een VMware-omgeving. In mijn ogen is de populariteit van Puppet wederom een voorbeeld waaruit blijkt dat Linux en open source software steeds meer main stream worden. Het is gereedschap om juist grote aantallen servers te beheren en dat betekent dat er dus grote aantallen Linux servers in gebruik zijn bij steeds meer organisaties.

Al met al prima redenen om het te gaan gebruiken, maar ik vraag me af of er ook redenen zijn om Puppet juist niet te gebruiken?
Dit artikel is verschenen op de site van Computable op 20-03-2012

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