Desde hace años, una respuesta frecuente de las Administraciones Públicas a la excesiva dependencia de uno o varios proveedores (el famoso vendor lock-in) ha sido solicitar que el código del software que adquieren sea abierto (Open Source). Parece lógico: si el código es abierto, la dependencia disminuye. 

Sin embargo, adoptar este modelo no garantiza autonomía tecnológica ni reduce automáticamente el esfuerzo interno de mantenimiento. Por eso, más que obsesionarse con el Open Source, la mejor estrategia es identificar las áreas de dependencia y seleccionar las herramientas más adecuadas para cada caso.

El origen del movimiento Open Source

El Open Source nació como una reacción ideológica a modelos de software cerrados y concentrados en grandes proveedores. Con el tiempo pasó de ser una alternativa a convertirse en infraestructura estándar del mundo digital (Linux, Kubernetes, PostgreSQL, etc.).

Ese cambio cultural y tecnológico llegó también — aunque algo más tarde — a la Administración Pública, que durante décadas había priorizado soluciones propietarias por motivos muy pragmáticos: seguridad, soporte contractual, responsabilidad jurídica y estabilidad. El efecto no deseado fue una dependencia creciente de unos pocos proveedores para cualquier mejora o adaptación, dejando a muchas organizaciones públicas “enjauladas” en relaciones contractuales difíciles de sustituir (vendor lock-in).

En respuesta, en los últimos años varias normas estatales o incluso municipales han intentado revertir esta situación. Por ejemplo, en octubre de 2017, Barcelona aprobó una política explícita de uso y desarrollo de software libre y de código abierto en la Mesura de govern per a la digitalització oberta. El ayuntamiento promovió como objetivo la compra preferente de soluciones Open Source y de sistemas basados en arquitecturas y estándares abiertos. También, y esto es importante, la medida proponía dotar al Ayuntamiento de perfiles y capacidades internas para recuperar conocimiento y gobernar los servicios digitales. 

Lo interesante de estas normativas es que no solo se centran en el Open Source, sino que hacen igual énfasis en otras dimensiones clave como la inversión en capacidades internas o las arquitecturas basadas en estándares abiertos. Sin embargo, muchas veces, a la hora de implementar se pone casi toda la atención en que el código sea Open Source. 

Y aquí viene el problema.

Centrarnos demasiado en que el software sea Open Source puede cegarnos ante una realidad clave: el hecho de que el código esté disponible no implica que el sistema esté bien diseñado para integrarse. Siguen existiendo fuentes de dependencia, incluso con código abierto.

Otras fuentes de dependencia y cómo atajarlas

Muchas veces, la clave para evaluar si una tecnología genera dependencia no es si el código es abierto o cerrado, sino si el sistema es interoperable, auditable y portable.

• Interoperable significa que los sistemas pueden comunicarse de forma estructurada y estandarizada.
• Auditable significa que el comportamiento del sistema puede ser evaluado y supervisado.
• Portable significa que la Administración puede cambiar de proveedor sin rehacer toda su infraestructura.

En muchos casos, la clave está menos en la licencia y más en la arquitectura. Sin una arquitectura API-first, estándares de datos comunes y una gobernanza tecnológica acompañada de capacidades internas, abrir el código aporta poco.

Existen ejemplos claros de esta diferencia. Múnich migró a Linux con el proyecto LiMux para reducir dependencia, pero años después se revirtió la decisión y tuvieron que volver a Windows. El problema no fue el código abierto en sí, sino la falta de capacidad interna suficiente y las dificultades de interoperabilidad con otros sistemas. La licencia no garantizó autonomía.

En sentido contrario, Estonia construyó su gobierno digital sobre X-Road, un protocolo interoperable de intercambio de datos. No todo es código abierto, pero la arquitectura garantiza portabilidad y control sobre los datos. Algo similar ocurre con el estándar GTFS en movilidad urbana: permite cambiar de proveedor sin rehacer los datos. La clave no es la licencia del software, sino el control del estándar.

Esto es lo que una Administración tiene que exigir de cualquier solución tecnológica: estándares abiertos, APIs bien definidas y capacidad real de integración.

Además, hay un riesgo adicional: adoptar software Open Source sin capacidad interna para mantenerlo. Si la Administración no dispone de equipos técnicos capaces de auditar, adaptar y evolucionar ese software, el proveedor externo seguirá siendo imprescindible. La dependencia cambia de forma, pero no desaparece.

Preguntas clave antes de contratar tecnología

A la hora de plantear la integración de un software en la Administración, la pregunta “¿es Open Source?” es relevante, pero primero debemos preguntarnos:

1. ¿Está construido sobre estándares abiertos?
2. ¿Permite sustituir al proveedor sin rehacer el sistema?
3. ¿Facilita el intercambio de datos con otros sistemas internos o con otras administraciones?
4. ¿Existe una estrategia real de mantenimiento y evolución a medio y largo plazo?

El Open Source es un modelo excelente, pero no debe ser un fin en sí mismo. El objetivo final es una Administración que sea dueña de sus procesos y de sus datos, capaz de cambiar de socio tecnológico sin que el servicio al ciudadano se vea comprometido. Debemos centrarnos en construir arquitecturas modulares basadas en estándares abiertos y en reforzar las capacidades de los equipos públicos. Ahí está la verdadera autonomía.

‍