32 679 Open standaarden en opensourcesoftware bij de Rijksoverheid

Nr. 5 LIJST VAN VRAGEN EN ANTWOORDEN

Vastgesteld 15 juni 2011

De commissie voor de Rijksuitgaven¹ en de vaste commissie voor Binnenlandse Zaken² hebben een aantal vragen voorgelegd aan de Algemene Rekenkamer over de brief van 15 maart 2011 inzake het rapport van de Algemene Rekenkamer «Open standaarden en opensourcesoftware bij de Rijksoverheid» (Kamerstuk 32 679, nr. 2)

De Algemene Rekenkamer heeft deze vragen beantwoord bij brief van 15 juni 2011. Vragen en antwoorden zijn hierna afgedrukt.

De voorzitter van de commissie voor de Rijksuitgaven,

Van Gerven

De voorzitter van de vaste commissie voor Binnenlandse Zaken,

Dijksma

De adjunct-griffier van de commissie voor de Rijksuitgaven,

Clemens

1³

Kan de Algemene Rekenkamer de toegepaste onderzoeksmethodiek aangeven? Zo nee, waarom niet? Zo ja, kan deze methodiek worden toegelicht en kan worden aangegeven waarop deze is gebaseerd? Is de gehanteerde methodiek afhankelijk geweest van het geconstateerde beperkte beeld op de ICT-uitgaven van de overheid?

In de paragrafen 1.3, 4.1, 4.2.1 en 4.3.1 van het rapport gaan wij in op de onderzoeksmethodiek. U vraagt om een aanvullende toelichting. Wij zijn van start gegaan met een theoretisch, op de TCO (Total Cost of Ownership)-benadering gebaseerd model voor een kosten-batenanalyse. De TCO-benadering is gebaseerd op 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. In beginsel maakt dit model het mogelijk een vergelijking te maken tussen de kosten en baten van de huidige closedsourcesoftware en de kosten en baten van opensource alternatieven. Zoals we aangeven in § 4.3.1 stuitten wij bij het maken van een dergelijke vergelijking echter op belangrijke beperkingen die onder meer te maken hebben met het beschikbare cijfermateriaal. Het theoretische model hebben we daarom moeten inruilen voor een meer pragmatische aanpak. Om tot een indicatief beeld van de huidige softwarekosten te komen zijn we nagegaan van welke kostencomponenten de ministeries de hoogte wel (indicatief) konden aangeven. Dit zijn de licentiekosten en onderhoudskosten van de huidige software en de totale ICT-kosten van het ministerie.

2 en 24

Maakt de Algemene Rekenkamer zelf gebruik van open of gesloten software? In hoeverre voldoet de Algemene Rekenkamer aan het actieplan Nederland Open in Verbinding (NOiV)?

Hoe staat de Algemene Rekenkamer als instituut zelf ten aanzien van open ICT-beleid?

De Algemene Rekenkamer handelt in de lijn van het kabinetsplan. Wij hebben zelf niet a priori een standpunt over de wenselijkheid van open technologie. Technologische argumenten en kostenoverwegingen moeten een plaats hebben in het proces van strategievorming en besluitvorming. Net als bij de ministeries zijn ook bij ons de mogelijkheden voor quick wins in termen van kostenbesparingen nog niet uitgeput maar wel beperkt in relatie tot de totale ICT-kosten, wat overigens niet wegneemt dat dergelijke alternatieven de moeite waard kunnen zijn. We zijn ons dan ook actief en nadrukkelijk aan het oriënteren op wat er op dit vlak mogelijk en voor ons haalbaar is bij de verwerving van nieuwe softwarefunctionaliteit. Verder wegen we bij vervanging van bestaande systemen de mogelijkheden van open en gesloten ICT technologie zorgvuldig, zakelijk en zonder vooroordelen tegen elkaar af.

3 en 15

Is de Algemene Rekenkamer van mening dat er geen duidelijke financiële overzichten bij de ministeries aanwezig zijn, waardoor niet inzichtelijk is hoeveel waaraan is uitgegeven en gaat worden op het gebied van ICT? Is de Algemene Rekenkamer van mening dat deze overzichten er wel zouden moeten zijn? Beschikt de Algemene Rekenkamer van de eigen organisatie over een dergelijk overzicht? Is dit meegenomen in het onderzoek?

De Algemene Rekenkamer stelt dat een goed beeld op de ICT-uitgaven van de overheid ontbreekt. Wat is er volgens de Algemene Rekenkamer voor nodig om een goed beeld te krijgen van de ICT-uitgaven van de overheid? Wat zouden ministeries kunnen doen om wel een goed beeld te krijgen van de integrale ICT-kosten? In welke mate heeft het ontbreken van een goed beeld van de ICT-uitgaven het onderzoek van de Algemene Rekenkamer beperkt?

Wij vinden het vanzelfsprekend dat bij de ministeries financiële overzichten aanwezig zijn die duidelijk maken hoeveel waaraan is uitgegeven op het gebied van ICT en dat er ramingen zijn van toekomstige uitgaven. Tegelijkertijd merken we op dat dit volgens ons niet automatisch betekent dat de financiële administratie zo moet zijn ingericht dat de vragen naar kosten en baten die in ons onderzoek aan de orde waren op eenvoudige wijze te beantwoorden zijn. Ministeries stemmen hun administratie af op de eigen systematiek van planning en control, de Rijksbegrotingsvoorschriften en de eisen voor begroting en verantwoording in de comptabele wet- en regelgeving.

Wat wij wel van ministeries verwachten is dat zij inzicht hebben in aantallen licenties, bijvoorbeeld om te kunnen vaststellen dat het aantal licenties overeenkomt met het daadwerkelijke gebruik van de software.

Het onderzoek was gericht op de ministeries met inbegrip van de batenlastendiensten. De Algemene Rekenkamer vormt geen onderdeel van een ministerie en is dus niet meegenomen, evenmin als de andere Hoge Colleges van Staat. In de eigen bedrijfsvoering beschikt de Algemene Rekenkamer over een registratie van aantallen licenties. We houden van elke applicatie bij hoeveel en welk soort licenties we hebben. Wat financiële informatie betreft hebben we een overzicht van alle onderhoudskosten van applicaties. Een financieel overzicht in termen van totale licentiekosten (aanschaf en onderhoud) houdt de Algemene Rekenkamer niet bij. Dat overzicht is wel uit de financiële registratie en het contractenregister af te leiden.

Wij constateren dat er beperkingen in het beeld zijn, niet dat een goed beeld op de ICT-uitgaven van de overheid ontbreekt. De administraties van de ministeries, zowel de financiële administratie als die van het licentie- en applicatiebeheer, zijn er niet (specifiek) op ingericht om inzicht te bieden in de uitgaven op het gebied van ICT. Ministeries zijn daar ook niet toe verplicht. Zie ook § 4.1 (p.41) van het rapport. Voor een preciezer antwoord op de vraag wat de kosten van de huidige software zijn, zou meer gedetailleerd cijfermateriaal nodig zijn. Bij de inrichting van (financiële) administraties moet echter rekening worden gehouden met wat in het Angelsaksische taalgebied wordt aangeduid als «cost of costing»: het bijhouden van kostencomponenten brengt zelf ook weer kosten met zich mee. Van geen enkele administratie kan worden verwacht dat zij antwoord geeft op elke mogelijke onderzoeksvraag.

Vraag 4: deze vraag is beantwoord in combinatie met de vragen 32, 33 en 34.

5

Is het ICT-kostenmodel van voorzitter Marc Vloemans van de Open Source Software Leveranciersorganisatie (OSSLO) betrokken bij het onderzoek? Zo nee, waarom niet? Zo ja, waarom is hierover niets terug te lezen in het rapport?

Wij hebben het ICT-kostenmodel van de OSSLO niet toegepast, omdat het niet geschikt is om de totale ICT-kosten, softwarelicentiekosten en softwareonderhoudskosten in beeld te brengen.

Het kostenmodel is geschikt om een «business case» uit te werken waarin voor een bepaalde toepassing alle kosten van open en gesloten software met elkaar worden vergeleken. Dat was voor ons onderzoek niet relevant.

6

Is de mogelijkheid van het in eigen beheer ontwikkelen van software bekeken, en het mogelijke besparingspotentieel hiervan? Zo nee, waarom niet? Zo ja, waarom is hierover niets terug te lezen in het rapport?

Nee, dat is niet meegenomen. Ministeries onderkennen al jaren dat het zelf ontwikkelen van software een activiteit is die niet tot hun core business behoort en die beter overgelaten kan worden aan de markt, dus door leveranciers van open of gesloten oplossingen.

7

Klopt het dat het definitieve rapport al bij andere partijen buiten de Kamer, o.a. IBM en NOiV, beschikbaar was voordat het officieel openbaar werd? Met welk doel?

Hiervan is ons niets bekend, anders dan dat anderen berichten hierover hebben verspreid. Wij hebben bij dit rapport vanzelfsprekend onze gebruikelijke maatregelen voor vertrouwelijkheid getroffen en hebben nota’s van bevindingen en conceptversies van het rapport zoals gebruikelijk alleen via onze vaste contactpersonen bij de ministeries aangeboden, met het verzoek tot vertrouwelijke behandeling.

8

Is bij de kosten van closed software ook gekeken naar de kosten die gemaakt moeten worden om nieuwere versies van programma’s aan te schaffen, omdat oude versies niet meer onderhouden worden? Zo nee, waarom niet?

Deze kosten zijn wel meegenomen in de kwalitatieve beschrijving van kosten die in hoofdstuk 3 van het rapport aan de orde komen maar zijn niet gekwantificeerd. De reden voor het laatste is dat de hiervoor vereiste informatie niet eenvoudig uit de administratie te halen is (zie ook antwoord vraag 3). Het was derhalve onmogelijk deze informatie te achterhalen binnen de voor het onderzoek beschikbare tijd.

9

Is onderzocht wat opensourcesoftware mogelijk aan energiebesparing kan opleveren? Zo nee, waarom niet?

De onderzoeksvragen waren niet gericht op energiebesparing. In de beperkte doorlooptijd die voor het onderzoek beschikbaar was, konden wij niet nagaan of het plausibel is dat potentiële kostenbesparingen van energiebesparing zich in substantiële mate voordoen.

10 en 12

Kan de Algemene Rekenkamer aangeven hoe het mogelijk is, gegeven de onderzoeksvraag die door de Kamer is gesteld, dat de reikwijdte van het onderzoek zo beperkt is in de zin dat alleen de ministeries en de baten-lastendiensten erin zijn betrokken? Kan de Algemene Rekenkamer aangeven waarom de zelfstandige bestuursorganen en de andere overheden op geen enkele wijze zijn meegenomen, eventueel via het hanteren van diverse scenario's?

Waarom zijn de decentrale overheden buiten beschouwing gelaten? Welke pogingen zijn er gedaan om decentrale overheden alsnog bij het onderzoek te betrekken? Is een benadering van vrijwillige medewerking van deze decentrale overheden aan het onderzoek overwogen?

Omdat de doorlooptijd van het onderzoek beperkt was, hebben wij ervoor gekozen om ons te richten op de ministeries, met inbegrip van batenlastendiensten. Ministers dragen geen rechtstreekse verantwoordelijkheid voor de bedrijfsvoering van rwt’s en zbo’s. Zij zijn dus niet op basis van hun specifieke verantwoordelijkheid aanspreekbaar voor het softwarebeleid van die organisaties. De redenen waarom wij de decentrale overheden niet in het onderzoek hebben kunnen betrekken hebben wij per brief van 18 januari 2011 aan de Tweede Kamer gemeld (Tweede Kamer, vergaderjaar 2010–2011, 26 643, nr. 170), zie ook § 1.3.4 (Reikwijdte) van het onderzoeksrapport.

Het betrekken van decentrale overheden op vrijwillige basis hebben wij overwogen maar weer verworpen. De reden hiervoor is dat de doorlooptijd hiervan niet binnen het door de Tweede Kamer gevraagde tijdpad paste.

11

Kan worden aangegeven hoe het komt dat de Algemene Rekenkamer zo'n beperkte invalshoek ten aanzien van de kosten hanteert? Waarom worden vrijwel alleen de licentiekosten berekend? Is het de Algemene Rekenkamer niet bekend dat er ook kosteneffecten verbonden zijn aan leveranciersafhankelijkheid, zoals het niet kunnen overstappen naar nieuwere, betere en goedkopere systemen en software, lagere onderhoudskosten omdat er geen sprake is van een monopolist etc.? Hoe wordt dat beoordeeld?

In hoofdstuk 4 van het rapport is beschreven wat precies is onderzocht om de kosten in beeld te brengen. Het onderzoek betreft het deel van de software waar een opensourcevariant voor bestaat. Softwarekosten bestaan uit kosten voor aanschaf (waaronder licentiekosten), implementatie, exploitatie (waaronder beheer) en 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 ontbreken.

In hoofdstuk 3 (Het vraagstuk «open») besteden we ook in kwalitatieve zin aandacht aan een veelheid van kosteneffecten (zie § 3.2.3 en § 3.3.5). Waar kwantitatieve informatie niet voorhanden is past het ons als onderzoeksinstituut niet om hierover min of meer speculatieve uitspraken te doen.

Vraag 12: Deze vraag is beantwoord in combinatie met vraag 10, zie aldaar.

13

Klopt het dat niet in de eerste plaats en alleen de Kamer maar de Europese Commissie en het kabinet-Kok een initiërende rol vervulden?

Deze vraag hebben wij niet onderzocht. Wij hebben tien jaar parlementaire debatten in Nederland in beeld gebracht om het verzoek van de Tweede Kamer aan ons in perspectief te plaatsen.

14

Kan de stelling dat de overige kosten bij opensourcesoftware hoger kunnen zijn dan bij gesloten varianten nader onderbouwd worden? In hoeverre kan gesteld worden dat de kosten bij opensourcesoftware met betrekking tot de benodigde expertise bij installatie, transitie, documentatie, implementatie, ondersteuning en het beheer van de software over het algemeen hoger liggen dan bij gesloten varianten?

In algemene zin is niet vast te stellen dat de totale kosten die verbonden zijn aan opensourcesoftware per definitie lager (of hoger) liggen dan de totale kosten die verbonden zijn 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. Of de te verwachten kosten hoger of lager zullen zijn kan slechts per geval worden bekeken. Een voorbeeld van een situatie waarin de kosten hoger kunnen zijn is wanneer een closedsourcebesturingssysteem wordt vervangen door een open variant, terwijl voor een deel van de organisatie of van de applicaties het oorspronkelijke besturingssysteem operationeel moet worden gehouden. Voorop staat dat per geval een bewuste keuze gemaakt moet worden voor de beste oplossing voor die specifieke situatie.

Vraag 15: deze vraag beantwoorden we in combinatie met vraag 3, zie aldaar.

16

Is het mogelijk dat naast de besparingen die bij opensourcesoftware behaald kunnen worden met betrekking tot de licentiekosten, ook aanzienlijke besparingen gerealiseerd kunnen worden door voordelen op het gebied van kwaliteit, duurzaamheid, leveranciersonafhankelijkheid en technische deugdelijkheid?

Ja, in principe is dat mogelijk. Het is afhankelijk van de situatie en van geval tot geval zal moeten worden bekeken of die voordelen reëel zijn en wat de omvang is van de mogelijke besparingen die ermee gemoeid zijn (zie ook § 3.3.5 in het rapport).

17

In hoeverre kan gesteld worden dat het rapport van de Algemene Rekenkamer een vertekend beeld geeft van de totale besparingen die gerealiseerd kunnen worden door open standaarden en opensourcesoftware omdat het zich beperkt tot licentiekosten, terwijl potentiële additionele besparingen die te maken hebben met zaken als kwaliteit, duurzaamheid, leveranciersonafhankelijkheid en technische deugdelijkheid buiten beschouwing zijn gelaten? Hadden de berekende besparingen niet hoger gelegen als deze zaken wel meegenomen waren in het onderzoek?

Wij hebben geen totale besparing berekend omdat het beschikbare cijfermateriaal zich daar niet toe leent. Wel hebben wij pogingen daartoe ondernomen. In het rapport (p.45–46 en samenvatting p. 10) is aangegeven op welke problemen we zijn gestuit bij het berekenen van het theoretische besparingspotentieel.

18

Hoe is bepaald welk deel van de software in principe vervangbaar zou zijn door opensourcealternatieven? Hoe is die afbakening gemaakt? Op grond van welke informatie? Is dit een representatief deel van de binnen de overheid gebruikte software? Zo ja, waarom en op welke wijze is dit bepaald? Zo nee, waarom stelt de Algemene Rekenkamer dat daarmee het maximaal te behalen besparingspotentieel, zoals door de Algemene Rekenkamer berekend, is bereikt?

In het format waarmee we bij de ministeries informatie hebben opgevraagd is opgenomen dat het in het algemeen gaat om software als: besturingssystemen, kantoorautomatisering, e-mailapplicaties, webbrowsers, geografische informatiesystemen, contentmanagementsystemen, applicaties voor webontwikkeling en databasemanagementsystemen. Voor deze software zijn in principe ook opensourcevarianten beschikbaar. Voor deze afbakening is onder meer gebruik gemaakt van inventarisaties van NOiV⁴. Wij hebben op deze manier getracht een zo representatief mogelijk overzicht samen te stellen. Per ministerie hebben wij in gesprekken nader bekeken welke softwarecategorieën het vooral betrof in het geval van dat specifieke ministerie.

Wij hebben geen maximaal besparingspotentieel berekend (zie antwoord op vraag 17). Wij zeggen ook niet dat het maximaal behaalde besparingspotentieel bereikt is. Wel bevelen wij, het geheel overziende, aan geen al te hoge verwachtingen te hebben van de besparingsmogelijkheden door de ruimere toepassing van open standaarden en opensourcesoftware. Deze aanbeveling doen wij omdat volgens ons de mogelijkheden voor quick wins in termen van kostenbesparingen, hoewel allerminst uitgeput, beperkt zijn in relatie tot de totale ICT-kosten van de rijksoverheid. Met «allerminst uitgeput» doelen wij onder meer op de dynamiek van de ICT-markt waarin zich voortdurende nieuwe kansen voordoen.

19 en 20

Is er naar het oordeel van de Algemene Rekenkamer enig verband tussen het overstappen van gesloten op open technologie en de realisering van beleidsdoelen ten aanzien van bedrijfsvoering en marktordening?

Is de Algemene Rekenkamer van oordeel dat de keuze tussen open en gesloten technologie geen politieke aspecten heeft en dus niet behoort te worden gemaakt door het kabinet en niet kan worden gecontroleerd door de Kamer?

De relatie met de bedrijfsvoering leggen we in het rapport in § 3.2.3 (Vaak genoemde voordelen van open standaarden) en § 3.3.5. (Vaak genoemde voordelen van opensourcesoftware).

Wat de marktordening betreft merken we op dat de overheid, waarmee we in dit verband het totaal van de centrale en decentrale overheden bedoelen, een grote klant van de ICT-industrie is. Overheidsbrede veranderingen ten aanzien van de keuze van softwareleveranciers zullen hierdoor ongetwijfeld bedoelde en/of onbedoelde effecten hebben op de softwaremarkt. Een bedoeld effect van een overheidsbrede overstap op opensourcesoftware zou kunnen zijn dat de licentiekosten van closedsourcesoftware van dominante softwareleveranciers omlaag gaan. Een wellicht onbedoeld effect van een keuze voor opensourcesoftware in het algemeen zou marktverstoring kunnen zijn, bijvoorbeeld als leveranciers van closedsourcesoftware door een algemene roep om opensourcesoftware concurrentienadeel ondervinden in deelmarkten waar al veel opensourceleveranciers actief zijn.

Overigens is het ook denkbaar dat de overheid haar potentiële marktmacht aanwendt om voordelige volumecontracten af te sluiten met leveranciers van (closedsource) software.

Of en hoe de overheid haar potentiële marktmacht moet aanwenden is een bestuurlijke keuze, die uiteraard door de Tweede Kamer kan en moet worden gecontroleerd.

21

Is de werking van het «comply or explain»-principe uit het actieplan NOiV onderzocht? Wordt dit op de juiste manier toegepast? Werkt dit voor de ministeries? Hoe verhoudt dit principe zich tot de conclusie van de Algemene Rekenkamer dat een veel breder scala aan overwegingen aan de orde is dan uitsluitend financiële?

Dit hebben wij niet onderzocht.

22

Er moet een strategische aanpak komen, maar ligt die er niet al met het actieplan NOiV? Wat schort er volgens de Algemene Rekenkamer aan dit actieplan? Welke verbeteringen moeten hierin doorgevoerd worden? Wat zullen de gevolgen voor het beleid met betrekking tot open standaarden en opensourcesoftware zijn als het kabinet NOiV loslaat?

De strategische aanpak die wij bedoelen, ligt er nog niet met het actieplan NOiV. Het actieplan is een algemeen beleidsplan voor de Nederlandse overheid als geheel. Het opstellen van een dergelijk plan is een van de stappen in de beleidsvorming. De strategieën die wij in het rapport bedoelen zijn strategieën van de ministeries zelf, die aansluiten op een overkoepelende bovendepartementale strategie. Het opstellen van deze strategieën is de verantwoordelijkheid van de afzonderlijke ministers, respectievelijk de minister van BZK als coördinerend minister, en niet een verantwoordelijkheid van het kabinet. Het in het actieplan neergelegde algemene beleid is kaderstellend, maar vormt nog niet de door ons bedoelde strategische aanpak. Vanzelfsprekend moeten deze strategieën aansluiten bij algemeen beleid, dus ook met het beleid dat is neergelegd in het actieplan.

We hebben het actieplan niet inhoudelijk beoordeeld en spreken er dan ook geen oordeel over uit. Het actieplan is kabinetsbeleid en het is dus de verantwoordelijkheid van het kabinet om het actieplan opnieuw te bezien in het licht van onze conclusies en aanbevelingen, na te gaan of er consequenties uit volgen voor dat algemene beleid en vast te stellen of en zo ja welke aanpassingen zij nodig achten. Het initiatief hiervoor ligt bij de minister van EL&I en de minister van BZK. Vervolgens kan de Tweede Kamer de gemaakte keuzes beoordelen.

23

Welke bevoegdheden zou de Chief Information Officer (CIO) Rijk naar het oordeel van de Algemene Rekenkamer wel of juist niet moeten hebben, gezien de bezwering «dat te allen tijde rekening moet worden gehouden met de functiespecifieke behoeften op ICT-gebied die van toepassing tot toepassing en van departement tot departement kunnen verschillen»? Voldoet de recente versterking van de positie van de CIO Rijk wel of juist niet aan de aanbevelingen van de Algemene Rekenkamer?

Het zijn niet zozeer de bevoegdheden of de positie zelf van de CIO Rijk die bij deze aanbeveling aan de orde zijn als wel de wijze waarop de CIO Rijk daarvan gebruik maakt. De afstemming tussen de bovendepartementale strategie en de departementale strategieën kan geen puur topdown-proces zijn en is een kwestie van onderlinge afstemming. Bewust gedoseerd gebruik van doorzettingsmacht kan wellicht helpen om voor tempo te zorgen, om consistentie tussen de strategieën te bereiken, om ervoor te zorgen dat de strategieën praktisch bruikbaar zijn en om eventuele patstellingen te doorbreken.

Vraag 24: deze vraag is beantwoord in combinatie met vraag 2, zie aldaar.

25

Zijn er volgens de Algemene Rekenkamer alternatieve methoden om een inschatting te maken van het gebruik van opensourcesoftware bij lagere overheden en zelfstandige bestuursorganen?

Het maken van een inschatting van het gebruik van opensourcesoftware bij decentrale overheden en zelfstandige bestuursorganen (zbo’s) zou bijvoorbeeld kunnen gebeuren door via gesprekken in het veld en met commerciële ICT-dienstverleners te achterhalen wat de belangrijkste softwareproducten met closedsourcesoftware-licenties zijn die hoge kosten veroorzaken (te denken valt aan kantoorautomatisering, databasemanagementsystemen en ERP-systemen). Vervolgens kan bij een steekproef van decentrale overheden en zbo’s via gesprekken en/of enquêtes worden nagegaan of deze producten dan wel opensourcevarianten daarvan in gebruik zijn. Als in de vraag met «het gebruik van» (ook) bedoeld is «de kosten van», dan verwachten we dat een onderzoek daarnaar op vergelijkbare problemen zal stuiten als die wij beschrijven in § 4.1 van het onderzoeksrapport. Bij het bewerkstellingen van medewerking door decentrale overheden kunnen wellicht de Vereniging van Nederlandse Gemeenten (VNG), het Interprovinciaal Overleg (IPO) en de Unie van Waterschappen een bemiddelende rol vervullen. Ook kan overwogen worden om de gegevens via de lokale en regionale rekenkamers te verzamelen. Dat kan wellicht gebeuren door tussenkomst van de Nederlandse Vereniging van Rekenkamers & Rekenkamercommissies (NVRR).

U vraagt naar alternatieve methoden om een inschatting te maken van het gebruik van opensourcesoftware. Hierbij merken we op dat de vraag naar het gebruik van opensourcesoftware een ander type vraag is dan de vragen die de Tweede Kamer ons gevraagd heeft te onderzoeken, die gaan over vermindering van gebruik.

26 en 52

Welke experts zijn wel geraadpleegd, maar uiteindelijk niet genoemd in het rapport? Kan de Algemene Rekenkamer aangeven welke bronnen wel en welke bronnen niet zijn verwerkt in het onderzoek?

Welke vakliteratuur heeft de Algemene Rekenkamer geraadpleegd bij het onderzoek?

Enkele experts zijn door een fout van onze kant niet vermeld in bijlage 7 van het onderzoeksrapport. Het betreft de volgende experts: O. Sessink (ministerie van Defensie), M. Smit, J. van der Torn (beiden van Stone-IT) en R. Smit (ministerie van Veiligheid en Justitie). De bronnen die wij relevant vonden om te vermelden zijn verder te vinden in de lijst met experts en de literatuurlijst. Op de achtergrond heeft ook andere literatuur een rol gespeeld in het kader van oriëntatie op open technologie. De informatie uit deze literatuur heeft bijgedragen aan ons beeld van het vraagstuk maar is niet één op één in het rapport opgenomen. Daarom is deze literatuur niet in de literatuurlijst opgenomen.

27

Hoeveel business cases zijn er aangeleverd en onderzocht? Klopt het dat niet alle aangeleverde informatie uiteindelijk betrokken is bij het rapport? Waarom niet? Wat is de reactie van de Algemene Rekenkamer op de veelgehoorde klacht uit het veld dat veel van de aangeleverde business cases niet terug lijken te komen in het uiteindelijke rapport?

Onder een business case verstaan wij, zoals in het kader van (ICT-)projecten gebruikelijk is, de zakelijke rechtvaardiging van een project. De business case geeft de redenen voor het project, beantwoordt het waarom en bevat een overzicht van de te verwachten kosten en baten. Wij hebben verschillende business cases aangeleverd gekregen. Daarnaast zijn ons diverse voorbeelden genoemd van de overstap op open standaarden en opensourcesoftware, maar zonder bijbehorende business cases. Deze hebben wij daarom niet kunnen gebruiken voor ons onderzoek. Zie voor de verwerking van alle aangeleverde informatie het antwoord op vraag 28. Bij gebrek aan voldoende casuïstiek hebben we het begrip «business case» in het rapport overigens ruim opgevat. Niet altijd was er sprake van een mate van uitwerking en onderbouwing die we verwachten van een volwaardige business case.

28

Klopt het dat er wel gesprekken zijn geweest met Stone-IT, maar dat met de uitkomsten van deze gesprekken niets is gedaan? Waarom niet?

Het klopt dat wij gesproken hebben met vertegenwoordigers van Stone-IT. Helaas behoren zij tot de experts die abusievelijk niet zijn opgenomen in de lijst met experts in ons rapport (zie antwoord op vraag 26). Dit gesprek heeft dezelfde behandeling gekregen als alle andere gesprekken en de via het gesprek verkregen informatie heeft dus ook een rol gespeeld bij het opstellen van het rapport.

29

Waarom heeft de Algemene Rekenkamer zich bij het bespreken van strategische ICT-doelstellingen beperkt tot de interne ICT-behoefte van kerndepartementen?

Wij betogen in het rapport dat mogelijkheden en scenario’s voor de vermindering van het gebruik van gesloten standaarden en de introductie van opensourcesoftware bij de ministeries niet op zichzelf staan maar afhangen van keuzes die gemaakt worden binnen het proces van strategische planning. Wij zeggen niet dat die strategische planning zich moet beperken tot de interne ICT-behoefte van de departementen. Integendeel, strategische planning is bij uitstek extern gericht: namelijk op de te bereiken doelen op de beleidsterreinen van een ministerie. Een voorbeeld van een strategische doelstelling is de doelstelling van het ministerie van EL&I om met de inzet van ICT de beschikbaarheid en toegankelijkheid van digitale voorzieningen voor bedrijven te verbeteren (zie: «Programma Regeldruk Bedrijven 2011–2015», bijlage bij Tweede Kamer 29 515, nr. 327). Het ministerie verwacht dat met behulp van ICT aanvragen van bedrijven bij de overheid sneller kunnen worden verwerkt en bedrijven gedurende de doorlooptijd beter op de hoogte kunnen worden gehouden van de status van hun verzoek. Voor ondernemers heeft dit als voordeel dat men bijvoorbeeld directe toegang kan krijgen tot alle voor hen relevante informatie en voortgang van vergunningaanvragen, dat men informatie maar eenmaal hoeft aan te leveren aan de overheid en dat de ondernemer zijn vergunningen via internet kan aanvragen op het moment dat het uitkomt, ook buiten kantooruren. Primair heeft het ministerie dus effecten in de buitenwereld op het oog, maar om deze effecten te kunnen bereiken dient het ministerie de doelstelling in elk geval ook een concrete vertaling te geven bij de invulling van het interne ICT-beleid. Tegelijkertijd is hier ook het aspect interoperabiliteit aan de orde. Het is dan ook de verantwoordelijkheid van het ministerie van EL&I om ervoor te zorgen dat de hiervoor benodigde standaardisatie plaatsvindt.

30

Hoe beoordeelt de Algemene Rekenkamer de «vaak genoemde voordelen van open standaarden», gezien de opmerking «Er bestaat geen bewijsvoering voor de algemene geldigheid van deze potentiële voordelen.»?

Met onze opmerking dat er geen bewijsvoering is voor de algemene geldigheid van vaak genoemde voordelen van open standaarden willen wij aan de discussie over open standaarden een praktische invalshoek toevoegen. Tabel 3 op pagina 50 van het rapport, waarin de mogelijke kwalitatieve baten staan die in de drie gepresenteerde business cases worden genoemd, illustreert dat van geval tot geval moet worden nagegaan wat de eventuele voordelen van open standaarden zijn. Deze business cases noemen allerlei andere mogelijke baten dan die wij in ons rapport noemen als vaak genoemde voordelen (zie § 3.2.3).

31

Zijn er meer voordelen van opensourcesoftware te noemen, die niet vallen onder het criterium «vaak genoemde voordelen» van de Algemene Rekenkamer? Bijvoorbeeld dat het gebruik van opensourcesoftware de concurrentie bevordert in een markt die gedomineerd wordt door gesloten software, wat leidt tot betere producten en lagere prijzen? Bijvoorbeeld dat bij zakelijk gebruik van opensourcesoftware werknemers thuis kosteloos en legaal dezelfde software kunnen gebruiken, wat het risico van malware voor organisaties vermindert?

De «vaak genoemde voordelen» die het rapport in § 3.3.5 vermeldt zijn niet bedoeld als limitatieve opsomming en er kunnen ook andere voordelen verbonden zijn aan opensourcesoftware. Inderdaad kan opensourcesoftware de concurrentie bevorderen (zie ook ons antwoord op de vragen 19 en 20). In het marktsegment van de contentmanagementsystemen voor websites hebben verschillende softwareleveranciers de markt betreden op basis van opensourcesoftware. In dat marksegment kan nu gekozen worden tussen diverse leveranciers van open en gesloten softwareproducten. Concurrentie bevordert in het algemeen een gunstiger prijs-kwaliteitverhouding. Wij zijn niet nagegaan of dat in dit marktsegment het geval is, maar zien wel dat vaak gekozen wordt voor een opensourcevariant, zoals Hippo (geleverd door het gelijknamige Nederlandse bedrijf), Drupal, Typo3 of Joomla! Nog een ander potentieel voordeel kan zijn een verminderde leveranciersonafhankelijkheid bij onderhoud van software doordat het bij opensourcesoftware in principe eenvoudiger is om het onderhoud bij een andere partij onder te brengen. Bij closedsourcesoftware kan dat lastiger zijn in verband met auteursrecht op broncode en octrooirecht op patenten. Voorwaarde is wel dat er meer opensourceleveranciers zijn die deze diensten kunnen verlenen, omdat anders alsnog een vendor lock-in kan ontstaan. Ook hiervoor geldt dus dat dit mogelijke voordeel zich niet automatisch voordoet bij alle opensourcesoftware. In ons rapport merkten we dit meer in het algemeen op voor vaak genoemde voordelen (§ 3.3.5).

Over het risico van malware merken we het volgende op. Afhankelijk van het door de werkgever afgesloten softwarecontract brengt het thuisgebruik van software wel of niet in substantiële mate extra kosten met zich mee. Wat het in de vraag vermelde risico van malware betreft nemen wij aan dat bedoeld is dat een werknemer minder snel geneigd zal zijn om cracks (gekraakte versies) te installeren als deze thuis gratis legale software ter beschikking heeft. Dat is een plausibele veronderstelling, maar het installeren van cracks is zeker niet de enige en volgens ons ook niet de belangrijkste weg waarlangs een computer thuis besmet kan raken. Het risico van malware is altijd aanwezig en organisaties moeten daarom zowel bij closedsource- als bij opensourcesoftware maatregelen treffen om malware te weren.

4, 32, 33 en 34

Zijn internationale en Europese rapporten over besparingspotentieel bij het onderzoek betrokken? Zo nee, waarom niet? Zo ja, welke? Waarom is hierover niets terug te lezen in het rapport?

Is er een vergelijking gemaakt tussen het Nederlandse beleid ten aanzien van het gebruik van opensourcesoftware en het beleid van Duitsland, Frankrijk, het Verenigd Koninkrijk, Spanje en Finland?

Klopt het dat in al deze landen opensourcesoftware wordt toegepast door overheden? Wat is het belangrijkste verschil tussen de toepassing door de Nederlandse overheid en de toepassing van open source in deze landen?

Waarom kunnen resultaten die bijvoorbeeld in Finland worden bereikt, niet in Nederland worden behaald? (zie: Large-scale migration to an open source office suite: An innovation adoption study in Finland, Karjalainen Martti, University of Tampere, 2010).

Wij kennen verschillende berichten over het gebruik van opensourcesoftware in het buitenland. Ook verwezen sommige van onze gesprekspartners naar migratieprojecten bij overheden in het buitenland. Andere gesprekspartners plaatsten belangrijke kanttekeningen bij het geclaimde succes van die projecten. De door de Tweede Kamer gevraagde deadline stond ons niet toe om de buitenlandse voorbeelden in het onderzoek te betrekken. Het lijkt ons wel plausibel dat in het buitenland gebruik wordt gemaakt van opensourcesoftware, ook al omdat dit in Nederland ook het geval is. De case study over de situatie in Finland is ons bekend. Zoals hiervoor aangegeven, ontbrak ons de tijd om hier nadere aandacht aan te geven. Wel wijzen wij erop dat het onderwerp van die case study het adoptieproces van softwarevervanging betreft. Bovendien was er een noodzaak om te migreren omdat de bestaande closedsourcesoftware voor de kantoorautomatisering (Lotus SmartSuite) waar de meerderheid van de medewerkers gebruik van maakte niet meer onderhouden werd door de leverancier (IBM). Overigens is informatie uit één bron (in dit geval ook geen onafhankelijke bron – het is uitgevoerd door de CIO van het betreffende Finse ministerie) voor ons nooit toereikend om gerapporteerde resultaten als feit aan te nemen.

35

Waarom worden gesloten en opensourcesoftware in het onderzoek van de Algemene Rekenkamer niet gelijkwaardig behandeld?

De Algemene Rekenkamer heeft niet a priori een voorkeur voor opensource- of closedsourcesoftware software. Ons is niet gevraagd om een vergelijking te maken tussen opensourcesoftware en closedsourcesoftware en dat hebben we ook niet gedaan. De Tweede Kamer heeft ons gevraagd naar de besparingsmogelijkheden door de introductie van opensourcesoftware. Op deze vraag hebben we getracht een zo bruikbaar mogelijk antwoord te geven binnen de grenzen van het beschikbare feitenmateriaal bij de ministeries en het gegeven tijdpad.

36

Welk deel van de gesloten standaarden en software kan worden vervangen door open standaarden en opensourceoplossingen en welk deel niet? Welke criteria hanteert de Algemene Rekenkamer bij het beoordelen of oplossingen vervangen kunnen worden of niet? Beperkt de Algemene Rekenkamer zich alleen tot wat vandaag beschikbaar is of heeft de Algemene Rekenkamer ook ontwikkelingsfasen van opensourceoplossingen meegenomen in het onderzoek?

In § 5.2.2 van ons rapport leggen we uit dat het niet op voorhand mogelijk is om een specifiek deel van het softwarelandschap aan te wijzen dat «open» gemaakt kan worden. Dit moet daarom van geval tot geval bekeken worden. Het is de verantwoordelijkheid van de ministeries om te beoordelen of software vervangen kan worden of niet. Wij hanteren zelf dan ook geen criteria hiervoor. Wel verwachten we van de ministeries dat ze de afweging op een zakelijke basis maken. Bij grotere vervangingsoperaties betekent dit dat de ministeries business cases moeten maken (zie onze uitleg van dat begrip in het antwoord op vraag 27). In § 5.3.1 wijzen wij erop dat zich voortdurend nieuwe ontwikkelingen voordoen. Wij vinden het vanzelfsprekend dat de ministeries zich niet beperken tot wat nu beschikbaar is en in hun afwegingen nieuwe ontwikkelingen betrekken, zowel open als gesloten.

37

Aan welke voorwaarden moet volgens de bevindingen van de Algemene Rekenkamer zijn voldaan om de implementatie van open source mogelijk te maken?

De belangrijkste voorwaarde is volgens ons dat de ministeries een strategische aanpak volgen. Daaruit kunnen concrete randvoorwaarden volgen, bijvoorbeeld dat bepaalde gesloten standaarden worden vervangen door open varianten, dat specifieke deskundigheid wordt opgebouwd of dat er geld kan worden vrijgemaakt voor investeringen. Algemene randvoorwaarde is dat «het werk tijdens de verbouwing doorgaat», dus dat het primaire proces en het bereiken van de organisatiedoelen niet in gevaar komen.

38

Waaruit bestaan de directe en indirecte kosten van proprietary softwarelicenties?

De belangrijkste directe en indirecte kosten zijn hieronder opgesomd.

• kosten voor licenties (gebruiksrechten), afhankelijk van de contractvorm gebaseerd op aantal gebruikers, het aantal gelijktijdige gebruikers, het aantal devices, het aantal servers of aantallen processors in servers;

• kosten voor recht op nieuwe releases/nieuwe versies, meestal onderhoudskosten genoemd;

• kosten voor verwerving van de software (marktonderzoek, aanbesteding, selectie en aanschaf);

• kosten voor (recht op) support van de (tussen)leverancier, uiteenlopend van telefonische ondersteuning tot consultancy ter plaatse;

• kosten voor benodigde hardware en overige ICT-infrastructuur die door de software is vereist;

• opleiding en training van beheerders en mogelijk de eindgebruikers;

• beheer van de software (installatie, inrichting, conversie en testen; initieel en bij upgrades);

• beheer voor ondersteuning operationeel gebruik;

• mogelijke interfaces met andere software;

• eventueel aanvullend maatwerk.

39

Wat zijn de kosten die worden veroorzaakt door het werken met verouderde systemen en applicaties omdat nieuwe niet ingevoerd kunnen worden door vendor lock-in?

Over de kosten die worden veroorzaakt door het werken met verouderde systemen en applicaties valt in zijn algemeenheid eigenlijk niets te zeggen. Dus ook niet als dat doorwerken een gevolg is van vendor lock-in. De hoogte van eventuele kosten (of besparingen) kan alleen in concrete gevallen worden vastgesteld.

40

Zijn de vier vertrekpunten van de Model Architectuur Rijksdienst (MARIJ) feitelijk of normatief? Op welke wijze werken deze vertrekpunten door in de bevoegdheidsverdeling op het gebied van ICT-projecten bij de rijksoverheid?

De vier vertrekpunten zijn normatief. Wij hebben niet onderzocht in welke mate de feitelijke situatie bij de ministeries daar al mee in overeenstemming is.

41

Wat is de betekenis van de bedragen in het licht van de constatering dat de softwarekosten van het Rijk niet nauwkeurig te bepalen zijn?

De bedragen zijn een indicatie van de kosten op grond van de van de ministeries verkregen overzichten en geven de orde van grootte aan waarmee we van doen hebben. Het in de cijfers vervatte beeld is dus indicatief en bovendien een momentopname (peiljaar 2009). Maar ondanks deze beperkingen menen wij dat dit voor het te voeren debat wel het enige beschikbare beeld is.

Zie verder ook § 4.1 van het rapport.

42

Hoe verklaart de Algemene Rekenkamer het lage percentage licentiekosten (4%) in verhouding tot bijvoorbeeld getallen die Microsoft in 2005 aangaf (8%) en IBM in 2004 (27%)? Hoe wordt het getal van 4% onderbouwd?

Bij gebrek aan cijfers uit administraties hebben wij navraag gedaan bij de ministeries. Het percentage dat wij noemen is berekend op grond van de resultaten hiervan. Aan de ministeries is gevraagd per applicatie van software waarvoor ook opensourcevarianten beschikbaar zijn (zie ook het antwoord op vraag 18) de jaarlijkse licentiekosten op te geven. Het totaal van deze bedragen is € 88 miljoen en afgezet tegen de totale opgeven ICT-kosten van de ministeries van € 2,1 miljard maakt dat 4 procent. Percentages krijgen inhoud als duidelijk is op welke maatschappelijke sector ze betrekking hebben, op welke wijze ze tot stand zijn gekomen en welke kostencomponenten er wel en niet in zijn meegenomen. Van de door u genoemde percentages is ons deze context niet bekend. Wij hebben dan ook geen verklaring voor de verschillen tussen onze percentages en die in de vraag, en al evenmin hebben we een verklaring voor de verschillen tussen de percentages van de twee door u genoemde bedrijven.

43

Acht de Algemene Rekenkamer het verstandig om in de toekomst door ministeries wel een administratie op applicatieniveau bij te laten houden met betrekking tot licenties?

Wij vinden het verstandig als ministeries een administratie op applicatieniveau bijhouden. Een van de redenen hiervoor is dat de organisatie moet kunnen voldoen aan de licentievoorwaarden. Dit betekent dat in elk geval bekend moet zijn over welke aantallen en typen licenties de organisatie beschikt en dat de organisatie het gebruik van de licenties controleert.

44

Is het correct dat de berekeningen voor de proef bij het ministerie van Defensie niet alleen een absolute besparing behelzen, maar dat tegelijkertijd het aantal werkplekken meer dan verdubbeld is? Klopt het dat daardoor de besparing per werkplek feitelijk veel groter is dan nu is weergeven door de Algemene Rekenkamer? Kan de Algemene Rekenkamer aangeven hoeveel er nu per werkplek wordt bespaard? Kan de Algemene Rekenkamer bevestigen dat de cijfers zijn aangeleverd door de controller van het ministerie van Defensie?

Vooraf merken we op dat de twee praktijkvoorbeelden van het ministerie van Defensie, net als de overige praktijkvoorbeelden in dezelfde paragraaf (§ 4.3.2) van het rapport, slechts zijn opgenomen om te illustreren dat organisaties soms belangrijke besparingen verwachten door gebruik te maken van opensourcesoftware. Wat de precieze hoogte is van de vermelde cijfers is voor dat doel minder relevant.

De berekening van potentiële besparingen heeft het ministerie van Defensie gebaseerd op het verschil tussen de kosten bij het gebruik van closedsourcesoftware en de kosten bij het gebruik van opensourcesoftware. Naast kwalitatieve baten vermeldt het ministerie in het geval van Veilig Internet ook dat één licentie oneindig veel gebruikers kan ondersteunen en dat meer (gelijktijdige) gebruikers mogelijk zijn. Een hoger aantal gebruikers leidt echter niet tot een hogere feitelijke besparing. Wel dalen de kosten per opensourcesoftware-gebruiker omdat het ministerie de hiervoor benodigde extra investering op nihil schat. Mogelijk is er in dit geval dus sprake van een lagere investering per extra gebruiker van opensourcesoftware dan per extra gebruiker van closedsourcesoftware.

Zoals wij in ons rapport aangeven zijn wij niet nagegaan of de vermelde getallen reëel zijn. De reden hiervoor is dat de verkregen ramingen sterk afhangen van verschillende aannames.

Over uw vraag naar de herkomst van de gegevens merken we het volgende op. De praktijkvoorbeelden zijn aangeleverd door een onderdeel van de bedrijfsgroep Informatievoorziening en Technologie (IVENT) van het Ministerie van Defensie. Uit een toelichtend gesprek met IVENT hebben wij begrepen dat de controller van IVENT betrokken is geweest bij het opstellen van de cijfers. Verdere afstemming heeft plaatsgevonden met de Hoofddirectie Informatievoorziening en Organisatie van het ministerie.

45

Voldoet de business case basisregistraties aan de definitie van een project met open standaarden, zoals de Algemene Rekenkamer dat hanteert? Hoe beoordeelt de Algemene Rekenkamer de houdbaarheid van de mogelijke besparing die berekend is? Welk deel van de berekende besparing wordt bereikt door de inzet van open standaarden en hoe wordt de overige besparing gerealiseerd?

De business case Stelsel van basisregistraties beschrijft ondermeer het realiseren van voorzieningen (koppelingen) die gebruik maken van de open standaard Extensible Markup Language (XML). De verwachte besparingen zijn afkomstig van een extern bureau (zie pagina 49 van ons rapport). Wij hebben geen nader onderzoek naar deze cijfers gedaan. De business case hebben we opgenomen om te illustreren dat organisaties soms belangrijke besparingen verwachten van open standaarden. Uit de business case is niet af te leiden welk deel van de verwachte besparingen wordt toegeschreven aan het open zijn van de beoogde voorziening.

46

Kan de Kamer nog een vervolg verwachten op dit rapport met betrekking tot nacalculaties van business cases?

Op pagina 49 van het rapport geven wij aan dat ons geen evaluaties bekend zijn van afgeronde projecten waarbij is overgegaan van «gesloten» naar «open». De Algemene Rekenkamer heeft geen vervolgonderzoek gepland. Wij hebben wel de gewoonte om enige jaren na de publicatie van een onderzoek een zogenoemd terugblikonderzoek te doen en daarbij kan deze afweging wellicht opnieuw aan de orde zijn.

47 en 48

Hoe beoordeelt de Algemene Rekenkamer de doelmatigheid van het beleid ten aanzien van open source tot nu toe?

Hoe beoordeelt de Algemene Rekenkamer het actieplan Nederland Open in verbinding?

Wij hebben niet het beleid ten aanzien van open source of het actieplan NOiV beoordeeld. Dit is ons ook niet gevraagd.

49

Op welke termijn kan volgens de Algemene Rekenkamer de afbouw van huidige gesloten standaarden en de introductie van opensourcesoftware worden gerealiseerd?

In § 5.2.4 van het rapport leggen we uit dat de overgang van «gesloten» naar «open» nooit op een bepaald moment afgerond kan zijn.

50

Wat zijn de gevolgen voor de ICT-kosten, als door maatschappelijke en technische ontwikkelingen in de nabije toekomst de ICT-middelen (zoals hardware en software) minder centraal komen te staan?

Op basis van ons onderzoek kunnen wij deze vraag helaas niet beantwoorden.

51

Heeft de Algemene Rekenkamer onderzoek van de Universiteit van Amsterdam uit 2004 (Kosten en baten van open standaarden en open source software in de Nederlandse publieke sector: een analyse op meso- en macroniveau, SEO) en dat van het Centraal Planbureau uit 2009 (Competition, innovation and intellectual property rights in software markets) geraadpleegd? Zo nee, waarom niet? Zo ja, waarom is hierover niets terug te lezen in het rapport? Wat is de beoordeling van de Algemene Rekenkamer van deze onderzoeken?

Ja, beide onderzoeken waren bekend bij de Algemene Rekenkamer.

Het eerstgenoemde onderzoek concludeert dat er waarschijnlijk netto maatschappelijke baten zijn te behalen als de publieke sector geheel overstapt op software die is gebaseerd op open standaarden. Over software concludeert het rapport dat het niet vaststaat dat in alle gevallen netto maatschappelijke baten zijn te behalen als de publieke sector op brede schaal gebruik maakt van opensourcesoftware. Al met al wijst de analyse wel in de richting van welvaartswinst door de overstap op opensourcesoftware. Deze winst blijft echter gebaseerd op een theoretische exercitie en wordt nergens gekwantificeerd.

De studie van het CPB analyseert wanneer het wenselijk is dat de overheid opensourcesoftware stimuleert in reactie op marktfalen in softwaremarkten. De belangrijkste bevinding is dat het direct stimuleren van opensourcesoftware, bijvoorbeeld door de (Rijks)overheid, de marktwerking kan verbeteren als onder andere de leveranciersafhankelijkheid groot is. De studie bevat geen kwantificering van deze voordelen en geeft ook geen concrete voorbeelden van softwaredeelmarkten die voor stimulering in aanmerking komen.

De studies geven niet aan hoe de overstap naar OS en OSS concreet zal kunnen plaatsvinden en maken hierdoor niet duidelijk of de verwachtingen van welvaartswinst of marktwerking realistisch zijn.

Hierdoor waren de resultaten van deze onderzoeken niet bruikbaar voor de beantwoording van de vraag hoe groot de kostenbesparing voor de publieke sector zou kunnen zijn.

Vraag 52: Deze vraag is beantwoord in combinatie met vraag 26, zie aldaar.

---

1 Samenstelling:

Leden: Omtzigt, P.H. (CDA), Veen, E. van der (PvdA), Neppérus, H. (VVD), Gerven, H.P.J. van (SP), voorzitter, Blanksma-van den Heuvel, P.J.M.G. (CDA), Dijck, A.P.C. van (PVV), Broeke, J.H. ten (VVD), ondervoorzitter, Ouwehand, E. (PvdD), Heijnen, P.M.M. (PvdA), Bashir, F. (SP), Sap, J.C.M. (GL), Harbers, M.G.J. (VVD), Plasterk, R.H.A. (PvdA), Groot, V.A. (PvdA), Braakhuis, B.A.M. (GL), Vliet, R.A. van (PVV), Mulder, A. (VVD), Dijkgraaf, E. (SGP), Verhoeven, K. (D66), Koolmees, W. (D66), Besselaar, I.H.C. van den (PVV), Schouten, C.J. (CU) en Vacature (CDA).

Plv. leden: Knops, R.W. (CDA), Vermeij, R.A. (PvdA), Ziengs, E. (VVD), Gesthuizen, S.M.J.G. (SP), Haverkamp, M.C. (CDA), Gerbrands, K. (PVV), Beek, W.I.I. van (VVD), Thieme, M.L. (PvdD), Monasch, J.S. (PvdA), Irrgang, E. (SP), Grashoff, H.J. (GL), Straus, K.C.J. (VVD), Hamer, M.I. (PvdA), Kuiken, A.H. (PvdA), Gent, W. van (GL), Beertema, H.J. (PVV), Boer, B.G. de (VVD), Staaij, C.G. van der (SGP), Pechtold, A. (D66), Koşer Kaya, F. (D66), Graus, D.J.G. (PVV), Slob, A. (CU) en Hijum, Y.J. van (CDA).

2 Samenstelling:

Leden: Dijksma, S.A.M. (PvdA), voorzitter, Beek, W.I.I. van (VVD), Staaij, C.G. van der (SGP), Koopmans, G.P.J. (CDA), Bochove, B.J. van (CDA), Aptroot, Ch.B. (VVD), ondervoorzitter, Smilde, M.C.A. (CDA), Jansen, P.F.C. (SP), Ortega-Martijn, C.A. (CU), Brinkman, H. (PVV), Raak, A.A.G.M. van (SP), Thieme, M.L. (PvdD), Dibi, T. (GL), Heijnen, P.M.M. (PvdA), Elissen, A. (PVV), Monasch, J.S. (PvdA), Schouw, A.G. (D66), Marcouch, A. (PvdA), Boer, B.G. de (VVD), Hennis-Plasschaert, J.A. (VVD), Lucassen, E. (PVV), Verhoeven, K. (D66) en Grashoff, H.J. (GL).

Plv. leden: Dam, M.H.P. van (PvdA), Burg, B.I. van der (VVD), Dijkgraaf, E. (SGP), Sterk, W.R.C. (CDA), Bruins Slot, H.G.J. (CDA), Steur, G.A. van der (VVD), Knops, R.W. (CDA), Dijk, J.J. van (SP), Slob, A. (CU), Klaveren, J.J. van (PVV), Vacature (SP), Ouwehand, E. (PvdD), Gent, W. van (GL), Kuiken, A.H. (PvdA), Fritsma, S.R. (PVV), Vermeij, R.A. (PvdA), Pechtold, A. (D66), Wolbert, A.G. (PvdA), Nieuwenhuizen-Wijbenga, C. van (VVD), Taverne, J. (VVD), Bontes, L. (PVV), Hachchi, W. (D66) en Voortman, L.G.J. (GL).

3 Een afschrift van de brief aan dhr. H.S. te L is ter inzage gelegd bij het Centraal Informatiepunt Tweede Kamer.

4 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.