La soberanía digital exige financiación, no solo adopción
En esta página
La Comisión Europea ha abierto una convocatoria de aportaciones sobre una nueva “Estrategia europea para ecosistemas digitales abiertos”.1 La consulta dura hasta el 3 de febrero, y el planteamiento dice mucho: el código abierto como “bien público que se puede usar, modificar y redistribuir libremente” y que podría reforzar la independencia tecnológica y la ciberseguridad de la UE.2
Han identificado bien el problema. Los gobiernos y las empresas europeas dependen mucho de proveedores de software de fuera de la UE, como Microsoft, Google y Amazon, y eso crea vulnerabilidades en la cadena de suministro de infraestructuras críticas. La solución a la que recurren es el código abierto. Sin dependencia de un proveedor. Código auditable. Libertad para hacer un fork si un proyecto muere o si una empresa cambia de rumbo contra tus intereses.
He escrito aparte sobre cómo la CLOUD Act de EE. UU. y la erosión de la confianza en el tratamiento transatlántico de datos ya empujan a los gobiernos europeos a desmontar sus dependencias de Microsoft. La revuelta silenciosa de Europa contra la nube de EE. UU. concreta el riesgo para la soberanía: una administración estadounidense hostil podría obligar a los proveedores a retener o incautar datos, y Europa quedaría expuesta si no controla su propia pila.
Es el instinto correcto. Pero no funcionará si no están dispuestos a pagarlo.
El código abierto es la herramienta correcta
Seamos claros: la UE no se equivoca con la elección tecnológica. El código abierto es de verdad el camino hacia la soberanía digital, y el razonamiento es sencillo.
Cuando tu gobierno funciona con software propietario, estás alquilando tu propia infraestructura. Microsoft puede cambiar las condiciones de licencia. Oracle puede auditarte hasta rendirte. Amazon puede dar de baja el servicio gestionado sobre el que has montado tus sistemas. No tienes recurso alguno, porque el código no es tuyo.
El código abierto cambia el reparto de poder. Puedes auditarlo en busca de vulnerabilidades y puertas traseras, algo esencial en sistemas del Estado. Puedes hacer un fork si los mantenedores llevan el proyecto en una dirección que no te sirve. Puedes contratar a desarrolladores locales para adaptarlo a tus necesidades. No quedas atado a la hoja de ruta de un único proveedor.
No es teoría. Múnich migró a Linux, volvió a Windows y ahora se plantea Linux otra vez.3 Ese ir y venir no es un fracaso del código abierto, es una demostración de que hay opciones. Podían cambiar. Prueba a hacerlo con diez años de integraciones con Microsoft 365.
Lo que he visto en el código abierto
Llevo más de quince años escribiendo código de forma profesional, y el código abierto ha sido la base de todo lo que he construido. Los productos en los que he trabajado, Flowstate, Jamie, MimeProtect y Blinq, se apoyan en miles de dependencias que mantienen personas a las que nunca conoceré.
Algunos de esos mantenedores trabajan para grandes empresas que contribuyen al código abierto como parte de su modelo de negocio. Pero muchos no. Son personas que mantienen infraestructura crítica en su tiempo libre, a menudo por poco dinero o por nada.
He visto repetirse el mismo patrón. Un desarrollador brillante crea una librería que resuelve un problema difícil. Se adopta. Las empresas construyen productos encima. Las notificaciones de GitHub del mantenedor se vuelven abrumadoras. Se quema. El proyecto se abandona o se arrastra con actualizaciones esporádicas.
Lo peor llega cuando algo se rompe. Se divulga una vulnerabilidad. El mantenedor, que lleva años haciendo esto gratis y muchas veces con un trabajo a jornada completa, de pronto tiene a todo internet exigiéndole un parche urgente. Algunos lo gestionan con elegancia. Otros desaparecen.
Esto no es sostenible. Hemos montado la economía digital sobre trabajo voluntario, y seguimos sorprendiéndonos cuando a los voluntarios se les acaban las fuerzas.
El problema de la extracción de valor
Lo que reconoce la consulta de la UE es que gran parte del valor que generan los proyectos europeos de código abierto lo capturan grandes tecnológicas internacionales en lugar de beneficiar a la economía de la UE.4
Los desarrolladores europeos construyen herramientas. Las publican como código abierto. Amazon las toma, las envuelve en servicios gestionados y se las vende de vuelta a las empresas europeas. Elastic, Redis, MongoDB: el patrón está bien documentado. Los creadores construyen y los hyperscalers monetizan.
Esta es la fuga de soberanía que la UE intenta tapar. Pero no se arregla solo usando más código abierto. Si los gobiernos europeos adoptan código abierto y los desarrolladores que lo mantienen siguen sin poder pagar el alquiler, solo has cambiado tu dependencia de Microsoft por una dependencia de voluntarios sin sueldo.
El valor tiene que quedarse en el ecosistema. Eso significa pagar a quienes construyen y mantienen el software.
Las subvenciones no son la respuesta
La UE sabe financiar cosas. Horizonte Europa, Europa Digital, los programas nacionales de innovación: no faltan mecanismos de subvención. Pero las subvenciones resuelven el problema equivocado.
Las subvenciones se orientan a objetivos. Pides financiación para construir algo nuevo. Cumples hitos. Entregas un informe final. El proyecto termina.
La infraestructura de código abierto no funciona así. OpenSSL, la librería que protege la mayor parte de internet, no tenía pocos recursos porque nadie financiara una nueva implementación de TLS. Los tenía escasos porque nadie financió el mantenimiento continuo de una que ya existía. Cuando llegó Heartbleed en 2014, el mundo descubrió que la infraestructura de cifrado crítica la mantenían un puñado de desarrolladores a tiempo parcial.5
Con Log4j pasó lo mismo. Una librería de logging que usa prácticamente toda aplicación Java del planeta, mantenida por voluntarios. Cuando apareció la vulnerabilidad Log4Shell, esos voluntarios tuvieron que correr para arreglar un fallo crítico que afectaba a miles de millones de sistemas, sin cobrar por ello.6
No puedes llegar a la infraestructura a base de subvenciones. Las subvenciones financian proyectos y la infraestructura necesita operaciones. La diferencia importa.
Cómo es la financiación de verdad
La consulta de la UE menciona “modelos sostenibles de compensación a los desarrolladores”, y los actores del sector han presentado una hoja de ruta de 70 puntos que cubre los mecanismos de inversión.7 Son las conversaciones que hay que tener.
La financiación real del código abierto se parece a esto:
Presupuestos operativos, no subvenciones por proyecto. Paga un sueldo a los mantenedores para que la infraestructura crítica siga segura y actualizada. Financia el trabajo aburrido: parches de seguridad, actualización de dependencias, documentación, gestión de la comunidad.
Preferencia en la contratación pública. Si los gobiernos europeos gastan miles de millones en software, exige que ese gasto prefiera soluciones de código abierto con mantenedores europeos. Cada euro que se gasta en licencias de Microsoft es un euro que no se gasta en construir alternativas soberanas.
Apoyo a la infraestructura. Construye y aloja los servicios que necesitan los proyectos de código abierto: CI/CD, repositorios de paquetes, alojamiento de documentación. La Linux Foundation y la Apache Foundation ofrecen parte de esto, pero hay sitio para equivalentes europeos.
Redacción técnica y accesibilidad. Una buena documentación hace utilizables los proyectos. Financia a redactores técnicos para que las herramientas de código abierto sean accesibles a los equipos de TI del gobierno, que quizá no tengan los conocimientos para trabajar solo con el código fuente.
Los comentarios de la consulta muestran que la comunidad lo entiende.8 La cuestión es si la UE destinará el presupuesto.
La soberanía es una decisión de gasto
La UE gasta sumas enormes en software. Los departamentos de gobierno de toda Europa pagan a Microsoft, Google y Amazon licencias que suman miles de millones al año. Parte de ese gasto es inevitable: no vas a sustituir Windows de la noche a la mañana.
Pero cada decisión de compra es una elección. Cada renovación de un acuerdo empresarial es dinero que podría financiar alternativas soberanas.
La soberanía digital no es una elección tecnológica. Es una partida del presupuesto.
La UE ha identificado bien que el código abierto es la herramienta. Pero una herramienta olvidada en un cobertizo no construye nada. Hacen falta personas que la usen, la mantengan y la mejoren. Y esas personas tienen que pagar el alquiler.
El código abierto no salvará a Europa de la dependencia tecnológica si Europa no lo paga. No con subvenciones para proyectos vistosos, sino con financiación operativa para la infraestructura de la que ya dependemos. No con programas de innovación, sino con políticas de contratación que dirijan el dinero hacia los mantenedores europeos.
La consulta se cierra el 3 de febrero. La cuestión no es si la UE entiende el problema, porque es evidente que sí. La cuestión es si firmará los cheques.
Footnotes
-
EU launches call for evidence on European open digital ecosystems – Linuxiac ↩
-
Munich considers Linux, again – ZDNet ↩
-
The Linuxiac article notes that “much value generated by European open-source projects is captured by large international tech companies rather than benefiting the EU economy.” ↩
-
The Heartbleed Bug and Open Source Security – OpenSSL Security Advisory, 2014 ↩
-
The Log4j vulnerability and the importance of open source security – CISA ↩
-
El artículo de LWN.net menciona una hoja de ruta de 70 puntos de los actores del sector que cubre desarrollo tecnológico, formación en competencias, prácticas de contratación, mecanismos de inversión y marcos de gobernanza. ↩
-
Have your say: European Open Source Strategy – European Commission ↩