Veel overheden, waaronder gemeenten, zijn volop bezig met de zoektocht naar digitale soevereiniteit en een transparante overheid. Een centraal thema daarin is het vermijden van vendor lock-in: de afhankelijkheid van één leverancier waardoor overstappen duur of complex wordt.
In die zoektocht komt open source vaak vanzelf bovendrijven. Het klinkt logisch: open code betekent toch dat je onafhankelijk en transparant kunt werken? Maar zo eenvoudig ligt het niet. Open source kan zeker bijdragen aan transparantie en soevereiniteit, maar lock-in ligt nog steeds op de loer — afhankelijk van hoe je ermee omgaat, of je zelf ontwikkelt of bestaande oplossingen hergebruikt, en hoe governance en eigenaarschap zijn ingericht.
Al bijna 25 jaar werk ik met en aan open source en heb ik ervaren hoe krachtig het kan zijn. Tegelijkertijd heb ik gezien dat de praktijk complexer is dan de belofte, en dat er scherpe keuzes nodig zijn.
In dit artikel verken ik waarom open source een belangrijke rol speelt in deze discussie, maar ook waarom het meer nuance vraagt — en waarom governance, licenties en eigenaarschap minstens zo bepalend zijn voor echte onafhankelijkheid.
De belofte van open source
Open source wordt vaak gepresenteerd als het tegengif tegen lock-in:
- Vrij gebruik, geen licentiekosten
- Vrije keuze van leverancier of zelfbeheer
- Innovatie vanuit een brede community
Voor bestuurders klinkt dit ideaal: onafhankelijk van grote cloudaanbieders en volledige grip op je digitale infrastructuur.
Maar wie beter kijkt, ziet dat open source-projecten vaak óók afhankelijkheden en vormen van lock-in kennen. Alleen zijn ze subtieler en minder zichtbaar.
De realiteit – risico’s bij hergebruik
Open source geeft technische vrijheid: de code is beschikbaar en je kunt in theorie altijd doorgaan door een fork (kopie/afgeleide) te maken. De praktijk is lastiger. Want heb je als organisatie ook de middelen en de bereidheid om dat te doen als licentievoorwaarden veranderen, een project stopt, of als de community een koers kiest die jou niet past?
Bij hergebruik zie je verschillende signalen die op nieuwe lock-in wijzen:
- Dominantie van één partij: één leverancier bepaalt in de praktijk de koers of ondersteuning.
- Veranderende licentievoorwaarden: nieuwere versies kunnen onder andere condities verschijnen.
- Afhankelijkheid van governance: als de spelregels niet open zijn, kan een enkele partij de macht houden.
- Zakelijke ondersteuning en gesloten add-ons: cruciale functies of support zijn soms alleen via één leverancier te krijgen.
Kortom: de vraag is niet alleen mág je de code gebruiken, maar vooral kun je invloed hebben en houden, en ben je bereid om zelf verantwoordelijkheid te nemen als het project met de oplossing of de besturing een kant opgaat die je niet wilt?
Hoe open source in de praktijk werkt, hangt sterk af van de governance: de manier waarop een project wordt bestuurd en hoe beslissingen worden genomen. Is dat breed gedragen door meerdere partijen, of vooral door één dominante partij?
Belangrijk om te benadrukken: deze risico’s spelen niet in elk open source-project. Er zijn ook tal van projecten waar de governance breed gedragen is en de community borg staat voor continuïteit. Deze risico’s zijn dus niet onvermijdelijk, maar ze vragen wél aandacht bij de keuze en inrichting.
Samenwerken aan hergebruik – keuzes voor overheden
Wanneer overheden en (semi)publieke organisaties bestaande open-source-oplossingen uit de markt willen hergebruiken, spelen andere overwegingen dan bij zelf ontwikkelen. De centrale vraag is: hoe wordt het hergebruik gezamenlijk georganiseerd?
- Samen kiezen voor één oplossing: Organisaties spreken af dat zij dezelfde oplossing gebruiken en ondersteunen. Dat kan efficiënt zijn. Voorwaarde is wel dat eigenaarschap en sturing niet bij één partij berusten, maar onafhankelijk en door meerdere organisaties te dragen zijn. Anders neemt het risico op afhankelijkheid van één leverancier (lock-in) toe.
- Werken met standaarden en meerdere oplossingen: Er wordt afgesproken aan welke standaarden oplossingen moeten voldoen, terwijl ruimte blijft voor verschillende implementaties. Dit vergroot de keuzevrijheid en verkleint afhankelijkheid, maar kan meer variatie in het gebruik betekenen.
Uitleg en openheid
Welke route ook wordt gekozen: het publiek moet kunnen zien waarom een keuze is gemaakt en op basis waarvan. In juridische termen gaat het om motiveringsplicht en transparantie: de keuze wordt deugdelijk onderbouwd en inzichtelijk gemaakt (bijvoorbeeld door het probleem, de bekeken opties, de criteria en de afweging kort vast te leggen).
Het type project en de organisatievorm zijn daarbij doorslaggevend. Als een oplossing is ondergebracht in een onafhankelijke stichting of vereniging (of vergelijkbaar), sluit gezamenlijke adoptie vaak goed aan. Als een project zwaar leunt op één leverancier, is het kwetsbaarder: de kans op lock-in en hogere overstapkosten neemt toe. In zulke situaties blijkt werken met standaarden vaak de veiligere route.
Effectief hergebruik begint met een inventarisatie van bestaande oplossingen en de manier waarop die zijn georganiseerd. Op basis daarvan kan een bewuste keuze worden gemaakt: gezamenlijk één oplossing (met stevig, gedeeld eigenaarschap) óf standaarden met meerdere alternatieven. Het helpt als de onderbouwing van die keuze beknopt wordt vastgelegd en openbaar beschikbaar is.
Samen ontwikkelen met de markt: gebrek aan scherpte
Ook wanneer overheden samen met marktpartijen open source ontwikkelen, is er nog veel ruimte voor verbetering:
- IP-recht: In veel projecten staat in de codebase één organisatie vermeld als rechthebbende. Maar dat is geen bewijs op zich: juridisch gezien ontstaat auteursrecht automatisch bij de maker, en contracten bepalen of en hoe dat wordt overgedragen. Het is daarom cruciaal dat de afspraken in contracten aansluiten bij wat in de repository wordt vermeld, en andersom. Als die consistentie ontbreekt, kan er onduidelijkheid ontstaan, juridische conflicten of zelfs ruimte voor een organisatie om de software later onder andere voorwaarden uit te geven.
- Governance: In een open source-project moet duidelijk zijn hoe rollen en verantwoordelijkheden worden verdeeld. Wie kan bijvoorbeeld maintainer worden en wie beslist daarover? Als dit in de praktijk alleen bij de oorspronkelijke bouwer ligt, ontstaat afhankelijkheid en wordt de markt gesloten. Goede governance beschrijft daarom niet alleen welke rollen er zijn, maar ook hoe je ze kunt verkrijgen en hoe onafhankelijk wordt bewaakt dat dit eerlijk verloopt. Alleen dan kunnen meerdere partijen gelijkwaardig meedoen en blijft de markt echt open.
- Contributies: Ook bij bijdragen van verschillende partijen moet helder zijn hoe met rechten en licenties wordt omgegaan. Houdt de auteur het IP-recht en wordt die expliciet als rechthebbende genoemd in de bestanden? Of worden de rechten formeel overgedragen aan het project? Daarnaast moet vaststaan dat bijdragen onder dezelfde licentie beschikbaar komen en dat de bijdrager bevoegd is om namens zijn of haar organisatie deel te nemen. Zonder zulke afspraken ontstaat er snel onduidelijkheid, wat de openheid en continuïteit van het project kan ondermijnen.
Het gevolg is niet altijd bewuste lock-in, maar door gebrek aan scherpte en afspraken gaan de voordelen van open source verloren en raken innovatie en samenwerking eerder geremd dan versneld.
Samen ontwikkelen tussen (semi)publieke organisaties: aanvullende complexiteit
Wanneer meerdere overheden samen een open source-project starten, wordt het al snel complexer. Er komen namelijk extra regels en juridische kaders bij kijken, bijvoorbeeld rond aanbestedingen en eigenaarschap. Die hebben direct invloed op hoe je een gezamenlijk project organiseert en inkoopt. Wie kiest voor formele samenwerking moet rekening houden met deze regels en verplichtingen.
1. Gezamenlijk opdrachtgeverschap: Hoe organiseer je gezamenlijk opdrachtgeverschap zonder dat je in de knel komt met aanbestedingsregels, zeker omdat centrale en decentrale overheden vaak met verschillende drempelwaarden en procedures werken?
2. Horizontaal of verticaal samenwerken: Samenwerking tussen gemeenten (horizontaal) of tussen gemeenten en de rijksoverheid (verticaal) klinkt logisch, maar mag niet altijd zomaar. Er zijn voorwaarden en beperkingen die bepalen wanneer dit formeel is toegestaan en hoe dit moet worden vastgelegd, bijvoorbeeld in een convenant.
3. Semipublieke organisatie aansluiten: Hoe kunnen semipublieke organisaties, maatschappelijke stichtingen of andere organisaties meedoen? Kunnen zij toetreden tot dezelfde afspraken, of zijn zij aangewezen op een eigen variant of commerciële afgeleide?
4. Intellectueel eigendom: Bij gezamenlijke ontwikkeling blijft iedere organisatie in principe eigenaar van wat zij zelf maakt. Je kunt dit eigenaarschap gezamenlijk vastleggen, zodat alle partijen samen houder zijn van de rechten. Een andere optie is om één gezamenlijke organisatie als houder aan te wijzen. In dat laatste geval moet iedere deelnemer via een aparte overeenkomst (zoals een Copyright Assignment Agreement) formeel de rechten overdragen. Welke route je ook kiest: het vraagt altijd om duidelijke en consistente afspraken, zodat later geen discussie ontstaat over wie wat met de code mag doen.
Deze voorbeelden laten zien dat gezamenlijke open source-ontwikkeling niet alleen een technisch en organisatorisch vraagstuk is, maar ook sterk juridisch gekleurd. Formele samenwerking kan nuttig zijn om commitment en gezamenlijke verantwoordelijkheid vast te leggen, maar brengt altijd complexiteit met zich mee.
Community-gedreven governance kan een alternatief bieden: een structuur waarin alle partijen gelijkwaardig kunnen meebeslissen en bijdragen — zonder afhankelijk te zijn van één leverancier, één opdrachtgever of ingewikkelde juridische constructies. Dit verlaagt de juridische drempels, stimuleert een open markt en houdt de codebase toegankelijk.
Maar dit werkt alleen als er bereidheid is bij zowel opdrachtgevers als marktpartijen om verantwoordelijkheid te delen en actief bij te dragen.
Samenwerking op zichzelf brengt ook uitdagingen met zich mee:
- Samenwerking en snelheid: Zijn opdrachtgevers (gezamenlijk) in staat om dicht bij elkaar te blijven wanneer behoeften uit elkaar lopen? Durven opdrachtgevers verschillen expliciet en publiek te maken — inclusief dat de oplossing meerdere varianten moet kunnen ondersteunen — om eindeloze besluitvorming te voorkomen? Is er bij formele samenwerking een helder mandaat of commissie die bij conflict beslist, of blijven besluiten hangen? Kan snelheid behouden blijven?
- Vraagarticulatie en expertise: Kunnen opdrachtgevers de vraag scherp, toetsbaar en afgebakend formuleren — inclusief wat buiten scope valt? Is de benodigde expertise aan opdrachtgeverzijde daadwerkelijk beschikbaar en gemandateerd (product, UX/onderzoek, architectuur, security/privacy, juridisch/inkoop), en wat gebeurt er bij uitval of wisselingen? Hoe worden botsende gebruikersbelangen (lokaal vs. landelijk) gewogen zonder te vervallen in “iedereen een beetje tevreden”?
- Vrijwilligheid of verplichting: Erkennen opdrachtgevers dat ‘freeriding’ in een vroege fase ook waardevol kan zijn (adoptie, massa, bewijs), en dat directe cofinancieringsplicht averechts kan werken? Hoe laten actieve kartrekkers of sleutelpartijen tijdelijke samenwerkingsafspraken over bijdragen ontstaan zonder het open-source karakter (afwisselende, vrijwillige bijdragen) te verliezen — en is dat op termijn vol te houden? Wanneer kantelt “vrijwillig en afwisselend” naar “eerlijke verdeelsleutels” en vervolgens naar "verplichtingen" — en wie bepaalt dat kantelpunt? Welke invloed houden kleinere opdrachtgevers als financiering ongelijk verdeeld is en grotere partijen de agenda (kunnen) bepalen?
Kortom: vraagstukken aan opdrachtgeverszijde — “hoe doen we dit met elkaar?” — dienen zich snel op, waardoor het gesprek over de inrichting van open source ondergesneeuwd raakt en community én codeontwikkeling door onduidelijkheid worden geremd. Bovendien, als de samenwerking een té verplicht karakter krijgt, dan dreigt de samenwerking de lock-in te worden.
Slotbeschouwing: community-gedreven governance als sleutel
Open source kan bijdragen aan transparantie en stimulatie van een open markt, maar alleen als governance en onafhankelijkheid goed zijn ingericht. Zonder heldere afspraken over IP, licenties en de rol van opdrachtgeverschap ligt lock-in nog steeds op de loer.
Community-gedreven governance, onafhankelijk van individuele opdrachtgevers of leveranciers, is daarom essentieel. Zo blijft de verantwoordelijkheid bij de community en blijft de codebase toegankelijk, ook wanneer contracten of samenwerkingen veranderen.
⚡️ De vraag is dus of we bereid zijn als overheden én marktpartijen om samen te investeren in community-gedreven governance, zodat open source niet alleen bijdraagt aan digitale soevereiniteit en transparantie, maar ook duurzaam samenwerken tussen overheden en markt én een efficiëntere overheid mogelijk maakt.
☕️ Zonder nieuwe lock-in aan de slag met open source? Ik ben beschikbaar als onafhankelijk adviseur. Stuur me een DM op LinkedIn en we plannen een koffie.
#opensource #digitalesoevereiniteit #transparantie #overheid #governance #vendorlockin #openstandaarden #commongroundnl