Open Source, Open Standaarden, Open Systemen

Naar aanleiding van een reactie op de E-Learning website waar open systemen gebaseerd op open source en open standaarden genoemd wordt als de huidige trend, en een bericht in de Computable over een intern beleidsdocument van de ministeries van Binnenlandse Zaken en Economische Zaken waarin staat dat de overheid het gebruik van open standaarden en open source software moet stimuleren omdat dat haar minder afhankelijk zou maken van softwareleveranciers. (bron: Computable) wilde ik wat achtergrondinformatie verstrekken over de drie genoemde begrippen. Ze worden namelijk vaak in één adem genoemd alsof ze onlosmakelijk met elkaar verbonden zouden zijn, alsof de ene niet zonder de andere zou kunnen.
Open standaarden (bron)
Een volledig gedocumenteerde specificatie, zonder patenten of andere beperkingen, is een absolute noodzaak om van een Open Standaard te kunnen spreken. Men onderscheidt gewoonlijk drie hoofdtypes Open Standaarden naargelang de garanties die ze de eindgebruiker bieden:
1) Een basisvorm die de gebruiker geen extra waarborgen biedt.
2) Gecertifieerd door een commissie. Dat moet garanderen dat een enkel bedrijf niet naar willekeur de Open Standaard aanpast, zelfs al geeft het de nieuwe specificaties vrij.
3)Genormeerd door door overheden gecontroleerde instanties, zoals ISO.

Zie voor een overzicht van de verschillende standaarden en specificaties (en hun onderlinge verschillen!!) op het gebied van leertechnologie ook de website van Peter Sloep. Overigens zijn niet alle standaarden open, er zijn ook gesloten standaarden. Die zijn eigendom van een bedrijf en dat bedrijf kan bepalen wat er mee mag gebeuren. Bijvoorbeeld ook of een standaard voor een bepaald besturingssysteem beschikbaar komt of welke andere software die standaard mag ondersteunen. Veel van de standaarden die we nu kennen en gebruiken zijn overigens géén open standaarden !

Open Source
Open Source producten zijn die producten waarvan de broncode vrij beschikbaar is voor bestudering, doorgave, modificatie en gebruik. (bron Vereniging Open Source Nederland)
Zie voor een uitgebreidere beschrijving de website van het Open Source Initiative (OSI).

Open Systemen
Het begrip “open systeem” wordt in het Nederlands voor zo ongeveer alles gebruikt wat denkbaar is. Zo vond ik het in het kader van wetgeving, accreditatie, verwarmingsketels, chipkaartsystemen, inspraakprocedures etc. etc.
Deze engelstalige definitie uit de Glossary of Telecommunication Terms van de Amerikaanse regering geeft de nodige duidelijkheid:
open system: A system with characteristics that comply with specified, publicly maintained, readily available standards and that therefore can be connected to other systems that comply with these same standards. (bron Federal Standard 1037C)

Freeware, Copyleft, GNU
Voor een overzicht van andere gerelateerde begrippen als GNU, Freeware, Copyleft etc zie de Free Software Foundation (FSF) website.

Zo te zien zijn het alle drie heel belangrijke zaken, dat klopt. Maar ze zijn geen drie-eenheid en ze zijn ook heel relatief.

Nauwelijks direct bruikbare open standaarden beschikbaar
Op het gebied van onderwijstechnologie zijn er op dit moment een (groot) aantal specificatieks in ontwikkeling. ADL (SCORM), IMS en een paar andere timmeren hard aan de weg om gezamenlijke structuren te ontwikkelen die uiteindelijk kunnen leiden tot open standaarden.
Voorlopig komt alleen de LOM Metadata specificatie op korte termijn in aanmerking voor de Open Standaard status.

Natuurlijk, daarnaast zijn er nog een heleboel andere open standaarden in gebruik: HTML, XML, SVG zijn een paar voorbeelden van open standaarden die zeker hun waarde hebben bij het ontwikkelen van onderwijsmateriaal. Maar ga er niet vanuit dat bijvoorbeeld een labeltje “gebaseerd op de open standaard XML” voldoende is. Er zijn namelijk veel gesloten standaarden die op hun beurt gebruik maken van XML!

De beschikbare specificaties zijn nog onvolwassen
Het centre for educational technology interoperability standards (CETIS) heeft onlangs een praktijkonderzoek gedaan naar de uitwisselbaarheid van contentpackages. Daarbij werd geprobeerd content van het ene tool/de ene softwareomgeving te importeren in de andere. Het onderzoek toonde aan dat er nog veel werk te doen is voordat de verschillende programma’s ook daadwerkelijk content kunnen uitwisselen. Een belangrijke oorzaak was dat, tijdens de vervolmaking van de specificatie, veel verschillende versies verschijnen. Een programma dat voldoet aan versie 1.x kan vaak geen packages van versie 1.y lezen en omgekeerd.

Open Source niet per definitie Open Systeem
Open Source software kan zo gesloten zijn als maar mogelijk is. Immers het feit dat de source code beschikbaar is wil niet zeggen dat ook de voor jou gewenste interfaces en uitwisselingsstandaarden beschikbaar zijn. Ja maar die kun je zelf bouwen zullen voorstanders van open software zeggen. Dat klopt, maar dat kan ook als de leverancier de juiste ontwikkeltools en/of interfacespecificaties beschikbaar stelt. De kosten van het bouwen van een interface hoeven niet te verschillen. Een niet open source systeem kan heel open zijn doordat de leverancier zich tot doel stelt zo veel mogelijk (open) standaarden te ondersteunen. Het is ook maar d
e vraag of je de source nodig hebt. Een van de voorbeelden waar open source versus niet open source nu veel gebruikt wordt is Microsoft Office versus OpenOffice. Waarom zou ik de source-code van een tekstverwerker willen hebben? Het feit dat OpenOffice toevallig open source is, maakt het niet eenvoudiger over te stappen, mijn afhankelijkheid van de leverancier wordt er niet kleiner van. Overigens is het product waar nu het meest over gesproken wordt StarOffice, de niet-gratis, niet open source versie van OpenOffice die door SUN aan de man/vrouw gebracht wordt.

Een open systeem?
Een wereld met één open systeem bestaat niet, of is in ieder geval niet zinvol. Pas als er meerdere open systemen zijn kun je van uitwisselbaarheid spreken. Dus zonder een product X en Y, is een “open systeem” Z onzin. Met welke andere producten kan product Z dan uitwisselen? En op welke manier dan? Pas als je drie open systemen ziet, van verschillende leveranciers, die probleemloos met elkaar kunnen communiceren, weet je dat je op de goede weg bent.
Ook dan zul je je overigens moeten afvragen hoeveel en welke standaarden het systeem moet ondersteunen om “open” te zijn. Is alleen SCORM voldoende (even buiten beschouwing gelaten dat dat geen standaard is) ? Een systeem dat zowel open standaarden als gesloten standaarden ondersteund is veel opener dan een systeem dat zich beperkt tot uitsluitend open standaarden.

Ook met potentiële open standaarden kan het mis gaan.
Hoewel het soms een kinderachtige discussie lijkt, is het verschil tussen specificaties en standaarden niet zo onbeduidend als dat het lijkt. De specificaties zoals opgesteld door het IMS voor bijvoorbeeld metadata, contentpackaging, question and test interoperability (QTI) en de SCORM specificaties zijn nog geen open standaarden. Een actie van IBM onlangs om patentrechten te claimen op een andere potentiëel open standaard, het eveneens op XML gebaseerde ebXML heeft verschillende organisaties, waaronder het CETIS duidelijk gemaakt dat er reden voor zorg is. Hoewel de definitie van een open standaard zoals die hierboven gegeven is, ebXML door de patentrechten zou bestempelen als een gesloten standaard, is het ook van de nu vrij beschikbare specificaties absoluut niet 100% zeker dat het ook open standaarden in de meest pure zin van de definitie worden.

En nu?
Duidelijk zal zijn dat we er belang bij hebben als we open systemen aanschaffen en op basis van open standaarden de verschillende deelsystemen aan elkaar kunnen koppelen. Daarmee kunnen we voorkomen dat we afhankelijk worden van één enkele leverancier en proberen er voor te zorgen dat de overgang naar nieuwe(re) systemen in de toekomst minder moeilijk verloopt dan anders. Dát er nieuwe systemen zullen komen is een wetmatigheid, we gebruiken nu ook geen Lotus 1-2-3 meer, we zullen over 5 jaar geen Microsoft Office meer gebruiken. En ook Blackboard zal als product dan niet meer bestaan. Welk product we dan gebruiken weet ik niet. Of dat een open source product is vind ik niet belangrijk. Belangrijk is dat we als bedrijven (onderwijsinstellingen) streven naar onderlinge uitwisselbaarheid en hergebruik. Dat kunnen we alleen doen door er zelf voor te zorgen dat we op de hoogte zijn van de verschillende specificaties en standaarden, waar mogelijk zelf bijdragen aan de totstandkoming ervan. Daarvoor moeten we ook kritisch zijn bij de aanschaf en bouw van software. Niet zomaar een leverancier vertrouwen als hij een labeltje op zijn product hangt, maar kijken wat je er mee kunt: “O, uw product ondersteund SCORM, maar waar zie ik dat functioneel terug in de applicatie? welke andere systemen kunt u aantoonbaar informatie mee uitwisselen? en wat gebeurt er bij de volgende versie van de specificatie?” etc. En dus vooral nog niet wedden op één paard (systeem, specificatie, standaard).
Daarnaast is een open systeem maar één kant van de medaille. De herbruikbaarheid van content wordt door veel meer bepaald, bijvoorbeeld door de inhoudelijke herbruikbaarheid en curriculum-onafhankelijkheid van het materiaal. Of gewoonweg het formaat waarin de content aangeleverd wordt. Want ook met SCORM kun je HTML documenten uitwisselen waarbij het aanpassen aan jouw situatie net zoveel tijd kost als het helemaal opnieuw maken van de content.