Polonia ha incorporado por primera vez un capítulo específico sobre software de código abierto a su estrategia nacional de digitalización.
Qué está confirmado
La estrategia fue adoptada en junio de 2026 e incluye la creación de un OSPO nacional, una plataforma de repositorios y medidas para impulsar el uso de soluciones abiertas en las administraciones locales.
Por qué importa
El cambio convierte el open source en una cuestión de política pública y no solo en una elección técnica. Esto afecta a contratación, mantenimiento, reutilización y soberanía tecnológica.
Contratación pública
Los pliegos pueden incorporar requisitos sobre acceso al código, licencias, documentación, formatos abiertos y capacidad de reutilización. La Administración debe evaluar el coste total y no únicamente el precio de licencia.
OSPO y repositorios
Un OSPO nacional puede coordinar inventario, contribuciones, comunidades y políticas de publicación. Una plataforma común puede reducir repositorios aislados y facilitar descubrimiento y reutilización.
Seguridad
El código abierto sigue necesitando gestión de vulnerabilidades, dependencias, releases y responsables de mantenimiento.
Qué puede aprender España
El modelo polaco ofrece una referencia para crear políticas coordinadas de repositorios públicos, reutilización y reducción de dependencia.
Fuentes
Fuente: Interoperable Europe / OSOR.
Conclusión
La clave será comprobar si la estrategia se traduce en repositorios mantenidos, reutilización real y capacidad institucional para operar software abierto.
El salto de proyecto aislado a política nacional de software público
La novedad polaca es relevante porque intenta coordinar decisiones que normalmente se toman por organismo. Un OSPO nacional puede ofrecer criterios comunes de licencias, publicación, seguridad y reutilización.
Sin esa coordinación, distintas Administraciones pueden publicar repositorios con estructuras, licencias y procesos incompatibles, reduciendo la posibilidad de que otros reutilicen el trabajo.
La estrategia se alinea con el debate europeo que analizamos en la estrategia de código abierto para las Administraciones.
Qué hace un OSPO público
Una Open Source Programme Office puede inventariar software, definir políticas de contribución, revisar licencias, coordinar comunidades y ayudar a los equipos a publicar proyectos con documentación suficiente.
También puede evitar que un organismo desarrolle desde cero una capacidad ya disponible en otro repositorio.
El OSPO no sustituye a los equipos técnicos; actúa como centro de competencia y gobernanza.
Repositorios comunes y descubrimiento
Publicar código no garantiza reutilización si nadie sabe que existe. Una plataforma común puede facilitar búsqueda por función, tecnología, organismo, licencia y estado de mantenimiento.
La ficha de cada proyecto debería indicar versión, documentación, dependencias, responsable, hoja de ruta y política de soporte.
Los repositorios abandonados tendrían que marcarse claramente para evitar que otros organismos los adopten pensando que siguen mantenidos.
Licencias comprensibles para contratación
Las Administraciones necesitan saber qué derechos obtienen y qué obligaciones asumen cuando reutilizan software. Un catálogo de licencias recomendadas puede reducir incertidumbre.
También conviene diferenciar código desarrollado por encargo, componentes de terceros y librerías. Cada capa puede tener condiciones distintas.
Los pliegos deberían exigir una lista de dependencias y licencias para facilitar revisiones posteriores.
Seguridad de la cadena de suministro
El acceso al código facilita auditoría, pero no elimina vulnerabilidades. Los proyectos necesitan procesos de actualización, advisories, gestión de dependencias y responsables de releases.
Un inventario de componentes permite reaccionar cuando aparece una vulnerabilidad en una librería utilizada por múltiples organismos.
La política debería exigir builds reproducibles o, al menos, mecanismos que relacionen el código publicado con los binarios desplegados.
Reutilización entre Administraciones locales
El apoyo a autoridades locales puede ser una de las áreas con mayor retorno. Los municipios pequeños no pueden mantener grandes equipos de desarrollo, por lo que componentes compartidos pueden reducir coste.
La reutilización debe acompañarse de despliegues sencillos, documentación y soporte. Un repositorio complejo sin guías tendrá poca utilidad para una entidad con recursos limitados.
El modelo puede inspirar a diputaciones y comunidades españolas que ofrecen servicios compartidos.
Contratación orientada a derechos de reutilización
Cuando una Administración financia un desarrollo, debería decidir desde el inicio qué derechos necesita sobre el código y si pretende publicarlo. Negociar esta cuestión al final puede resultar costoso.
Los contratos pueden exigir repositorio, historial de cambios, documentación, scripts de despliegue y transferencia de conocimiento.
La competencia mejora si una segunda empresa puede mantener el software sin reconstruirlo desde cero.
Open source no significa hacerlo todo internamente
Una organización puede contratar soporte profesional sobre software abierto. La diferencia es que debería conservar mayor capacidad para cambiar de proveedor si la documentación y la licencia lo permiten.
La soberanía depende de la existencia de alternativas reales, no de que todos los desarrolladores sean empleados públicos.
También es importante evaluar la salud de la comunidad y la frecuencia de releases.
Cómo priorizar qué publicar
No todo código interno merece convertirse en proyecto público. Herramientas con secretos, dependencias específicas o poco valor externo pueden permanecer internas.
El OSPO puede priorizar componentes genéricos: librerías, conectores, formularios, módulos de interoperabilidad o herramientas de seguridad.
La publicación debería incluir limpieza previa, documentación y eliminación de credenciales o datos.
Métricas para saber si la estrategia funciona
Contar repositorios es insuficiente. Resulta más útil medir reutilizaciones entre organismos, contribuciones externas, incidencias resueltas, tiempo ahorrado y reducción de dependencia.
También puede medirse cuánto tarda un organismo en desplegar una solución publicada y qué esfuerzo necesita para adaptarla.
Los proyectos sin uso deberían revisarse y, si procede, archivarse.
Relación con interoperabilidad
El código abierto facilita inspeccionar interfaces, pero los sistemas seguirán necesitando estándares y modelos comunes. La experiencia de Finlandia con semántica compartida ilustra que reutilizar código y reutilizar significado son problemas relacionados pero distintos.
Las APIs deberían documentarse independientemente de la implementación para que otros productos puedan cumplir el mismo contrato.
Esta separación reduce dependencia incluso cuando un componente concreto deja de mantenerse.
IA y software abierto
La expansión de IA añade modelos, pipelines y herramientas que pueden beneficiarse de repositorios públicos. Sin embargo, publicar código no implica publicar datos sensibles ni pesos con restricciones.
La estrategia europea de IA pública interoperable favorece precisamente componentes reutilizables.
Los proyectos deberían documentar modelos, licencias, datasets y requisitos de hardware por separado.
Gobernanza de contribuciones externas
Un repositorio público puede recibir issues y pull requests de empresas, universidades o ciudadanos. La Administración necesita reglas para revisar y aceptar cambios.
Los mantenedores deben poder explicar qué versiones están soportadas y qué roadmap existe.
La colaboración abierta genera valor cuando existe capacidad real para atenderla.
Qué podría trasladar España del modelo polaco
Una política coordinada de OSPO, repositorios y contratación podría reducir duplicidades entre administraciones. España ya dispone de múltiples iniciativas de reutilización, pero un enfoque más homogéneo facilitaría descubrimiento y mantenimiento.
La clave sería asignar responsables y presupuesto, no limitarse a crear un portal de enlaces.
También podría vincularse con catálogos de componentes interoperables y requisitos del ENS.
Riesgos que debe evitar la estrategia
El principal es confundir publicación con reutilización. Miles de repositorios sin mantenimiento pueden aumentar ruido en lugar de reducir costes.
Otro riesgo es imponer una política uniforme a sistemas con necesidades diferentes. El OSPO debería ofrecer criterios y apoyo, no sustituir la responsabilidad técnica de cada servicio.
La seguridad debe integrarse en releases y no aparecer solo en auditorías puntuales.
Preguntas frecuentes
¿Qué es un OSPO?
Es una oficina que coordina políticas y prácticas relacionadas con software de código abierto dentro de una organización.
¿Open source significa que el software es gratuito?
La licencia puede no tener coste, pero operación, soporte, infraestructura y evolución siguen generando gasto.
¿Puede una Administración contratar soporte externo?
Sí. El objetivo es conservar capacidad de elección y reutilización, no eliminar proveedores.
¿Qué debe publicar un repositorio público?
Código, licencia, documentación, dependencias, instrucciones de despliegue y estado de mantenimiento cuando corresponda.
Conclusión operativa
La estrategia polaca resulta significativa porque intenta convertir el software abierto en una capacidad institucional: OSPO, repositorios, contratación y apoyo a administraciones locales.
Su éxito dependerá de que los proyectos tengan mantenimiento, usuarios y métricas. El open source crea opciones, pero la soberanía solo aparece cuando existen conocimiento, comunidad y capacidad real de operar el software.
Presupuesto de mantenimiento: la parte que decide si un repositorio sobrevive
Publicar software es relativamente sencillo; mantenerlo durante años requiere recursos. La estrategia debería asignar responsables y presupuesto para incidencias, actualizaciones y documentación.
Un proyecto sin mantenedor conocido puede quedar obsoleto aunque siga siendo técnicamente accesible. El catálogo debería mostrar claramente el nivel de soporte.
Las Administraciones que reutilicen una solución necesitan saber si pueden contratar mantenimiento a terceros o asumirlo internamente.
Catálogo de componentes frente a catálogo de proyectos
Muchos repositorios completos son difíciles de reutilizar fuera de su contexto. En cambio, componentes pequeños —autenticación, conectores, librerías de formularios, validadores— pueden integrarse en más servicios.
El OSPO puede ayudar a identificar piezas generalizables y separarlas de lógica específica de un organismo.
Esta modularidad aumenta posibilidades de adopción y reduce el esfuerzo de adaptación.
Documentación como requisito de publicación
Un repositorio público debería explicar para qué sirve, cómo se despliega, qué dependencias utiliza y qué versión está soportada. Sin esta información, el código puede ser legible solo para el equipo original.
Los ejemplos y entornos de prueba reducen la barrera para nuevos organismos.
La documentación también debe explicar limitaciones y casos que no están cubiertos.
Comunidades y empresas proveedoras
El software público abierto puede crear un mercado de empresas capaces de ofrecer implantación y soporte sobre una base común. Esto evita que cada contratación financie desde cero el mismo desarrollo.
Para que exista competencia, la documentación y los procesos de release deben estar abiertos y no depender de información privada del proveedor inicial.
Las comunidades pueden aportar correcciones, pero la Administración debe mantener capacidad de decisión sobre el roadmap de sus componentes críticos.
Formación de empleados públicos
Los equipos necesitan competencias básicas sobre licencias, Git, gestión de dependencias y seguridad de repositorios. Sin ellas, la política puede quedar restringida a unos pocos especialistas.
La formación debería adaptarse a perfiles: jurídico y contratación necesitan entender licencias; desarrollo, contribuciones y releases; dirección, costes y dependencia.
Un OSPO puede coordinar materiales y asesoramiento reutilizables.
Indicadores de salud de un proyecto abierto
Además de estrellas o descargas, conviene observar frecuencia de commits, tiempo de resolución, releases, número de mantenedores y organizaciones que reutilizan el software.
Un proyecto con pocas actualizaciones no siempre está abandonado si su funcionalidad es estable, por lo que las métricas deben interpretarse con contexto.
La ficha pública debería informar del estado: activo, mantenimiento limitado, archivado o sustituido.
Integración con políticas de ciberseguridad
Los repositorios pueden incorporar análisis de dependencias, secret scanning y generación de inventarios de componentes. Estas prácticas deberían automatizarse en los proyectos públicos más relevantes.
Las vulnerabilidades necesitan un canal de reporte y un proceso de divulgación coordinada.
El código abierto expone más ojos al software, pero el beneficio aparece solo si existe capacidad para responder.
Qué podría ser un repositorio público de referencia
Un catálogo nacional podría combinar búsqueda, metadatos, licencias, estado y enlaces al repositorio original sin obligar a centralizar todos los proyectos en una única plataforma.
Esta federación permitiría que cada organismo mantenga su flujo de trabajo mientras la ciudadanía y otras Administraciones disponen de un punto común de descubrimiento.
Los metadatos deberían ser legibles por máquina para facilitar inventarios automáticos.
Reutilización transfronteriza
Si los proyectos utilizan licencias y estándares compatibles, software desarrollado por una Administración puede reutilizarse en otro país. La estrategia europea de open source intenta precisamente aumentar esta circulación.
Las diferencias jurídicas y lingüísticas seguirán requiriendo adaptación, pero una arquitectura modular reduce el trabajo.
Polonia puede beneficiarse de soluciones europeas existentes en lugar de construir todo desde cero.
Qué debería observar España de la ejecución polaca
Será especialmente útil comprobar cómo se financia el OSPO, qué autoridad tiene, cómo se coordinan administraciones locales y qué métricas publica.
También interesará saber si la plataforma de repositorios consigue reducir duplicidades o se limita a agregar enlaces.
Los resultados pueden aportar evidencia para diseñar políticas españolas más coordinadas de software público.
Una cuarta lectura relacionada: interoperabilidad pública
El valor del código abierto aumenta cuando se combina con interfaces comunes. Casos como Information Mediator en Irlanda muestran cómo una arquitectura bien definida permite sustituir componentes manteniendo contratos de integración.
Software abierto e interoperabilidad no son sinónimos, pero juntos pueden reducir barreras de entrada y dependencia.
La continuidad de los proyectos será la prueba real de que la estrategia ha generado capacidad pública y no solo nuevos repositorios.
Fotografía: Digital Buggu / Pexels.