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

Ik volg het ict-nieuws dagelijks en met een speciale interesse voor alles wat met open source software te maken heeft. Ik lees daarvoor ook iede3re dag verschillende websites. De laatste tijd zijn me een aantal berichten opgevallen.

Google wordt door Oracle aangeklaagd voor het schenden van software patenten in Java. Het inmiddels zeer populaire Android besturingssysteem voor smartphones zou op een ongeoorloofde manier gebruik maken van Java. De uitkomst van deze rechtszaak treft de bedrijven die gebruik maken van Android en dat zijn er veel. Overigens heeft James Gosling, de developer van Java, er wel een interessante eigen mening over.

Er was nog een bericht dat me opviel. LibreOffice splitst zich af van het OpenOffice project. SUN was sponsor van OpenOffice, maar door de overname van SUN is dit in handen gekomen van Oracle. Inmiddels is de community rond OpenOffice blijkbaar niet gelukkig met de koers die Oracle vaart. Men heeft gekozen voor een ingrijpende oplossing, een fork van het OpenOffice project. Oracle is verzocht zich hierbij weer aan te sluiten. Tot nu toe heeft Oracle geen stappen in die richting gezet. Andere organisaties hebben zich inmiddels wel bij LibreOffice aangesloten waaronder Red Hat, Free Software Foundation, Google, Canonical, Novell en Gnome.

Het derde dat me opviel was het bericht dat de Apache Software Foundation van mening is dat Oracle de licentievoorwaarden schendt van het (inmiddels) eigen Java product. Ze roept daarom de leden van het Java Community Proces op om tegen de nieuwe versie van Java (versie 7) te stemmen. Het dispuut richt zich hierbij op de Field-of-Use (FOU) beperking. De Apache Software Foundation stelt zich hierbij bijzonder strijdbaar op.

Nu zou je kunnen denken dat ik hier alleen naar Oracle kijk, maar dat is niet het geval. Zo heeft Microsoft TomTom aangeklaagd voor het gebruik van het file systeem (FAT) binnen de TomTom devices. Op internet werd gesuggereerd dat het een aanval tegen Linux betrof. Het beperkt zich wat mij betreft niet tot Oracle, maar betreft alle grote software bedrijven.

Onder vuur

Ik kan me niet aan de indruk onttrekken dat open source software door grote software bedrijven aangevallen wordt. Een paar jaar geleden heb ik CEO van Open Invention Network Keith Bergelt ontmoet. Deze organisatie koopt software patenten met als doel Linux te beschermen en beschikbaar te houden voor de industrie. Patenten worden op een royalty-free wijze beschikbaar gesteld. Keith vertelde me toen al dat hij een toename van patent rechtszaken verwachtte. Hij noemde het toen ‘de stilte voor de storm’. Krijgt hij gelijk?

Is dit de manier waarop de grote software bedrijven proberen invloed te krijgen op de ongrijpbare open source software en de communities? Gaat ze dat ook lukken, of zijn de verschillende communities in staat zich hiertegen te verzetten? Vervallen deze bedrijven in hun ‘oude’ gedrag en zijn ze niet in staat om met een frisse blik te kijken? Bovendien vraag ik me af welke rol de Nederlandse overheid (of de Europese Unie) hierin zou moeten spelen. Nu de verschillende Europese overheden serieuze interesse tonen in open source software is het niet in het belang dat deze in diskrediet worden gebracht.

Dit artikel is verschenen op de site van Computable op 15-11-2010

Als voorstander van open source software benoem ik graag de voordelen ervan. Ze zijn inmiddels wel bekend. Een uitgekauwd onderwerp is kostenbesparingen. Nu wil ik een voordeel onder de aandacht brengen waarvan wellicht niet iedereen op de hoogte is.

Men weet dat open source door communities wordt gemaakt. Ze bestaan uit bedrijven of individuele programmeurs die zich rond interessante software verenigen. Deze programmeurs ontlenen een deel van hun identiteit aan de community.

Ik ken een programmeur die bijdragen levert aan het Debian-project. Hij is trots als zijn package geaccepteerd wordt vanwege de strenge eisen. Blijkbaar doe je het goed als jouw code geaccepteerd wordt.

In een community besluiten enkele mensen welke bijdragen gebruikt worden. De kwaliteit van de code is belangrijk bij deze keuze. De code moet duidelijk zijn, ‘Lean and mean’ en aansluiten bij de ontwikkeling die het softwareproduct doormaakt. De nieuwe vervangt dan de bestaande code, omdat deze beter is of beter aansluit bij de ontwikkeling.

In het verleden waren er discussies over welke methode van task sceduling (schakelen tussen taken) in Linux gebruikt moest worden. Wordt men het niet eens, dan kan de code als patch voort blijven bestaan. Echter, meestal wordt gekozen voor de beste implementatie.

Firewall

Een voorbeeld is de firewall code in Linux. Toen ik me hier voor het eerst in verdiepte, was ipchains de gebruikte methode, opvolger van ipfwadm. Was ipchains dan beter en makkelijker of gaf het meer mogelijkheden? Kort erna werd ipchains vervangen door iptables. Ik onderzocht hoe iptables werkte en pastte mijn firewall scripts aan. Voor marketingmedewerkers van een commercieel softwarebedrijf was dit een ramp geweest. Hoe leg je klanten uit dat er andere software gebruikt moet gaan worden? Tot drie keer toe! Waren ipfwadm en ipchains dan niet goed? In de open source wereld is dat geen probleem. Technici zijn snel overtuigd van de betere techniek. En er zijn geen marketingmensen die er hinder van ondervinden.

Het lijkt erop dat er een pool is van elkaar beconcurrerende technieken waarbij de beste wint. Zie daar de vergelijking met de evolutie theorie van Charles Darwin. Volgens ‘Survival of the Fittest’ heeft het organisme met de hoogste overlevingskans de grootste kans op nakomelingen; zo blijven de sterksten bestaan. Overigens gaat de vergelijking verder mank, omdat de theorie ook uit gaat van toeval dat voor diversiteit zorgt.

Haaienvijver

De gedachte van de pool vind ik interessant. In de praktijk werkt het ook zo. Iptables is al jaren de dominante techniek. Er is nog één vraagstuk dat mij bezig houdt. Levert de community uiteindelijk superieure software op? En, zo ja, is dat dan niet de reden om open source software te gebruiken?

Dit artikel is verschenen op de site van Computable op 29-0-2010