In ‘andere tijden’ van de cartografie schreef men ‘Here Be Dragons’ in nog niet goed in kaart gebrachte gebieden. In meerdere opzichten geld die term nu ook nog voor het domein ‘interoperabiliteit’. Veel verhalen, veel meningen, veel inzichten. Een aantal ‘ontdekkingsreizigers’ doen verhaal van hun ervaringen en maken het soms dramatischer dan de werkelijkheid.

image image

In de praktijk ervaren we als ‘digital native’ dagelijks ‘ongemerkt’ vele vormen van uitwisseling van informatie en ervaren we ?gemerkt? soms een aantal drempels. Software applicaties kennen verschillende middelen om informatie uit te wisselen en interoperabiliteit te bieden. in hoofdlijnen zijn de belangrijkste drie:

  • Application Programming Interface (API)
  • Protocol
  • Formaat

image

In een vereenvoudigde representatie zou je kunnen zeggen dat de ieder van deze drie middelen een eigen verbijzondering van interoperabiliteit kan bieden:

  • API ? functionele interoperabiliteit
  • Protocol ? transactionele interoperabiliteit
  • Formaat ? informatie interoperabiliteit

Via een API kan een applicatie van extra functionaliteit worden voorzien. Bijvoorbeeld functies die niet door de oorspronkelijke ontwikkelaar/uitgever zijn voorzien. Bekende voorbeelden zijn de APIs van Microsoft Windows en Microsoft Office. Succesvol toegepast door een zeer groot aantal ondernemingen en individuele ontwikkelaars voor eigen toepassingen en uitbreidingen.

Middels een protocol kunnen applicaties synchroon interactief informatie uitwisselen.  Bekende voorbeelden zijn HTTP voor uitwisseling van informatie via internet ?browsers?.

Formaten zijn in feite de representatie van informatie. Voor opslag en/of transport. Bekende voorbeelden  zijn het binaire bestandsformaat voor Microsoft Office (de bekende: doc, xls, en ppt bestanden), en HTML voor world wide web pagina?s.

image

De broncode van een software applicatie kan ook de basis zijn voor het realiseren van interoperabiliteit. Maar de API, protocol en formaat middelen bieden een laagdrempeliger, goedkoper en beheersbaardere mogelijkheid voor interoperabiliteit. Interoperabiliteit via (of afhankelijk van) inzicht en het aanpassen van broncode is de meest kostbare vorm van interoperabiliteit. Je kunt je voorstellen hoe onpraktisch, tijdrovend en foutgevoelig het zou zijn om voor interoperabiliteit tussen web browsers afhankelijk te zijn van de broncode van die browsers.

Voor de API, protocol en formaat geldt een spectrum aan mogelijkheden voor het gebruik van deze middelen. Van volledig voorbehouden aan de eigenaar/ontwikkelaar van de software toepassing (gesloten), of volledig open en zelfs zonder beheer (‘free’).

image

Daartussenin liggen voor interoperabiliteit de meest interessante opties. Voor de meeste API’s (interfaces), protocollen en formaten geldt dat ze gepubliceerd worden in een handleiding, of onder betaalde of gratis licentie worden aangeboden. Een aantal wordt gepubliceerd voor vrij gebruik door iedereen (open of vrije specificatie) zonder dat daar een licentie voor nodig is. En een aantal API’s, protocollen en formaten zijn ?open standaard? waardoor er onafhankelijkheid is in de ontwikkeling.

Iedere kolom in het spectrum heeft eigen consequenties, voor- en nadelen. In de praktijk is het niet zo dat ‚‚n kolom andere verdringt, ze vullen elkaar aan. De gebruiker, ontwikkelaar, en de bedenker van de interface, protocol of het formaat hebben keuzes en afwegingen te maken. Die afwegingen hebben te maken met factoren zoals beschikbaarheid, kwaliteit, functionaliteit, adoptie, gebruik, dynamiek van/in het domein en meer.

Broncode is duidelijk niet de eerste keuze voor het bereiken van interoperabiliteit. Maar broncode is wel in diverse opzichten relevant. E‚n blik op dat onderwerp is wat men met de broncode zou willen kunnen. Wederom is daar keuze voor zowel de gebruiker, ontwikkelaar, en de bedenkers van de software toepassing.

image

Het spectrum voor broncode loopt hier van een behoefte tot het gebruik van het eindresultaat (de software applicatie zelf) tot en met een behoefte om de broncode te mogen aanpassen en door ontwikkelen naar eigen inzicht. Software applicaties die onder een ‘gebruiks recht’ worden aangeboden kunnen ook voorzien worden van een recht op ‘inzage’ of ‘verificatie’ van de broncode. Bij applicaties die onder een ‘hergebruiks recht’ worden aangeboden is het verifi‰ren en de inzage al mogelijk.

Het participeren in de ontwikkeling van de ‘originele’ broncode is niet per definitie ‘licentie’ of model afhankelijk. Vormen van participatie in ontwikkeling kunnen ingericht worden onafhankelijk van de licentie die van toepassing wordt verklaard op de uiteindelijke code onder een software toepassing.

En let ook op dat voor het aanpassen van functionaliteit in een software toepassing, de eerder genoemde Application Programming Interfaces een ‘beheerste’ manier vormen. Voor het uitbreiden, of aanpassen van functionaliteit in een toepassing is niet per definitie toegang tot de orginele broncode noodzakelijk. Software configuratie, opties en API’s zijn daar eveneens ‘beheersbare’ middelen voor.

DUS?

Waar ik over het algemeen een vrolijke dag van krijg zijn de discussies over gesloten software versus open software. Prima, leuk tijdverdrijf, maar in veel gevallen onderschat men de openheid van veronderstelde ‘gesloten software’ en de geslotenheid van veronderstelde ‘open software’. En het bovenstaande kan voor deskundigen lijken op een ‘over simplificatie’, maar dat gaat vele malen meer op voor veel de inhoud van veel  van de ‘versus’ discussies.

Bovenstaande kreeg ik niet goed onder woorden binnen 140 tekens in een reactie op twitter, maar voel je vrij te interacteren :-)

twitter.com/hansbos