El código abierto está ganando un espacio más estratégico en la transformación digital de las Administraciones Públicas europeas. El Open Source Observatory (OSOR), dentro del ecosistema de Interoperable Europe, ha convocado para el 24 de septiembre de 2026 una sesión específica para analizar las implicaciones de la estrategia europea de código abierto para el sector público.
La agenda sitúa el open source en torno a cuatro ideas: transparencia, interoperabilidad, reutilización y mayor control sobre la infraestructura digital. El enfoque es relevante porque durante años muchas administraciones han utilizado software abierto de forma puntual, pero el debate actual va más allá de elegir una licencia: se trata de cómo colaborar, mantener soluciones y reducir dependencias tecnológicas sin comprometer seguridad ni continuidad.
Del software gratuito a la infraestructura estratégica
Uno de los errores más habituales es identificar código abierto con software gratuito. Una solución puede no tener coste de licencia y, sin embargo, requerir inversión en implantación, soporte, seguridad, formación y mantenimiento. El valor estratégico está en el acceso al código, la capacidad de modificarlo y la posibilidad de reutilizarlo bajo sus condiciones de licencia.
Para una Administración, esto puede mejorar su capacidad de negociar y evitar que una función crítica dependa exclusivamente de un proveedor. Pero esa ventaja solo existe si la organización conserva documentación, conocimiento y derechos suficientes para operar o cambiar de mantenedor.
Reutilización entre administraciones
Muchas entidades públicas resuelven problemas muy parecidos: sedes, portales, gestión de citas, formularios, intercambio de datos, autenticación o visualización territorial. Cuando cada organismo contrata una solución desde cero se multiplican costes.
El código abierto permite que un desarrollo financiado por una Administración pueda convertirse en base para otras, siempre que exista un modelo de mantenimiento. Reutilizar no significa copiar sin control. Es necesario gestionar versiones, seguridad, documentación y contribuciones.
Los proyectos más sostenibles suelen disponer de una comunidad o de una organización responsable que coordina el producto.
Interoperabilidad y estándares abiertos
La estrategia europea relaciona código abierto con interoperabilidad. El objetivo no es que todo el sector público utilice la misma aplicación, sino que los sistemas puedan comunicarse y reutilizar componentes.
Las APIs documentadas, formatos abiertos y modelos semánticos compartidos son tan importantes como la licencia del software. Un producto de código abierto puede seguir siendo difícil de integrar si utiliza formatos poco documentados.
Por eso los pliegos deben evaluar arquitectura y portabilidad de datos además de pedir una determinada modalidad de licencia.
Soberanía digital y capacidad de elección
La soberanía digital se suele interpretar como la capacidad de mantener control sobre tecnologías y datos críticos. El open source puede contribuir al permitir inspección y sustitución de proveedores, pero no elimina todas las dependencias.
Una aplicación abierta desplegada sobre servicios propietarios puede seguir generando lock-in. Del mismo modo, una Administración sin personal o proveedores alternativos puede depender de un único mantenedor aunque disponga del código.
La soberanía debe evaluarse de extremo a extremo: aplicación, infraestructura, datos, identidad, APIs, documentación y conocimiento.
Seguridad: transparencia no equivale a ausencia de riesgo
El código abierto permite que más personas revisen el software, pero eso no garantiza que alguien lo haga. Una solución abandonada puede acumular vulnerabilidades igual que cualquier producto propietario.
Las administraciones deben comprobar actividad del proyecto, frecuencia de actualizaciones, gestión de vulnerabilidades, dependencias y proceso de respuesta a incidentes. También necesitan un inventario de componentes para reaccionar cuando aparece un problema en una librería utilizada.
En sistemas críticos conviene definir acuerdos de soporte aunque el código esté disponible públicamente.
Cómo cambia la contratación pública
Un pliego orientado a código abierto debe ir más allá de exigir que se entregue un repositorio. Tiene que establecer qué licencia se utilizará, qué documentación se entregará, cómo se gestionarán dependencias y qué derechos tiene la Administración para reutilizar y contratar a terceros.
También conviene exigir procesos de integración continua, pruebas, inventario de componentes y documentación de despliegue. El objetivo es evitar una situación donde el código esté disponible pero resulte impracticable mantenerlo sin el adjudicatario original.
La reversibilidad debe probarse. Una entrega final de archivos sin conocimiento operativo no es suficiente.
Modelos de sostenibilidad
Una de las cuestiones centrales del evento europeo es cómo escalar el código abierto mediante cooperación, financiación y colaboración público-privada. Mantener un producto utilizado por muchas administraciones requiere recursos permanentes.
Existen modelos donde una Administración lidera, consorcios que financian conjuntamente o comunidades donde empresas prestan soporte sobre una base común. Cada opción tiene ventajas y riesgos.
La gobernanza debe definir quién decide la hoja de ruta, cómo se aceptan cambios y cómo se priorizan correcciones de seguridad.
Qué proyectos deberían abrirse
No todo desarrollo público tiene que publicarse automáticamente. Puede haber restricciones de seguridad, derechos de terceros o componentes que no sean reutilizables. La decisión debe analizarse caso por caso.
Sin embargo, cuando una solución resuelve una necesidad común y ha sido financiada con recursos públicos, evaluar su reutilización puede generar valor. Especialmente en componentes no diferenciadores: formularios, conectores, librerías, vocabularios o herramientas de gestión.
El papel de las comunidades locales
Ayuntamientos y regiones pueden beneficiarse especialmente de soluciones reutilizables. Un municipio pequeño difícilmente puede mantener un desarrollo complejo, pero puede participar en un ecosistema donde varias entidades comparten costes.
Para que ese modelo funcione, la solución debe ser configurable y evitar personalizaciones que fragmenten el producto en decenas de versiones incompatibles.
Checklist para una estrategia open source pública
- Identificar dependencias críticas actuales.
- Evaluar dónde la reutilización puede reducir duplicidades.
- Definir licencias y derechos desde el inicio del contrato.
- Exigir documentación de despliegue y mantenimiento.
- Inventariar componentes y dependencias.
- Establecer un proceso de seguridad y actualizaciones.
- Planificar financiación del mantenimiento.
- Definir gobernanza y hoja de ruta.
- Probar la reversibilidad con proveedores alternativos.
- Publicar únicamente cuando el análisis jurídico y de seguridad lo permita.
Preguntas frecuentes
¿Cuándo se celebra el evento de OSOR?
Está previsto para el 24 de septiembre de 2026 y se celebrará en formato online.
¿Qué temas aborda?
Objetivos de la estrategia europea, aplicación práctica en Administraciones, cooperación, financiación y colaboración con el ecosistema open source.
¿Código abierto significa coste cero?
No. Reduce o cambia determinados costes de licencia, pero sigue requiriendo implantación, mantenimiento, soporte, seguridad y personal.
¿Puede reducir el lock-in?
Puede ayudar, especialmente cuando se combina con estándares abiertos, documentación, portabilidad de datos y proveedores alternativos.
Fuente oficial
La información se basa en la convocatoria del Open Source Observatory de Interoperable Europe.
En Digitalización Pública News seguiremos esta estrategia y los proyectos de software reutilizable que puedan cambiar la arquitectura digital de las Administraciones.
Cómo evitar que un proyecto abierto termine dependiendo de un solo proveedor
Disponer del código fuente es solo el primer paso. La Administración necesita documentación de arquitectura, instrucciones de despliegue, pruebas automatizadas y un inventario de dependencias. Sin esos elementos, un tercero puede tardar tanto en comprender el sistema que el proveedor inicial conserve de facto una posición exclusiva.
Una buena práctica es exigir que el proyecto pueda ser compilado y desplegado desde un repositorio documentado. También conviene utilizar estándares conocidos y evitar componentes propietarios innecesarios en la cadena de desarrollo.
La importancia de las comunidades de mantenimiento
El software público reutilizable necesita una comunidad o una estructura de gobernanza. Cuando varias entidades comparten el producto, deben decidir cómo se priorizan funcionalidades y quién financia mantenimiento. Sin coordinación, cada Administración puede crear su propia bifurcación y perderse la ventaja de trabajar sobre una base común.
Los modelos federados permiten que distintas organizaciones contribuyan sin perder una hoja de ruta compartida. Empresas privadas también pueden ofrecer implantación y soporte sobre el mismo código, generando competencia alrededor del servicio y no del acceso exclusivo al producto.
Open source y seguridad de la cadena de suministro
La apertura no elimina el riesgo de dependencias vulnerables. Un proyecto puede incorporar cientos de librerías de terceros. Por eso las Administraciones deberían exigir inventario de componentes, actualización continua y un proceso para reaccionar ante vulnerabilidades críticas.
Las herramientas de análisis de dependencias y los SBOM pueden mejorar la visibilidad. Lo esencial es saber qué componentes se utilizan y quién responde cuando necesitan actualizarse.
Reutilización frente a personalización extrema
Un producto compartido pierde valor si cada organismo exige modificaciones incompatibles. Conviene separar un núcleo común de configuraciones locales. La parametrización permite adaptar formularios, imagen o flujos sin mantener versiones de código diferentes.
Antes de pedir una personalización, la entidad debería valorar si el requisito responde a una necesidad legal o a una costumbre interna que podría simplificarse.
Contratos de mantenimiento competitivos
Cuando la documentación y el código son accesibles, varias empresas pueden competir por soporte. Para que esto sea real, los pliegos deben evitar requisitos diseñados alrededor del proveedor anterior y centrarse en capacidades verificables.
La Administración también puede dividir desarrollo y auditoría o establecer mecanismos de revisión independiente en sistemas críticos.
Medir el valor del código abierto
No basta con contar repositorios publicados. Los indicadores útiles incluyen reutilizaciones reales, número de entidades usuarias, proveedores capaces de mantener la solución, frecuencia de actualizaciones y tiempo de resolución de vulnerabilidades.
Un proyecto pequeño pero utilizado por muchas entidades puede generar más valor público que un gran repositorio sin comunidad.
Lecturas relacionadas
La reutilización tecnológica se relaciona con la IA interoperable en el sector público, los pilotos europeos de GenAI, el gobierno del dato y la evolución de LEOS y EdiT.
Qué debería incluir un repositorio público mantenible
Un repositorio reutilizable necesita mucho más que el código. Debe incluir instrucciones de instalación, requisitos de infraestructura, configuración, modelo de datos, pruebas y política de contribución. También conviene describir cómo reportar vulnerabilidades y qué versiones reciben soporte.
La automatización del despliegue reduce dependencia de conocimiento informal. Si el sistema solo puede instalarlo quien lo desarrolló originalmente, la apertura jurídica del código tiene un valor práctico limitado.
Estándares abiertos y datos portables
El open source aporta capacidad de inspección, pero la portabilidad depende también de los datos. Una Administración puede disponer del código de una aplicación y seguir atrapada si no puede extraer información completa con relaciones y metadatos.
Los pliegos deberían exigir exportaciones documentadas y, cuando sea posible, formatos estándar. Las APIs deben cubrir operaciones relevantes y no limitarse a funciones superficiales.
Cómo evaluar si merece la pena reutilizar
No todo proyecto abierto es adecuado para otra entidad. Antes de adoptar conviene revisar actividad reciente, comunidad, arquitectura, dependencias, licencia y grado de personalización necesario. A veces adaptar una solución madura resulta eficiente; en otros casos el coste de transformación supera el de una alternativa distinta.
Una prueba técnica corta puede ayudar a validar compatibilidad con identidades, infraestructura y sistemas existentes antes de tomar una decisión.
Evitar la fragmentación de versiones
Cuando cada organismo modifica el núcleo por su cuenta, el mantenimiento se complica. Es preferible contribuir mejoras al proyecto común y reservar extensiones locales para módulos claramente separados.
Esta disciplina permite que correcciones de seguridad y nuevas versiones puedan adoptarse sin rehacer todas las personalizaciones.
Open source y contratación de soporte
Una arquitectura abierta puede ampliar el número de proveedores capaces de competir por mantenimiento. Para que ocurra, los requisitos deben permitir que empresas distintas accedan a documentación y entornos de prueba en condiciones razonables.
El objetivo no es prescindir de proveedores, sino evitar que la Administración dependa de uno por falta de acceso al conocimiento técnico.
Una estrategia abierta necesita capacidad interna
La apertura tecnológica funciona mejor cuando la Administración conserva conocimiento suficiente para tomar decisiones sobre arquitectura, seguridad y evolución. Externalizar mantenimiento puede ser razonable, pero la entidad necesita personal capaz de entender el sistema, validar propuestas y supervisar cambios.
Esta capacidad interna también mejora la contratación. Un equipo que conoce el producto puede redactar requisitos más precisos, evaluar ofertas con criterios técnicos y distinguir entre una mejora real y una personalización que aumenta dependencia. El objetivo no es desarrollar todo internamente, sino conservar capacidad de gobierno.
Próximo paso para las Administraciones interesadas
Las entidades que quieran avanzar pueden empezar identificando soluciones ya existentes en su organización, revisando licencias, dependencia de proveedor y facilidad de exportación. A partir de ese mapa resulta más sencillo decidir dónde el código abierto puede aportar reutilización y dónde conviene mantener otras alternativas. El criterio principal debería ser siempre sostenibilidad, seguridad e interoperabilidad a largo plazo.
Fotografía: Digital Buggu / Pexels.