Open systemen zijn lang de droom van veel computergebruikers geweest – en de nachtmerrie van veel leveranciers. Een open systeem betekent dat gebruikers hun systemen bij iedereen kunnen kopen en vrij zijn om te zoeken naar de beste prijs/prestatie-verhouding, zonder loyaal te zijn aan één leverancier.
Open systemen zijn afhankelijk van standaarden; die kunnen componenten van verschillende leveranciers probleemloos laten samenwerken. Er bestaan voorgestelde en gedocumenteerde standaarden voor programmeertalen, besturingssystemen, databases, beheer en communicatie. Het concept faalt echter als niet alle componenten aan één enkele standaard voldoen.
De jure-standaarden worden vastgesteld door diverse commissies. Leveranciers zijn daarin sterk vertegenwoordigd, met als doel – naar men cynisch mag veronderstellen – het proces te vertragen en te verwarren. De meeste de jure-standaarden zijn te complex, te beperkt en te laat. Als een de jure-standaard is vastgesteld, verstoren leveranciers het beeld door eigen functies toe te voegen. Een ‘industrie-standaard met de volgende uitbreidingen’ blijft leveranciergebonden.
De facto-standaarden zijn daarom doorgaans veel praktischer. Dominante leveranciers als IBM bepalen hun eigen standaard en de rest van de wereld bootst deze na om in de markt te blijven. Dominante leveranciers letten echter vooral op hun eigen gevestigde belangen (winst) en niet op de gebruikers, waardoor veel de facto-standaarden abominabel zijn; denk aan Windows 3.1 en Ole.
Zelfs als de jure-standaarden goed ondersteund worden, zijn er problemen. Cobol bijvoorbeeld is goed gedefinieerd en de Ansi-standaard compilers hebben de overhand. In verband met specifieke systeemfuncties als database-toegang en TP-monitors zijn in de praktijk echter speciale extensies nodig. Bij een TP-monitor bijvoorbeeld is de i/o-code gescheiden van de hoofdcode, terwijl de schermafhandeling bij een time-sharing systeem juist door inline code wordt uitgevoerd. Cobol-compilers kunnen daarom alleen maar op de Ansi-standaard gebaseerd zijn.
Een ander voorbeeld zijn relationele databases. Standaard-SQL wordt redelijk ondersteund, maar alle leveranciers bieden belangrijke uitbreidingen voor bijvoorbeeld locking-algoritmen, views en stored procedures. Als deze uitbreidingen niet worden gebruikt, ontstaan ernstige prestatieproblemen. Door deze zelfde extensies echter, werkt een Oracle-programma niet met DB/2 enzovoort.
De leveranciers waren dol op Unix en hetzelfde geldt straks waarschijnlijk voor NT. Unix zelf biedt geen ondersteuning voor zakelijke applicaties. Deze gebruiken geen Unix maar een database en schermfuncties. Er draait dus bijvoorbeeld een Sybase-, Informix- of Oracle-programma op een Unix-doos, en geen Unix-programma. Daarnaast zijn er de leveranciergebonden beheertools. Hoe hard leveranciers hun systemen als HP-UX, Solaris, AIX en SCO ook ‘open systemen’ noemen, echt open zijn ze dus niet.
Sap, leverancier van applicatiepakketten, heeft de situatie verslechterd. Sap R/3 is gebouwd op een 3-tier hiërarchie: een PC voor de gui-client, een Unix-doos voor de bedrijfs-software en een andere Unix-doos voor de database. Het is zo ‘open’ dat men Unix probleemloos kan inwisselen voor NT, OS/2 voor Windows en dergelijke. Zelfs Sap heeft echter problemen met het overdragen van bedrijfs-software naar andere SQL-standaard databases dan Oracle. En als een gebruiker Unix vervangt door NT, wat doet hij dan met zijn beheertools? Erger nog is dat Sap R/3 heeft geschreven in zijn eigen 4GL en dat R/3 specifieke Sap TP-services op de Unix-doos gebruikt. Waarom heeft Sap third-party produkten geïntroduceerd terwijl het ook veel breder beschikbare produkten als Cobol en Tuxedo kon inzetten? Om de gebruiker totaal in het Sap-produkt op te sluiten. Het is een goed produkt, maar ook het meest gesloten systeem dat je je kunt voorstellen – terwijl Sap het profileert als open.
Sommige systemen realiseren ware overdraagbaarheid (Pick en Bos bijvoorbeeld), maar leveranciers hebben deze nooit gesteund – juist omdat ze overdraagbaar waren. Unix was de beste gok; het pretendeerde openheid, maar hoefde dat nooit waar te maken. AS/400 is een uitzondering; elke OS/400-applicatie draait op elke AS/400, waardoor deze oplossing opener is dan Unix en dergelijke.
Van NT gaat een enorme dreiging uit. De Unix-wereld heeft zich daarom erg ingespannen om sommige standaarden te laten samenwerken. Het X/Open-consortium definieert Unix-standaarden (Spec1170) en doet pogingen voor hogere niveaus, zoals SQL, X en graphics (Motif). De Open Software Foundation heeft geprobeerd een alternatieve Unix-versie te definiëren, OSF/1, maar is daar niet in geslaagd. Wel hebben ze goede standaarden voor communicatie (DCE) en beheer (DME) opgesteld. Al met al moeten we blij zijn met de fusie van OSF en X/Open tot de Opengroup – het is beter dan niets.
