Hoe VWS open source aanbesteedt naar een open zorg-ICT-ecosysteem

Het ministerie van VWS biedt een kijkje in de keuken van het aanbestedingsproces van de Persoonlijke Gezondheidsomgeving (PGO) en de doorontwikkeling van het MedMij-stelsel. Hoe geef je handen en voeten aan de opensource-ambitie en hoe zet je open source in als strategisch beleidsinstrument binnen publieke voorzieningen?

Het Ministerie van Volksgezondheid, Welzijn en Sport (VWS) werkt hard aan de ontwikkeling van het gezondheidsinformatiestelsel (GIS). Voor de ontwikkeling van een aantal onderdelen kiest VWS voor opensource-aanbesteding in de markt. De overheid kent een wettelijke inspanningsverplichting om open source te werken. Voor de zorgsector is deze verplichting er niet. Desondanks vindt VWS het belangrijk dat er in het GIS een hoge ambitie van opensourcewerken wordt toegepast. VWS laat hiermee zien hoe open source ingezet wordt als strategisch beleidsinstrument binnen publieke voorzieningen.

Daarnaast vinden we het als overheidsorganisatie belangrijk om kennis te delen. In dit artikel geven wij daarom graag inzicht in een recente aanbesteding door VWS, de Persoonlijke Gezondheidsomgeving (PGO) en de doorontwikkeling van het MedMij-stelsel. VWS laat zien hoe het aanbestedingsproces eruit heeft gezien, welke overwegingen er zijn gemaakt en tenslotte tot welke concrete aanbestedingsteksten dit heeft geleid.

Eisen aan aanbesteden

Het inkopen van maatwerksoftware is een complex proces. In een multidisciplinair team wordt geprobeerd het aanbestedingsproces zo te doorlopen dat de meest passende oplossing wordt verworven voor de beste prijs. Elke aanbesteding bestaat uit functionele eisen en niet-functionele eisen. Functionele eisen zijn de concrete wensen die vanuit de bedrijfsvoering komen, oftewel wat de software precies moet doen om het werk makkelijker te maken. Niet-functionele eisen gaan over randvoorwaarden. Denk hierbij aan eisen rond privacywetgeving, informatiebeveiliging en open standaarden. Ook duurzaamheid en open source vallen onder niet-functionele eisen.

De opensource-ambitie

Voor de genoemde PGO-aanbesteding is eerst beoordeeld welke doelen nagestreefd moesten worden met opensourcewerken. De wettelijke opensource-inspanningsverplichting geeft een duidelijke ondergrens, hier ‘ambitieniveau 1’ genoemd:

Het eenmalig open source publiceren van alle broncode na afronden van de aanbesteding. Feedback wordt niet verwerkt.

VWS heeft ambitieuzere doelen. Het is de ambitie om het GIS meer vanuit een open ecosysteem-gedachte te ontwikkelen. Dit betekent dat de producten en kennis open toegankelijk, interoperabel en transparant zijn, zodat samenwerking mogelijk is. Dit wordt gezien als een manier om efficiëntere en innovatievere zorg te bevorderen.

Een belangrijk onderdeel van deze aanbesteding was daarom het mogelijk maken van hergebruik, zodat wat leverancier A bouwt makkelijk te integreren is in het proces waarvoor leverancier B verantwoordelijk is. Voor hergebruik is het regelmatig, tussentijds publiceren van technische en functionele documentatie essentieel. Dit leidde tot de keuze voor het zogenoemde ‘ambitieniveau 8’:

Het vanaf het begin volledig openbaar open source ontwikkelen van de broncode, aangevuld met open documentatie, faciliteert onmiddellijk hergebruik of toekomstige doorontwikkeling optimaal. Met de inbreng van derden wordt naar behoefte of noodzaak iets gedaan.

Met ambitieniveau 8 benoemen we ook dat er een nog hogere ambitie mogelijk is. Bij het maximale ambitieniveau, laten we dat ‘ambitieniveau 10’ noemen, is ons inziens een vorm van regie op de samenwerking tussen leveranciers nodig die in deze aanbesteding niet haalbaar was.

Proces van aanbesteden

Eerst is, zoals gebruikelijk bij aanbestedingen, een marktconsultatie gedaan. Hieruit bleek dat de aanbesteding wenselijk was.

Daarna is een selectiedocument opgesteld. Hierin staan de globale doelen van de aanbesteding, de selectiecriteria en een toelichting op het proces, zoals de belangrijkste data. In het selectiedocument moest direct al het opensource-ambitieniveau van de aanbesteding worden verwoord:

De, onder de overeenkomst ontwikkelde software, inclusief achterliggende broncode en documentatie, zonder belemmeringen en kosteloos tijdens en na de opdracht ter beschikking te stellen middels respectievelijk een nog nader te bepalen open source- en creative commons-licentie.

Daarop kwamen vanuit potentieel geïnteresseerde leveranciers verschillende vragen. Deze vragen zijn verzameld en beantwoord in een document genaamd de nota van inlichtingen. Vragen die door leveranciers gesteld werden waren bijvoorbeeld:

• Moet de ontwikkelde broncode worden overgedragen aan de opdrachtgever na het aflopen van de overeenkomst? Waar liggen de intellectueel eigendomsrechten van de broncode?
• Hoe gaat de beschikkingstelling precies in zijn werk? Wat moet er precies allemaal ter beschikking gesteld worden? Als de ontwikkelde software al onderdeel uitmaakt van een groter geheel, moet dat grotere geheel dan ook open source ter beschikking gesteld worden? Mag iedereen met het open source beschikbare werk doen wat die wil?
• Moeten de leveranciers gaan samenwerken en zo ja, hoe ziet dat er dan uit?
• Hoe moeten leveranciers omgaan met het gebruik van bestaande componenten waar ze zelf geen intellectueel eigendomsrechten van bezitten?
• Hoe verwacht opdrachtgever dat opdrachtnemers geld kunnen verdienen aan open source ontwikkelde broncode?

Vervolgens is het beschrijvend document en het programma van eisen gepubliceerd. In het beschrijvend document staat wat leveranciers moeten doen en tegen welke prijs. In het programma van eisen wordt gedetailleerd beschreven waar het opgeleverde werk technisch aan moet voldoen. De tekst die wij in deze documenten opnamen over open source is vergelijkbaar met de zin in het selectiedocument, met het verschil dat nu ook de details ingevuld waren:

De, onder de overeenkomst ontwikkelde software, inclusief achterliggende broncode en documentatie, zonder belemmeringen en kosteloos tijdens de opdracht ter beschikking te stellen, middels respectievelijk de European Union Public License (EUPL) versie 1.2. of hoger en de CreativeCommons Attribution Share Alike (CC BY-SA).

We hebben ervoor gekozen ervaring met open source ontwikkelen uit te vragen als een van de subgunningscriteria. Deze input speelde dus mee in de scoring van leveranciers. Dat deden wij met deze tekst:

Of en, zo ja, hoe u software op basis van Open Source geïntegreerd heeft in uw ontwikkelproces.

In het programma van eisen is vermeld wat er specifiek vanuit de open source-ontwikkeling werd verwacht van leveranciers, zoals dat de componenten waaruit de software bestaat met Software Bill of Material-standaarden inzichtelijk moeten worden gemaakt en de eis tot het opnemen van een publiccode.yml. Ook moet de broncode na afloop van de opdracht te archiveren zijn door de opdrachtgever.

Hierop volgden vragen en die zijn gebundeld beantwoord in een tweede nota van inlichtingen.

Leveranciers bereid tot open source ontwikkelen

De methode om in deze aanbesteding opensourcewerken te integreren is positief bevallen. Door allereerst het ambitieniveau te bepalen werd voorkomen dat open source het doel werd in plaats van een middel om onze doelen, zoals efficiëntie en innovatie, te ondersteunen. Opensourcewerken en open source zijn niet op één manier te interpreteren. Dat is al te zien aan de vele beschikbare opensource-licenties met elk hun eigen voorwaarden. Het is ook te zien aan de verschillende niveaus waarop opensourcesamenwerking tot stand kan worden gebracht.

In deze aanbesteding lag het ambitieniveau van de doelen waaraan open source moest bijdragen hoog. Het goed vertalen van het ambitieniveau naar specifieke teksten in een aanbesteding was een uitdaging. Zo wil je niet te veel op de stoel van de leverancier gaan zitten, maar ook niet achteraf discussie krijgen omdat eisen of wensen te vraag of ambigu zijn beschreven.

Uit vragen en inschrijvingen van leveranciers blijkt dat deze openstaan voor het open source ontwikkelen binnen een maatwerkaanbesteding. Leveranciers vragen duidelijkheid over de kaders waarbinnen het opensourcewerken plaatsvindt en over de invloed op hun bestaande bedrijfsvoering. Bij de inschrijvingen blijkt dat de leveranciers wel op één of andere manier het opensourcewerken in hun bedrijfsvoering hebben geïntegreerd. Leveranciers geven aan volop gebruik te maken van bestaande opensourcecomponenten en veelal hun ontwikkelproces ook al vormgegeven te hebben rond versie beheersystemen en agile ontwikkelmethoden. Sommige leveranciers geven aan ook actief bij te dragen aan de open source community’s.

Lessen voor aanbestedingsgereedschapskist

Wij hebben ook veel geleerd. Bij een toekomstige aanbesteding willen we vollediger zijn in het beschrijven van de eisen en verwachtingen. Zo zouden we op voorhand meer duidelijkheid willen geven over de verantwoordelijkheid die een leverancier heeft bij het gebruik van bestaande open source componenten, bijvoorbeeld dat de leverancier ervoor verantwoordelijk is licentieconflicten te voorkomen. Ook wat de leverancier moet doen bij beveiligingsproblemen bij het gebruik van opensourcecomponenten moet meer aandacht krijgen.

Door de aanbesteding zijn er vragen opgekomen over de reikwijdte van open source en of dit ook geldt voor bestaande software. In deze aanbesteding is dit aanvankelijk verwoord als: ‘Alle onder deze aanbesteding ontwikkelde …’ Misschien dat dit punt nog duidelijker was geweest met de zinssnede: ‘Alleen specifiek voor deze overeenkomst ontwikkelde …’

Tijdens de aanbesteding viel op dat we met elkaar een opgave hebben in hoe we vanuit aanbestedingsrecht kijken naar intellectueel eigendom in relatie tot open source. Volgens de meeste standaard inkoopvoorwaarden in de publieke sector komt bij maatwerkaanbestedingen het intellectueel eigendom standaard bij de opdrachtgever te liggen. Zo wordt de opdrachtgever niet belemmert bij de doorontwikkeling van dat maatwerk. Nadeel is alleen dat verder niemand iets met die broncode kan zonder toestemming van die opdrachtgever. Het biedt allerlei voordelen om die intellectueel eigendomsbepaling te vervangen of aanvullen door een opensource-licentie. Je wordt als opdrachtgever niet belemmerd in de doorontwikkeling van het maatwerk en derden – inclusief de opdrachtnemer – krijgen de mogelijkheid om de broncode ook (commercieel) te hergebruiken naar eigen inzicht. De broncode die met publiek geld is ontwikkeld kan daarmee aanvullend renderen én de leverancier heeft een prikkel om de broncode zo goed mogelijk voor hergebruik te ontwikkelen. Makkelijk te hergebruiken broncode is ook makkelijker te doorontwikkelen, wat weer een voordeel is voor de opdrachtgever.

Conclusies

Open source aanbesteden kán. Ook op een hoog ambitieniveau. Leveranciers zijn bereid hieraan mee te werken, wanneer de kaders duidelijk zijn. Leveranciers blijken ruim ervaring te hebben met opensourcesoftware en de open source manier van werken. Als je ze er maar naar vraagt.

Daarnaast blijkt de welwillendheid van al mijn collega’s. Ik hoor regelmatig scepsis over managers, inkopers of projectleiders die open source geen kans zouden willen geven. Die scepsis heb ik niet ervaren. Iedereen was juist heel erg bereid om voor open source aanbesteden te gaan, omdat daarmee belangrijke doelen kunnen worden bereikt, zoals het verlagen van het risico op vendor lock-ins. Als er maar een duidelijk handelingsperspectief is. Om die te bieden heb ik als opensource-expert meegeschreven in de aanbesteding en ik werd betrokken bij veel van de aanbestedingsoverleggen.

Om open source aanbesteden te laten werken moeten we de kennis die in de overheid is mijn inziens bundelen, zodat we tot gezamenlijke kaders en concreet handelingsperspectief komen waar organisaties op kunnen teruggrijpen. Dat is eerder met het onderwerp duurzaamheid gelukt. Laten we het nu doen voor opensourcewerken! Zo werken we toe naar een open ecosysteem van overheidsdigitalisering.