De overheid moet geen hoge verwachtingen hebben van kostenbesparing met open source software. De besparingen zitten vooral in de gratis softwarelicenties. Licentiekosten bepalen bij ministeries slechts 4 procent van het totale ict-budget. Ict-vraagstukken puur vanuit kostenbesparing bekijken, vormt daarom een te beperkt perspectief. Niet de kosten, maar de organisatiedoelen moeten leidend zijn bij het Rijk. Dat adviseert de Algemene Rekenkamer aan de Tweede Kamer.
De Rekenkamer onderzocht op verzoek van het parlement de mogelijke inzet van en besparingen met open standaarden en open source bij de overheid. Saskia Stuiveling, de president van de Algemene Rekenkamer, presenteerde het onderzoeksrapport op dinsdagmiddag 15 maart 2011.
In het onderzoek heeft de Rekenkamer alleen gekeken naar de ict-situatie bij de diverse ministeries. De situatie bij zelfstandige bestuursorganen (zoals Kadaster, DUO en UWV) en decentrale overheden (zoals provincies en gemeenten) worden niet belicht. Daar zou de Rekenkamer geen onderzoeksbevoegdheid hebben.
Beperkt voordeel
Het kostenvoordeel van opensourceproducten beperkt zich volgens de onderzoekers voornamelijk tot de gratis licenties. Dat voordeel is beperkt, schrijven ze. De ministeries besteedden in 2009 ongeveer 88 miljoen euro aan softwarelicenties, wat slechts 4 procent is van het totale budget van 2,1 miljard euro dat de ministeries uitgaven aan hardware en software.
Open source software is niet per definitie de goedkopere variant, leggen de onderzoekers uit. 'Andere kosten kunnen hoger zijn dan bij gesloten varianten. Vaak zal bovendien het beëindigen van de relatie met een leverancier uitstapkosten met zich meebrengen.' De Rekenkamer waarschuwt ook dat een overstap naar open source kan leiden tot kapitaalvernietiging, doordat het Rijk tal van lopende licentieafspraken heeft.
Meer invalshoeken
'Bij de keuze voor een softwareapplicatie zijn meer invalshoeken van belang dan alleen de kosten', schrijven ze in het rapport. '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.'
Ook adviseren ze de overheid om het doel van efficiëntieverbetering duidelijk te scheiden van beleidsdoelen voor de marktordening voor software.
De onderzoekers schrijven dat ze het lastig vinden om de kosten van software bij ministeries te achterhalen. Licentiekosten worden vaak niet apart en per jaar geregistreerd. Bovendien besteden de organisaties delen van hun ict uit aan externe dienstverleners, die de kosten niet afzonderlijk in rekening brengen.
Welke kosten?
Bij de bepaling van de softwarekosten (licenties en onderhoud) heeft de Rekenkamer enkel gekeken naar software waarvoor een opensourcevariant bestaat. De onderzoekers noemen dit het 'relevante deel van de software'. Het gaat bijvoorbeeld om het besturingssysteem, de kantoorautomatisering en systemen voor geografische informatie (GIS), klantrelatiebeheer (cms), webontwikkeling en databasemanagement. Er is niet gekeken naar serversoftware.
Bovendien is voor het onderzoek enkel gekeken naar ministeries en niet naar de zelfstandige bestuursorganen (zbo's) en decentrale overheden zoals provincies, waterschappen en gemeenten. De Tweede Kamer had in juli 2010 de Rekenkamer verzocht om een onderzoek waarbij ook decentrale overheden werden meegenomen.
Open source levert weinig besparing op. Gut, wie had dat gedacht.
Er valt vast heel veel op het rapport aan te merken, maar iedereen die een beetje kijk heeft op kosten in de ICT weet dat licentiekosten zo’n beetje de laatste post is waar je moet zoeken voor besparingen.
De argumenten van de open source brigade snijden vaak geen hout. Neem het toverwoord “vendorlock”. Grote flauwekul! Dat staat volledig los van het gebruik van open source of niet.
Toch komt die 4% wel in de buurt bij wat ik met grote projecten tegen kom.
Zowel bij grote commerciele organisaties/multinationals als bij de ministeries en ZBO’s zit in de projecten van 10 tot 100+ miljoenen zo’n 5% aan licentiekosten begroot.
Hardware iets meer.
Implementatie (incl. requirements, analyse, ontwerp, test, acceptatie en produktie) is de grote hap van meer dan 50%.
De rest ~ 40% is beheer en organisatie. Deze laatste post is bij OSS vaak iets groter als bij CSS vanwege het grotere aantal losse ‘onderdelen’
Bij de grotere commerciele organisaties zie ik meestal een rationelere afweging tussen OSS en CSS met meestal combinaties hiervan!
Er wordt overigens in dit soort discussies zo vaak open source en open standaarden op 1 hoop gegooid.
M.i. zijn open standaarden tegenwoordig overal waar ik kom van cruciaal belang.
Lokale overheden zitten vaak behoorlijk vast met proprietaire oplossingen van Centric, Microsoft en kleine softwarebedrijven met point-oplossingen.
Werkplek-automatisering is ook een verhaal apart.
Naar mijn mening gaat het meestal niet om wat het beste of goedkoopste is, maar:
– wat de markt om je heen gebruikt
– wat je klanten gebruiken
– waar je applicaties mee werken
– wat gebruikers kennen/gewend zijn
– waar heel veel formulieren/templates/rekenmodellen zijn gemaakt
– standaardisatie op 1 werkplek waar alles op werkt
Daarom zie ik hier bij grote bedrijven altijd Microsoft als de standaard.
Bij bedrijven die zich daar voor lenen zie je dat techneuten die dat willen of basiswerkplekken met vastomlijnde functionaliteit soms wel Linux gebruiken.
Maar bijna overal met 1 of meer windows-virtualisaties voor toepassingen die alleen onder windows (goed) draaien.
net zoals V2000 en Betamax, Macintosh en MS-DOS, etc.
@Hans, het lijkt erop dat je niet alleen weinig op hebt met open source, maar ook weinig met je opdrachtgever. Je praat zo gemakkelijk over de licentiekosten die door de opdrachtgever betaald moeten worden. Maar die moeten wel meegenomen worden in de TCO (ook bij de vergelijking tussen twee closed source oplossingen). Als je dat bij elke post nalaat, zijn de extra kosten voor de opdrachtgever al gauw substantieel.
En Hans, je weet toch ook wel dat vendor lock-in tegengegaan wordt door open standaarden en dat bij open source alleen maar open standaarden gebruikt worden, terwijl de closed source leveranciers daar nog steeds veel moeite mee hebben? En één gesloten standaard kan al voor vendor lock-in zorgen als de eigenaar daarvan niet bereid is om anderen (betaald) patenrecht te verlenen. Zelfs bij gelijkblijvende kosten is dat al vervelend voor je opdrachtgever. Het beperkt diens vrijheid.
Ik denk dat het een terechte constatering is dat Open Source software niet gratis is, dat de ontwikkeling en in stand houden van een Open Source gebaseerde oplossing ook kosten met zich mee brengen, en dat dat niet per definitie goedkoper en beter is dan een Closed Source gebaseerde oplossing.
De constatering dat een van de voordelen van Open Source software is dat je kunt mee bepalen wat de verdere koers is, en functies in te bouwen die er (nog) niet in zitten is natuurlijk niet wezenlijk anders dat bij Closed Source, ook daar beïnvloeden gebruikers de toekomst van het product, en ook daar kun je zelf functies (laten) bijbouwen voor een betere business fit. Wellicht tegen andere kosten, maar dan ook met andere opbrengsten.
De redenatie dat je met Open Source geen last hebt van “vendor-lock-in” omdat bij Open Source kun je het “sleutelen” aan de software uitbesteden aan derden, gaat natuurlijk ook op voor Closed Source, daar is een hele dienstverlenende industrie door ontstaan. Bovendien is er ook bij Open Source software een afhankelijkheid tussen de gebruikers en de ontwikkelaars, de ontwikkelaars zullen alleen de extra functies realiseren als zij daar voldoende brood (financieel, intellectueel, emotioneel) in zien.
Ook bij Open Source kan er een vendor-lock-in ontstaan, omdat de transitie van het ene (Open Source) software platform naar een ander (Open of Closed Source) software platform zulke kosten met zich mee brengen dat de investeringen niet opwegen tegen de opbrengsten.
Het argument dat je met Open Source software bijdraagt aan je eigen IT asset opbouw is wellicht waar, maar je kan je afvragen of dat het doel is van een organisatie die voornamelijk gebruik wil maken van IT. Met dezelfde redenatie zou je namelijk kunnen rechtvaardigen dat het wenselijk is dat iedere (overheids-) organisatie haar eigen elektriciteitscentrale, papierfabriek, of iets anders bouwt en beheert. Dat we dat niet doen komt omdat het gebruik van elektriciteit is gebaseerd op standaarden (230 volt 50 Hz) en dat iedere elektriciteitsleverancier daaraan voldoet, en de consumenten apparaten (functies) kunnen aanschaffen die gewoon ingeplugd kunnen worden en het dan ook doen en een redelijke prijs hebben (en dat willen we ook met IT).
Wat, tenslotte, wordt genoemd als bijkomend effect van een adoptie van Open Source, stimulering van de lokale IT-diensten economie, suggereert dat bijdragen aan een Open Source community regionaal worden beperkt (dus een Open Source ontwikkelaar vanuit India, China of de USA wordt uitgesloten van een bijdrage aan Nederlandse Open Source producten). Los van het feit dat dit technisch zeer lastig is om af te dwingen, staat het haaks op de gedachte van Open Source, namelijk van een “public, collaborative software development”.
Dit “bijkomende effect” onthult echter de wel de kern van de discussie in de Nederlandse politiek; Open Source software is goed voor de lokale IT-dienstverleners , en geeft de indruk dat je minder afhankelijk bent van grote (buitenlandse) multinationals die Closed Source software leveren. Dat is echter in hoge mate een politiek, ideologische en belangen discussie. Dat de Rekenkamer zich hierover niet uitlaat is eerder een kwaliteit dan een tekortkoming.
Heeft Open Source dan helemaal geen voordeel? Jazeker wel, Open Source stimuleert innovatie en creatief oplossen van problemen, iets wat iedere grotere organisatie slechts zeer moeilijk kan doen omdat, . . . . ze een grote organisatie is met vele gevestigde belangen die ter discussie worden gesteld door innovatie.
Erg jammer om te zien dat de discussie over Open/Close Source de richting op gaat van een geloofstrijd, met alle irrationele opinies en emoties vandien, waardoor voorbij wordt gegaan aan hetgeen wat een wezenlijke, essentiële en structurele besparing en een verhoging van de kwalitieit oplevert: gemeenschappelijke standaarden (en dat is heel iets anders dan iedereen zijn eigen “open standaard”).
Gemeenschappelijke standaarden zullen als gevolg hebben dat de discussie niet meer gaat over de voortbrengingswijze (open vs closed) maar over kosten en opbrengsten van onderling uit te wisselen functies (strijkijzer van merk A vs strijkijzer van merk B) en vervolgens leiden tot lagere aanschafkosten en een hogere kwaliteit!
Het ongenoegen dat er veel geld wordt besteed aan ICT, maar dat het “maar matig” functioneert is zonder meer terecht, maar om Open Source als oplossing te zien, dat is wel erg kort door de (verkeerde) bocht.
@mic: “De redenatie dat je met Open Source geen last hebt van “vendor-lock-in” omdat bij Open Source kun je het “sleutelen” aan de software uitbesteden aan derden, gaat natuurlijk ook op voor Closed Source”
Closed Source heeft geen vendor lock-in?
Alles heeft lock-in, zelfs eigen maatwerk.
Als je er na een tijd vanaf wilt, brengt dat hoge kosten met zich mee vanwege migratie, integratie, opleiding en beheer.
Quote: “De redenatie dat je met Open Source geen last hebt van “vendor-lock-in” omdat bij Open Source kun je het “sleutelen” aan de software uitbesteden aan derden, gaat natuurlijk ook op voor Closed Source, daar is een hele dienstverlenende industrie door ontstaan”
Hoe ga je aan de broncode sleutelen als je die gewoon niet hebt? Of heb je het over reverse engineering wat de meeste EULA’s niet toe laten en als je het toch stiekem illegaal doet minstens 100 keer zoveel tijd en geld kost?
@mic, je noemt veel goede argumenten, maar sommige zaken kloppen niet helemaal.
Open standaards ga je niet elke dag inwisselen voor andere, maar dat mag je geen vendor-lock-in noemen. Vendor-lock-in door een gesloten standaard (of een standaard waarbij het patentrecht te duur is gemaakt) heeft een heel andere impact op de vrije markt, dan het “vastzitten” aan een standaard waar meerdere leveranciers met elkaar moeten concurreren. Transitie kost geld, vendor-lock-in kost nog een keer extra geld. Die denkfout wordt ook door Ronald gemaakt.
Dat je elektriciteit van verschillende leveranciers kan betrekken komt doordat de rijksoverheid heeft ingegrepen en standaards heeft vastgesteld (samen met andere landen). Dat betekent niet dat ze energieopwekking op bedrijfs-, lokaal of regionaal niveau willen controleren als lokale asset. De open standaards moeten de handelsbelemmeringen tegengaan. Overigens zullen culturele verschillen en nationale wetgeving er voor zorgen dat er een nationale IT-asset ontwikkeld wordt (closed en open source).
Ik zie geen argumenten waarom de Rekenkamer niet zou mogen bekijken wat de economische effecten van open source zijn, noch wat dat besluit met kwaliteit te maken heeft. Waarom zou de overheid beleid mogen ontwikkelen om minder afhankelijk te zijn van energie die in het buitenland gekocht moet worden, maar niet willen nadenken over software die in het buitenland gekocht moet worden?
Open Source is niet De oplossing, maar kan in veel gevallen wel een deel van de oplossing zijn. En goede open standaards zijn nog belangrijker. Dat wordt elke dag in de praktijk bewezen.