Dans les années 1980, le monde des normes formelles s'est rangé derrière OSI (Open Systems Interconnect), une suite de protocoles entièrement spécifiée produite par le processus international de l'ISO. Elle était soutenue par les monopoles téléphoniques européens et la plupart des gouvernements, qui étaient légalement tenus d'acheter du matériel OSI, et c'était le choix rationnel : complet, rigoureux, normalisé à l'avance par des comités. Le TCP/IP de l'internet était l'outsider — défini seulement par une communauté autonome de volontaires, sans mandat, sans vote, sans statut dans aucun organisme officiel.

Un concours direct selon les règles des institutions de normalisation était impossible à gagner. OSI avait les voix, l'officialité et les mandats d'achat ; TCP/IP n'en avait presque aucun. Tout arbitrage de type comité entre les deux, fondé sur la légitimité, la représentation ou le statut bureaucratique, aurait livré le terrain à l'ISO avant même qu'une seule implémentation ne soit livrée.

Plutôt que de contester OSI sur son propre terrain formel, les ingénieurs de l'internet ont refusé de voter tout court. Dès 1992, l'IETF avait explicité un principe de gouvernance que David Clark a nommé dans un discours cette année-là : « Nous rejetons les rois, les présidents et le vote. Nous croyons au consensus approximatif et au code en fonctionnement. » Une norme était tranchée non par un vote oui/non, mais par la question de savoir si suffisamment de personnes l'avaient réellement construite et fait tourner — le code sur le terrain, et non le nombre de délégués dans la salle, était l'arbitre.

L'IETF a refusé de voter, tranchant les normes par consensus approximatif et code en fonctionnement : ce qui était déjà déployé, et non les votes, est devenu l'arbitre.

Le code en fonctionnement est observable et déjà déployé, il l'emporte donc par l'adoption tandis que le rival est encore en cours de spécification.

Chaque nouveau déploiement de TCP/IP fait office de vote, si bien que le critère s'accumule dans une seule direction.

La complétude d'OSI le rendait trop complexe à achever, laissant peu de code en fonctionnement, tandis que TCP/IP était actif sur des milliers de réseaux.

Quand deux normes sont bloquées, ne votez pas — comptez laquelle fonctionne déjà sur le terrain, et laissez cela décider.

OSI avait trop de complexité et trop peu de code en fonctionnement, tandis que TCP/IP était déjà actif sur des milliers de réseaux — il l'a donc emporté par l'adoption, et non par le vote. Au milieu des années 1990, TCP/IP l'a emporté et OSI a discrètement perdu. Le consensus approximatif et le code en fonctionnement n'ont pas seulement gagné une bataille — ils sont devenus la norme de gouvernance de la normalisation de l'internet, transmise de l'IETF au W3C et à la plupart des processus de collaboration ouverte depuis. Le mécanisme a survécu aux protocoles spécifiques qui l'ont prouvé pour la première fois.

VÉRIFIEZ LES SOURCES

Les sources

  1. IEEE Annals of the History of Computing — 'Rough Consensus and Running Code' and the Internet-OSI Standards War (A.L. Russell) IEEE · doi.org
  2. Computer History Museum — Networking revolution: the protocol wars Computer History Museum · computerhistory.org