Los estándares son documentos técnicos redactados por ingenieros y discutidos en comités antes de implementarse en código. Sin embargo, analizarlos únicamente en términos técnicos sería pasar por alto un aspecto esencial de su naturaleza y función.
De hecho, los estándares son también -y sobre todo- herramientas políticas, ya que definen a los actores del mercado, determinan la dirección del desarrollo y establecen los intereses a los que sirve el ecosistema. En otras palabras, sustentan las relaciones de poder del mercado.
Qué hace un estándar
Un estándar es un mecanismo de coordinación que permite a múltiples partes independientes -como desarrolladores de software, fabricantes de hardware, creadores de contenido, gobiernos y empresas- colaborar sin tener que negociar cada vez los términos de su interacción.
Al igual que un idioma, un estándar permite la comunicación con todos quienes lo hablan. Es una promesa inmensamente valiosa de comunicación universal, razón por la cual los estándares son tan importantes en la informática, donde los efectos de red de la compatibilidad se multiplican rápidamente.
Sin embargo, un estándar también define las condiciones de participación.
Un estándar sencillo y transparente, basado en conocimiento ampliamente disponible, puede ser implementado por múltiples partes sin generar desigualdad.
Por el contrario, un estándar complejo y deliberadamente oscuro que requiera conocimientos especializados solo puede ser implementado correctamente por quienes lo definieron, lo que genera desigualdad.
Por lo tanto, la complejidad de un estándar actúa como una barrera, determinando quién puede acceder al mercado y el equilibrio de poder dentro de él.
Ecosistemas abiertos
Un ecosistema abierto no depende de un documento que contenga las especificaciones del estándar, sino más bien de la capacidad de cualquier parte interesada para implementar el estándar de manera completa y correcta de acuerdo con las especificaciones, sin recurrir a comportamientos no documentados ni a ingeniería inversa.
Esto requiere que las especificaciones estén redactadas con claridad, de manera que solo permitan una interpretación, y que el estándar no dependa de comportamientos definidos por la implementación de referencia, lo cual convertiría a esta última en una dependencia obligatoria. También requiere que el estándar sea lo suficientemente estable como para evitar que las implementaciones conformes queden obsoletas debido a revisiones silenciosas.
Cuando se cumplen todas estas condiciones, cualquiera puede implementar el estándar, incluso quienes no participaron en su creación. Las universidades, las pequeñas empresas, las comunidades de código abierto, las agencias gubernamentales y los desarrolladores individuales pueden producir software que cumpla con el estándar.
La competencia es posible en función de la calidad de la implementación, en lugar de la proximidad a los autores del estándar o la ingeniería inversa. El estándar proporciona una base sobre la cual cualquiera puede construir.
Ecosistemas cerrados
Si bien el cierre de un ecosistema a través de un estándar puede ser accidental, por lo general es intencional y se basa en una serie de mecanismos bastante fáciles de enumerar.
El primer mecanismo es la complejidad innecesaria. Cuando un estándar define sus propias soluciones a problemas que ya cuentan con soluciones válidas y ampliamente implementadas, obliga a otros participantes a reinventar la rueda. Cada subsistema privativo es un nuevo elemento que aumenta los costos y, a menudo, limita artificialmente la compatibilidad.
El segundo mecanismo es la subdeterminación. Cuando las especificaciones son ambiguas o limitadas, las diferentes implementaciones producen resultados distintos. Cuando un documento se muestra de manera ligeramente diferente, los usuarios siempre culpan a la segunda aplicación en lugar de al formato. Esta es una forma extremadamente insidiosa de dependencia.
El tercer mecanismo es la extensibilidad. Si las especificaciones permiten la incorporación de extensiones privativas, el documento cumple técnicamente con el estándar, pero solo un programa puede mostrarlo correctamente. En este caso, el estándar simplemente ampara un sistema privativo.
Además de estos tres mecanismos, existe una influencia directa o indirecta sobre los organismos de estandarización. La influencia directa ocurre cuando el proveedor puede influir en el proceso de estandarización mismo, moldeando los requisitos de cumplimiento para que se ajusten al comportamiento de su propia aplicación. La influencia indirecta ocurre cuando el proveedor puede influir en otros miembros a través de factores externos al proceso de estandarización.
Lo que está en juego más allá del software
Las consecuencias de los estándares abiertos y cerrados afectan a más que solo a los desarrolladores de software.
Por ejemplo, un gobierno que archiva sus documentos en un formato que solo puede manejarse correctamente con un software específico queda, en la práctica, dependiente del proveedor que lo desarrolló. Esto significa que la preservación a largo plazo de los documentos públicos está sujeta a las decisiones comerciales de una empresa privada.
Las instituciones culturales, como las bibliotecas, los archivos y los museos, enfrentan el mismo problema a escalas de tiempo más largas. Es más probable que un formato abierto y estandarizado siga siendo legible con el paso del tiempo que un formato privativo, cuyo soporte continuo depende de las prioridades estratégicas de un solo proveedor.
Para las economías en desarrollo y las organizaciones de interés público con recursos limitados, los estándares abiertos proporcionan una infraestructura vital que garantiza la igualdad de acceso.
Interpretar lo técnico como político
Al evaluar una norma, los detalles técnicos se vuelven políticos.
Usar #RRGGBB para los colores en lugar de un sistema privativo no es una elección estética; afecta quién puede implementar el formato y quién se beneficia del ecosistema que este crea.
Adoptar el estándar ISO 8601 para las fechas en lugar de un sistema de numeración heredado de un único software privativo basado en un error de hace cincuenta años es elegir la interoperabilidad por encima de la continuidad con un pasado privativo.
Estas decisiones se suman.
Un estándar que se alinea sistemáticamente con prácticas abiertas y establecidas, en lugar de una reinvención privativa basada en múltiples decisiones de este tipo, es fundamentalmente diferente de un formato privativo que constantemente hace lo contrario, aunque ambos produzcan documentos que parezcan idénticos en pantalla y ambos lleven la etiqueta de «estándar abierto». Esta etiqueta significa muy poco.
Lo que importa es si los desarrolladores independientes pueden crear software que cumpla plenamente con el estándar y si el ecosistema es genuinamente accesible para todos los que deseen participar. En última instancia, el estándar debe servir a los intereses de los usuarios y no a los de la empresa que lo definió.
Estas son cuestiones políticas que merecen ser discutidas como tales.
Artículo original (en inglés)
Ilustración: Sebastián Acosta Nieto (Colombia)
