En la década de 1980, el mundo de los estándares formales se alineó detrás de OSI (Open Systems Interconnect), una suite de protocolos completamente especificada producida por el proceso internacional de ISO. Estaba respaldada por los monopolios telefónicos europeos y la mayoría de los gobiernos, que tenían la obligación legal de comprar equipos OSI, y era la elección racional: completa, rigurosa, estandarizada de antemano por comités. El TCP/IP de internet era el caballo oscuro: definido solo por una comunidad autogobernada de voluntarios, sin mandato, sin votación, sin posición en ningún organismo oficial.

Una contienda directa según las reglas de las instituciones de estandarización era imposible de ganar. OSI tenía los votos, la oficialidad y los mandatos de compra; TCP/IP casi ninguno. Cualquier evaluación al estilo de comité de ambos por legitimidad, representación o posición burocrática habría entregado el campo a ISO antes de que se enviara una sola implementación.

En lugar de disputar OSI en su propio terreno formal, los ingenieros de internet se negaron a votar por completo. Para 1992, la IETF había hecho explícito un principio rector que David Clark nombró en una charla de ese año: «Rechazamos reyes, presidentes y votaciones. Creemos en el consenso aproximado y el código en funcionamiento». Un estándar se resolvía no por una votación de sí/no, sino por si suficientes personas lo habían construido y ejecutado realmente: el código en el campo, no el número de delegados en la sala, era el árbitro.

La IETF se negó a votar y resolvió los estándares por consenso aproximado y código en funcionamiento: lo que ya estaba desplegado, no las votaciones, se convirtió en el árbitro.

El código en funcionamiento es observable y ya está desplegado, así que gana por adopción mientras el rival todavía se está especificando.

Cada nuevo despliegue de TCP/IP actúa como un voto, así que el criterio se acumula en una sola dirección.

La completitud de OSI lo hacía demasiado complejo de terminar, dejando poco código en funcionamiento, mientras que TCP/IP ya estaba activo en miles de redes.

Cuando dos estándares se bloquean, no voten: cuenten cuál ya funciona en el campo y dejen que eso decida.

OSI tenía demasiada complejidad y demasiado poco código en funcionamiento, mientras que TCP/IP ya estaba activo en miles de redes, así que ganó por adopción, no por votación. A mediados de la década de 1990, TCP/IP prevaleció y OSI perdió discretamente. El consenso aproximado y el código en funcionamiento no solo ganaron una batalla: se convirtieron en la norma rectora de la estandarización de internet, trasladada desde la IETF al W3C y a la mayoría de los procesos de colaboración abierta desde entonces. El mecanismo sobrevivió a los protocolos específicos que lo demostraron por primera vez.

CONSULTA LAS PRUEBAS

Las fuentes

  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