Por qué cooperación y competencia dejaron de ser conceptos opuestos.
Revisando un trabajo que escribí hace casi veinte años sobre software libre, volví a encontrarme con el dilema del prisionero. Entonces lo había utilizado para pensar la competencia entre dos modelos tecnológicos que parecían irreconciliables: el software propietario, representado inevitablemente por Microsoft, y el modelo abierto y colaborativo que crecía alrededor de Linux.
Veinte años después, aquella oposición resulta bastante menos interesante que la pregunta que había detrás.
¿Qué ocurre cuando distintos actores pueden obtener una ventaja individual cerrando su solución, pero el ecosistema completo se beneficia cuando existen reglas que les permiten cooperar?
La respuesta ya no pasa por decidir quién ganó la vieja discusión entre Gates y Linus. Pasa por entender que, en tecnología, cooperación y competencia pueden necesitarse mutuamente.
La falsa dicotomía entre abierto y cerrado
La historia no terminó con la victoria de uno de los dos modelos.
El ecosistema tecnológico actual combina infraestructura de código abierto con servicios propietarios, plataformas cerradas construidas sobre componentes abiertos, proveedores comerciales que contribuyen a proyectos comunitarios y organizaciones que consumen ambos modelos simultáneamente.
La discusión, entonces, dejó de ser simplemente si una organización debe elegir software abierto o propietario.
La pregunta más útil es otra: ¿qué capacidad conserva esa organización para integrar, modificar, reemplazar o abandonar una tecnología cuando sus necesidades cambian?
Desde esa perspectiva, la apertura deja de ser una característica ideológica del software y pasa a ser una herramienta posible dentro de un problema mucho mayor: la gobernanza tecnológica.
Cooperar para poder competir
A primera vista, cooperación y competencia parecen fuerzas opuestas. Sin embargo, buena parte de los mercados tecnológicos funcionan precisamente porque los competidores comparten alguna infraestructura común.
Protocolos, formatos, estándares, APIs e interfaces interoperables permiten que distintos productos puedan comunicarse sin necesidad de pertenecer al mismo proveedor.
Esa base compartida no elimina la competencia. Puede ser precisamente lo que permite que siga existiendo.
Cuando cambiar de proveedor exige reconstruir integraciones, migrar datos en formatos difíciles de reutilizar, reemplazar procesos completos o perder conocimiento acumulado, la decisión tecnológica inicial empieza a condicionar todas las decisiones posteriores.
El problema ya no es solamente cuánto cuesta adquirir una solución. También importa cuánto costará dejarla.
Por eso, la competencia tecnológica no se protege únicamente teniendo muchos proveedores disponibles al momento de contratar. También requiere preservar condiciones para que esos proveedores puedan volver a competir en el futuro.
El dilema del prisionero en el Estado
En la Administración Pública este problema adquiere otra dimensión.
Cada organismo puede tener incentivos perfectamente razonables para resolver sus necesidades de manera independiente: contratar una solución, desarrollar una aplicación, construir su propia base de datos o diseñar una integración específica.
Individualmente, cada decisión puede ser eficiente.
Pero cuando todos hacen lo mismo sin mecanismos de cooperación, el resultado colectivo puede ser exactamente el contrario: múltiples organismos pagando por desarrollos similares, sistemas que no pueden comunicarse entre sí, datos replicados innecesariamente, conocimiento concentrado en distintos proveedores y soluciones que deben reconstruirse cada vez que aparece una nueva necesidad.
Ahí reaparece el dilema del prisionero.
Cada actor optimiza su propia decisión, pero el sistema completo podría obtener un resultado mejor si existieran condiciones que permitieran compartir, reutilizar e interoperar.
La cooperación tecnológica, en ese contexto, no consiste necesariamente en utilizar todos el mismo sistema. Consiste en diseñar un ecosistema en el que las decisiones de un organismo no impidan las del siguiente.
Interoperabilidad como política pública
Por eso la interoperabilidad dejó de ser un problema exclusivamente técnico.
Un Estado interoperable necesita poder intercambiar información entre organismos, reutilizar desarrollos, identificar fuentes auténticas de datos y evitar que cada nueva necesidad obligue a construir nuevamente aquello que ya existe.
Esto requiere arquitectura, pero también decisiones jurídicas.
¿Quién puede reutilizar un desarrollo financiado con recursos públicos? ¿Qué derechos debe conservar el organismo sobre el software que contrata? ¿En qué formatos deben entregarse los datos? ¿Qué documentación debe exigir? ¿Cómo se garantiza una eventual migración? ¿Qué conocimiento no debería quedar exclusivamente en manos del proveedor?
Las respuestas no están solamente en el código. También están en los pliegos, contratos, licencias, políticas de datos, estándares técnicos y decisiones de arquitectura.
La interoperabilidad es, por eso, tanto una cuestión tecnológica como una cuestión de gobernanza.
El problema no es el proveedor: es la dependencia
La dependencia tecnológica suele confundirse con una discusión sobre proveedores determinados.
No es necesario.
Un proveedor puede prestar un excelente servicio y, al mismo tiempo, una organización puede haber diseñado mal su relación con esa tecnología.
El problema aparece cuando cambiar deja de ser una opción razonable.
Datos difíciles de extraer, formatos propietarios sin alternativas adecuadas, integraciones no documentadas, conocimiento crítico que nunca fue transferido, desarrollos cuya titularidad no quedó correctamente definida o costos de migración desproporcionados pueden transformar una buena decisión inicial en una dependencia futura.
Ese riesgo es particularmente relevante en el Estado, donde los sistemas pueden permanecer operativos durante décadas y atravesar distintas gestiones, presupuestos, proveedores y estrategias tecnológicas.
Gobernar esa dependencia no significa evitar proveedores ni desarrollar todo internamente. Significa conservar capacidad de decisión.
Apertura como estrategia, no como dogma
Esto también obliga a revisar una vieja simplificación: software libre contra software propietario.
El código abierto puede ofrecer ventajas importantes de reutilización, auditabilidad, adaptación e independencia. Pero abrir el código no resuelve automáticamente problemas de seguridad, mantenimiento, interoperabilidad o continuidad.
Del mismo modo, una solución propietaria no implica necesariamente una dependencia inaceptable si existen condiciones adecuadas de portabilidad, documentación, interoperabilidad, transferencia de conocimiento y salida.
Por eso, la pregunta madura no es "¿abierto o cerrado?"
Es "¿qué necesitamos conservar abierto para seguir teniendo capacidad de decidir?"
A veces será el código. Otras veces serán los datos, los formatos, las interfaces, la documentación, el conocimiento o las condiciones contractuales que permitan migrar.
La apertura deja entonces de ser un fin en sí mismo y se convierte en una estrategia de gobernanza.
Competencia, cooperación y mejora continua
Hay todavía otra consecuencia.
Cuando las soluciones pueden interoperar y el conocimiento puede reutilizarse, cada desarrollo no necesita empezar desde cero.
Una mejora realizada para resolver el problema de un organismo puede convertirse en la base para resolver el de otro. Una integración puede reutilizarse. Un estándar puede evitar desarrollos redundantes. Una solución puede evolucionar con aportes provenientes de necesidades distintas.
La cooperación genera así una infraestructura común sobre la cual todavía puede existir competencia.
Los proveedores pueden competir por implementar mejor, integrar mejor, mantener mejor, innovar o prestar mejores servicios sin que cada cambio obligue a reconstruir todo el ecosistema.
Y el Estado puede beneficiarse de esa competencia sin perder el conocimiento acumulado cada vez que cambia de proveedor.
Veinte años después
Hace veinte años era tentador representar esta discusión como una pelea entre dos nombres: Gates contra Linus, software propietario contra software libre.
Hoy esa oposición resulta demasiado pequeña.
El verdadero problema no es quién controla una determinada pieza de software, sino cuánto condiciona una decisión tecnológica las decisiones que vendrán después.
Ahí el dilema del prisionero conserva toda su utilidad.
Una organización puede obtener una ventaja inmediata optimizando exclusivamente su propia solución. Un proveedor puede obtenerla cerrando su ecosistema. Un organismo puede resolver más rápido construyendo algo que solamente atienda su necesidad particular.
Pero un ecosistema tecnológico sostenible necesita algo más: reglas que permitan cooperar sin eliminar la competencia y competir sin destruir la posibilidad de cooperación.
Veinte años después, el dilema sigue siendo el mismo.
No se trata de elegir entre competir o cooperar, sino de diseñar ecosistemas donde cooperar no impida competir y competir no obligue a empezar de cero.