Rapport Algemene Rekenkamer; Rapport Open standaarden en opensourcesoftware bij de Rijksoverheid - Open standaarden en opensourcesoftware bij de Rijksoverheid - Hoofdinhoud

Dit rapport Algemene Rekenkamer is onder nr. 2 toegevoegd aan dossier 32679 - Open standaarden en openscourcesoftware bij de rijksoverheid.

Officiële titel	Open standaarden en opensourcesoftware bij de Rijksoverheid ; Rapport Algemene Rekenkamer; Rapport Open standaarden en opensourcesoftware bij de Rijksoverheid
Document­datum	15-03-2011
Publicatie­datum	15-03-2011
Nummer	KST326792
Kenmerk	32679, nr. 2
Externe link	originele PDF
Originele document in PDF

Tweede Kamer der Staten-Generaal

Vergaderjaar 2010–2011

32 679

Open standaarden en opensourcesoftware bij de rijksoverheid

Nr. 2

RAPPORT

4.3                 Mogelijke besparingen door ruimer gebruik van opensourcesoftware                                                                  45

4.3.1              Aanpak: geen simpele rekensom                                              45

4.3.2              Praktijkvoorbeelden                                                                   46

5                    Conclusies en aanbevelingen                                                   52

5.1                 Beschouwing van het parlementaire debat                             52

5.2                 Antwoorden op vragen Tweede Kamer                                   52

5.2.1              Mogelijkheden en scenario’s                                                    52

5.2.2              Vervangingspotentieel                                                               53

5.2.3              Softwarekosten en mogelijke besparingen                             54

5.2.4              Termijn voor introductie                                                            54

5.2.5              Voor- en nadelen, kansen en risico’s en voorwaarden voor implementatie                                                                    55

5.3                 Aanbevelingen                                                                            55

5.3.1              Verwachtingenmanagement                                                     55

5.3.2              Scheiden van beleidsdoelstellingen                                         55

5.3.3              Werken vanuit strategisch perspectief                                     56

5.3.4              Rol CIO’s                                                                                      56

5.3.5              Rol minister van BZK                                                                 56

6                    Reactie minister en nawoord Algemene Rekenkamer           57

6.1                 Reactie ministers                                                                        57

6.2                 Nawoord Algemene Rekenkamer                                             57

Bijlage 1 Overzicht antwoorden, conclusies, aanbevelingen,

bestuurlijke reactie en nawoord                                               59 Bijlage 2 Lijst met open standaarden voor pas toe of leg uit-principe                                                                                  63

Bijlage 3 Lijst met gangbare open standaarden                                     64

Bijlage 4 Definitie open standaard                                                           65

Bijlage 5 Definitie opensourcesoftware                                                  66

Bijlage 6 Format voor onderzoek naar kosten                                        68

Bijlage 7 Geraadpleegde experts                                                             71

Bijlage 8 Begrippen en afkortingen                                                          72

Literatuur                                                                                    75

SAMENVATTING

Inleiding

De Algemene Rekenkamer heeft op verzoek van de Tweede Kamer onderzoek gedaan naar open standaarden en opensourcesoftware bij de rijksoverheid.¹ Uit de vragen van de Tweede Kamer spreekt de wens dat de overheid meer gebruik gaat maken van open technologie (open standaarden en opensourcesoftware). De Algemene Rekenkamer heeft zelf niet a priori een standpunt over de wenselijkheid van open technologie. Technologische keuzes op het gebied van ICT zijn strategische keuzes, die moeten worden gemaakt in het licht van de werkprocessen van de rijksoverheid die door die technologie worden ondersteund. Technologische argumenten en kostenoverwegingen moeten een plaats hebben in het proces van strategievorming en besluitvorming, maar mogen daarbij niet de enige invalshoek zijn.

Invulling gevend aan het verzoek van de Tweede Kamer zijn we nagegaan of een ruimere toepassing van open standaarden en opensourcesoftware voordelen oplevert in de vorm van kostenbesparingen voor de rijksoverheid en een betere marktwerking in de softwarebranche.

Met dit rapport willen wij eraan bijdragen dat betrokken partijen goed geïnformeerd een debat aan kunnen gaan over de voor- en nadelen van het gebruik van open standaarden en opensourcesoftware door de overheid. Op die manier willen we mede bijdragen aan toekomstbe-stendig beleid van het kabinet hieromtrent.

De vragen van de Tweede Kamer hebben als onderzoeksvragen voor dit onderzoek gediend. We vatten deze vragen als volgt samen:

• 1. 

  Welke mogelijkheden en scenario’s bestaan er voor de vermindering van het gebruik van gesloten standaarden en de introductie van opensourcesoftware bij de ministeries?

• 2. 

  Welk deel van de gesloten standaarden en software kan worden vervangen door open standaarden en opensourceoplossingen en welk deel niet?

• 3. 

  Wat zijn de huidige kosten? Wat zijn de indicatieve initiële en structurele kosten na vermindering van het gebruik van gesloten standaarden en na de introductie van opensourcesoftware? Welke indicatieve besparingen kunnen hiermee worden gerealiseerd?

• 4. 

  Op welke termijn zouden de vermindering van het gebruik van gesloten standaarden en de introductie van opensourcesoftware kunnen worden gerealiseerd?

• 5. 

  Welke voor- en nadelen en kansen en risico’s onderscheidt de Algemene Rekenkamer naast de kostenoverwegingen? Aan welke voorwaarden moet zijn voldaan om de implementatie van open standaarden en opensourcesoftware mogelijk te maken?

• 6. 

  Welke aanbevelingen kan de Algemene Rekenkamer doen, gelet op de relevante actuele nationale en internationale ontwikkelingen rond de inzet van ICT door overheden?

¹ Motie-Gerkens c.s. (Tweede Kamer, 2010b) en het daaruit voortvloeiende verzoek van de Tweede Kamer aan de Algemene Rekenkamer (Tweede Kamer, 2010c).

De vragen zoals de Tweede Kamer die heeft geformuleerd hadden ook betrekking op de decentrale overheden. We hebben de decentrale overheden buiten beschouwing gelaten, omdat wij daar geen onderzoeksbevoegdheden hebben. Wij hebben ons onderzoek gericht op de ministeries, met inbegrip van de baten-lastendiensten. Extern verzelfstandigde onderdelen van het Rijk, zoals rechtspersonen met een wettelijke taak (RWT’s) en zelfstandige bestuursorganen (zbo’s), zijn ook niet in dit onderzoek meegenomen. De reikwijdte van het onderzoek is weergegeven in onderstaande figuur.

Reikwijdte van het onderzoek

Decentrale overheden

(provincies, gemeenten, waterschappen)

Tien jaar beleid en debatten

De afgelopen tien jaar heeft de Tweede Kamer vaak opgeroepen tot «meer» gebruik van open standaarden en opensourcesoftware. In reactie daarop heeft het een kabinet verschillende beleids- en uitvoeringsprogramma’s ontwikkeld.

Belangrijkste mijlpalen rond open standaarden en opensourcesoftware

Maart 2011

Publicatie rapport Algemene Rekenkamer

m h

Jan. 2009

Instructie               Eerste rijksdienst bij voortgangsaanschaf ICT- rapportage diensten of ICT-producten van kracht

NOiV

Juli 2010

Tweede voortgangsrapportage NOiV

Een aantal Kamerleden stelt zich kort vóór en na de millenniumwisseling als doel het gebruik van open standaarden en software bij de overheid en in het onderwijsveld te stimuleren.

Op 20 november 2002 neemt de Tweede Kamer een motie van Tweede Kamerlid Vendrik aan met het verzoek aan de regering om ervoor te zorgen dat per 2006 alle in de publieke sector gebruikte software aan open standaarden voldoet en dat gestimuleerd moet worden dat in de publieke sector gebruikgemaakt wordt van opensourcesoftware.

Het kabinet lanceert in reactie daarop in maart 2003 het programma Open standaarden en opensourcesoftware (OS&OSS). In de jaren daarna komt het kabinet met verschillende acties die als doel hebben kennis binnen het publieke domein op het gebied van opensourcetoepassingen te verspreiden.

In maart 2006 worden het College standaardisatie en het Forum standaardisatie opgericht bij besluit van de minister van Economische Zaken (EZ). Het beleid ten aanzien van open standaarden wordt daar ondergebracht. Het beleid voor opensourcesoftware wordt ook voortgezet in een vernieuwd programma onder de naam Open source als onderdeel van software strategie (OSOSS).

Per januari 2008 wordt het programmabureau Nederland open in verbinding (NOiV) ingericht in opdracht van de ministers van EZ en van Binnenlandse Zaken en Koninkrijksrelaties (BZK) om de uitvoering van het kabinetsbeleid te ondersteunen. Ook stellen de ministers van EZ en BZK het zogenaamde comply or explain and commit-regime in voor de toepassing van open standaarden. Over de mate van naleving van dat regime moeten ministers verantwoording afleggen in de toelichting bij het departementaal jaarverslag bij de informatie over de bedrijfsvoering.

In mei 2010 spreekt de Tweede Kamer over de voortgang van het programma NOiV. Dit mondt uit in de motie-Gerkens c.s. en het verzoek aan de Algemene Rekenkamer.

Ook wordt in 2010 de tweede voortgangsrapportage NOiV aangeboden aan de Tweede Kamer. Als knelpunt wordt daarin onder andere genoemd dat lang niet elke door de overheid gevraagde functionaliteit in open-sourcesoftware beschikbaar is. Ook meldt de rapportage de ervaringen van gebruikers dat de totale kosten van een opensourceoplossing vaak hoog zijn door de kosten van de expertise bij installatie, transitie, documentatie, implementatie, ondersteuning en beheer van de software.

Het vraagstuk «open»

Omdat uit de vraagstelling van de Tweede Kamer de wens spreekt dat de overheid meer gebruik gaat maken van open technologie, besteden we in dit rapport vooral ook aandacht aan de vraag of en zo ja welke voordelen daaraan verbonden zijn.

ICT bij het Rijk: informatiehuishouding en het softwarelandschap ICT is onmisbaar voor het functioneren van vrijwel elke organisatie en ook voor de rijksoverheid. De ministeries hebben voor de uitvoering van hun bedrijfsprocessen een informatiehuishouding ingericht, die wordt ondersteund door ICT: hardware, software, beheer en gebruikersondersteuning. Het softwarelandschap van een ministerie (alle software die in gebruik is) kent een gelaagde opbouw: van de gebruikersapplicaties tot de systeemlagen die niet zichtbaar zijn voor gebruikers. Omdat het software-landschap een complex geheel is, met tal van onderlinge samenhangen, is het niet zonder meer mogelijk één van de onderdelen ervan te vervangen.

ICT in samenhang met de bedrijfsprocessen van de overheid

Open en gesloten standaarden

Een standaard is niet meer en niet minder dan een verzameling afspraken die ervoor zorgt dat applicaties en andere onderdelen van het software-landschap gegevens van elkaar kunnen verwerken. Deze afspraken bevorderen de samenwerking tussen organisaties (ook wel interoperabiliteit genoemd). Standaarden kunnen gesloten zijn of open. Een gesloten standaard is een standaard die is vastgesteld en wordt onderhouden door een natuurlijke persoon of een rechtspersoon (meestal een bedrijf of een groep bedrijven). Veel gesloten standaarden bevatten onderdelen die octrooirechtelijk beschermd zijn en waarvoor de gebruiker moet betalen. Open standaarden zijn vrij te gebruiken. De open en gesloten varianten zijn uitersten; er bestaan veel tussenvarianten en mengvormen.

Vaak genoemde voordelen van open standaarden

In algemene zin kan niet worden gesteld dat open standaarden beter zijn dan gesloten standaarden of andersom. Wel wordt van open standaarden een aantal voordelen vaak genoemd:

Kwaliteit: het proces waarin open standaarden tot stand komen vergroot de kans dat alle relevante belangen worden meegenomen. Kostenbesparing: open standaarden kunnen worden gebruikt zonder eventuele octrooikosten.

Leveranciersonafhankelijkheid: bij open standaarden is het makkelijker om over te stappen op een andere producent met een ander softwareproduct.

Duurzaamheid: het gebruik van open standaarden maakt het waarschijnlijker dat de data ook in de toekomst bruikbaar zullen zijn.

Er bestaat geen bewijsvoering voor de algemene geldigheid van deze potentiële voordelen.

Opensourcesoftware en closedsourcesoftware

Bij opensourcesoftware kan de gebruiker de broncode inzien en veranderen. Bij closedsourcesoftware is de gebruiker voor aanpassingen aan de software en koppelingen naar andere computerprogramma’s gebonden aan de originele leverancier. Een ander kenmerk van opensourcesoftware is dat het wordt geproduceerd door een community - een vaak niet formeel georganiseerde groep programmeurs - en niet door een bedrijf zoals het geval is bij closedsourcesoftware.

Op basis van de Auteurswet berusten de auteursrechten van software bij de maker ervan. De maker kan anderen het recht op gebruik van de software toekennen. Dat gebeurt in een licentieovereenkomst tussen de producent en de gebruiker van de software, kortweg: licentie. Het gebruik van software is gebonden aan de voorwaarden in de licentieovereenkomst. In het algemeen bepalen de licentievoorwaarden bij closedsourcesoftware onder meer dat het verboden is om kopieën van de software te maken, dat de licentie niet mag worden doorverkocht en dat het gebruik van de software beperkt is tot een bepaald aantal computers dan wel (gelijktijdige) gebruikers.

De essentie van opensourcelicenties is dat ze de gebruiker het recht geven om de broncode te gebruiken, te kopiëren, aan te passen en te verspreiden - hetzij in originele hetzij in aangepaste vorm. Dit recht geldt in elk geval voor niet-commercieel gebruik en (afhankelijk van de licentievorm) vaak ook voor commercieel gebruik.

Ook voor software geldt dat de open en de gesloten variant uitersten zijn en dat er veel mengvormen bestaan. Zo bevat steeds meer closedsourcesoftware onderdelen waarvan de broncode open is. Een andere mengvorm is dual licensing. Dit houdt in dat de software zowel gratis als in een betaalde versie wordt verspreid. De betaalde versie bevat dan bijvoorbeeld extra functionaliteit of heeft een gebruikersvriendelijke interface. Vaak biedt een bedrijf alleen bij de betaalde versie van de software ondersteuning bij implementatie en een helpdeskfunctie.

Kosten voor open en gesloten software

Vaak wordt verondersteld dat «open» ook betekent «gratis». Aan het gebruik van software zijn bij een grote organisatie zoals een ministerie echter altijd kosten verbonden: voor aanschaf (waaronder de licentiekosten), implementatie, exploitatie (waaronder beheer) en onderhoud. Dat geldt zowel voor closedsourcesoftware als voor opensourcesoftware. Het belangrijkste verschil vormen de kosten van softwarelicenties (onderdeel van de aanschafkosten), die in het geval van opensourcesoftware in beginsel nul zijn. Desalniettemin is opensourcesoftware niet per definitie de goedkopere variant, omdat de andere kosten hoger kunnen zijn dan bij gesloten varianten. Vaak zal bovendien het beëindigen van de relatie met een leverancier uitstapkosten met zich meebrengen.

Leveranciers hanteren uiteenlopende strategieën op het punt van het onderscheid tussen «open» en «gesloten». Soms stellen bedrijven software die eerst gesloten was later als opensourcesoftware ter beschikking aan een community, waardoor de ontwikkelkosten die de softwareproducent zelf moet maken lager worden. In andere gevallen verkoopt een softwareleverancier een gesloten variant van software die eerst open was. Deze manieren om geld te verdienen aan software (verdienmodellen) veranderen voortdurend, onder invloed van veranderende verhoudingen op de markt.

Bij de keuze voor een softwareapplicatie zijn meer invalshoeken van belang dan alleen de kosten. De software moet ook passen binnen de informatie- en ICT-architectuur van het Rijk en de uitwerking daarvan voor de verschillende onderdelen van het Rijk.

Vaak genoemde voordelen van opensourcesoftware

Net als voor open standaarden geldt voor opensourcesoftware dat er vaak goede eigenschappen als voordeel worden genoemd:

Er zou een snelle respons zijn op vragen over de software omdat er altijd wel een community-lid is dat een oplossing weet voor je probleem.

Opensourcesoftware zou duurzamer zijn dan closedsourcesoftware omdat het voortbestaan van de software beter gewaarborgd is. De

software is immers niet afkomstig van één leverancier.

Ook de technische degelijkheid van de software wordt vaak genoemd als voordeel van opensourcesoftware.

Net zoals open standaarden niet «van nature» bepaalde voordelen hebben, geldt dat opensourcesoftware ook niet altijd deze goede eigenschappen heeft. Opensourcesoftware verschilt vooral van closedsourcesoftware door de licentie die wordt gehanteerd.

Softwarekosten rijksoverheid en besparingsmogelijkheden

Beschikbaarheid van gegevens bij de ministeries Kosten voor software bestaan uit:

aanschafkosten (waaronder licentiekosten);

implementatiekosten;

exploitatiekosten (waaronder beheer);

onderhoudskosten.

De werkprocessen van de ministeries zijn in hoge mate geautomatiseerd en software vormt een onlosmakelijk onderdeel van die processen. Bestanddelen worden in het algemeen niet apart geadministreerd. Dat geldt ook voor de kosten van software. Er geldt geen verplichting voor de ministeries om dat wel te doen en de softwarekosten zijn niet rechtstreeks af te leiden uit de administraties van de ministeries. Zo worden bijvoorbeeld licentiekosten vaak niet apart en per jaar geregistreerd omdat ze in één keer voor een aantal jaren worden afgerekend, dikwijls voor verschil- lende applicaties tegelijk. Ook is een deel van de ICT van verschillende ministeries uitbesteed aan externe dienstverleners die wel de verleende dienst, maar niet de afzonderlijke licentiekosten of onderhoudskosten in rekening brengen.

Huidige kosten

Dit betekent dat de softwarekosten van de rijksoverheid niet nauwkeurig te bepalen zijn zonder een zeer intensieve studie, waarbij bovendien ook dan tal van aannames moeten worden gedaan. Vooral de kosten van implementatie en exploitatie (met inbegrip van beheer) zijn moeilijk eenduidig te bepalen omdat deze kosten ook ontstaan door tijdsbeslag van (ondersteunende) ICT-afdelingen en eindgebruikers.

In de onderstaande figuur is te zien uit welke componenten de totale ICT-kosten van de ministeries bestaan. Hierin hebben wij schematisch weergegeven welke verschillende kostencomponenten we onderscheiden en welke van die kostencomponenten we specifiek in beeld hebben gebracht.

Componenten van de totale ICT-kosten van ministeries

Hardware

_______A______

Software

Indicatief in beeld gebracht door Algemene Rekenkamer

Aanschaf (incl. licenties)

Implementatie

Exploitatie (incl. beheer)

Onderhoud

Overige software

____A____

Relevant deel

Totale opgegeven ICT-kosten ministeries

€ 2,1 miljard*

Onbekende ICT-gerelateerde kosten

Onder meer: kosten eigen personeel

Veel ICT-gerelateerde kosten (waaronder vooral de kosten voor eigen personeel) blijven buiten beeld omdat ze niet worden toegerekend aan een van bovenstaande kostencomponenten.

*cijfers 2009

Wij hebben de softwarekosten in beeld gebracht op basis van globale schattingen van de ministeries en gesprekken daarover. Wij hebben ons daarbij beperkt tot dat deel vande software waarvoor in principe open-sourcealternatieven beschikbaar zijn. Dit deel duiden we aan als het «relevante deel» van de software. Welk deel het relevante deel proportioneel uitmaakt van alle in gebruik zijnde software is niet met voldoende mate van precisie te zeggen. Wij hebben ons gericht op twee compo- nenten van de softwarekosten, namelijk licentiekosten en onderhoudskosten. Om deze kosten in perspectief te plaatsen zijn we ook nagegaan hoe hoog de totale ICT-kosten van de ministeries zijn. Hierbij gaat het, voor zover achterhaalbaar, om de totale kosten voor aanschaf, implementatie, exploitatie en onderhoud van alle hardware en alle software. Dat betekent dat de ministeries in het totale ICT-bedrag alle externe kostencomponenten hebben meegerekend, voor zover deze voor de ministeries achterhaalbaar zijn. Ze hebben daarbij waar nodig gebruikgemaakt van schattingen.

Met elk ministerie hebben we overlegd om te bekijken op welke wijze het ministerie de door ons gevraagde informatie het beste kon aanleveren. Op basis van de afspraken hierover hebben de Chief Information Officers (CIO’s) ons de informatie die zij konden achterhalen verstrekt. Wij benadrukken dat het beeld indicatief is en bovendien een momentopname (peiljaar 2009). Maar ondanks alle beperkingen geldt dat dit voor het te voeren debat wel het enige beschikbare beeld is.

Het indicatieve beeld is als volgt: in 2009 bedroegen de totale ICT-kosten van ministeries (alle hardware en alle software samen) ongeveer € 2,1 miljard. Hiervan bestond ongeveer € 88 miljoen (ongeveer 4% van de totale ICT-kosten) uit licentiekosten van het relevante deel van de software en ongeveer € 170 miljoen (ongeveer 8% van de totale ICT-kosten) uit onderhoudskosten van het relevante deel van de software.

De hoogten van de ontvangen cijfers lopen uiteen tussen de ministeries. Zo varieerden de totale opgegeven ICT-kosten per ministerie tussen € 5,5 miljoen en € 560 miljoen. De opgegeven licentiekosten van het relevante deel van de software varieerden tussen € 0,16 miljoen en € 24 miljoen. De opgegeven onderhoudskosten van het relevante deel van de software ten slotte, varieerden tussen € 0,5 miljoen en € 60 miljoen.

Mogelijke besparingen door ruimer gebruik van opensourcesoftware

De Tweede Kamer lijkt vooral geïnteresseerd in besparingsmogelijkheden.

Het berekenen van het theoretische besparingspotentieel stuit op een aantal problemen:

De hoogte van de huidige kosten van de relevante software blijkt maar zeer ten dele vast te stellen.

Er zijn vele mengvormen en vaak bestaan applicaties uit een combinatie van open en gesloten standaarden en softwarecomponenten. Naast aanschafkosten (waaronder licentiekosten) is ook sprake van kosten voor implementatie, exploitatie (waaronder beheer) en onderhoud. Bovendien zijn er doorgaans verschillen in functionaliteit tussen closedsourcesoftware en de opensourcevariant. Er is geen sprake van een statische situatie.

Er moet rekening worden gehouden met de waarde van de bestaande hard- en software op het ministerie (installed base). Een geforceerde overgang naar andere hard- en software, in plaats van een overgang op een natuurlijk moment, kan leiden tot kapitaalvernietiging. Ministeries blijken bij de aanschaf van software in een aantal gevallen breder te kijken dan alleen de vraag of de software «open» is. Dergelijke keuzes, gebaseerd op een ICT-strategie, leiden in veel gevallen al tot een combinatie van closedsource- en opensourcesoftware in één systeem, ook wel aangeduid als best source.

In onze zoektocht naar betrouwbare financiële gegevens zijn wij enkele business cases tegengekomen waarbij sprake was van een (voorgenomen) overgang van gesloten naar open technologie. Het aantal beschreven cases is te klein en te uiteenlopend (ook qua financieel belang) om er stellige conclusies uit te trekken. Het beeld dat uit de cases naar voren komt is dater soms belangrijke besparingen verwacht worden door de mogelijkheden die opensourcesoftware biedt, maar dat in andere situaties de besparingen, in elk geval procentueel gezien, ook verwaarloosbaar kunnen zijn. Er zijn ook situaties voorstelbaar waarin de inzet van open technologie juist tot hogere kosten kan leiden. Ten slotte blijkt dat er een veel breder scala aan overwegingen aan de orde is dan uitsluitend de financiële.

Conclusies

Beschouwing van het parlementaire debat

We nemen een herhaling van zetten waar in het parlementaire debat over open standaarden en opensourcesoftware. De Tweede Kamer roept op tot «meer» gebruik van open standaarden en opensourcesoftware. Zij laat steeds weten dat onvoldoende vorderingen worden gemaakt en het kabinet geeft aan wel degelijk beleid te voeren. We zien dat het debat vooral wordt gevoerd op basis van beelden in plaats van op concrete feiten en cijfers. De gedachte bij Tweede Kamer en kabinet lijkt te zijn dat het zo snel mogelijk overstappen van gesloten op open technologie de beleidsdoelen ten aanzien van bedrijfsvoering en marktordening dichterbij zal brengen.

Antwoord op vraag 1 Mogelijkheden en scenario’s

Mogelijkheden en migratiescenario’s staan niet op zichzelf maar hangen af van keuzes die gemaakt worden in het proces van strategische planning. Daarbij moeten de te bereiken organisatiedoelen leidend zijn. Uitgaande van die doelen worden achtereenvolgens de informatiestrategie en de ICT-strategie afgeleid. De ICT-strategie gaat onder meer over de vraag welke softwarefunctionaliteit er nodig is (softwarebeleid) en hoe daarin zal worden voorzien (verwervingsbeleid). Pas in het kader van het verwervingsbeleid zijn keuzes op het terrein van gesloten versus open standaarden respectievelijk software aan de orde.

Antwoord op vraag 2 Vervangingspotentieel

De keuze voor opensource- of closedsourcesoftware is niet zwart–wit. Het aanbod op de huidige softwaremarkt verandert continu en omvat allerlei mengvormen van open en gesloten varianten. De ministeries maken tegenwoordig al veel gebruik van opensourcesoftware. Daar komt bij dat het softwarelandschap van een ministerie uit een groot aantal onderdelen bestaat, die via veel verschillende standaarden met elkaar en met de buitenwereld gegevens uitwisselen. Dat maakt dat de keuze voor software niet alleen gebaseerd kan zijn op de vraag «open of niet?». Op deze complexe werkelijkheid is alleen greep te krijgen met een strategische aanpak. De consequentie daarvan is dat het niet op voorhand mogelijk is om een specifiek deel van het softwarelandschap aan te wijzen dat «open» gemaakt kan worden, laat staan dat dit valt te kwantificeren. Bovendien ontstaan er in het aanbod continu nieuwe versies en applicaties, open en gesloten en alles daartussen.

Antwoord op vraag 3 Softwarekosten en mogelijke besparingen Licentiekosten vormen slechts een beperkt deel van de totale software-kosten (zie figuur kostencomponenten). Eventuele besparingen op de softwarekosten van de ministeries kunnen alleen in concrete situaties worden bepaald door kosten–batenanalyses te maken in het kader van de uitvoering van het softwarebeleid en de daarbij behorende verwervingsstrategie. Dergelijke kosten–batenanalyses moeten uitgaan van de totale kosten voor software. Dat wil zeggen: naast de aanschafkosten (waaronder licentiekosten) moeten ook de kosten voor implementatie, exploitatie (waaronder beheer) en onderhoud meegewogen worden.

Antwoord op vraag 4 Termijn voor introductie

De overgang van «gesloten» naar «open» zal niet op een bepaald moment volledig afgerond zijn. Er zal sprake zijn van verschuivingen naar meer of minder gebruik van open standaarden en opensourcesoftware. Hoe en binnen welke termijn die verschuivingen verlopen, hangt af van de gehanteerde informatie- en ICT-strategie, de uitgangssituatie (installed base) van het betreffende ministerie en van ontwikkelingen op de softwaremarkt.

Antwoord op vraag 5 Voor- en nadelen, kansen en risico’s en voorwaarden voor implementatie

Een groot deel van dit rapport gaat over voor- en nadelen en kansen en risico’s, maar deze zijn niet algemeen geldig. Ze hangen in belangrijke mate af van de concrete situatie, de standaard in kwestie en het specifieke softwareproduct. De vraag of bepaalde voor- of nadelen en kansen of risico’s zich voordoen kan alleen worden beantwoord door onderzoek naar de omstandigheden in een concrete situatie en door specifiek marktonderzoek naar de voor die situatie beschikbare softwareproducten en diensten.

Aanbevelingen

Verwachtingenmanagement

De Tweede Kamer verwacht dat een ruimere inzet van open technologie (open standaarden en opensourcesoftware) tot forse besparingen zal leiden. Volgens ons zijn er slechts beperkte mogelijkheden voor quick wins in termen van kostenbesparingen in relatie tot de totale ICT-kosten van de rijksoverheid. Wij bevelen het geheel overziende aan geen al te hoge verwachtingen te hebben van de besparingsmogelijkheden door de ruimere toepassing van open standaarden en opensourcesoftware.

Beleidsdoelstellingen

Wij bevelen aan een duidelijk onderscheid te maken tussen de beleidsdoelen gericht op een betere de bedrijfsvoering van de ministeries (betere publieke dienstverlening en eventuele kostenbesparingen), beleidsverantwoordelijkheid van de minister van BZK, respectievelijk beleidsdoelen gericht op marktordeningsvraagstukken, beleidsverantwoordelijkheid van de minister van Economische Zaken, Landbouw en Innovatie (EL&I). Voor beide soorten beleidsdoelen dienen eenduidige doelen te worden geformuleerd zodat het beleid effectief en efficiënt kan worden vormgegeven en uitgevoerd en de minister van BZK respectievelijk de minister van EL&I zich hierover kunnen verantwoorden.

Strategisch perspectief

Wij bevelen de coördinerende ministers en de vakministers aan om vanuit strategische doelen te werken. Het benaderen van ICT-vraagstukken puur vanuit de wens kosten te besparen vormt een te beperkt perspectief.

Rol CIO’s

In het proces van strategische besluitvorming dient de CIO Rijk samen met de departementale CIO’s een sleutelrol te krijgen. Om te zorgen voor een consistent ICT-beleid op rijksniveau zou de CIO Rijk die sleutelrol en de bijbehorende bevoegdheden moeten krijgen in de interdepartementale afstemming. Bij deze benadering dient wel te allen tijde rekening te worden gehouden met de functiespecifieke behoeften op ICT-gebied die van toepassing tot toepassing en van departement tot departement kunnen verschillen.

Rol minister van BZK

Ons onderzoek heeft zich niet gericht op de mate waarin de verschillende ministeries strategische doelstellingen op ICT-gebied hebben geformuleerd die de basis vormen voor het nemen van technologische beslissingen, waaronder softwarekeuzes.

Wij bevelen de minister van BZK aan na te gaan in hoeverre ministeries hun softwarekeuzes maken op basis van strategische doelstellingen op ICT-gebied en daar criteria voor te expliciteren. Ook bevelen wij de minister aan ervoor te zorgen dat alle ministeries medio 2012 aan deze criteria voldoen. Omdat de invulling van de criteria door technologische ontwikkelingen onderhevig is aan permanente verandering, bevelen wij de minister ook aan om de criteria en de operationalisering daarvan periodiek tegen het licht te houden en zo nodig bij te stellen. Wij denken dat de overheid voor de invulling van deze criteria ook gebruik zou moeten maken van kennis en expertise van personen uit andere branches dan de overheid.

Ten slotte bevelen wij de minister van BZK aan regelmatig de Tweede Kamer te informeren over de ICT-strategie en de voortgang daarvan.

Reactie ministers

De minister van BZK heeft op 9 maart 2011, mede namens de minister van EL&I, gereageerd op ons rapport. De minister stemt in met onze conclusies, met enkele kanttekeningen. Zo geeft hij aan dat alle ministeries sinds 2009 een informatiestrategie en een daaruit afgeleide ICT-strategie hebben. Ook tekent hij aan dat het weliswaar niet op voorhand mogelijk is om een specifiek deel van het softwarelandschap aan te wijzen dat «open» gemaakt kan worden, maar dat dit per organisatie wel mogelijk is. Verder is de minister van mening dat gemiddeld genomen vooral de kwalitatieve voordelen van open standaarden groter zijn dan de nadelen. Ten slotte zegt de minister de complexiteit en verwevenheid van ICT-omgevingen niet als een feit te beschouwen maar juist te willen verminderen.

Wat onze aanbevelingen betreft geeft de minister van BZK aan te zullen overleggen met de minister van EL&I over hoe de beleidsdoelen voor bedrijfsvoering en marktordening in de toekomst scherper onderscheiden kunnen worden. De minister schrijft ook dat de positie van de CIO Rijk en de departementale CIO’s onlangs versterkt is.

Voor het toegezegde overleg tussen de minister van BZK en de minister van EL&I over het onderscheid tussen beleidsdoelen geldt dat we het vooral van belang achten dat dit uitmondt in concreet geformuleerd beleid en bijbehorende aanpak. Wat de ambities van de minister betreft om de complexiteit en verwevenheid van ICT-omgevingen te verminderen zijn we vooral benieuwd naar de concrete stappen. De minister gaat in zijn reactie namelijk niet in op onze aanbevelingen over zijn rol als coördinerend minister. Evenmin geeft hij aan of en hoe hij de Tweede Kamer van informatie zal voorzien over de ICT-strategie en de voortgang daarvan. Tot slot benadrukken we het belang van een strategie die is afgestemd op maatschappelijke en technische ontwikkelingen in de nabije toekomst. Daarbij komen de ICT-middelen (zoals hardware en software) minder centraal te staan en gaan de strategische beslissingen vooral om het definiëren van de juiste informatie- en ICT-diensten.

1 INLEIDING

1.1 Aanleiding: verzoek Tweede Kamer

In de Tweede Kamer is de afgelopen jaren veel gesproken over open standaarden en opensourcesoftware. Standaarden zijn afspraken over de manier waarop organisaties, applicaties, softwarecomponenten en netwerken met elkaar kunnen samenwerken. Een voorbeeld is het documentformaat waarin tekstgegevens worden opgeslagen en getransporteerd. Naast gesloten standaarden, die zijn vastgesteld door een leverancier en die uitsluitend gebruikt mogen worden met toestemming van de leverancier, bestaan er ook open standaarden die openbaar toegankelijk zijn en die iedereen vrijelijk mag gebruiken (zie ook definitie in bijlage 4). Het doel van open standaarden is het bevorderen van de mogelijkheden om gegevens uit te wisselen.

Van opensourcesoftware² is sprake als het iedereen vrijstaat de broncode³ in te zien, te gebruiken, te verbeteren, aan te vullen en verder te verspreiden (zie ook definitie in bijlage 5). Dit in tegenstelling tot closedsourcesoftware (proprietary software), waarbij de gebruiker niet het recht op inzage van de broncode heeft en voor aanpassingen van de software en koppelingen naar andere computerprogramma’s gebonden is aan de originele leverancier. Het doel van opensourcesoftware is het bevorderen van de laagdrempelige toegankelijkheid van die software voor zoveel mogelijk partijen.

²  Ook wel «FLOSS» genoemd: Free-/Libre-/ Opensourcesoftware.

³  In de broncode legt een programmeur de instructies vast die de computer moet uitvoeren. Broncode kan door de mens gelezen worden maar moet worden vertaald (gecompileerd) in «machinetaal» om de instructies te kunnen laten uitvoeren door een computer.

Motie Tweede Kamer

Tijdens het Algemeen Overleg met de staatssecretaris van Binnenlandse Zaken en Koninkrijksrelaties (BZK) op 12 mei 2010 over onder meer grote ICT-projecten (Tweede Kamer, 2010a) uitte Kamerlid Gerkens, woordvoerder ICT van de Socialistische Partij (SP), kritiek op de voortgang van het actieplan van het kabinet Nederland open in verbinding (NOiV). Dit actieplan ziet de informatie-uitwisseling tussen informatiesystemen van de overheid als een essentiële voorwaarde voor een toekomstvaste ontwikkeling van overheidsdiensten en -toepassingen die door en met ICT in brede zin mogelijk worden gemaakt. Om dit te bereiken wil het kabinet met het actieplan NOiV het gebruik van open standaarden en open-sourcesoftware versnellen en stimuleren. Het programma loopt volgens de SP bijzonder stroef en de partij uitte de vrees dat het een stille dood aan het sterven is. Dit vormde de aanleiding om een motie in te dienen (de motie-Gerkens c.s., Tweede Kamer, 2010b) gericht op een onderzoek door de Algemene Rekenkamer. Deze motie werd op 20 mei 2010 aangenomen.

In de motie vraagt de Tweede Kamer de Algemene Rekenkamer een onderzoek te doen naar de vermindering van het gebruik van gesloten standaarden en de introductie van opensourcesoftware bij de rijksoverheid en de decentrale overheden en de besparingen die dit kan opleveren. De Tweede Kamer is van mening is dat er forse besparingen kunnen worden behaald in de uitgaven aan ICT door de overheid wanneer de marktwerking verbeterd wordt door openheid van de markt.

Verzoek aan de Algemene Rekenkamer

Nadat de Tweede Kamer op 20 mei 2010 de motie over het verzoek aan de Algemene Rekenkamer heeft aangenomen (Tweede Kamer, 2010b) heeft op 6 juli 2010 vooroverleg plaatsgevonden tussen vertegenwoordigers van de Algemene Rekenkamer en een lid van de Tweede Kamer (mevrouw Van der Burg, VVD) en twee medewerkers van het Bureau Onderzoek Rijksuitgaven (BOR). In dit vooroverleg is overeenstemming bereikt over de vraagstelling en het gewenste tijdpad. De vaste commissie voor de Rijksuitgaven heeft volgens procedure de vaste commissie voor Binnenlandse Zaken en Koninkrijksrelaties per brief d.d. 12 juli 2010 positief geadviseerd over het verzoek aan de Algemene Rekenkamer (Tweede Kamer, 2010c). Op 22 juli 2010 hebben wij van de Tweede Kamer een uitwerking van het verzoek ontvangen om onderzoek uit te voeren zoals gevraagd in de motie-Gerkens c.s. In verband met het krappe tijdpad hebben wij de Tweede Kamer per brief d.d. 22 juli 2010 laten weten het onderzoek zonder verdere uitstel in uitvoering te nemen. Op 9 september 2010 hebben wij het officiële verzoek van de Tweede Kamer ontvangen, naar aanleiding waarvan wij de uitvoering van het onderzoek per brief hebben bevestigd (Algemene Rekenkamer 2010b).

1.2 Betrokken actoren

Voor dit onderzoek zijn de volgende actoren relevant:

De minister van Economische Zaken, Landbouw en Innovatie (EL&I 4), die verantwoordelijk is voor de ordening van de ICT-markt. De minister van BZK, die verantwoordelijk is voor de kwaliteit van de informatievoorziening van het Rijk, met inbegrip van de agentschappen en zbo’s.

Het programmabureau NOiV, dat als doel heeft overheidsorganisaties te informeren over de mogelijkheden van open standaarden en opensourcesoftware en ze te stimuleren deze waar mogelijk toe te passen in hun informatiesystemen in de lijn van het actieplan Nederland Open in Verbinding. Het programmabureau is een van de programma’s van ICTU.⁵

College standaardisatie en Forum standaardisatie Het College standaardisatie heeft tot taak de ministers van EL&I en van BZK aanbevelingen te doen over open standaarden voor de elektronische gegevensuitwisseling tussen overheidsorganisaties en bedrijven, tussen overheidsorganisaties en burgers en tussen overheidsorganisaties onderling en het gebruik van open standaarden te bevorderen. Daartoe houdt het college een lijst in stand met open standaarden waarvoor voor overheidsorganisaties een «comply or explain and commit»-regime geldt, zie hoofdstuk 2 (het College Standaardisatie noemt dit «pas toe of leg uit», zie ook bijlage 2) en een lijst met gangbare open standaarden (zie bijlage 3).

Het Forum standaardisatie heeft tot taak de werkzaamheden van het college voor te bereiden en het college te adviseren over zijn werkzaamheden.

Marktpartijen en brancheorganisaties: softwareproducenten en softwareleveranciers, bedrijven die software implementeren, beheren en onderhouden, bedrijven die ICT-dienstverlening aanbieden en hun brancheorganisaties.

Community’s: groepen personen die meer of minder formeel georganiseerd samenwerken en die open standaarden of opensourcesoftware ontwikkelen, aanpassen en onderhouden en ter beschikking stellen.

⁴  Tot 14 oktober 2010: de minister van Economische Zaken.

⁵  ICTU staat voor ICT Uitvoeringsorganisatie; deze organisatie werd als stichting op 11 april 2001 opgericht door het ministerie van Binnenlandse Zaken en Koninkrijksrelaties en de Vereniging van Nederlandse Gemeenten. Het werkveld van ICTU is de elektronische overheid (bron: www.ictu.nl).

1.3 Opzet van het onderzoek

1.3.1 Doel

Met dit rapport willen wij bijdragen aan een goed geïnformeerd debat over de mogelijkheden en onmogelijkheden van een ruimere toepassing van open standaarden en opensourcesoftware door de overheid en daarmee aan toekomstbestendig beleid van het kabinet hieromtrent.

1.3.2 Probleemstelling

Dit rapport gaat in op de vraag of een ruimere toepassing van open standaarden en opensourcesoftware voordelen oplevert in de vorm van kostenbesparingen voor de overheid en een betere marktwerking in de softwarebranche. De onderzoeksvragen van de Tweede Kamer zijn leidend geweest, met dien verstande dat de impliciete onderliggende aannames (zie § 1.3.3) niet als uitgangspunt hebben gediend, maar zijn meegenomen als te onderzoeken thema’s.

Open standaarden en opensourcesoftware worden vaak in één adem genoemd. Het zijn echter twee verschillende fenomenen die soms met elkaar samenhangen. In dit rapport zullen wij het onderscheid toelichten en steeds aangeven welke van de twee fenomenen we behandelen.

1.3.3 De vragen van de Tweede Kamer

De vragen van de Tweede Kamer hebben als onderzoeksvragen voor dit onderzoek gediend; we vatten ze als volgt samen:⁶

• 1. 

  Welke mogelijkheden en scenario’s bestaan er voor de vermindering van het gebruik van gesloten standaarden en de introductie van opensourcesoftware bij de ministeries?

• 2. 

  Welk deel van de gesloten standaarden en software kan worden vervangen door open standaarden en opensourceoplossingen en welk deel niet?

• 3. 

  Wat zijn de huidige kosten? Wat zijn de indicatieve initiële en structurele kosten kosten na vermindering van het gebruik van gesloten standaarden en na de introductie van opensourcesoftware? Welke indicatieve besparingen kunnen hiermee worden gerealiseerd?

• 4. 

  Op welke termijn zouden de vermindering van het gebruik van gesloten standaarden en de introductie van opensourcesoftware kunnen worden gerealiseerd?

• 5. 

  Welke voor- en nadelen en kansen en risico’s onderscheidt de Algemene Rekenkamer naast de kostenoverwegingen? Aan welke voorwaarden moet zijn voldaan om de implementatie van open standaarden en opensourcesoftware mogelijk te maken?

• 6. 

  Welke aanbevelingen kan de Algemene Rekenkamer doen, gelet op de relevante actuele nationale en internationale ontwikkelingen rond de inzet van ICT door overheden?

⁶ Deze vragen hebben betrekking op de ministeries. De vragen zoals de Tweede Kamer die heeft geformuleerd hadden ook betrekking op de decentrale overheden. Zoals in § 1.3.4 aangegeven, hebben we de decentrale overheden buiten beschouwing moeten laten en ons onderzoek gericht op de ministeries.

Uit deze vragen spreekt de wens van de Tweede Kamer dat de overheid meer gebruik gaat maken van open technologie (open standaarden en opensourcesoftware). Een wens die overigens ook uit eerdere debatten in de Tweede Kamer reeds is gebleken. Verder proeven wij uit de vraagstelling enkele impliciete aannamen, namelijk dat:

het Rijk open technologie op dit moment niet of nauwelijks gebruikt;

open technologie gelijkwaardige functionaliteit biedt;

er een concreet aanwijsbaar deel van in gebruik zijnde standaarden en software valt aan te wijzen dat evident in aanmerking komt om te worden vervangen door open varianten;

de administraties van het Rijk inzicht kunnen bieden in de kosten van standaarden en software;

open technologie goedkoper is dan gesloten technologie.

De Algemene Rekenkamer heeft zelf a priori geen standpunt over de wenselijkheid van open technologie. Technologische keuzes op het gebied van ICT zijn strategische keuzes, die moeten worden gemaakt in het licht van de processen van het Rijk die door die technologie worden ondersteund. Technologische argumenten en kostenoverwegingen moeten een plaats hebben in het proces van strategievorming en besluitvorming, maar mogen daarbij niet de enige invalshoek zijn.

Wij onderschrijven ook niet op voorhand de genoemde impliciete aannames.

1.3.4 Reikwijdte

Dit rapport is geschreven vanuit de invalshoek van de rijksoverheid. Het verzoek van de Tweede Kamer had ook betrekking op de decentrale overheden (provincies, gemeenten en waterschappen). De Algemene Rekenkamer beschikt echter niet over onderzoeksbevoegdheden bij de decentrale overheden. Het Ministerie van BZK heeft ons in ambtelijk overleg laten weten evenmin over dergelijke bevoegdheden te beschikken en ook niet op andere wijze de benodigde gegevens te zullen verzamelen bij de decentrale overheden. Daarom hebben we de decentrale overheden buiten beschouwing moeten laten en ons onderzoek gericht op de rijksoverheid. Wij hebben alleen die onderdelen van de rijksoverheid in het onderzoek betrokken waarbij een van de ministers direct verantwoordelijk is voor de bedrijfsvoering. Dat zijn de ministeries zelf, met inbegrip van de baten-lastendiensten. Extern verzelfstandigde onderdelen van het Rijk, zoals rechtspersonen met een wettelijke taak (RWT’s) en zelfstandige bestuursorganen (zbo’s), zijn niet in dit onderzoek meegenomen. De reikwijdte is weergegeven in figuur 1.

Figuur 1 Reikwijdte van het onderzoek

Ministeries

(kerndepartementen en baten-lastendiensten)

Rwt’s en zbo’s

Decentrale overheden

(provincies, gemeenten, waterschappen)

1.3.5 Aanpak

Wij hebben verschillende onderzoeksactiviteiten uitgevoerd om de vragen van de Tweede Kamer te kunnen beantwoorden.

Kostenonderzoek bij de ministeries

Het kostenonderzoek bij de ministeries diende drie doelen. Het primaire doel was om te bepalen wat de ordegrootte van de huidige software- en applicatiekosten is. Daarnaast wilden we een indicatief antwoord krijgen op de vraag wat het huidige aandeel aan opensourcesoftware is. Ten slotte was het kostenonderzoek bedoeld om een globaal inzicht te krijgen in het softwarelandschap bij de ministeries als context voor het onderzoek: welke soorten software worden door de verschillende ministeries gebruikt en welke overeenkomsten en verschillen in software-landschap bestaan er tussen de ministeries?

Zoals in § 4.1 wordt toegelicht, zijn softwarekosten niet rechtstreeks af te leiden uit de administraties van de ministeries. Wij hebben daarom de kosten van de software van de rijksoverheid in beeld gebracht op basis van globale schattingen van de ministeries. We hebben hiervoor een «format» opgesteld (zie bijlage 6) dat gebaseerd is op de belangrijkste verschillen in kostenopbouw tussen closedsourcesoftware⁷ software en opensourcesoftware. Bij het opstellen van dit format hebben wij onder meer gebruikgemaakt van de Handreiking voor kosten-batenanalyse voor ICT projecten (Ecorys, 2007). Het format is te beschouwen als een vereenvoudigde variant van een Total Cost of Ownership (TCO)-model⁸. We hebben dit format besproken met de Chief Information Officier (CIO) van het Rijk, met de CIO’s van enkele ministeries en met drie directeuren van interne ICT-dienstverleners⁹ die hun financiële administratie hebben ingericht volgens het baten-lastenstelsel.¹⁰ Daarnaast hebben wij enkele externe deskundigen geraadpleegd, respectievelijk uit de wereld van advies, audit en wetenschap. Het unanieme commentaar luidde dat ons format, hoewel analytisch bruikbaar, in de praktijk voor ministeries niet volledig in te vullen zou zijn op basis van gegevens in hun administraties.

We hebben een tweesporenaanpak toegepast. We hebben met de ministeries het kostenonderzoek aan de hand van ons format uitgevoerd, met als doel bij elk ministerie in elk geval die gegevens te verkrijgen die het ministerie wel kon leveren, waar nodig gebruikmakend van schattingen. Daarnaast hebben we de wijze waarop de genoemde interne ICT-dienstverleners hun software en de kosten daarvan beheren geanalyseerd. De gegevens uit de beide sporen hebben wij gecombineerd tot een indicatief totaalbeeld, dat wij hebben geverifieerd bij de CIO’s van de ministeries.

⁷  Closedsourcesoftware wordt ook wel aangeduid met de term propriëtaire software. Het begrip closedsourcesoftware wordt verder toegelicht in § 3.3.

⁸  TCO (Total Cost of Ownership) is een definitie van kosten die alle directe en indirecte kosten van een product omvat over de hele levenscyclus van het product van verwerving tot en met afstoting.

⁹  Hiermee bedoelen we organisaties (al dan niet intern verzelfstandigd) die ICT-diensten leveren aan een of meer ministeries.

¹⁰  Dit waren: GDI (Ministerie van Justitie, vanaf 14 oktober 2010: Ministerie van Veiligheid en Justitie), Ivent (Ministerie van Defensie), SSO-ICT (Ministerie van Verkeer en Waterstaat, vanaf 14 oktober 2010: Ministerie van Infrastructuur en Milieu).

Het beeld is uitdrukkelijk niet gebaseerd op onderliggende gedetailleerde administratieve gegevens en onze controle daarvan, en wijkt dan ook af van onze normale werkwijze. Desondanks menen wij dat wij met dit indicatieve beeld er een bijdrage aan kunnen leveren dat de Tweede Kamer en de betrokken ministers goed geïnformeerd een debat aangaan over de mogelijkheden en onmogelijkheden van een ruimere toepassing van open standaarden en opensourcesoftware.

Expertraadpleging

We hebben een aantal externe deskundigen geraadpleegd om zicht te krijgen op de mogelijkheden en beperkingen, dilemma’s en benaderingswijzen van vraagstukken op het gebied van open standaarden en opensourcesoftware. Wij hebben gesproken met een groot aantal personen die beleidsmatig, wetenschappelijk of vanuit de praktijk deskundig zijn op dit terrein. Wij hebben dit gedaan in individuele interviews en tijdens een expertmeeting waarbij wij de kennis, ervaringen en meningen van de verschillende externe deskundigen bij elkaar hebben gebracht en met elkaar hebben geconfronteerd.

In bijlage 7 staat een overzicht van de geraadpleegde externe deskundigen.

Literatuurverkenning

We hebben relevante literatuur, waaronder ook internetbronnen, op het gebied van open standaarden en opensourcesoftware bestudeerd en geanalyseerd. Deze verkenning hebben wij gebruikt om de informatie, afkomstig uit andere bronnen te valideren en aan te vullen.

Discussiegroep op LinkedIn

In een discussiegroep op de zakelijke netwerksite LinkedIn hebben we gedurende twee weken een discussie opengesteld over de voor- en nadelen van open standaarden en opensourcesoftware. Het doel was om kennis te nemen van een zo breed mogelijk scala aan inzichten en ervaringen. Belangrijk was om, waar mogelijk, onderbouwde casussen en business cases te identificeren van de introductie van opensourcesoftware waarmee aantoonbaar per saldo kosten zijn bespaard.

Analyse van de parlementaire discussie

We hebben de parlementaire debatten over open standaarden en opensourcesoftware van de afgelopen tien jaar geanalyseerd. Het doel was na te gaan over welke onderwerpen is gedebatteerd, welke standpunten uit de discussie naar voren kwamen en wat de uitkomsten van de debatten waren.

Analyse business cases

In diverse gesprekken die wij in het kader van dit onderzoek hebben gevoerd hebben we verschillende business cases aangereikt gekregen, die zijn opgesteld omdat een organisatie overwoog over te gaan op open standaarden of opensourcesoftware of een combinatie daarvan. We hebben vier business cases op het terrein van opensourcesoftware en eveneens drie business cases wat betreft open standaarden bestudeerd. Een business case wordt in principe opgesteld voorafgaand aan een project. Ons zijn geen evaluaties bekend van afgeronde projecten waarbij is overgegaan van «gesloten» naar «open».

1.4 Leeswijzer

In hoofdstuk 2 geven we een beknopte historische beschouwing van de debatten en van de ontwikkeling van het beleid over open standaarden en opensourcesoftware bij de overheid.

In hoofdstuk 3 gaan wij in op het vraagstuk «open». Wat zijn open standaarden en wat is opensourcesoftware? Wij leggen deze begrippen uit en plaatsen ze in het perspectief van de doelstellingen die de rijksoverheid met ICT nastreeft. Daarbij geven wij aan welke vormen van open en gesloten standaarden en software er zijn en welke mengvormen voorkomen. Ook gaan wij in op de kostenstructuur van de verschillende vormen van software voor de overheid als gebruiker daarvan en de verdienmodellen die marktpartijen en community’s hanteren of kunnen hanteren bij het aanbieden van softwarelicenties en aan software gerelateerde dienstverlening.

In hoofdstuk 4 gaan wij in op de softwarekosten van de rijksoverheid en de mogelijke besparingen die daarop zijn te realiseren en de daaraan verbonden kansen, risico’s en de hieraan verbonden randvoorwaarden. In hoofdstuk 5 presenteren wij de antwoorden op de vragen van de Tweede Kamer en onze aanbevelingen.

De bestuurlijke reactie op ons rapport en ons nawoord daarbij staan in hoofdstuk 6.

2 TIEN JAAR BELEID EN DEBATTEN

De Tweede Kamer heeft het afgelopen decennium vaak gedebatteerd over open standaarden en opensourcesoftware. In dit hoofdstuk geven we een beknopte historische beschouwing van die debatten en van de ontwikkeling van het beleid over open standaarden en opensourcesoftware bij de overheid. In figuur 2 staan de belangrijkste mijlpalen in de debatten en de beleidsontwikkeling weergegeven. Een meer uitgebreide weergave van de parlementaire discussie is terug te vinden in de bijlage op de website van de Algemene Rekenkamer: www.rekenkamer.nl.

Figuur 2 Belangrijkste mijlpalen rond open standaarden en opensourcesoftware

Maart 2011

Publicatie rapport Algemene Rekenkamer

m h

Jan. 2009

Instructie               Eerste rijksdienst bij voortgangsaanschaf ICT- rapportage diensten of ICT-producten van kracht

NOiV

Juli 2010

Tweede voortgangsrapportage NOiV

Een aantal Kamerleden¹¹ stelt zich rond de millenniumwisseling als doel het gebruik van open standaarden en software bij de overheid en in het onderwijsveld te stimuleren. Naar aanleiding hiervan kondigen de minister van Onderwijs, Cultuur en Wetenschappen en de minister voor Grote Steden en Integratiebeleid aan te onderzoeken wat de beste manier is om dit te bevorderen en met plannen te komen (Tweede Kamer, 1999; Tweede Kamer, 2001). Op 20 november 2002 dient Kamerlid Vendrik een motie in waarin hij de regering verzoekt ervoor te zorgen dat per 2006 alle in de publieke sector gebruikte software aan open standaarden voldoet en te stimuleren dat in de publieke sector gebruikgemaakt wordt van opensourcesoftware (Tweede Kamer, 2002). Deze motie wordt aangenomen.

¹¹ Lambrechts en Bakker, D66 en Voûte-Droste, VVD.

Gebaseerd op deze motie lanceert het kabinet in maart 2003 het programma Open standaarden en open source software (OS&OSS) dat door ICTU wordt uitgevoerd (BZK en EZ, 2003). De vraag wat de ambitie van de overheid moet zijn komt ook in de discussie tussen de minister en de Tweede Kamer naar voren. De doelstellingen zijn: de gegevensuitwisseling (interoperabiliteit) tussen overheidsdomeinen verbeteren, de toegankelijkheid van informatie vergroten en leveranciersonafhanke-lijkheid bewerkstelligen. Het is niet de bedoeling om een verplichting op te leggen voor opensourcesoftware en er worden ook geen kwantitatieve doelstellingen vastgelegd voor en door het kabinet.

In de jaren daarna komt het kabinet met een aantal acties die als doel hebben kennis binnen het publieke domein op het gebied van open-sourcetoepassingen te verspreiden, onder andere door een bewustwordingsprogramma, een catalogus, een handleiding aanbesteding en de oprichting van de Standaardisatieraad en het Standaardisatieforum (Tweede Kamer, 2004a). Kamerleden vragen de regering naar mogelijke kostenbesparingen (Tweede Kamer, 2004b) bij de toepassing van open-sourcesoftware en over het «megacontract» tussen de overheid en Microsoft (Tweede Kamer, 2005). In het laatste geval van de vervanging van de software voor kantoorautomatisering was er volgens de minister geen volwaardig opensourcealternatief beschikbaar. In augustus 2005 gaan de minister van EZ en de minister voor Bestuurlijke Vernieuwing en Koninkrijksrelaties (BVK) in op de stand van zaken van de uitvoering van de motie-Vendrik van november 2002. Zij geven aan dat de overheid voor de uitwisseling van financiële gegevens gebruik gaat maken van de taal XML (een open standaard), wat volgens het kabinet een forse lastenre-ductie genereert (EZ en BVK, 2005).

In maart 2006 worden het College standaardisatie en het Forum standaardisatie opgericht bij besluit van de minister van Economische Zaken (EZ, 2006a). Ook wordt besloten het beleid ten aanzien van open standaarden onder te brengen bij het college en het forum. Het beleid voor open-sourcesoftware wordt ook voortgezet in een vernieuwd programma onder de naam Open source als onderdeel van software strategie (OSOSS).

De overheid zet haar stimuleringsbeleid voort (EZ, 2006b), onder andere door het inrichten van een expertisecentrum bij het ICTU, een zogeheten Taxonomie Project¹² en de invoering van Open Document Format (ODF), een standaard voor reviseerbare documenten (EZ, 2006c).

In 2007 dienen de Kamerleden Aptroot en Vendrik een motie in waarin de regering wordt verzocht ervoor te zorgen dat zo spoedig mogelijk, doch uiterlijk op 1 januari 2009, alle door de publieke en semipublieke sector gebruikte software aan open standaarden voldoet en dus alle e-overheidsvoorzieningen, zoals elektronische formulieren, gebaseerd zijn op open standaarden (Tweede Kamer, 2007). Deze Kamerleden vinden de uitvoering van de motie-Vendrik uit 2002 tot dan toe bedroevend. De ingediende motie wordt verworpen.

¹² Het Nederlands Taxonomie Project is een initiatief van het voormalig Ministerie van Justitie en Ministerie van Financiën, gericht op de vereenvoudiging van het elektronisch uitwisselen van financiële gegevens tussen ondernemingen en de Kamers van Koophandel (KvK’s), de Belastingdienst en het Centraal Bureau voor de Statistiek (CBS) door toepassing van XBRL in financiële rapportages. Dit project is opgevolgd door het Programma SBR (Standard Business Reporting).

In het najaar van 2007 ontvangt de Tweede Kamer van de ministers van EZ en van BZK het actieplan Nederland open in verbinding (NOiV). De doelstellingen van het programma OS&OSS uit 2003 worden opnieuw gelanceerd met acties van het NOiV voor een versnelde invoering vanaf medio 2008 (EZ, 2007). Het programmabureau NOiV wordt per januari 2008 ingericht in opdracht van de ministers van EZ en van BZK om de uitvoering van de actielijnen van het kabinet actief te ondersteunen. Ook zetten de ministers van EZ en van BZK voor de toepassing van open standaarden in op het zogenaamde «comply or explain and commit-regime», wat het volgende inhoudt:

Comply: Pas vastgestelde open standaarden toe bij ICT-opdrachten voor nieuw- of verbouw en contractverlenging van ICT.

Explain: Of leg uit dat je ze niet kunt gebruiken, waarbij de uitzonde- ringscriteria zijn:

• - 

  Voor de gewenste functionaliteit is geen open standaard beschikbaar.

• - 

  De open standaard wordt niet door meerdere leveranciers en op meerdere platforms ondersteund.

• - 

  De bedrijfsvoering en/of dienstverlening komen op onaanvaardbare wijze in gevaar, inclusief beveiligingsrisico’s.

• - 

  Internationaal gemaakte afspraken worden geschonden. Commit Geef het voornemen aan om open standaarden toe te passen zodra een uitzonderingscriterium niet meer van toepassing is.

Dit regime moet vanaf april 2008 gaan gelden voor een basislijst met open standaarden die wordt opgesteld door het Forum standaardisatie per januari 2008. In het hernieuwde Instellingsbesluit voor het College en het Forum standaardisatie uit2010 staat niet expliciet beschreven of en door wie de basislijst met open standaarden wordt vastgesteld.

Begin 2008 vindt er in de Tweede Kamer een spoeddebat plaats over de aanbesteding van het project Gezamenlijke ontwikkeling uniforme rijksdesktop (GOUD). Uit de contra-expertise bij het aanbestedingstraject blijkt dat niet al het mogelijke in het werk is gesteld om invulling te geven aan de wensen van de Tweede Kamer en de toezegging van de staatssecretaris van EZ over het gebruik van open standaarden en opensource-software (Financiën, 2008a). De Tweede Kamer neemt een aantal moties aan, waaronder de motie van Kamerlid Aptroot (Tweede Kamer, 2008a) en de motie van het Kamerlid Vos (Tweede Kamer, 2008b). In de motie-Aptroot wordt gevraagd de aanbesteding te heroverwegen en in de motie-Vos wordt gevraagd bij de overheidsaanbestedingen nadrukkelijker te eisen dat open standaarden worden gebruikt. In reactie op deze moties geeft het kabinet aan dat alle open standaarden in het aanbestedingsdocument, daar waar dat nog niet het geval was, van wensen worden omgezet in eisen (Financiën, 2008b).

¹³ IPv6 staat voor Internet Protocol versie 6 en is de opvolger van versie 4 (IPv4). IPv6 is in gebruik genomen met name vanwege het dreigende tekort aan beschikbare IP-adressen. Een IP-adres is een uniek identificeerbaar internetadres voor een computer die is aangesloten op het internet of een netwerk. IPv4 en IPv6 zijn beide open standaarden.

Op 23 november 2008 wordt de Instructie rijksdienst bij aanschaf ICT-diensten of ICT-producten van kracht. De bijlage bij deze instructie stelt in artikel 3 het «comply or explain and commit»-principe verplicht en bepaalt in artikel 4 dat over de mate van naleving van dat principe verantwoording wordt afgelegd in de toelichting bij het departementaal jaarverslag bij de informatie over de bedrijfsvoering.

In 2010 neemt de Tweede Kamer een motie aan om over te schakelen op de IPv6-standaard¹³ (Tweede Kamer, 2010d) en bespreekt een voorstel voor een onderzoek door de Algemene Rekenkamer (Tweede Kamer, 2010a). Dat voorstel leidt tot de motie-Gerkens c.s. en het verzoek dat de aanleiding vorm voor ons onderzoek.

Ook wordt in 2010 de tweede voortgangsrapportage NOiV aangeboden aan de Tweede Kamer (EZ, 2010). Deze rapportage herhaalt de voortgang die in 2009 al werd vermeld. Zo wordt gerapporteerd dat er meer dan 200 verschillende pakketen opensourcesoftware in gebruik zijn. Als knelpunt wordt onder andere genoemd dat lang niet elke door de overheid gevraagde functionaliteit in opensourcesoftware beschikbaar is. Ook meldt de rapportage de ervaringen van gebruikers dat de totale kosten van een opensourceoplossing vaak hoog zijn door de kosten van de benodigde expertise bij installatie, transitie, documentatie, implementatie, ondersteuning en beheer van de software.

3 HET VRAAGSTUK «OPEN»

Open standaarden en opensourcesoftware zijn onderwerpen waarover, buiten een relatief kleine groep van personen die hier professioneel mee bezig is, veel onduidelijkheden en misverstanden bestaan. In dit hoofdstuk gaan we in op deze begrippen en leggen we de relatie tussen deze begrippen en de kosten die zijn verbonden aan software. Met het uiteenzetten van de begrippen «open standaarden» en «open-sourcesoftware», beantwoorden we voor een belangrijk deel de vragen van de Tweede Kamer. Omdat uit de vraagstelling van de Tweede Kamer de wens spreekt dat de overheid meer gebruik gaat maken van open technologie, besteden we in dit hoofdstuk vooral ook aandacht aan de vraag of en zo ja welke voordelen daaraan verbonden zijn.

In bijlage 4 van dit rapport staat de definitie van een open standaard volgens het Forum standaardisatie. In bijlage 5 is de definitie opgenomen die het Open Source Initiative (OSI) hanteert voor opensourcesoftware.

3.1 ICT bij het Rijk

¹⁴  Ministeries wisselen bijvoorbeeld niet alleen onderling gegevens uit maar ook met tal van andere organisaties. Verder hebben veel ministeries (delen van) hun ICT uitbesteed bij een externe commerciële dienstverlener en zijn er ontwikkelingen gaande in de richting van gezamenlijke ICT-voorzieningen voor alle ministeries.

¹⁵  ERP-pakketten zijn softwarepakketten met een sterk geïntegreerde functionaliteit waarmee in principe de gehele bedrijfsvoering kan worden ondersteund. Met een dergelijk systeem is het eenvoudiger om financiële middelen in verband te brengen met andere bedrijfsvoeringsaspecten dan met ‘losse’ systemen. ERP staat voor Enterprise Resource Planning.

ICT is onmisbaar voor het functioneren van vrijwel elke organisatie en ook voor de rijksoverheid. In eerder onderzoek gaven we al aan dat ICT niet meer alleen ondersteunend is, maar »de overheid in het hart raakt» (Algemene Rekenkamer, 2010a). ICT kan niet op zichzelf worden beschouwd maar moet in samenhang worden gezien met de bedrijfsprocessen van de overheid, zie figuur 3 op de volgende bladzijde.

De figuur toont in een sterk vereenvoudigde weergave¹⁴ twee ministeries die voor de uitvoering van hun bedrijfsprocessen een informatiehuishouding hebben ingericht. De ICT die de informatiehuishouding ondersteunt is gelaagd opgebouwd. Elk van deze lagen bevat hardware en software. De bovenste laag bevat de applicaties die in gebruik zijn bij specifieke onderdelen van een ministerie. Te denken valt aan beleidsinformatiesystemen en subsidiesystemen. De laag daaronder bevat applicaties die departementsbreed worden gebruikt. Hierbij gaat het bijvoorbeeld om kantoorautomatisering (zoals tekstverwerking, spreadsheets en e-mail), bedrijfsvoeringssystemen (zoals ERP-pakketten¹⁵ en HRM-systemen), systemen voor workflowmanagement en systemen voor beheer van documenten en contentmanagementsystemen voor websites. De lagen daaronder vormen de technische infrastructuur van software en hardware die nodig is om de applicaties te laten functioneren. Het gaat hierbij om de systeemsoftware (besturingssystemen, databasemanagementsystemen en software die de opslag van gegevens verzorgt), de hard-warelaag (netwerkservers en werkplekcomputers), en de netwerkinfrastructuur (de schakelpunten en de bekabeling). Omdat de eindgebruikers van de ICT-voorzieningen deze onderste drie lagen niet zien, duiden we ze in dit rapport aan als «onder de motorkap». Alle software bij elkaar duiden we in aan als het «softwarelandschap».

Figuur 3 ICT in samenhang met de bedrijfsprocessen van de overheid

Tabel 1 geeft een globale indeling in een aantal categorieën software die relevant zijn voor de rijksoverheid met enkele voorbeelden.

Tabel 1 Categorieën software met enkele voorbeelden

Categorie

Omschrijving

Voorbeelden

Kantoorautomatisering

Software voor de gemiddelde eindgebruiker, ook wel bekend als de «desktop»-applicaties

E-mail

Tekstverwerking Spreadsheets Documentmanagement

Specifieke eindgebruikersapplicaties

Applicaties voor beleidsdirecties en voor ondersteunende afdelingen

Beleidsinformatiesystemen Subsidiesystemen Geografische informatiesystemen Financiële systemen

HRM-systemen¹

ERP-pakketten

Software voor websites en intranetten²

Software voor de interne en externe communicatie

– Webservers³

– Applicaties voor web-contentmanagement – Applicaties voor webontwikkeling – Webbrowsers

Technische informatiesystemen

Systemen die ingebouwd zijn in technische apparatuur

Systemen voor wegsignalering Flitspalen met nummerplaatherkenning Besturing van waterwerken Tarifering openbaar vervoer (OV-chipkaart)

ICT-infrastructuur en ontwikkel- en beheersoftware

Software voor de ICT-afdelingen

– Besturingssystemen

– Databasemanagementsystemen

– Tools voor netwerkbeheer

– Applicatieservers⁴

– Fileservers

– Beveiligingssoftware

– Applicaties en tools voor softwareontwikkeling

¹  HRM: Human Resource Management.

²  Een intranet is de interne variant van een externe website.

³  Webservers verzorgen het intra- en internetverkeer.

⁴  Een applicatieserver is een voorziening, bestaande uit software en hardware, die de applicaties ter beschikking van de eindgebruiker stelt.

Tussen de onderdelen van het softwarelandschap bestaan tal van samenhangen. Om hier een idee van te geven laten we als voorbeeld in figuur 4 (op de volgende bladzijde) zien welke onderdelen van het softwarelandschap met elkaar moeten samenwerken bij de uitvoering van een eenvoudig proces binnen de rijksoverheid: een werknemer van ministerie A maakt een document dat vervolgens verwerkt wordt door een werknemer van ministerie B.

Figuur 4 Onderdelen van het softwarelandschap die betrokken zijn bij een eenvoudig proces

Uit dit voorbeeld blijkt dat zelfs bij een eenvoudig proces reeds een groot aantal applicaties en systeemprogramma’s betrokken zijn, die met elkaar moeten samenwerken voor het beoogde resultaat. Om te kunnen samenwerken moeten die applicaties en systeemprogramma’s elkaars gegevens kunnen verwerken. Hier zijn technische afspraken voor nodig, ofwel technische standaarden (zie § 3.2.2).

Het softwarelandschap van ministeries is dus bijzonder complex en het is niet zonder meer mogelijk om één van de onderdelen van het software-landschap te vervangen. Er moet immers altijd rekening worden gehouden met de plaats van het onderdeel in het totale softwareland-schap van het ministerie en de relaties die het heeft met andere software-onderdelen en de technische standaarden die ervoor zorgen dat die onderdelen op elkaar aansluiten.

3.2 Open en gesloten standaarden

Een standaard is niet meer en niet minder dan een verzameling afspraken. Een voorbeeld van een standaard uit de fysieke wereld is het internationale maatstelsel¹⁶ waardoor overal ter wereld precies hetzelfde wordt verstaan onder bepaalde maten: een meter, bijvoorbeeld, is overal even lang.

Standaarden in de softwarewereld zorgen ervoor dat applicaties of andere softwarecomponenten elkaars gegevens volledig en correct kunnen verwerken. Dit maakt communicatie tussen systemen mogelijk.

3.2.1 Onderscheid tussen gesloten en open

Standaarden kunnen gesloten zijn of open. Een gesloten standaard is een standaard die is vastgesteld en wordt onderhouden door een natuurlijke persoon of een rechtspersoon - meestal een bedrijf of een groep bedrijven. Standaarden vallen niet onder de bescherming van de auteurswet. Daarom wordt het octrooirecht ingezet om het gebruik van de standaard te regelen en er inkomsten uit te verkrijgen. Veel gesloten standaarden, maar vooral de gesloten technische standaarden, bevatten daarom onderdelen die octrooirechtelijk beschermd zijn. De GSM-standaard voor mobiele telefonie maakt bijvoorbeeld gebruik van ongeveer 2000 octrooien die in het bezit zijn van ongeveer twintig bedrijven (Paapst 2010). Het bezit van het octrooirecht vertegenwoordigt een waarde die in de vorm van royalty’s wordt doorberekend in de hardware en software waarin de standaard wordt toegepast. De consument betaalt er dus voor.

TIFF is een voorbeeld van een deels gesloten standaard voor de weergave van grafische documenten en op het gebied van multimedia (beeld en geluid) is het formaat MPEG-4 een bekend voorbeeld van een gesloten standaard (zie kader verderop).

Aan open standaarden zijn of geen octrooirechten verbonden of de octrooirechten worden ter beschikking gesteld zonder dat de gebruiker royalty’s verschuldigd is. Dat laatste gebeurt onder bepaalde voorwaarden. Een voorbeeld is de RTLinuxFree Open Patent License1⁷, die een bepaald octrooi zonder royalty’s beschikbaar stelt mits het octrooi wordt gebruikt in opensourcesoftware.¹⁸ Andere kenmerken van een open standaard zijn:

hij wordt onderhouden door een non-profitorganisatie;

de beschrijving van de standaard is publiekelijk beschikbaar en mag vrij gebruikt worden.

¹⁶  Système International d’Unités.

¹⁷  Zie RTLinux (2007). Het betreft een octrooi dat het open source besturingssysteem Linux geschikt maakt voor gebruik in «real-time» (dus tijd-kritische) omgevingen, zoals de procesindustrie en de luchtvaart.

¹⁸  Om precies te zijn: indien de software beschikbaar wordt gesteld onder de GPL licentievorm, een licentievorm met copyleft-bepaling, zie hiervoor § 3.3.2.

¹⁹  Het W3C Consortium telt ongeveer 330 deelnemende bedrijven en andere organisaties, zoals universiteiten. Het consortium ontwikkelt en beheert webstandaarden en heeft momenteel ruim 650 (concept-)stan-daarden in beheer.

²⁰  XBRL is gebaseerd op XML (zie hierna).

Bekende voorbeelden van open standaarden zijn:

Hypertext Markup Language (HTML) en Cascading Stylesheets (CSS)

van het W3C Consortium¹⁹ voor de structurering van inhoud,

respectievelijk de vormgeving van webpagina’s;

eXtensible Business Reporting Language (XBRL)²⁰ voor de uitwisseling van financiële gegevens en andere bedrijfsgegevens via internet;

Open Document Format (ODF) voor de uitwisseling van reviseerbare documenten;

Portable Document Format Archive (PDF/A) voor de uitwisseling van niet-reviseerbare documenten.

Voorbeelden van gesloten standaarden en hun open tegenhangers

Uitwisselingsformaten Octrooicentrum Nederland Ook in het proces van het aanvragen van octrooien wordt gebruikgemaakt van open en van gesloten standaarden. De «Uitvoeringsregeling 2009 Rijksoctrooiwet 1995» noemt drie standaarden voor het formaat waarin bestanden mogen worden aangeleverd, te weten PDF, TIFF en JPEG. Als degene die een octrooi aanvraagt een van deze drie standaarden gebruikt kan hij of zij er dus vanuit gaan dat het Octrooicentrum Nederland zijn aanvraag kan lezen. TIFF is een deels gesloten standaard van het bedrijf Adobe. PDF en JPEG daarentegen zijn open standaarden.

Multimediaformaten

MPEG-4²¹ is een gesloten standaard voor opslag en transport van multimedia (beeld en geluid, bijvoorbeeld video). Aan deze standaard zijn ruim 1 000 octrooien verbonden van ruim 25 partijen, waaronder bedrijven als Philips, Mitsubishi en Sony. Deze partijen hebben hun belangen ondergebracht in het bedrijf MPEG LA, LLC²². Dit bedrijf biedt bedrijven die de standaard gebruiken de octrooien aan als een «patent pool».

Een van de open tegenhangers van MPEG-4 is het formaat OGG. Dit is een open standaard voor audio en video, die vrijelijk gebruikt kan worden zonder de beperkingen van softwareoctrooien. OGG wordt beheerd door de Xiph.Org Foundation²³, een non-profitorganisatie die open multimedia bestandsformaten en software ontwikkelt.

Open en gesloten standaarden zoals we ze hierboven onderscheiden hebben zijn uitersten. De praktijk is veel complexer:er bestaan vele tussenvarianten en mengvormen. Een voorbeeld is het OOXML documentformaat van Microsoft (ook wel docx genoemd). Dit formaat is gespecificeerd op basis van de open gestandaardiseerde «taal» XML²⁴ en is vrij beschikbaar. Het formaat kent echter ook eigen (gesloten) standaarden van Microsoft, bijvoorbeeld voor het gebruik van wiskundige formules en vector graphics,²⁵ en maakt geen gebruik van de open standaarden die daar al voor bestaan (namelijk MathML respectievelijk SVG).

3.2.2 Interoperabiliteit

Standaarden maken samenwerking mogelijk binnen en tussen organisaties. Bij software heet deze samenwerking «interoperabiliteit».

²¹ Deze standaard is verwant aan het bekende MP3-formaat voor audio.

²²  www.mpegla.com

²³ www.xiph.org

²⁴  De XML-standaard bestaat uit een verzameling regels die men kan gebruiken om data volgens een eenduidige systematiek te beschrijven, zodat applicaties de data correct kunnen verwerken.

²⁵  Onder vector graphics wordt een verzameling technieken verstaan die bepaalde applicaties gebruiken voor de representatie van beeldmateriaal, zoals technische tekeningen.

Het is gangbaar om de volgende drie niveaus van interoperabiliteit te onderscheiden:

organisatorische interoperabiliteit;

semantische interoperabiliteit;

technische interoperabiliteit.

Organisatorische standaardisatie vraagt in het algemeen om een nadere concretisering in de vorm van semantische standaarden en deze vragen op hun beurt om standaardisering op technisch niveau.

Organisatorische interoperabiliteit

Organisatorische interoperabiliteit betekent dat organisaties in staat zijn om efficiënt en effectief met elkaar samen te werken. Dit wordt mogelijk gemaakt door de relevante processen van de organisaties in de sector goed op elkaar af te stemmen. De voordelen die met het invoeren van een organisatorische standaard gerealiseerd kunnen worden, zijn veelal organisatieoverstijgend en hebben betrekking op bijvoorbeeld een maatschappelijke sector. Zo zijn er in het kader van een doelmatigere verwerking van huisafval bijvoorbeeld afspraken gemaakt tussen de afvalverwerkingsbedrijven van een aantal gemeenten over zaken zoals waar de gegevens voor de afvalheffing²⁶ worden opgeslagen, wie het beheer erover heeft, hoe de toegang tot die gegevens geregeld is, en welke regels worden toegepast voor de privacybescherming van burgers.

Semantische interoperabiliteit

Semantische interoperabiliteit houdt in dat organisaties informatie van elkaar kunnen verwerken. Hiervoor is semantische standaardisatie nodig, die ervoor zorgt dat de precieze betekenis van de uitgewisselde informatie door alle partijen op dezelfde manier wordt begrepen. Voorbeeld: hoe definiëren we het begrip «persoon». Doen we dat aan de hand van de combinatie geslachtsnaam, voorvoegsels, voorletters, en geboortedatum? Of gebruiken we het Burgerservicenummer? Of het A-nummer?²⁷

²⁶  Het gaat hierbij om gegevens zoals het aantal afvalaanbiedingen per huishouding, het containervolume, het containergewicht of een combinatie daarvan.

²⁷  Burgerservicenummer (het voormalige Sofinummer): het persoonsnummer dat wordt gebruikt in de uitvoering van sociale zekerheids- en fiscale wetgeving. A-nummer: het persoonsnummer dat gebruikt wordt door de gemeentelijke basisadministraties.

²⁸  Deze afkorting staat voor «Transmission Control Protocol/Internet Protocol». Ontwikkeling en onderhoud van de TCP/IP-standaarden worden gefinancierd door The Internet Engineering Task Force (IETF). Dit is een non-profitorganisatie met 90 institutionele leden (bedrijven en andere organisaties) en 26 000 individuele leden (www.ietf.org).

²⁹ Bron: Forum Standaardisatie, http://www.open-standaarden.nl/actueel/ nieuws-en-persberichten. Zie nieuwsbericht 4 november 2010.

Technische interoperabiliteit

Technische interoperabiliteithoudt in datsoftwarecomponenten met elkaar kunnen samenwerken, met elkaar kunnen «praten». Technische standaarden maken dit mogelijk. Voorbeelden zijn standaarden voor de uitwisseling van opgemaakte tekst (denk aan de gesloten standaarden uit de Microsoft Office suite die zijn uitgekomen voorafgaand aan de versie Office 2007 (.doc), de niet volledig open standaard OOXML en de open standaard ODF, en de open webstandaarden van het w3c-consortium). Bij middleware (de laag software tussen de toepassingslaag en de besturingslaag) zijn veel standaarden te vinden die bedoeld zijn voor de technische interoperabiliteit. Een voorbeeld is de «TCP/IP-stack»,²⁸ een verzameling standaarden die het mogelijk maakt dat applicaties gegevens uitwisselen via een datacommunicatieverbinding. Deze standaard is oorspronkelijk ontwikkeld voor internetverkeer, maar is uitgegroeid tot de meest gebruikte standaard voor netwerkverkeer en wordt bijvoorbeeld ook gebruikt voor de interne netwerken van organisaties. In onderstaand kader staat een voorbeeld van een standaard die wordt ingevoerd om de interoperabiliteit te bevorderen.

De Aquo-standaard

De Aquo-standaard is een semantische standaard die als doel heeft dat alle waterbeherende overheden hun gegevens op eenzelfde manier registreren. De standaard maakt het mogelijk om op een uniforme wijze meetgegevens en analyses uit te wisselen tussen de partijen die betrokken zijn bij het waterbeheer, zoals waterschappen, provincies en Rijkswaterstaat. Onderdelen van de AQUO standaard die gericht zijn op de uitwisseling van geografische gegevens en meetgegevens zijn in overeenstemming met de Europese INSPIRE richtlijn waardoor informatie eenvoudiger Europees gedeeld kan worden. Op 4 november 2010 werd de Aquo-standaard toegevoegd aan de «pas toe of leg uit-lijst» voor open standaarden van het

College Standaardisatie.²⁹

3.2.3 Vaak genoemde voordelen van open standaarden

In algemene zin kan niet worden gesteld dat open standaarden beter zijn dan gesloten standaarden of andersom. Wel worden er aan open standaarden doorgaans een aantal voordelen toegeschreven. Hierbij gaat het vooral om kwaliteit, kostenbesparing, leveranciersonafhankelijkheid en duurzaamheid. In deze paragraaf bespreken wij deze potentiële voordelen en de daaraan ten grondslag liggende veronderstellingen. Omdat er geen bewijsvoering is voor de algemene geldigheid van de genoemde voordelen, spreken wij ons niet uit over de vraag of de genoemde voordelen reëel zijn. In de business cases die wij hebben bestudeerd wordt niet altijd expliciet benoemd op basis van welke criteria gekozen wordt voor open standaarden boven gesloten standaarden. Hierdoor is het ook niet duidelijk of de hierna genoemde voordelen een rol gespeeld hebben.

Kwaliteit standaarden

Wanneer een standaard in een open proces tot stand komt, zijn alle bekende of onbekende partijen die belang hebben bij de samenwerking in de gelegenheid om vanuit hun specifieke belang mee te sturen in het standaardisatieproces. Dat vergroot in theorie de kans dat alle relevante belangen worden meegewogen. Dit veronderstelde voordeel wordt vaak verwoord met de uitspraak «open standaarden hebben een hogere kwaliteit». Wij hebben geen onderbouwing voor die uitspraak, of voor het tegendeel, gevonden. Standaardisatie als open proces kan bijdragen aan de kwaliteit, maar vormt er volgens ons geen garantie voor. Of en in hoeverre sprake is van een hogere kwaliteit is afhankelijk van de situatie en moet van geval tot geval worden bezien.

Kostenbesparing

Open standaarden kunnen worden gebruikt zonder kosten die direct zijn verbonden aan eventuele octrooien die in de standaard zijn opgenomen. Aan het gebruik van gesloten standaarden zijn deze kosten in het algemeen wel verbonden. Als voorbeeld noemen we royalty’s die moeten worden afgedragen om een standaard te mogen implementeren in een applicatie, zie tekstkader hieronder. Ook kan het zijn dat er andere vergoedingen moeten worden betaald, bijvoorbeeld een vergoeding per transactie bij betalingen.

Royalty’s en andere vergoedingen zijn echter niet de enige kosten die verbonden zijn aan standaarden. Het implementeren, onderhouden en ondersteunen van een standaard brengt namelijk ook kosten met zich mee, ongeacht of die standaard open of gesloten is. Of en in welke mate per saldo sprake is van kostenbesparing door het gebruik van open standaarden, zal afhangen van de situatie en moet van geval tot geval worden bezien.

Voorbeeld royalty’s bij gesloten standaarden

³⁰ De community Mozilla en het bedrijf Opera zijn twee producenten van onder meer webbrowsers (Firefox, respectievelijk Opera), waarbij de eerste opensourcesoftware is en de tweede gesloten. Beide zijn gratis. Wikipedia is een internetencyclopedie, die gebaseerd is op de opensourcesoftware MediaWiki.

MPEG-4 is een gesloten standaard voor opslag en transport van multimedia (zie § 3.2.1). Vanwege de royalty’s en voorwaarden zijn er verschillende partijen, waaronder Mozilla, Opera en Wikipedia³⁰, die geen gebruik willen maken van MPEG-4. Mozilla schat dat het jaarlijks ongeveer € 4 miljoen aan royalty’s zou moeten uitkeren, maar noemt ook als bezwaar dat de voorwaarden en royalty’s drempels opwerpen voor innovatie en hergebruik (NOiV, 2010).

Leveranciersonafhankelijkheid

Open standaarden maken het de gebruiker gemakkelijker om over te stappen op een andere producent met een ander softwareproduct, bijvoorbeeld omdat het product beter aan zijn eisen voldoet of omdat het goedkoper is, dan wel omdat er betere service bij wordt verleend. Gesloten standaarden brengen in een aantal gevallen met zich mee dat de softwaregebruiker min of meer wordt gedwongen om meerdere applicaties van dezelfde producent te gebruiken. Men spreekt hierbij van een vendor lock-in. Wie bijvoorbeeld gebruikmaakt van MS Word als tekstverwerker zou in principe kunnen kiezen voor een spreadsheet van een andere softwareproducent. Doorgaans kiest de gebruiker echter voor het product van dezelfde producent, MS Excel in dit geval, omdat het uitwisselen van gegevens dan op de minste problemen stuit.

Duurzaamheid

Het gebruik van open standaarden maakt het waarschijnlijker dat de data ook in de toekomst bruikbaar zullen zijn. Elke (versie van een) applicatie wordt namelijk slechts gedurende een bepaalde tijd ondersteund door de producent. Bovendien stappen organisaties ook uit eigen beweging over van de ene applicatie op de andere. Als de oude applicatie gebaseerd is op een gesloten standaard is het de leverancier die bepaalt of data die bij een bepaalde applicatie horen ook in de toekomst nog bruikbaar zullen zijn. In het geval van een open standaard is de softwaregebruiker in beginsel niet afhankelijk van de specifieke leverancier van de software en dit kan zorgen voor betere waarborging van de duurzame beschikbaarheid van data die bij die applicatie horen.

Overigens bestaat er ook bij het gebruik van open standaarden afhankelijkheid: de gebruiker is afhankelijk van de organisatie of de community die de standaard onderhoudt. En ook bij een gesloten standaard kan het onderhouden van de standaard in principe worden overgenomen door anderen, bijvoorbeeld als de initiële leverancier de standaard niet langer kan of wil onderhouden.

3.3 Opensourcesoftware en closedsourcesoftware

Opensourcesoftwarezijn computerprogramma’s waarvan de gebruiker de broncode kan inzien en veranderen. Dit in tegenstelling tot closedsource-software, waarbij de gebruiker niet het recht op inzage van de broncode heeft en voor aanpassingen van de software en koppelingen naar andere computerprogramma’s gebonden is aan de originele leverancier. Een ander kenmerk van opensourcesoftware is dat het wordt geproduceerd door een community, een vaak niet formeel georganiseerde groep programmeurs die samen aan een softwareproject werken, en niet door een bedrijf zoals het geval is bij closedsourcesoftware.

3.3.1 Diffuus onderscheid: vele mengvormen

Net als open en gesloten standaarden kennen ook opensourcesoftware en closedsourcesoftware vele mengvormen. Zo bevat bijvoorbeeld steeds meer closedsourcesoftware onderdelen waarvan de broncode open is en de verwachting is dat in 2012 ongeveer 80% van de commerciële software gebruikt maakt van opensourcetechnologie (Gartner, 2008). En ook aan de productiekant is het onderscheid niet zwart–wit. We zien vaak samenwerkingsverbanden tussen community’s en bedrijven en er zijn community’s die financieel of door programmeerwerk worden ondersteund door een of meer bedrijven.

Casadesus-Masanell en Llanes (2010) maken onderscheid tussen de basisfunctionaliteit van een programma en de functionele extra’s. Men kan hierbij denken aan een programma dat als basisfunctionaliteit e-mailverkeer en agendabeheer biedt. Functionele extra’s zijn dan bijvoorbeeld geavanceerde zoekfuncties voor de mailbox en synchronisatie van de mailbox en agenda met een smartphone.³¹ Zowel de basisfunctionaliteit als de functionele extra’s kunnen open of gesloten zijn. Casadesus-Masanell en Llanes komen zo op vier typen software (zie tabel 2): een volledig open variant (opensource, kwadrant linksboven), een volledig gesloten (proprietary, kwadrant rechtsonder) en twee mengvormen. Bij de ene mengvorm (open core, kwadrant rechtsboven) is de basisfunctionaliteit opensource en zijn de functionele extra’s gesloten, terwijl bij de andere mengvorm (open edge, kwadrant linksonder) het omgekeerde het geval is: basisfunctionaliteit gesloten en extra’s open. Elk van de kwadranten in tabel 2 bevat enkele voorbeelden.³²

Tabel 2 Opensourcesoftware en closedsourcesoftware en twee mengvormen

Extensions

Open

Closed

Open Open source

– My SQL – Red Hat Linux – Open Solaris – Eclipse

Open core

– Sugar CRM – JasperSoft – Zimbra – Mac Os X

Base

Closed Open edge

– MSFT.Net – Stata

– Mathematica – Facebook

Proprietary

– MS Windows – MS Office – Oracle 11 g – SAP

Bron: Casadesus-Masanell en Llanes (2010)

Een andere mengvorm is «dual licensing» (zie § 3.3.2).

³¹  Een smartphone is een mobiele telefoon met internettoegang en applicaties voor bijvoorbeeld mailverkeer en agendabeheer. Voorbeelden zijn de Blackberry van het bedrijf Research in Motion of de iPhone van Apple.

³²  MySQL en Oracle 11g zijn databasemanagementsystemen, Red Hat Linux, Open Solaris, Mac OSX en MS (Microsoft) Windows zijn besturingssystemen. MSFT (Micro-soft).Net en Eclipse zijn hulpmiddelen voor softwareontwikkeling. Stata en Mathematica zijn wiskundige programma’s (voor statistische respectievelijk technische berekeningen). SugerCRM is een programma voor klantbeheer. Jaspersoft is een programma dat rapportages genereert uit databasegegevens. Zimbra is software voor e-mail en agendabeheer. Facebook is de software die de gelijknamige social media website gebruikt. MS Office is de Microsoft suite van kantoorapplicaties. SAP is een ERP-pakket.

³³  ECM komt kort gezegd neer op beheer en beschikbaarstelling van de in de organisatie aanwezige verzameling aan ongestructureerde informatie zoals documenten en andere vormen van content, waaronder videomateriaal.

Marktpartijen kunnen optreden als financier van community’s. Een voorbeeld hiervan is te vinden in het onderstaande tekstkader.

Voorbeeld van financiële verwevenheid community-bedrijfsleven

Het Amerikaanse Alfresco levert het «enterprise contentmanage-mentsysteem» (ECM)³³. Een van de oprichters van Alfresco in 2005 was de voormalige Chief Operations Officer (en medeoprichter) van het bedrijf Business Objects, dat in 2007 is overgenomen door SAP AG, de producent van het ERP-pakket SAP. Een dochtermaatschappij van SAP AG, SAP Ventures, ismedefinancier van Alfresco. Wat de precieze overwegingen hiervoor zijn is ons niet bekend, maar in het algemeen komen dergelijke verwevenheden voort uit wederzijds belang. De Alfresco-community kan een hogere productie leveren en het bedrijf Alfresco kan mede richting geven aan de ontwikkeling van een opensourceproduct dat wellicht in de toekomst (ook) in commerciële vorm op de markt kan worden gebracht (zie ook tekstkader «Dual licensing» in § 3.3.2).

3.3.2 Softwarelicenties

Op basis van de Auteurswet berusten de auteursrechten van software bij de maker ervan.³⁴ De maker kan anderen het recht op gebruik van de software toekennen.³⁵ Dat gebeurt in een licentieovereenkomst, kortweg: licentie. De softwarelicentie regelt hoe de koper software mag gebruiken. De licentie draagt niet het eigendomsrecht van de software over, maar geeft de koper het niet-exclusieve recht³⁶ op het gebruik van de software. Dat gebruik is gebonden aan de voorwaarden uit de licentieovereenkomst.

Licenties voor closedsourcesoftware

Bij closedsourcesoftware bepalen de licentievoorwaarden in het algemeen dat het verboden is om kopieën van de software te maken (behoudens een backup voor eigen gebruik),³⁷ dat de licentie niet mag worden doorverkocht, dat het gebruik van de software beperkt is tot een bepaald aantal computers dan wel (gelijktijdige) gebruikers en dat «reverse engineering»³⁸ niet is toegestaan. Het is gebruikelijk om in de licentieovereenkomst de aansprakelijkheid van de softwareproducent voor gebreken aan het product of gevolgschade te beperken of uit te sluiten.

³⁴  Artikel 1 en artikel 10, lid 1, punt 12.

³⁵  Artikel 12, lid 3 in samenhang met lid 2.

³⁶  Dat wil zeggen dat de softwareproducent de licentie ook aan anderen mag verkopen.

³⁷  De Auteurswet beschouwt het maken van een reservekopie niet als een inbreuk op het auteursrecht (artikel 45k). De Europese Softwarerichtlijn (artikel 5 lid 2) bepaalt dat het maken van een (noodzakelijke) reservekopie door een rechtmatige gebruiker van het programma niet bij overeenkomst kan worden verhinderd.

³⁸  Reverse engineering is het afleiden van de broncode uit de gecompileerde versie van een computerprogramma. De Auteurswet staat reverse egnineering overigens toe als dat gebeurt om interoperabiliteit tussen programma’s te bereiken. Dat geldt alleen als de informatie die voor interoperabiliteit nodig is niet «reeds langs andere weg snel en gemakkelijk beschikbaar» is (Auteurswet, art. 45m, lid 1b).

³⁹  De licentie kan dus aan verschillende personen worden verkocht.

⁴⁰  Voorbeelden van veelgebruikte licentievormen met een (sterke) copyleft-bepaling zijn: GNU General Public License (GPL) en Affero GNU Public License (AGPL). Voorbeelden van licentievormen die geen copyleft-bepaling of een zwakke copyleft-bepaling bevatten zijn: Lesser GNU General Public License (LGPL), Berkeley Software Distribution License (BSD), Apache Licence en Mozilla Public License (MPL).

Licenties voor opensourcesoftware

De drie kernprincipes van opensourcesoftware zijn dat opensourceli-centies de gebruiker het recht geeft (Laurent, 2004):

• 1. 

  de software niet-exclusief³⁹ te gebruiken, al dan niet commercieel – het laatste overigens afhankelijk van de specifieke licentievorm, zie hierna;

• 2. 

  de broncode van de software gratis te gebruiken;

• 3. 

  de broncode aan te passen en nieuwe broncode te produceren die gebaseerd is op de in licentie gegeven broncode.

Het komt erop neer dat een opensourcelicentie de gebruiker het recht geeft om de broncode te gebruiken, te kopiëren, aan te passen en te verspreiden – hetzij in originele hetzij in aangepaste vorm. Dit recht geldt in elk geval voor niet-commercieel gebruik en (afhankelijk van de licentievorm) vaak ook voor commercieel gebruik van de software.

Een bedrijf kan inkomsten verkrijgen uit software die het gebouwd heeft met gebruikmaking van opensourcesoftware door de opensourcesoftware te combineren met closedsourcesoftware en het geheel als closedsource-software te verkopen. Sommige opensourcelicenties sluiten deze mogelijkheid uit met een «copyleft-bepaling». Deze bepaling verplicht de gebruiker om bij eventuele verspreiding van de gewijzigde broncode, al dan niet in combinatie met closedsourcesoftware, dit ook weer onder dezelfde licentie te doen. Bij licenties zonder copyleft-bepaling is het toegestaan om de broncode te wijzigen en eventueel te bundelen met gesloten broncode en het geheel vervolgens de status van closedsourcesoftware code te geven.⁴⁰

Europese standaard voor opensourcelicenties: EUPL

In opdracht van de Europese Commissie is de European Union Public License (EUPL) opgesteld. In eerste instantie was het doel daarbij om voor opensourcesoftware die in opdracht van de Europese Commissie werd en wordt gebouwd de gebruiksrechten bij de verdere verspreiding ervan te regelen. De EUPL-licentie is hiertoe vertaald in 22 van de 23 officiële talen van de lidstaten van de Europese Unie, waarbij er ook voor is gezorgd dat de vertaalde licentie in die landen rechtsgeldig is.⁴¹ Deze licentie kan dus worden toegepast bij opensourcesoftware die in opdracht van de rijksoverheid wordt gemaakt door een leverancier of in die huis wordt gebouwd.⁴² De licentie bevat een copyleft-bepaling.⁴³ Verder kent de EUPL bepalingen die garantie en aansprakelijkheid van de licentiegever expliciet uitsluiten. Daar voegt de licentie – strikt genomen overbodig – aan toe dat deze zaken aanvullend, in een aparte overeenkomst en tegen een tarief kunnen worden geregeld, evenals ondersteuning en advies. Daarbij bevat de licentie de opmerking dat het contractueel regelen van garantie en aansprakelijkheid met zich meebrengt dat de leverancier gehouden is tot vrijwaring van alle partijen in de productieketen van de broncode met betrekking tot aansprakelijkheid of vorderingen. Dit risico voor de leverancier zal, zo licht de EUPL toe, vanzelfsprekend ook tot uitdrukking komen in het tarief van de leverancier.

Dual licensing

Ook bij de licenties zien we een mengvorm tussen open en gesloten: dual licensing. Dit houdt in dat de software zowel gratis als in een betaalde versie wordt verspreid. De betaalde versie bevat dan bijvoorbeeld extra functionaliteit of heeft een gebruikersvriendelijke interface. Vaak biedt een bedrijf alleen bij de betaalde versie van de software de mogelijkheid van dienstverlening, bijvoorbeeld ondersteuning bij implementatie en een helpdeskfunctie. In § 3.3.4, over verdienmodellen van leveranciers, gaan we hier dieper op in.

Dual licensing

⁴¹  De EUPL is niet vertaald in het Gaelic, een van de twee officiële talen in Ierland.

⁴²  Bron: http://www.osor.eu/eupl.

⁴³  Wanneer op opensourcesoftware de copyleft-bepaling van toepassing is wordt de gebruiker verplicht om bij eventuele verspreiding van de gewijzigde broncode, al dan niet in combinatie met gesloten software, dit ook weer onder dezelfde licentie te doen.

⁴⁴  Bijvoorbeeld de Ubuntu-variant van het open source besturingssysteem Linux (alternatief voor MS Windows) en een reeks applicaties zoals OpenOffice (kantoorsoftware, alternatief voor MS Office), FireFox (internet-browser, alternatief voor MS Internet Explorer), Thunderbird (email, alternatief voor MS Outlook), GIMP (grafisch programma, alternatief voor Adobe Photoshop). Deze opensourcesoftware is in de vorm van broncode en als installeerbare programma’s gratis op internet beschikbaar.

⁴⁵  De reeks die we noemden voor de thuissituatie laat zich gemakkelijk aanvullen met bijvoorbeeld Apache (Webserver, alternatief voor MS Internet Information Services), Joomla! (beheer van web content, alternatief voor Green Valley of Tridion) en Compiere (ERP, een alternatief voor SAP of Oracle), et cetera.

Het Amerikaanse Alfresco levert het «enterprise contentmanage-mentsysteem» (ECM). Alfresco werkt daarbij metdual licensing. Dit houdt in dat Alfresco zijn software en als opensourcesoftware gratis ter beschikking stelt onder de naam Alfresco Community en gebundeld met eigen software verkoopt in de vorm van de gesloten versie Alfresco Enterprise. De licentie bij de opensourceversie maakt dit mogelijk, deze bevat namelijk geen «sterke» copyleft-bepaling. De commerciële versie bevat niet alleen extra functionaliteit maar wordt bovendien geleverd met aanvullende dienstverlening en zekerheden. Op het gebied van dienstverlening biedt het bedrijf bijvoorbeeld ondersteuning bij implementatie en hulp in geval van problemen. De extra zekerheden bestaan uit de mogelijkheid dienstverleningsovereenkomsten afsluiten met daarin afspraken over onder meer probleemoplossing en foutherstel (Alfresco, z.j.).

3.3.3 Softwarekosten

Vaak wordt verondersteld dat «open» ook betekent «gratis». Dat is echter niet het geval, omdat aan het gebruik van software altijd kosten zijn verbonden, zeker wanneer het gebruik een zakelijk karakter heeft.

In een thuissituatie kunnen mensen zelf vrij eenvoudig opensourceappli-caties en –besturingssystemen installeren.⁴⁴ Ook mensen die een klein bedrijf starten of een kleine tot middelgrote non-profitorganisatie komen ver met louter gratis opensourcesoftware.⁴⁵

Hierdoor kan gemakkelijk het idee postvatten dat opensourcesoftware «dus» gratis is. Dat is echter een misvatting. Bij opensourcesoftware is de licentie gratis, maar het op basis van de broncode vervaardigde product mag onder bepaalde licenties wel degelijk worden verkocht. Bovendien vormen de licentiekosten slechts een deel van de totale softwarekosten: er moet ook rekening worden gehouden met de kosten van implementatie, onderhoud en beheer van de gebruikte software. Bij een grote organisatie als een ministerie kost software altijd geld.

In deze paragraaf geven we een overzicht van de belangrijkste kosten die verbonden zijn aan het gebruik van software. We onderscheiden:

aanschafkosten (waaronder licentiekosten);

implementatiekosten;

exploitatiekosten (waaronder beheer);

onderhoudskosten. Deze kosten hebben zowel betrekking op opensourcesoftware als op closedsourcesoftware. Het belangrijkste verschil vormen de kosten van softwarelicenties (zie aanschafkosten), die in het geval van opensourcesoftware in beginsel nul zijn. Desondanks is opensourcesoftware niet per definitie de goedkopere variant.

Aanschafkosten

Hieronder vallen bij closedsourcesoftware hoofdzakelijk de kosten van softwarelicenties. Deze kosten zijn er in principe niet in het geval van opensourcesoftware. Dat betekent echter niet dat er geen aanschafkosten gemoeid zijn met opensourcesoftware. De broncode moet namelijk worden omgezet in een voor de organisatie bruikbaar computerprogramma. Dat kan de leverancier doen, wat leidt tot (zichtbare) externe kosten, maar het kan ook gebeuren door de eigen ICT-afdeling van de organisatie, waarmee (vaak onzichtbare) interne personeelskosten gemoeid zijn. Ook kost het geld om zekerheden te verkrijgen over zaken zoals betrouwbaarheid, informatiebeveiliging, de beschikbaarheid van periodieke updates en zekerheden omtrent het intellectuele eigendom.⁴⁶ Bij de vervanging van Windows door het opensourcebesturingssysteem Linux kan de organisatie bijvoorbeeld kiezen voor enterprise-versies. Deze worden geleverd door commerciële bedrijven die opensourcesoftware aanbieden en daar dienstverlening bij de verkopen. De extra zekerheden worden dan via de aanschafprijs in rekening gebracht.

De beschikbaarheid van periodieke updates wordt vaak geregeld in servicecontracten, zie exploitatiekosten. Vaak zal het beëindigen van de relatie met een leverancier ook uitstapkosten met zich meebrengen.

Zo kunnen de kosten oplopen doordat kortingen vervallen voor andere software van dezelfde leverancier (bij afname van licenties voor verschillende producten geven leveranciers vaak kortingen).

⁴⁶ Er vindt veel juridische strijd plaats over schendingen van het auteursrecht bij softwareontwikkeling. Dat is zowel bij closedsourcesoftware als bij opensource-software het geval. Opensourcesoftware komt echter relatief vaak onder vuur te liggen, wat niet zo verwonderlijk is omdat de broncode immers open is en eventuele schendingen dus eenvoudiger te ontdekken zijn en ook de bewijsvoering eenvoudiger is.

Implementatiekosten

Software moet vaak speciaal worden ingericht om optimaal bruikbaar te zijn in een specifieke situatie. Dit veroorzaakt – zowel bij opensource-software als bij closedsourcesoftware – eenmalige kosten bij de implementatie. Ook is het vaak nodig om bestanden die door de oude applicatie gemaakt zijn te converteren naar het technische opslagformaat van de nieuwe applicatie. Verder zijn er altijd verschillen tussen applicaties in de bediening ervan door eindgebruikers en het onderhoud door de ICT-afdeling, of door een externe dienstverlener in het geval van outsourcing. Dit betekent kosten voor opleiding en training van medewerkers. Deze kosten treden op bij elke overstap, dus bijvoorbeeld ook bij de overstap van de ene closedsource-applicatie op de andere. Wel kan de hoogte van de kosten van geval tot geval variëren.

Exploitatiekosten

De belangrijkste exploitatiekosten van opensourcesoftware zijn de kosten van servicecontracten. Deze contracten kunnen onder meer betrekking hebben op de levering van periodieke updates, gebruikersondersteuning en het oplossen van problemen.

Onderhoudskosten

Als nieuwe software (vaak maatwerk) een tijd gebruikt wordt, ontstaan als regel aanvullende wensen, bijvoorbeeld een nieuwe functionaliteit of het verbeteren van een bestaande functionaliteit. Deze aanpassingen zijn bij closedsourcesoftware vaak duur doordat de klant maar bij één partij terecht kan voor de aanpassingen, namelijk de producent van de software, die vaak de dominante aanbieder van dat type software is. Er is dan sprake van een zogenoemde vendor lock-in: de gebruiker wordt afhankelijk gemaakt van de producent doordat er veel kosten moeten worden gemaakt om te kunnen overstappen op software van een andere producent of opensourcesoftware met dezelfde functionaliteit.

Ook het tempo waarin de organisatie nieuwe versies van de software invoert wordt vaak sterk bepaald door de softwareproducent, die oudere versies slechts gedurende een beperkte tijd blijft ondersteunen.

3.3.4 Verdienmodellen van leveranciers

Software valt onder de auteursrechtelijke bescherming van de Auteurswet. Deze bescherming is geregeld in artikel 1, dat bepaalt dat het auteursrecht het uitsluitend recht is van de maker van een «werk» om dit openbaar te maken en te verveelvoudigen. Artikel 10 noemt «computerprogramma’s en het voorbereidend materiaal» als werken in de zin van de Auteurswet. Bedrijven die software ontwikkelen onder een geslotenlicentie, ontlenen «marktmacht» aan deze auteursrechtelijke bescherming. Deze bescherming geeft ze namelijk het exclusieve recht hun producten op de markt te brengen door hun auteursrechten te verkopen of hun producten onder licentie uit te brengen voor gebruik door anderen (CPB, 2009). Hoe groot die marktmacht is, hangt af van de mate waarin de software uniek is, de beschikbaarheid van alternatieven en de kwaliteit van de software die gebruikers ervaren.

In § 3.1 hebben wij een aantal categorieën van software onderscheiden (kantoorautomatisering, specifieke eindgebruikersapplicaties, software voor websites en intranetten, technische informatiesystemen, ICT-infrastructuur en ontwikkel- en beheersoftware). Niet voor al deze verschillende categorieën van software zijn vergelijkbare alternatieven beschikbaar in de vorm van opensourcesoftware. Er bestaat derhalve niet één softwaremarkt, maar er is sprake van een groot aantal verschillende deelmarkten, die bovendien niet statisch zijn maar zich ontwikkelen. In sommige deelmarkten van de softwaremarkt is sprake van sterke marktconcentratie. Desktopsoftware/kantoorautomatisering kent wereldwijd één dominante aanbieder (Microsoft), op de deelmarkt van ERP-pakketten zijn twee dominante aanbieders actief (SAP en Oracle) en ongeveer 60% van de deelmarkt van databasemanagementsystemen is in handen twee aanbieders (Microsoft en Oracle, zie Database Magazine, 2010). In andere deelmarkten zien we veel verschillende aanbieders van software. Voor contentmanagementsystemen voor websites is er bijvoorbeeld keuze uit een veelheid aan zowel open als gesloten varianten van softwarepakketten.

Leveranciers volgen uiteenlopende strategieën op het punt van het onderscheid «open» en «gesloten». Op die manier ontstaan verschillende verdienmodellen. Deze modellen zullen onder invloed van verschuivende verhoudingen op de markt blijven veranderen. Soms stellen bedrijven op een bepaald moment hun tot dan toe closedsourcesoftware als open-sourcesoftware ter beschikking van een, al dan niet door het bedrijf zelf georganiseerde, community. Daarmee wordt een deel van de ontwikkelac-tiviteiten naar de community verplaatst, wat neerkomt op verlaging van de ontwikkelkosten die de softwareproducent zelf moet maken. Een voorbeeld is het bedrijf Apple, dat een deel van zijn besturingssysteem OSX onder de naam Darwin vrijgaf onder een opensourcelicentie. Het kan ook zijn dat een bedrijf closedsourcesoftware vrijgeeft omdat het zich wil specialiseren in advies, implementatie en onderhoud en erop rekent nieuwe klanten te kunnen trekken als de licentiekosten vervallen. In andere gevallen biedt een softwareleverancier closedsourcesoftware aan die eerst opensource was. Veel commerciële software is op die manier ontstaan (zie bijvoorbeeld het tekstkader «Verschil tussen opensource- en closedsourcesoftware is vooral de licentievorm» in § 3.3.5). Dit gebeurt bijvoorbeeld door opensourcecomponenten te combineren met closedsourcecomponenten, of door de opensourcecom-ponenten te verpakken in een schil van closedsourcesoftware die er een gebruikersvriendelijk pakket van maakt. Dit is alleen toegestaan als er geen copyleft-bepaling in de licentie is opgenomen, zie § 3.3.2.

3.3.5 Vaak genoemde voordelen van opensourcesoftware

Net zoals open standaarden niet «van nature» bepaalde voordelen hebben (zie § 3.2.3) zien we goede eigenschappen die vaak als voordeel van opensourcesoftware worden genoemd niet automatisch terug bij alle opensourcesoftware.

⁴⁷  Bron: http://www.nl.capgemini.com/ expertise/publicaties/open-source-maturity-model-een-selectie-voor-een-open-wereld/ of http://sourceforge.net/projects/qualipso-omm/.

⁴⁸  http://www.coverity.com/html/press/ coverity_open_source_integrity.html.

Zo wordt aan opensourcesoftware vaak een hogere technische degelijkheid toegeschreven, vanwege de potentieel beschikbare kennis binnen de community. Een community levert echter niet per definitie technisch deugdelijke software af (en ook het omgekeerde is niet op voorhand waar). Omdat opensourcesoftware in community’s wordt geprogrammeerd en de ene community de andere niet is, verschilt de kwaliteit van de software van geval tot geval. Bij het beantwoorden van de vraag of er een serieus alternatief voor closedsourcesoftware beschikbaar is speelt de factor kwaliteit van de opensourcevariant uiteraard een belangrijke rol. Kwaliteit van software is echter lastig te meten. Er zijn wel een aantal initiatieven ontplooid om hier modellen voor te ontwikkelen, zoals het Open Source Maturity Model.⁴⁷ Verder wordt vaak verondersteld dat de kwaliteit van opensourcesoftware beter wordt door het gebruik. Toepassingen die veel gebruikt worden zullen een meer actieve en grotere community hebben, of zelfs professionele ondersteuning van een bedrijf genieten. In theorie komt dit de kwaliteit ten goede.

Over de technische kwaliteit van opensourcesoftware circuleren verschillende berichten. Zo zijn er aanwijzingen dat de vaktechnische kwaliteit van het programmeerwerk bij opensourcesoftware de laatste jaren verbeterd is.⁴⁸ Daar staat tegenover dat het bedrijf Software Improvement Group (SIG), dat zich heeft toegelegd op het meetbaar maken van karakteristieken van software, aangeeft dat opensourcesoftware vaak nogal tegenvalt als het gaat om de technische kwaliteit. Als voorbeeld noemt

SIG het gebruik van codeduplicatie, wat betekent dat dezelfde code meerdere keren voorkomt in de broncode. Op zichzelf hoeft codedupli-catie geen consequenties te hebben voor het functioneren van de software, maar het maakt het onderhoud van de software wel lastiger en foutgevoeliger. Een wijziging moet dan namelijk op verschillende plaatsen in de broncode worden doorgevoerd.

Een ander voordeel dat over opensourcesoftware veelvuldig genoemd wordt is een snellere respons op vragen over de software. Omdat een hele community beschikt over kennis over de software, in plaats van alleen de producent, zou er altijd wel een lid van de community zijn die vrijwel meteen met een oplossing voor je probleem komt. Dat argument gaat echter alleen op als er een actieve community met voldoende leden achter de software staat.

Ook zou opensourcesoftware duurzamer zijn dan closedsourcesoftware, omdat het voortbestaan beter gewaarborgd is. De software is immers niet afkomstig van één leverancier, die failliet kan gaan, kan worden overgenomen, of bijvoorbeeld kan besluiten het product van de markt te nemen of oudere versies niet meer te ondersteunen. Maar ook hier is een actieve community van voldoende omvang een voorwaarde. Bovendien kunnen bedrijven ook community’s «overnemen» (financieel of door inbreng van broncode steunen) of juist afstoten. Ten slotte moet rekening gehouden worden met het feit dat opensourcesoftware vooral verschilt van closedsourcesoftware door de licentievorm die wordt gehanteerd (zie tekstkader), voor de kwaliteit van de software zelf maakt het in dat geval niet uit of hij het label «open» of «gesloten» heeft.

Verschil tussen opensource- en closedsourcesoftware is vooral de licentievorm

Het verschil tussen opensourcesoftware en closedsourcesoftware is niet gelegen in verschillen in de software maar in verschillen in de manier waarop de software wordt geleverd. Deze verschillen komen tot uiting in de licentievorm waaronder de software beschikbaar is. Het komt in de praktijk regelmatig voor dat software die op het ene moment nog gratis onder een opensourcelicentie ter beschikking staat, de volgende dag onder een gesloten licentie wordt gebracht en geld gaat kosten, of omgekeerd. Een goede illustratie hiervan is het databasemanagementsysteem MaxDB. De ontwikkeling van deze software is eind jaren ’70 van de vorige eeuw gestart als universitair onderzoeksproject aan de Technische Universität Berlin. In de jaren ’80 werd het vervolgens door het bedrijf Nixdorf Computer AG doorontwikkeld en als closedsourcesoftware op de markt gebracht onder de productnaam DDB/4. Nadat dit bedrijf samen met de divisie Data Information Services van Siemens verder ging als Software AG werd het (als closedsourcesoftware) op de markt gebracht onder de naam AdabasD. In 1997 werd de software verkocht aan SAP AG, die het product omdoopte in SAP DB. In 2000 stelde SAP AG het commerciële product als opensourcesoftware beschikbaar onder een licentievorm die door een sterke copyleft-bepaling commercieel gebruik uitsluit, waarbij SAP doorging met de ontwikkeling van de software. In 2004 verkocht SAP AG het product door aan MySQL AB (dat later werd overgenomen door Sun Microsystems, dat op zijn beurt naderhand opging in Oracle). Vervolgens kwam het weer terug in handen van SAP AG, die het als opensourcesoftware uitbracht onder de naam MaxDB (Bundes Ministerium des Inneren, 2008).

49

Vergadering ICBR, 22 september 2008. ICBR is de Interdepartementale Commissie Bedrijfsvoering Rijksdienst, voorgezeten door de directeur-generaal Organisatie en Bedrijfsvoering Rijk.

3.3.6 Software als onderdeel van de informatie- en ICT-architectuur

Aan de afweging tussen open en gesloten gaat de vraag vooraf welke doelen er bereikt moeten worden. Bij de keuze voor een softwareappli-catie zijn niet alleen de kosten van belang. De software moet ook passen binnen de informatie- en ICT-architectuur van het Rijk en de uitwerking daarvan voor de verschillende onderdelen van het Rijk.

Bij een ministerie is het realiseren van beleidsdoelen bepalend voor de inrichting van het werkproces. Een informatiehuishouding die wordt ondersteund door ICT en die is gebaseerd op een deugdelijke strategie, maakt daar onderdeel van uit. De laatste tien jaar wordt de gedachte steeds meer gemeengoed dat de inrichting van de informatiehuishouding en de bijbehorende ondersteunende ICT het beste kan gebeuren door te werk te gaan «onder architectuur». Dat maakt het mogelijk om vele, vaak gelijktijdig plaatsvindende veranderingsprocessen een inhoudelijke sturing te geven (vgl. Berg en Steenbergen, 2004). Toegespitst op het onderwerp van dit rapport is het voordeel hiervan dat softwarekeuzes met inbegrip van de bijbehorende standaarden optimaal kunnen worden afgestemd op de organisatiedoelen.

Voor de overheid (in brede zin) geldt de Nederlandse Overheid Referentie Architectuur (NORA). De huidige versie van NORA is versie 2.0 (Kenniscentrum e-overheid, 2007). NORA versie 3.0 is in ontwikkeling en op onderdelen al klaar. NORA is nader geconcretiseerd voor de verschillende bestuurslagen en voor de laag van de rijksoverheid is de Model Architectuur Rijksdienst (MARIJ) vastgesteld,⁴⁹ die geldt voor de kerndepartementen. MARIJ formuleert de volgende vier vertrekpunten (Kenniscentrum e-overheid, 2008):

• 1. 

  het Rijk is een eenheid;

• 2. 

  het Rijk is doeltreffend;

• 3. 

  het Rijk is doelmatig;

• 4. 

  het Rijk is transparant.

Bij de discussie over de inrichting van de informatiehuishouding en ICT-architectuur van de kerndepartementen zijn deze vier vertrekpunten leidend.

De woorden «referentie» in NORA en «model» in MARIJ drukken uit dat het om abstracte modellen gaat die de grote lijnen van de inrichting neerzetten. Om ze daadwerkelijke als sturingsinstrument bij de inrichting van de ICT te kunnen gebruiken moeten ze eerst nader worden geconcretiseerd voor de specifieke ministeries of de onderdelen daarvan.

4 SOFTWAREKOSTEN RIJKSOVERHEID EN MOGELIJKE BESPARINGEN

In dit hoofdstuk gaan wij in op de vragen van de Tweede Kamer over de kosten van software van de ministeries en de mogelijkheden voor besparingen. Omdat standaarden zijn geïmplementeerd in software of organisatorische procedures gaan wij niet separaat in op de kosten van standaarden. De kosten zijn onderdeel van de softwarekosten.

4.1 Beschikbaarheid van gegevens bij de ministeries

Kosten voor software bestaan uit aanschafkosten, waaronder ook licentiekosten, implementatiekosten, exploitatiekosten inclusief de kosten voor beheer, en uit onderhoudskosten. De werkprocessen van de ministeries zijn in hoge mate geautomatiseerd en software vormt een onlosmakelijk bestanddeel van die processen. Bestanddelen worden in het algemeen niet apart geadministreerd, zo ook worden de kosten van software niet apart geadministreerd. Er geldt dan ook geen verplichting voor de ministeries om dat wel te doen en de softwarekosten zijn niet rechtstreeks af te leiden uit de administraties van de ministeries. Zo worden bijvoorbeeld de jaarlijkse licentiekosten vaak niet apart geregistreerd omdat ze in één keer voor een aantal jaren worden afgerekend, dikwijls voor verschillende applicaties tegelijk. Uit de administratie volgens het kasstelsel is dan niet af te leiden wat in enig jaar de licentiekosten van een specifieke applicatie zijn. Ook is een deel van de ICT van verschillende ministeries uitbesteed aan externe dienstverleners. De dienstverlener brengt tarieven in rekening op basis van soorten en aantallen geleverde diensten, zonder daarbij licentiekosten of onderhoudskosten te specificeren. Er wordt dan een overeenkomst gesloten voor de beschikbaarheid van software in combinatie met diensten zoals beheer en onderhoud en een helpdeskfunctie voor de betreffende software. Het ministerie stuurt in dat geval op de kwaliteit en kosten van de dienstverlening.

Het bovenstaande betekent dat de kosten van in gebruik zijnde software bij de verschillende ministeries niet met grote nauwkeurigheid te bepalen zijn zonder een zeer intensieve studie waarbij bovendien ook dan tal van aannames moeten worden gedaan. Vooral de kosten van implementatie en exploitatie (met inbegrip van beheer) zijn moeilijk te bepalen omdat deze kosten ook ontstaan door tijdsbeslag van (ondersteunende) ICT-afdelingen en van de eindgebruikers van de software. Niet alleen zou die onderzoekinspanning veel tijd vergen en ook dan nog slechts een benadering kunnen opleveren, het zou ook voor de departementen zelf een kostbare operatie kunnen worden. Bij een van de ministeries liep al ongeveer een jaar een project naar het in kaart brengen van alle in gebruik zijnde software. Het ministerie raamde de met die werkzaamheden verbonden kosten op ongeveer € 400 000.

We hebben daarom moeten besluiten af te zien van het opbouwen van kosteninzicht vanuit de administraties, en over te stappen op het opbouwen van een zo goed mogelijk beeld op basis van globale schattingen van de ministeries en gesprekken daarover.

4.2 Huidige kosten

4.2.1 Aanpak en redeneerlijn

Gelet op het grote aantal applicaties dat ministeries in gebruik hebben, hebben wij ons onderzoek naar softwarekosten bij de ministeries toegespitst op die software die direct relevant is in het kader van dit onderzoek, namelijk de software waarvoor in principe opensourcevari-anten beschikbaar zijn. Welke software dat precies is kan variëren per ministerie, maar in het algemeen gaat het om software als:

besturingssystemen;

kantoorautomatisering (tekstverwerking, spreadsheets,etc);

e-mailapplicaties;

webbrowsers;

geografische informatiesystemen;

contentmanagementsystemen;

applicaties voor webontwikkeling;

databasemanagementsystemen.

Dit onderzoek betreft dus niet alle software, maar alleen dat deel van de software waar een opensourcevariant voor bestaat. Dit deel van de software duiden we aan als «het relevante deel» van de software (zie figuur 5 in § 4.2.2). Welk deel dat proportioneel uitmaakt van alle in gebruik zijnde software is op basis van ons onderzoek niet met voldoende mate van precisie te zeggen. Ook in de vakliteratuur hebben we op dit punt onvoldoende houvast gevonden.

Softwarekosten bestaan uit kosten voor: aanschaf (waaronder licentiekosten); implementatie;

exploitatie (waaronder beheer); onderhoud.

De toedeling van de kosten van het relevante deel van de software aan deze kostencomponenten is op basis van de gegevens waarover de ministeries beschikken niet goed te maken. In het kader van dit onderzoek zijn primair de licentiekosten van belang, omdat bij opensourcesoftware de licentiekosten kunnen worden vermeden. Daarom hebben we de ministeries gevraagd in elk geval aan te geven wat bij benadering de hoogte van de totale licentiekosten is van het relevante deel van de software.

Daarnaast zijn we nagegaan over welke andere componenten van softwarekosten de ministeries een bruikbaar beeld konden verschaffen. Dat bleken de onderhoudskosten te zijn. We hebben dus niet alle softwarekosten in het onderzoek apart in beeld gebracht, maar uitsluitend de licentie- en onderhoudskosten en alleen voor zover ze betrekking hebben op het relevante deel van de software. De overige kostencomponenten (andere aanschafkosten naast licentiekosten, en implementatie- en exploitatiekosten) en de kosten van andere software zijn dus niet in beeld gebracht.

Om de licentiekosten en onderhoudskosten van het relevante deel van de software in perspectief te plaatsen zijn we ook nagegaan wat de totale jaarlijkse ICT-kosten van de ministeries zijn. Hierbij gaat het, voor zover achterhaalbaar, om de totale kosten voor aanschaf, implementatie, exploitatie en onderhoud van zowel hardware als software. Het betreft de totale kosten van hardware en de totale kosten van software. Dat betekent dat de ministeries in het totale ICT-bedrag alle externe kostencomponenten hebben meegerekend, voor zover deze voor de ministeries achterhaalbaar zijn, waarbij waar nodig gebruik is gemaakt van schattingen.

4.2.2 Resultaten

In figuur 5 is te zien uit welke componenten de totale ICT-kosten van de ministeries bestaan. Hierin hebben wij schematisch weergegeven welke verschillende kostencomponenten we onderscheiden en welke van die kostencomponenten we specifiek in beeld hebben gebracht. In het schema zijn de verschillende kostencomponenten met stippellijnen van elkaar gescheiden omdat de relatieve omvang van de afzonderlijke componenten niet bekend is. Elk van de kostencomponenten kan bovendien in omvang veranderen bij de overstap van closedsource-software op opensourcesoftware. Zo kunnen de aanschafkosten bijvoorbeeld dalen of juist stijgen: dalen door het vervallen van licentiekosten of stijgen door bijkomende kosten zoals uitstapkosten, verbonden aan het beëindigen van de relatie met de leverancier van closedsourcesoftware (zie § 3.3.3). Hetzelfde geldt voor de implementatiekosten en onderhoudskosten: ze kunnen dalen omdat men niet afhankelijk is van de leverancier (vendor lock-in, zie § 3.3.3) of stijgen als bijvoorbeeld het ministerie expertise rond het specifieke opensourceproduct extern moet inhuren omdat die intern onvoldoende aanwezig is. Ook de kosten voor exploitatie (waaronder beheer) kunnen dalen of stijgen. Deze kosten kunnen bijvoorbeeld dalen als wordt overgestapt op een opensourcebesturings-systeem dat minder zware eisen aan de hardware stelt dan de closedsourcevariant. Maar ze kunnen ook stijgen, bijvoorbeeld als onderdelen van het ministerie de closedsourcevariant niet kunnen missen zodat de ICT-afdeling genoodzaakt is om niet alleen de nieuwe, open-sourcevariant in exploitatie te nemen maar daarnaast ook nog de bestaande, closedsourcevariant in exploitatie te houden. Ten slotte is er ook nog sprake van ontwikkeling in de tijd. Zo kunnen de kosten in eerste instantie stijgen omdat bijvoorbeeld eigen personeel aanvullende opleidingen nodig heeft of omdat de bestaande closedsourcevariant tijdelijk in exploitatie moet blijven naast de nieuwe, opensourcevariant.

Totale ICT-kosten

In figuur 5 is te zien dat de totale ICT-kosten van alle ministeries samen ongeveer € 2,1 miljard bedragen. Het peiljaar hiervoor was 2009. Zoals gezegd betreft het de gezamenlijke opgaven van de ministeries van alle softwarekosten (licentiekosten en overige aanschafkosten, de kosten van implementatie, exploitatie en onderhoud) van zowel de relevante software als alle overige software en alle hardwarekosten (aanschaf, implementatie, exploitatie en onderhoud).

Van het totaal van de ICT-kosten hebben wij, gelet op de onderzoeksvraag, specifiek de licentiekosten en de onderhoudskosten van het relevante deel van de software in beeld gebracht, zie hierna. Wij hebben geen onderzoek gedaan naar de andere kostencomponenten.

Figuur 5 Componenten van de totale ICT-kosten van ministeries

Hardware

_______A______

Indicatief in beeld gebracht door Algemene Rekenkamer

Aanschaf (incl. licenties)

Implementatie

Exploitatie (incl. beheer)

Onderhoud

Overige software

____A____

Software

A

Relevant deel

Totale opgegeven ICT-kosten ministeries

€ 2,1 miljard*

Onbekende ICT-gerelateerde kosten

Onder meer: kosten eigen personeel

*cijfers 2009

Veel ICT-gerelateerde kosten (waaronder vooral de kosten voor eigen personeel) blijven buiten beeld omdat ze niet worden toegerekend aan een van bovenstaande kostencomponenten.

Softwarelicentiekosten

Het totaal van licentiekosten van het relevante deel van de software in 2009 die blijken uit de opgaven van de ministeries bedraagt ongeveer € 88 miljoen (afgezet tegen de totale ICT-kosten van alle ministeries samen is dit ongeveer 4 %). Gelet op onze opmerkingen over de beschikbaarheid van gegevens bij de ministeries gaan wij ervan uit dat dit eerder een onderschatting dan een overschatting van het werkelijke percentage is. Een deel van de licentiekosten zal mogelijk onderdeel zijn van overeenkomsten met ICT-dienstverleners, maar niet afzonderlijk zichtbaar zijn als licentiekosten.

Software-onderhoudskosten

Het totaal van de jaarlijkse onderhoudskosten van het relevante deel van de software in 2009 die blijken uit de opgaven van de ministeries bedraagt ongeveer € 170 miljoen (afgezet tegen de totale ICT-kosten van alle ministeries samen is dit circa 8 %). Uit de gesprekken bij de ministeries hebben wij opgemaakt dat het vaak moeilijk is om de kosten van ICT-dienstverlening uit te splitsen naar dienstverlening voor applicatieon-derhoud en andere vormen van dienstverlening. Aan de andere kant weten we uit andere onderzoeken dat de tijdsbesteding van intern personeel doorgaans niet (volledig) wordt toegerekend aan specifieke ICT-projecten of activiteiten. In de door de ministeries opgegeven kosten voor onderhoud kunnen derhalve zowel onderschattingen als overschattingen zitten.

Verschillen tussen ministeries

De hoogten van de ontvangen cijfers lopen uiteen tussen de ministeries. Zo varieerden de totale opgegeven ICT-kosten per ministerie tussen € 5,5 miljoen en € 560 miljoen. De opgegeven licentiekosten van de relevante software varieerden per ministerie tussen € 0,16 miljoen en € 24 miljoen. De opgegeven onderhoudskosten van de relevante software ten slotte, varieerden tussen € 0,5 miljoen en € 60 miljoen. We noemen deze cijfers uitsluitend om aan te geven dat er verschillen zijn tussen ministeries; het is niet onze bedoeling om individuele ministeries er uit te lichten. Uit het feit dat een bepaald getal hoog of laag is, zijn geen conclusies te trekken over de vraag of het ministerie het op dat punt «goed doet» of niet. De cijfers zijn namelijk niet onderling vergelijkbaar. Bovendien zijn de bedrijfsprocessen van de ministeries verschillend waardoor er ook verschillen zijn in het softwarelandschap.

Samenvattend is het indicatieve beeld als volgt. Voor het peiljaar 2009 bedroegen de totale ICT-kosten (alle hardware en alle software samen) ongeveer € 2,1 miljard. Hiervan bestond ongeveer € 88 miljoen (ongeveer 4% van de totale ICT-kosten) uit licentiekosten van de relevante software en ongeveer € 170 miljoen (ongeveer 8% van de totale ICT-kosten) uit onderhoudskosten van de relevante software.

4.3 Mogelijke besparingen door ruimer gebruik van opensourcesoftware

4.3.1 Aanpak: geen simpele rekensom

De Tweede Kamer lijkt vooral geïnteresseerd in besparingsmogelijkheden. In theorie is een besparingspotentieel te bepalen door het verschil te nemen tussen de huidige kosten van softwaregebruik en de kosten van softwaregebruik als alle closedsourcesoftware voor zover mogelijk vervangen zou zijn door open varianten. Het berekenen van dit theoretische besparingspotentieel stuit echter op een aantal problemen.

In de eerste plaats blijkt de hoogte van de huidige kosten van de relevante software maar zeer ten dele vast te stellen. Dit beeld komt naar voren uit ons onderzoek naar de kosten bij ministeries.

In de tweede plaats is er maar zeer beperkt sprake van een afweging tussen (een zuivere vorm van) opensourcesoftware en (een zuivere vorm van) closedsourcesoftware. Er zijn veel mengvormen en vaak bestaan applicaties uit een combinatie van open en gesloten standaarden en softwarecomponenten.

In de derde plaats blijkt dat niet in algemene zin is vast te stellen dat de totale kosten die zijn verbonden aan opensourcesoftware lager liggen dan de totale kosten die zijn verbonden aan closedsourcesoftware. Naast aanschafkosten (waaronder licentiekosten, die doorgaans nihil zijn in het geval van opensourcesoftware), zijn immers ook kosten voor implementatie, exploitatie (waaronder beheer) en onderhoud verbonden aan het gebruik van software. Bovendien is de functionaliteit van een opensource-variant van een bepaalde applicatie doorgaans niet exact gelijk is aan die van de gesloten variant.

In de vierde plaats wordt door de experts en in de literatuur die wij hebben geraadpleegd benadrukt dat er geen sprake is van een statische situatie, dat rekening moet worden gehouden met de waarde van de installed base⁵⁰ van de bestaande hard- en software en dat geforceerde overgangen tot kapitaalvernietiging aanleiding kunnen geven. Dergelijke

⁵⁰ De combinatie van de bestaande technische infrastructuur en het bestaande softwarelandschap.                                         kapitaalvernietiging kan voorkomen worden als per situatie voor een natuurlijk» overgangsmoment wordt gekozen. Een natuurlijk moment is bijvoorbeeld het moment waarop bestaande licenties aflopen. Wij hebben geconstateerd dat de meeste ministeries hiervan geen afzonderlijke administratie op applicatieniveau bijhouden.

Ten slotte blijkt uit ons onderzoek dat ministeries in een aantal gevallen een bewuste keuze maken voor de aanschaf van een (set van) applicaties op basis van een ICT-strategie. De afweging is dan veel breder dan de vraag of opensourcesoftware beschikbaar is. Dit leidt in veel gevallen tot een combinatie van closedsourcesoftware en opensourcesoftware in één systeem, ook wel aangeduid als best source.

In onze zoektocht naar betrouwbare financiële gegevens zijn wij enkele business cases tegengekomen waarbij sprake was van een (voorgenomen) overgang van gesloten naar open technologie. Overigens verschillen de business cases in aanpak en onderbouwing en is er soms sprake van een globale kosten-batencijferopstelling. De business cases dienen als illustraties hoe organisaties in concrete situaties verwachten besparingen te kunnen realiseren.

4.3.2 Praktijkvoorbeelden

Vier praktijkvoorbeelden opensourcesoftware

Tijdens de gesprekken die wij bij de ministeries hebben gevoerd, hebben verschillende ministeries voorbeelden gegeven van situaties waarin de vervanging van bepaalde closedsourcesoftware naar opensourcesoftware had plaatsgevonden of was overwogen. Wij hebben bij drie van deze business cases de bijbehorende onderbouwing bestudeerd om tot een indicatie van het besparingspotentieel te komen.

Opensourcesoftware: Veilig Internet

Het Ministerie van Defensie stelt hoge eisen aan de beveiliging van informatie en systemen. Een consequentie hiervan is dat medewerkers vanaf de standaardwerkplek niet zomaar gebruik kunnen maken van internet en dat daar een speciale voorziening voor nodig is. De bestaande voorziening voor internettoegang was niet altijd stabiel en stond slechts een beperkt aantal gelijktijdige gebruikers toe. In 2010 is «Veilig Internet», een op opensource-software gebaseerde internetvoorziening, in gebruik genomen. Hiermee is de toegang tot internet stabiel, veilig, snel, schaalbaar, kortom kwalitatief beter en goedkoper. Eén licentie stelt het Ministerie van Defensie in staat om (in principe) oneindig veel medewerkers te faciliteren. Het Ministerie van Defensie schat dat Veilig Internet in vergelijking met de huidige (gesloten) voorziening ongeveer 42% goedkoper is. Dit houdt een potentiële besparing in van ongeveer € 1 miljoen per jaar.⁵¹ Wij zijn niet nagegaan of dit reële getallen zijn.

⁵¹ Verwachte besparingen zijn gebaseerd op kostprijzen van de dienstverlener maar zonder investeringskosten en bijkomende «afnemers-kosten», waaronder het trainen van eindgebruikers. Per saldo zal de uiteindelijke kostenbesparing dus lager zijn.

⁵² Ministerie van Defensie, «Pilot telestick», in: In Touch, 2010, nr. 3, p. 14.

⁵³  Dit bedrag is gebaseerd op kostprijzen die Ivent als interne ICT-dienstverlener doorberekent aan de gebruikersorganisatie, maar zonder investeringskosten en bijkomende kosten bij de gebruikersorganisatie waaronder het trainen van eindgebruikers. Per saldo zal de uiteindelijke besparing dus lager zijn.

⁵⁴  Dit is software voor beheer van documenten.

Opensourcesoftware: Telestick

Het Ministerie van Defensie is in 2010 gestart met de pilot «Telestick».⁵² De Telestick is een USB-stick, die wordt gebruikt in combinatie met een paslezer. Hiermee kan een defensiemedewerker vanuit een niet-defensielocatie op een veilige wijze toegang krijgen tot het defensienetwerk, waarbij de identiteit van de medewerker wordt geverifieerd via de persoonlijke defensiepas (een beveiligde toegangspas die ook gebruikt wordt voor de toegang tot gebouwen van het ministerie). De Telestick is een alternatief voor de huidige voorziening die bestaat uit een defensielaptop en een persoonlijke code. De Telestick kan aan elke pc worden gekoppeld, waarna de medewerker inlogt op het defensienetwerk. De Telestick met paslezer is in vergelijking met de laptop een goedkopere manier om medewerkers van buitenaf toegang te verlenen tot het defensienetwerk. Op basis van schattingen verwacht het Ministerie van Defensie dat de Telestick 80% goedkoper kan zijn dan de bestaande voorziening. Dit komt neer op een verwachte besparing in de orde van grootte van ongeveer € 0,5 miljoen per jaar.⁵³ Wij zijn niet nagegaan of dit reële getallen zijn.

Opensourcesoftware: Enterprise Content Management (ECM)⁵⁴

Het Ministerie van Justitie schat dat ongeveer 35% van de software opensource is. In de softwarecategorie ECM wordt zelfs overwegend gebruik gemaakt van opensourcesoftware. Voor deze softwarecate-gorie heeft GDI, de interne ICT-dienstverlener ons op basis van schattingen aangegeven wat de besparingen zijn door het gebruik van opensourcesoftware. De licentiekosten zijn bij de opensourceva-riant nihil. In de exploitatie zijn nauwelijks verschillen te zien. Per saldo levert dit geen substantiële besparing op, naar schatting van het ministerie bedraagt de besparing slechts ongeveer € 60 000 (ruim 2% van de kosten van een closedsource-oplossing).

Verder hebben we in diverse gesprekken die wij in het kader van dit onderzoek hebben gevoerd verschillende business cases aangereikt gekregen, die zijn opgesteld omdat een organisatie overwoog over te gaan op open standaarden of opensourcesoftware of een combinatie daarvan. Een van deze cases heeft, net als de vorige drie, betrekking op opensourcesoftware.

Opensourcesoftware: Gemeente Amsterdam⁵⁵

De gemeente Amsterdam heeft in 2006, op verzoek van de gemeenteraad, een business case opgesteld over hoe om te gaan met het in 2008 aflopende contract met Microsoft voor kantoorautomatisering. De business case heeft als doel om inzichtelijk te maken onder welke condities het mogelijk is om als gemeente Amsterdam een leveran-ciersonafhankelijke keuze voor software te hebben. Als uitgangspunt van de business case is een aantal strategische softwaredoelstel-lingen benoemd, zoals verhoogde interoperabiliteit, verhoogde leveranciersonafhankelijkheid, continuïteit van de bedrijfsvoering en kostenneutraliteit. Deze doelstellingen zijn vooral kwalitatief van aard. Dat een en ander zo veel mogelijk kostenneutraal uitgevoerd dient te worden wijst erop dat het hoofddoel van het project niet het besparen van kosten was. De business case laat zien dat de gestelde strategische softwaredoelstellingen behaald kunnen worden door een breder gebruik van open standaarden en/of opensourcesoftware,

al dan niet in combinatie met closedsourcesoftware.⁵⁶

Op basis van prijsopgaven van drie leveranciers geeft de business case aan dat de verwachte besparingen na uitrol naar alle 16 000 werkplekken jaarlijks tussen de € 1,5 en € 6 miljoen bedragen.

Drie praktijkvoorbeelden open standaarden

De overige drie ontvangen business cases betreffen open standaarden. Typerend voor deze business cases is dat ze vooral inzicht geven in de te verwachten (maatschappelijke) baten van een project. De projecten bestaan uit zowel het organiseren en inrichten van de gegevensuitwisseling als uit standaardisatieactiviteiten om interoperabiliteit te bereiken of te verbeteren. De baten die gerealiseerd kunnen worden door specifiek voor open standaarden te kiezen, blijken niet uit de business cases. De business cases over open standaarden zijn in de volgende tekstkaders beschreven.

Open standaarden: INSPIRE⁵⁷

⁵⁵  DCE Consultants B.V., Business Case: Open Softwarestrategie Gemeente Amsterdam, 2006.

⁵⁶  In 2009 is toch besloten een nieuw contract met Microsoft af te sluiten ter overbrugging van de periode totdat de standaard open werkplek geschikt is gemaakt voor de hele gemeente (College van B&W Gemeente Amsterdam, agendapunt 17 maart 2009. Onderwerp: Microsoftcontracten, Amsterdam, 2009.)

⁵⁷  ECORYS Nederland BV en Grontmij Nederland BV, Kosten-batenanalyse INSPIRE: eindrapport, Rotterdam, 2009.

⁵⁸  Dit zijn de verwachte besparingen bij invoering volgens het «basismodel» (invoering met minimale kosten en maximaal effect), wat inhoudt dat de overheid de richtlijn omzet in nationale wetgeving en stuurt op minimale impact voor organisaties die INSPIRE-plichtige geo-informatie beheren. Uitsluitend enkele (de «best passende») datasets worden ontsloten en geharmoniseerd.

In Nederland is een traject opgestart voor een goede invoering van de INSPIRE-richtlijn (Infrastructure for Spatial Information in the European Community). Bij de voorbereiding van dit traject is in 2009 een analyse uitgevoerd naar de impact en de kosten en baten van de invoering van de richtlijn. In de business case is geraamd dat de jaarlijkse baten van invoering van INSPIRE volgens het basismodel oplopen van ongeveer € 0,5 miljoen tot € 8,6 miljoen euro in de periode tot 2024.⁵⁸ Het grootste voordeel wordt verwacht door een grotere efficiency bij de gebruikers. Voor dataleveranciers is het efficiencyvoordeel beperkt. Het saldo van de kosten en de baten van de invoering van INSPIRE laat zien dat naar verwachting over de totale tijdshorizon van de kosten-batenanalyse de baten de kosten met € 34,0 miljoen overstijgen (netto contante waarde).

Open standaarden: WelstandTransparant⁵⁹

Het project WelstandTransparant is bedoeld om snelle en gemakkelijke toegang tot gemeentelijke welstandsnota’s te bieden via internet. Voor de besluitvorming over de landelijke uitrol hiervan is in 2009 een verkenning uitgevoerd naar de maatschappelijke kosten en baten van WelstandTransparant. Daarbij is een business case opgesteld. De hierin gekwantificeerde financiële baten van het project bestaan vooral uit efficiencyvoordelen, administratieve lastenverlichting en vermeden kosten. De landelijke invoering van WelstandTransparant leidt voor de periode t/m 2015 tot geschatte totale baten van € 17,2 miljoen. Over de totale tijdshorizon van de maatschappelijke kosten-batenanalyse (15 jaar) laat de business case een geraamd financieel voordeel zien van € 1,8 miljoen (netto contante waarde).

Open standaarden: Stelsel van basisregistraties⁶⁰

Het kabinet heeft het gebruik van basisregistraties wettelijk verplicht met als doel om het eenmalig registreren en meervoudig gebruik van gegevens te bevorderen. Volgens de business case Stelsel van basisregistraties is het gemeenschappelijk ontwikkelen van voorzieningen voor (het gebruik van) deze registraties efficiënter en effectiever dan het voor elke basisregistratie en per afnemer afzonderlijk ontwikkelen van voorzieningen. Dat komt doordat redundantie in investeringen en kosten worden vermeden. De baten van de businesscase zijn vermeden kosten en investeringen en synergievoordelen ten opzichte van het nulalternatief. In het gunstigste model bedragen de verwachte totale baten over de periode 2010–2020 volgens het externe bureau ongeveer € 918 miljoen en bedraagt het verwachte positieve saldo van kosten en baten voor de periode 2010–2020 ruim € 720 miljoen (contante waarde).

Ons zijn geen evaluaties bekend van afgeronde projecten waarbij is overgegaan van «gesloten» naar «open». Wij beschikken dus niet over informatie op basis waarvan betrouwbare uitspraken zijn te doen over de mate waarin de vooraf geraamde besparingen uit de business cases feitelijk zijn gerealiseerd. Wij overwegen hier nog naar op zoek te gaan omdat uiteraard vooral de nacalculatie relevant is voor de Tweede Kamer.

⁵⁹  ECORYS Nederland BV, Maatschappelijke kosten-batenanalyse WelstandTransparant, Rotterdam, 2009.

⁶⁰  PricewaterhouseCoopers, Verfijning en herijking kosten-batenanalyse voor investeringen in gemeenschappelijke voorzieningen in het stelsel van basisregistraties: Grip op centrale en decentrale investeringen en kosten maximeert de businesscase. Referentie: 2010–0430/ADB/mh/ms/wb, 23 februari 2010.

De opstellers van de business cases hebben bij het maken van de kosten-batenanalyses gewerkt met veronderstellingen. Verwachte kosten en baten (en dus de per saldo besparingen) zijn geraamd op grond van aannames. De kwaliteit van de onderbouwing van de gehanteerde aannames verschilt. In sommige business cases is bijvoorbeeld gewerkt met een gevoeligheidsanalyse, die inzicht geeft in de gevolgen van het aanpassen van een aantal essentiële veronderstellingen die ten grondslag liggen aan de kosten-batenanalyse. In die gevallen biedt de business case ook inzicht in de bandbreedte waarbinnen de kosten en baten naar verwachting zullen vallen. In de verschillende business cases is tevens een raming gemaakt van de terugverdientijd van projectalternatieven.

Het aantal beschreven cases is te klein en te uiteenlopend (ook qua financieel belang) om er stellige conclusies uit te trekken. Het beeld dat uit de cases naar voren komt is dat er soms belangrijke besparingen verwacht worden door gebruik te maken van de mogelijkheden die opensourcesoftware biedt, maar dat in andere situaties de besparingen, in elk geval percentueel gezien, ook verwaarloosbaar kunnen zijn. Ook blijkt dat er een veel breder scala aan overwegingen aan de orde is dan uitsluitend de puur financiële.

Tot slot een opmerking over een mogelijke vertekening in het beeld dat uit de onderzochte business cases naar voren komt. In het algemeen worden business cases opgesteld nadat vooronderzoek heeft uitgewezen dat de kosten van een project waarschijnlijk zullen opwegen tegen de baten van het project. Het is dan ook voorstelbaar dat in andere situaties, die niet beschreven zijn in business cases, de inzet van open standaarden en/of opensourcesoftware juist tot hogere kosten kan leiden.

De business cases op het gebied van open standaarden betreffen projecten die veel meer inhouden dan alleen de standaardisatie door middel van open standaarden. De business cases maken duidelijk dat standaardisatie een noodzakelijke voorwaarde vormt voor het welslagen van het project, maar niet wat specifiek het aandeel is van standaardisatie in de verwachte kostenvoordelen. Evenmin is duidelijk of het voor de te behalen besparingen van belang is dat de voor de standaardisatie gebruikte standaarden open zijn.

Alle business cases geven aan dat met de overstap naar open standaarden en/of opensourcesoftware beoogd wordt om kwalitatieve baten te realiseren. Deze beoogde baten vatten we samen in tabel 3.

Tabel 3 Overzicht beoogde kwalitatieve baten in business cases van (open) standaarden en opensourcesoftware

Project                                      Mogelijke kwalitatieve baten

(Open) standaarden

INSPIRE                                    • Versterken van beleid op het gebied van e-Overheid en geo-informatie

• • 

  Betere en opener dienstverlening van providers

• • 

  Efficiëntere beleidsvorming en projectvoering door gebruikers (vooral in grensoverschrijdende gebieden) •Versterken van kennisontwikkeling bij dataproviders en gebruikers

•Versterken van innovatie

WelstandTransparant            • Verbetering van de informatievoorziening

• • 

  Bijdrage aan groter vertrouwen in de overheid/verbetering imago overheid

•Verbetering van de kwaliteit van het welstandsbeleid

• • 

  Mogelijkheden voor nieuwe toepassingen en diensten

• • 

  Aansluiting op andere digitale systemen (onder meer van bestemmingsplannen)

Stelstel van basisregis- • Stijgende efficiëntie in primair proces van afnemers traties                                       • Goedkopere verkrijging van data door één loket

• • 

  Verhoogde datakwaliteit

• • 

  Groeiend gebruik van basisregistraties

• • 

  Bredere inzet van voorzieningen

Project

Mogelijke kwalitatieve baten

Opensourcesoftware

Gemeente Amsterdam

• • 

  Leveranciersonafhankelijkheid

• • 

  Verbeterde interoperabiliteit

• • 

  Bedrijfscontinuïteit (onder meer door sharedservicesconcept) •Tegemoetkoming aan politieke wensen

• • 

  Digitale duurzaamheid

• • 

  Imago Amsterdam - ICT-stad van Nederland

Veilig internet (Defensie)

• • 

  Leveranciersonafhankelijkheid

• • 

  Verbeterde interoperabiliteit

• • 

  Betere performance

• • 

  Meer (gelijktijdige) gebruikers

• • 

  Functionaliteit herbruikbaar

• • 

  Stabiliteit

Telestick (Defensie)

• • 

  Veiliger

• • 

  Goedkoper schaalbaar (uitrol naar groot aantal medewerkers)

• • 

  Interoperabiliteit (door gebruik defensiepas)

5 CONCLUSIES EN AANBEVELINGEN

In dit hoofdstuk presenteren wij onze conclusies. Om te beginnen in de vorm van enkele algemene observaties over het parlementaire debat dat in de afgelopen tien jaar gevoerd is en vervolgens in de vorm van antwoorden op de vragen die de Tweede Kamer ons gesteld heeft. We sluiten het hoofdstuk af met enkele aanbevelingen.

5.1  Beschouwing van het parlementaire debat

De afgelopen tien jaar heeft de Tweede Kamer vaak opgeroepen tot «meer» gebruik van open standaarden en opensourcesoftware. In reactie daarop heeft het kabinet beleids- en uitvoeringsprogramma’s ontwikkeld die gericht zijn op drie verschillende beleidsdoelen:

betere publieke dienstverlening;

meer marktwerking in de ICT-sector;

financiële besparingen voor de overheid.

De gedachte lijkt dat het zo snel mogelijk vervangen van gesloten standaarden door open standaarden en closedsourcesoftware door opensourcesoftware deze drie beleidsdoelen dichterbij zal brengen. Volgens ons gaat het echter om onvergelijkbare beleidsdoelen die om twee verschillende soorten maatregelen vragen:

Een betere publieke dienstverlening en eventuele kostenbesparingen zijn doelen die bereikt kunnen worden door, waar nodig, te werken aan een betere samenwerking tussen overheidsorganisaties en aan een doelmatiger bedrijfsvoering. Samenwerking hangt primair samen met standaarden en bij bedrijfsvoering speelt vooral software een belangrijke rol.

De beoogde betere marktwerking in de ICT-sector is een doel op het terrein van marktordening. Geëigende middelen om dit doel te bereiken zijn mededingingswet- en regelgeving en toezicht daarop.

Ook constateren we dat de discussie tussen het kabinet en de Tweede Kamer vooral gevoerd wordt op basis van beelden in plaats van op basis van concrete feiten en cijfers. Dat wordt mede veroorzaakt door het feit dat over de uitvoering van het kabinetsbeleid niet altijd wordt verantwoord. Zo hebben ministers zich in de jaarverslagen over 2009 niet verantwoord over het comply or explain and commit-beleid ten aanzien van open standaarden, terwijl dat sinds april 2008 wel verplicht is.

Hierdoor heeft het debat het karakter van herhaling van zetten gekregen, waarbij de Tweede Kamer steeds laat weten dat onvoldoende vorderingen worden gemaakt en het kabinet steeds aangeeft wel degelijk beleid te voeren.

5.2 Antwoorden op vragen Tweede Kamer

5.2.1 Mogelijkheden en scenario’s

Vraag 1: Welke mogelijkheden en scenario’s bestaan er voor de vermindering van het gebruik van gesloten standaarden en de introductie van opensourcesoftware bij de ministeries?

Mogelijkheden en migratiescenario’s staan niet op zichzelf maar hangen af van keuzes die gemaakt worden in het proces van strategische planning. Daarbij moeten organisatiedoelen leidend zijn. Van die doelen worden achtereenvolgens de informatiestrategie en de ICT-strategie afgeleid. De ICT-strategie gaat onder meer over de vraag welke software-functionaliteit er nodig is - het softwarebeleid - en hoe daarin zal worden voorzien - het verwervingsbeleid. Pas bij het verwervingsbeleid is de keuze voor gesloten of open standaarden en closedsource- of opens-ourcesoftware aan de orde.

Het aantal mogelijkheden en scenario’s is groot en deze volgen voor een belangrijk deel uit het softwarebeleid en het verwervingsbeleid. Het voert te ver om het complete scala aan scenario’s hier uitputtend te behandelen. In plaats daarvan geven we een overzicht van de belangrijkste onderwerpen die volgens ons onderdeel moeten zijn van het software- en verwervingsbeleid:

Het «waarom»: met welk doel is welke softwarefunctionaliteit nodig? Deze vraag dient te worden beantwoord op basis van de beleids- en bedrijfsvoeringsdoelstellingen van het ministerie. Het «wat»: welke segmenten van het softwarelandschap betreft het? Hier gaan we op in bij de beantwoording van vraag 2 (§ 5.2.2). Het «wanneer»: volgens welk tijdpad zal er worden voorzien in de vereiste softwarefunctionaliteit? Hier gaan we op in bij de beantwoording van vraag 4 (§ 5.2.4).

Het «hoe»: op welke wijze wordt er voorzien in de vereiste softwarefunctionaliteit? Zelf doen of uitbesteden («make or buy»), maatwerk of standaardsoftware («off the shelf») open of closedsourcesoftware, zelf beheren dan wel uitbesteden?

De business case: de zakelijke rechtvaardiging. Welke opties zijn er om de softwaredoelen te realiseren (inclusief de «nuloptie»: niets doen)? Waarom is de gekozen optie de beste? Wat zijn de verwachte kwantitatieve, kwalitatieve, financiële en niet-financiële kosten en baten? Wat zijn de belangrijkste risico’s en hoe zal het kostenbeeld zich naar verwachting ontwikkelen? In de beantwoording van vraag 3 gaan we in op de financiële aspecten (§ 5.2.3).

De randvoorwaarden die vervuld moeten zijn op het terrein van de beschikbare tijd, het geld en de mensen en andere middelen om de software te kunnen implementeren, beheren en onderhouden. Hier gaan we op in bij de aanbevelingen (§ 5.3).

5.2.2 Vervangingspotentieel

Vraag 2: Welk deel van de gesloten standaarden en closedsourcesoftware kan worden vervangen door open standaarden en opensourceoplos-singen en welk deel niet?

In de vorige paragraaf hebben we aangegeven dat de keuze voor open of closedsourcesoftware niet zwart-wit is, maar dat sprake is van een keuze waarbij veel meer overwegingen een rol spelen. De rijksoverheid maakt tegenwoordig al veel gebruik van opensourcesoftware. Ook komen open en gesloten varianten met vergelijkbare functionaliteit regelmatig naast elkaar voor bij de rijksoverheid. Verder blijkt uit het onderzoek dat het aanbod op de huidige softwaremarkt allerlei mengvormen omvat van open en gesloten varianten. Daar komt bij dat het softwarelandschap van een ministerie uit een groot aantal onderdelen bestaat, die via veel verschillende standaarden gegevens uitwisselen met elkaar en met de buitenwereld. Dit is de complexe werkelijkheid waarmee ministeries te maken hebben en waar alleen greep op te krijgen is met een strategische aanpak. De consequentie daarvan is dat het niet op voorhand mogelijk is om een specifiek deel van het softwarelandschap aan te wijzen dat

«open» gemaakt kan worden, laat staan dat dit valt te kwantificeren. Bovendien is er geen sprake is van een statisch geheel: de softwarewereld ontwikkelt zich snel en wordt gekenmerkt door het continu ontstaan van nieuwe versies en applicaties, open en gesloten en alles daartussen.

5.2.3 Softwarekosten en mogelijke besparingen

Vraag 3: Wat zijn de huidige kosten? Wat zijn de indicatieve introductie-kosten van en de indicatieve structurele kosten na vermindering van het gebruik van gesloten standaarden en de introductie van opens-ourcesoftware? Welke indicatieve besparingen kunnen hiermee worden gerealiseerd?

De kosten van in gebruik zijnde software bij de verschillende ministeries blijken niet met voldoende nauwkeurigheid te bepalen te zijn zonder een zeer intensieve studie waarbij bovendien tal van aannames moeten worden gedaan. Wij hebben de softwarekosten van de rijksoverheid daarom indicatief in beeld gebracht op basis van globale schattingen van de ministeries. We hebben daarbij alleen gekeken naar dat deel van de software waar een opensourcevariant voor bestaat (het «relevante deel» van de software). Welk deel dat proportioneel uitmaakt van alle in gebruik zijnde software is niet met voldoende mate van precisie te zeggen.

De toedeling van softwarekosten aan de te onderscheiden kostencomponenten – aanschaf (waaronder licentiekosten), implementatie, exploitatie (waaronder beheer) en onderhoud – is op basis van de administraties van de ministeries niet goed te maken. Wel hebben wij als onderdeel van de totale ICT-kosten voor alle hardware en alle software van ongeveer € 2,1 miljard in 2009 de licentiekosten en onderhoudskosten kunnen achterhalen. Deze bedragen € 88 miljoen (licentiekosten), respectievelijk € 170 miljoen (onderhoudskosten). Hieruit blijkt dat het totaal van de licentie- en onderhoudskosten van het relevante deel van de software slechts een beperkt deel (12%) van de totale ICT-kosten uitmaakt. De licentiekosten vormen op hun beurt weer een beperkt deel van de softwarekosten. Op basis van de van ministeries verkregen gegevens is echter niet aan te geven wat het aandeel is van de licentiekosten binnen het totaal van kosten van het relevante deel van de software.

Eventuele besparingen op de softwarekosten van de ministeries kunnen alleen in concrete situaties worden bepaald door kosten-batenanalyses te maken in het kader van de uitvoering van het softwarebeleid en de daarbij behorende verwervingsstrategie. Dergelijke kosten-batenanalyses moeten niet gebaseerd zijn op louter de aanschafkosten, waaronder licentiekosten, maar uitgaan van de totale kosten en ook rekening houden met de kosten voor implementatie, exploitatie (waaronder beheer) en onderhoud van de software.

5.2.4 Termijn voor introductie

Vraag 4: Op welke termijn zouden de vermindering van het gebruik van gesloten standaarden en de introductie van opensourcesoftware kunnen worden gerealiseerd?

De overgang van «gesloten» naar «open» zal nooit op een bepaald moment afgerond zijn. Wel zijn er verschuivingen mogelijk naar meer of minder gebruik van open standaarden en opensourcesoftware. De mate waarin sprake is van die verschuivingen en de termijn waarop deze kunnen worden gerealiseerd hangen af van de informatiestrategie en ICT-strategie die het ministerie hanteert, de uitgangssituatie (installed base) van het betreffende ministerie en van ontwikkelingen op de softwaremarkt die voor het ministerie in kwestie van belang zijn.

Zoals we in het antwoord op de eerste vraag hebben aangegeven volgt de keuze voor een bepaalde oplossing uit de informatie- en ICT-strategie. De hierboven genoemde (externe) ontwikkelingen zijn factoren die in zo’n strategie als randvoorwaarden moeten worden meegenomen.

5.2.5 Voor- en nadelen, kansen en risico’s en voorwaarden voor implementatie

Vraag 5: Welke voor- en nadelen en kansen en risico’s onderscheidt de Algemene Rekenkamer naast de kostenoverwegingen? Aan welke voorwaarden moet zijn voldaan om de implementatie van open standaarden en opensourcesoftware mogelijk te maken?

Voor- en nadelen, kansen en risico’s, en voorwaarden hebben we besproken in hoofdstuk 3 en 4. Wij benadrukken dat deze voor- en nadelen, kansen, risico’s, en voorwaarden niet primair samenhangen met open standaarden of opensourcesoftware, maar sterk afhangen van de concrete situatie, de standaard in kwestie en het specifieke softwareproduct. De vraag of de voor- en nadelen en de kansen en risico’s in een concreet geval aanwezig zijn kan alleen worden beantwoord door onderzoek van de omstandigheden in die concrete situatie en door marktonderzoek te doen naar de op dat moment beschikbare producten en diensten op het terrein van software.

5.3 Aanbevelingen

5.3.1 Verwachtingenmanagement

De Tweede Kamer verwacht dat een ruimere inzet van open technologie (open standaarden en opensourcesoftware) tot forse besparingen zal leiden. Ons beeld is echter dat in die gevallen waar de keuze voor open ICT-technologie voor de hand ligt, de overstap vaak al gemaakt is. Dat zijn die gevallen waarin er adequate open alternatieven voorhanden zijn, die worden ondersteund door actieve community’s, en waarin er weinig belemmeringen zijn in de vorm van softwareafhankelijkheden. Waar minder sprake is van open technologie is dat vooral omdat er minder direct toepasbare open alternatieven beschikbaar zijn. Ook vormen de licentiekosten een relatief beperkt deel van de totale ICT-kosten van de overheid. Op grond hiervan zijn volgens ons de mogelijkheden voor quick wins in termen van kostenbesparingen, hoewel allerminst uitgeput, wel beperkt in relatie tot de totale ICT-kosten van de rijksoverheid. Met «uitgeput» doelen wij onder meer op de dynamiek van de situatie waarin zich voortdurende nieuwe kansen voordoen. Wij bevelen het geheel overziende aan geen al te hoge verwachtingen te hebben van de besparingsmogelijkheden door de ruimere toepassing van open standaarden en opensourcesoftware.

5.3.2 Scheiden van beleidsdoelstellingen

Wij bevelen aan een duidelijk onderscheid te maken tussen de beleidsdoelen gericht op een betere de bedrijfsvoering van de ministeries (betere publieke dienstverlening en eventuele kostenbesparingen), beleidsverant- woordelijkheid van de minister van BZK en de beleidsdoelen gericht op marktordeningsvraagstukken, beleidsverantwoordelijkheid van de minister van EL&I. Voor beide soorten beleidsdoelen dienen eenduidige doelen te worden geformuleerd zodat het beleid effectief en efficiënt kan worden vormgegeven en uitgevoerd en de minister van BZK respectievelijk de minister van EL&I zich hierover kunnen verantwoorden.

5.3.3 Werken vanuit strategisch perspectief

Wij bevelen de coördinerende ministers en de vakministers aan om vanuit strategische doelen te werken. Het benaderen van ICT-vraagstukken puur vanuit de wens om kosten te besparen vormt een te beperkt perspectief, vooral als die besparingen louter gerealiseerd moeten worden door de ruimere toepassing van open standaarden en opensourcesoftware. Met ICT is bij de rijksoverheid veel geld gemoeid en kostenbewustzijn is daarom een vereiste maar is zeker niet voldoende als enige invalshoek voor het maken van softwarekeuzes.

5.3.4 Rol CIO’s

In het proces van strategische besluitvorming dient de CIO Rijk samen met de departementale CIO’s een sleutelrol te krijgen. Een CIO vervult immers de brugfunctie tussen de beleids- en bedrijfsvoeringsdirecties en de ICT.⁶¹ Wij bevelen aan dat de CIO Rijk in de interdepartementale afstemming expliciet die sleutelrol met bijbehorende bevoegdheden krijgt, om zo te bevorderen dat op rijksniveau consistent ICT-beleid wordt ontwikkeld. Bij deze benadering dient wel te allen tijde rekening te worden gehouden met de functiespecifieke behoeften op ICT-gebied die van toepassing tot toepassing en van departement tot departement kunnen verschillen.

5.3.5 Rol minister van BZK

Ons onderzoek heeft zich niet gericht op de mate waarin de verschillende ministeries strategische doelstellingen op ICT-gebied hebben geformuleerd, zoals bedoeld in § 5.3.3, die de basis vormen voor het nemen van technologische beslissingen, waaronder softwarekeuzes.

Wij bevelen de minister van BZK aan na te gaan in hoeverre ministeries hun softwarekeuzes maken op basis van strategische doelstellingen op ICT-gebied en daar criteria voor te expliciteren. Ook bevelen wij de minister aan ervoor te zorgen dat alle ministeries medio 2012 aan deze criteria voldoen. Omdat de invulling van de criteria door technologische ontwikkelingen aan permanente verandering onderhevig is, bevelen wij de minister ook aan om de criteria en de operationalisering daarvan periodiek tegen het licht te houden en zo nodig bij te stellen. Wij denken dat de overheid voor de invulling van deze criteria ook gebruik zou moeten maken van kennis en expertise van personen uit andere branches dan de overheid.

Ten slotte bevelen wij de minister van BZK aan regelmatig de Tweede Kamer te informeren over de ICT-strategie en de voortgang daarvan.

61

Zie onze rapporten over ICT-projecten bij de overheid – Algemene Rekenkamer, 2007b en 2008.

6 REACTIE MINISTERS EN NAWOORD ALGEMENE REKENKAMER

We hebben het conceptrapport naar alle ministers verstuurd, waarbij we de ministers van BZK en van EL&I hebben aangesproken als coördinerende ministers. De minister van BZK heeft op 9 maart 2011 mede namens de minister van EL&I gereageerd op ons rapport. Hieronder vatten wij de reactie samen. De integrale reactie staat op onze website www.rekenka-mer.nl. De reactie gaf ons aanleiding tot een kort nawoord.

6.1 Reactie bewindspersonen

De minister schrijft dat het conceptrapport een zakelijk en genuanceerd beeld geeft van het onderwerp open standaarden en opensourcesoftware en dat onze conclusies de uitvoering van het beleid ten aanzien van open standaarden en opensourcesoftware binnen de rijksoverheid onderschrijven.

De minister stemt in met onze conclusies maar plaatst er ook enkele kanttekeningen bij.

Zo merkt hij op dat alle ministeries sinds 2009 een informatiestrategie en een daaruit afgeleide ICT-strategie hebben, mede in het kader van het actieplan NOiV.

Ook tekent hij aan dat het weliswaar niet op voorhand mogelijk is om een specifiek deel van het softwarelandschap aan te wijzen dat «open»

gemaakt kan worden, maar dat dit wel per organisatie mogelijk is.

Wat de voor- en nadelen betreft is de minister van mening dat gemiddeld genomen vanuit het oogpunt van interoperabiliteit vooral de kwalitatieve voordelen van open standaarden groter zijn dan de nadelen.

De minister merkt ook op dat wij de complexiteit en de verwevenheid van

ICT-omgevingen in ons rapport als een feit beschrijven, terwijl hij het juist wil doen verminderen. Het kabinetsbeleid plaatst de overstap naar open standaarden en/of opensourcesoftware daarom vooral in het licht van lange termijnvoordelen en economisch maatschappelijke baten van betere samenwerking en efficiëntere gegevensuitwisseling binnen en tussen organisaties, aldus de minister.

De minister gaat in zijn reactie ook in op onze aanbevelingen. Hij onderschrijft onze aanbeveling om niet te hoge verwachtingen te hebben, maar merkt daarbij wel op dat de markt in ontwikkeling is. Wat betreft het maken van een duidelijk onderscheid tussen de beleidsdoelen voor bedrijfsvoering en de beleidsdoelen voor marktordening geeft de minister van BZK aan te zullen overleggen met de minister van EL&I over hoe dit onderscheid in de toekomst scherper gehanteerd kan worden.

In reactie op onze aanbevelingen om softwarekeuzes te baseren op een strategische aanpak laat de minister weten dat de positie van de CIO Rijk en de departementale CIO’s onlangs versterkt is.

6.2 Nawoord Algemene Rekenkamer

Als bij alle ministeries inderdaad adequate informatie- en ICT-strategieën zijn vastgesteld en worden gerealiseerd, zoals de minister aangeeft, is er een goede basis aanwezig voor doordachte softwarekeuzes. Wij hebben niet onderzocht of dit het geval is. Een adequate strategie is afgestemd op maatschappelijke en technische ontwikkelingen in de nabije toekomst, waarbij de ICT-middelen (zoals hardware en software) minder centraal komen te staan en de strategische beslissingen vooral gaan om het definiëren van de juiste informatie- en ICT-diensten. Wat betreft het maken van een duidelijk onderscheid tussen de beleidsdoelen voor bedrijfsvoering (minister van BZK) en voor marktordening (minister van EL&I) vinden wij het vooral van belang dat het resultaat van het overleg tussen de twee coördinerende ministers wordt vastgelegd in de vorm van concreet geformuleerd beleid en bijbehorende aanpak. De minister geeft aan de complexiteit en de verwevenheid van ICT-omgevingen en de leveranciersafhankelijkheid te willen verminderen. Hij maakt echter nog niet duidelijk hoe en volgens welk tijdpad hij deze ambities wil realiseren. De minister gaat niet op onze concrete aanbevelingen over zijn rol als coördinerend minister (ga na of ministeries hun softwarekeuzes strategisch maken, expliciteer daar criteria voor, zorg dat alle ministeris daar medio 2012 aan voldoen, houd de criteria periodiek tegen het licht en gebruik kennis en expertise uit andere branches). Evenmin geeft hij aan of en hoe hij de Tweede Kamer van informatie zal voorzien over de ICT-strategie en de voortgang daarvan.

BIJLAGE 1 OVERZICHT ANTWOORDEN, CONCLUSIES, AANBEVELINGEN, BESTUURLIJKE REACTIE EN NAWOORD

Meer info

Conclusies Algemene Rekenkamer

Aanbevelingen Algemene Rekenkamer

Reactie minister

Nawoord Algemene Rekenkamer

Algemene beschouwingen over parlementaire debat over open standaarden en opensourcesoftware

Hoofdstuk 2            Gedachte bij Tweede Kamer en kabinet lijkt te zijn dat het zo snel mogelijk overstappen van gesloten op open technologie de beleidsdoelen ten aanzien van bedrijfsvoering en marktordening dichterbij zal brengen. Parlementaire debat wordt vooral gevoerd op basis van beelden in plaats van concrete feiten en cijfers. Debat is hierdoor herhaling van zetten geworden.

Wij bevelen het geheel overziende aan geen al te hoge verwachtingen te hebben van besparingsmo-gelijkheden door ruimere toepassing van open standaarden en opens-ourcesoftware.

Beleidsdoelen op terrein van bedrijfsvoering (betere publieke dienstverlening en eventuele kostenbesparingen) en beleidsdoelen ten aanzien van marktordening (betere marktwerking) vragen om verschillende soorten maatregelen:

• • 

  betere publieke dienstverlening en kostenbesparingen: standaarden, respectievelijk softwarekeuzes;

• • 

  marktordening: mededingingswet en toezicht daarop.

Ministers van BZK en van EL&I moeten duidelijk onderscheid maken tussen beleidsdoelen gericht op bedrijfsvoering van ministeries (betere publieke dienstverlening en eventuele kostenbesparingen) respectievelijk marktordening. Voor beide soorten beleidsdoelen moeten eenduidige doelen worden geformuleerd

Minister van BZK zal              Van belang is dat resultaat overleggen met minister      overleg wordt vastgelegd van EL&I hoe beleids-            in concreet geformuleerd doelen in toekomst                beleid en bijbehorende scherper te onderschei-        aanpak. den.

Antwoorden op de vragen van de Tweede Kamer

Vraag 1 Mogelijkheden en scenario’s voor vermindering van het gebruik gesloten varianten en introductie open varianten

§ 3.1 en § 3.3.6

Informatiestrategie en daaruit afgeleide ICT-strategie bepalen vereiste softwarefunctionaliteit. Pas daarna is keuze open of gesloten technologie (standaarden of software) aan de orde.

Mogelijkheden en migratiescenario’s hangen af van strategische keuzes, waarbij organisatiedoelen leidend zijn.

Alle ministeries hebben Wij hebben niet onder- informatiestrategie en daaruit afgeleide ICT-strategie.

zocht of bij alle ministeries een adequate informatie- en ICT-strategieën zijn vastgesteld en worden gerealiseerd. Een adequate strategie stelt de ICT-middelen minder centraal en gaat vooral over informatie- en ICT-diensten.

Meer info

Conclusies Algemene Rekenkamer

Aanbevelingen Algemene Rekenkamer

Reactie minister

Nawoord Algemene Rekenkamer

Vraag 2 Vervangingspotentieel

Hoofdstuk 3            Softwarelandschap is com- plex geheel: veel onderdelen, die via veel standaarden gegevens uitwisselen met elkaar en met buitenwereld. Ministeries maken al veel gebruik van open technologie.

Keuze tussen open en gesloten technologie is niet zwart-wit. Softwaremarkt biedt veel mengvormen aan. Bovendien ontstaan er continu nieuwe versies en applicaties, open en gesloten en alles daartussen. Er is dus geen specifiek deel van softwarelandschap aan te wijzen dat «open» gemaakt moet worden. Keuze voor software is veel meer dan louter een keuze tussen open en gesloten technologie.

Per organisatie is aan te wijzen welk deel van het softwarelandschap «open» gemaakt kan worden.

Minister wil complexiteit, verwevenheid en leveranciersafhankelijk-heid van ICT-omgevin-gen verminderen. Perspectief kabinetsbeleid is daarom: lange termijnvoordelen van betere samenwerking en efficiëntere gegevensuitwisseling.

Minister maakt niet duidelijk hoe en volgens welk tijdpad hij zijn ambities wil realiseren. In dit verband wijzen wij nogmaals op onze concrete aanbevelingen ten aanzien van zijn rol als coördinerend minister.

Vraag 3 Softwarekosten en mogelijke besparingen

§ 3.3.3 en                Licentiekosten vormen hoofdstuk 4            slechts een beperkt deel van totale softwarekosten. Eventuele besparingen op softwarekosten van ministeries kunnen alleen in concrete situaties worden bepaald door kosten-baten-alyses te maken in kader van uitvoering van softwarebe-leid en daarbij behorende verwervingsstrategie. Dergelijke analyses moeten uitgaan van totale kosten en ook rekening houden met aanschafkosten, waaronder licentiekosten, en kosten voor implementatie, exploitatie (waaronder beheer) en onderhoud van software.

Meer info                 Conclusies Algemene                   Aanbevelingen Algemene            Reactie minister                      Nawoord Algemene

Rekenkamer                                    Rekenkamer                                                                                       Rekenkamer

Vraag 4 Termijn voor introductie

§ 3.2.1, § 3.3.1, Overgang van gesloten naar

§ 3.3.4 en                 open technologie is niet op

§ 3.3.6                      bepaald moment afgerond.

Wel zijn er verschuivingen van gesloten naar open technologie mogelijk. Deze verschuivingen en termijn waarop die kunnen plaatsvinden hangen af van:

• • 

  informatiestrategie en ICT-strategie;

• • 

  uitgangssituatie («installed base»);

• • 

  ontwikkelingen op softwaremarkt.

Vraag 5 Voor- en nadelen, kansen en risico’s en voorwaarden voor implementatie

Hoofdstuk 3 en Voor- en nadelen, kansen, hoofdstuk 4             risico’s, en voorwaarden zijn niet te koppelen aan open standaarden of open- sourcesoftware, maar hangen sterk af van concrete situatie, standaard in kwestie en specifieke softwareproduct. Vraag of open alternatieven aanwezig zijn kan alleen worden beantwoord door onderzoek naar specifieke omstandigheden in concrete situaties en door marktonderzoek te doen naar beschikbare softwareproducten en

-diensten.

Meer info

Conclusies Algemene Rekenkamer

Aanbevelingen Algemene Rekenkamer

Reactie minister

Nawoord Algemene Rekenkamer

Vraag 6 Welke aanbevelingen kan de Algemene Rekenkamer doen?

Hoofdstuk 5

Ministers van BZK en van EL&I en vakministers moeten vanuit strategische doelen werken, rekening houdend met installed base en marktontwikkelingen. ICT-vraagstukken puur vanuit kostenbesparingen benaderen is te beperkt. Kostenbewustzijn is een vereiste maar is niet voldoende.

CIO Rijk moet samen met departementale CIO’s sleutelrol krijgen in strategisch proces. Hij moet rol en bevoegdheden krijgen die consistent ICT-beleid van rijksoverheid mogelijk maken. Bij deze benadering dient wel te allen tijde rekening te worden gehouden met functiespecifieke behoeften op ICT-gebied die van toepassing tot toepassing en van departement tot departement kunnen verschillen.

Positie CIO Rijk en departementale CIO’s is onlangs versterkt.

Minister van BZK moet nagaan in hoeverre ministeries hun softwarekeuzes maken op basis van strategische doelstellingen op ICT-gebied en daar criteria voor expliciteren. Hij moet er ook voor zorgen dat alle ministeries medio 2012 aan deze criteria voldoen. Voorts moet minister criteria en operationalisering daarvan periodiek tegen het licht houden en zo nodig bijstellen.

Overheid zou voor de invulling van deze criteria ook gebruik moeten maken van kennis en expertise van personen uit andere branches dan overheid. Minister van BZK moet Tweede Kamer regelmatig informeren over ICT-strate-gie en voortgang daarvan.

We constateren dat minister niet ingaat op aanbevelingen over zijn rol als coördinerend minister. Evenmin geeft hij aan of en hoe hij Tweede Kamer zal voorzien van informatie over ICT-strategie en voortgang daarvan.

BIJLAGE 2 LIJST MET OPEN STANDAARDEN VOOR PAS TOE OF LEG UIT-PRINCIPE

Hieronder staat de lijst met open standaarden waarvoor het pas toe of leg uit-principe van toepassing is van het Forum standaardisatie per 16 december 2010.

NEN-ISO/IEC 27001:2005 nl

NEN-ISO/IEC 27002:2007 nl

SETU standaard

Uitwisselings Formaat (StUF)

eXtensible Business Reporting Language (XBRL) v2.1

Aquo-standaard

Dimensions v1.0

(IPv4)

(IPv6)

ebMS en WUS

ebMS en WUS zoals nader gespecificeerd binnen de OSB

Internet Protocol version 6 en Internet Protocol version 4

ISO 32000-1:2008 Part 1: PDF 1.7

ISO/IEC 15948:2003, Portable Network Graphics (PNG) Specification

(Second Edition)

ISO/IEC IS 10918-1, Joint Photographic Experts Group (JPEG)

NEN-ISO 19005-1:2005 EN (PDF/A-1)

NTA 2035:2009 E-portfolio NL

Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH)

Open Document Format ISO 26 300

Security Assertion Markup Language (SAML)

Web Services for Remote Portlets (WSRP)

Webrichtlijnen zoals vastgelegd in het Besluit kwaliteit Rijksoverheids- websites, ministerraad 30 juni 2006⁶²

⁶² Naast technische onderdelen bevatten de webrichtlijnen ook onderdelen die gaan over zaken als toegankelijkheid en gebruiksvriendelijkheid.

BIJLAGE 3 LIJST MET GANGBARE OPEN STANDAARDEN

Hieronder staat de lijst met gangbare open standaarden van het Forum standaardisatie per 16 december 2010.

EI standaarden

Informatie Publicatie Model Vergunningen (IPM)

Internet Calendaring and Scheduling Core Object Specification

(iCalendar)

vCard (VCF)

Cascading Style Sheets (CSS)

Comma-Separated Values (CSV)

Domain Name System (DNS)

Dynamic Host Configuration Protocol (DHCP)

Extensible Stylesheet Language Transformations (XSLT)

File Transfer Protocol (FTP)

HTTP over TLS (HTTPS)

HyperText Markup Language (HTML)

Hypertext Transfer Protocol (HTTP)

Internet Message Access Protocol (IMAP)

Internet Printing Protocol (IPP)

ISO 8601:2004 (Datum en tijd)

Lightweight Directory Access Protocol (LDAP)

MD5 message-digest algorithm (MD5)

Network News Transfer Protocol (NNTP)

Network Time Protocol (NTP)

Post Office Protocol versie 3 (POP3)

Real-time Transport Protocol (RTP)

Scalable Vector Graphics (SVG)

Security Architecture for the Internet Protocol (IPsec)

Session Initiation Protocol (SIP)

Simple Mail Transfer Protocol (SMTP)

Simple Network Management Protocol (SNMP)

Simple Object Access Protocol (SOAP)

Structured Query Language (SQL)

Styles Layer Descriptor (SLD)

Transmission Control Protocol / Internetprotocol (TCP/IP)

Transport Layer Security (TLS)

Uniform Resource Identifier (URI)

Uniform Resource Locator (URL)

Uniform Resource Names (URN)

Universal Description Discovery Integration (UDDI)

User Datagram Protocol (UDP) / Internet Protocol (IP)

UTF-8

Web Services Description Language (WSDL)

XML

BIJLAGE 4 DEFINITIE OPEN STANDAARD

In de omschrijving door het Forum standaardisatie is een standaard volledig «open» als:⁶³

• 1. 

  de standaard is goedgekeurd en zal worden gehandhaafd door een non-profit organisatie, en de lopende ontwikkeling gebeurt op basis van een open besluitvormingsprocedure die toegankelijk is voor alle belanghebbende partijen (consensus of meerderheidsbeschikking enz.);

• 2. 

  de standaard is gepubliceerd en over het specificatiedocument van de standaard vrijelijk kan worden beschikt of het is te verkrijgen tegen een nominale⁶⁴ bijdrage; het moet voor een ieder mogelijk zijn om het te kopiëren, beschikbaar te stellen en te gebruiken om niet of tegen een nominale prijs;

• 3. 

  het intellectuele eigendom – m.b.t. mogelijk aanwezige patenten – van (delen) van de standaard is onherroepelijk⁶⁵ ter beschikking gesteld op een «royalty-free» basis;

• 4. 

  er zijn geen beperkingen omtrent het hergebruik van de standaard.

⁶³  Bron: http://www.open-standaarden.nl/ open-standaarden/wat-zijn-open-standaarden/ (geraadpleegd op 2 augustus, 2010).

⁶⁴  We gaan ervan uit dat hiermee bedoeld wordt: een redelijke vergoeding van kosten die feitelijk gemaakt zijn voor het beschikbaar stellen van de norm. De kosten die gemaakt zijn voor de ontwikkeling van de standaard vallen er dus buiten.

⁶⁵  De ter beschikking stelling op «royalty-free» basis kan dus naderhand niet meer worden teruggedraaid.

66

BIJLAGE 5 DEFINITIE OPENSOURCESOFTWARE

Een bekende definitie van het begrip opensourcesoftware is die van het «Open Source Initiative» (OSI). Deze definitie bestaat uit tien criteria (OSI, 2010b).

1      Vrije verspreiding De licentie legt partijen geen beperkingen op om de software te verkopen of weg te geven als onderdeel van een softwarepakket dat componenten bevat die afkomstig zijn uit verschillende bronnen. De licentie vereist niet dat er royalty’s of andere vergoedingen moeten worden betaald.

2      Broncode moet meegeleverd worden De broncode moet worden meegeleverd met de software dan wel zonder kosten te downloaden zijn. De software moet zowel als uitvoerbaar programma als in de vorm van broncode verspreid mogen worden.

3      Afgeleide werken zijn toegestaan De licentie moet aanpassingen van de broncode en het maken van op de broncode gebaseerd nieuwe broncode toestaan; deze afgeleide werken mogen verspreid worden onder dezelfde licentievoorwaarden als die van de oorspronkelijke software.

4      Intact laten van de originele broncode mag als voorwaarde worden gesteld

Licenties mogen bepalen dat alleen de gecompileerde versie van de software mag worden aangepast. De aanpassingen mogen dan uitsluitend in de vorm van een «patch» worden verspreid. De originele broncode blijft in dit geval dus altijd ongewijzigd intact (vgl: http://nl.wikipedia.org/wiki/Open_Source_Definition).

5      Geen discriminatie tegen personen of groepen De licentie mag niet discrimineren tegen gebruikers of groepen.

6      Geen discriminatie tegen toepassingsgebied De licentie mag geen beperkingen opleggen aan het type activiteiten waarvoor de software wordt gebruikt.

7      Licentierechten gelden voor iedereen De rechten verbonden aan het programma moeten gelden voor iedereen naar wie het programma verspreid wordt, zonder de noodzaak voor de ontvanger om akkoord te gaan met een aanvullende licentie.

8      Onafhankelijkheid van specifieke producten

9      Geen beperkingen aan andere meegeleverde software De licentie mag geen beperkingen stellen aan andere software die samen met de software wordt verspreid. De licentie mag bijvoorbeeld niet bepalen dat alle andere gelijktijdig verspreide programma’s ook opensourcesoftware moeten zijn.

10    Technologie-neutraliteit Geen van de licentiebepalingen mag betrekking hebben op een bepaalde technologie of interface-stijl.

OSI is een non-profitorganisatie⁶⁶ die de taak op zich heeft genomen softwarelicenties te certificeren en daarmee te kwalificeren als «OSI certified open source». Deze certificering wordt breed geaccepteerd. Het OSI heeft 67 opensourcelicenties goedgekeurd (stand december 2010). Hiervan worden er in de praktijk echter slechts een beperkt aantal gebruikt. Veelgebruikte licenties zijn: GNU General Public License (GPL), Lesser GNU General Public License (LGPL), Affero GNU Public License

OSI is een «public benefit corporation», gevestigd in California, USA, zie OSI (2010a). (AGPL), Artistic License, Berkeley Software Distribution (BSD), Apache

Licence en Mozilla Public License (MPL). In Europees verband is de European Union Public Licence (EUPL) ontwikkeld.

In tabel 4 is weergegeven welke van de hiervoor genoemde licenties het mogelijk maken om opensourcesoftware te verspreiden in combinatie met closedsourcesoftware.⁶⁷ De licenties met «Nee» bevatten een copyleft-bepaling. Preciezer gezegd: de licenties met «Nee» bevatten een sterke copyleft-bepaling, die met «Ja» hebben zijn of non-copyleft licenties, of hebben een zwakke copyleft-bepaling.⁶⁸

Tabel 4 Licenties die wel of niet toestaan open- en closedsource te combineren

Licentie                                    Open broncode te combineren met closedsourcesoftware?

⁶⁷  http://inventarisoss.smals.be/nl/112-rch.html.

⁶⁸  Zie voor dit onderscheid Aimé (2010).

BIJLAGE 6 FORMAT VOOR ONDERZOEK NAAR KOSTEN

Inleiding

Het kostenmodel is bedoeld als basis voor het verzamelen van de informatie die nodig is om antwoord te geven op de vraag wat de huidige kosten zijn van de bestaande softwareapplicaties waarvoor in principe OSS-varianten beschikbaar zijn. Het kostenmodel bestaat uit een algemeen onderdeel waarin een aantal organisatiebrede gegevens worden gevraagd en uit een softwarespecifiek onderdeel waarin gegevens per softwareapplicatie worden gevraagd.

Om de uitvraag per softwareapplicatie overzichtelijk en beperkt te houden hanteren we een indeling in softwarecategorieën. Hierbij is ondermeer gebruikgemaakt van inventarisaties van NOiV⁶⁹. Alleen de gegevens over alle softwareapplicaties die tot de softwarecategorieën horen, zowel maatwerk als standaardpakketten, zijn nodig voor de beantwoording van de onderzoeksvragen van dit onderzoek. Wellicht is de indeling in softwarecategorieën in het geval van uw ministerie minder voor de hand liggend. In dat geval overleggen wij graag met u over een alternatieve indeling als basis voor een bruikbaar kosteninzicht. Onderstaande tabel geeft aan welke algemene gegevens en welke gegevens per softwareapplicatie gevraagd worden. Toelichting op de algemene gegevens en de gegevens per softwareapplicatie volgen na de beide tabellen.

Gevraagde gegevens

⁶⁹ Bron: https://wiki.noiv.nl/xwiki/bin/view/ NOiV/OSS%20Apps%20List en https:// www.noiv.nl/files/2009/12/ Implementatiestrategie_cover.pdf, beide geraadpleegd op 14 september 2010.

Toelichting op gevraagde gegevens

Algemene gegevens

Toelichting

Totale omvang ICT-budget

Alle centrale en decentrale uitgaven in 2009 waaronder in elk geval:

• • 

  investeringen in en exploitatie van hardware en software

• • 

  intern en extern personeel voor ICT-infrastructuur, ICT-projecten en ICT-ondersteuning

• • 

  uitbestede ICT-diensten

• • 

  advisering rond ICT

Totale (organisatiebrede) personeelsomvang

Personeelsomvang in fte van de totale organisatie, inclusief eventuele intern verzelfstandigde eenheden.

Mate van OSS-gebruik

We onderscheiden de volgende vier categorieën:

• • 

  vrijwel niet

• • 

  beperkt

• • 

  intensief

• • 

  overwegend

Totale kosten softwarelicenties verworven in de afgelopen vijf jaar.

Totaalbedrag van licentiekosten voor softwarelicenties die de afgelopen vijf jaar verworven zijn. Dit is met inbegrip van kosten die via derden bij u in rekening worden gebracht.

Gegevens per softwareapplicatie Toelichting

Naam van softwareapplicatie

Productnaam plus versienummer van het softwarepakket. Indien er sprake is van een maatwerkpakket de aanduiding «maatwerk» toevoegen.

Softwarecategorie

Keuze uit:

• • 

  Besturingssystemen

• • 

  Kantoorapplicaties (tekstverwerking, spreadsheets, etc.)

• • 

  E-mail

• • 

  Web-browser

• • 

  ERP

• • 

  CRM

• • 

  Geografische Informatiesystemen

• • 

  Content Management Systemen

• • 

  webontwikkeling

• • 

  Databasemanagementsystemen

Naam leverancier

De naam van de leverancier van de softwareapplicatie.

Aantal gebruikerslicenties

Het aantal gebruikerslicenties dat de organisatie in totaal heeft voor de betreffende softwareapplicatie.

Jaarlijkse kosten per licentie

Jaarlijkse kosten per gebruikerslicentie. Indien er sprake is van meerdere verschillende soorten licenties die per soort ook andere kosten hebben dient per licentiesoort te worden gespecificeerd. Verschillende soorten licenties kunnen zijn «concurrent user licentie», «named user licentie», of licenties per device.

Jaarlijkse kosten van onderhoudscontract

Jaarlijkse kosten van het contract, of de service level agreement (SLA), die met de (externe) dienstverlener is afgesloten. In onderhoudscontracten worden doorgaans zaken geregeld rondom het beheer van de software en aanpassingen daarop. Indien de gebruikerslicenties onderdeel vormen van het onderhoudscontract dient dat hier te worden aangegeven.

% Open Source / Closed Source

Sommige software bestaat uit zowel een gesloten source deel als een open source deel. Hier kan een indicatie van de verhouding van open source en gesloten source van de software worden aangegeven.

In gebruik sinds (datum)

Datum dat de software in productie is genomen.

In gebruik tot (datum)

Verwachte datum dat de software uit productie wordt genomen.

Opmerkingen

Bij sommige aspecten kunnen mogelijk geen eenduidige gegevens worden gegeven. Die kunnen hier worden uitgelegd.

BIJLAGE 7 GERAADPLEEGDE EXPERTS

Expertmeeting J. D. Bos J. Flippo

Drs. C. Franke

National Technology Officer, Microsoft Nederland

Programmamanager I-aanbod Rijk, Ministerie van

BZK

Algemeen directeur Franke Interim Management

BV

Drs. ing. B. Van Graft Ministerie van Veiligheid en Justitie

Drs. A. Kamphuis CISA CISM B. Linders Mr. W. Schop

Prof. dr. C. Verhoef

Ir. M.P.F. Vloemans

Drs. N.J. Westpalm van Hoorn

Holland Open

ICT^~Office

Programmamanager Nederland Open in

Verbinding

Hoogleraar Informatica, Vrije Universiteit

Amsterdam

Voorzitter Open Source Software Leveranciers

Organisatie

Voorzitter Forum Standaardisatie

Individuele gesprekken Drs. J. Attema Drs. M. Chen A.A.J. Dijkhuijs F.R. Groustra MSc Mr. M. W. I. Hillenaar

Mr. drs. W. van Holst

J. Korpel

Mr. H.M. Leether

Dr. B. van Lier MCM

CMC

Ir. P.H. Minnecré

Ing. S.A. Mittertreiner

Ing. F. Mous

J. Mulder

Drs. B. L. E. van

Oranje

Mr. M.H. Paapst

A. van Polen

B. Prehn Drs. A. Reinders Drs. D. van Roode S.J. Rozema Mr P.C. van Schelven Dr. ir. J. Visser M.J. Wildvank

Adviseur ECP EPN

Bestuursadviseur Gemeente Amsterdam

Ministerie van Veiligheid en Justitie

Ministerie van Veiligheid en Justitie

Directeur Informatiebeleid Rijk Ministerie van

BZK/CIO Rijk

Juridisch adviseur, Nederland Open in Verbinding

Onderzoeker, Nederland Open in Verbinding

Legal Councel bedrijfsvoering Justitie, Ministerie van Veiligheid en Justitie

Account Director Government, Centric

Projectmanager Nederland Open in Verbinding

Hoofd I&A van NL Octrooicentrum

Ictivity

ICT^~Office

Levi 9 Global Sourcing

Docent/juridisch onderzoeker Rijksuniversiteit

Groningen

Hoofd ICT-beheer (voormalig) Ministerie van

Volkshuisvesting, Ruimtelijke Ordening en Milieu

Beleidsmedewerker gemeente Amsterdam

Senior Beleidsmedewerker Ministerie van BZK

Manager Public Affairs ICT^~Office

Ministerie van Financiën, Belastingdienst

Juridisch Adviseur ICT^~Office

Software Improvement Group

Software Improvement Group

BIJLAGE 8 BEGRIPPEN EN AFKORTINGEN

Applicatieserver Architectuur

BOR Broncode

BZK

Business case

CIO Community

Copyleft-bepaling

CTO

DMS .doc

.docx

ECM

EL&I

Een applicatieserver is een voorziening, bestaande uit software- en hardware, die de applicaties ter beschikking van de eindgebruiker stelt Het geheel aan principes en modellen dat richting geeft aan ontwerp en realisatie van de processen, organisatorische inrichting, informatievoorziening en technische infrastructuur van een organisatie. (Berg en Steenbergen, 2004) Bureau Onderzoek Rijksuitgaven van de Tweede Kamer

In de broncode legt een programmeur de instructies vast die de computer moet uitvoeren. Broncode kan door de mens gelezen worden maar moet worden vertaald (gecompileerd) in «machinetaal» om de instructies te kunnen laten uitvoeren door een computer.

(Ministerie van) Binnenlandse Zaken en Koninkrijksrelaties

Zakelijke rechtvaardiging van (bijvoorbeeld) een project

Chief Information Officer

In dit rapport: een groep personen die meer of minder formeel georganiseerd samenwerken en die open standaarden of opensourcesoftware ontwikkelen, aanpassen en onderhouden en om niet ter beschikking stellen. Deze bepaling verplicht de gebruiker om bij eventuele verspreiding van de gewijzigde broncode, al dan niet in combinatie met closedsourcesoftware, dit ook weer onder dezelfde licentie te doen.

Chief Technology Officer. Functie op strategisch niveau van de organisatie. De CTO is verantwoordelijk voor de vakinhoudelijke aspecten bij de besluitvorming van inzet van technologie (in dit rapport: de inzet van ICT). Documentmanagementsysteem Gesloten standaard van Microsoft Office voor reviseerbare documenten (Office 2003 en ouder) Op open standaarden gebaseerde standaard van Microsoft Office voor reviseerbare documenten (Office 2007 en nieuwer)

ECM komt kort gezegd neer op beheer en beschikbaarstelling van de in de organisatie aanwezige verzameling aan ongestructureerde informatie zoals documenten en andere vormen van content, waaronder videomateriaal.

(Ministerie van) Economische Zaken, Landbouw en Innovatie

ERP

EZ

GSM HRM HTML Intranet

IP JPEG

KA LinkedIn

Middleware

NOiV MPEG-1 layer 3

MPEG-4 ODF

OGG

Onder architectuur OOXML

OSOR.eu

OSS

OSSLO

Patch

PDF

RWT SAP

ERP-pakketten zijn softwarepakketten met een sterk geïntegreerde functionaliteit waarmee in principe de gehele bedrijfsvoering kan worden ondersteund. Met een dergelijk systeem is het eenvoudiger om financiële middelen met andere bedrijfsvoeringsaspecten in verband te brengen dan met «losse» systemen. ERP staat Electronic Resources Planning

(Ministerie van) Economische Zaken (vanaf 14 oktober 2010: EL&I) Global System for Mobile communications Human Resource Management Hypertext Markup Language Een intranet is de interne variant van een externe website

Internet protocol

JPEG is een open standaard voor het opslaan van afbeeldingen. JPEG staat voor Joint Photographic Experts Group Kantoorautomatisering

Social networksite die vooral gebruikt wordt in de zakelijke sfeer.

Algemene term om software aan te duiden die applicaties en/of systeemsoftware met elkaar verbindt.

Nederland Open in Verbinding MPEG-1 layer 3 is een gesloten standaard die gebruikt wordt om geluid te comprimeren. De veel gebruikte afkorting is MP3.

MPEG-4 is een gesloten standaard die veelal wordt gebruikt voor compressie van videodata Open Document Format is een open standaard voor het bewaren en/of uitwisselen van tekstbestanden, rekenbladen, grafieken en presentaties OGG is een open standaard voor audio- en videobestanden Op basis van architecturen

Office Open XML is een open standaard bestandsformaat voor Office-documenten OSOR.eu is een platform bedoeld om de ontwikkeling en uitwisseling van OSS applicaties voor gebruik in de publieke sector te ondersteunen. OSOR staat voor Open Source Observatory and Repository Opensourcesoftware

Open Source Software Leveranciers Organisatie Een patch is een aanpassing van een programma tussen de reguliere updates door. Patches dienen in het algemeen om beveiliginsgproblemen op te lossen (security patches) of fouten in het programma te reparenen (bug fixes) PDF is een standaard voor de uitwisseling van niet-reviseerbare elektronische documenten. PDF staat voor Portable Document Format Rechtspersoon met een wettelijke taak SAP staat voor Systems, Applications, and Products in Data Processing en is een ERP-systeem

Systeemsoftware

TCO

TIFF TCP/IP

Webserver XML

zbo

Software die de computer in staat stelt applicaties te laten draaien. Hieronder vallen onder meer besturingssystemen, databasemanagementsystemen en software die de opslag van gegevens verzorgt.

TCO (Total Cost of Ownership) is een definitie van kosten die alle directe en indirecte kosten van een product omvat over de hele levenscyclus van het product van verwerving tot en met afstoting. TIFF is een open standaard voor opslag van beelden. TIFF staat voor Tagged Image File Format Transmission Control Protocol / Internetprotocol is een groep «netwerkprotocollen» (netwerkstandaarden) die onder meer het internetverkeer ondersteunen.

Webservers verzorgen die het intra- en internetverkeer

Extensible Markup Language, een standaard die bestaat uit een verzameling regels die men kan gebruiken om data volgens een eenduidige systematiek te beschrijven, zodat applicaties de data correct kunnen verwerken Zelfstandig bestuursorgaan

LITERATUUR

Wet- en regelgeving

Auteurswet. Stb. 2004, 410.

Instellingsbesluit College en Forum Standaardisatie. Besluit van de Minister van Economische Zaken van 27 maart 2006, nr. 6022730, tot instelling van het College Standaardisatie en het Forum Standaardisatie (instellingsbesluit College en Forum Standaardisatie). Stcrt. 2006, 70, 7 april 2006.

Instellingsbesluit College en Forum Standaardisatie 2010. Besluit van de Minister van Economische Zaken van 11 maart 2010, nr. ETM/IT 10040343 tot instelling van het College Standaardisatie en het Forum Standaardisatie 2010 (Instellingsbesluit College en Forum Standaardisatie 2010). Stcrt. 2010 4499, 31 maart 2010.

Instructie rijksdienst bij aanschaf ICT-diensten of ICT-producten. Besluit van de Staatssecretaris van Economische Zaken van 8 november 2008, nr. WJZ/8157380, tot vaststelling Instructie rijksdienst inzake aanschaf ICT-diensten en ICT-producten. Strct. 21 november 2008, nr. 837.

Publicaties

Aimé (2010). Thierry Aimé, A Practical Guide to Using Free Software in the Public Sector. Version 1.31, juni 2010. www.osor.eu/communities/eupl/ FAQ-LL-V131-EN.pdf, geraadpleegd op 25 december 2010.

Alfresco (z.j.). www.alfresco.com/, geraadpleegd op 3 januari 2011.

Algemene rekenkamer (2007a). Aanbesteding ICT-component P-Direkt. Tweede Kamer, vergaderjaar 2006–2007, 31 027, nr. 1. Den Haag: Sdu.

Algemene Rekenkamer (2007b). Lessen uit ICT-projecten bij de overheid: Deel A. Tweede Kamer, vergaderjaar 2007–2008, 26 643, nr. 100. Den Haag: Sdu.

Algemene Rekenkamer (2008). Lessen uit ICT-projecten bij de overheid: Deel B. Tweede Kamer, vergaderjaar 2007–2008, 26 643, nr. 130. Den Haag: Sdu.

Algemene Rekenkamer (2010). Informatiehuishouding van het Rijk. Tweede Kamer, vergaderjaar 2009–2010, 32 307, nr. 2. Den Haag: Sdu.

Algemene Rekenkamer (2010b). Brief van de Algemene Rekenkamer over onderzoek naar introductie van open source software bij de overheid. Tweede Kamer, vergaderjaar 2009–2010, 26 643, nr. 168. Den Haag: Sdu.

Berg en Steenbergen (2004). M. van den Berg en M. van Steenbergen. DYA^® Stap voor stap naar professionele enterprise-architectuur. Sogeti, 2004.

Bundesministerium des Inneren (2008). Migrationsleifaden; Leifaden für die Migration von Software. Bundesministerium des Innern, Referat IT 2, Berlin, april 2008. http://www.cio.bund.de/cln_102/DE/IT-Methoden/ Migrationsleitfaden/migrationsleitfaden_node.html, geraadpleegd op 3 januari 2011.

BZK en EZ (2003). Brief van de min BZK en de sts EZ over het programma «Open Standaarden en Open Source Software voor de overheid». Tweede Kamer, vergaderjaar 2002–2003, Niet-dossierstuk 2002–2003, bzk0300075.

BZK (2010). Brief van de staatssecretaris van Binnenlandse Zaken en Koninkrijksrelaties. Tweede Kamer, vergaderjaar 2009–2010, 26 643, nr. 158. Den Haag: Sdu.

Casadesus-Masanell en Llanes (2010). R. Casadesus-Masanell en G. Llanes, Mixed Source. Working Paper 10–022.

Database Magazine (2010). DBMS markt gedomineerd door Microsoft en Oracle. http:// www.dbm.nl/Nieuws/69562/%E2%80%98DBMS-markt-gedomineerd-door-Microsoft-en-Oracle%E2%80%99, geraadpleegd op 17 januari 2011.

Ecorys (2007). Handreiking voor kostenbatenanalyses voor ICT projecten. Opdrachtgever: Ministerie van Economische Zaken. Opgesteld door Ecorys, Research en Consulting. Rotterdam, december 2007.

EZ en BVK (2005). Brief ministers over de automatisering van de publieke sector. Tweede Kamer, vergaderjaar 2004–2005, 26 643, nr. 67. Den Haag: Sdu.

EZ (2006a). Instellingsbesluit College en Forum Standaardisatie. Staatscourant, 7 april 2006, nr. 70/pag. 8.

EZ (2006b). Brief minister ter aanbieding van «Nederland in verbinding, Beleidskader voor de elektronische communicatie». Tweede Kamer, vergaderjaar 2005–2006, 26 643, nr. 81. Den Haag: Sdu.

EZ (2006c). Brief minister over het gebruik van open source software en open standaarden door de publieke sector. Tweede Kamer, vergaderjaar 2006–2007, 26 643, nr. 82. Den Haag: Sdu.

EZ (2007). Nederland Open in Verbinding; Een actieplan voor het gebruik van Open Standaarden en Open Source Software bij de (semi-)publieke sector. 20-09-2007, Bijlage bij Tweede Kamer, vergaderjaar 2006–2007, 26 643, nr. 98, Den Haag: Sdu.

EZ (2010). Tweede Voortgangsrapportage Nederland Open in Verbinding Tweede Kamer, vergaderjaar 2009–2010, bijlage bij kamerstuk 26 643, nr. 163. Den Haag: Sdu.

Europese Commissie (2010). «Towards interoperability for European public services», Mededeling COM(2010) 744 final i, Annex 2. Brussels, 16-12-2010.

Financiën (2008a). Brief minister met lijst van documenten met betrekking tot de aanbesteding van het project GOUD. Tweede Kamer, vergaderjaar 2007–2008, 26 643, nr. 111. Den Haag: Sdu.

Financiën (2008b). Brief minister over aanbesteding project GOUD. Tweede Kamer, vergaderjaar 2007–2008, 26 643, nr. 120. Den Haag: Sdu.

Gartner (2008). Gartner Highlights Key Predictions for IT Organisations and Users in 2008 and Beyond. Press release 31 januari 2008. http:// www.gartner.com/it/page.jsp?id=593207. Geraadpleegd op 29 december 2010.

Kenniscentrum e-overheid, 2007. Nederlandse Overheid Referentie Architectuur; Samenhang en samenwerking binnen de elektronische overheid. Kenniscentrum e-overheid, 25 april 2007.

Kenniscentrum e-overheid, 2008. Model Architectuur Rijksdienst; MARIJ 1.0. Kenniscentrum e-overheid, 14 juli 2008.

Laurent (2004). Andrew M. St. Laurent, Understanding Open Source and Free Software Licensing. O’Reilly.

NOiV (2010). Handreiking multimediaformaten; Naar optimale toegang van audio, video en afbeeldingen. Nederland Open in Verbinding. Den Haag, juni 2010.

OCG 2010. Business case. The Office of Government Commerce, HM Treasury (verenigd Koninkrijk) http://www.ogc.gov.uk/ documentation_and_templates_business_case.asp. Geraadpleegd op 29 december 2010.

OSI (2010a). «About the Open Source Initiative». www.opensource.org/ about, geraadpleegd op 24 december 2010.

OSI (2010b). The Open Source Definition (Annotated); Version 1.9. www.opensource.org/osd.html (geraadpleegd op 24 december 2010).

Paapst 2010. M.H. paapst (mondelinge mededeling).

Tweede Kamer (1999). Verslag algemeen overleg over onder meer de financiële aspecten van ICT in het onderwijs. Tweede Kamer, vergaderjaar 1998–1999, 25 733, nr. 29. Den Haag: Sdu.

Tweede Kamer (2001). Vragen van de leden Lambrechts en Bakker. Tweede Kamer, vergaderjaar 2001–2002, 25 733, nr. 61. Den Haag: Sdu.

Tweede Kamer (2002). Motie van het lid Vendrik.Tweede Kamer, vergaderjaar 2002–2003, 28 600 XIII, nr. 30. Den Haag: Sdu.

Tweede Kamer (2004a). Vragen en antwoorden over de Rijksbrede ICT-agenda. Tweede Kamer, vergaderjaar 2003–2004, 26 643, nr. 54. Den Haag: Sdu.

Tweede Kamer (2004b). Vragen van het lid Van Dam. Tweede Kamer, vergaderjaar 2004–2005, nr. 243. Den Haag: Sdu.

Tweede Kamer (2005). Vragen van de leden Vendrik, Gerkens en Van Dam. Tweede Kamer, vergaderjaar 2004–2005, nr. 2090. Den Haag: Sdu.

Tweede Kamer (2007). Gewijzigde motie van de leden Aptroot en Vendrik. Tweede Kamer, vergaderjaar 2006–2007, 26 643, nr. 88. Den Haag: Sdu.

Tweede Kamer (2008a). Motie van het lid Aptroot. Tweede Kamer, vergaderjaar 2007–2008, 26 643, nr. 114 . Den Haag: Sdu.

Tweede Kamer (2008b). Motie van het lid Vos. Tweede Kamer, vergaderjaar 2007–2008, 26 643, nr. 115. Den Haag: Sdu.

Tweede Kamer (2010a). Verslag algemeen overleg op 12 mei 2010 over onder meer grote ICT-projecten. Tweede Kamer, vergaderjaar 2009–2010, 26 643, nr. 159. Den Haag: Sdu.

Tweede Kamer (2010b). Motie van het lid Gerkens c.s. (onderzoek door Algemene Rekenkamer). Tweede Kamer, vergaderjaar 2009–2010, 26 643, nr. 156. Den Haag: Sdu.

Tweede Kamer (2010c). Brief van de vaste commissie voor Binnenlandse Zaken en Koninkrijksrelaties. Tweede Kamer, vergaderjaar 2009–2010, 26 643, nr. 165. Den Haag: Sdu.

Tweede Kamer (2010d). Motie van het lid Gerkens c.s. (overschakeling naar IPv6). Tweede Kamer, vergaderjaar 2009–2010, 26 643, nr. 151. Den Haag: Sdu.

Tweede Kamer (2010). Behandeling brief vaste commissie voor BZK t.g.v. onderzoeksvoorstel over afbouw gesloten standaarden en introductie van open source software bij Rijksoverheid (26 643, nr. 165). Tweede kamer, Handelingen 2009–2010, nr. 98, blz. 7990.