Existe un mecanismo sofisticado mediante el cual los ecosistemas tecnológicos privativos mantienen su control sobre usuarios e instituciones, incluso cuando estos creen estar tomando decisiones libres, utilizando estándares abiertos y construyendo infraestructura digital independiente.
El mecanismo no actúa mediante la fuerza, sino mediante una estrategia más sutil y duradera: la superposición de dependencias, donde cada capa oculta a la que está debajo, de modo que cuando el sistema falla, la causa aparente es distinta a la real.
Se trata de un patrón estructural con componentes identificables y modos de fallo predecibles, con una única consecuencia política: la atribución sistemática de los fallos de interoperabilidad a las alternativas abiertas, y no a las dependencias privativas que realmente los causan.
Comprender todo esto es esencial para cualquiera que trabaje en una política de interoperabilidad genuina, porque sin ello, incluso las intervenciones políticas mejor intencionadas abordan el síntoma visible sin tocar el problema mayor de la arquitectura subyacente, que sigue funcionando exactamente como fue diseñada.
La percepción del mal funcionamiento
Comencemos por la experiencia del usuario, porque aquí es donde se produce el daño político.
Se crea un documento en Microsoft Word y se envía a un compañero que usa LibreOffice en Linux. El compañero abre el archivo. Algo anda mal: una tabla se ha desplazado, el texto se ha reordenado, una tipografía se ve diferente, los saltos de página se han movido.
La experiencia es familiar para millones de personas en entornos institucionales que han adoptado, o están considerando adoptar, software de código abierto. Es la experiencia que genera los tickets al servicio de ayuda, los correos electrónicos de pura frustración al departamento de TI, las conversaciones que terminan con «¿puedes enviarme solo un PDF?» y el sentimiento generalizado que, con el tiempo, consolida la idea de que el software de código abierto no está listo para uso profesional.
¿Cuál es la causa de este fallo? Los usuarios culparán a LibreOffice, los administradores de TI culparán a la incompatibilidad de formatos, los legisladores culparán a la inmadurez de los estándares abiertos.
Todas estas son respuestas incorrectas. O más bien, son todas respuestas a la pregunta equivocada, porque describen dónde se manifiesta el fallo, no dónde se origina.
La causa real es un conjunto de sistemas técnicos interdependientes, cada uno contribuyendo con un modo de fallo diferente, todos produciendo un único resultado visible.
El formato contiene estructuras privativas que solo la implementación de Microsoft maneja correctamente. El renderizado introduce variaciones dependientes de la plataforma que la especificación del formato no controla. Las tipografías privativas no pueden distribuirse legalmente con software de código abierto.
Tres modos de fallo distintos que producen el mismo síntoma, e igualmente invisibles para el usuario, quien solo percibe que las cosas funcionaban en Word y no funcionan en LibreOffice.
Esta es la arquitectura de la dependencia en capas. Cada capa absorbe la cadena causal y emite una señal diferente, una que apunta hacia la alternativa abierta.
Capa uno: el formato y sus características ocultas
La primera capa es la más discutida y la más visible políticamente: el formato de documento. El conflicto entre ODF y OOXML ha sido ampliamente documentado, litigado dentro de los organismos de estandarización y debatido en parlamentos nacionales e instituciones europeas.
Pero incluso dentro de este terreno bien cartografiado, vale la pena aclarar el mecanismo específico de ocultación en la capa del formato.
OOXML, el formato que Microsoft Office produce de manera predeterminada, existe en dos niveles de conformidad. Strict es una especificación razonablemente limpia. Transitional es algo categóricamente diferente: un formato diseñado para codificar el comportamiento acumulado de versiones anteriores de Microsoft Office, preservando décadas de elecciones de implementación privativas como elementos normativos de un estándar aparentemente abierto.
OOXML Transitional incluye VML — Vector Markup Language, un formato de dibujo privativo de finales de los 90 que precede y contradice el sistema DrawingML definido en otra parte de la misma especificación.
Incluye referencias definidas como «como en versiones anteriores de Microsoft Office», que solo tienen sentido si se tiene acceso a esas versiones anteriores y a sus detalles de implementación no documentados.
Incluye extensiones que permiten a Microsoft incrustar funcionalidad privativa en documentos, invisible para implementaciones que no sean de Microsoft, y capaz de causar diferencias silenciosas de renderizado que van desde variaciones visuales menores hasta fallos completos de diseño.
Crucialmente, OOXML Transitional es lo que Microsoft Office produce de manera predeterminada.
Cada vez que un usuario guarda un documento de Word sin seleccionar un formato diferente, produce un archivo optimizado para el ecosistema Microsoft y sutilmente hostil a cualquier otro.
Los usuarios no saben que esto está sucediendo, porque la elección se hace por ellos en el nivel del formato, y cuando el documento falla en LibreOffice, la contribución de la capa del formato a ese fallo es invisible. El usuario ve un problema de renderizado, no un problema de formato.
Esta es la primera capa de ocultación: construcciones de formato privativo enmascaradas bajo la etiqueta de «estándar industrial», que producen errores que parecen deficiencias de implementación en el software receptor.
Capa dos: el renderizado y su comportamiento no especificado
La segunda capa es menos discutida, menos visible políticamente, y por estas mismas razones más duradera como fuente de fallos de interoperabilidad: el renderizado de texto.
Los estándares de formato de documento especifican contenido. Definen lo que contiene un documento: texto, estructura, relaciones lógicas, objetos incrustados e instrucciones de formato.
Lo que no especifican, y que ninguno de los principales estándares de formato de documento ha especificado jamás, es cómo debería renderizarse ese contenido. La traducción del contenido codificado en glifos visibles en una pantalla o una página se deja a la implementación, y diferentes implementaciones toman diferentes decisiones.
Estas decisiones operan en varios subsistemas.
Los motores de shaping -los componentes de software que traducen secuencias de caracteres Unicode en secuencias de glifos y manejan las reglas complejas de escrituras como el árabe, el devanagari y el tailandés- difieren según la plataforma.
HarfBuzz, el motor de shaping de código abierto utilizado por LibreOffice y la mayoría de las aplicaciones Linux, produce una salida correcta y conforme a los estándares, pero esa salida puede diferir en detalle de los motores Uniscribe o DirectWrite de Windows, particularmente para escrituras complejas con selección de glifos sensible al contexto.
Las diferencias son casi siempre invisibles para el texto latino, pero para las escrituras no latinas utilizadas por una parte significativa del sector público y la ciudadanía europeos, pueden ser significativas.
La interpretación de las pistas (hinting) varía entre los motores de renderizado. Las tipografías incorporan instrucciones de hinting -algoritmos que ajustan los contornos de los glifos para una visualización nítida en bajas resoluciones de pantalla- pero esas instrucciones son interpretadas de manera diferente por distintos renderizadores.
Una tipografía optimizada para el motor de renderizado GDI de Windows puede mostrarse con diferente peso y espaciado bajo FreeType en Linux, incluso en tamaños idénticos.
Las diferencias son mínimas para cualquier carácter individual, pero afectan la calidad percibida del texto y contribuyen a la impresión general de que los entornos de código abierto son ligeramente menos pulidos.
Los algoritmos de salto de línea y justificación son la fuente más significativa de variación en el renderizado y la causa más directa del reflujo de documentos.
El algoritmo que determina dónde dividir las líneas -cómo distribuir las palabras en una línea de un ancho determinado, si aplicar o no guiones y cómo hacerlo, cómo manejar el texto justificado- es una elección de implementación que ninguna especificación de formato regula.
El algoritmo de salto de línea de Microsoft Word es privativo y no está documentado, y es muy diferente al de LibreOffice. Ambas son implementaciones legítimas de la misma función, y pueden producir diferentes saltos de línea; diferentes saltos de línea significan diferentes saltos de página; y diferentes saltos de página significan que un documento paginado en Word no se paginará de la misma manera en LibreOffice.
Esto no es un defecto en la calidad de la implementación, sino la consecuencia normal y predecible de diferentes elecciones de renderizado que los estándares de formato de documento no definen. Y produce errores que invariablemente se atribuyen al software que recibe el documento, porque ahí es donde aparece la diferencia visible, en lugar de atribuirse a las especificaciones que son su causa.
La capa de renderizado es el componente técnicamente más complejo de la dependencia en capas y el más difícil de abordar, pero también es la capa que revela más claramente las dimensiones del problema: un error generado por una elección diferente tomada por dos proyectos, atribuido únicamente al software de código abierto, basándose en una confianza completamente injustificada, casi basada en la fe, en la calidad del software privativo.
Tercera capa: las tipografías y la dependencia de recursos privativos
La tercera capa completa el panorama y, en muchos entornos prácticos, causa el mayor daño: las tipografías. Aquí no analizaremos el bloqueo a nivel tipográfico en sí mismo, sino que explicaremos cómo opera la capa tipográfica dentro del modelo de dependencia estratificada.
Las tipografías interactúan con ambas capas superiores. A nivel de formato, las tipografías aparecen como referencias con nombre: un documento declara que el texto del cuerpo está compuesto en Calibri y los títulos en Cambria. Si esas dos tipografías no están disponibles en el sistema receptor -y este es el caso en todos los sistemas para los que no se ha adquirido una licencia de las tipografías privativas-, el software debe sustituirlas.
La sustitución cambia las métricas, y las métricas, a su vez, cambian la geometría. La geometría alterada produce reflujo, diseños rotos, formularios que desbordan sus márgenes; y también aquí el fallo se atribuye a la aplicación que recibe el documento.
A nivel de renderizado, las tipografías interactúan con el motor de conformación, el sistema de insinuación y la canalización de suavizado de formas específicas para cada diseño tipográfico y sus instrucciones incrustadas. Una tipografía optimizada para la pila de renderizado de Windows se mostrará de manera diferente bajo FreeType, incluso antes de que ocurra cualquier sustitución, y esto contribuye a la divergencia visual general entre entornos.
Lo que hace que la capa tipográfica sea particularmente efectiva como mecanismo de bloqueo es la combinación de la indisponibilidad legal y la falta de información del usuario. Las tipografías privativas en el centro del problema -Calibri y Cambria, y antes Arial y Times- no están disponibles bajo ningún tipo de licencia de código abierto.
Esta es una restricción legal que el software de código abierto no puede superar, pero que los usuarios perciben no como un problema de licencias, sino como un problema de software -no como la consecuencia de una estrategia, sino como una prueba de que el software de código abierto no puede manejar documentos ordinarios.
Solo Aptos, la más reciente de las tipografías privativas de Microsoft, se publica bajo una licencia parcialmente restrictiva, ya que vincula su uso a una descarga del sitio de Microsoft. Por lo tanto, también puede ser instalada legalmente por usuarios de Linux, pero esto no ha tenido suficiente difusión, por lo que el mecanismo de bloqueo solo se reduce, no se elimina.
Por qué «invisible» es la palabra clave
Cada una de las tres capas sería un problema manejable si fuera visible, y si los usuarios tuvieran la oportunidad de ver claramente que el error se origina en el formato privativo, o en las especificaciones de renderizado insuficientes, o en la tipografía privativa. Los problemas visibles pueden abordarse y resolverse basándose en un diagnóstico preciso y una intervención específica.
La fortaleza de este esquema reside en su oscuridad. Cada capa actúa como un recodificador de señales: toma la salida de la capa inferior y la reemite como algo que parece un tipo diferente de problema.
Así, la dependencia de tipografías privativas produce un error que parece un problema de renderizado del software; el problema de renderizado produce un error que parece una deficiencia de implementación; y, finalmente, la estructura de formato privativo produce un error que parece un incumplimiento de los estándares.
Cuando el error llega al usuario, su origen está completamente oculto, y la responsabilidad se redirige sistemáticamente al último elemento de la cadena: el software de código abierto, que simplemente intentaba mostrar un documento diseñado para derrotarlo.
Esto no es una coincidencia derivada de un diseño deficiente.
Un software que generara errores aleatorios sería un problema para la empresa que lo desarrolló, porque la frustración del usuario fluiría de vuelta hacia el software originante.
Un sistema que genera errores en el límite con los competidores, de manera que siempre se atribuyen a esos competidores, es un activo competitivo.
Aquí, la cuestión de la intención importa menos que la cuestión de la estructura: cualquiera que sea la motivación detrás de las decisiones de diseño originales, la arquitectura resultante funciona como una restricción, y sus efectos son observables y medibles.
Cómo respondió la política y dónde fracasó
La respuesta política al bloqueo documental se ha concentrado en el formato: exigir el uso de ODF y formatos abiertos en la contratación pública, y garantizar que los documentos gubernamentales puedan crearse y consultarse sin el uso de software privativo. Desafortunadamente, estas intervenciones casi nunca han ido acompañadas de sanciones para hacer cumplir la normativa, y las reglas a menudo se han ignorado.
Además, estos mandatos de formato no han abordado el uso de tipografías privativas en las plantillas de documentos, por lo que al arreglar solo la capa superior, dejan la inferior expuesta y completamente operativa, donde es menos visible y menos relevante políticamente y, por lo tanto, más duradera.
Los documentos siguen fallando en el límite con el software de código abierto, y los usuarios siguen culpando a este último. La voluntad política detrás del mandato de formato se erosiona progresivamente por las quejas de los usuarios sobre problemas de interoperabilidad, que parecen contradecir la promesa del mandato de formato abierto y estándar en sí mismo.
Una institución que implementa LibreOffice pero no aborda la consistencia del renderizado -permitiendo que una infraestructura mixta de sistemas Windows y Linux intercambie documentos sin reconocer que la variación en el renderizado no es un defecto del software- corre el riesgo de crear un problema de interoperabilidad interna que podría utilizarse para justificar un retorno al monocultivo.
La capa de renderizado no ha recibido casi ninguna atención política. Ningún marco importante de soberanía digital especifica requisitos de fidelidad de renderizado. Ningún estándar de contratación define la conformidad en términos de consistencia visual entre implementaciones.
Las herramientas para abordar este problema -implementaciones de renderizado de referencia, conjuntos de pruebas de renderizado, puntos de referencia de fidelidad- existen solo como prototipos o propuestas, y no se han integrado en ningún marco político serio.
Conocer este patrón es un acto político
La estratificación invisible de dependencias es un patrón nacido de casi cincuenta años de evolución no regulada del software de productividad personal, y uno que amenaza con hacer que el camino hacia la soberanía digital sea extraordinariamente complejo.
Importa darle un nombre al patrón, para que pueda ser utilizado en discusiones políticas, en preguntas parlamentarias, en especificaciones de contratación y en el debate público sobre la soberanía digital, en todos los niveles, incluso por los medios de comunicación.
La estratificación invisible de dependencias conecta fenómenos que no parecen estar relacionados -incompatibilidades de formato de documentos, variación en el renderizado, fallos de sustitución de tipografías- y muestra que son expresiones de la misma arquitectura subyacente.
Una vez que estos fenómenos se ven como un patrón, en lugar de como problemas técnicos aislados, una respuesta política apropiada se vuelve más clara, porque no es suficiente arreglar una sola capa y exigir un solo estándar – aunque ese sea un primer paso fundamental.
Es necesario hacer legibles todas las dependencias e integrarlas en políticas de interoperabilidad que aborden el formato, el renderizado y las tipografías de manera explícita y específica, con mecanismos de cumplimiento que se apliquen a las tres capas.
La comunidad del código abierto y los estándares abiertos ha construido las bases técnicas para una interoperabilidad genuina: los formatos abiertos son maduros y sólidos, las aplicaciones de código abierto están completamente a la altura de la tarea, y hay cientos de tipografías con licencias abiertas, muchas de ellas compatibles en métricas con las privativas.
La arquitectura del bloqueo no persiste porque las alternativas sean inadecuadas. Persiste porque la política aún no ha aprendido a mirar más allá de la superficie visible del cumplimiento del formato y a reconocer las capas subyacentes donde las dependencias privativas siguen operando -invisibles e ignoradas- haciendo el trabajo para el que fueron diseñadas.
Artículo original (en inglés)
