In 2002 nam de Kamer de motie Vendrik aan, met de intentie “dat in 2006 alle door de publieke sector gebruikte software aan open standaarden voldoet [en om de (…) software met een open broncode (open source software) in de publieke sector te stimuleren”. Dat leidde eind 2007 tot het actieplan Nederland Open in Verbinding, in de woorden van staatssecretaris Heemskerk: “Gebruik open standaarden, of kom met een zeer goed verhaal waarom dit niet mogelijk is en geef dan aan wanneer ze wél toe gepast worden.” Met als doel “de afhankelijkheid van ICT-leveranciers te verminderen.”
In 2002 nam de Kamer de motie Vendrik aan, met de intentie “dat in 2006 alle door de publieke sector gebruikte software aan open standaarden voldoet [en om de (…) software met een open broncode (open source software) in de publieke sector te stimuleren”. Dat leidde eind 2007 tot het actieplan Nederland Open in Verbinding, in de woorden van staatssecretaris Heemskerk: “Gebruik open standaarden, of kom met een zeer goed verhaal waarom dit niet mogelijk is en geef dan aan wanneer ze wél toe gepast worden.” Met als doel “de afhankelijkheid van ICT-leveranciers te verminderen.”
Open standaarden en open source software
Open standaarden definiëren de principes voor het verwerken en uitwisselen van informatie. Door de definities publiekelijk beschik baar te stellen, is de standaard open. Met als gevolg dat verschil lende softwarepakketten, mits zij dezelfde standaard gebruiken, informatie met elkaar kunnen uitwisselen. Open standaarden worden vaak verward met open source software (OSS). OSS is software waarvan de broncode niet alleen voor de auteurs beschikbaar is, maar ook voor derden.1 Dit betekent dat het iedereen vrij staat om de broncode te gebruiken, te ver anderen, aan te vullen en te distribueren. Door een broncode te veranderen (et cetera), verandert de software, het instrument voor de verwerking van informatie.
De Nederlandse overheid promoot het gebruik van een mengel moesje van open source en open standaarden. Het gebruik van open standaarden is een basale eis (“open standaarden, tenzij”), aangevuld met de intentie om open source software te implementeren.
Voordelen: een ideologische benadering
De Nederlandse overheid stimuleert het gebruik van OSS door het programma Nederland Open in Verbinding (NOiV). Dit programma stelt dat standaarden en open source software belangrijk zijn voor de overheid2, omdat
- open standaarden informatie toegankelijker maken;
- open source software inzichtelijk is, waardoor
- de werking van software transparanter is,
- lokale softwareleveranciers in staat zijn om aanpassingen te doen en het onderhouden van software niet afhankelijk is van één leverancier,
- méér mensen aan de software (kunnen, IvO) werken, zodat de innovatie groter is dan bij gesloten software en de beveiliging ervan verbetert,
- per definitie lagere licentiekosten kent.
Hedendaagse organisaties moeten wel informatie kunnen uitwisselen tussen afdelingen, ketenpartners en klanten. Nut en noodzaak van open standaarden zijn daarom nauwelijks omstreden, hoewel er nog wel wat gesloten standaarden in omloop zijn.
Nut en noodzaak van Open Source Software is stukken lastiger vast te stellen. Dat komt doordat de opgave zo ongenuanceerd is. Alsof aangetoond moet worden dat auto’s met een ‘open’ motorkap beter zijn dan auto’s met een gesloten motorkap.
Natuurlijk heb ik in principe liever een auto met een open kap: die kan ik overal laten repareren. Maar als ik een 4×4 (auto met vierwielaandrijving, red.) nodig heb omdat ik in de rimboe woon, dan heb ik niets aan een open Trabant. Dan maar liever een dichtgelaste Landrover. Waarmee gezegd zij dat de transparantie van OSS een mooi beginsel is, maar dat er meer criteria nodig zijn om vast te stellen welk product bij mij past.
Risico’s en randvoorwaarden: een praktische benadering
Om een geschikte en werkbare oplossing te selecteren, is een concrete en praktijkgerichte toetssteen nodig. Bijvoorbeeld het Open Source Maturity Model van Capgemini (oorspronkelijk alweer van 2003).3 Een model dat trouwens ook door NOiV is omarmd. Door middel van dit model kun je:
- de volwassenheid van open source software beoordelen, bijvoorbeeld hoeveel ontwikkelaars werken aan de software, en hoe lang al;
- inzicht krijgen in de ‘match’ tussen de software en de business requirements; bijvoorbeeld de mate waarin de software integreert met andere pakketten, en of de software modulair is en gemakkelijk te beheren;
- open source software vergelijken met gesloten producten; zoals ten aanzien van gebruiksvriendelijkheid, interfaces, performance;
- het belang van een leverancier duidelijk maken; bijvoorbeeld ten aanzien van de onafhankelijkheid van de leverancier en het platform, zoals Microsoft of Linux, ondersteuning, advies, training, implementatie, enzovoort.
Kortom, open software moet voldoende ontwikkeld zijn en blijven, passen binnen de organisatie en gelijk of beter presteren dan andere software. Tenslotte mag je er niet te afhankelijk van worden en moeten er degelijke leveranciers zijn. Het zal u niet verbazen dat in de realiteit grote verschillen bestaan.
Kun je op open source-oplossingen vertrouwen?
Op de vraag of een (documentair) informatiemanager op open source software kan vertrouwen, bestaat niet één antwoord. De genoemde criteria maken inzichtelijk waarom het ene softwarepakket geschikt is voor implementatie en het andere niet. De criteria zijn zelfs zodanig van aard, dat ze grotendeels toepasbaar zijn op open én gesloten software. Met andere woorden: open source software is – net als gesloten software – geen heilige graal.
OSS kenmerkt zich doordat die in principe door meer en verschillende partijen kan worden aangepast en verbeterd. Of dat in de praktijk ook daadwerkelijk gebeurt en of dat leidt tot een Landrover of een Trabant, verschilt van product tot product.
Drs. Ivo van Onna is adviseur bij Doxis Informatiemanagers.
1 Voor een uitgebreide definitie, zie: http://opensource.org/docs/osd
2 Zie http://www.noiv.nl/waarom_ososs
3 Zie voor een overzicht van bestaande modellen: http://en.wikipedia.org/wiki/Open_source_software_assessment_methodologies
