Open Source is meer dan code delen

We dachten dat het genoeg was. Code op een repository zetten. Open source verklaren. Klaar. Hergebruik geregeld, vendor lock-in opgelost, digitale autonomie bereikt.

Digitale autonomie bereik je niet met een README. De beleidsmedewerker, de projectleider - die willen niet door repositories bladeren. Wat kan het? Wat kost het? Wie kan het leveren? Hoe doe ik mee? Niet meer van nerds voor nerds, maar van nerds voor de Nederlandse samenleving.

Open source gaat over mensen, niet over code. Over ambtenaren die elkaar op weg helpen om met open source van start te gaan. Over leveranciers die open source simpel maken met SaaS. Over bestuurders die digitale autonomie waarmaken.

Dit kompas helpt je verder. Met concrete stappen die je vandaag kunt zetten. Van het eerste gesprek over samenwerking tot het starten van een actieve community. Van het kiezen van een licentie tot het organiseren van financiering.

Want open source werken begint waar de code eindigt.

Mijn naam is Flori. Ik help open source samenwerkingen groeien – van code naar community. Ik heb dit kompas geschreven voor VNG Realisatie en werk hier aan een vernieuwde versie waarmee je direct kunt bouwen aan je samenwerking: van theorie naar actie. En, uiteraard vrij te gebruiken onder creative commons licentie (CC BY-SA 4.0).

Klaar om te beginnen? Gebruik het menu aan de linkerkant om door het kompas te navigeren.

Licentie

Licentie

Dit werk is een afgeleide versie van de Handreiking intergemeentelijk samenwerken rondom open source door VNG Realisatie (v0.2.2, © 2025), beschikbaar onder CC BY-SA 4.0.

Deze versie (v0.3.0) is aangepast door Rebel Alliance en gepubliceerd onder dezelfde CC BY-SA 4.0 licentie.

Eigen versie maken? Verwijs naar VNG Realisatie als oorspronkelijke auteur en publiceer je werk onder CC BY-SA 4.0.

Datum: 29 januari 2026

Versiebeheer

Mis je informatie of heb je best practices om toe te voegen?

Inleiding

Waarom dit kompas?

Steeds meer gemeenten werken samen aan open source software-oplossingen. Deze samenwerking biedt grote voordelen: kennisdeling, minder vendor lock-in, en meer regie op de doorontwikkeling. Maar hoe organiseer je zo’n samenwerking goed? Welke afspraken moet je maken? Hoe regel je de financiën?

Deze kompas helpt gemeenten bij het opzetten van samenwerkingsafspraken rondom open source software. Het bevat checklists, beslishulpen, templates en praktijkvoorbeelden, waardoor je zonder diep inhoudelijke kennis direct aan de slag kan.

Voor wie is deze kompas?

Deze kompas is bedoeld voor:

• Gemeenten die willen starten met een intergemeentelijke samenwerking rondom open source software
• Gemeenten die een bestaande informele samenwerking willen formaliseren
• Coördinerende gemeenten die hun samenwerking beter willen structureren
• Beleidsmakers, juristen en IT-professionals die betrokken zijn bij gemeentelijke samenwerkingen

Je hoeft geen expert te zijn in open source of juridische zaken. De kompas begeleidt je stap voor stap door alle belangrijke onderwerpen.

Hoe gebruik je deze kompas?

Drie manieren om deze kompas te gebruiken

1. Van begin tot eind (aanbevolen bij nieuwe samenwerkingen)

Als je een nieuwe samenwerking opstart, doorloop dan alle stappen in volgorde. Elke stap bouwt voort op de vorige. Begin met het bepalen van jullie ambitie (Stap 1) en werk door naar de operationele details.

2. Specifieke onderwerpen opzoeken (als je al een samenwerking hebt)

Als je al samenwerkt maar specifieke vragen hebt, ga dan direct naar de relevante stap. Wil je bijvoorbeeld jullie financieringsmodel herzien? Ga naar Stap 4. Onduidelijkheid over governance? Zie Stap 3.

3. Als checklist bij formaliseren (voor bestaande informele samenwerkingen)

Werk je al samen maar informeel? Gebruik de kompas dan als checklist om te kijken wat je al geregeld hebt en wat nog ontbreekt. Waarschijnlijk kun je enkele stappen overslaan omdat jullie daar al goede afspraken over hebben.

Niet alles is altijd nodig

Deze kompas is uitgebreid en dekt alle mogelijke aspecten van gemeentelijke samenwerking. Dat betekent niet dat je alles moet doen!

De benodigde complexiteit hangt af van:

• Jullie ambitieniveau: Lichte coördinatie heeft minder structuur nodig dan volledige regie
• Aantal deelnemers: Met 3 gemeenten kun je informeler werken dan met 25
• Strategisch belang: Kernsystemen vragen meer formalisering dan kleine tools
• Budget: Zonder geldstromen is financiële administratie overbodig

Tip: Start eenvoudig en bouw uit naarmate de samenwerking groeit. Beter een simpele afspraak die werkt dan een complex systeem dat niemand begrijpt.

Tips voor effectief gebruik

• Lees eerst Stap 1: Dit helpt je bepalen welke andere stappen relevant zijn
• Gebruik het als gespreksonderwerp: Bespreek de stappen met je collegagemeenten
• Pas aan op jullie situatie: Zie het als inspiratie, niet als keurslijf
• Kom er later op terug: Evalueer jaarlijks of jullie afspraken nog passen

Opbouw van de kompas

De kompas is opgebouwd in vijf delen met in totaal 10 stappen. Elk deel behandelt een ander aspect van de samenwerking:

Deel 1: Fundament leggen

Begin hier. Dit deel helpt je de basis te bepalen.

Stap 1: Bepaal jullie samenwerkingsambitie

Hoeveel regie willen jullie op de doorontwikkeling? Dit bepaalt hoeveel je moet organiseren. Behandelt vier ambitieniveaus: van ‘delen zonder regie’ tot ‘volledige regie’. Inclusief beslishulp.

Stap 2: Verdeel rollen en taken

Wie doet wat? Overzicht van taken per ambitieniveau, RACI-matrix.

Deel 2: Governance & Financiën

Hoe nemen jullie besluiten en financieren jullie de samenwerking?

Stap 3: Kies een governancemodel

Hoe nemen jullie besluiten? Behandelt overlegstructuren (van eenlaags tot drielaags), besluitvormingsmethoden (consensus, stemmen, mandaat) en waarover jullie moeten besluiten.

Stap 4: Kies een financieringsmodel

Betalen gemeenten een bijdrage en hoe verdeel je kosten? Behandelt de keuze voor wel/geen communitybijdrage en vier verdeelsleutels: gelijk, naar inwoners, naar gebruik, of hybride.

Deel 3: Community

Hoe organiseer je de samenwerking met gebruikers en leveranciers?

Stap 5: Bouw en onderhoud de community

Hoe betrek en ondersteun je gebruikers? Onboarding nieuwe gemeenten, communicatie, gebruikersbijeenkomsten en kennisdeling.

Stap 6: Organiseer samenwerking met de markt

Hoe werk je met leveranciers? Behandelt het creëren van een gezonde markt van leveranciers, ter voorkoming van vendor lock-in.

Deel 4: Juridisch

Regelt de formele kant: overeenkomsten en eigendom.

Stap 7: Stel een samenwerkingsovereenkomst op

Wat leg je vast en hoe? Overzicht van alle onderwerpen die in de overeenkomst moeten: van partijen en doel tot duur en beëindiging. Praktische tips over ondertekening en bijlagen.

Stap 8: Regel intellectueel eigendom

Wie is eigenaar van de code? Beschrijft twee eigendomsmodellen, de rol van open source licentie, en hoe om te gaan met bijdragen van gemeenten en leveranciers.

Deel 5: Technisch

Richt de technische basis in voor samenwerking aan code.

Stap 9: Kies een open source licentie

Welke licentie past bij jullie software? Uitleg van het verschil tussen permissieve (MIT, Apache) en copyleft (EUPL, GPL, AGPL) licenties. Inclusief vergelijkingstabel en beslishulp.

Stap 10: Richt technische infrastructuur in

Waar staat de code en hoe werken jullie samen? Behandelt repository platforms (GitHub, GitLab), branching strategieën, code review, documentatie, release management en issue tracking.

Snelzoeker: welke stappen zijn voor mij relevant?

Gebruik onderstaande tabel om snel te zien welke stappen je nodig hebt, afhankelijk van jullie situatie:

Tot slot

Deze kompas is tot stand gekomen op basis van ervaringen uit de praktijk van gemeentelijke samenwerkingen. Het is bedoeld als hulpmiddel, niet als keurslijf. Pas het aan op jullie eigen situatie en laat je niet ontmoedigen als niet alles meteen perfect is.

Open source samenwerking tussen gemeenten is een leerproces. Jullie zullen onderweg dingen tegenkomen die anders lopen dan verwacht. Dat hoort erbij. Het belangrijkste is dat jullie blijven samenwerken, van elkaar leren, en de afspraken aanpassen als dat nodig is.

Succes met jullie samenwerking!

Over dit kompas

Versie: 0.3.0 (29 januari 2026)

Contact: flori@rebelalliance.nl

Licentie: Dit kompas is gebaseerd op VNG Realisatie “Handreiking intergemeentelijk samenwerken rondom open source” v0.2.2 (CC BY-SA 4.0). Deze afgeleide versie is gemaakt door Rebel Alliance en gepubliceerd onder dezelfde CC BY-SA 4.0 licentie.

Feedback: We horen graag jullie ervaringen en suggesties voor verbetering. flori@rebelalliance.nl

Stap 1: Bepaal jullie samenwerkingsambitie

Voordat je kiest voor een bepaald samenwerkingsmodel, is het belangrijk om eerst helder te krijgen hoeveel regie jullie als gemeenten willen hebben op de doorontwikkeling van de open source software. Deze keuze bepaalt in grote mate welke organisatievorm en afspraken passend zijn.

De regieladder: van minimaal naar maximaal

Je kunt de mate van regie zien als een ladder met verschillende treden. Elke trede vraagt meer organisatie, maar geeft ook meer invloed op de richting van de software:

Trede 1: Delen zonder regie

Kenmerken:

• Code wordt op een publieke repository geplaatst (bijvoorbeeld GitHub) onder een open source licentie
• Gemeenten kunnen de code vrij gebruiken en doorontwikkelen
• Elke gemeente regelt eigen doorontwikkeling met eigen leveranciers
• Geen gezamenlijke afstemming of planning

Wanneer passend:

Dit model werkt goed als de software vooral als startpunt dient en gemeenten hun eigen richting willen bepalen. Bijvoorbeeld bij experimenten of als gemeenten zeer verschillende behoeften hebben.

Trede 2: Lichte coördinatie

Kenmerken:

• Een klein aantal gemeenten (2-5) werkt samen
• Informele afspraken over wie wat doet
• Regelmatig overleg over doorontwikkeling
• Mogelijk een contactpersoon die afspraken coördineert
• Kosten worden verdeeld op basis van onderling overleg

Wanneer passend:

Dit werkt voor kleine groepen die elkaar goed kennen en vergelijkbare behoeften hebben. De overhead blijft beperkt, maar er is wel afstemming over de richting.

Trede 3: Gestructureerde samenwerking

Kenmerken:

• Meer gemeenten (6-100+) werken samen
• Formele samenwerkingsovereenkomst
• Gemeenten betalen een jaarlijkse communitybijdrage
• Gezamenlijke besluitvorming over prioriteiten (bijvoorbeeld via stuurgroep)
• Duidelijke rollen: wie beheert repository, wie werft nieuwe gemeenten, wie coördineert, wie heeft het contract met leveranciers
• Periodieke community-bijeenkomsten

Wanneer passend:

Dit niveau is nodig wanneer meer gemeenten willen meedoen en er behoefte is aan voorspelbaarheid en gezamenlijke sturing. De investering in organisatie loont door grotere schaal en betere afstemming.

Trede 4: Volledige regie

Kenmerken:

• Grote groep gemeenten (75-342) en/of strategisch belangrijk product
• Professionele organisatie met gelaagde governance
• Uitvoeringsorganisatie die onder aansturing staat van de governance, met daarin rollen als:
  • Product owner
  • Ontwikkelteam
  • Quality Assurance
  • Community management
  • Communicatie
  • Governance ondersteuning
  • Contract & leveranciersmanagement

Wanneer passend:

Dit niveau is nodig voor strategische applicaties waar gemeenten sterke regie op willen houden, applicaties die tot standaard worden verklaard, of wanneer de schaal zo groot is dat professioneel beheer noodzakelijk is.

Factoren die je keuze bepalen

Bij het bepalen van het juiste ambitieniveau spelen verschillende factoren een rol:

1. Aantal deelnemende gemeenten

Met 2-5 gemeenten kun je vaak nog informeel werken. Vanaf 6-10 gemeenten wordt formalisering wenselijk. Boven de 20 gemeenten is een meer professionele structuur meestal noodzakelijk.

2. Strategisch belang van de software

Gaat het om een kernsysteem of een ondersteunend hulpmiddel? Hoe kritisch is de software voor de dienstverlening? Hoe groot zijn de risico’s bij uitval of problemen?

3. Ontwikkelintensiteit

Is de software ‘af’ en vooral stabiel te houden, of zijn er plannen voor doorontwikkeling? Meer doorontwikkeling vraagt vaak om meer coördinatie.

4. Beschikbare capaciteit en geld

Hoeveel tijd kunnen jullie investeren in de samenwerking? Hoeveel budget is er beschikbaar? Een hoog ambitieniveau vraagt om dedicated capaciteit en meer budget.

5. Homogeniteit van behoeften

Hebben gemeenten vergelijkbare wensen en aanpassingen nodig, of lopen de behoeften sterk uiteen? Bij grote verschillen is een lossere vorm soms praktischer.

Beslishulp: welk niveau past bij jullie?

Beantwoord onderstaande vragen om je keuze te verhelderen:

Vraag 1: Hoeveel gemeenten verwachten jullie dat mee gaan doen?

• 2-5 gemeenten → Lichte coördinatie is waarschijnlijk voldoende
• 6-100+ gemeenten → Gestructureerde samenwerking wordt aanbevolen
• (Vrijwel) alle gemeenten → Volledige regie is waarschijnlijk nodig

Vraag 2: Willen jullie gezamenlijk sturen op doorontwikkeling?

• Nee, elke gemeente doet dat zelf → Delen zonder regie
• Ja, maar informeel → Lichte coördinatie
• Ja, met duidelijke afspraken → Gestructureerde samenwerking of hoger

Vraag 3: Is de software strategisch belangrijk voor jullie dienstverlening?

• Nee, het is een experiment of hulpmiddel → Lager ambitieniveau volstaat
• Ja, het is een kernsysteem → Hoger ambitieniveau nodig

Vraag 4: Zijn jullie bereid om tijd en geld te investeren in de organisatie?

• Minimaal → Kies voor een lager ambitieniveau
• Substantieel → Hoger ambitieniveau is mogelijk

Tip: Het is verstandig om te starten op een lager niveau en op te schalen als de samenwerking groeit en meer volwassen wordt.

Stap 2: Verdeel rollen en taken

Ongeacht of je informeel of formeel samenwerkt, zijn er concrete rollen en taken die ingevuld moeten worden. Welke rollen relevant zijn, hangt af van jullie gekozen ambitieniveau.

Deze stap helpt je om helder te krijgen welke taken er zijn, wie ze kan vervullen en hoe je dat organiseert. Zonder duidelijke rolverdeling en administratieve structuur ontstaat onduidelijkheid en blijven taken liggen.

Overzicht: taken per ambitieniveau

Niet alle taken zijn bij elk ambitieniveau relevant. Hieronder zie je welke taken bij welk niveau horen:

Basistaken (bij alle samenwerkingen)

Deze taken zijn bij elke samenwerking relevant. In praktijk zien we dat bij startende samenwerken er vaak één gemeente in de lead is in samenwerking met de leverancier/ontwikkelaar:

• Contactpersoon/aanspreekpunt: Iemand die vragen beantwoordt en nieuwe gemeenten te woord staat. Voorkomt dat iedereen bij verschillende mensen moet aankloppen.
• Beheer code repository: Iemand met beheerdersrechten die code kan accepteren (merge requests) en releases kan maken. Zorgt voor kwaliteitscontrole.
• Technisch beheer: Code reviews uitvoeren, beoordelen van merge requests, bewaken van codekwaliteit en technische samenhang.

Tijdsinvestering: 2-4 uur per week bij kleine samenwerking.

Taken bij lichte coördinatie

Deze taken worden relevant bij lichte coördinatie:

• Coördinatie overleggen: Voorbereiden en organiseren van gebruikersoverleg, notulen maken, acties opvolgen.
• Coördinatie samenwerking: contact onderhouden met de samenwerkingspartners, zorgen dat afspraken worden gemaakt en nagekomen.

Taken bij gestructureerde samenwerking en volledige regie

Vanaf gestructureerde samenwerking moet ook over de volgende taken worden worden nagedacht:

• Collecteren, beheren en aanwenden van de communitybijdrage: Facturen versturen, betalingen monitoren, herinneringen sturen bij niet-betaling, financiële administratie voeren en contracten sluiten met leveranciers.
• Financieel beheer: Budgetbewaking, financiële planning, verantwoording aan deelnemers, opstellen begrotingen en jaarrekeningen.
• Community management: Organiseren van gebruikersbijeenkomsten, verzamelen van feedback en wensen, roadmap maken.
• Product ownership: Bepalen van productvisie en strategie, prioriteren van roadmap, accepteren van opgeleverd werk, balanceren van wensen van verschillende gemeenten.
• Architectuur en technische visie: Bewaken van technische koers, architectuurbeslissingen, zorgen voor technische samenhang en toekomstbestendigheid.
• Aansturen ontwikkelteam: Dagelijkse sturing van developers (intern of extern), sprint planning, stand-ups, bewaken van voortgang en kwaliteit.
• Werven nieuwe gemeenten: Geven van demos en presentaties, beantwoorden van vragen van geïnteresseerde gemeenten, onboarding van nieuwe deelnemers.
• Communicatie: Verzorgen van nieuwsbrieven, updates over nieuwe releases, onderhouden van website of communicatiekanalen.
• Monitoring en rapportage: Bijhouden van gebruik, tevredenheid meten, voortgang monitoren, rapporteren aan stuurgroep of gebruikersoverleg.
• Leveranciersmanagement: Beheren van relaties met leveranciers, zorgen dat er een gezonde markt van leveranciers is, escaleren van problemen, zorgen voor kennisborging.

Van taken naar personen: wie doet wat?

Nu je weet welke taken er zijn, is de vraag: wie gaat deze uitvoeren? Er zijn verschillende manieren om taken te beleggen:

Optie 1: Bij een coördinerende gemeente

Hoe werkt het: Medewerkers van één gemeente (de penvoerder) vervullen de rollen namens de hele samenwerking, al dan niet in samenwerking met externe leveranciers en/of freelancers.

Voordelen:

• Korte lijnen en snelle communicatie
• Continuïteit door vaste personen
• Diepe kennis van de materie

Aandachtspunten:

• Vergoed de capaciteit (financieel of anderszins)
• Zorg voor back-up bij ziekte/verlof
• Let op belangenverstrengeling (penvoerder is ook deelnemer)

Geschikt voor: Informele samenwerkingen tot gestructureerde samenwerking.

Optie 2: Roulerend tussen gemeenten

Hoe werkt het: Gemeenten wisselen elkaar periodiek af. Bijvoorbeeld: elke gemeente is een jaar ‘aan de beurt’ voor bepaalde taken.

Voordelen:

• Eerlijke verdeling van lasten
• Alle gemeenten leren de samenwerking van binnenuit kennen
• Voorkomt afhankelijkheid van één gemeente
• Kan als in-kind bijdrage worden gerekend waardoor een gemeente minder communitybijdrage hoeft te betalen

Aandachtspunten:

• Continuïteit in gevaar bij elke wissel
• Goede documentatie en overdracht cruciaal
• Niet alle gemeenten hebben gelijke capaciteit

Geschikt voor: Informele samenwerkingen en lichte coördinatie.

Optie 3: Verdeeld over gemeenten

Hoe werkt het: Verschillende gemeenten nemen verschillende taken op zich, gebaseerd op expertise of interesse. Bijvoorbeeld: gemeente A doet product ownership, gemeente B coördineert bijeenkomsten, gemeente C doet financiën.

Voordelen:

• Benut expertise en interesse
• Verdeelt lasten over meerdere gemeenten
• Betrokkenheid van meer gemeenten

Aandachtspunten:

• Coördinatie tussen verschillende gemeenten nodig
• Onduidelijkheid wie waarvoor verantwoordelijk is
• Risico dat taken tussen wal en schip vallen

Geschikt voor: Informele of gestructureerde samenwerking met heldere taakverdeling en goede onderlinge afstemming.

Optie 4: Externe partij

Hoe werkt het: Een externe organisatie neemt (een deel van de) rollen op zich. In praktijk zien we bijvoorbeeld vaak dat de leverancier/ontwikkelaar rollen op zich neemt. Meer hierover in Deel 3: Community.

Voordelen:

• Ontlast gemeenten
• Neutrale partij (mits niet de ontwikkelaar/leverancier)
• Contractuele afspraken over de uitvoering van het werk

Aandachtspunten:

• Kosten (moet uit communitybijdrage)
• Afhankelijkheid van een externe partij
• Indien ontwikkelaar/leverancier: commerciële belangen van en publieke belangen kunnen elkaar in de weg komen te zitten

Geschikt voor: gestructureerde samenwerkingen

Praktische uitwerking: maak een RACI-matrix

Een RACI-matrix helpt om voor elke taak helder te krijgen wie wat doet. RACI staat voor:

• R - Responsible: Wie voert de taak uit?
• A - Accountable: Wie is eindverantwoordelijk?
• C - Consulted: Wie moet geraadpleegd worden?
• I - Informed: Wie moet geïnformeerd worden?

Voorbeeld voor een gestructureerde samenwerking:

Taak: Technisch beheer repository

• R: Developer bij gemeente A
• A: Coördinator bij gemeente A
• C: Stuurgroep
• I: Alle deelnemers via nieuwsbrief

Taak: Organiseren gebruikersbijeenkomst

• R: Coördinator bij gemeente A
• A: Stuurgroep
• C: Gebruikersgroep (voor agenda-input)
• I: Alle deelnemers

Checklist: hebben we alle rollen belegd?

Loop deze checklist door om te controleren of je niets vergeten bent:

Technisch:

• ☐ Beheer code repository (admin-rechten)
• ☐ Code review en merge requests
• ☐ Release management
• ☐ Technische documentatie

Organisatorisch:

• ☐ Contactpersoon/aanspreekpunt
• ☐ Coördinatie overleggen
• ☐ Notulen en actielijsten
• ☐ Organisatie bijeenkomsten

Financieel:

• ☐ Facturering
• ☐ Betalingen monitoren
• ☐ Financiële administratie
• ☐ Financiële rapportage

Community:

• ☐ Werven nieuwe gemeenten
• ☐ Onboarding nieuwe deelnemers
• ☐ Communicatie (nieuwsbrieven, website)
• ☐ Verzamelen feedback

Bij gestructureerde samenwerking en volledige regie ook:

• ☐ Product ownership
• ☐ Contractmanagement
• ☐ Aansturen ontwikkelteam
• ☐ Leveranciersmanagement

Praktische tips

Maak het expliciet en schrijf het op

Neem de rolverdeling op in de samenwerkingsovereenkomst of als bijlage. Voorkomt discussies over ‘wie zou dit eigenlijk doen’.

Zorg voor back-up

Voor kritische rollen: zorg dat er altijd een tweede persoon is die kan overnemen bij ziekte, verlof of vertrek.

Documenteer processen

Beschrijf niet alleen wie wat doet, maar ook hoe. Dat maakt het gemakkelijker om taken over te dragen of nieuwe mensen in te werken.

Scheiding van geldstromen

Gebruik aparte kostenplaats of administratie. Voorkomt dat community-geld en andere gemeentelijke middelen door elkaar lopen.

Bouw reserves op

Zorg voor buffer van 3-6 maanden aan vaste kosten. Geeft ademruimte bij uitval van een deelnemer, vertraging in betalingen, of onvoorziene kosten.

Evalueer jaarlijks

Bespreek jaarlijks of de rolverdeling nog past. Bij groei of krimp moet je soms bijsturen.

Erken en waardeer de inzet

Mensen die rollen vervullen investeren tijd en energie. Zorg dat dit gezien en gewaardeerd wordt, zowel binnen hun gemeente als door de hele community.

Maak financiële administratie bespreekbaar

Maak financiële administratie onderdeel van vaste agendapunten in het overleg. Dat normaliseert het en voorkomt verrassingen.

Tip: Start niet te ambitieus. Beter om met minder rollen te beginnen en goed uit te voeren, dan veel rollen op papier die niet ingevuld worden. Je kunt altijd opschalen als de samenwerking groeit.

Stap 3: Kies een governancemodel

Governance gaat over hoe jullie als samenwerkende gemeenten besluiten nemen, wie daarbij betrokken is, en hoe jullie die besluiten voorbereiden en uitvoeren. Een helder governancemodel voorkomt onduidelijkheid en conflicten.

Bij het vormgeven van jullie governance zijn drie vragen centraal: wie besluit, hoe besluiten jullie, en over wat moeten jullie besluiten?

1. Wie besluit? Overlegstructuur

Afhankelijk van jullie ambitieniveau en schaal, kun je kiezen voor verschillende overlegstructuren:

Eenlaags model - Gebruikersoverleg

Hoe werkt het:

Alle deelnemende gemeenten komen periodiek samen in één overleg. Elke gemeente heeft één stem. Besluiten worden gezamenlijk genomen, of op basis van wie budget heeft voor een doorontwikkeling.

Kenmerken:

• Simpel en transparant
• Alle gemeenten hebben directe inspraak
• Geen tussenschakels of mandaten nodig
• Frequentie: 2-4 keer per jaar

Geschikt voor: Lichte coördinatie en kleine gestructureerde samenwerkingen (tot ca. 20 gemeenten)

Tweelaags model - Stuurgroep + Gebruikersgroep

Hoe werkt het:

Een kleinere stuurgroep (4-8 personen) neemt strategische besluiten. In praktijk zien we dat dit veelal gemeenten zijn met een groot belang bij de doorontwikkeling en/of een kerngroep van gemeenten die samen (het gros van) de kosten dragen. Een bredere gebruikersgroep verzorgt de operationele aansturing (doorontwikkeling, communicatie, community, etc).

Rolverdeling:

• Stuurgroep: Strategische koers, budget, conflictmanagement, leveranciersstrategie
• Gebruikersgroep: Wensen inventariseren, roadmap bepalen, communicatie, nieuwe functionaliteit (laten) ontwikkelen en testen

Samenstelling stuurgroep:

• Vertegenwoordiging van verschillende gemeentetypes
• Mix van inhoudelijke en bestuurlijke expertise
• Eventueel een onafhankelijk voorzitter
• Roulerende zetels (bijvoorbeeld om de 2 jaar wissel)

Geschikt voor: Gestructureerde samenwerking en Volledige regie (vanaf ca. 10 gemeenten)

Drielaags model - Stuurgroep + Gebruikersgroep + Werkgroepen

Hoe werkt het:

Bij meer complexe voorzieningen en/of voorzieningen die van groot publiek belang zijn is het mogelijk om een verdere onderverdeling te maken tussen strategisch, tactisch en operationele verantwoordelijkheden. Te denken valt aan operationele werkgroepen die doorontwikkeling op specifieke thema’s voorbereiden.

Rolverdeling:

• Stuurgroep: Eindverantwoordelijkheid, bestuurlijke ambassadeurs, toezicht, financiële verantwoording, strategie, jaarplan
• Gebruikersgroep: Dagelijkse sturing, prioritering, roadmap, leveranciersrelaties, relatiemanagement gebruikers
• Werkgroepen: Doorontwikkelwensen uitwerken

Geschikt voor: Gestructureerde samenwerking en Volledige regie (vanaf ca. 50 gemeenten)

2. Hoe besluiten jullie? Besluitvormingsmethode

Er zijn verschillende manieren om tot besluiten te komen. De keuze hangt af van de aard van de samenwerking en het besluit:

Consensus

Hoe werkt het:

Er wordt overlegd totdat iedereen zich kan vinden in het besluit. Geen enkele gemeente heeft een veto, maar er wordt gezocht naar een oplossing waar iedereen achter staat.

Voordelen:

• Breed draagvlak
• Alle gemeenten voelen zich gehoord
• Betere uitvoering door eigenaarschap

Nadelen:

• Kan traag zijn
• Risico op verwaterde compromissen
• Een enkele blokkerende gemeente kan doorgang belemmeren

Geschikt voor: Strategische besluiten en kleine groepen. Werkt goed bij hoge mate van vertrouwen en wanneer er een verbindende coördinator is.

Meerderheid van stemmen

Hoe werkt het:

Besluiten worden genomen met een eenvoudige meerderheid (meer dan 50%) of gekwalificeerde meerderheid (bijvoorbeeld 2/3 of 3/4). Elke gemeente heeft één stem.

Voordelen:

• Duidelijk en efficiënt
• Voorkomt impasses
• Schaalbaar naar grote groepen

Nadelen:

• Minderheid voelt zich mogelijk gepasseerd
• Risico op wij-zij denken
• Minder geschikt voor hechte samenwerkingen

Varianten:

• Eenvoudige meerderheid: Voor operationele besluiten
• Gekwalificeerde meerderheid (2/3): Voor belangrijke besluiten (strategische koers, grote investeringen)
• Unanimiteit: Voor fundamentele wijzigingen

Geschikt voor: Grotere groepen en gestructureerde samenwerking. Vooral bij operationele besluiten.

Mandaat met adviesrecht

Hoe werkt het:

Voor bepaalde besluiten krijgt de stuurgroep, coördinator of product owner mandaat om zelfstandig te beslissen. Andere gemeenten hebben adviesrecht maar geen vetorecht.

Voordelen:

• Snelle besluitvorming
• Minder vergaderlast
• Professionele uitvoering mogelijk

Voorwaarden:

• Helder afgebakende mandaten
• Regelmatige rapportage aan alle deelnemers
• Escalatiemogelijkheid bij fundamentele bezwaren

Geschikt voor: Operationele en technische besluiten bij Volledige regie. Bijvoorbeeld: technische keuzes, kleine aanpassingen, bug fixes.

Hybride aanpak (aanbevolen)

In de praktijk werkt een combinatie vaak het best: consensus voor strategische keuzes, stemmen voor operationele besluiten, en mandaat voor dagelijkse uitvoering.

3. Waarover besluiten jullie? Beslisbevoegdheden

Maak expliciet over welke onderwerpen besloten moet worden en wie dat mag doen:

Strategische besluiten

• Meerjarenstrategie en visie
• Keuze open source licentie
• Governancemodel en samenwerkingsovereenkomst
• Financieringsmodel
• Toelating nieuwe gemeenten
• Fundamentele wijziging van scope of doel

Tactische besluiten

• Jaarbudget en communitybijdrage
• Jaarroadmap en prioritering features
• Keuze leveranciers (boven bepaald bedrag)
• Wijzigingen samenwerkingsovereenkomst
• Major releases

Operationele besluiten (mandaat)

• Dagelijkse aansturing ontwikkelteam
• Technische architectuurkeuzes
• Bug fixes en kleine aanpassingen
• Communicatie-uitingen
• Kleine uitgaven (onder bepaald bedrag)

Praktische tips

Leg het vast in een governance charter

Maak een eenvoudig document (3-5 pagina’s) waarin je vastlegt: overlegstructuur, besluitvormingsmethoden per type besluit, mandaten, en overlegfrequentie. Dit voorkomt veel discussie later.

Start simpel, formaliseer later

Begin met een eenvoudig model (bijvoorbeeld alleen gebruikersoverleg met consensus). Als je groeit en complexer wordt, kun je altijd een laag toevoegen.

Evalueer jaarlijks

Bespreek jaarlijks of jullie governance nog past. Groei vraagt soms aanpassing.

Investeer in goede voorbereiding

Goed voorbereide vergaderingen met duidelijke stukken maken besluitvorming effectiever, ongeacht welk model je kiest.

Tip: Besteed aandacht aan hoe je omgaat met conflicten. Wat doe je als gemeenten het fundamenteel oneens zijn? Een escalatieprocedure of mediatiemogelijkheid kan helpen om vastgelopen situaties te doorbreken.

Stap 4: Kies een financieringsmodel

Open source betekent niet kosteloos. Doorontwikkeling, beheer en coördinatie kosten geld. Een helder financieringsmodel zorgt dat iedereen weet wat de bijdrage is en waarom.

Bij het kiezen van een financieringsmodel zijn drie vragen leidend: betalen gemeenten iets, zo ja hoeveel, en hoe verdeel je de kosten?

1. Betalen of niet betalen?

Geen communitybijdrage

Wanneer passend:

Bij ‘Delen zonder regie’ of zeer lichte coördinatie waar geen gezamenlijke kosten zijn. Code staat op publieke repo, gemeenten regelen zelf doorontwikkeling.

Consequenties:

• Geen gezamenlijke doorontwikkeling mogelijk
• Geen ondersteuning of coördinatie te financieren
• Elke gemeente investeert individueel (of niet)
• Risico op uiteen groeien van versies

Wel communitybijdrage

Wanneer passend:

Vanaf ‘Lichte coördinatie’ met gezamenlijke kosten, of zodra er gestructureerd doorontwikkeld wordt.

Waarvoor gebruik je de bijdrage:

• Gezamenlijke doorontwikkeling (ontwikkelaars inhuren)
• Coördinatie en ondersteuning (als dit niet door gemeente wordt gedaan)
• Technische infrastructuur (hosting, tools)
• Documentatie en kennisdeling
• Community-activiteiten (bijeenkomsten, communicatie)

2. Hoe hoog is de bijdrage?

De hoogte hangt af van jullie ambities en wat je gezamenlijk wilt realiseren. Begin met wat je wilt doen, reken uit wat dat kost, en verdeel dat.

Stappenplan bepalen bijdrage

Stap 1: Inventariseer gewenste activiteiten

Wat willen jullie het komende jaar bereiken? Bijvoorbeeld:

• 4 nieuwe features ontwikkelen (geschat 800 uur à €100 = €80.000)
• Coördinatie 0,2 FTE (€15.000)
• 2 gebruikersbijeenkomsten (€3.000)
• Infrastructuur en tools (€2.000)

Stap 2: Reken uit wat dit kost

In bovenstaand voorbeeld: totaal €100.000 per jaar.

Stap 3: Verdeel over gemeenten

Bij 20 gemeenten: gemiddeld €5.000 per gemeente. Maar hoe verdeel je dit precies? Zie volgende sectie.

Stap 4: Communiceer transparant

Leg uit waar het geld naartoe gaat. Gemeenten willen weten dat hun bijdrage goed besteed wordt.

3. Hoe verdeel je de kosten? Verdeelsleutels

Er zijn verschillende manieren om de totale kosten over gemeenten te verdelen:

Model 1 - Gelijke verdeling

Hoe werkt het:

Elke gemeente betaalt hetzelfde bedrag, ongeacht grootte.

Voordelen:

• Simpel en transparant
• Iedereen gelijke stem, iedereen gelijke bijdrage
• Laagdrempelig voor kleine gemeenten

Nadelen:

• Kleine gemeenten betalen relatief meer (als % van budget)
• Grote gemeenten betalen relatief minder
• Kan grote gemeenten afhouden van deelname

Voorbeeld:

20 gemeenten, totaal €100.000 → elk €5.000 per jaar.

Geschikt voor: Lichte coördinatie en kleinere samenwerkingen. Werkt goed als gemeenten vergelijkbaar zijn qua grootte of als bedragen laag blijven (< €10.000).

Model 2 - Naar inwoneraantal

Hoe werkt het:

Bijdrage evenredig aan aantal inwoners. Grote gemeente betaalt meer, kleine minder.

Voordelen:

• Eerlijker: draagkracht bepaalt bijdrage
• Aantrekkelijker voor grote gemeenten
• Betaalbaar voor kleine gemeenten
• Bekende systematiek (lijkt op BCF-systematiek)

Nadelen:

• Iets complexer te berekenen
• Discussie mogelijk: waarom meer betalen terwijl je gelijke stem hebt?
• Inwoneraantal verandert jaarlijks (minimaal)

Voorbeeld:

20 gemeenten, samen 1.000.000 inwoners, totaal €100.000. Gemeente A (100.000 inwoners) betaalt €10.000. Gemeente B (25.000 inwoners) betaalt €2.500.

Geschikt voor: Gestructureerde samenwerking en Volledige regie, vooral bij grotere bedragen en mix van grote en kleine gemeenten.

Model 3 - Naar gebruik

Hoe werkt het:

Bijdrage gebaseerd op daadwerkelijk gebruik. Bijvoorbeeld: aantal transacties, aantal gebruikers, aantal afgenomen modules.

Voordelen:

• Eerlijk: wie meer gebruikt betaalt meer
• Laagdrempelig voor nieuwe gemeenten (proberen is goedkoop)
• Schaalbaar

Nadelen:

• Complex: gebruik moet gemeten en gerapporteerd worden
• Onvoorspelbaar budget voor gemeenten
• Moeilijk om basis-infrastructuur te financieren
• Voelt minder als samenwerking, meer als dienstverlening

Geschikt voor: Vooral bij SaaS-achtige toepassingen of wanneer gebruik sterk varieert. Minder geschikt voor klassieke gemeentelijke samenwerkingen.

Model 4 - Hybride: basis + variabel

Hoe werkt het:

Combinatie van vaste basisbijdrage (gelijk of naar inwoners) en variabel deel (naar gebruik of specifieke wensen).

Voorbeeld:

• Basis €2.000 per gemeente voor infrastructuur en basis-onderhoud
• Plus variabel deel naar inwoners voor doorontwikkeling
• Gemeente kan extra betalen voor maatwerk-features

Voordelen:

• Flexibel en rechtvaardig
• Basisbeheer is gegarandeerd
• Ruimte voor maatwerk zonder andere gemeenten te belasten

Nadelen:

• Complexer te administreren
• Vraagt goede afspraken over wat basis is en wat extra

Geschikt voor: Volwassen samenwerkingen met diverse behoeften. Voorkomt free-rider probleem en biedt ruimte voor differentiatie.

4. Overzichtstabel verdeelsleutels

Maak scenario’s

Een veel gestelde vraag is: “Hoe bepalen we wat het per gemeente gaat kosten?” Door verschillende scenario’s door te rekenen, krijg je inzicht in de bandbreedte en wordt het eenvoudiger te communiceren wat je met elkaar zou kunnen met een hogere bijdrage of meer deelnemers.. We adviseren minimaal 2 en eventueel zelfs 3 begrotingsscenario’s te maken.

Scenario 1: Minimum begroting (overlevingsmodus)

Vraag: Wat is het absolute minimum zonder welk de samenwerking ophoudt te bestaan?

Bevat typisch:

• Kritieke bugfixes en security patches
• Minimaal technisch beheer (hosting, repository)
• Basale coördinatie (aanspreekpunt)
• Geen doorontwikkeling, geen groei, geen community-activiteiten

Wanneer relevant:

• Bij zeer beperkt budget
• Als fall-back scenario bij financiële tegenvallers
• Om te laten zien wat er “under the hood” minimaal nodig is

Risico’s van dit scenario:

• Geen innovatie, systeem raakt achterhaald
• Geen nieuwe gemeenten, community verschraalt
• Verhoogd risico op uitval door gebrek aan onderhoud
• Bestaande deelnemers kunnen afhaken

Scenario 2: Streef begroting (realistisch en wenselijk)

Vraag: Wat is realistisch én wenselijk voor het komende jaar gegeven onze ambities?

Bevat typisch:

• Onderhoud én doorontwikkeling (2-4 nieuwe features)
• Professionele coördinatie en community management
• Gebruikersbijeenkomsten en kennisdeling
• Onboarding nieuwe gemeenten
• Documentatie op orde houden
• Ruimte voor kleinere aanpassingen

Wanneer relevant:

• Dit is meestal het voorkeursscenario
• Balans tussen ambitie en betaalbaarheid
• Zorgt voor gezonde groei en continuïteit

Dit scenario als basis: Gebruik dit als uitgangspunt voor besluitvorming. Dit is wat je “normaal” wilt kunnen doen.

Scenario 3: Wens begroting (ideaalbeeld)

Vraag: Wat zou het ideaalplaatje zijn zonder budgettaire beperkingen?

Bevat typisch:

• Ambitieus doorontwikkelplan (6-8 nieuwe features)
• Volledige product owner + community manager
• Meerdere leveranciers actief (gezond ecosysteem)
• Innovatie en experimenten
• Marketing en actieve groei-activiteiten
• Uitgebreide ondersteuning nieuwe gemeentes

Wanneer relevant:

• Laat zien wat mogelijk is bij voldoende schaalgrootte
• Inspiratie en richting voor groei

Gebruik van dit scenario: Dit hoeft niet nu, maar kan wel de richting bepalen. Bij groei kun je dit scenario dichterbij brengen.

Doorrekenen: twee variabelen

Voor elk scenario bereken je twee situaties:

Variant A: Huidig aantal deelnemers

Wat betekent dit scenario per gemeente bij het huidige aantal deelnemers?

Variant B: Bij groei met X gemeenten

Wat betekent dit scenario per gemeente als we groeien met [X aantal] nieuwe deelnemers?

Dit laat zien:

• Hoe schaalvoordelen werken (meer deelnemers = lagere kosten per gemeente)
• De prikkel om te groeien
• Realistische verwachtingen voor nieuwe toetreders

Praktisch voorbeeld: Signalen Community

Dit betreft een fictief voorbeeld!

Context:

• Meldsysteem openbare ruimte
• Momenteel: 45 gemeenten
• Ambitie: groeien naar 75 gemeenten in 2 jaar

Scenario 1: Minimum begroting

Activiteiten:

• Hosting en infrastructuur: €10.000
• Kritieke bugfixes (100 uur x €100): €10.000
• Minimale coördinatie (0,1 FTE): €7.500
• Totaal: €27.500

Kosten per gemeente:

Scenario 2: Streef begroting (aanbevolen)

Activiteiten:

• Hosting en infrastructuur: €12.000
• Doorontwikkeling 3 features (400 uur @ €100): €40.000
• Bugfixes en klein onderhoud (150 uur @ €100): €15.000
• Coördinatie en community management (0,3 FTE): €22.500
• 2 Gebruikersbijeenkomsten: €4.000
• Communicatie en onboarding: €3.000
• Tools en licenties: €2.500
• Reserve (10%): €9.900
• Totaal: €108.900

Kosten per gemeente:

Met verdeelsleutel naar inwoners (voorbeeld):

Scenario 3: Wens begroting (ideaal)

Activiteiten:

• Hosting en infrastructuur (professioneel): €18.000
• Ambitieus doorontwikkelplan 6 features (800 uur @ €100): €80.000
• Onderhoud en bugfixes (250 uur @ €100): €25.000
• Volledige product owner (0,4 FTE): €30.000
• Community manager (0,3 FTE): €22.500
• 3 Gebruikersbijeenkomsten + jaarconferentie: €12.000
• Marketing en actieve werving: €8.000
• Leveranciersdag en ecosysteem-ontwikkeling: €5.000
• Uitgebreide documentatie en trainingen: €6.000
• Innovatie-experimenten: €10.000
• Tools, licenties en onvoorzien: €8.500
• Reserve (10%): €22.500
• Totaal: €247.500

Kosten per gemeente:

Met verdeelsleutel naar inwoners (voorbeeld):

Template voor eigen doorrekening

Gebruik onderstaande template om jullie eigen scenario’s door te rekenen:

Stap 1: Definieer jullie scenario’s

Scenario 1: Minimum

• Wat is het absolute minimum?
• Welke activiteiten kunnen NIET weg?

Scenario 2: Streef (aanbevolen)

• Wat willen we realistisch bereiken?
• Balans tussen ambitie en betaalbaarheid

Scenario 3: Wens (optioneel)

• Wat zou ideaal zijn?
• Wat doen we als we meer budget/deelnemers hebben?

Stap 2: Maak een kostenoverzicht per scenario

Stap 3: Bereken kosten per gemeente

Variant A: Huidig aantal deelnemers

Aantal deelnemers nu: […]

Variant B: Bij groei

Verwacht aantal deelnemers: […]

Stap 4: Trek conclusies

Welk scenario is realistisch?

• Minimum: te weinig ambitie, maar wel haalbaar
• Streef: balans tussen ambitie en betaalbaarheid
• Wens: mooi ideaal, maar vraagt meer budget of groei

Wat is het effect van groei?

• Kostendaling per gemeente bij groei naar […] gemeenten: …%
• Break-even punt (wanneer wordt wens-scenario betaalbaar?): bij […] gemeenten

Aanbeveling:

• Start met scenario: […]
• Groeiambitie: naar […] gemeenten in […] jaar
• Dan mogelijk opschalen naar: […]

Communicatie naar gemeenten

Bij werven nieuwe gemeenten

Transparant zijn over kosten:

“De bijdrage hangt af van onze gezamenlijke ambitie en het aantal deelnemers. We hebben drie scenario’s doorgerekend:

• Minimum (overlevingsmodus): €X per gemeente
• Streef (aanbevolen, gezonde groei): €Y per gemeente
• Wens (ideaalplaatje): €Z per gemeente

Bij groei naar [X] gemeenten dalen de kosten naar respectievelijk €A, €B en €C per gemeente. Hoe meer gemeenten meedoen, hoe betaalbaarder het voor iedereen wordt.“

Bij besluiten over begroting

Faciliteer keuze met scenario’s:

“De stuurgroep kan kiezen uit drie begrotingsscenario’s voor 2026:

1. Minimum (€X totaal): Basis op orde, geen groei
2. Streef (€Y totaal, aanbevolen): 3 features, community-activiteiten, groei naar 75 gemeenten
3. Wens (€Z totaal): Ambitieus doorontwikkelplan, professionele organisatie

Bij het huidige aantal deelnemers betekent scenario 2 een bijdrage van €… per gemeente. Bij het verwachte aantal van 60 gemeenten eind 2026 daalt dit naar €…“

Veelgestelde vragen

Vraag: Moeten we alle drie scenario’s altijd maken?

Nee. Minimum + Streef is vaak voldoende. Het Wens-scenario is vooral nuttig om richting te geven en te laten zien wat mogelijk is bij meer schaal.

Vraag: Hoe bepaal je de groei-verwachting?

Kijk naar:

• Aantal geïnteresseerde gemeenten (wachtlijst)
• Vergelijkbare voorzieningen (hoeveel gemeenten gebruiken die?)
• Totale doelgroep (hoeveel gemeenten hebben deze behoefte?)
• Realistische groei per jaar (10-20% is vaak haalbaar)

Wees eerlijk: liever conservatief schatten dan teleurstellen.

Vraag: Wat als we de groei niet halen?

Bouw flexibiliteit in:

• Start met minimumscenario of licht streefscenario
• Evalueer na 6 maanden en pas aan
• Of: maak afspraken over bijstorten als groei tegenvalt

Vraag: Kunnen we het budget halverwege het jaar aanpassen?

Ja, maar zorg dat je vooraf afspraken maakt over hoe je dit doet en doe het transparant:

• Leg uit waarom (groei valt tegen, of juist mee)
• Laat gemeenten besluiten (via governance)
• Voorkom verrassingen: communiceer tijdig

Vraag: Hoe ga je om met gemeenten die alleen het minimum willen betalen?

Een communitybijdrage is vrijwillig. De software is immers open source, dus partijen kunnen de code met een eigen leverancier draaien. Zorg dat je in de communicatie duidelijk maakt dat het een publiek belang is om de code en de samenwerking samen goed en gezond te houden. Spreek partijen aan op solidariteit. Maak ook afspraken met leveranciers dat zij wijzen op het belang van de communitybijdrage als gemeenten zich rechtstreeks bij hun melden voor een contract.

Praktische tips

Start eenvoudig, verfijn later

Begin met gelijke verdeling of simpele inwoner-verdeling. Je kunt altijd verfijnen als jullie meer ervaring hebben.

Maak een meerjarenraming

Laat zien wat gemeenten de komende 3 jaar kunnen verwachten qua bijdrage. Dat helpt bij budgetteren.

Bouw een buffer

Plan niet 100% van het budget in. Houd 10-15% reserve voor onvoorziene zaken.

Evalueer jaarlijks

Kijk elk jaar of het model nog past. Bijdrage verhogen kan, maar wees transparant over waarom.

Begin realistisch

Start met het streefscenario, niet met de wens. Beter positief verrassen dan teleurstellen.

Update scenario’s jaarlijks

Scenario’s zijn geen beton. Herzie ze elk jaar op basis van:

• Behaalde groei
• Leerervaringen uit het afgelopen jaar
• Nieuwe inzichten over kosten
• Verschuivende ambities

Gebruik het als gesprekstool

Scenario’s zijn niet bedoeld als harde voorspelling, maar als gespreksstarter:

• “Wat vinden jullie belangrijk?”
• “Wat zijn we bereid te investeren?”
• “Hoeveel groei verwachten we realistisch?”

Wees transparant over onzekerheden

Benoem expliciet:

• Aannames die je hebt gemaakt
• Risico’s (groei valt tegen, kosten vallen hoger uit)
• Hoe je bijstuurt als realiteit afwijkt

Laat het schaalvoordeel zien

De kracht van samenwerking zit in schaalvoordeel. Maak dit visueel duidelijk met een grafiek die laat zien hoe kosten per gemeente dalen bij groei.

Tip: Stel een financieel verantwoording op. Dit hoeft geen boekwerk te zijn, maar laat zien waar het geld naartoe is gegaan en wat daarmee bereikt is. Dat versterkt draagvlak.

Tip: Gebruik de scenario-aanpak niet alleen bij de start, maar ook bij belangrijke momenten zoals: evaluatie na jaar 1, belangrijke strategische keuzes, werving van nieuwe deelnemers, discussies over opschaling

Stap 5: Bouw en onderhoud de community

Een levendige community is de motor van een succesvolle open source samenwerking. Het gaat niet alleen om het delen van code, maar om het creëren van een ecosysteem waarin gemeenten én leveranciers actief bijdragen, kennis delen en elkaar ondersteunen.

Deze stap helpt je om een community te bouwen die groeit en blijft bestaan, zelfs als specifieke personen of gemeenten wisselen.

Waarom community belangrijk is

Een sterke community zorgt voor:

• Kennisdeling: Gemeenten leren van elkaars ervaringen en oplossingen
• Snellere probleemoplossing: Meer ogen zien meer, bugs worden sneller gevonden en opgelost
• Innovatie: Nieuwe ideeën en use cases ontstaan door uitwisseling
• Duurzaamheid: De samenwerking wordt minder afhankelijk van individuele personen
• Attractiviteit: Een actieve community trekt nieuwe deelnemers (gemeenten én leveranciers) aan

Fasen van community-ontwikkeling

Fase 1: Pioniersfase (2-5 gemeenten)

Kenmerken:

• Kleine groep vroege adopters
• Persoonlijke contacten en korte lijnen
• Veel experimenteren en leren
• Informele communicatie (e-mail, ad-hoc calls)

Belangrijkste taken:

• Documenteer alles wat je doet (ook mislukkingen!)
• Maak kennis deelbaar (wiki, README, handleidingen)
• Organiseer informele kennissessies
• Creëer een veilige omgeving om te leren

Tijdsinvestering: 2-4 uur per maand

Fase 2: Groeifase (6-20 gemeenten)

Kenmerken:

• Meer gemeenten sluiten aan
• Behoefte aan structuur neemt toe
• Verschillende niveaus van betrokkenheid
• Groeiende kennisbasis

Belangrijkste taken:

• Organiseer regelmatige gebruikersbijeenkomsten (2-4x per jaar)
• Richt communicatiekanalen in (nieuwsbrief, Slack/Teams)
• Ontwikkel onboarding-materiaal voor nieuwe gemeenten
• Faciliteer kennisdeling tussen gemeenten

Tijdsinvestering: 0,1-0,2 FTE (4-8 uur per week)

Fase 3: Volwassen community (20+ gemeenten)

Kenmerken:

• Grote, diverse groep deelnemers
• Gelaagde community (kern, actief, passief)
• Gestructureerde communicatie en kennisdeling
• Meerdere leveranciers actief

Belangrijkste taken:

• Professionele community management
• Diverse events (gebruikersconferentie, hackathons, webinars)
• Actief werven nieuwe deelnemers
• Community ambassadeurs activeren
• Leveranciersecosysteem ondersteunen

Tijdsinvestering: 0,2-0,4 FTE (8-16 uur per week)

Praktische community-activiteiten

1. Onboarding nieuwe gemeenten

Maak het makkelijk om te starten:

• Welkomstpakket: Korte intro, getting started guide, wie-doet-wat overzicht
• Buddy-systeem: Koppel nieuwe gemeente aan ervaren deelnemer
• Onboarding-sessie: Persoonlijke kennismaking en technische walkthrough
• Quick wins: Zorg dat nieuwe gemeenten snel waarde ervaren

Voorbeeld onboarding-checklist:

• ☐ Welkomstmail met links naar documentatie
• ☐ Uitnodiging voor Slack/Teams workspace
• ☐ Kennismaking met community coördinator
• ☐ Buddy toegewezen voor eerste 3 maanden
• ☐ Onboarding-sessie gepland (live demo + Q&A)
• ☐ Toegang tot repository en development environment
• ☐ Eerste gebruikersbijeenkomst bijgewoond

2. Communicatiekanalen

Kies passende kanalen per type communicatie:

Structurele updates (1-weg):

• Nieuwsbrief (maandelijks of kwartaal)
• Release notes via e-mail
• Website/portal met nieuws

Dagelijkse interactie (2-weg):

• Slack/Teams workspace
• GitHub Discussions/Issues
• Mailinglist voor technische vragen

Kennisdeling en netwerken:

• Gebruikersbijeenkomsten (2-4x per jaar)
• Webinars over specifieke onderwerpen
• Jaarlijkse community dag/conferentie

Tips voor effectieve communicatie:

• Wees consistent in ritme (vaste nieuwsbrief-momenten)
• Houd het praktisch en relevant (geen algemene praatjes)
• Vier successen (nieuwe features, toegetreden gemeenten)
• Deel ook uitdagingen (transparantie bouwt vertrouwen)
• Moedig peer-to-peer communicatie aan

3. Gebruikersbijeenkomsten organiseren

Format 1: Kwartaal gebruikersoverleg (2-3 uur)

Voorbeeld agenda:

• Opening en mededelingen
• Voortgang laatste kwartaal
• Roadmap en prioritering komende periode
• Best practices / use case van deelnemer
• Technische updates / demo nieuwe features
• Rondvraag en afsluitin

Format 2: Jaarlijkse community dag (hele dag)

Programma elementen:

• Plenaire opening
• Parallelle workshops over specifieke onderwerpen
• Showcase: gemeenten presenteren hun gebruik
• Marktplaats: leveranciers tonen oplossingen
• Open space / unconference voor zelforganisatie
• Borrel voor informeel netwerken

4. Kennisdeling faciliteren

Creëer een kennisbasis:

• Wiki of documentatiesite: Centraal punt voor alle informatie
• FAQ: Verzamel veelgestelde vragen en antwoorden
• Use cases: Inspirerende voorbeelden van gebruik
• Tutorials: Stapsgewijze handleidingen
• Video’s: Screencasts van installatie, configuratie, gebruik

Stimuleer kennisdeling:

• Show & tell sessies: Gemeente toont hun specifieke toepassing
• Lessons learned: Deel expliciete leerervaringen (ook mislukkingen!)
• Community call: Maandelijkse open sessie voor Q&A
• Knowledge champions: Gemeenten met specifieke expertise als aanspreekpunt

5. Bijdragen stimuleren

Maak het makkelijk om bij te dragen:

Code bijdragen:

• Duidelijke CONTRIBUTING.md met proces
• Good first issue labels voor beginners
• Code review feedback die leerzaam is
• Erkenning van bijdragen (contributors lijst)

Non-code bijdragen:

• Documentatie verbeteren
• Bug reports schrijven
• Features suggereren
• Nieuwe gebruikers helpen
• Presentaties geven op events

Erken en waardeer:

• Persoonlijke dank voor bijdragen
• Highlight in nieuwsbrief (“contributor of the month”)
• Certificaten of badges voor actieve bijdragers
• Speciale rol/status in community (ambassadeur, champion)

Praktische tips

Start klein en bouw op

Je hoeft niet meteen alle bovenstaande activiteiten te doen. Begin met:

1. Basis communicatiekanaal
2. Kwartaal gebruikersoverleg
3. Onboarding-materiaal voor nieuwe gemeenten

Voeg activiteiten toe naarmate de community groeit.

Maak het persoonlijk

Mensen verbinden met mensen, niet met organisaties. Faciliteer persoonlijk contact, gebruik video calls, organiseer fysieke bijeenkomsten. Een sterke community heeft gezichten en namen, niet alleen logo’s.

Vier successen

Deel positieve ontwikkelingen: nieuwe gemeenten, geleverde features, opgeloste problemen. Dit creëert momentum en positieve energie.

Wees transparant over uitdagingen

Verberg problemen niet. Een volwassen community kan omgaan met tegenslagen als je eerlijk communiceert. Dit bouwt vertrouwen.

Investeer in de lange termijn

Community-building kost tijd en moeite maar betaalt zich terug in duurzaamheid en veerkracht. Een sterke community maakt de samenwerking minder kwetsbaar.

Tip: Een community is geen doel op zich, maar een middel. Het ultieme doel is dat gemeenten beter hun werk kunnen doen dankzij de samenwerking. Blijf dat centrale doel voor ogen houden bij alle community-activiteiten.

Stap 6: Organiseer samenwerking met de markt

Een van de grootste uitdagingen bij open source samenwerkingen is het ontwikkelen van een gezond leveranciersecosysteem. In de praktijk zien we te vaak dat een open source oplossing afhankelijk blijft van één leverancier - meestal de initiële ontwikkelaar. Dit creëert vendor lock-in, precies wat open source juist zou moeten voorkomen.

Deze stap helpt je om een markt te creëren waarin meerdere leveranciers kunnen concurreren en gemeenten echte keuzevrijheid hebben.

De uitdaging: van vendor lock-in naar ecosysteem

De typische situatie

Fase 1: Ontstaan (1 leverancier)

• Een gemeente ontwikkelt met één leverancier een oplossing
• De oplossing wordt open source gemaakt
• Andere gemeenten willen meedoen
• Maar: kennis zit volledig bij die ene leverancier

De valkuil:

• Nieuwe gemeenten vragen dezelfde leverancier voor ondersteuning
• Leverancier krijgt monopoliepositie zonder formele lock-in
• Andere leveranciers durven niet te investeren (te klein, te onzeker)
• Gemeenten denken dat ze keuzevrijheid hebben, maar in de praktijk niet

Het gevolg:

• Geen competitie op prijs of kwaliteit
• Afhankelijkheid van beschikbaarheid en bereidheid van die ene partij
• Beperkte innovatie (geen verschillende perspectieven)
• Risico bij falen of exit van die leverancier

Waarom is het lastig nieuwe leveranciers te krijgen?

Gemeenten noemen vaak:

• “Nieuwe leveranciers willen niet”
• “Ze snappen open source niet”
• “Het is te complex om in te stappen”

Leveranciers noemen vaak:

• “Te onzeker, we weten niet hoe groot de markt is”
• “Geen level playing field met de oorspronkelijke ontwikkelaar”
• “Te veel investering vooraf zonder garanties”
• “Onduidelijk waar we op kunnen concurreren”

De oplossing: actief een ecosysteem bouwen

Het creëren van een gezond leveranciersecosysteem vraagt bewuste sturing van gemeenten. Het gebeurt niet vanzelf.

Stap 1: Maak de markt transparant en aantrekkelijk

Creëer marktzekerheid:

Publiceer duidelijke informatie over:

• Huidige schaal: Hoeveel gemeenten gebruiken de oplossing?
• Groeitraject: Hoeveel nieuwe gemeenten verwacht (niet: hopen)?
• Contractwaarde: Wat is de totale markt? (bijv. “20 gemeenten, gemiddeld €15k/jaar = €300k jaarlijks”)
• Groeiambitie: Welke doelgroep (bijv. “alle 50 gemeenten met >100k inwoners”)

Voorbeeld: GEM Chat marktinformatie

Huidige situatie (2025):

• 25 gemeenten live
• Gemiddeld contract: €12.000/jaar voor SaaS + support
• Totale marktwaarde: €300.000/jaar

Groeitraject (2026-2027):

• Target: 50 gemeenten
• Potentiële marktwaarde: €600.000/jaar
• Nieuwe aanbesteding gepland: Q2 2026

Rollen beschikbaar voor leveranciers:

• SaaS-hosting en beheer (€8k/gemeente/jaar)
• Maatwerk en integratie (€4k/gemeente/jaar)
• Support en training (€2k/gemeente/jaar)

Dit geeft leveranciers concrete business case om te investeren in de oplossing.

Stap 2: Definieer verschillende leveranciersrollen

Breek de vendor lock-in door rollen te scheiden. Niet één leverancier doet alles, maar verschillende partijen vullen verschillende rollen.

Mogelijke rollen in het ecosysteem:

1. SaaS-provider / Hosting-partij

• Verantwoordelijkheid: Beschikbaar houden van de applicatie
• Competitie op: Uptime, performance, security, prijs
• Waarde: €6.000-12.000 per gemeente per jaar
• Entry barrier: Hoog (infrastructuur kennis, security)

2. Implementatie-specialist / Integrator

• Verantwoordelijkheid: Software koppelen aan lokale systemen
• Competitie op: Snelheid, kwaliteit, lokale aanwezigheid
• Waarde: €5.000-20.000 per gemeente (eenmalig)
• Entry barrier: Middel (technische kennis, API-integratie)

3. Feature developer / Innovator

• Verantwoordelijkheid: Nieuwe functionaliteit ontwikkelen
• Competitie op: Innovatiekracht, ontwikkelsnelheid, prijs
• Waarde: €50.000-200.000 per feature (gedeeld over gemeenten)
• Entry barrier: Middel (kennis codebase, open source werkwijze)

4. Support-organisatie / Helpdesk

• Verantwoordelijkheid: Gebruikers ondersteunen
• Competitie op: Responsietijd, klanttevredenheid, bereikbaarheid
• Waarde: €1.000-3.000 per gemeente per jaar
• Entry barrier: Laag (product kennis, geen development)

5. Training & Advies

• Verantwoordelijkheid: Gebruikers opleiden, procesoptimalisatie
• Competitie op: Didactische kwaliteit, inhoudelijke kennis
• Waarde: €2.000-5.000 per gemeente (eenmalig + refresh)
• Entry barrier: Laag (product kennis, adviseurschap)

6. Community manager / Coördinator

• Verantwoordelijkheid: Community faciliteren, roadmap-coördinatie
• Competitie op: Organisatietalent, overstijgend vermogen
• Waarde: €30.000-60.000 per jaar (voor alle gemeenten samen)
• Entry barrier: Laag (social skills, geen techniek)

Stap 3: Creëer een level playing field

Zorg dat iedere leverancier toegang heeft tot:

Technische documentatie:

• Architectuur-overzicht
• API-documentatie
• Deployment-handleidingen
• Development environment setup
• Code standards en conventions

Kennisdeling:

• Toegang tot community Slack/forum
• Deelname aan technische werkgroepen
• Inzicht in roadmap en prioriteiten
• Toegang tot gebruikersfeedback

Procurement-informatie:

• Aanbestedingskalender (wanneer wat opnieuw in de markt?)
• Contractvoorwaarden en SLA’s
• Gunningscriteria (waar wordt op beoordeeld?)
• Referentie-implementaties

Praktijk voorbeeld:

Publiceer een “Supplier Information Pack” met:

• Productvisie en roadmap
• Technische architectuur
• Huidige klanten en use cases
• Marktomvang en groei
• Rolomschrijvingen en kansen
• Contact voor vragen

Organiseer een “Supplier Day”:

• Presentatie product en visie
• Demo’s en technische deep-dive
• Q&A met product owners en gebruikers
• Networking met gemeenten
• Publiceer opname voor wie niet aanwezig kon zijn

Stap 4: Pas aan uw inkoop- en aanbestedingsproces

Voorkom onbedoeld vendor lock-in in aanbestedingen:

❌ Verkeerd: Alles in één perceel

Perceel 1: SaaS-hosting, doorontwikkeling, support, training Resultaat: Alleen grote partijen kunnen inschrijven, vaak wint de incumbent

✅ Goed: Modulaire percelen

Perceel 1: SaaS-hosting en beheer Perceel 2: Feature development (per feature af te roepen) Perceel 3: Support en training Resultaat: Verschillende leveranciers, specialisatie, flexibiliteit

Gunningscriteria die ecosysteem ondersteunen:

Vermijd:

• “Ervaring met dit specifieke product” (bevoordeelt initieel ontwikkelaar)
• “Referenties bij Nederlandse gemeenten” (bevoordeelt gevestigde partijen)
• Zeer lage prijzen als enig criterium (race to the bottom)

Gebruik:

• “Open source ontwikkelervaring” (neutraler)
• “Bijdragen aan open source projecten” (stimuleert participatie)
• Balans prijs/kwaliteit (30/70 ipv 100% prijs)
• Community bijdrage als criterium (10-15%)
• “Plan om bij te dragen aan doorontwikkeling”

Contractuele bepalingen voor vendor lock-in preventie:

Neem op in contracten:

• Kennisdeling-verplichting: Leverancier documenteert alle aanpassingen en deelt kennis met community
• Overdraagbaarheid: Bij einde contract moet overdracht naar andere partij soepel verlopen
• Open source contributie: Alle ontwikkelde code wordt bijgedragen aan de open source repository
• Standaarden: Gebruik van open standaarden en API’s (geen proprietary extensies)
• Exit-ondersteuning: Leverancier ondersteunt transitie naar andere partij bij contracteinde

Stap 5: Stimuleer nieuwe toetreders actief

Maak het aantrekkelijk om te starten:

Kleine start-opdrachten (“foot in the door”):

• Specifieke kleine features (€5-10k)
• Proof-of-concept voor nieuwe module
• Documentatie-verbetering
• Support voor pilot-periode

Dit laat nieuwe partijen kennismaken met:

• De codebase en technologie
• De werkwijze en community
• De gemeenten als klant

Met lage investment en beperkt risico.

Pilot-regelingen:

• Nieuwe leverancier mag 2-3 gemeenten bedienen in pilot
• Begeleiding door initiële ontwikkelaar (knowledge transfer)
• Evaluatie na 6 maanden
• Bij succes: meedingen naar grotere contracten

Community-betrokkenheid waarderen:

In aanbestedingen:

• 10-15% van score voor “community contributie”
• Punten voor: code bijdragen, documentatie, forum-activiteit, event-participatie
• Dit stimuleert leveranciers om actief te investeren in community

Stap 6: Organiseer kennisoverdracht en samenwerking

Van concurrent naar co-creator:

Het doel is niet dat leveranciers elkaar beconcurreren op een zero-sum game, maar dat ze samen het ecosysteem versterken.

Faciliteer leveranciers-overleg:

Leveranciers Werkgroep (kwartaal):

• Bespreek technische issues en oplossingen
• Coördineer wie welke features oppakt
• Deel beste practices
• Voorkom dubbel werk

Technische sessies:

• Deep-dives in architectuur
• Code reviews samen doen
• Security & performance optimalisatie
• Innovation days

Kennis-uitwisseling:

• Documentatie gezamenlijk verbeteren
• Troubleshooting guides schrijven
• Best practices delen
• Training materiaal ontwikkelen

Waarom werkt dit?

• Verlaagt kosten voor iedereen (gemeenschappelijke investering)
• Verhoogt kwaliteit (meer ogen, meer expertise)
• Vergroot de markt (betere producten = meer gemeenten)
• Creëert reputatie (zichtbaarheid in community)

Governance: de rol van gemeenten

Gemeenten moeten actief sturen op ecosysteem-ontwikkeling:

Product Owner / Roadmap-bepaling:

• Gemeenten bepalen wát er ontwikkeld wordt
• Niet de leverancier
• Dit voorkomt feature-bloat en vendor-sturing

Neutrale arbiter:

• Bij conflicten tussen leveranciers
• Bij discussies over architectuur-keuzes
• Bij vragen over standards

Community-facilitator:

• Organiseer supplier days
• Faciliteer leveranciers-werkgroep
• Creëer transparantie en fair play

Contracthouder:

• Modulaire contractering
• Bewuste rolscheiding
• Transparante procurement

Monitoring: gezondheid van het ecosysteem

Goede indicatoren:

• Meerdere leveranciers actief (groei loopt gelijk op met groei nieuwe gemeenten)
• Nieuwe leveranciers treden toe
• Concurrentie op verschillende dimensies (prijs, kwaliteit, innovatie)
• Leveranciers dragen bij aan community (code, documentatie)
• Gemeenten kunnen makkelijk wisselen van leverancier
• Leveranciers werken samen (geen pure concurrentie)

Waarschuwingssignalen:

• Nog steeds >80% omzet bij één leverancier
• Nieuwe partijen haken af na verkenning
• Prijzen dalen niet of stijgen
• Geen nieuwe features van leveranciers (alleen van gemeenten)
• Gemeenten kunnen niet wisselen (te complex/duur)
• Leveranciers claimen “eigen variant” of “verbetering” zonder open source te delen

Veelvoorkomende valkuilen

Valkuil 1: “De markt lost het zelf wel op”

Mythe: Als we het open source maken, komt de markt vanzelf. Realiteit: Zonder actieve sturing blijft één leverancier domineren. Oplossing: Gemeenten moeten actief sturen (zie stappenplan hierboven).

Valkuil 2: “Te klein, geen partij geïnteresseerd”

Mythe: Onze markt is te klein voor meerdere leveranciers. Realiteit: Ook bij 10-15 gemeenten kan een ecosysteem ontstaan als je rollen scheidt. Oplossing: Begin met kleine rollen (support, training) en bouw op. Niet alles tegelijk.

Valkuil 3: “Oorspronkelijke leverancier heeft voorsprong, unfair”

Mythe: We moeten de initiële ontwikkelaar bevoordelen, ze hebben het initiatief genomen. Realiteit: Initiële voordeel is logisch, maar moet afnemen in de tijd. Oplossing:

• Jaar 1-2: Extra waardering voor initiële investering (bijv. in gunningscriteria)
• Jaar 3+: Level playing field voor iedereen
• Kennisoverdracht-verplichting voor incumbent

Valkuil 4: “Open source = gratis, niemand verdient eraan”

Mythe: Open source betekent dat leveranciers er geen geld aan verdienen. Realiteit: Business model verschuift van licenties naar services. Oplossing: Wees expliciet over betaalde diensten:

• SaaS hosting
• Support en training
• Maatwerk en integratie
• Consultancy

Valkuil 5: “Technische complexiteit”

Mythe: Open source is te complex voor meerdere leveranciers. Realiteit: Complexiteit is vaak excuus, geen reden. Oplossing:

• Investeer in documentatie
• Modulaire architectuur
• Open standaarden en API’s
• Leveranciers-training

Praktische tips

Start early

Denk al in de pilot-fase na over het ecosysteem. Wacht niet tot je 20 gemeenten hebt. Bij 5-10 gemeenten kun je al verschillende leveranciers betrekken.

Wees expliciet

Communiceer duidelijk dat het doel is om meerdere leveranciers te hebben. Dit voorkomt teleurstellingen en creëert een duidelijke verwachting.

Beloon samenwerking

Geef waardering (in contracten, in de community) aan leveranciers die bijdragen aan het gemeenschappelijk belang.

Maak het concreet

Niet: “We willen meerdere leveranciers” Wel: “In 2026 willen we minimaal 3 leveranciers actief hebben, waarvan minimaal 1 nieuwe toetreder”

Meet en stuur

Monitor de gezondheid van het ecosysteem (zie boven) en stuur bij als het niet de goede kant opgaat.

Durf te experimenteren

Probeer nieuwe modellen (pilot-regelingen, start-opdrachten). Niet alles werkt direct, leer van wat wel en niet werkt.

Tip: Een gezond leveranciersecosysteem is geen luxe maar noodzaak voor duurzame open source samenwerking. Het voorkomt vendor lock-in, stimuleert innovatie en verlaagt kosten. Het vraagt investering en actieve sturing van gemeenten, maar betaalt zich terug in keuzevrijheid en kwaliteit.

Stap 7: Stel een samenwerkingsovereenkomst op

Een samenwerkingsovereenkomst legt de afspraken tussen gemeenten juridisch vast. Het document beschermt alle partijen, voorkomt misverstanden en biedt houvast bij wijzigingen of conflicten.

De overeenkomst hoeft niet complex te zijn, maar moet wel de belangrijkste afspraken bevatten.

Wanneer heb je een overeenkomst nodig?

Niet altijd nodig:

Bij ‘Delen zonder regie’ (code op publieke repo zonder verdere afspraken) is geen overeenkomst nodig. De open source licentie regelt het gebruik.

Wel nodig vanaf:

• Lichte coördinatie met kosten of verplichtingen
• Gestructureerde samenwerking
• Volledige regie
• Zodra er een communitybijdrage wordt gevraagd
• Zodra er gezamenlijke contracten met leveranciers komen

Wat leg je vast in de overeenkomst?

De samenwerkingsovereenkomst brengt alle eerder gemaakte keuzes samen. Het is geen nieuw beslismoment, maar het vastleggen van wat jullie al hebben afgesproken.

1. Partijen en doel

• Wie: Welke gemeenten nemen deel (met bijlage voor toekomstige toetreders)
• Wat: Om welke software/toepassing gaat het
• Waarom: Wat is het doel van de samenwerking

2. Governance (zie stap 3)

• Overlegstructuur (gebruikersoverleg, stuurgroep)
• Besluitvormingsmethoden
• Mandaten en bevoegdheden
• Overlegfrequentie

3. Rollen en taken (zie stap 2)

• Concrete rolbezetting (wie doet wat)
• Eventuele rol van penvoerder

4. Financiën (zie stap 4)

• Financieringsmodel en verdeelsleutel
• Hoogte communitybijdrage
• Betalingstermijnen en -voorwaarden
• Kostenverdeling bij onvoorziene uitgaven
• Financiële verantwoording

5. Intellectueel eigendom (zie stap 8)

• Eigendom van de code
• Open source licentie
• Rechten op bijdragen van gemeenten en leveranciers

6. Duur, wijziging en beëindiging

• Looptijd: Voor bepaalde tijd (bijv. 3 jaar met automatische verlenging) of onbepaalde tijd
• Opzegging: Opzegtermijn en modaliteiten (bijv. 6 maanden voor einde kalenderjaar)
• Wijziging: Hoe kun je de overeenkomst aanpassen (welke meerderheid)
• Afwikkeling: Wat gebeurt er met code en lopende contracten bij beëindiging

7. Nieuwe deelnemers en uittreding

• Voorwaarden voor toetreding (welke gemeenten, welke criteria)
• Procedure voor toelating (hoe wordt besloten, wie stemt)
• Opzegging door individuele gemeente (termijn, gevolgen)
• Toegang tot code blijft bestaan (via open source licentie)

8. Aansprakelijkheid en waarborgen

• Software wordt geleverd ‘as is’ (geen garanties)
• Beperking aansprakelijkheid tussen gemeenten
• Elke gemeente verantwoordelijk voor eigen implementatie
• AVG en privacy: elke gemeente is zelf verwerkingsverantwoordelijke

9. Geschillenregeling

• Eerst onderling overleg
• Bij impasse: mediator of bindend advies
• Toepasselijk recht: Nederlands recht

10. Overige bepalingen

• Communicatie en vertrouwelijkheid
• Gebruik naam en logo’s
• Evaluatie en rapportage

Praktische tips

Houd het simpel en leesbaar

Vermijd juridisch jargon waar mogelijk. De overeenkomst moet door iedereen te begrijpen zijn. Gebruik bijlagen voor technische details.

Start met een concept

Gebruik een template (zie bijlage) en pas deze aan op jullie situatie. Laat juridische afdeling meekijken, maar laat het geen 50-pagina monster worden.

Bijlagen zijn je vriend

Leg zaken die vaak wijzigen (lijst deelnemers, hoogte bijdrage, concrete rollen) in bijlagen vast. Dan hoef je niet de hele overeenkomst te wijzigen.

Ondertekening

Bepaal wie moet tekenen. Bij kleine gemeenten volstaat vaak de afdelingshoofd, bij grotere keuzes mogelijk wethouder of college. Check jullie mandaatregeling.

Keuzegids en templates

Om je op weg te helpen bij het opstellen van een samenwerkingsovereenkomst, hebben we een keuzegids en twee templates beschikbaar:

1. Keuzegids samenwerkingsovereenkomst

Download keuzegids

Een handleiding die je helpt bij het maken van keuzes voor je samenwerkingsovereenkomst. Loop deze door voordat je begint met invullen van de templates.

2. Template samenwerkingsovereenkomst

Download template

Een voorbeeldovereenkomst die je kunt aanpassen aan jullie specifieke situatie. Het template bevat alle essentiële elementen en invulopties.

3. Template addendum

Download addendum template

Een template voor het addendum bij de samenwerkingsovereenkomst. Gebruik dit voor zaken die regelmatig wijzigen, zoals de lijst met deelnemende gemeenten of de hoogte van de communitybijdrage.

Stap 8: Regel intellectueel eigendom

Bij open source samenwerking is helder wie eigenaar is van de code en onder welke voorwaarden deze gebruikt mag worden. Dit voorkomt juridische problemen en stimuleert bijdragen.

Intellectueel eigendom (IE) gaat over drie vragen: wie is eigenaar, wat mag iedereen ermee, en wat gebeurt er met bijdragen van anderen?

1. Eigendom van de code

Vaak wordt bij open source ten onrechte gedacht dat er geen sprake is van Intelectueel Eigendom. Dit is er wel degelijk en het is belangrijk om bij de ontwikkeling van open source software na te denken waar dit ligt. Hieronder zijn twee modellen geschetst wie juridisch eigenaar is van de code:

Model A - Gemeenschappelijk eigendom

Hoe werkt het:

Alle deelnemende gemeenten zijn gezamenlijk eigenaar. Niemand kan individueel over de code beschikken.

Voordelen:

• Gelijkwaardigheid tussen gemeenten
• Continuïteit los van individuele gemeenten
• Niemand kan eenzijdig beslissen
• Past bij samenwerkingsgedachte

Nadelen:

• Juridisch complex bij uittreding gemeente
• Wat als één gemeente bezwaar maakt tegen iets?

Geschikt voor: Kleine groepen (2-8 gemeenten) met hoge mate van vertrouwen

Model B - Eén gemeente als eigenaar

Hoe werkt het:

Eén gemeente (vaak de initiatiefnemer) blijft juridisch eigenaar. Andere gemeenten krijgen gebruiksrecht via de open source licentie.

Voordelen:

• Juridisch eenvoudig
• Duidelijk aanspreekpunt naar buiten
• Eigenaar kan snel beslissen

Nadelen:

• Ongelijkheid tussen gemeenten
• Andere gemeenten afhankelijk van eigenaar
• Eigenaar draagt juridische verantwoordelijkheid

Let op:

Leg in de samenwerkingsovereenkomst vast dat de eigenaar niet eenzijdig de licentie kan wijzigen en dat andere gemeenten invloed hebben op de richting.

Geschikt voor: Lichte coördinatie waarbij één gemeente duidelijk trekker is

Model C - Onafhankelijke partij (bijvoorbeeld stichting)

Hoe werkt het:

Een onafhankelijke rechtspersoon (bijvoorbeeld een stichting) wordt juridisch eigenaar van de code. Deelnemende gemeenten hebben zeggenschap via het bestuur van deze organisatie.

Voordelen:

• Neutrale eigenaar zonder eigen belang
• Continuïteit los van individuele gemeenten
• Professionele governance structuur mogelijk
• Duidelijk extern aanspreekpunt

Nadelen:

• Extra juridische en bestuurlijke lasten (statuten, bestuur, AVG-verantwoordelijkheid)
• Oprichtingskosten en jaarlijkse administratie
• Risico van vervreemding tussen stichting en gemeenten

Let op:

Leg in de statuten vast hoe gemeenten zeggenschap hebben (bijvoorbeeld: elk bestuurslid vertegenwoordigt X gemeenten). Bepaal ook wat er gebeurt bij ontbinding van de stichting met het eigendom van de code. Zorg dat de stichting geen winstoogmerk heeft (ANBI-status kan fiscaal voordelig zijn).

Geschikt voor: Grote groepen gemeenten, strategisch belangrijk product waar lange termijn continuïteit essentieel is, of wanneer meerdere producten onder één gezamenlijke externe constructie worden gebracht.

2. Open source licentie

Ongeacht wie eigenaar is: de code wordt gepubliceerd onder een open source licentie. Die licentie bepaalt wat iedereen (binnen en buiten de samenwerking) met de code mag doen.

De keuze van licentie wordt uitgebreid behandeld in Stap 9. Voor intellectueel eigendom is het belangrijkste:

• De licentie geeft iedereen recht om de code te gebruiken, kopiëren en aanpassen
• Ook als een gemeente uitstapt, mag ze de code blijven gebruiken (via de licentie)
• De licentie is onherroepelijk: je kunt hem niet meer intrekken

3. Bijdragen van gemeenten en leveranciers

Wanneer gemeenten of leveranciers code bijdragen, moet helder zijn dat deze bijdragen onder dezelfde licentie vallen. Dit regelen jullie met een Contributor License Agreement (CLA).

Wat is een CLA?

Een CLA is een korte verklaring waarin de bijdrager bevestigt dat:

1. Ze het recht hebben om de code bij te dragen (het is hun eigen werk of ze hebben toestemming)
2. De bijdrage onder de gekozen open source licentie valt
3. De bijdrage geen inbreuk maakt op rechten van derden

Twee varianten

Developer Certificate of Origin (DCO):

Lichtgewicht variant. Developer tekent digitaal (via ‘Signed-off-by’ in commit message) dat bijdrage aan voorwaarden voldoet. Simpel en gebruikelijk bij open source projecten.

Formele CLA:

Uitgebreider document dat apart getekend wordt. Biedt meer juridische zekerheid maar is bewerkelijker. Vooral relevant bij commerciële partijen of strategische software.

Aanbeveling: Voor gemeentelijke samenwerkingen is DCO meestal voldoende. Gebruik alleen formele CLA als juristen daar sterk op aandringen.

Bijdragen van leveranciers

Wanneer jullie leveranciers inhuren voor doorontwikkeling, neem dan expliciet op in het contract:

• Alle door leverancier ontwikkelde code wordt eigendom van [gemeente/stichting/gemeenschappelijk]
• Code wordt gepubliceerd onder [gekozen open source licentie]
• Leverancier garandeert dat code geen inbreuk maakt op rechten van derden
• Leverancier mag code niet voor commerciële doeleinden hergebruiken (tenzij je dat wél wilt)

Praktische tips

Kies eigendomsmodel passend bij ambitie

Kleine groep, informeel → Één gemeente eigenaar. Gestructureerd, professioneel → Gemeenschappelijk of stichting.

Licentie is belangrijker dan eigendom

Door open source licentie kan iedereen de code gebruiken, ongeacht wie eigenaar is. Focus op goede licentiekeuze.

Leg het vast, maar maak het niet complex

Een paragraaf in de samenwerkingsovereenkomst over IE is voldoende. Verwijs naar de gekozen licentie voor details.

Check contracten met leveranciers

Veel standaardcontracten geven leverancier auteursrecht. Pas dit expliciet aan voor open source ontwikkeling.

Tip: Vraag juridische afdeling niet om het perfecte IE-model te bedenken, maar presenteer één van de drie modellen en vraag hen dat uit te werken. Dat voorkomt eindeloze juridische discussies.

Stap 9: Kies een open source licentie

Een open source licentie bepaalt wat anderen met jullie code mogen doen. Het is de juridische basis van jullie open source samenwerking. De keuze van licentie heeft grote consequenties voor hergebruik, doorontwikkeling en commercieel gebruik.

Deze stap helpt je een weloverwogen keuze te maken tussen de belangrijkste licenties die voor gemeentelijke software relevant zijn.

Wat doet een open source licentie?

Een open source licentie geeft iedereen (binnen en buiten de samenwerking) het recht om:

• Te gebruiken: De software voor elk doel inzetten
• Te bestuderen: De broncode inzien en begrijpen hoe het werkt
• Te wijzigen: Aanpassingen maken voor eigen gebruik
• Te verspreiden: Kopiëren en delen met anderen (al dan niet met aanpassingen)

Maar licenties kunnen wel voorwaarden stellen aan hoe dit mag. En daar zit het verschil tussen licenties.

Twee hoofdtypen: Permissief vs Copyleft

Open source licenties vallen uiteen in twee families:

Permissieve licenties (vrijgevige aanpak)

Principe:

Doe ermee wat je wilt, ook commercieel. Je mag de code zelfs in gesloten producten verwerken.

Voorbeelden:

MIT, Apache 2.0, BSD

Effect:

Maximale vrijheid, maar ook maximaal risico dat anderen de code commercieel exploiteren zonder iets terug te geven aan de community.

Copyleft licenties (reciproque aanpak)

Principe:

Je mag de code gebruiken en aanpassen, maar als je het verspreid moet je wijzigingen ook open source maken onder dezelfde licentie.

Voorbeelden:

GPL, EUPL, AGPL

Effect:

Beschermt tegen commerciële toe-eigening. Verbeteringen blijven beschikbaar voor de community. Maar kan drempel opwerpen voor gebruik door partijen die code willen sluiten.

Overzicht relevante licenties voor gemeenten

Hieronder de belangrijkste licenties, hun kenmerken en wanneer ze passen:

EUPL 1.2 (European Union Public License)

Type:

Copyleft (matige sterkte)

Kernpunten:

• Speciaal ontwikkeld voor Europese overheden
• Officieel beschikbaar in alle EU-talen
• Copyleft: wijzigingen moeten open source blijven
• Compatibel met GPL en andere belangrijke licenties
• Beschermt tegen patentclaims

Voordelen:

• Door en voor overheden gemaakt
• Nederlandse vertaling beschikbaar
• Voorkomt dat commerciële partijen code ‘dichtdoen’
• Balans tussen openheid en bescherming

Nadelen:

• Minder bekend buiten Europa
• Leveranciers moeten begrijpen wat het betekent
• Copyleft kan drempel zijn voor sommige gebruikers

Geschikt voor: Gemeentelijke samenwerking waarbij je wilt voorkomen dat leveranciers de code sluiten. Standaardkeuze voor veel Nederlandse gemeenten.

MIT License

Type:

Permissief

Kernpunten:

• Zeer korte en simpele licentie
• Minimale restricties
• Mag in commerciële producten verwerkt worden
• Geen verplichting om wijzigingen te delen

Voordelen:

• Zeer breed geaccepteerd
• Makkelijk te begrijpen
• Geen drempels voor gebruik
• Maximale verspreiding mogelijk

Nadelen:

• Geen garantie dat verbeteringen terugkomen
• Commerciële partijen kunnen afgeleide producten sluiten
• Geen patentbescherming

Geschikt voor: Wanneer maximale verspreiding en adoptie belangrijker is dan bescherming. Kleine tools, bibliotheken, of als je commercieel hergebruik wilt stimuleren.

Apache License 2.0

Type:

Permissief (met patentbescherming)

Kernpunten:

• Lijkt op MIT maar met expliciete patentclausule
• Beschermt tegen patentclaims
• Commercieel gebruik toegestaan
• Geen verplichting om wijzigingen te delen

Voordelen:

• Breed geaccepteerd in tech-industrie
• Betere patentbescherming dan MIT
• Duidelijk over contributie-rechten

Nadelen:

• Complexer dan MIT
• Geen copyleft (verbeteringen kunnen privé blijven)

Geschikt voor: Wanneer patentbescherming belangrijk is maar copyleft niet gewenst. Vaak gebruikt bij infrastructuur-software.

GNU GPL 3.0 (General Public License)

Type:

Sterke copyleft

Kernpunten:

• Strikte copyleft: alle afgeleide werken moeten GPL zijn
• Beschermt sterk tegen commerciële toe-eigening
• Patentbescherming inbegrepen
• Meest gebruikte copyleft licentie wereldwijd

Voordelen:

• Maximale bescherming: verbeteringen blijven open
• Wereldwijd bekend en getest
• Sterke community van gebruikers

Nadelen:

• Kan drempel zijn voor bedrijfsleven
• ‘Virale’ werking: code die GPL-code gebruikt moet ook GPL worden
• Engelse tekst (geen officiële NL-versie)

Geschikt voor: Wanneer je wilt garanderen dat alle verbeteringen open blijven. Bijvoorbeeld bij strategische software waar lock-in voorkomen moet worden.

GNU AGPL 3.0 (Affero GPL)

Type:

Zeer sterke copyleft (inclusief SaaS)

Kernpunten:

• Zoals GPL, maar ook voor webservices
• Als je de software als dienst aanbiedt, moet je de code delen
• Sluit ‘SaaS loophole’ van GPL

Voordelen:

• Maximale bescherming ook tegen SaaS-exploitatie
• Voorkomt dat bedrijven de code als gesloten dienst aanbieden

Nadelen:

• Zeer restrictief, grote drempel voor commerciële partijen
• Kan adoptie belemmeren
• Complex in de praktijk

Geschikt voor: Webapplicaties waar je wilt voorkomen dat partijen er een gesloten SaaS-dienst van maken. Vooral relevant bij cloud-based software.

Vergelijkingstabel

Beslishulp: welke licentie past bij jullie?

Doorloop deze vragen om tot een keuze te komen:

Vraag 1: Is het belangrijk dat verbeteringen open blijven?

• Ja, absoluut: Kies copyleft (EUPL, GPL, AGPL)
• Nee, maximale verspreiding belangrijker: Kies permissief (MIT, Apache)

Vraag 2: Willen jullie specifiek voorkomen dat leveranciers de code sluiten?

• Ja: EUPL of GPL
• Nee: MIT of Apache

Vraag 3: Is het een webapplicatie die als dienst aangeboden kan worden?

• Ja, en we willen SaaS-exploitatie voorkomen: AGPL
• Ja, maar dat mag: MIT of Apache
• Nee, geen webapp: EUPL, GPL, MIT of Apache

Vraag 4: Is patentbescherming belangrijk?

• Ja: Apache, EUPL, GPL of AGPL (alle hebben patentclausule)
• Nee/niet relevant: MIT kan ook

Vraag 5: Hecht je waarde aan Europese context?

• Ja, Nederlandse/Europese voorkeur: EUPL (officiële NL-vertaling)
• Nee, internationale standaard: MIT, Apache of GPL

Aanbevelingen per scenario

Scenario 1: Gemeente-applicatie voor dienstverlening

Bijvoorbeeld: zaaksysteem, vergunningensysteem, participatieplatform

Aanbeveling: EUPL 1.2 - Voorkomt vendor lock-in, houdt verbeteringen open, geschikt voor overheden.

Scenario 2: Kleine tool of bibliotheek

Bijvoorbeeld: validatie-tool, API-client, herbruikbare component

Aanbeveling: MIT - Maximale adoptie, eenvoudig, breed geaccepteerd.

Scenario 3: Strategische infrastructuur-software

Bijvoorbeeld: burgerzaken-platform, gemeentelijk dataplatform

Aanbeveling: GPL 3.0 of EUPL 1.2 - Sterke bescherming tegen toe-eigening, waarborgt continuïteit.

Scenario 4: Cloud-based webapplicatie

Bijvoorbeeld: online formulieren, digitaal loket, meldsysteem

Aanbeveling: AGPL 3.0 - Voorkomt dat partijen een gesloten SaaS-variant maken.

Scenario 5: Willen commerciële sector stimuleren

Bijvoorbeeld: innovatieve technologie die je breed wilt verspreiden

Aanbeveling: Apache 2.0 - Permissief maar met patentbescherming, aantrekkelijk voor bedrijven.

Praktische tips

Beslis vroeg, maar niet te vroeg

Kies de licentie voordat je code publiceert. Maar als je nog experimenteert, wacht dan totdat je weet wat je gaat bouwen.

Je kunt later niet meer veranderen

Een eenmaal gekozen licentie is moeilijk te wijzigen. Je hebt toestemming nodig van alle contributors. Kies dus zorgvuldig.

LICENTIE-bestand in repository

Plaats altijd een LICENSE of LICENTIE.txt bestand in de root van je repository met de volledige licentietekst.

Copyright notices in broncode

Voeg aan elk bronbestand een korte copyright notice toe die verwijst naar de licentie.

Betrek juridische afdeling, maar…

Laat juridische adviseur meekijken, maar laat het geen jarenlang proces worden. De licenties die hier staan zijn bewezen en veilig te gebruiken.

Bij twijfel tussen permissief en copyleft

Voor gemeentelijke software: kies copyleft (EUPL). Het voorkomt vervelende verrassingen en past bij publieke waarden.

Tip: Kijk wat vergelijkbare projecten doen. Als er al een ecosysteem is van open source gemeente-software, kies dan een compatibele licentie.

Stap 10: Richt technische infrastructuur in

Open source samenwerking vraagt om technische infrastructuur: waar staat de code, hoe beheer je versies, hoe documenteer je, en hoe release je nieuwe versies? Deze stap helpt je de technische basis op orde te krijgen.

Goed ingerichte technische infrastructuur maakt samenwerken makkelijk en voorkomt chaos. Het hoeft niet perfect, maar wel praktisch werkbaar.

1. Code repository platform

De code repository is het centrale punt waar alle broncode staat. Het platform moet ondersteunen: versiebeheer, samenwerken, code review, en issue tracking.

GitHub

Kenmerken:

• Meest populaire platform wereldwijd
• Gratis voor publieke repositories
• Uitgebreide tooling (Actions, Projects, Discussions)
• Grote community en veel integraties

Voordelen:

• Developers zijn ermee vertrouwd
• Zichtbaarheid: mensen vinden je project makkelijk
• Veel documentatie en ondersteuning
• CI/CD via GitHub Actions

Nadelen:

• Eigendom Microsoft (kan bezwaar zijn)
• Data staat in VS (privacy-overwegingen)

Geschikt voor: Meeste gemeentelijke projecten. Standaardkeuze tenzij je specifieke redenen hebt om anders te kiezen.

GitLab

Kenmerken:

• Open source platform (kan zelf hosten)
• Gratis cloud-versie (gitlab.com)
• Uitgebreide DevOps-functionaliteit ingebouwd
• Sterke CI/CD

Voordelen:

• Kan zelf gehost worden (volledige controle)
• Europese cloud-optie beschikbaar
• Alles-in-één platform (planning, CI/CD, security)

Nadelen:

• Minder zichtbaar dan GitHub
• Self-hosting vraagt onderhoud en expertise
• Interface kan complex zijn

Geschikt voor: Wanneer je specifiek Europese hosting wilt of volledige controle door self-hosting nodig hebt.

code.overheid.nl

Kenmerken:

• Catalogus van Nederlandse overheids-software
• Geen hosting, maar verwijzingen naar repositories
• Beheerd door VNG en Logius

Gebruik:

Je host code op GitHub/GitLab, maar registreert project ook op code.overheid.nl voor vindbaarheid binnen overheidssector.

Aanbeveling: Gebruik GitHub of GitLab voor hosting, en registreer je project aanvullend op code.overheid.nl voor zichtbaarheid.

2. Repository-structuur en branching

Hoe organiseer je de code in de repository? Een heldere structuur voorkomt verwarring.

Repository-structuur

Minimaal aanwezig:

• README.md: Wat is dit project? Hoe installeren? Hoe gebruiken?
• LICENSE / LICENTIE.txt: Volledige tekst van de open source licentie
• CONTRIBUTING.md: Hoe kunnen anderen bijdragen?
• Code of Conduct: Gedragsregels voor community

Verder structuur:

• /src of /app: Broncode
• /docs: Documentatie
• /tests: Geautomatiseerde tests
• /examples: Voorbeeldcode

Branching strategie

Branches (vertakkingen) helpen om verschillende versies parallel te ontwikkelen. Voor gemeentelijke samenwerking volstaat vaak een eenvoudig model:

Simpel model (aanbevolen voor starten):

• main / master: Stabiele, productie-klare code
• feature branches: Voor nieuwe functionaliteit (bijv. feature/vergunningen)
• bugfix branches: Voor bug fixes

Uitgebreider model (bij intensieve ontwikkeling):

• main: Productie
• develop: Ontwikkelversie
• release/x.y: Voorbereiden releases
• feature/…: Nieuwe features

Tip: Start simpel. Je kunt altijd complexer worden als de samenwerking groeit.

3. Code review en kwaliteit

Open source betekent niet ‘alles mag’. Code review zorgt voor kwaliteit en kennisdeling.

Pull Request workflow

Wijzigingen worden niet direct in main gezet, maar via Pull Requests (GitHub) of Merge Requests (GitLab):

• Developer maakt feature branch
• Schrijft code + tests
• Opent Pull Request met beschrijving
• Anderen reviewen de code
• Na goedkeuring: merge naar main

Review-regels

Stel regels vast:

• Minimaal 1 review vereist (beter: 2)
• Tests moeten slagen
• Code voldoet aan style guide
• Geen eigen code reviewen

Geautomatiseerde checks

Zet geautomatiseerde checks in:

• Linting: Code style controleren
• Unit tests: Functionaliteit testen
• Security scanning: Kwetsbaarheden detecteren
• Code coverage: Testdekking meten

4. Documentatie

Goede documentatie is cruciaal voor hergebruik. Zonder documentatie blijft de beste code onbruikbaar.

Soorten documentatie

1. README.md (verplicht):

• Wat doet deze software?
• Voor wie is het bedoeld?
• Hoe installeer je het?
• Quick start voorbeeld
• Licentie-informatie

2. Installatie-instructies:

• Systeemvereisten
• Stap-voor-stap installatie
• Configuratie
• Veelvoorkomende problemen

3. Gebruikersdocumentatie:

• Functionaliteit uitgelegd
• Screenshots/video’s
• Use cases

4. Technische documentatie:

• Architectuur-overzicht
• API-documentatie
• Database schema
• Deployment-instructies

5. Bijdrage-richtlijnen (CONTRIBUTING.md):

• Hoe bij te dragen?
• Code style
• Pull request proces
• Testing vereisten

Documentatie-tools

• Markdown bestanden: Simpel, in repository, versie-beheerd
• GitHub/GitLab Wiki: Collaboratief, maar los van code
• ReadTheDocs / MkDocs: Professionele documentatie-sites
• Swagger / OpenAPI: Voor API-documentatie

Aanbeveling: Start met Markdown bestanden in /docs folder. Dat is laagdrempelig en werkt altijd.

5. Release management

Hoe breng je nieuwe versies uit? Release management zorgt voor duidelijkheid naar gebruikers.

Semantic Versioning

Gebruik semantic versioning (SemVer): MAJOR.MINOR.PATCH

• MAJOR (1.0.0 → 2.0.0): Breaking changes, niet backwards compatible
• MINOR (1.0.0 → 1.1.0): Nieuwe functionaliteit, backwards compatible
• PATCH (1.0.0 → 1.0.1): Bug fixes, backwards compatible

Release proces

Eenvoudig proces:

• Bepaal versienummer
• Update CHANGELOG.md met wijzigingen
• Tag de release in Git (v1.2.0)
• Maak GitHub/GitLab release aan
• Communiceer release naar gebruikers

CHANGELOG.md

Houd een changelog bij die per versie beschrijft:

• Added: Nieuwe features
• Changed: Wijzigingen in bestaande functionaliteit
• Deprecated: Features die binnenkort verdwijnen
• Removed: Verwijderde features
• Fixed: Bug fixes
• Security: Security fixes

Release cyclus

Bepaal een ritme:

• Time-based: Elke 3 maanden een release
• Feature-based: Release als belangrijke feature klaar is
• Hybride: Vaste cyclus + ad-hoc voor urgent

Aanbeveling: Start met releases op basis van features. Als samenwerking mature wordt, ga naar vast ritme.

6. Issue tracking en projectbeheer

Hoe houd je bij wat er gedaan moet worden? Issues en projectborden helpen om overzicht te houden.

Issues

Gebruik issues voor:

• Bug reports
• Feature requests
• Documentatie-verbeteringen
• Vragen van gebruikers

Labels gebruiken:

• Type: bug, feature, documentation, question
• Prioriteit: critical, high, medium, low
• Status: ready, in progress, blocked
• good first issue: Voor nieuwe contributors

Issue templates

Maak templates voor verschillende soorten issues. Zorgt dat je altijd de juiste informatie krijgt.

Bug report template:

• Wat verwachtte je?
• Wat gebeurde er?
• Stappen om te reproduceren
• Versie / omgeving

Projectborden

GitHub Projects of GitLab Boards voor overzicht:

• Backlog: Nog te doen
• To Do: Gepland
• In Progress: Wordt aan gewerkt
• Review: Wacht op review
• Done: Afgerond

Praktische tips

Begin simpel, bouw uit

Je hoeft niet alles vanaf dag 1 perfect te hebben. Start met: repository, README, LICENSE, en een simpele branch strategie. De rest groeit organisch.

Documentatie is geen one-time job

Documentatie raakt verouderd. Maak het onderdeel van je workflow: nieuwe feature → update documentatie.

Automatiseer wat je kunt

Zet CI/CD in voor testing, linting, en deployment. Dat scheelt handmatig werk en voorkomt fouten.

Investeer in onboarding

Maak het makkelijk voor nieuwe gemeenten of developers om te beginnen. Goede README + installatie-instructies betalen zich terug.

Leer van anderen

Kijk hoe andere succesvolle open source gemeenteprojecten het doen. Kopieer wat werkt.

Tip: Technische infrastructuur is geen doel op zich. Het moet samenwerken makkelijker maken. Als iets te complex wordt, vereenvoudig het.

Afsluiting

Gefeliciteerd!

Je hebt alle 10 stappen van deze kompas doorlopen. Je bent nu uitgerust met de kennis en tools om succesvol intergemeentelijke open source samenwerking op te zetten.

De 10 stappen samengevat

Deel 1: Fundament leggen

Stap 1: Bepaal je ambitie en samenwerking

• Kies je ambitieniveau (gebruiker, bijdrager, initiator)
• Selecteer de juiste samenwerkingspartners
• Creëer draagvlak bij stakeholders

Stap 2: Kies een governance structuur

• Bepaal besluitvormingsproces
• Verdeel rollen en verantwoordelijkheden
• Organiseer overlegstructuur

Deel 2: Governance & Financiën

Stap 3: Bepaal je financieringsmodel

• Kies passend financieringsmodel
• Maak realistische meerjarenbegroting
• Regel financiële governance

Stap 4: Formaliseer samenwerking

• Selecteer juridische vorm
• Stel samenwerkingsovereenkomst op
• Leg rechten en plichten vast

Deel 3: Community

Stap 5: Bouw een community

• Start met heldere visie en missie
• Zet communicatiekanalen op
• Faciliteer onboarding nieuwe leden
• Organiseer regelmatige events

Stap 6: Beheer de community

• Wijs community manager aan
• Faciliteer contributor journey
• Handhaaf gedragscode
• Meet community health

Deel 4: Juridisch

Stap 7: Bepaal eigenaarschap en IP

• Kies eigenaarschapsmodel
• Regel IP-overdracht in contracten
• Implementeer contributor agreements
• Bescherm handelsmerk

Stap 8: Kies een licentie

• Selecteer open source licentie (waarschijnlijk EUPL-1.2)
• Implementeer LICENSE bestand
• Check licentiecompatibiliteit
• Monitor dependencies

Deel 5: Technisch

Stap 9: Zet infrastructuur op

• Kies code hosting platform
• Implementeer CI/CD
• Configureer quality tools
• Setup documentation

Stap 10: Organiseer onderhoud

• Bepaal onderhoudsmodel
• Alloceer resources en budget
• Implementeer issue management
• Plan releases en updates

Belangrijkste lessen

1. Start klein, groei geleidelijk

Begin niet te ambitieus. Start met een klein samenwerkingsverband en bouw stap voor stap uit. Een succesvol klein project is beter dan een mislukt groot project.

2. Investeer in community

Open source draait om mensen, niet alleen om code. Investeer tijd en geld in community building en management. Een actieve, betrokken community is de basis voor succes.

3. Wees transparant

Transparantie bouwt vertrouwen. Deel je plannen, beslissingen, uitdagingen en successen openlijk met je community en stakeholders.

4. Plan voor lange termijn

Open source is een marathon, geen sprint. Zorg voor duurzaam onderhoud, financiering en governance. Denk in jaren, niet in maanden.

5. Leer van anderen

Je hoeft het wiel niet opnieuw uit te vinden. Kijk naar succesvolle voorbeelden, gebruik bestaande sjablonen en vraag advies aan ervaren open source practitioners.

Veelgemaakte fouten

Let op deze valkuilen:

❌ Onderschatten complexiteit: Open source is niet “gratis”. Het kost tijd, geld en inspanning.

❌ Geen duidelijke doelen: Zonder heldere doelstellingen is het moeilijk om succes te meten.

❌ Onvoldoende commitment: Halfslachtige inzet leidt tot halfslachtige resultaten.

❌ Verkeerde verwachtingen: Verwacht niet direct massale adoptie. Community groeit geleidelijk.

❌ Negeren van onderhoud: Zonder onderhoud sterft je project. Plan en budget ervoor.

Succesfactoren

Dit maakt open source samenwerking succesvol:

✅ Duidelijke visie en missie: Iedereen weet waarom en waarvoor

✅ Sterke governance: Heldere processen en besluitvorming

✅ Actieve community management: Dedicated aandacht voor community

✅ Kwalitatieve code en documentatie: Professionele uitstraling

✅ Duurzame financiering: Meerjarige commitment

✅ Goede communicatie: Regelmatige updates en transparantie

Hulp en ondersteuning

Je hoeft het niet alleen te doen. Deze organisaties kunnen helpen:

VNG (Vereniging Nederlandse Gemeenten)

• E-mail: flori@rebelalliance.nl
• Ondersteuning: Gemeentelijke samenwerking, governance
• Resources: Sjablonen, best practices

Foundation for Public Code

• Website: https://publiccode.net
• Ondersteuning: Internationale best practices, codebase stewardship
• Resources: Standard for Public Code

Open State Foundation

• Website: https://openstate.eu
• Ondersteuning: Open source bij overheid, transparantie

Common Ground community

• Website: https://commonground.nl
• Ondersteuning: Gemeentelijke digitalisering, open source

Pleio - Open Overheid

• Platform: https://openoverheid.pleio.nl
• Community: Netwerk van ambtenaren met open source ervaring

Resources

Sjablonen en hulpmiddelen

Governance en juridisch:

• VNG modelovereenkomsten
• OS2 governance templates (Engels/Deens)
• Foundation for Public Code governance guides

Technisch:

• GitHub/GitLab templates
• Standard for Public Code checklist
• CONTRIBUTING.md templates

Financieel:

• TCO calculators voor open source
• Budgetsjablonen

Inspirerende voorbeelden

Nederlands:

• OpenZaak: Zaakgericht werken platform
• Signalen: Meldingen management systeem
• NLX: Interoperabiliteit infrastructuur
• Haal Centraal: API’s voor basisregistraties

Internationaal:

• OS2 (Denemarken): 50+ gemeenten, 20+ producten
• decidim (Spanje/Barcelona): Participatie platform
• OpenCRVS (Global): Civil registration systeem
• X-Road (Estland): Data exchange layer

Leesmateriaal

Boeken:

• “Working in Public” - Nadia Eghbal
• “The Open Organization” - Jim Whitehurst
• “Producing Open Source Software” - Karl Fogel (gratis online)

Artikelen en blogs:

• Opensource.com - Government section
• GOV.UK blog - Open source artikelen
• VNG website - Digitalisering en innovatie

Events en netwerken

Nederland:

• Common Ground Event (jaarlijks)
• OSS Conferenties
• VNG bijeenkomsten

Internationaal:

• FOSDEM (Brussel)
• Open Source Summit Europe
• All Things Open

Call to action

Deel je ervaring

Heb je deze kompas gebruikt? Deel je ervaringen!

• Wat werkte goed?
• Wat was lastig?
• Wat ontbreekt?

Stuur je feedback naar: flori@rebelalliance.nl

Draag bij

Deze kompas is open source en leeft. Bijdragen zijn welkom:

• Verbeteringen voorstellen
• Voorbeelden toevoegen
• Vertalingen maken
• Nieuwe inzichten delen

Inspireer anderen

Help andere gemeenten op weg:

• Deel je succesverhalen
• Presenteer op bijeenkomsten
• Blog over je ervaring
• Mentor andere gemeenten

Tot slot

Intergemeentelijke open source samenwerking biedt enorme kansen voor de publieke sector:

• Betere software door samen te werken
• Lagere kosten door te delen
• Meer transparantie door openheid
• Grotere innovatie door community

Het vraagt investering, doorzettingsvermogen en samenwerking. Maar de resultaten zijn de moeite waard.

Succes met je open source avontuur!

Over dit kompas

Versie: 0.3.0 Datum: 29 januari 2026 Auteur: Rebel Alliance Licentie: Dit kompas is gebaseerd op VNG Realisatie “Handreiking intergemeentelijk samenwerken rondom open source” v0.2.2 (CC BY-SA 4.0). Deze afgeleide versie is gemaakt door Rebel Alliance en gepubliceerd onder dezelfde CC BY-SA 4.0 licentie.

Contact:

• E-mail: flori@rebelalliance.nl

Bijdragen: Dit kompas is gebaseerd op de oorspronkelijke handreiking van VNG Realisatie v0.2.2, tot stand gekomen met input van vele gemeenten, leveranciers en experts uit het veld. Dank aan iedereen die heeft bijgedragen!

“De beste manier om de toekomst te voorspellen, is om het te bouwen.” - Alan Kay

“Alone we can do so little; together we can do so much.” - Helen Keller