duration: 45 min
- Leuk dat ik hier mag vertellen over DON - Grapje dat ik hier aan de overkant van het kanaal woon - Vertellen over alle inzichten van DON afgelopen jaren - Mooie tools die hieruit voort zijn gekomen De afgelopen jaren ben ik standaarden gaan zien als een manier van samenwerken, van afspraken die je maakt als je bijvoorbeeld een API bouwt of een front-end. Ik zie het als een manier voor onze overheid om eindelijk wat meer eenduidig te developen, maar ook als een manier om instructies mee te geven aan LLM's zodat coding agents niet uit de bocht vliegen. In die zin worden standaarden steeds belangrijker.
Kort eerst iets over mijzelf. Ik ben Tom, werk al sinds 2023 aan developer.overheid.nl. Als freelancer veel verschillende overheidsprojecten gedaan. Vind het mooi om daaraan te werken omdat we met developer.overheid.nl een gemeenschappelijk platform hebben om developers op eenduidige manier software te laten bouwen. Mijn rol is developer advocate wat betekent dat ik me verdiep in wat developers nodig hebben om bijvoorbeeld compliant te kunnen worden aan een standaard.
Even wat we gaan doen: eerst kort wat developer.overheid.nl is, en hoe ik er terechtkwam via mijn werk bij VWS tijdens corona. Daarna het overheidslandschap en waarom standaardiseren daar zo lastig is. Dan ons antwoord: tooling die zo goed is dat je vanzelf compliant wordt, langs drie pijlers. En je ziet straks ook hoe standaarden instructies worden voor je coding agent.
Eerst kort wat developer.overheid.nl is, want daar kom ik vandaan. Het is een developerportaal voor de hele overheid. Denk aan de developer-docs die je kent van grote platforms, alleen dan voor honderden organisaties tegelijk. - Een API-register: welke API's zijn er bij de overheid, met documentatie, en we checken of ze voldoen aan de API Design Rules. - Een open source-register op basis van publiccode.yml: welke software is er al, wie gebruikt het, zodat je niet opnieuw het wiel uitvindt. - Een kennisbank over API's, open source en front-end. En we zijn zelf ook open source: alles staat op GitHub, en iedereen mag meedoen. We leggen niets op. We proberen het makkelijk te maken. Daar gaat deze talk over.
Voordat ik bij developer.overheid.nl begon, werkte ik als freelancer bij VWS. Midden in de coronacrisis: software voor het bron- en contactonderzoek, vragenlijsten en formulieren, en het informeren van burgers met statistieken.
Nou waar we toen mee te maken hadden waren veel beleidswijzigingen. Het kon zijn dat als we maandagochtend onze werkdag begonnen dat er dan allerlei parameters zoals bijvoorbeeld de quarantaineperiode gewijzigd moesten worden. Wij moesten dat dan zo snel mogelijk doorvoeren, dit had trouwens allerlei effecten op hoe de front-end werkte, dus dat moest getest worden, en dan moest het naar productie. Nog een ding, voor het VWS was het dus iets nieuws om zelf software te bouwen. Dus de organisatie moest er heel erg aan wennen. Ja, het voelde als developer dus gek om in die context ook te bouwen, omdat er niks vastgelegd was.
Nou nadat mijn project bij min-vws afliep was ik dus heel erg bezig met deze vraag. Dat was het moment waarop ik tegen developer.overheid.nl aanliep. Destijds was het nog een stuk minder volledig dan het nu is, alleen het concept van een gedeeld developer portaal sprak me heel erg aan.
Tijdens mijn werk kwam ik erachter dat overheidsorganisaties eerder functioneren als aparte eilandjes dan als een ecosysteem. Elke organisatie waarmee ik praatte had een andere tech-stack.
Echter! Veel taken die organisaties hebben zijn hetzelfde. Neem bijvoorbeeld de Woo: dat geldt voor ministeries, gemeentes, provincies, waterschappen en ZBO's (UWV, DUO, RDW). Dus zou het logisch zijn om de software die je bouwt voor deze taken te delen met elkaar, en er samen aan te ontwikkelen. ZOU JE DENKEN!
Insert image of overheids-islands?
Er ís wel een manier waarop de overheid standaarden afdwingt: de "pas toe of leg uit"-lijst van het Forum Standaardisatie. Een lijst van zo'n 40 open standaarden. Koop je als overheidsorganisatie ICT in boven de 50.000 euro, dan moet je die standaarden toepassen. Doe je dat niet, dan moet je uitleggen waarom, in je jaarverslag. Op de lijst staan dingen die jullie kennen: HTTPS en HSTS, DNSSEC, WCAG voor toegankelijkheid, OpenAPI, en de REST API Design Rules, waar ik het straks uitgebreid over ga hebben. Maar: een lijst maakt nog niet dat het ook gebeurt.
Onze overheid heeft haar macht heel goed verdeeld. De ene uitvoerende organisatie heeft in feite weinig te zeggen over de andere. Dit is heel nuttig want het zorgt voor stabiliteit, alleen kan je dus geen technische werkwijze afdwingen!
- Dit is de strategie die we sindsdien gevolgd hebben - We kunnen niemand echt iets opleggen - Daarom tooling bouwen die nuttig is voor developers - Een bepaalde use-case goed ondersteunen - Dit is ook echt de kern van de filosofie van developer.overheid.nl
Dit is de bron van de Open Source Catalogus die je net zag. Het bestand werkt als een vlag: "dit is overheidssoftware, en je mag het hergebruiken". Het is machineleesbaar, dus catalogi kunnen het automatisch oppikken.
Naam, URL, status, licentie, onderhoud: dat is eigenlijk alles. De longDescription is ingekort voor de slide. Nieuw sinds 0.5: `organisation` (wie publiceert de software, met een URI). Nieuw in 0.7: `supports`, welke standaarden/regelgeving de software ondersteunt (hier de API Design Rules). Vervangt de landspecifieke secties.
Dezelfde checker draait ook gewoon in je terminal, zonder installatie: npx en gaan. Je geeft aan tegen welke standaard je wil checken, hier de API Design Rules, en je OAS-bestand of een URL. Je krijgt per overtreding de regel, waar in je spec het zit, en een link naar de kennisbank met uitleg hoe je eraan voldoet. En belangrijk: bij errors is de exit code 1. Dus je hangt hem zo in je pipeline en je merge request wordt rood. Met --fail-on kun je zelf kiezen of warnings ook al falen.
En dan de volgende stap: dezelfde regels, maar dan vóórdat je code schrijft. In onze skills-marketplace zit een plugin met skills voor de Logius-standaarden, waaronder de API Design Rules. Vraag je coding agent om een API te ontwerpen, en de skill laadt vanzelf. De agent kent dan de regels: major versie in de URI, kebab-case paden, de API-Version header. En hij hergebruikt de standaardcomponenten via een $ref, in plaats van ze zelf te verzinnen. Daarna draait hij de don-checker zelf, dus hij controleert zijn eigen werk. Precies de drie fouten van de vorige slide, maar nu voorkomen in plaats van gevonden. Standaarden als instructies voor je LLM: zo vliegt je agent niet uit de bocht.
## Een les die we leerden Van PROD naar OpenAPI Specification <!-- Ooit onderhielden we een API validator. Een complexe tool die live naar de endpoints van een API ging kijken of deze wel compliant was.
En dan pijler 3: gedeelde services. Het mooiste voorbeeld: code.overheid.nl, sinds april 2026 live als soft launch. Een eigen forge voor de hele overheid, gebouwd op Forgejo: de community-fork van Gitea, GPLv3+, beheerd door de non-profit Codeberg e.V. Geen enterprise-tier, geen upsell, geen vendor lock-in. Het draait op eigen overheidsinfrastructuur bij SSC-ICT en is gratis voor elke overheidsorganisatie. Een initiatief van het OSPO van BZK, samen met SSC-ICT, Opensourcewerken en developer.overheid.nl. Voor jou als developer voelt het gewoon als GitHub: git push, pull requests, issues, code review. De Kiesraad zet er al code op, zoals Abacus. Toegang is nog beperkt: aanmelden via codeplatform@rijksoverheid.nl.
Voor de BioShock-fans onder ons: dit is geen verzoek. … Nee hoor, grapje. Wij kunnen niks afdwingen, en daarom bouwen we tooling die je wílt gebruiken.
Scan de QR-code om je in te schrijven voor de developer.overheid.nl meetup: https://opensourcewerken.nl/events/view/8dfe1365-3742-4832-8359-f2efed31126a/developeroverheidnl-meetup-samenbeterbouwen