In de afgelopen periode is er veel geschreven over de langzame invoering van het actieplan Nederland Open in Verbinding (NOiV). Een van de belangrijkste factoren van deze langzame invoering is de langdurige, onjuiste samenvoeging van de discussie rondom open source en open standaarden. Het loskoppelen van beide termen brengt het vliegwiel weer in beweging.
In de kern zijn open source en open standaarden twee verschillende onderwerpen. Voor de helderheid: open source is een ontwikkelmethodiek waarmee de broncode ter beschikking wordt gesteld voor ontwikkeling en productie en open standaard is een specificatie voor software die wordt vastgesteld en bewaakt door een onafhankelijke instantie. De discussie rondom de samengevoegde termen wordt integraal gevoerd over een aantal assen, te weten kosten, interoperabiliteit en (on)afhankelijkheid van een leverancier.
Onlangs werd in Computable nog uitgebreid gediscussieerd over het kostenaspect van open source-software versus closed source-software. De conclusie is dat de prijs niet primair zou moeten bepalen of open source-software wel of niet gebruikt moet worden. Een juiste keuze moet gemaakt kunnen worden door een juiste inhoudelijke vraagstelling in de aanbesteding. Een mooie uitdaging voor de Inkoopafdelingen...
De (on)afhankelijkheid van een leverancier is een lastigere discussie. Een belangrijke vraag hierbij is of het nadelig is om afhankelijk te zijn van een leverancier. En bewerkstelligt het gebruik van open source-software werkelijk volledige onafhankelijkheid? Deze discussie is formeel al afgesloten met de motie-Vendrik die reeds in 2002 is aangenomen door de Tweede Kamer. Inmiddels is deze vertaald in het actieplan NOiV, maar in de praktijk heeft deze motie nog geen draagvlak verworven binnen de overheid. Het actieplan dient als concretisering om dit verandertraject te versnellen.
Op het gebied van interoperabiliteit is de discussie niet zo moeilijk. Uiteraard moet de overheid streven naar open standaarden, maar het is niet per definitie zo dat dit met het gebruik van open source-software wordt opgelost. Tevens zijn er tegenwoordig ook vele closed source-producten beschikbaar die voldoen aan het principe van open standaarden. Het integreren van de discussie rondom open source en open standaarden in één actieplan is dan ook niet verstandig en zou in twee delen gevoerd moeten worden. Hiermee kunnen de open standaarden worden geïmplementeerd terwijl de discussie/weerstand op het gebied van open source kan worden afgerond. Het NOiV komt daarmee weer in beweging.
Alles in perspectief plaatsen lijkt me aan de orde. Als de motie Vendrik er onvoldoende in slaagt om in een periode van 5 jaar (nov 2002 - sept 2007) meters te maken dan denk ik dat de prestaties van NOiV vanaf september vorig jaar door Bart Omlo tekort worden gedaan.
Bart zegt in zijn artikel dat OS en OSS in de kern twee verschillende onderwerpen zijn. Dat is juist. Echter; het actieplan Nederland Open in Verbinding gaat daar dus niet over en vooral het programma NOiV heeft dit benadrukt. Nog even ter herinnering:
- vergroten van interoperabiliteit
- verminderen van leveranciersafhankelijkheid
- bevorderen van gelijk speelveld op de softwaremarkt
Een samenvoeging van termen die Bart noemt is wat mij betreft in de details van het actieplan dus ook niet aan de orde. Dat blijkt vooral uit de rol van Forum Standaardisatie die zich uitsluitend op de open standaarden richt. Dat de beide termen vaak in 1 ademzucht worden genoemd is iets anders, mogelijk historisch gegroeid?
Het kostenaspect van open source software versus gesloten source software waarover in de Computable is gediscussieerd leidt juist tot samenvoeging van termen! Als je daar dus aan meedoet dan lever je een bijdrage aan de verwarring die inkopers nu waarschijnlijk toch al ervaren. Er zijn bovendien meer dan voldoende criteria waar inkopers rekening moeten houden, niet voor niets wordt met de slogan "comply-or-explain and commit" uitsluitend op open standaarden gedoeld [1].
Is het nadelig om afhankelijk te zijn van een leverancier, dat wordt door Bart gevraagd. In de praktijk heeft deze stelling volgens hem nog weinig draagvlak maar daarvan zie ik andere feiten. Zie ook dit sprekende voorbeeld [2]. Natuurlijk zie ik ook de "opstartproblemen" die er zijn, bijvoorbeeld als we kijken naar de aanbesteding van de GOUD werkplek. In dit specifieke voorbeeld wordt de projectleider Jan Arnoud ten Cate [3] JUIST geconfronteerd met de nadelen van leveranciersafhankelijkheid. Een beter signaal vanuit de praktijk naar leveranciers en politieke beslissers is eigenlijk niet mogelijk. Soms moet je een paar keer de neus stoten om het de volgende keer in 1 keer goed te doen.
Tenslotte de discussie over interoperabiliteit en discussie/weerstand op het gebied van open source software. Als de gebruiker in zijn functionele beschrijving heeft aangegeven dat interoperabiliteit noodzakelijk is dan doet het er toch niet toe of die eis wel of niet met open source software wordt ingevuld? Dus vanwaar die discussie? Er volgt gewoon een software-selectie traject waarbij wordt getoetst of aan eerder genoemde criteria worden voldaan.
Alles kan altijd beter. Mijn cryptische omschrijving dat het gedachtengoed achter NOiV er nog lang niet is. Dat hoeft ook niet en is ook onredelijk om te verwachten. Duurzaamheid en onafhankelijkheid in de IT is relatief nieuw en wordt zwaar bevochten waarbij de lieden van NOiV op de middenstip van het voetbalveld staan. Daarover zijn Bart en ik het in ieder geval eens.
Bauke Keulen | Yacht
[1] http://www.ez.nl/Onderwerpen/Betrouwbare_telecom/Open_Standaarden_en_Open_Source_Software/Ontwerptekst_instructie_Comply_or_explain_commit
[2] http://www.aanbestedingskalender.nl/noticedetails.aspx?id=35f4e4fa-ed7a-4844-8136-3e9fc3282c10
[3] http://digitaalbestuur.nl/db-diep/goud-gaat-goed
Met de stelling dat open standaarden en open source in artikelen en discussies beter uit elkaar gehouden moeten worden ben ik het volledig eens. Voor het toepassen van open standaarden zijn namelijk heel andere argumenten van toepassingen als voor het toepassen van open source.
Een discussie over open standaarden en los daarvan een discussie over open source is een stuk overzichtelijker.
Lees ook