Beheer en doorontwikkeling nuts-node

Status: loopt Waar: #development en #releases

Wat het is

De nuts-node is het kernproduct van de community en draait in productie bij deelnemers. Beheer en doorontwikkeling staan als doorlopend werk in het jaarplan. Binnen dit werk is één rol formeel belegd: het producteigenaarschap, op 13 oktober 2025 met consent bij Rein Krul, als opvolger van Tomas Harreveld en daarvoor Wout Slakhorst. Bij dat besluit is de rol omschreven als aanspreekpunt en verantwoordelijk voor het product in de brede context: techniek, ontwikkeling en support. Wat de rol precies omvat is daarna niet uitgewerkt.

Deze pagina is een reconstructie van de bestaande praktijk, samengesteld uit de GitHub-repositories en de Slack-kanalen. Het is een beschrijving van wat er gebeurt, geen voorstel tot verandering.

Opdracht

Doel. Een nuts-node die veilig, actueel en bruikbaar is voor de partijen die hem in productie draaien, met een voorspelbaar release- en ondersteuningsbeleid.

Scope. De opdracht omvat:

• Backlog en prioritering op basis van lopende projecten, de behoefte van de kring Toepassingen en projecten van de kring zelf
• Releases en versiebeheer, waaronder release candidates wanneer een externe partij een versie moet kunnen vastpinnen, bijvoorbeeld voor een pentest
• Security, waaronder het patchen van CVE's en het beheer van kwetsbaarheden in de images
• Deprecation en migratie, waaronder het uitfaseren van did:nuts en het gRPC-netwerk, en de migratiedocumentatie van v5 naar v6
• Ondersteuning aan node-beheerders en implementaties in het veld, van configuratie- en certificaatvragen tot performanceonderzoek
• Technische documentatie van de node
• Functionele voorstellen met consultatie in de community voordat ze op de backlog komen
• Communicatie richting node-beheerders over releases, kwetsbaarheden en het ondersteuningsbeleid

Buiten scope vallen: het beheer van individuele nodes bij deelnemers, de toepassingen die op de node draaien, en het beheer van de samenwerkingsmiddelen zelf zoals de GitHub-organisatie en de toegangsrechten daarop.

Resultaat. Doorlopend werk zonder einddatum. De kring stuurt via prioritering en kaders, niet via besluiten per issue.

Belegging. Producteigenaar: Rein Krul. Ontwikkeling: Rein Krul en Steven van der Vegt. Externe bijdragen via pull requests staan open voor iedereen. De producteigenaar prioriteert binnen deze opdracht en is aanspreekpunt voor het product; het aanwijzen van mensen en het beleggen van uren is aan de kring.

Werk met een financieel gevolg dat niet in de begroting is voorzien, zoals een security scan of een groter stuk ontwikkelwerk, wordt afgestemd met de producteigenaar. Gaat het om werk van substantiële omvang, dan meldt degene die het oppakt dat in de kring. De inschatting daarvan ligt bij de betrokkene zelf; het gaat om navolgbaarheid achteraf, niet om toestemming vooraf.

Werkwijze. Vragen en meldingen komen binnen via #development en via GitHub-issues. Releases en kwetsbaarheden worden aangekondigd in #releases; node-beheerders wordt gevraagd zich daarop te abonneren. Bij functionele wijzigingen die gebruikers raken wordt eerst een voorstel in de community gelegd voordat het op de backlog komt.

De producteigenaar kan taken uit deze opdracht vrij delegeren, bijvoorbeeld tijdens vakantie of bij piekbelasting. De verantwoordelijkheid voor de rol blijft daarbij bij de producteigenaar; delegatie van de rol zelf is een besluit van de kring.

Vastgelegd beleid

Beleid dat in de praktijk geldt en dat hier expliciet wordt gemaakt:

• Ondersteunde versies. CVE's worden gepatcht op de laatste minor van de twee ondersteunde major-versies. Wie op een lagere minor zit, moet upgraden om security- en bugfixes te ontvangen. Minor-upgrades zijn niet-breaking.
• Major-versies worden bepaald door breaking changes op de API en op de deployment. Een major kan dus ook een enkele noodzakelijke configuratiewijziging zijn.
• Aankondiging. Releases en kwetsbaarheden worden aangekondigd in het releases-kanaal. Node-beheerders zijn zelf verantwoordelijk voor het volgen daarvan.

Te besluiten

1. Bevestigt de kring de opdracht zoals hierboven beschreven, als beschrijving van de bestaande praktijk?
2. Welke repositories en ondersteunende software vallen onder deze opdracht, en welke zijn deprecated of niet ondersteund? Voorstel is die lijst als bijlage vast te stellen, zodat voor deelnemers duidelijk is waar zij op kunnen bouwen.
3. Waar landen inhoudelijk-beleidsmatige besluiten over de node? Het jaarplan constateert dat besluiten over de node vaak grote impact hebben op de kring Toepassingen, maar nergens expliciet als corrigeerbaar beleidsbesluit worden genomen. Het technisch convergentieoverleg in oprichting kan hierin een rol spelen: het brengt de toepassingsverantwoordelijken en de kring bij elkaar en kan besluiten die om een kaderkeuze vragen voorbereiden voor de kring.
4. Bevestigt de kring het beleid hierboven, zodat deelnemers zich erop kunnen verlaten?
5. Bevestigt de kring de ontwikkelaars zoals hierboven genoemd, en hoe worden nieuwe mensen toegevoegd? Op dit moment volgt dat uit de schrijfrechten op de repositories en niet uit een besluit. Dit hangt samen met de open punten uit het jaarplan over de gedeelde ontwikkelinzet en over de vraag of de uitvoerende ontwikkeling in een subkring hoort.

Samenhang met andere trajecten

• v6-migratie. Het uitfaseren van did:nuts en het gRPC-netwerk raakt het beheer van de node rechtstreeks; de migratiedocumentatie komt uit deze opdracht voort.
• PKIOverheid G4-transitie. De analyse en de eventuele aanpassingen lopen via het producteigenaarschap.
• Technisch convergentieoverleg in oprichting. Beoogde plek om node-besluiten met impact op toepassingen voor te bereiden.
• COT en het knooppunt. De node en het knooppunt worden deels door dezelfde mensen ontwikkeld; de afbakening tussen beide is niet vastgelegd.
• Community-tooling. Het beheer van de GitHub-organisatie, de toegangsrechten en de kanalen valt onder dat werkpakket en niet onder deze opdracht.
• Vernieuwing van de technische documentatie. De node-documentatie valt binnen deze opdracht en binnen het procesvoorstel van het COT.

Bronnen

Wie erbij betrokken zijn

Hoe haak je aan

Vragen over het draaien van een node en meldingen van problemen gaan naar #development. Draai je een node in productie, abonneer je dan op #releases en zorg dat de meldingen daadwerkelijk bij je binnenkomen.