De ontwikkeling van open source software is anders en zal anders zijn bij de overheid. De motieven van ontwikkelaars om te participeren, de belangen van gebruiksorganisaties en de rol van publieke belangen zijn anders in een overheidscontext, stelt Arjan Widlak. Ook hoe de markt moet functioneren als onderdeel van dat ecosysteem is een zoektocht in volle gang. Want de overheid heeft belangen als gebruiker en als ontwikkelaar en bedrijven kunnen een rol hebben als aanbieders van oplossingen of personeel. Wat zouden de ontwerpprincipes van zo’n “community” of “ecosysteem” kunnen zijn?
Vorig jaar verscheen een onderzoeksrapport naar open source communities. Edo Plantinga betoogde dat dit rapport geen recht doet aan de werkelijkheid vanwege de onderzoeksopzet, de smalle nationale focus en de vergeten rol van bedrijven. Een actueel beeld, zegt Plantinga met gevoel voor humor, maar dan van twintig jaar geleden. Ook in termen van verouderde bronnen was het rapport weinig compleet. Zo is de dissertatie Understanding Open Source Communities – An organizational perspective van Ruben van Wendel de Joode uit 2005 over het hoofd gezien, maar nog altijd interessant.
Uitdagingen
Wat Van Wendel de Joode doet in zijn dissertatie is een aantal ontwerpprincipes uit de institutionele economie[1] toepassen op open source gemeenschappen. Het aardige van die benadering is, dat deze ontwerpprincipes redelijk tijdloos zijn als relevante aandachtspunten voor elke samenwerking over organisaties heen en dus ook voor de uitdaging die vandaag voor ligt. Die uitdaging is hoe de belangen van overheden onderling, gezamenlijk en in relatie met hun leveranciers kunnen worden uitgelijnd. En dat ook nog in heel verschillende contexten, met weinig centrale sturing.
‘De ontwikkeling van open source software bij de overheid vraagt om het doordenken van een institutionele basis’
De situatie voor gemeenten, die nu veelal werken met software in eigendom van bedrijven, is heel anders dan de situatie voor uitvoeringsorganisaties, die veelal werken met software die ze in grote mate in eigendom hebben. Tegelijk is nu wel duidelijk dat er niet “spontaan” een community ontstaat die de ultieme oplossing voor de hondenbelasting als open source software ontwikkelt en ondersteunt, zoals ik negentien jaar geleden al schreef.
De ontwikkeling van open source software bij de overheid zal anders zijn en vraagt niet – zoals Plantinga terecht schreef – om een verdieping van “een verouderd beeld ingegeven door naïef idealisme van een community van hobbyende nerds”. Dat vraagt om het doordenken van een institutionele basis die het mogelijk maakt om overheden en bedrijven in relatieve autonomie tot duurzame oplossingen te laten komen.
Gemeenschappelijke goederen
De dissertatie van Van Wendel de Joode start met een klassiek economisch onderscheid tussen goederen. Enerzijds goederen waarvan je mensen kunt uitsluiten of juist niet. Je kunt mensen uitsluiten van het gebruik van jouw mobiel, maar niet van de bescherming van de dijken. Anderzijds goederen waarvan de consumptie gezamenlijk kan of juist niet. Je kunt samen Netflix kijken, maar niet dezelfde ampul vaccin gebruiken. Er zijn dan vier soorten goederen te onderscheiden. Ten eerste de goederen die we allemaal kennen uit de supermarkt, private goederen. Daarnaast zijn er zogenaamde tol-goederen. Een typisch voorbeeld is een snelweg. Consumptie van de één gaat niet ten koste van de ander, maar met een tolpoortje zijn mensen wel uit te sluiten van gebruik.
‘Is niemand uit te sluiten van het gebruik van open source software?’
Gesloten commerciële software kun je ook zien als een tol-goed. Door het auteursrecht kunnen mensen uitgesloten worden van consumptie, maar in principe gaat consumptie van de één niet ten koste van de ander. Net als het tolpoortje introduceer je overhead en administratieve lasten waar niemand op zit te wachten, maar dat is noodzakelijk om een individuele partij de investering te laten realiseren. We zien weinig tolpoortjes in Nederland, omdat we er bij fysieke infrastructuur voor kiezen om met centrale coördinatie die noodzaak weg te nemen en zo tevens de negatieve neveneffecten (lasten, onproductieve arbeid) te mitigeren en de positieve neveneffecten te versterken (arbeidsdeling, handel).
Maar er zijn nog twee soorten goederen. Enerzijds goederen in gedeeld eigendom waarbij consumptie rivaliserend is. Dit is het terrein waarop Van Wendel de Joode’s inspiratie, Elinor Ostrom, de Nobelprijs voor de economie won. Zij beschreef hoe gemeenschappen het probleem van overgebruik gevolgd door uitputting toch onderling reguleren. Dit probleem is bekend als the tragedy of the commons. Zij – en vele anderen – beschreven voorbeelden waar het lukte om aan die tragedie te ontsnappen. Zo kan het gezamenlijk gebruik van water voor irrigatie plaatsvinden door de sluizen en dammen in te stellen met de mensen die op die dag water nodig hebben. In elk van die voorbeelden zijn institutionele mechanismen te vinden – duurzame regelmatigheden in het gedrag van mensen – die je kunt beschrijven aan de hand van regels. En dit zijn andere arrangementen dan de markt of de staat. Tenslotte beschrijft zij de overeenkomsten tussen die waaier aan voorbeelden aan de hand van een kleine set meer algemene ontwerpprincipes. Het zijn deze ontwerpprincipes die Van Wendel de Joode toepast op open source gemeenschappen.
‘Software is toch op geen enkele wijze rivaliserend?’
Uiteraard kun je je afvragen of open source software niet eerder in de vierde groep thuishoort, de publieke goederen. Want is het niet juist zo dat niemand van het gebruik van open source software is uit te sluiten, wanneer die eenmaal openbaar is gepubliceerd? Bovendien is software toch op geen enkele wijze rivaliserend? Ja, dat is zo. Tegelijkertijd is het niet voor niets zo dat het leger, de dijken en andere publieke goederen centraal gecoördineerd worden door de staat. Zonder centrale coördinatie komen zulke goederen niet tot stand. De reden om je toch te laten inspireren door de ontwerpprincipes van Ostrom is dan ook de afwezigheid van voldoende of gezaghebbende centrale coördinatie.
In dit deel beschrijf en bespreek ik de eerste twee ontwerpprincipes, in het tweede deel de andere vijf.
1. Duidelijke grenzen
Gemeenschappelijke goederen vragen om duidelijke grenzen. Dat zijn organisatorische grenzen, maar ook grenzen aan het gezamenlijke goed. Bij iets als water voor irrigatie is één van de belangrijkste redenen voor grenzen het reguleren van toe-eigening: wie mag hoeveel op welk moment gebruiken?
Gebruik van software daarentegen doet niets af aan het nut voor of de beschikbaarheid van anderen. Toch zijn ook bij een publiek goed als open source software duidelijke grenzen belangrijk, aldus Van Wendel de Joode. Ook hier kan toe-eigening door derden het gezamenlijke goed bedreigen, bijvoorbeeld via octrooi. En ook andere krachten van buiten kunnen het gemeenschappelijke goed bedreigen, zoals rechtszaken die het auteursrecht van de gemeenschap betwisten. Open source communities, zo beschrijft hij, initiëren daarvoor bijzondere institutionele arrangementen. De bekendste en meest evidente is natuurlijk de licentie, maar denk ook aan stichtingen die misbruik waarnemen en rechtszaken tegen individuele ontwikkelaars ondersteunen.
2. Regels voor productie en gebruik
Ontwikkeling en onderhoud van de software is de invulling die Van Wendel de Joode geeft aan het ontwerpprincipe van productie en gebruik. Er zijn mechanismen nodig voor samenwerking en coördinatie. Het equivalent van gezamenlijk dammen en schuiven zetten om water te verdelen zijn bij open source software bijvoorbeeld systemen voor versiebeheer, mailing lists, wens- en foutlijsten, handleidingen en richtlijnen voor codeerstijlen, maar ook het gedeelde streven naar elegantie, modularisatie en lijsten met de expliciete erkenning van bijdragen.
‘Als bijdragen moeilijk te begrijpen zijn, zijn ze kwetsbaar om overschreven te worden’
Het zijn veelal afspraken die alleen werken als iedereen ze ook gebruikt. Van Wendel de Joode beschrijft dit als de “paradox van de vrijwillige standaardisatie”. Het beperkt de autonomie en flexibiliteit van de individuele programmeur, maar toch gebeurt het vrijwillig.[2] Eén van de verklaringen daarvoor is de wens tot acceptatie van een bijdrage en de duurzaamheid daarvan. Er is een belang bij de ontwikkelaar dat de code waarin hij zijn tijd heeft geïnvesteerd ook onderdeel wordt van de distributie. Acceptatie is belangrijk, omdat bijdragen makkelijk te vervangen zijn. Dus als bijdragen naar de gemeenschappelijk afgesproken norm “slecht leesbaar” of “moeilijk te begrijpen” zijn, zijn ze kwetsbaar om overschreven te worden.
Betekenis voor de actuele uitdaging
Ook vandaag de dag zijn deze eerste twee ontwerpprincipes relevante aandachtspunten bij het vormgeven van het ecosysteem dat software duurzaam moet ontwikkelen en onderhouden. Enerzijds zijn grenzen altijd belangrijk om mensen een groepsgevoel te geven. Deelnemers willen zich kunnen identificeren en zich thuis kunnen voelen. Anders dan bij formele organisaties is toetreding tot open source gemeenschappen onbegrensd, zeker waar het gaat om het gebruik alleen.
Maar dit geldt ook als het gaat om bijdragen, althans, zolang je maar daadwerkelijk bijdraagt. En zolang uit dat werk ook kennis van zaken blijkt of je ten minste laat zien dat je leert als je die kennis niet bleek te hebben. Programmeurs groeien op met zulke principes (socialisatie) en dit versterkt op belangrijke manieren alle andere mechanismen die maken dat een gemeenschap duurzaam kan voortbestaan. Het zorgt ervoor dat alle gebruikers ook daadwerkelijk vruchten kunnen plukken van de gezamenlijke inspanning. Het zorgt ervoor dat de gemeenschap groeit en groeit met mensen met een behoefte aan kwaliteit en leren. Dit zijn belangrijke zelfversterkende factoren.
‘Er is een serieus risico dat bedrijven zeggen mee te willen werken, maar de code toch onder private controle willen brengen’
Anderzijds zijn deze factoren ook niet onbedreigd en zijn er in de voorliggende uitdaging ook nieuwe bedreigingen. Alle software bevat – als het goed – veel meer generieke onderdelen dan onderdelen specifiek voor toepassing in een bepaalde context. Echter de toepassingen bij de overheid zijn relatief bijzonder. Er is geen groep individuen en bedrijven die elkaar vinden in hun behoefte aan een besluitvormingssysteem voor toeslagen. Dat maakt dat de rol van betaling en opdrachtverlening veel belangrijker en bovendien de rol bedrijven in de gemeenschap anders van karakter. Als de rol van de overheid als ontwikkelaar klein is en als opdrachtgever groot, is er een sterke prikkel voor bedrijven om afhankelijkheden te introduceren. Afhankelijkheden die niet zozeer het open karakter bedreigen, maar wel het publieke karakter van de software. Er is een serieus risico dat bedrijven zeggen mee te willen werken, maar met handige trucs de code toch onder private controle (willen) brengen. Bijvoorbeeld door de basisdistributie te controleren of door een toets op veiligheid niet als dienstverlening te zien, maar onlosmakelijk te verbinden met controle over de code. Het is vaak niet makkelijk om dat direct te doorzien en vraagt daarom om institutionele arrangementen, bijvoorbeeld via een deskundige toets of evaluatie, uitgevoerd met enige regelmaat. Want waar het traditioneel bij open source gemeenschappen primair om openheid en samenwerking gaat, gaat het in deze context misschien wel evenzeer of meer om het voorkomen van private controle.
‘Grotere wendbaarheid is wellicht in het algemeen belang, maar niet per se in het organisatiebelang’
Ook de regels voor productie en gebruik vragen deels om heroverweging. Wat Van Wendel de Joode “de paradox van vrijwillige standaardisatie” noemt in open source gemeenschappen, is niet direct een mechanisme dat we herkennen uit overheidsland. En dat is te begrijpen. Hoe generieker software wordt, hoe minder die voorziening noodzakelijkerwijs is verbonden met een specifieke organisatie. Grotere wendbaarheid is wellicht in het algemeen belang, maar niet per se in het organisatiebelang. Net zoals private controle over de code softwareleveranciers een machtspositie geeft, zo geeft ook controle over een concreet systeem en de data daarin een specifieke overheidsorganisatie de zekerheid niet te passeren te zijn. Dergelijke perverse prikkels zijn onderdeel van de uitdaging om een werkend en duurzaam ecosysteem te scheppen. Er zullen specifieke mechanismen van coördinatie en samenwerking nodig zijn, die dit adresseren.
Gemiste kans
Het onderzoek naar open source communities van vorig jaar was een gemiste kans. Plantinga gaf in zijn reactie al aan dat dit in belangrijke mate ook aan de formulering van de opdracht lag. Het zou veel meer moeten gaan, zo zei hij, over ecosystemen en de zakelijke motieven van organisaties om open source software in te zetten. Een manier om de uitdaging en de mogelijke oplossingen te organiseren is aan de hand van de meer economisch ingestoken ontwerpprincipes die Ostrom en vele anderen terugzagen in honderden voorbeelden van het beheer van gemeenschappelijke goederen. De mechanismen die daarin gevonden zijn om dat goed en duurzaam te reguleren en om bedreigingen voor de samenwerking en de continuïteit daarvan te pareren kunnen een inspiratie zijn. En dat geldt ook voor de mechanismen die Van Wendel de Joode identificeert wanneer hij die toepast op open source communities, van versiebeheersystemen tot stichtingen die bescherming bieden aan zowel ontwikkelaars als het gezamenlijke goed. In het volgende deel bespreek ik de andere vijf ontwerpprincipes.
Voetnoten
[1]Het deel van de economie dat kijkt naar de rol van instituties bij het vormen van economisch gedrag en economische uitkomsten. Instituties zijn de (informele) afspraken die we beschrijven als regels waarmee we politieke, sociale en economische relaties organiseren.
[2]In Volwassen Digitale Overheid:63 is een overzicht te vinden van instituties naar probleemtype overgenomen uit Egyedi, T.M. & Widlak, A.C. (2019). Institutional Economics of Standards, Regulation and Innovation Effects. In: K. Jakobs & P. Morone (Eds.), EURAS proceedings 2019: Standards for a Bio-Based Economy (pp. 143-162), 13-15 June 2018, LUISS Guido Carli University, Rome, Italy.
Geef een reactie