Er is een moment zo vanzelfsprekend dat we het helemaal niet opmerken.

U steekt een netwerkkabel in een wandcontactdoos. De contactdoos komt van een Duitse fabrikant, de kabel uit Taiwan, de switch eronder uit Californië, de router erachter uit Zweden. En het werkt. Niet omdat iedereen aardig voor elkaar is. Maar omdat iedereen zich aan dezelfde regels houdt: IEEE 802.3 — Ethernet.

Dat klinkt banaal. Het is banaal. En juist daarom is het opmerkelijk.

Wat een standaard werkelijk is

Een standaard is geen software. Geen apparaat. Geen product. Een standaard is een afspraak. Een gedeelde taal waarin mensen en machines communiceren zonder elkaar persoonlijk te kennen.

Op de kleinste schaal betekent dat: stekkers passen. Op de grootste: het internet werkt. Daartussen ligt een wereld van specificaties die bepalen hoe gegevens worden gecodeerd, verzonden, geïnterpreteerd en bevestigd — zodat miljoenen apparaten die nooit van elkaar wisten met elkaar kunnen praten.

Wie dat eenmaal begrijpt, ziet de digitale wereld met andere ogen. Niet als een verzameling magische dozen, maar als een weefsel van afspraken die ooit iemand heeft opgeschreven.

Zonder standaarden geen digitaal ecosysteem

Het internet zoals we het kennen zou zonder standaarden onmogelijk zijn. TCP/IP, gedefinieerd in de RFC’s van de IETF, is het protocol dat elk apparaat met het netwerk verbindt. HTTP, eveneens in RFC’s gespecificeerd, is de basis van het World Wide Web. DNS vertaalt namen in adressen. TLS versleutelt verbindingen. SMTP transporteert e-mails. BGP routeert datapakketten rond de hele wereldbol.

Geen van deze technologieën is eigendom van een bedrijf. Geen is geheim. Elk is op papier gezet, gepubliceerd, door iedereen leesbaar, door iedereen te implementeren. Juist die openheid is de reden waarom het internet kon groeien — niet als product van één leverancier, maar als ecosysteem waaraan iedereen mocht deelnemen.

Had men het internet propriëtair gebouwd, dan had het nooit deze omvang bereikt. Er zouden veel kleine netwerken zijn die niet met elkaar spraken. Precies dat was de telecommunicatiewereld vóór de standaarden: eilandoplossingen die alleen binnen eigen muren werkten.

Wie de regels schrijft

Standaarden vallen niet uit de lucht. Ze worden gemaakt — door instellingen wiens taak het is afspraken te onderhandelen die een meerderheid kunnen overtuigen.

De IETF (Internet Engineering Task Force) beheert de RFC-reeks. „RFC" staat voor Request for Comments — een bescheiden naam voor het belangrijkste documentarchief van het internet. Iedereen kan een RFC indienen. Iedereen kan meediscussiëren. Besloten wordt niet bij meerderheid, maar bij rough consensus — ruwe consensus. Dat is traag, soms frustrerend, en het is de reden waarom RFC’s zo robuust zijn.

Het IEEE (Institute of Electrical and Electronics Engineers) is verantwoordelijk voor standaarden op de fysieke laag: Ethernet, wifi (802.11), bluetooth-gebaseerde radiotechniek. Waar bits door kabels of lucht stromen, regelt meestal een IEEE-standaard hoe.

De ISO (Internationale Organisatie voor Standaardisatie) dekt alles af, van papierformaten (het bekende DIN-A4 is een ISO-norm) tot landcodes tot procesbeheer. Het W3C definieert hoe het web is opgebouwd — HTML, CSS, XML. De ECMA standardiseert programmeertalen zoals JavaScript. De ITU coördineert internationale telecommunicatie.

Deze instellingen zijn geen autoriteiten met macht. Het zijn podia waarop belangengroepen onderhandelen. Fabrikanten, onderzoekers, beheerders, overheden — iedereen brengt zijn perspectief in. De standaard die ontstaat is een compromis. En compromissen zijn nooit perfect, maar vaak goed genoeg om de wereld bijeen te houden.

De prijs van standaardisatie

Standaarden zijn moeizaam. Wie ooit een specificatie heeft gelezen, weet dat. Ze zijn droog, pedant, vol randgevallen en bijzondere condities. Dat is geen toeval — het is het gevolg van het feit dat elke denkbare situatie moet worden overdacht voordat het document klaar is.

Een standaard ontstaat niet in weken. Vaak duurt het jaren. Commissies vergaderen, concepten circuleren, commentaren worden verzameld, verwerkt, opnieuw becommentarieerd. Geschillen over details kunnen maanden binden — of een veld 16 of 32 bit breed moet zijn, of een time-out in seconden of milliseconden wordt gemeten.

Dat voelt als verspilling. In de tijd dat een standaard wordt onderhandeld, had een bedrijf drie producten op de markt kunnen gooien. En juist dat is de verleiding: snel zijn, propriëtair blijven, het terrein alleen domineren.

Maar wie eraan toegeeft, betaalt later een andere prijs.

Wanneer standaarden concurreren

Er is niet altijd de ene standaard. Vaak staan er meerdere naast elkaar, en de markt beslist — niet altijd rationeel.

Iedereen kent de grap: „Er zijn veertien concurrerende standaarden. Laten we er één ontwikkelen die ze allemaal verenigt. Nu zijn het er vijftien." Hij raakt een zenuw omdat hij waar is. REST tegen SOAP. Markdown tegen AsciiDoc. YAML tegen TOML tegen JSON. USB-C tegen Lightning tegen MagSafe. VHS tegen Betamax.

Concurrerende standaarden kosten resources. Adapters, vertalers, compatibiliteitslagen — dat alles bestaat omdat de wereld het niet over één oplossing eens kon worden. In sommige gevallen zet een standaard door omdat hij technisch beter is. In veel gevallen omdat hij tijdig, goedkoop of goed verkocht was. Soms blijft een decennialange loopgravenoorlog waarin beide kampen bestaan en niemand echt wint.

Toch: ook concurrerende standaarden zijn beter dan helemaal geen. Want waar een standaard bestaat, is interoperabiliteit mogelijk. Waar er geen bestaat, heerst het monopolie van wie de markt controleert.

Wat open standaarden onderscheidt van propriëtaire

Een propriëtair protocol werkt — zolang de leverancier bestaat, de licentie betaalt en de interesse behoudt. Verdwijnt de aanbieder, verandert de strategie of verdubbelt de prijs, dan rest een systeem dat met niets meer praat.

Een open standaard daarentegen behoort niemand en iedereen toe. Hij kan door iedereen worden geïmplementeerd. Hij overleeft bedrijven, tijdperken, technologiewisselingen. SMTP is ouder dan de meeste hedendaagse firma’s. HTTP werkt nog steeds, hoewel de wereld eromheen compleet is veranderd.

Dat heeft een nevengevolg dat zelden wordt genoemd: open standaarden verminderen afval. Apparaten die volgens open standaarden communiceren, zijn langer te gebruiken, te combineren, te repareren. Wie op propriëtaire interfaces is aangewezen, gooit hardware weg zodra de leverancier de ondersteuning stopt. Elektronisch afval is onder meer een standaardiseringsprobleem.

De lock-in-val

Hier wordt het ongemakkelijk. Want propriëtaire oplossingen zijn zelden toeval — ze zijn vaak opzettelijk.

Een leverancier die een eigen protocol ontwikkelt, handelt niet noodzakelijk uit kwaadaardigheid. Vaak begint het pragmatisch: een functie die de concurrentie mist, een integratie die alleen met het eigen product werkt, een prestatieoptimalisatie die alleen met de eigen stack geldt. Dat is legitiem.

Wat daarna gebeurt, is het probleem. Zodra een klant naar dit propriëtaire systeem is gemigreerd — zijn gegevens geïmporteerd, zijn processen afgestemd, zijn personeel getraind —, begint de omsingeling. Elke verdere integratie werkt het beste met het eigen product. Elke uitbreiding bindt dieper. Elk jaar dat verstrijkt maakt een uitstap duurder, langzamer, riskanter.

Dat is vendor lock-in: de strategische verschuiving van de onderhandelingspositie. De klant kiest één keer — en beslist nooit meer. De leverancier hoeft niet meer te overtuigen, alleen maar te behouden. Prijzen kunnen omhoog, supportniveaus samengevoegd, functies naar hogere licentieniveaus verplaatst worden. De klant kan niet weg. Hij kan alleen betalen.

Open standaarden breken deze logica. Waar een standaard geldt, kan de leverancier worden vervangen. Gegevens kunnen worden geëxporteerd, het protocol begrijpt iedereen, de integratie is na te trekken. De klant blijft soeverein — en precies die soeveriniteit is het wat propriëtaire bedrijfsmodellen vrezen.

Het is geen toeval dat de agressiefste lobbyisten tegen standaardisatie altijd afkomstig zijn van hen die het meest te verliezen hebben: de eigenaren van gesloten ecosystemen. Standaardisatie betekent concurrentie. En concurrentie betekent dat je je moet inspannen.

Begrijpen en debuggen

Wie een infrastructuur beheert, leert snel: problemen zijn onvermijdelijk. Wat telt, is of men ze kan begrijpen.

Bij een open standaard kan ik de specificatie lezen. Ik kan nagaan wat een pakket moet bevatten, hoe een antwoord eruit moet zien, waar een fout vandaan komt. Ik kan een verbinding vastleggen en zien wat er gebeurt — omdat de formaten gedocumenteerd zijn.

Bij een propriëtair protocol zie ik bytes. En ik zie een supportcontract.

Dat is geen abstract voordeel. Het is het verschil tussen een avond waarop ik een probleem oplos en een week wachten op een antwoord uit een vreemd ticketsysteem.

Wat dit met libcom.de te maken heeft

Wij bij libcom.de leunen al meer dan twee decennia op open standaarden. Niet uit principetrouw, maar uit praktijk. Systemen die op RFC’s en IEEE-standaarden zijn gebaseerd, zijn te begrijpen, te repareren en verder te ontwikkelen — ook als de oorspronkelijke leverancier allang vergeten is.

Een goed deel van ons werk bestaat eruit klanten te helpen uit propriëtaire doodlopende straten te ontkomen en te migreren naar gestandaardiseerde, interoperabele infrastructuren. Dat betekent soms dat we langzamer zijn dan een vlotte productbelofte. Maar het betekent ook dat wat we bouwen over vijf jaar nog werkt — en door iemand anders te begrijpen is.

Als u zich afvraagt of uw IT te zwaar leunt op propriëtaire oplossingen, of of standaardisatie van uw systemen zinvol zou zijn: schrijf ons op contact@libcom.de. We maken een eerlijke inventaris — zonder verkoopdruk, met de blik op wat uw infrastructuur op lange termijn nodig heeft.

Standaarden zijn niet glamoureus. Niemand vertelt zijn kinderen dat hij vandaag een compromis over een 32-bit-veld onderhandelde. Maar zonder die compromissen zou er geen internet zijn, geen web, geen e-mail, geen telefoonnetwerk dat over grenzen heen werkt.

Ze zijn het saaiste fundament dat de wereld bijeenhoudt. En misschien is het precies goed dat ze saai zijn — want saai betekent betrouwbaar. En betrouwbaar is wat infrastructuur hoort te zijn.