Zeven ontwerpprincipes voor open source communities bij de overheid (deel 1)

Beeld: Shutterstock

De ontwikkeling van open source software is 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. Ook hoe de markt moet functioneren als onderdeel van dat ecosysteem is een zoektocht in volle gang. Want de overheid heeft belangen als gebruiker 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?

Volgens Edo Plantinga deed het onderzoeksrapport naar open source communities geen recht aan de werkelijkheid vanwege de onderzoeksopzet, de smalle nationale focus en de vergeten rol van bedrijven. ‘Een actueel beeld’, schrijft 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.

Wat Ruben van Wendel de Joode doet in zijn dissertatie is een aantal ontwerpprincipes uit de institutionele economie¹ 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 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 een community die de ultieme oplossing voor de hondenbelasting als open source software ontwikkelt en ondersteunt niet “spontaan” ontstaat, schreef ik negentien jaar geleden al. 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 een het doordenken van een institutionele basis die het mogelijk maakt om overheden en bedrijven in relatieve autonomie tot duurzame oplossingen te laten komen.

Verschillende soorten goederen

De dissertatie van Van Wendel de Joode start bij 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 vier soorten goederen te onderscheiden:

• Private goederen: goederen die we allemaal kennen uit de supermarkt, .
• 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. 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.
• Gemeenschappelijke goederen: goederen in gedeeld eigendom, waarbij consumptie rivaliserend is.
• Publieke goederen: goederen die niet rivaliserend en niet uitsluitbaar zijn en die centraal gecoördineerd worden door de staat, zoals het leger en de dijken. Zonder centrale coördinatie komen zulke goederen niet tot stand.

Gemeenschappelijke goederen

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

Uiteraard kun je je afvragen of open source software niet eerder in de vierde groep thuis hoort, 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 publieke goederen centraal gecoördineerd worden. 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.

De eerste twee ontwerpprincipes

In dit artikel beschrijf en bespreek ik de eerste twee ontwerpprincipes. In een volgend artikel de restende ontwerpprincipes.

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 voorgrenzen het reguleren van toe-eigening: wie mag hoeveel op welk moment gebruiken. Gebruik van software daarentegen doet niets af aan het nut 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 [2]. 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, mailinglists, wens- en foutlijsten, handleidingen en richtlijnen voor codeerstijlen, maar ook het gedeelde streven naar elegantie, modularisatie en lijsten met de expliciete erkenning van bijdragen.

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 [3]. 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 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 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 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 met handige trucs 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 . 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.

Slotwoord

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 een volgend deel bespreek ik de andere vijf ontwerpprincipes.

[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] Via octrooi kan gebruik van een bepaalde techniek effectief worden gemonopoliseerd. Al is er wettelijk geen octrooi op software op zichzelf mogelijk, door opeenvolgende jurisprudentie is dit nu in bepaalde gevallen toch mogelijk.
[3] 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.

Arjan Widlak is directeur van Stichting Kafkabrigade en publiceert op het snijvlak van technologie en publieke waarden.

Klik HIER om het tweede deel van het artikel te lezen