Opensource is nu standaard voor maatwerksoftware Nederlandse gemeenten

Als Nederlandse gemeenten voortaan maatwerksoftware inkopen, zou dat standaard opensource moeten zijn, tenzij er een goede reden is om daarvan af te wijken. Dat blijkt uit de nieuwe leidraad van de Vereniging Nederlandse Gemeenten.

Maatwerksoftware is 'opensource, tenzij', vermeldt de toelichting op de richtlijnen Gibit 2025. Ook Common Ground, het initiatief van gemeenten om gezamenlijk software te laten maken, maakt in principe alleen gebruik van open source-software. Dat is nieuw ten opzichte van de vorige richtlijnen.

De broncode moet staan op een gitplatform zoals GitHub of GitLab en de vereiste licentie is de European Union Public License, zo staat in de toelichting. Ook dat is een wijziging, want daarbij komt het eigendom niet langer te liggen bij de leverancier. De richtlijnen zijn niet verplicht om te volgen, maar vormen wel een leidraad voor gemeenten bij de inkoop van software en afwijken kan in principe alleen met een goede motivatie.

Reacties (35)

[Triblade_8472]

Dit is toch niet nieuw..?

Bron uit 2024:

https://www.digitaleoverheid.nl/overzicht-van-alle-onderwerpen/open-source/beleid/

De overheid volgt het beleid ‘Open, tenzij’: software van de overheid moet zoveel mogelijk open source zijn, behalve als er goede redenen zijn om de software niet beschikbaar te maken.

[Pyronick]

Dit is toch niet nieuw..?

Bron uit 2024:

https://www.digitaleoverh...erpen/open-source/beleid/
[...]

Klopt, maar dat 'Open, tenzij'-beleid was in de praktijk vooral een richtlijn voor de Rijksoverheid. Gemeenten hebben veel autonomie en konden dat advies tot nu toe vrij makkelijk naast zich neerleggen.

Juist bij die lagere overheden valt nu de grootste winst te behalen, omdat alle 342 gemeenten exact dezelfde landelijke wet- en regelgeving moeten uitvoeren. Als ze vanuit één gemeenschappelijke open source basis gaan werken, voorkom je dat het wiel lokaal 342 keer opnieuw moet worden uitgevonden. Dat scheelt simpelweg een hoop belastinggeld en nutteloos dubbel (driehonderdtweeënveertig dubbel?) werk.

[Reactie gewijzigd door Pyronick op 5 maart 2026 19:20]

[Vaevictis_]

Centric is daar groot mee geworden elke gemeenten eigen maatwerk want ja wij zijn anders dan de buren.

[Stijnvi]

Laat mij beginnen door te zeggen dat ik deze stap enorm toejuich. Ik vraag me alleen af waarom deze eis specifiek wordt gesteld aan maatwerksoftware in plaats van aan reguliere software. Het lijkt me juist een stuk logischer om dit als eis te stellen aan reguliere software. Daar is namelijk bijna altijd een open-source variant van, en dat is ook het grootste deel van de software die er gebruikt wordt. Maatwerksoftware is juist een van de weinige gevallen waarin je zou moeten toestaan dat het niet open-source is.

[Triblade_8472]

Als je iets laat ontwikkelen, kan je vooraf eisen stellen. Het moet immers nog gebouwd worden. Met kopen/licenseren is het product er al.

De tijd komt nog wel dat standaard software naar open source gaat, maar stapje voor stapje.

[Stijnvi]

Als je iets laat ontwikkelen, kan je vooraf eisen stellen. Het moet immers nog gebouwd worden.

Klopt, maar het lijkt me juist dat die ontwikkeling dus vele malen duurder is als het open-source moet zijn, omdat de leverancier afstand doet van het eigendom. En één gemeente kan deze hoge up-front kost waarschijnlijk niet betalen. En dan wordt er dus alsnog gekozen voor closed source.

Toevoeging: open-source is dus een goede eis voor collectieve inkoop, maar wanneer een kleine gemeente maatwerksoftware wil zal het waarschijnlijk heel lastig worden om dit te kunnen betalen als de eigenaar afstand moet doen ervan.

[Reactie gewijzigd door Stijnvi op 5 maart 2026 19:05]

[Llopigat]

Als het maatwerk is dan is het sowieso raar dat de leverancier eigendom houdt vind ik. Je huurt ze in om iets voor je te bouwen.

Als ik een huis laat bouwen dan blijft het ook geen eigendom van de aannemer en kan ik wie ik wil er aan laten werken. Ja, ik weet het, vergelijkingen gaan vaak scheef. Maar toch.

[Reactie gewijzigd door Llopigat op 5 maart 2026 19:10]

[latka]

Ik kan de projectontwikkelaar ook vragen om het te bouwen en aan mij te verhuren. Dan is het niet van mij en zijn de maandelijkse kosten te behapstukken. Nadeel: je betaald uiteindelijk meer (vandaar ook dat een projectontwikkelaar hier wel in mee kan gaan)

[Stijnvi]

Daarnaast gaat het hier niet om een huis wat door één gezin bewoond kan worden, maar software die oneindig vaak verkocht kan worden. De ontwikkelaar kan bij closed-source dus ook hopen de software uiteindelijk aan nog meer gemeenten te verkopen.

[Reactie gewijzigd door Stijnvi op 5 maart 2026 19:52]

[lenwar]

Dat heeft er niets mee te maken. Open Source is niet per definitie vrije software. Als ik software op github zet, en het openbaar maak, en ik zet er geen licentie bij, ben ik nog steeds de copyrighthouder, en mag niemand het gebruiken.

(Of dat in de praktijk een slimme zet is om te doen, is weer een ander verhaal)

[William_H]

Als het maatwerk is, moet er dus sowieso (zeer waarschijnlijk) iets nieuws gemaakt worden. Waarom zou je dat dan juist niet open-source maken. Door het open-source te maken hoeft het wiel niet 10x opnieuw uitgevonden te worden, en kunnen andere gemeenten ook profiteren van deze software. En dan zou dat in theorie ook nog goedkoper kunnen, want de software is er al.

[Sissors]

Maar voor iig de eerste gemeente gaat het heel veel duurder worden als een leverancier het niet aan meerdere partijen kan verkopen meer. Ik vermoed dat ook in de praktijk dat de impact van deze richtlijn beperkt gaat zijn, simpelweg omdat de offerte veel hoger gaat zijn dan bij closed source.

[HansvDr]

Als wij software maken leveren wij de source aan de klant. Waar de klant voor tekent is dat de software alleen voor eigen gebruik is. Dus zomaar bij een andere organisatie inzetten mag niet, ook al hebben ze de code.

En willen ze dat wel dan wordt het contract anders en inderdaad vele malen duurder.

[CrazyBernie]

Drie goede redenen denk ik :

1. Maatwerk is dit makkelijk voor vast te leggen omdat de opdrachtgever betaald.
2. Er gaat waarschijnlijk heel veel geld verloren omdat vrijwel hetzelfde maatwerk op meerdere plaatsen gebouwd wordt. Bij open source kunnen gemeentes makkelijker samenwerken of bestaande investeringen uit nutten.
3. Vendor lockin voorkomen.

Uiteindelijk is dit de op maat naar dit ook voor reguliere software regelen natuurlijk.

[Remzi1993]

Het is gewoon goed dat ze ergens beginnen. Je moet met iets beginnen en zoals andere al aangeven bij maatwerk software kan je eisen makkelijker eisen stellen als opdrachtgever omdat je het laat maken ipv iets afneemt dat als bestaat.

[Ed Vertijsment]

Ik vind dat, ook als medewerker van een organisatie die common ground projecten (dus open source) markt volstrekt logisch.

indien off the shelf beschikbaar is dat bijna altijd goedkoper, je wilt dan niet die keuze uitsluiten omdat het niet open source.

je wilt niet Windows voor desktop uitsluiten omdat het closed is, en nee, Linux is dan niet (altijd) goedkoper.

[R_Zwart]

Open source varianten van commerciële software zijn het vaak net niet. Ik heb bijvoorbeeld nog nooit een open source applicatie gevonden die beter is dan Lightroom of Capture One. Libre Office en Open Office zijn het ook net niet t.o.v. MS Office. Daarnaast kan je nog te maken hebben het gepatenteerde functionaliteit die je mogelijk wel nodig hebt. En zo zijn er nog wel meer zaken te bedenken.

[Hennie-M]

Klinkt als een heel goed idee!
Nu maar hopen dat grote gemeenten met veel geld niet hun eigen fork gaan maken van het Burgerzakensysteem en dat de kleine gemeente maar achter de leverancier/ groep aan moet hobbelen omdat die geen developers kunnen/willen inhuren maar een dienst willen afnemen.

[Macshack]

Echt weer zo'n tegendraadse afspraak. Bij de overheid snapt men echt niks van investeren, zo blijkt. Ja lekker al je code open source maken waar je al die tijd aan gewerkt hebt, of misschien wel op de plank hebt liggen maar nu open source moet worden omdat je een opdracht voor de gemeente wilt doen.

Of, dit trekt partijen aan die nog weinig ervaring hebben en op deze manier toch aan werkervaring kunnen komen. Wat de kwaliteit meestal niet ten goede komt. Of partijen gaan hogere bedragen rekenen. Of de gemeente gaat toch weer voor een internationaal bedrijf want die heeft software dat 70% past bij de behoefte van de gemeente.

Dit collectief denken gaat uitlopen tot collectief berooft worden. En niemand begrijpt waarom het steeds duurder en slechter wordt.

[CAPSLOCK2000]

Echt weer zo'n tegendraadse afspraak.

Hoezo tegendraads? De overheid probeert al jaren die kant op aan het bewegen. Het gaat allemaal niet soepel, maar de intentie is er. Alle beleid op dit gebied is gericht op openheid van broncode, protocollen, bestandsformaten, etc. Dit is gewoon de volgende stap in een lang lopend proces.

Ja lekker al je code open source maken waar je al die tijd aan gewerkt hebt, of misschien wel op de plank hebt liggen maar nu open source moet worden omdat je een opdracht voor de gemeente wilt doen.

Het gaat over maatwerk, dat ligt bijna per definitie niet op de plank.

[HansvDr]

Ook bij maatwerk gebruik je heel veel zaken die je eerder ontwikkeld hebt.

Maar goed, open source betekent niet dat de overheid kan doen met de code wat ze willen, alleen dat ze de code hebben.

[R_Zwart]

Waarom is het een probleem om het open te maken? Het werk wordt betaald en vervolgens kan je ene contract voor support en life cycle management verkopen. Goed voor een continue cash flow.

En als je het niet wilt, biedt je het gewoon niet aan. Als die gesloten software genoeg waarde vertegenwoordigt zijn er wel andere klanten te vinden.

[Reactie gewijzigd door R_Zwart op 5 maart 2026 20:31]

[Hydranet]

Ik ben benieuwd hoe dat straks gaat wanneer wetten zoals die in Colorado en California in Europea ingevoerd gaan worden m.b.t opensource besturing systemen. Als voorbeeld deze.

https://www.pcgamer.com/software/operating-systems/a-new-california-law-says-all-operating-systems-including-linux-need-to-have-some-form-of-age-verification-at-account-setup/

Mag hopen dat dit alleen toegepast kan worden op corporate Linux distributies, want community distributies daar zit geen bedrijf achter maar vrijwilligers over de hele wereld. Zal ook afhangen hoe die wetten van papier naar de werkelijkheid vertaald gaan worden.

[Reactie gewijzigd door Hydranet op 5 maart 2026 19:32]

[Lord Anubis]

titel 'is'

artikel 'zou'

wet 'richtlijnen' als in voorkeur


Lekker geschreven artikel weer.

[Amanoo]

Denk je dat ze die gegevens hardcoden in de software? En met elke nieuwe inwoner in de gemeente dan gelijk een nieuwe versie moeten compileren?

Ze gooien alleen de software op Github. In software staat geen gevoelige data. Daarvoor gebruik je databases enzo. Die kan je lokaal draaien zodat niemand erbij kan, of je kan met keys werken zodat het veilig wordt verstuurd.

[genosis]

Als software developer die met open source software werkt snap ik dat uiteraard. Het gaat me meer om dat straks alle lekken in diezelfde open source software misbruikt kunnen gaan worden. De gemiddelde tijd voor een exploit is tegenwoordig in 2026 1,6 dagen... (zie https://zerodayclock.com/)

[Pyronick]

Dat risico geldt net zo goed voor closed-source software. Vrijwel elk gesloten pakket leunt tegenwoordig zwaar op open-source dependencies (denk aan de log4j-ramp); deze componenten hebben vaak gewoon een Apache-, MIT- of BSD-licentie. Het verschil is dat je bij een gesloten black box blind moet wachten op de leverancier.

Daarnaast dwingen de Cbw en de NIS2-richtlijn gemeenten en hun leveranciers inmiddels tot strakke supply chain security. Een actuele SBOM is hierbij standaard (verplicht), evenals het geautomatiseerd en dagelijks handmatig monitoren op CVE's. Zodra er een kwetsbaarheid opduikt met een snelle exploit-tijd, biedt de wetgeving én een open codebase de gemeente juist de handvatten om direct in te grijpen of de leverancier dwingend de opdracht te geven de specifieke dependency te patchen, in plaats van afhankelijk te zijn van een ondoorzichtige updatecyclus.

Dat gezegd hebbende, de aangewezen functionaris blijft helaas een mens... En ook nog eens 1 ambtenaar...

[zonglew00]

Er is meer dan alleen btw nummers. Betalingskenmerk van bepaalde belastingen zijn ook gekoppeld aan BSN. Waarom? Geen idee , dit hanteren we al voordat meeste tweakers waren geboren. Wat Odido heeft te maken met dit is ver te zoeken. Btw nummers zijn gelekt niet van nummers. Wijs vingertje naar de ministers die op de post van belastingdienst hebben gezeten (VVDers?)

[Llopigat]

Tot 2020 was het BSN nummer verwerkt in het BTW nummer van ZZP'ers. Als iemand dus klant is geweest in die tijd staat dat nummer uit die tijd er nog in. Ook omdat Odido die gegevens veel te lang heeft bewaard tegen hun eigen richtlijnen in.

[Remzi1993]

Inderdaad, maar kleine correctie van de rechtsvorm eenmanszaak. Die kunnen zich noemen wat ze willen, ZZP-er, freelancer of een kleine winkel. Het is inderdaad heel raar dat dat in het verleden het geval was.

[Shinji]

BSN komt voort uit een intern nummer van de belastingdienst om iemand te identificeren, door functioncreep is het geworden tot wat het nu is. Daarom ook dat het lang als BTW nummer gebruikt werd voor ZZPers.

[wooha]

Er is meer dan alleen btw nummers. Betalingskenmerk van bepaalde belastingen zijn ook gekoppeld aan BSN. Waarom? Geen idee , dit hanteren we al voordat meeste tweakers waren geboren.

Dat was me nooit opgevallen. Op zich vind ik dit discutabel, ook al vindt de communicatie van het betalingskenmerk plaats tussen de burger en belastingdienst met banken als tussenpartij die het BSN voor bepaalde doelen al moet verwerken.

Maar bovendien geeft een zoekopdracht me zo al een aantal websites die het betalingskenmerk om kunnen zetten en niet van de overheid lijken of zelfs zeggen te zijn. Dan vraag ik me af of die websites überhaupt wel aan de wetgeving voldoen. Ze noemen soms zelfs expliciet dat het BSN erin voorkomt en weten dat dus.

edit:
sorry voor de off-topic

[Reactie gewijzigd door wooha op 5 maart 2026 19:31]

[NMMNG]

Goed verhaal. Niks meer aan doen.

[Ed Vertijsment]

Open source heeft geen betrekking op de data dus een datalek heeft hier niet veel mee te maken.