In deze paragraaf wordt de organisatie van Open Source software ontwikkeling beschreven. Hierbij wordt gebruik gemaakt van het 7-S model van McKinsey.
5.3.1 Strategie
Strategie heeft te maken met de doelen die een organisatie nastreeft en de manier waarop men die probeert te bereiken. Open Source initiatieven hebben niet altijd betrekking op een organisatie. Sommige initiatieven, zo niet de meeste, bestaan uit een (grote) groep vrijwilligers die een gezamenlijk doel nastreven: een programma dat werkt, dat hun probleem oplost.
Strategie heeft echter in bedrijfskundige termen betrekking op de langere termijn, wat wil een organisatie bereiken in de toekomst, hoe gaat ze daar komen?!
In die zin kan het licentiemodel van Open Source software worden gezien als een instrument om een lange termijn streven te bereiken, namelijk openheid. Open Source software is ontstaan uit een soort frustratie over het commerciële model van software(ontwikkeling). Open Source software was het antwoord op, een soort verzet tegen, het sluiten van code en de bijkomstige afhankelijkheid en vrijheidsbeperking bij het oplossen van problemen. Om op de lange termijn te waarborgen dat Open Source software open blijft zijn er verschillende licentiemodellen in het leven geroepen die dit waarborgen. In die zin is openheid en bijbehorende licenties een strategie. Binnen Open Source ontwikkelinitiatieven tracht men het wiel niet opnieuw uit te vinden, een strategie voor het versnellen van ontwikkelingen. Zo zoekt men bij het ontwikkelen van programma’s eerst naar bestaande programma’s die in de buurt komen van de functionaliteit die nagestreefd wordt. Dit wordt mogelijk gemaakt door de openheid van de software en het licentiemodel. Software ontwikkelt zich op deze manier snel. Hergebruik van software is daarmee een duidelijke strategie.
Omdat Open Source initiatieven het veelal opnemen tegen grote kapitaalkrachtige organisaties wordt het vrijgeven van code ook wel gebruikt om te voorkomen dat men achter raakt op marktleiders en op die manier ophoudt te bestaat (Lerner en Tirole, 2002). Dit wordt voornamelijk gedaan door kleine organisaties die toekomst zien in hun product(en) maar niet kunnen opboksen tegen de giganten. Door code ter beschikking te stellen aan de OSS-ontwikkelgemeenschap beschikken zij over een potentieel eindeloos grote groep ontwikkelaars die bijdragen aan de ontwikkeling van hun product. Hiermee zijn zij echter ook de mogelijkheid kwijt om geld ter verdienen aan de verkoop van hun code. Onder andere door deze strategie zijn hybride businessmodellen ontstaat.
Ondernemingen met een hybride businessmodel ontwikkelen Open Source software om te verdienen aan complementaire services (Lerner en Tirole, 2002).
Het hanteren van standaarden kan als strategie worden gezien. Toegankelijkheid van code wordt gewaarborgd door het licentiemodel. Maar toegang tot code alleen is niet genoeg. Wanneer iedere ontwikkelaar gebruik zou maken van een drastisch andere manier van programmeren zou code wel eens ondoorgrondelijk kunnen worden. Om dit tegen te gaan worden standaarden gehanteerd. Deze standaarden hebben betrekking op hoe code globaal dient te worden gestructureerd.
Onder de noemer strategie kan ook het modulaire karakter van Open Source software worden geplaatst. Nauw verwant aan het toegankelijkheidsstreven waarborgt modulairiteit snelle ontwikkeling. In de Open Source wereld heerst de opvatting dat een programma één taak dient
uit te voeren. De uitvoer van meerdere taken wordt bereikt door meerdere code-modules op elkaar aan te sluiten. Ook hiervoor is het gebruik van standaarden zo belangrijk. Het ontwikkelen van programma’s is dus een relatief snelle bezigheid wanneer men slechts ontbrekende functionaliteit hoeft te ontwikkelen, de rest bereikt men door gewenste functionaliteitmodules te gebruiken.
In de Open Source wereld wordt snelle ontwikkeling en nauwe aansluiting bij gebruikersbehoefte bereikt door het vroeg vrijgeven van code en het vaak vrijgeven van code. Een oneindig grote groep ontwikkelaars kan code inzien en verbeteringen voorstellen/aandragen. Bestaande software wordt daardoor steeds snel verbeterd, met relatief kleine veranderingen.
5.3.2 Structuur
Wenger en Snyder (2000) maken een onderscheid tussen vier groepsconfiguraties, te weten: informele netwerken, projectteams, formele werkgroepen en belangengemeenschappen. Alle vier hebben ze andere doelen, andere manieren van samenstelling, andere manieren van cohesie en verschillende redenen om op te houden te bestaan. In overeenstemming met wat Lioubareva (2005) stelt, kunnen OSS-ontwikkelgemeenschappen worden getypeerd als belangengemeenschappen. Een gemeenschapsconfiguratie is volgens Lioubareva een type netwerkstructuur en vind zijn bestaansrecht in de aanwezigheid van belanghebbenden. De waarde van een dergelijke gemeenschap is afhankelijk van erkenning en acceptatie ervan door de belanghebbenden (Lioubareva, 2005). Met andere woorden, een belangengemeenschap kan pas bestaan als alle leden elkaar erkennen en accepteren. Het zijn voornamelijk sociale links die een belangrijke rol spelen bij het ontstaan van regels, vertrouwen en samenwerkingsstructuren. Op de volgende pagina is een schematische weergave gegeven van de vier typen groepsconfiguraties zoals Wenger en Snyder (2000) ze onderscheiden.
Gemeenschappen, net als netwerken, zijn systemen die bestaan uit tal van knooppunten in de vorm van individuen of organisaties. Knooppunten zijn alleen van belang zolang andere knooppunten ermee willen samenwerken (Raymond, 2000a). Een ander kenmerkend aspect van de netwerkstructuur is dat het geen duidelijke grens kent tussen klant en aanbieder.
De structuur die een project, een belangengemeenschap, aanneemt hangt af van de grootte van het project maar alle projecten hebben een duidelijk hiërarchische organisatie met een gedecentraliseerde beslissingsstructuur. Opmerkelijk is dat een Open Source ontwikkelproject (vrijwel) nooit fysiek samen is. De meeste projecten komen tot stand zonder dat de ontwikkelaars elkaar ooit zien (Raymond, 2000a). Raymond (2000b) geeft een driedeling in projectgrootte en structuur van een project.
In de twee meest succesvolle en geprefereerde werkvormen wordt een project geleidt door een ‘welwillende dictator’ (Raymond, 2000b), een sterke leider die door persoonlijke interesse en toewijding belangrijke betekenis heeft voor de cohesie in een ontwikkelgroep.
In de meest simpele vorm is een project klein en werken er meerdere ontwikkelaars onder de leider. Wanneer projecten groeien, ontstaan er onder de ‘welwillende dictator’ vaak twee niveaus ontwikkelaars: gebruikers die een normale bijdrage blijven leveren (willekeurig geïnteresseerden uit de OSS-ontwikkelgemeenschap die ten minste één keer bijdragen) en medeontwikkelaars (ontwikkelaars die op vaste basis bijdragen en meer invloed hebben op het beslissingsproces). Leider van een groep medeontwikkelaar word je door verantwoordelijkheid te nemen voor een deelproject of door een hoge mate van bijdrage bij het oplossen van bugs (programmafouten). Een substantiële en continue investering van tijd en moeite in het project is dus vereist om een leider van een deelproject te kunnen worden. Hiermee wordt de onderhoudsverantwoordelijkheid genomen voor dat deelsysteem en wordt zowel de implementatie ervan als ook de interface met de rest van het systeem gecoördineerd. Grote projecten als het Linux besturingssysteem hebben bewezen te werken in deze vorm (Bonaccorsi en Rossi 2003).
maar kiezen vaak voor een stemmingscomité voor de medeontwikkelaars of voor roulerend dictatorschap onder senior medeontwikkelaars. Dit gebeurt(de) respectievelijk bij de ontwikkeling van Apache Webserver Software en de programmeer taal Perl. Voor Apache is het ASF (Apache Software Foundation) opgericht, een non-profit vereniging voor het coördineren van ontwikkelingen.
Deze laatste projectstructuren wordt in de Open Source wereld niet geprefereerd, als onstabiel en lastig ervaren en daardoor weinig gebruikt (Raymond 2000b).
Doel Deelname Cohesie door Beëindiging
Belangengemeenschap Ontwikkeling capaciteiten van leden; kennis ontwikkelen en uitwisselen Vrije deelname. Door je aan te sluiten ben je lid
Passie, toewijding, identificatie met de experts in de groep Wanneer collectieve interesse verloren is, in Open Source: wanneer collectief probleem is opgelost Formele werkgroep Een product of dienst ontwikkelen Iedereen onder dezelfde manager Functieomschrijvin g en gezamenlijke doelen Bij eerstvolgende reorganisatie Projectteam
Het bereiken van een specifiek doel
Werknemers die door het topmanagement zijn aangewezen Project tussen doelen en doelstellingen Wanneer de projectdoelstelling is bereikt Informeel netwerk Het verzamelen en doorgeven van bedrijfsinformatie Vrienden, bekenden en zakenpartners Gezamenlijke behoeften
Wanneer men niets meer te halen heeft
Tabel 5-1: groepsconfiguraties volgens Wenger en Snyder
5.3.3 Systemen
Zoals reeds te lezen was is een OSS-ontwikkelgemeenschap te typeren als een belangengemeenschap, een type netwerkstructuur. Een netwerkstructuur kent volgens Lioubareva, 2005) geen duidelijke grens tussen klant en aanbieder. Hierdoor zijn andere coördinatiemechanismen van toepassing dan bij de marktconfiguratie (Lioubareva, 2005). In een marktconfiguratie is het onderscheid tussen klant en aanbieder duidelijk, coördinatie vindt voornamelijk plaats binnen een onderneming om zo efficiënt mogelijk af te kunnen zetten op de markt. Typerend hierbij is een top-down geplande hiërarchische organisatie van het ontwikkelproces. In het Open Source paradigma is dit vervangen door een gedecentraliseerde, bottom-up manier van werken zonder dwangmiddelen (Bonaccorsi en Rossi 2003). Het proces is adhoc, gedecentraliseerd en bijdrage is op eigen initiatief (Raymond, 2000a), dit is in overeenstemming met de typering van zoals Wenger en Snyder (2000) waarin zij stellen dat deelname aan een belangengemeenschap vrij is.
De regels, taken en plichten liggen binnen OSS-ontwikkelgemeenschappen niet vanaf het begin vast. Naarmate de omvang van een project toeneemt, komt leiderschap en bijbehorende autoriteit vanzelf tot stand op een bottom-up wijze door mate van inspanning en bijdrage aan het project (Bonaccorsi, A. en Rossi 2003).
Linus Torvalds, de initiator van het Linux besturingssysteem project, werkte volgens een simpele methode: geef vroeg vrij, geef vaak vrij en wees open over alles. Deze naïeve simpele structuur van kort opeenvolgende perioden van ontwikkelen en vrijgeven, mogelijk door het modulaire karakter van Open Source software, heeft een aaneenschakeling van cumulatieve ontwikkeling tot gevolg waardoor een soort Darwiniaans selectiesysteem van mutaties ontstaat (Gruen, 2005). Met andere woorden: het ontwikkelproces van Open Source software kent kort opeenvolgende iteraties van ontwikkelen, screening, ontwikkelen. Dit is ook het voornaamste coördinatiemechanisme en is de norm geworden in Open Source initiatieven sinds het Linux
besturingssysteem project.
Gevolg van weinig coördinatie en het ontbreken van vooraf vastgestelde taken en plichten is dat er parallelle ontwikkeling, van gelijke taken, kan ontstaan. Meerdere ontwikkelaars die met dezelfde taak bezig zijn. Parallelle ontwikkeling van verschillende taken kan ontstaan door het modulaire karakter van Open Source software.
Een ander, positieve bijkomstigheid van de geringe mate van coördinatie is dat er weinig administratieve rompslomp en bijkomende hoge kosten en tijdconsumptie is in OSS-ontwikkelgemeenschappen .
Naar mate een project volwassenheid bereikt zal het aantal werkzaamheden afnemen en zal uiteindelijk een kleine kern ontwikkelaars overblijven (Raymond a). In termen van Wenger en Snyder (2000) is dan de collectieve interesse dan verloren (of voldaan) en houdt de gemeenschap op te bestaan. Een kleine groep ontwikkelaars blijft zich echter veelal ontfermen over het project (denk aan verbeteringen doorvoeren, etc). Bij het mislukken van een project of wanneer interesse dermate afneemt dat niemand verder gaat met ontwikkelingen zal de groep ophouden te bestaan en blijft de tot dan ontwikkelde programmatuur publiek eigendom. De mogelijkheid blijft bestaan dat in de toekomst een ontwikkelaar de programmatuur opeist en ermee verder gaat, dan wel gebruikt voor nieuwe doeleinden, daarover onder Stijl van leiderschap meer.
Zoals reeds te lezen was zitten deelnemers van ontwikkelgemeenschappen (vrijwel) nooit fysiek bij elkaar. Mede daardoor wordt intensief gebruik gemaakt van communicatiemedia. Er vindt veel discussie plaats via fora, nieuwsgroepen, websites en chatboxes. Deze communicatie, op de chatboxes na, is asynchroon (Bonaccorsi en Rossi 2003) en heeft veelal een open karakter, dat wil zeggen dat iedereen die wil bijdragen dat kan doen. Doordat deelnemers aan ontwikkelgemeenschappen op fysieke afstand van elkaar werken, communicatie asynchroon verloopt en de werkzaamheden die uitgevoerd worden erg complex zijn, is communicatie erg ruisgevoelig. Om zoveel mogelijk ruis te voorkomen wordt kort, krachtig en zonder onnodige emotie gecommuniceerd.
Als gevolg van de communicatiemedia die in OSS-ontwikkelgemeenschappen worden gebruikt vindt codificatie van kennis plaats. Alles dat wordt gesproken is voor iedereen en ten alle tijden te raadplegen. Fora, nieuwsgroepen, en websites dienen als kennissysteem, databases waarin alle mogelijke informatie en gegevens over een project te raadplegen is. Doordat deze databanken ten alle tijden te raadplegen zijn, kan de ontwikkeltijd aanzienlijk worden verkort, het is immers niet meer nodig om te wachten tot een bron van informatie beschikbaar komt.
Belangrijk voor het voortbestaan van Open Source software zijn de (juridische) coördinatiemechanismen, de formele procedures/regels in het systeem. Binnen deze mechanismen vallen licentiemodellen, handelsmerken, participatie overeenkomsten versiebeheer systemen en handleidingen.
Licentiemodellen
De licentiemodellen van Open Source software zijn de tools die zorgen voor de institutionalisering van kennisdeling binnen OSS-ontwikkelgemeenschappen (Lioubareva, 2005). Dat wil zeggen dat het licentiemodel van de software bepaald in welke mate en hoe kennis wordt gedeeld. Lioubareva geeft een taxonomie van de licentiemodellen ingedeeld in drie hoofdgroepen/soorten.
Het copyleft (GPL) licentiemodel (copyleft is een woordspeling op het woord copyright), non-copyleft licentiemodellen en semi-vrije licentiemodellen. Alle drie stellen ze dat de code vrij toegankelijk is en dat men in staat moeten zijn code aan te passen. Divergentie van de code wordt daarmee door alle drie de licentiemodellen mogelijk gemaakt. De voornaamste verschillen zitten in het al dan niet toestaan van het opnemen van niet-open code in de Open Source code, met andere woorden, is het toegestaan dat delen van de code (in de toekomst) gesloten zijn?
Dat wil zeggen dat code altijd volledig open moet blijven. Dit is hoofdzakelijk om te voorkomen code in het evolutieproces steeds meer gesloten raakt. Non-copyleft licentiemodellen zijn hier minder streng in. Ze zijn zelf open, maar staan toe dat gesloten code opgenomen wordt (Lioubareva, 2005). De reden hiervoor is om uitwisselbaarheid, of compatibiliteit van code te vergroten. Sommige hardwareleveranciers zijn huiverig over het vrijgeven van technische details voor aansturing van hun product. Ze zijn bang dat ze daarmee hun concurrentiepositie op het spel te zetten. Het gevolg is dat deze hardware onder veel copyleft-software niet (correct) aangestuurd kan worden. Dit kan de adoptie van copyleft software tegengaan8.
Het copyleft licentiemodel stelt openheid voor iedereen en altijd veilig. Het niveau van convergentie (de compatibiliteit tussen de verschillende de software) blijft hierdoor beter gewaarborgd dan bij non-copyleft licentiemodellen (Lioubareva, 2005). Er wordt beweerd dat het bijdragen aan Copyleft licentie software hierdoor aantrekkelijker is.
Handelsmerken of logo’s
Handelsmerken, of merken, zijn woorden, afbeeldingen, geluiden of kleuren waarvoor geld dat de merkhouder het alleenrecht voor het gebruik ervan heeft9. Het wordt veelal gebruikt om producten te onderscheiden en bekendheid op te bouwen. Veel Open Source projecten hebben een (handels)merk geregistreerd, vaak verbonden aan een not-for-profit organisatie of vereniging. Logo’s gaan volgens Lioubareva (2005) divergentie tegen doordat ze het bandwagon effect versterken en doordat het moeilijk is om (met een afgesplitst project) aan populariteit te winnen ten aanzien van het al bekende project. Het bandwagon effect betekent dat mensen vaak dingen doen of geloven omdat de meerderheid van de mensen het doen of geloven. Dit wordt ook wel aangeduid als kuddegedrag10. Logo’s kunnen dit gedrag versterken doordat het bijdraagt aan het groepsgevoel (Krogh, Ichijo en Nonaka, 2000).
Participatieovereenkomsten
Bij sommige projecten dient een participatieovereenkomst getekend te worden voordat ontwikkelaars code mogen toevoegen aan een project. Door het tekenen van een dergelijke overeenkomst wordt de ontwikkelaar een officieel lid van de gemeenschap.
Wanneer men dergelijke overeenkomsten niet wil tekenen kan dat divergentie veroorzaken: een ontwikkelaar die weigert te tekenen kan de software downloaden en daarmee een eigen project starten, aan de andere kant geeft het tekenen van dergelijke overeenkomsten een groepsgevoel en dat gaat divergentie gaan.
Versiebeheer-systemen
In OSS-ontwikkelgemeenschappen kunnen veranderingen en verbetervoorstellen door iedereen aandragen worden. Deze veranderingen komen terecht in een selectieproces, uitgevoerd door de projectleider, die al dan niet in overleg bepaalt welke oplossing het beste past (Kogut en Metiu, 2001).
Software ontwikkeling is een complex proces: programma’s bestaan al snel uit duizenden regels
8 Persoonlijk ervaar ik dergelijke kwesties op mijn laptop. Zo worden de grafischekaart en de WiFi netwerkadapter respectievelijk incorrect en helemaal niet ondersteund door het copyleft Besturingssysteem dat ik gebruik. Gevolg is dat mijn laptop niet in staat is tot grafisch zware taken (dat wel mogelijk is onder het commerciële besturingssysteem op mijn laptop) en dat het niet mogelijk is om van een draadloos netwerk gebruik te maken.
9 http://nl.wikipedia.org/wiki/Handelsmerk 10 http://en.wikipedia.org.wiki/Bandwagon_effect,
code en het leveren van een bijdrage gaat vaak gepaard met het aanpassen van (delen van) bestaande code. Om alle wijzigingen met bijbehorende aantekeningen en opmerkingen te archiveren wordt gebruik gemaakt van versiebeheer-systemen (Egyedi en van Wendel de Joode, 2004). De twee grootste zijn momenteel CVS (Concurrent Versioning System) en de opvolger SubVersion. Deze tools stellen ontwikkelaars in staat te ontwikkelen in hun eigen stijl zonder bij te houden welke wijzigingen zij doorvoeren. Doordat dergelijke systemen in staat stellen tot het hanteren van persoonlijke ontwikkelmethoden/stijlen helpen zij convergentie te waarborgen. Lioubareva (2005) stelt namelijk dat ontwikkelaars sneller geneigd zullen zijn een project te verlaten wanneer dit niet mogelijk is.
Distributie-systemen
Om Open Source software projecten, hun status, de locatie van de broncode en de voortgang van ontwikkeling overzichtelijk te houden is er een distributie-systeem op het internet in de vorm van een website: Sourceforge.net. Op deze website wordt bijgehouden welke Open Source software projecten er zijn, waar men de website van de projecten kan vinden, waar de broncode te downloaden is en in welk stadium van ontwikkeling een project is. Daarnaast biedt het ontwikkelaars de mogelijkheid hun ideeën en eerste aanzetten tot een project te plaatsen om op deze manier geïnteresseerden aan te trekken.
Handleidingen en code
Andere vormen van coördinatie zijn beleidshandleidingen, technische handleidingen, styleguides voor programmeren en trainingsprogramma’s (Lioubareva, 2005). De vergelijking met indoctrinatie, formalisatie dringt zich op. Raymond (2000b) noemt dit acculturatie mechanismen. Bonaccorsi en Rossi (2003) spreken in dit geval over gecodificeerde tacite regels, die aan nieuwe ontwikkelaars worden verstrekt. Al deze tools hebben dezelfde functie als coördinatie mechanisme, ze vergroten de kans op een succesvolle uitkomst doordat ze overeenstemming in opvatting en doel bereiken (Lioubareva, 2005).
Ik zou de broncode zelf ook onder deze kop willen plaatsen, omdat de opbouw van software, in een specifieke programmeertaal, uit zichzelf ook een conventie of gemeenschappelijke taal is (Kasper, 2001), en op deze wijze als coördinatie mechanisme dient.
Commercie
Een laatste belangrijke vorm van coördinatie die het voortbestaan van Open Source software versterkt is de commercie. Hoe wordt een Open Source software product aantrekkelijk gemaakt voor het grote publiek als ontwikkelaars slechts hun eigen belang dienen en veelal techneut zijn? Hier komen veelal de hybride businessmodellen kijken: organisaties die geld verdienen aan het verfijnen van, het nuanceren van, innovaties om zo een groter publiek te dienen. Binnen dergelijke organisaties spelen traditionele coördinatiemechanismen. Het is interessant om te zien dat zelfs taken die minder intrinsiek gemotiveerd zijn in de wereld van Open Source software een manier vinden waarop ze uitgevoerd worden.
5.3.4 Significante waarden
De wereld van Open Source software staat in de ogen van velen (bijna) lijnrecht tegenover het businessmodel van veel commerciële organisaties. Onder de deelnemers van het Open Source ideaal bestaan twee houdingen tegenover het commerciële model, deze houdingen kenmerken de cultuur van OSS-ontwikkelgemeenschappen in twee subculturen: fanatisme en vijandigheid. Elke houding kent gradaties. Fanatisme komt in extreme mate voor (vrije software is alles en het enige dat telt) en in minder extreme mate (vrije software is interessant en de mensen die het maken