Tu pila de código abierto tiene un consejo de administración. Nadie le audita las cuentas.
Linux 6.15 eliminó un soporte que tres décadas de compradores habían dado por descontado, y a quienes les costó no estaban en la sala. Las empresas auditan a cada proveedor comercial y a ninguna de las fundaciones que sostienen de verdad su infraestructura.
En mayo de 2025, el kernel Linux 6.15 se publicó sin soporte para los procesadores 486 y los primeros 586 de Intel, cerrando una promesa de compatibilidad que llevaba vigente desde principios de los noventa y que no estaba escrita en ningún sitio. El razonamiento oficial fue práctico: mantener la capa de emulación que necesitaban esos chips consumía una atención de mantenimiento que el proyecto consideró mejor empleada en otra parte, y la propia lista de correo del kernel llevaba debatiendo la retirada abiertamente desde 2022. Defendible, en sus propios términos. Ahora pregunta a quién se consultó. Las empresas que aún hacen correr ese silicio, en controladores industriales, instrumental de laboratorio y sistemas embebidos que sobreviven a sus fabricantes (desde una fábrica en el Levante español hasta un laboratorio universitario en Ciudad de México), no tuvieron plazo de aviso, ni calendario publicado, ni asiento en ese hilo. Cerrar esa brecha es justo para lo que sirve la diligencia debida en código abierto, y casi nadie la practica.
Tu empresa no firmaría un contrato a cinco años con un proveedor sin comprobar quién lo posee, quién lo financia y qué ocurre cuando cambian sus intereses. Y sin embargo esa misma empresa construye una década de infraestructura sobre una plataforma de código abierto sin hacer una sola pregunta sobre la organización que la dirige. Donde existe diligencia, se detiene en el archivo de licencia, y la licencia solo regula lo que puedes hacer con el código tal como está. Lo que quien lo gobierna puede hacerle al código a partir de mañana queda completamente fuera de ese documento. Nadie manda una factura por una retirada de soporte. La partida presupuestaria aparece igualmente.
¿Te debe compatibilidad retroactiva un proyecto de código abierto?
No. La hoja de ruta, la política de obsolescencia y el soporte de plataformas quedan enteramente a discreción de quien gobierna el proyecto, punto. Con un proveedor comercial tendrías plazos de aviso, niveles de servicio y remedios contractuales; con quien gobierna un proyecto ascendente tienes la influencia proporcional a tu financiación y tu participación, y la mayoría de las empresas no aportan ni una ni otra. En términos de gobernanza, eres cliente sin factura de un proveedor que no te debe nada. Ese equilibrio funciona de maravilla mientras los incentivos coinciden por casualidad, y el error está en tratar esa coincidencia como una propiedad del código abierto en vez de como algo que hay que vigilar. Tampoco quien gobierna es una abstracción neutral: la membresía platino de la Linux Foundation es un quién es quién de fabricantes de chips, operadores de nube y fabricantes de dispositivos, cada uno con sus propios intereses comerciales, y los órganos de gobierno de otros proyectos del sector se parecen mucho a este.
¿Cuánto aviso dan en la práctica las retiradas de soporte en código abierto?
El que diga la política de quien gobierna, y ni un día más. El historial comparado merece leerse con calma, porque el rango es enorme. En el extremo generoso está Python. La PEP 373, publicada en 2008, fijó la jubilación de Python 2.7 para 2015, y cuando quedó claro que el ecosistema no estaba listo, el proyecto movió la fecha a 1 de enero de 2020. Eso es más de una década de aviso público y por escrito, revisado una vez, a favor de quienes dependían de él.
En el extremo contrario está CentOS. Las empresas adoptaron CentOS 8 en 2019 confiando en un ciclo de vida publicado que reflejaba el de Red Hat Enterprise Linux, con un fin de vida fijado para 2029. En diciembre de 2020 el proyecto anunció que CentOS Linux 8 terminaría a finales de 2021, al desplazarse el trabajo hacia CentOS Stream. Un margen que los usuarios habían valorado en casi una década se desplomó a unos doce meses de aviso, y cada plan de migración construido sobre esa fecha venció con siete años de antelación.
Node.js queda en medio y enseña la lección más sutil. Node 16 tenía un fin de vida publicado para abril de 2024 según el calendario de versiones del proyecto, y el proyecto adelantó esa fecha siete meses, hasta el 11 de septiembre de 2023, porque la librería OpenSSL 1.1.1 sobre la que corría se quedaba sin soporte antes, y nadie quería un entorno de ejecución corriendo sobre criptografía sin parchear. El calendario era real y quien gobernaba el proyecto honró su propio proceso. Aun así, quienes dependían de él perdieron siete meses, porque el reloj de otra organización llegó antes a cero.
Pon ese historial junto al del kernel y el patrón queda claro: el aviso es política, no física. Va de una década a un año, las fechas publicadas se mueven en ambas direcciones, y tu margen real de aviso es el plazo más corto de toda tu cadena de dependencias. La retirada de los 486 no es un escándalo; es el dato en el extremo más lejano de ese rango. No existía ningún documento de ciclo de vida para el soporte de hardware en el kernel, así que el único aviso disponible fue una discusión en una lista de correo que casi ningún departamento de compras del planeta estaba leyendo.
Cuando el papeleo fabrica el problema
Está emergiendo un riesgo distinto, y conviene decir con claridad que no tuvo ningún papel en la decisión sobre los 486, que se debatió en abierto durante años con argumentos de ingeniería. El riesgo es que ahora se puede generar bajo demanda «evidencia» de carga de mantenimiento. Un fragmento de código funciona en producción durante años sin que nadie se queje; una herramienta de escaneo automatizado produce un fallo teórico con apariencia plausible; el informe entra en el gestor de incidencias; el código pasa a tener incidencias abiertas, y retirarlo se lee como limpieza y no como obsolescencia forzada. El proyecto curl está viviendo la primera fase de esto. Su mantenedor, Daniel Stenberg, ya advertía en enero de 2024 sobre los informes de seguridad generados con IA, y en julio de 2025 informó de que en torno a una quinta parte de los informes de seguridad que recibía curl eran «basura» generada por IA, sin un solo informe válido producido con ayuda de IA hasta la fecha, y cada envío quemando horas de revisores cualificados. Borrar código a base de papeleo es una posibilidad real para cualquier proyecto cuyo triaje no sepa distinguir la especulación generada por máquina de un fallo que de verdad sufrió una persona.
Trata la excusa de «es cosa de la IA» con especial recelo en los debates sobre el alcance de un proyecto, porque la misma premisa se usa como capacidad en un argumento (con menos mantenedores se puede sostener más código) y como carga en el siguiente (la basura generada inunda el gestor de incidencias), y una premisa que sostiene a la vez una conclusión y la contraria no está haciendo ningún trabajo analítico.
¿Cómo es en la práctica la diligencia debida en código abierto?
Como la diligencia sobre un proveedor, apuntando una capa más abajo, y el historial comparado de arriba te da las preguntas directamente.
Política de ciclo de vida por escrito. ¿Publica siquiera una quien gobierna el proyecto? La década de aviso de Python existió porque existía la PEP 373. El kernel no tiene un documento equivalente para el soporte de hardware, y eso ya avisaba de que el aviso real sería lo que decidiera la lista de correo.
Historial y dirección. Cuando este gobierno del proyecto ha movido una fecha antes, ¿en qué sentido lo hizo? Python revisó a favor de quienes dependían de él; CentOS revisó en su contra, y de forma drástica. La última revisión de quien gobierna un proyecto es el mejor pronóstico disponible de la próxima.
Aviso transitivo. Tu margen real de aviso es el mínimo de toda la cadena, no el número que aparece en la caja. El calendario de Node 16 se cumplió a rajatabla hasta que se agotó el de OpenSSL. Mapea qué relojes de otras capas hereda tu plataforma.
Gobernanza y dinero. ¿Quién financia a quien gobierna el proyecto, y a esos financiadores les beneficia que tengas que renovar hardware o migrar de plataforma?
Exposición y salida. Sabe qué funcionalidades, plataformas y generaciones de hardware de tu parque quedan en la zona plausible de lo «legacy» para el proyecto ascendente, y calcula ya, con calma, el coste de bifurcar, fijar versión o migrar, en lugar de hacerlo en el trimestre en que llega el aviso de fin de soporte. Una salida que ya has calculado es la única que refuerza tu posición negociadora.
Nada de esto es exótico. Es la misma cartografía de incentivos que aplicamos en nuestras revisiones de estrategia tecnológica, apuntada hacia una contraparte que la mayoría de las organizaciones nunca se ha planteado examinar, y pertenece al mismo plan de ciclo de vida que las plataformas sobre las que se sostiene tu negocio. Encaja además con una disciplina que hemos defendido a propósito de la preparación real para adoptar IA: las afirmaciones se ponen a prueba antes de actuar sobre ellas, las haga quien las haga, río arriba o en tu propio consejo. Los cimientos bajo tu pila son proveedores sin ninguna de las obligaciones de un proveedor. Audita a quienes gobiernan tus dependencias como auditarías a un proveedor. Pueden cambiar de opinión, y el coste lo pagas tú.
Preguntas frecuentes
¿Cómo sé si un proyecto de código abierto del que dependo puede retirarme soporte sin avisar?
Vigila a quien gobierna el proyecto, no solo el código. La ausencia de una política de ciclo de vida por escrito, cambios en la financiación y en la composición del órgano de gobierno hacia nuevas prioridades comerciales, debates de obsolescencia planteados como «reducir la carga de mantenimiento», y una cobertura de mantenedores escasa en las rutas de código que tú usas son señales tempranas. La retirada de los 486 se anunció en los debates del kernel casi tres años antes de hacerse efectiva. Trata los hilos de gobernanza de un proyecto como tratarías las presentaciones de resultados de un proveedor: aburridos, públicos y llenos de información.
¿Son un riesgo real para el software estable los informes de errores generados por IA?
Sí, y la experiencia del proyecto curl muestra la forma que toma: una parte considerable de los informes de seguridad que recibe ahora está generada por máquina, y prácticamente ninguno ha resultado válido. El peligro está en el triaje. Un fallo teórico y generado por máquina es una evidencia más débil que un problema que de verdad sufrió alguien en producción, y un proyecto que trata ambos por igual acabará reclasificando código que funciona como si fuera una carga. Al evaluar una dependencia, pregunta si su proceso de triaje distingue la especulación generada por máquina de los informes de personas reales.
¿Qué debe cubrir una revisión de gobernanza de código abierto?
Cuatro cosas: si quien gobierna el proyecto publica una política de ciclo de vida y cómo ha cumplido o revisado fechas antes (el rango va desde la década de aviso de Python 2 hasta el desplome de CentOS 8, de 2029 a finales de 2021); quién gobierna y financia el proyecto y hacia dónde va su ingreso; un mapa de qué sistemas tuyos dependen de funcionalidad que plausiblemente podría clasificarse como «legacy», incluyendo los márgenes de aviso heredados de capas aún más arriba; y una ruta de salida ya calculada (bifurcar, fijar versión o migrar). Actualízala cada año, porque los incentivos de quien gobierna un proyecto cambian más rápido que tus ciclos de revisión.
Relacionado
- En Ubuntu 26.04 LTS, el coreutils del que depende tu build ya no es de GNU
- La prima de la soberanía: por qué las soluciones de IA soberana para empresas ganan por acceso, no por velocidad
- Los pleitos por secretos comerciales se ganan años antes de que nadie dimita. Que se lo pregunten a Faccenda Chicken.
- Security & Trust
Escrito por una persona editorial de IA del sistema editorial propietario de Abyshire y revisado por nuestro equipo.