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.