Open source aanbesteden: de vragen verschuiven van ‘waarom’ naar ‘hoe’

Zo’n 25 ambtenaren van verschillende overheidsorganisaties uit het hele land kwamen 13 juli bijeen in de Plint om ervaringen uit te wisselen en vragen te stellen over het inkopen van open source software. Vier juridisch experts op het snijvlak van open source en aanbesteding – Walter van Holst en Robin Verhoef (Hooghiemstra & Partners) en Maurits Westerik en Lot Wagemakers (Coupry advocaten) – zaten klaar om alle vragen uit de zaal te beantwoorden.

De diversiteit aan vragen en het daaropvolgende gesprek maakten ook deze editie waardevol voor de deelnemers. De vragen kwamen vanuit verschillende perspectieven: van inkoop en juridische kaders tot techniek, beheer en samenwerking met leveranciers.

Verdienmodel

Een van de onderwerpen die werd besproken, was het verdienmodel van leveranciers. Open source wordt nog regelmatig gekoppeld aan software zonder licentiekosten, terwijl de economische waarde in de praktijk vaak op een andere plek zit.

Bij veel open source-oplossingen ligt de focus op de dienstverlening rondom de software: implementatie, beheer, ondersteuning en doorontwikkeling. Op het gebied van dienstverlening zijn er veel overeenkomsten met het aanbesteden van dienstverlening voor gesloten software. De software zelf vormt daarbij de basis waarop leveranciers een dienstverleningsmodel kunnen bouwen.

Voor opdrachtgevers betekent dit dat zij bij een aanbesteding goed moeten kijken naar de manier waarop leveranciers waarde toevoegen en hoe zij continuïteit organiseren. Bij open source is het daarom een pré wanneer een leverancier een goede relatie heeft met de achterliggende communities of ervaring heeft met actieve participatie daarin. De kwaliteit en continuïteit van open source-projecten worden vaak versterkt wanneer gebruikers, ontwikkelaars en leveranciers actief bijdragen aan de verdere ontwikkeling ervan.

Rol leveranciers

Uit de sessie kwam naar voren dat leveranciers ook binnen open source een belangrijke rol houden. Die rol krijgt wel een ander accent. De relatie tussen opdrachtgever en leverancier blijft belangrijk, maar de afspraken gaan vaker over dienstverlening, samenwerking en kennisopbouw. Het open karakter van open source geeft opdrachtgevers meer ruimte om naast functionaliteit ook te kijken naar samenwerking, expertise en de manier waarop leveranciers bijdragen aan de verdere ontwikkeling van de oplossing. Dat vraagt om een andere balans in de manier waarop eisen worden opgesteld.

Een van de aanwezigen haalde een voorbeeld uit Frankrijk aan. Bij een aanbesteding voor ondersteuning van een groot aantal kantoorwerkplekken werd gevraagd naar de capaciteit om een omvangrijke omgeving te ondersteunen. Leveranciers die aangaven niet direct het volledige volume te kunnen bedienen, werden niet automatisch uitgesloten. De aanbestedende organisatie onderzocht waar deze beperking vandaan kwam en welke mogelijkheden er waren om de opdracht toch uit te voeren, bijvoorbeeld via samenwerking tussen leveranciers of een andere verdeling van de werkzaamheden.

Het voorbeeld laat zien dat een aanbesteding ook ruimte kan bieden om de mogelijkheden van de markt beter te begrijpen en oplossingen te vinden die vooraf niet volledig waren uitgeschreven.

Overstappen

Een andere vraag ging over het vervangen van bestaande closed source-software door open source. Een overstap is zelden alleen een technische migratie. Het raakt processen, data, integraties en de manier waarop een organisatie haar IT-landschap heeft ingericht.

Tijdens de sessie werd benadrukt dat organisaties hier al bij de start van een traject rekening mee kunnen houden. Een modulaire architectuur en het gebruik van open standaarden maken het eenvoudiger om onderdelen van een landschap later te vervangen. Ook de manier waarop data wordt opgeslagen en uitgewisseld heeft invloed op de mogelijkheden om over te stappen.

Juist bij natuurlijke vervangmomenten van bestaande software kunnen organisaties investeren in een meer modulaire architectuur. Daarmee ontstaat ruimte om onderdelen van het landschap later te vervangen door andere open source- of closed source-componenten. Een tip die werd gegeven, is om de exit onderdeel te maken van de opdracht. Organisaties kunnen vooraf nadenken over de kosten en inspanningen die nodig zijn wanneer een oplossing in de toekomst wordt vervangen. Dat is vooral relevant wanneer leveranciers gegevens in een gesloten formaat opslaan. Ook kunnen zij afspraken maken over overdraagbaarheid en toegang tot informatie die nodig is om een oplossing door een andere partij te laten beheren.

Kwaliteit en vitaliteit

Meerdere ICT-inkopers en contractmanagers hadden vragen over de continuïteit van open source-projecten. Hoe weet je of een oplossing toekomstbestendig is? Welke rol speelt de omvang van een community? En hoe voorkom je dat een organisatie afhankelijk wordt van een klein aantal ontwikkelaars, maar nu vanuit de open source hoek?

Daarbij kwam naar voren dat de kwaliteit en vitaliteit van een community relevante factoren zijn bij de keuze voor een oplossing. Niet alleen de beschikbaarheid van broncode is van belang, maar ook de manier waarop een project wordt bestuurd, hoe bijdragen worden verwerkt en hoe actief de community is in de doorontwikkeling.

Ook werd gesproken over de vraag hoe organisaties ervoor kunnen zorgen dat maatwerk terugvloeit naar de achterliggende community. In de praktijk kan een opdrachtgever niet afdwingen dat een community een bijdrage accepteert. Wel kunnen afspraken worden gemaakt over de inspanning van leveranciers om verbeteringen terug te brengen naar het oorspronkelijke project. Dat helpt om te voorkomen dat organisaties langdurig eigen varianten van software moeten onderhouden.

Wanneer een organisatie toch besluit een eigen fork te maken, is het belangrijk om de relatie met het hoofdproject zo goed mogelijk te behouden. Hoe dichter een eigen ontwikkeling bij het hoofdproject blijft, hoe eenvoudiger het doorgaans is om verbeteringen te blijven synchroniseren.

Vertrouwen

Ook vragen over wet- en regelgeving kwamen aan bod. Deelnemers vroegen onder meer hoe open source zich verhoudt tot de Cyberbeveiligingswet en de Cyber Resilience Act (CRA). Kan je wel vertrouwen op open source als het gaat om cruciale gemeentelijke infrastructuur, zoals de bediening van bruggen of sluizen? Ook kwamen er vragen over de nieuwe GIBIT-2025 waarin een open source-publicatie bij maatwerkoplevering nu de standaard is.

De juristen waren eenduidig. Juist voor dit soort cruciale systemen wil je volledig inzicht kunnen hebben in de werking van de broncode. Ook commerciële partijen uit deze sectoren leunen om die reden juist op open source.

Verantwoordelijkheid

Verder kwam uit de beantwoording naar voren dat open source geen aparte route vormt buiten bestaande verantwoordelijkheden. Organisaties moeten zelf blijven nadenken over risico’s, beveiliging, continuïteit en de inrichting van hun leveranciersrelaties en kunnen deze verantwoordelijkheid niet zomaar bij de leverancier leggen. Wel kan een aanbestedende dienst informatie van leveranciers nodig hebben om de beheersing van risico’s beter inzichtelijk te krijgen.

Ook bij aanbestedingen vraagt de keuze voor open source om een goede onderbouwing. Open source is immers een middel en geen doel. Het is dus belangrijk om te benoemen aan welke doelen open source moet bijdragen. Denk aan transparantie, hergebruik van software, mogelijkheden voor controle en het beperken van ongewenste afhankelijkheden. Vervolgens leg je uit dat open source het meest passende middel is om die doelen te realiseren en onder welke open source voorwaarden.

Zo is de VNG een prachtig voorbeeld van hoe je de keuze voor open source kunt toelichten. Zij hebben dit als volgt gedaan bij de GIBIT-2025: 'Door maatwerkprogrammatuur te laten ontwikkelen en deze vervolgens als open source-programmatuur te laten publiceren, wordt het voor andere gemeenten mogelijk om ook gebruik te maken van deze programmatuur, en wordt het goedkoper om vervolgens verder te bouwen op deze programmatuur. […] Het bevordert transparantie, stimuleert samenwerking tussen organisaties en maakt hergebruik mogelijk, wat leidt tot efficiëntere en duurzamere oplossingen.'

Een terugkerend onderwerp in verschillende vragen was de rol van de opdrachtgever zelf. Open source vraagt om kennis van de eigen organisatie, het IT-landschap en de manier waarop software wordt ontwikkeld en beheerd.

Dat betekent bijvoorbeeld dat opdrachtgevers moeten weten welke ruimte zij willen geven aan bestaande oplossingen en communities. Niet iedere behoefte hoeft opnieuw vanaf nul ontwikkeld te worden. In sommige gevallen ligt de meerwaarde juist in het aansluiten bij wat al beschikbaar is en het bijdragen aan verdere ontwikkeling.

Maatwerk

Ook bij maatwerk speelt dit een rol. Hoe specifieker een organisatie een oplossing laat ontwikkelen, hoe groter de kans dat deze afwijkt van bestaande open source-software en daarmee meer beheersinspanningen vraagt. Je kunt in dat geval minder gebruik maken van bestaande ontwikkelingen, kennis en onderhoud die binnen een open source-ecosysteem beschikbaar zijn.

Ervaringen delen

In de afgelopen twee jaar zijn er zeven kennissessies gehouden over dit thema, met tastbare resultaten. Overheden ontdekken dat zij niet alleen staan in hun open source-opgaven, dat er veel meer organisaties zijn die al volop inzetten op open source en vooral dat er veel meer mogelijk is.

Zo is ook het zaadje voor open source in de GIBIT-2025 in zijn huidige vorm geplant bij deze kennissessies. Deze toevoeging leidt op haar beurt weer tot nieuwe vragen, die in deze laatste sessie beantwoord konden worden.

Het laat zien dat de praktijkvragen die bij inkopers leven rondom open source steeds concreter worden en ook tot concrete resultaten leiden. Het laat ook zien dat open kennisdeling tussen overheden volgens het open source-principe cruciaal is om de grote transformatie naar een open ecosysteem met open source en open standaarden mogelijk te maken.