Het karakter van de OpenZaak community en de rol van codebase stewardship

Dit document bevat de initiele reflecties op het karakter van de OpenZaak community en de rol van codebase stewardship binnen OpenZaak die tijdens het traject naar voren zijn gekomen vanuit de stakeholders.

Inhoudsopgave

• Inhoudsopgave
• Inleiding: oorspronkelijke hypothese uit de marktconsultatie
• Wat zijn de karakteristieken van de OpenZaak-community?
• Hoe beïnvloedt deze vorm codebase stewardship?
  • Codebase stewardship – ‘vanilla’-variant
  • Codebase stewardship – ‘landelijke voorziening’-variant
  • Centrale git-hostingplatform?

Inleiding: oorspronkelijke hypothese uit de marktconsultatie

De governance van OpenZaak was ontworpen om meerdere zelfgemotiveerde partijen in staat te stellen deel te nemen aan de OpenZaak-community.

Dit gebeurde door open technische overleggen en product­stuurgroepvergaderingen te organiseren waaraan de community kon deelnemen.

Deze opzet was gebaseerd op de aanname dat marktpartijen zich proactief zouden inzetten als onderdeel van hun business development, en zo hun marktaandeel rond OpenZaak zouden vergroten.

Daarbij werd verondersteld dat overheden meerdere, relatief kleine opdrachten zouden uitschrijven die openstonden voor verschillende leveranciers, bijvoorbeeld voor ontwikkeling, onderhoud, hosting, implementatie en ondersteuning.

Wat zijn de karakteristieken van de OpenZaak-community?

Opensourcegemeenschappen verschillen sterk van karakter. Sommige bestaan uit samenwerkingen tussen grote multinationals, andere uit vrijwillige individuen, en weer andere uit gemeenschappen die samenwerken rondom een product van één bedrijf. Elk van deze modellen kent zijn eigen dynamiek en governancevorm.

OpenZaak is een duidelijk afgebakende component in een componenten-architectuur, specifiek ontwikkeld voor de Nederlandse context, onder beheer van de overheid, met een beperkt aantal marktpartijen (het ecosysteem). Het doel is (momenteel) niet zo veel mogelijk bijdragen van zo veel mogelijk partijen met de codebase als primair coördinatiepunt.

De nadruk ligt op ecosysteembeheer: gecoördineerd opdrachtgeverschap met één (of in de toekomst meerdere) marktpartij(en), waarbij afstemming tussen componenten essentieel is.

Dit verklaart waarom deze gemeenschap geen typische open community governance kent. De ambitie is bovendien om de aansturing in de toekomst vanuit landelijke regie te organiseren en de componenten gezamenlijk te exploiteren, en zo de samenhang tussen componenten te waarborgen.

Daarom wordt het merendeel van de ontwikkeling uitgevoerd door partijen die daartoe contractueel zijn aangesteld.

Hoe beïnvloedt deze vorm codebase stewardship?

Codebase stewardship – ‘vanilla’-variant

Open source als samenwerkingsmodel wordt vaak en met succes ingezet om samenwerking te faciliteren tussen partijen met uiteenlopende belangen. Dit kan gaan om duizenden vrijwillige ontwikkelaars, maar ook om drie tot vijf grote bedrijven die elk hun eigen commerciële belangen nastreven of zelfs met elkaar concurreren.

In dergelijke situaties is codebase stewardship gericht op het beschermen van de belangen van de codebase en de gemeenschap als geheel, als tegenwicht tegen de individuele belangen van deelnemers.

Als voorbeeld: open source databasesoftware MariaDB wordt gebruikt door partijen als Amazon, Tencent, Alibaba en Microsoft. Zij profiteren van elkaars investeringen in verbeteringen, terwijl zij tegelijkertijd elk hun eigen commerciële agenda hebben. De MariaDB Foundation (met een bestuur aangewezen door de betrokken bedrijven) beheert de codebase vanuit een relatief onafhankelijke positie om machtsconcentratie te voorkomen en samenwerking duurzaam te houden. Vergelijkbare modellen bestaan ook bij onder andere de Linux Foundation.

De Foundation for Public Code hanteerde een vergelijkbaar perspectief: als Nederlandse codebases worden hergebruikt door bijvoorbeeld Frankrijk, Duitsland en Italië, hoe voorkom je dan dat de belangen van één partij de samenwerking verstoren?

Ook tijdens de OpenZaak-marktconsultatie was dit een relevant uitgangspunt: open samenwerking tussen Maykin, implementatiepartners en andere ontwikkelpartijen - elk met hun eigen belangen - vraagt om een neutraal perspectief voor beslissingen in het belang van de codebase als geheel, wat uiteindelijk ook de gemeenten ten goede komt.

Codebase stewardship – ‘landelijke voorziening’-variant

Bij landelijke regie en gezamenlijk exploiteren geldt bovenstaande benadering niet één-op-één voor Common Ground-componenten, om de volgende redenen:

• er is sprake van één gecoördineerd opdrachtgeverschap; governance vindt niet uitsluitend op codebase-niveau plaats, maar ook op het niveau van landelijke regie en het componentportfolio;
• er bestaan nauwe afhankelijkheden tussen de componenten; zij staan of groeien niet volledig zelfstandig;
• sommige componenten implementeren Nederlandse wet- en regelgeving en zijn daarmee territoriaal gebonden en specifiek voor Nederlandse gemeenten;
• gezien het bovenstaande is het onwaarschijnlijk dat bedrijven spontaan een zelfstandig businessmodel rond een component ontwikkelen (al kan dit voor sommige componenten wel het geval zijn).

Dit betekent dat de ‘landelijke voorziening’-variant van codebase stewardship onder meer omvat:

• collectief producteigenaarschap (het verzamelen en prioriteren van behoeften, verzoeken en financiering);
• portfoliomanagement van componenten (afhankelijkheden, groeipaden, integratie);
• release management (roadmaps, planning, breaking changes);
• regie over het leveranciers-ecosysteem (samenwerking tussen ontwikkelpartij, reviewpartij, onderhoudspartij en SaaS-aanbieder, inclusief contract- en relatiemanagement);
• het beoordelen van het strategische afhankelijkheid en de volwassenheid van componenten om de benodigde mate van redundantie en bedrijfszekerheid te bepalen (bijvoorbeeld een tweede leverancier);
• het inschatten van realistisch schaalbaarheids- en hergebruikspotentieel, evenals het verwachte bijdragepotentieel van de community, wat richting geeft aan hoe open issue-trackers, roadmaps en besluitvorming worden ingericht.

Voor sommige componenten kan het voorkomen dat: a) één of meerdere marktpartijen direct diensten aan gemeenten willen aanbieden (bijvoorbeeld lokale versnelling of een specifieke feature voor één gemeente), of
b) een niet-gemeentelijke of internationale partij wil deelnemen.

In zulke gevallen moet worden geëvalueerd of deelname aan de samenwerking de codebase versterkt (meer investeringen en kennis) of juist belemmert (meer complexiteit dan de opbrengst rechtvaardigt). Deze afweging zal per component en per gemeenschap moeten worden gemaakt.

Wanneer landelijke regie en gezamenlijk exploiteren de uitgangspunten zijn, is de klassieke kernwaarde van codebase stewardship – het beschermen van de codebase tegen de invloed van één dominante partij – geen primair optimalisatiedoel. Er is immers één duidelijk leidend belang: dat van de landelijke regie.

Wel kan ruimte worden gelaten voor deelname door andere partijen, bijvoorbeeld andere Nederlandse of buitenlandse overheidsinstellingen, voor zover het de moeite waard is om hun belangen te bemiddelen met die van de landelijke regieorganisatie. In dat geval kan ‘vanilla’ codebase stewardship alsnog relevant zijn, maar dan misschien eerder op platformniveau (bijvoorbeeld via een entiteit als de Stichting Platform Zaakgericht Werken) dan op het niveau van individuele componenten.

Centrale git-hostingplatform?

Het lijkt zinvol dat vanuit landelijke regie wordt voorzien in:

• één centrale plek met een overzicht van alle componenten en hun versies;
• een expliciete beschrijving van afhankelijkheden tussen componenten;
• gestructureerde communicatie richting implementatie- en hostingpartners over releases, bug fixes, breaking changes en roadmaps.

Dit biedt een kans om een proof of concept te ontwikkelen rond portfoliomanagement van componenten binnen één git-hostingplatform:

• het beschikbaar maken van de laatste stabiele releases van alle componenten (bijvoorbeeld als downstream clones of als upstream repositories);
• het expliciet modelleren van afhankelijkheden tussen versies;
• het verkennen van effectieve vormen van communicatie richting hergebruikers.