Zeven ontwerpprincipes voor open source communities bij de overheid

Hoe moet een gezond ecosysteem rond open source software bij de overheid eruitzien? Edo Plantinga riep eerder op de aandacht daarbij minder te richten op een achterhaald beeld van communities van hobbyende nerds en meer op de zakelijke motieven om open source software in te zetten. In dit tweede deel vervolgt Arjan Widlak de bespreking van zeven ontwerpprincipes voor open source communities bij de overheid.

In het vorige deel werden de eerste twee ontwerpprincipes geïntroduceerd. Het zijn principes die Ruben van Wendel de Joode in zijn dissertatie ontleent aan Elinor Ostrom. Ostrom beschrijft hoe groepen ook zonder de coördinatie van markt of staat het gebruik van gemeenschappelijke goederen weten te reguleren. De overeenkomstige principes die zij vond, past Wendel de Joode toe op open source communities.
Ook open source communities hebben duidelijke grenzen nodig – dit is het eerste principe. Want ook open source communities hebben te maken met bedreigingen van buiten. Zo kan octrooi het gebruik van bepaalde technieken bedreigen, al is er wettelijk geen octrooi mogelijk op software op zichzelf.[1] Ook rechtszaken die het auteursrecht van de gemeenschap betwistten speelden regelmatig in de periode die Van Wendel de Joode onderzocht. Open source communities ontwikkelden daarvoor eigen institutionele arrangementen, zoals stichtingen die misbruik waarnemen en rechtszaken ondersteunen.

Ook hebben open source gemeenschappen eigen regels voor productie en gebruik, het tweede principe. Er zijn allerlei nieuwe mechanismen voor samenwerking en coördinatie te zien, zoals systemen voor versiebeheer, mailinglijsten, wens- en foutlijsten, expliciete erkenning van bijdragen en modularisatie. Van Wendel de Joode beschrijft de vrijwillige naleving aanvankelijk als “de paradox van vrijwillige standaardisatie”, die hij later verklaart vanuit de noodzaak van acceptatie van code. Want “foute” code is in dit systeem makkelijk te vinden en te vervangen.

3. Mechanismen voor conflictoplossing
Het potentieel voor conflict is in open source gemeenschappen zeer hoog. Duizenden mensen, tientallen, soms honderden betrokken organisaties, afkomstig uit allerlei landen, met verschillende motieven, zijn allemaal van elkaar afhankelijk om de software te maken en onderhouden. Nu kan conflict, zo leert de literatuur, veel positieve effecten hebben. Conflict voorkomt groupthink en stimuleert het overwegen van alternatieven. Conflicten kunnen de productiviteit verhogen, omdat alle betrokkenen beter begrijpen wat het probleem is en de creativiteit wordt gestimuleerd. En tenslotte – al klinkt het paradoxaal – zorgt conflict ook voor meer stabiliteit en balans in de gemeenschap, omdat niemand al te makkelijk z’n belangen kan doordrukken. (In de terminologie van vandaag ‘tegenmacht’). Tegelijk kan conflict ook buitengewoon disfunctioneel worden, vooral als het minder gaat om het probleem en meer om de persoon.

De rol van traditionele institutionele mechanismen als mediation en arbitrage, zo neemt Van Wendel de Joode waar, is zeer beperkt. Zelfs in grote gemeenschappen als de Linux-kernel, Apache of Debian, die besturen hebben en projectmanagement commissies. In open source communities zijn institutionele mechanismen ontwikkeld die meer gericht zijn op het (beleefd) ontwijken van de negatieve gevolgen van conflict, dan op het echt oplossen daarvan. Conflict wordt veelal genegeerd of geparkeerd. Wie praat over nieuwe of andere functionaliteit, krijgt een plekje op een wensenlijst. Er heerst een cultuur van doen. Als er twee opvattingen zijn, maar slechts één werkende oplossing, dan is de keuze al gemaakt. Ook heerst er een cultuur van bewijs. Laat zien dat het beter kan, met een werkende oplossing, dan kan iedereen zich een geïnformeerd oordeel vormen. Bij de gratie van versioning-systemen, zoals Git, zijn parallelle ontwikkellijnen mogelijk. Ook een parallelle distributie voor de conservatievere commerciële partijen maakt het mogelijk om verschillende belangen te accomoderen. Dit is allemaal niet per se efficiënt, maar vergroot wel ieders onafhankelijkheid zonder de synergie – bugfixing bijvoorbeeld – te verliezen.
We zien, zo zegt Van Wendel de Joode, vooral dat deze mechanismen een manier zijn om stagnatie te voorkomen. Om niet vast te blijven zitten in conflict of discussie, waardoor de continuïteit verloren zou kunnen gaan.

4. Collectieve keuzes
Ostrom onderscheidt verschillende niveaus waarop regels werken. Operationele regels begrenzen het individu. Op een hoger niveau worden die operationele regels vastgesteld via een besluitvormingsproces. Echter élk mechanisme dat individuele voorkeuren vertaalt in collectieve is een besluitvormingsproces. Ook hier, zo neemt Van Wendel de Joode waar, zijn bekende en traditionele mechanismen van weinig betekenis. Er wordt gestemd, maar dat is een ritueel. Deelnemers voelen zich zelden gebonden. Er zijn projectleiders, maar ze worden vaker niet dan wel gevolgd in hun preferenties. Collectieve besluitvorming komt veel vaker voort uit historische en organische processen. Licenties worden gekozen bij de start van een project. Alternatieve oplossingen in een project worden geselecteerd via ontwikkelactiviteit. Projecten worden populair of minder populair door zelfversterkende effecten als betrokkenheid van ontwikkelaars met een goede reputatie of de populariteit zelf.

Collectieve besluitvormingsprocessen zijn, kortom, de resultante van individuele handelingen, meer dan beslissingen. Juist omdat participanten niet gebonden zijn, is het individuele gedrag en de collectieve uitkomst eerder te vergelijken met het gedrag van een zwerm. Deelnemers laten zich leiden door “tags” of symbolen die indicaties zijn van kwaliteit, elegantie of continuïteit. Daar gaan ontwikkelaars aan de slag en die (wisseling van) participatie bepaalt de uitkomst.
Van Wendel de Joode problematiseert het begrip “consensus” en constateert dat dit in de praktijk de acceptatie is van het proces dat leidt tot een bindende uitkomst op operationeel niveau. Het leiderschap van projectleiders is eerder een nuttige mythe en stemmen eerder een ritueel. Beiden kunnen een “tag” opleveren, een indicatie, naast vele andere tags. Het handelen, via exit of bijdragen, bepaalt de collectieve uitkomst.

5. Monitoring en sanctionering
Vele kleine vergrijpen van de operationele regels komen regelmatig voor in open source gemeenschappen. Tegelijk komt sanctionering via formele mechanismen, zoals het ontnemen van de mogelijkheid om code toe te voegen, nauwelijks voor. Van Wendel de Joode verklaart dat vanuit de rol van sociale controle.[2] Die is groot, omdat iedere participant ook een toezichthouder is. De transparantie is buitengewoon groot, want wijzigingen zijn voor iedereen zichtbaar, ontwikkelaars worden automatisch op de hoogte gehouden en gebruik betekent dat de software wordt getest. Bovendien zijn er vele redundante mechanismen, waardoor er niet snel een bedreiging is voor de continuïteit.

6. Meerdere lagen in een geneste onderneming
Grote projecten, zoals Linux of Apache, zijn enorm complex. Het gaat om miljoenen regels code, verschillende distributies, duizenden ontwikkelaars en miljoenen gebruikers. De mechanismen om hiermee om te gaan vertonen grote gelijkenis met die van de moderne bureaucratie, zoals ook Emiel Rijshouwer meer recent concludeerde in zijn dissertatie over de evolutie van het anti-hiërarchische en anti-bureaucratische Wikipedia.[3] Taakspecialisatie, waardering van kennis en promotie op basis van kennis spelen een hoofdrol. Ervaren en gerespecteerde ontwikkelaars maken uiteindelijk de verbinding tussen modules en activiteiten mogelijk. Het belangrijke verschil is, aldus Van Wendel de Joode, dat deze werkverdeling in een open source community een emergent proces is. Ontwikkelaars kiezen zelf wat ze doen. Complexe taken leveren veel waardering op en trekken de ervaren ontwikkelaars aan. Ontwikkelaars kiezen ook zelf wat ze laten, zodat er ruimte is voor anderen om te leren en te groeien door die taken succesvol af te ronden.

7. Externe erkenning
Tenslotte speelt externe erkenning een rol. De open source community moet kunnen en mogen bestaan in de context waarin ze zich bevindt. Discussies die al ten tijde van Van Wende de Joode’s onderzoek speelden, spelen nog altijd. Zoals discussie over de veiligheid van open source software of de mate van innovatie. Het zijn discussies met vaak weinig nuance en veel retoriek en regelmatig verdachtmakingen. Ook hier zijn eigen institutionele arrangementen ontstaan. Met een “Developers Certificate of Origin” verklaren ontwikkelaars bij sommige projecten met hun bijdrage dat zij de code onder de betreffende open source licentie mogen brengen. De Linux Standard Base is een voorbeeld, de aanstelling van projectleiders of soms zelfs het oprichten van hele marketingafdelingen.

De conclusies van het onderzoek
De vraag in het onderzoek was hoe open source communities zijn georganiseerd. In de tabel – onder dit artikel – laat Van Wendel de Joode zien dat er maar een beperkt aantal gedragsregels nodig is om de zelforganisatie in een community te begrijpen. De regels zijn gebaseerd op de notie dat ontwikkelaars hun eigen nut proberen te maximaliseren, al is dat nut niet per se in geld uit te drukken. De gedachte dat keuzegedrag, bepaald door een beperkt aantal regels, tot fixatie en stagnatie zou leiden is onjuist. Dezelfde regels hoeven niet voor iedereen tot dezelfde keuzen te leiden omdat enerzijds de regels zelf ambigu zijn en anderzijds de individuele preferenties verschillen. Van Wendel de Joode komt zo tot een eenvoudig en elegant antwoord op zijn onderzoeksvraag.

Van Wendel de Joode zelf waarschuwt om zijn model niet zomaar te gebruiken om nieuwe en succesvolle communities te ontwerpen en dat het niet zomaar in een andere context en sector is in te zetten. De aanwezigheid van zelforganisatie, zo schrijft hij, betekent dat de communities niet of nauwelijks maakbaar en kopieerbaar zijn. Enerzijds heeft hij daarin natuurlijk gelijk. Anderzijds doen open source communities zelf precies dit. Zij proberen met de inzet van specifieke institutionele en technisch-institutionele mechanismen specifieke doelen te bereiken. Samenwerking en coördinatie door de ontwikkeling van versioning-software, zoals Git. Het verleiden van ontwikkelaars om bij te dragen door de bestaande code beschikbaar te stellen via open source licenties. Zijn waarschuwing betekent vooral: succes is niet vooraf zeker.

De opgave van vandaag
De ontwerpprincipes van Ostrom, toegepast en deels vertaald door Van Wendel de Joode zijn inspirerend omdat ze een kader kunnen vormen voor de zoektocht naar de institutionele mechanismen die nuttig en nodig zijn voor een gezond open source ecosysteem voor overheidssoftware. Uiteraard zullen dat instituties zijn waarvan moet blijken of ze werken of niet. Als iets een innovatieproces is, en een sociaal innovatieproces, is het dit. Tegelijk kan daar – mede dankzij zo’n overzichtelijke set ontwerpprincipes – ook best gestructureerd over nagedacht worden.
Er is zonder meer een analogie te trekken tussen bedrijven die een commerciële en meer conservatieve distributie aanbieden die zich voornamelijk richt op bugfixing en de behoeften van overheden die graag een langer interval wensen tussen veranderingen. Er kan gestructureerd nagedacht worden over de rol van licenties, die vooral de rechten regelen en het belang om te documenteren dat ontwikkelaars ook het recht hebben om code bij te dragen.[4]
Ook is er een parallel te zien tussen het autonome gedrag van individuele ontwikkelaars en het autonome gedrag dat uitvoeringsorganisaties laten zien in de digitalisering van de overheid. Daar is enerzijds een enorme synergie mogelijk, maar ook een grote mate van autonomie gewenst. De collectieve keuzes die we maken in de ontwikkeling van de digitalisering van de overheid zijn misschien ook wel beter te beschrijven als een resultante van het autonoom handelen van een zwerm uitvoeringsorganisaties dan als het gevolg van daadwerkelijke collectieve besluitvorming. En binnen gezonde kaders is het denkbaar om dat ook meer ten positieve te gebruiken.
De oproep van Plantinga, om deze discussie opnieuw te voeren, maar nu aan de hand van ecosystemen en zakelijke motieven en meer actueel onderzoek daarnaar, heeft beperkt gevolg gekregen. Wellicht ook omdat de vraag te groot en alomvattend lijkt. De ontwerpprincipes van Ostrom kunnen dat misschien meer hanteerbaar en overzichtelijk maken.

Voetnoten
[1]Ten tijde van de dissertatie van Van Wendel de Joode was software-octrooi een hot issue. In bepaalde gevallen heeft opeenvolgende jurisprudentie het toch mogelijk gemaakt software op zichzelf te octrooieren. Maar belangrijker nog was de financieel-juridische slagkracht waarmee destijds sommige bedrijven soms communities bedreigden. Daarnaast was er ongelijkheid in de moeite die het kostte om een octrooi aan te vragen, wat in Europa centraal kon, en de moeite die het kostte om octrooi te bestrijden, wat in elke lidstaat individueel moest. (Vermoedelijk is dit nog altijd zo).

[2]Van Wendel de Joode benoemt dit zelf niet letterlijk zo, in plaats daarvan beschrijft hij sociale controle als mechanisme. Zie ‘sanctionering’ in de tabel onder dit artikel.

[3]Emiel Rijshouwer, Organizing Democracy, 2019, PhD.

[4]Ik neem me voor om in de toekomst een artikel te schrijven over hoe licenties, contributor licence agreements, developer certificates of origin en het werkproces zelf zich verhouden.