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.
@Wim: mooie lijst van punten die aan de orde zijn bij het gebruik van software.
@Mic: goed verhaal waarin je de zaak rond software meer in het algemene trekt.
Wat mij opvalt, is het volgende.
De lijst van Wim gaat voor elke keuze van software op. Zijn vaststelling dat veel bedrijven Microsoft kiezen als standaard, is een verwarring die veel voorkomt. De software van Microsoft werkt in veel gevallen (redelijk) goed samen als alle versies binnen de door MS gestelde range liggen. De opslagformaten van MS zoals, tegenwoordig, Docx, Xlsx en dergelijke zijn g e e n standaarden. Het zijn een veel gebruikte opslagformaten.
De zelfde opmerkingen gaan op voor de MS GUI en aanverwanten. Veel gebruikt maakt het geen standaard en zeker geen open standaard.
Mic’s argument snijdt hout: open source ontstaat nooit gratis. Het gebruik, distribueren en wijzigen naar eigen behoefte van deze broncode is dat echter wel. Closed software kost geld op alle drie de punten. Natuurlijk hebben de mensen die de open source wijzigen ook een levensonderhoud nodig, dus kost dat geld. Maar je hoeft geen geld te geven voor het recht te mogen wijzigen.
Wat steeds achterwege blijft in de discussies over open source is de vrijheid. Open source geeft vrijheid. Misschien is dat wel de grootste tegenstander van de Open Source Software: Vrijheid. Bedrijven, organisaties, mensen zijn bang voor deze vrijheid. Vrijheid komt namelijk met verantwoordelijkheid. Verantwoordelijkheid voor ontwerpen, bouwen, onderhouden, gebruiken en wat dies meer zij rond software.
Stel nu eens dat de Rijksoverheid 1 desktop OS, 1 server OS, 1 kantoorautomatiseringspakket, 1 CMS, 1 DMS, 1 … heeft. Maakt niks uit of het OSS of CS is.
Hoe je het ook wendt of keert, CS moet je kopen om te mogen gebruiken, support moet je kopen onder voorwaarden, CS mag je nooit distribueren en CS mag je absoluut nooit aanpassen anders dan met goedvinden van de leverancier.
Hoe je het ook wendt of keert, OSS kost je niks om te gebruiken, support moet je kopen. Zonder voorwaarden echter. OSS mag je vrij distribueren en aanpassen naar lieve lust.
Nu nemen we een nieuw project van de Rijksoverheid. Om CS te gebruiken zit een traject van aanschaffen in het voortraject vanwege de licenties. De gekozen CS moet of kunnen samenwerken met de omgeving of een extra interface wordt ingesteld om te kunnen koppelen. Mocht de omgeving geen software hebben om de koppeling mee te maken moet ook daar het traject van aanschaf doorlopen worden.
Bij OSS het je geen licentiekwestie, in het geval van een interface de keuze of je het pakket aanpast om naadloos samen te werken of een externe interface bouwt en als andere partijen geen software hebben die mee kan werken distribueer je de nodige software.
Deze zelfde constructie is van toepassing op nog veel meer aanverwante gebieden die de kosten van software uitmaken.
Nu weer even terug naar de bevindingen van de Algemene Rekenkamer. Niet je kosten maar je strategie moet bepalend zijn. Als je strategie bepalend moet zijn, moet alles wat kosten maakt rond software gewogen worden. Overigens moet de strategie in lijn blijven met andere onderdelen van de bedrijfsstrategie. Eén van de onderdelen is kostenreductie. Het gebruik van software moet dus zo goedkoop mogelijk.
Wanneer je deze strategie voorop stelt dan gaat CS het altijd verliezen van OSS waarvan zelf bepaald wordt wanneer de software ‘end of lifecycle’ heeft, geen verplichte winkelnering heeft in de vorm van certificering en dergelijke om ondersteuning te kunnen blijven krijgen, enzovoort.
Daarnaast is strategie nooit een kort lopende planning. Dat is tactiek.
Als niet de kosten maar de strategie leidend moeten zijn, zijn dus alle migratie en overige genoemde kosten die de overstap belemmeren geen argumenten.
Het feit dat de Rijksoverheid dus geen OSS implementeert heeft dus te maken met gebrek aan strategie. Of, want er lijkt wel iets van een strategie te zijn (NOiV), blijkbaar een gebrek aan leiders die de strategie kunnen overzien en doorvoeren.
Komt de aap toch uit de mouw: OSS geeft vrijheid, dus verantwoordelijkheid. Het feit dat wij als gemeenschap de mensen in de overheid geen opdracht geven OSS voortvarend in te voeren, ligt dus aan onszelf. De vraag rond OSS wordt dan: zijn wij als gemeenschap bereid om onze verantwoordelijkheid te dragen voor de bestedingen rond al de ICT ten dienste van onze gemeenschap?
@ Ernest
zowel bij open source als bij closed source heb je (mogelijk) een vendor lock-in. Vendor lock-in is niet een fenomeen dat exclusief is “voorbehouden” aan closed source.
De argumentatie dat je bij OS geen vendor lock-in hebt OMDAT je kunt sleutelen aan de software, is onzin.
De meest gangbare definitie van Vendor lock-in (zowel binnen als buiten de IT wereld): “Vendor lock-in, also known as proprietary lock-in or customer lock-in, makes a customer dependent on a vendor for products and services, unable to use another vendor WITHOUT SUBSTANTIAL SWITCHING COSTS.”
Dus vendor lock-in wordt in hoge mate bepaald door de wisseling/transitie/switching kosten, of anders gezegd de kosten die je moet maken om een alternatief te gaan gebruiken.
@ Technicus; bij CS zal je niet aan de “core” sleutelen, maar eromheen, dus op een ander niveau, om zo de functies te realiseren die je nodig acht. Overigens, kun je je afvragen of je bij OS aan de core wilt sleutelen, dat zorgt er immers voor dat je in het vervolg moet nagaan of wijzigingen in de core door de “core owner” niet van invloed zijn op jouw aangebrachte wijzigingen en dat werkt kosten verhogend.
@ICT-er,
opmerkelijk dat je in je reactie spreekt over open standaard, vendor lock-in en wisselen van, terwijl ik het heb over open source en vendor lock-in. Ik neem aan dat je begrijpt dat open standaard niet het zelfde is als open source (en vice versa).
mbt dat een transitie geld kosten en dat vendor lock-in extra geld kost, geeft aan dat je een eigen, niet algemeen gangbare defintie hebt van vendor lock-in, en maakt mij benieuwd over welke additionele kosten je het hebt?
je argumenten waarom er lokale IT-asset zullen ontstaan zijn de zelfde argumenten waarom destijds een wasmachine van frans fabrikaat niet in nederland verkocht werd en omgekeerd, totdat (inderdaad) de (europese) overheid ingreep. Tzt zal dat ook op het ICT gebied plaatsvinden. De vraag is of je daarop gaat wachten (en dus iets realiseren wat na verloop van tijd waardeloos wordt) of wat anders gaat doen.
Wij hebben hier in Nederland een digitaal stem loket gehad. Die kon niet meer, want die was onveilig en daarnaast kon het bedrijf dat de software leverde te makkelijk de stemmen beinvloeden mocht zij dat willen.
Wij hebben dat systeem gehad. Heeft veel geld gekost om te implementeren, is maar een paar keer gebruikt en is toen bij het oud vuil gezet.
Dit heeft allemaal een hoop belastingsgeld gekost en we zijn we terug bij af.
Bij onze zuiderburen kan het wel. Door Open Source software te gebruiken kan er niet geknoeid worden en men maakt het veilig door meerdere mensen tegelijkertijd te laten stemmen.
In Duitsland schijnen ze het bij de gemeentes wel te begrijpen. Daar kan het wel.
@Mic: Ik begrijp het “Core” verhaal niet helemaal. Ik had het gewoon over de regels C++, C# of wat voor programmeertaal ook die leesbaar is en aan de andere kant de binaire bestanden die alleen door de processor van de machine begrepen kunnen worden.
Beste Mic, lees mijn reacties nog maar een keer, dan zie dat ik het onderscheid ken tussen open standaarden en open source. Vendor lock-in is koppelverkoop door bijvoorbeeld het inzetten van patentrechten rond koppelvlakken van hard en software en door garanties te koppelen aan onderdelen, supplies en diensten te leveren door de dezelfde vendor.
Bij elke transitie heb je te maken met investeringen in nieuwe hardware of nieuwe software, trainingen, migratieactiviteiten. Bij vendor lock-in moet je vaak meer vervangen en afschrijven, dan jouw bedoeling is. Bijvoorbeeld als je in de hoogtijdagen van de vendor lock-in een applicatie van een fabrikant wilde vervangen door één van een andere fabrikant, dan moest je vaak ook het OS, de server, de bekabeling en nog meer zaken vervangen. Apple doet dit nog in hoge mate.
Meerdere (defacto) standaards of vendor lock-in is voor onze overheid of de Eu geen reden om in te grijpen. Overheden zoals de Eu grijpen doorgaans pas in bij antitrust zaken. De universele telefonie-adapter is hierop een uitzondering.
Deze conclusie is “De Rekenkamer” zeker voorgerekend door hun “closed-source business vriendjes”….. daar ik de overheid zelf niet echt veel inhoudelijk verstand van IT aan de dag zie leggen (al jaren niet) 😛
@ ICT-er
Wat mij betreft maak je ten onrechte geen onderscheid tussen vendor lock-in en koppelverkoop (je stelt “ Vendor lock-in is koppelverkoop”), het is zeer zeker mogelijk dat er een vendor lock-in ontstaat als gevolg van koppel verkoop, het is niet het zelfde (alle koeien zijn dieren, maar niet all dieren zijn koeien).
Koppelverkoop is (wat mij betreft) een beperking in het kiezen van aanvullende diensten/producten omdat je voor een bepaald product/dienst hebt gekozen. Als je voor een Parker-pen kiest, ben je gedwongen de vullingen van het merk Parker te gebruiken, andere leveranciers kunnen die niet leveren om diverse redenen, waarvan een patent er een is. (Het zou dus ook heel goed mogelijk zijn dat ook bij OSS van koppelverkoop sprake is.)
Vendor lock-in ontstaat doordat de kosten(financieel/inspanning/emotioneel) voor het in gebruik nemen van een alternatief, (een Bic-pen in plaats van een Parker-pen) te hoog zijn (je hebt bv 100.000 Parker- vullingen op voorraad en die kun je weggooien) en niet opwegen tegen de voordelen (bv lagere “operationele schrijf kosten).
Dat zowel vendor lock-in als koppel verkoop resulteren in een beperking van de keuze vrijheid is zonder meer waar, maar daarom zijn nog niet twee omschrijvingen voor een zelfde situatie. Net zo min is het ontbreken van gemeenschappelijke standaards het zelfde als vendor lock-in.
Wat betreft de invloed van de overheden op standaards denk ik dat je die ten onrechte onderschat, en zeker die van de EU op het gebied van gemeenschappelijke standaards. De euro, de SEPA, de kleur-codering van elektriciteitskabels, toelatingseisen voor geneesmiddelen, samenstelling van de bio-autobrandstof, fijn-stof-emissie eisen, normen voor geluidsoverlast zijn allemaal voorbeelden van Europese (gemeenschappelijke) standaarden (afspraken) die dwingend zijn opgelegd. Met als resultaat een hogere kwaliteit tegen lagere kosten.
Het kern-probleem van de ICT of beter gezegd van de automatiseringswereld is dat resultaat zo vaak tegen valt, en de kosten vaak zo hoog uitvallen, daarom wordt gezocht naar alternatieven. Hoe die alternatieven worden gerealiseerd (op basis van closed/open source) is veel minder van belang (voor de eindgebruiker) dan de mogelijkheid om bij gebleken dis-functioneren van een oplossing (of component) dit te vervangen door een oplossing (component) van een andere leverancier.
Hiervoor zijn gemeenschappelijke standaards essentieel (en dat is heel wat anders dan dat iedereen een eigen open standaard heeft), en daaran dienen dan zowel de CS als de OS software (oplossingen) te voldoen.
@Mic: Een budgetaire barriere is geen vorm van vendor lock-in.
Jouw Parker metafoor is een mooi voorbeeld, maar je moet iets verder gaan.
Er gaan alleen Parker vullingen in. De Parker pen doet het na 2 weken gebruik alleen nog goed schrijven op Parker papier.
Het Parker papier kan alleen in Parker Enveloppen. Deze Parker Enveloppen kosten 500 euro per stuk.
Dat is een geval van vendor lock-in en dat lijkt verdomd veel op koppelverkoop.
@Technicus,
Je kunt de lijst van afhankelijkheden nog veel verder uitbreiden; Parker postzegels, Parker postbodes etc etc. en dat is zeker allemaal koppelverkoop, omdat je gedwongen bent die producten af te nemen bij een vooraf bepaalde leverancier.
Of het vendor lock-in is hangt van het alternatief af.
Als je gemakkelijk (lage kosten, weinig inspanning, je hebt je niet emotioneel gehecht aan de Parker pen etc) kunt switchen naar de Bic pen, die vervolgens ook de hele riedel van attributen heeft, en dus een vergelijkbaar alternatief is, is er geen sprake van vendor lock-in (je kunt gemakkelijk switchen naar een andere vendor, de deur is niet op slot), maar nog steeds wel van koppelverkoop (eventueel ook bij de Bic-pen).
Als je vervolgens kiest om NIET te switchen (van Parker naar het gelijkwaardige Bic alternatief) is dat geen vendor lock-in, maar een keuze van de gebruiker, die nog steeds wordt geconfronteerd met de koppelverkoop praktijken van Parker.
Als je besluit om niet te switchen omdat de totale kosten (financieel, emotioneel, inspanning etc.) van de “Parker–offering” vele malen goedkoper zijn dan die van de “Bic-offering” of omdat de totale transitie kosten (financieel, emotioneel, inspanning etc.) te hoog zijn, dan ben in-gesloten door de vendor Parker.
Wat ik nu zo opmerkelijk vindt in de wereld van automatisering, is dat bij het onderwerp vendor lock-in (en in mindere mate koppelverkoop) wordt afgegeven op de leveranciers van IT technologie, de HW en SW fabrikanten en leveranciers. Eigenlijk zou je naar de dienstverleners (business & it-consultants en software engineers) moeten kijken, zij zijn de grootste veroorzakers van de vendor lock-in, en technologie leveranciers in veel mindere mate.
Bij iedere automatiseringsoplossing gaat het leeuwendeel van het budget naar de dienstverleners. Gartner c.s. geven al jaren aan dat dit ergens rond de 65 tot 75% van het budget ligt. Of anders gezegd, zij veroorzaken het grootste deel van de transitie kosten, en dus in belangrijke mate de vendor lock-in.
De uitvoerders van de Open Source gebaseerde projecten zijn, opmerkelijk genoeg, wederom business & It consultant en software engineers (weliswaar van een andere bloedgroep dan de uitvoerders van Closed Source projecten, maar niet wezenlijk anders, ook zij moeten hun energierekening betalen, brood kopen, en hebben dus een inkomen nodig, wellicht berekenen zij lagere tarieven dan de grote system integrators, maar dat heeft niks te maken met de discussie closed vs open source). De door hun betaalde werkzaamheden creëren zij (mogelijk) wederom een vendor lock-in. (de pot verwijt de ketel …)
Zou je significant willen besparen op de automatiseringskosten, en de kwaliteit verhogen, dan zou je in hoge mate het werk van de automatiseerder moeten automatiseren.
Beste Mic, we kunnen je nu niet meer volgen. Je geeft me inhoudelijk gelijk, maar zegt dan weer van niet.
Aangezien vendor lock-in een Engelse term is, heb ik hieronder een Engelstalige definitie gezet.
“In economics, vendor lock-in, also known as proprietary lock-in, or customer lock-in, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs. Lock-in costs which create barriers to market entry may result in antitrust action against a monopoly.”
Dus het gaat bij vendor lock-in om het opwerpen van economische barrières bij zowel de keuze van aanvullende diensten als bij de vervanging.
Wat voorbeelden uit de ICT.
Compaq voegde vroeger bij de harde schijven hardwarematige (printplaat) patches toe. Die schijven werden niet door Compaq gemaakt, maar door externe leveranciers zoals Quantum die ook aan hun concurrenten en aan gebruikers leverden. Dat maakte de schijven ietsjes duurder in productie. Maar de Compaq schijven waren wel veel duurder in aanschaf (maar niet beter weet ik uit eigen ervaring). Wilde je standaardiseren op bijvoorbeeld IBM, dan kon je zonder normale printplaat niks met de dure Compaq schijven.
Compaq ging nog verder. Bij problemen met Compaq servers kon je geen gebruik maken van hun garantie als er “niet-Compaq” onderdelen inzaten, zoals geheugenmodules. De grap was dat Compaq geheugenmodules elders inkocht, bijvoorbeeld bij Hyuday of LGS, en er hun stikker opplakten (de oude fabrikantenstikker zat er nog onder). Ze vroegen er extra geld voor. De Compaq dealer had daar ook baat bij, want ze verdienden twee keer zo veel de geheugenmodule met die extra sticker. De bekende VOID stikkers zaten er niet voor niets op. Toen Compaq door HP overgenomen was, mochten er uiteraard ook door HP gestikkerde componenten inzitten.
Microsoft maakt het nog bonter door hardwarefabrikanten te benadelen die ook niet-MS producten meeverkochten. MS trouwe leveranciers konden de MS licenties goedkoper inkopen en dus voor een lagere prijs aanbieden. Wilde je als klant UNIX of Linux voor x86/ x86-64 PC’s aanschaffen, dan moest je de hardware van een andere PC-fabrikant kopen. Voor die praktijken is MS zwaar beboet omdat MS de x86/ x86-64 PC-markt domineerde en de gehele ICT-industrie werd aangetast.
Quote: “Zou je significant willen besparen op de automatiseringskosten, en de kwaliteit verhogen, dan zou je in hoge mate het werk van de automatiseerder moeten automatiseren”.
@Mic: Wij hebben dat – komend vanuit gedetacheerd systeembeheer – als softwarebedrijf zeer succesvol gedaan tussen 2001 en 2006. We hebben – met pijn en moeite – ons klantenbestand in die tijd wel verdubbeld, maar niet vervijfvoudigd (zoals noodzakelijk was om de gedaalde gemiddelde omzet per klant te compenseren).
De enige grote partij met wie we serieus in gesprek zijn gekomen was KPMG. Maar dat was meer vanuit de wederzijdse affiniteit met en bewondering voor de technologie. Partijen als Randstad, verzekeraars en banken kom je niet eens bij aan tafel.
Je houdt alleen maar klanten over waarbij je direct in gesprek bent met degene om wiens portemonnee het gaat (en het ook nog begrijpt). Dat is het enige voordeel.