El open source es gratis. Mantenerlo, no.

English Português

OSERA mantiene versiones de Spring que el proyecto original ya no soporta. Qué muestra sobre el open source y por qué es obsolescencia con otro nombre.

Línea de tiempo de tres versiones de Spring. El soporte del proyecto original termina entre 2023 y 2024, mucho antes de la marca de octubre de 2026. El soporte extendido llega hasta 2029.
Elaboración propia con datos de endoflife.date.

Spring Boot 2.7, Spring Framework 5.3 y Spring Security 5.7 dejaron de recibir soporte del proyecto original en 2023 y 2024. Lo indica endoflife.date. La versión más nueva de Spring Boot es la 4.1. Según OSERA, el sector financiero todavía corre esas tres líneas, y de ese hecho parte OSERA.

Qué es OSERA

El Open Source Enterprise Resiliency Alliance es una iniciativa de FINOS, la fundación de software abierto para servicios financieros. Según su sitio, mantiene versiones reforzadas de más de 50 librerías de Spring y de sus dependencias. Aplica correcciones para vulnerabilidades públicas a las versiones que sus miembros Premier priorizaron.

Trabaja en tres capas. Primero ofrece cada corrección al proyecto original, donde siga vivo. Cuando el original no puede aceptarla, mantiene un fork público. Y los miembros reciben además artefactos construidos y firmados, con SBOM y evidencia de pruebas, que consumen cambiando una línea en su proxy corporativo. El código sigue siendo abierto. Solo el acceso a esos artefactos requiere ser miembro.

El propio sitio aclara el límite: esos lanzamientos tienen plazo y son un puente hacia una versión vigente, no una licencia para quedarse atrás.

Los números que lo justifican

Estas son las cifras que publica OSERA:

  • Cerca del 80% de las dependencias open source están sin gestionar y desactualizadas, según Sonatype.
  • Una de cada tres instituciones confía en que los componentes que consume están mantenidos y al día, según el informe de FINOS de 2024.
  • Cerca del 78% de las explotaciones empiezan el día en que se publica la vulnerabilidad o antes. En 2018 eran el 19%, según el informe Patchmageddon de J.P. Morgan.
  • Una de cada cinco firmas financieras tiene equipos distintos que mantienen por su cuenta forks del mismo proyecto, según otro estudio de FINOS.

La licencia es gratis y el mantenimiento no

Usar open source no es comprar un producto. Es heredar una obligación. El código llega sin costo, y a partir de ahí alguien tiene que seguir corrigiéndolo.

Es el mismo problema que ya describimos para los sistemas de siempre. La obsolescencia tecnológica incluye todo lo que el proveedor ya no soporta. Una librería de 2022 en 2026 entra en esa definición, igual que un COBOL o un OpenVMS. Los sistemas legacy siguen en operación por el miedo al cambio. Y quedan expuestos porque dejan de recibir parches.

Con Spring ni siquiera falta el aviso. El proyecto publica sus fechas de fin de soporte, y el sector sigue en esas versiones dos y tres años después. No es un problema de información. Es que nadie tiene asignada la tarea de decidir qué hacer cuando la fecha llega.

Es también lo que ocurre cuando cada equipo hace su propio fork. Un proyecto que copia un formato ajeno hereda la tarea de seguirlo para siempre. Por eso en fluxrig consumimos el vocabulario de Moov tal como está. Cuando encontramos un hueco, devolvimos el arreglo al proyecto original.

Lo que nos parece valioso y lo que queda abierto

Lo valioso es que convierte el mantenimiento en una tarea con presupuesto, gobierno y dueño. Hoy suele ser la tarea que nadie tiene asignada. El sitio anuncia además un modelo de patrocinio por proyecto, para financiar directamente lo que cada firma más usa.

Tres cosas a tener en cuenta:

  • Es muy reciente. El sitio habla de resultados en semanas, y lo que mide es lo que ellos publican.
  • Tiene un precio. La membresía Premier cuesta $100.000 al año, y la General entre $15.000 y $90.000 según el tamaño de la firma, en las cifras del sitio. Mantener cuesta, y alguien lo paga.
  • Es un puente. El propio sitio lo dice. La salida sigue siendo modernizar, y OSERA compra el tiempo para hacerlo ordenado.

Por dónde empezar

Antes de pensar en un consorcio, cualquier organización puede responder cuatro preguntas:

  1. Qué versión de cada librería corre cada sistema, con un SBOM actualizado.
  2. Hasta cuándo la soporta el proyecto original, y si ya terminó.
  3. Qué se hace con cada una: actualizar, financiar su mantenimiento o retirarla, con fecha.
  4. Cuánto se presupuesta al año para mantener lo que se usa gratis.

Si el inventario de qué se corre y hasta cuándo se mantiene no existe, ese es el primer trabajo. En JAAB trabajamos la modernización de sistemas críticos junto a EBS, y empezamos por ese inventario.

Etiquetas
  • legacy
  • security
  • modernization
  • open-source

← Volver al blog

Agendar una reunión