Durante más de tres décadas, el kernel de Linux ha vivido con una realidad tan evidente como incómoda: la última palabra sobre qué cambios entran en la rama principal suele pasar por una única persona. Linus Torvalds, creador del proyecto y mantenedor “final” desde 1991, ha sido —en la práctica— el punto de cierre de un flujo de trabajo global que implica a cientos de desarrolladores y a más de un centenar de mantenedores.

Ahora, y por primera vez de forma explícita, la comunidad ha documentado un procedimiento de continuidad para el repositorio canónico del kernel: un plan pensado para activarse solo si el mantenedor principal no puede (o no quiere) seguir ejerciendo ese papel y, además, no existe una transición “normal” y ordenada.

Un “plan para el plan”, pero ya por escrito

El nuevo texto, incorporado a la documentación oficial del kernel, parte de una fotografía muy concreta: Linux es un proyecto altamente distribuido, donde cada subsistema tiene sus responsables, pero el paso final —integrar cambios en mainline— sigue siendo centralizado. El documento recuerda incluso que ya ha habido precedentes en los que otras personas han hecho ese trabajo cuando ha sido necesario (se cita el ciclo de la versión 4.19 en 2018).

Lo relevante no es tanto descubrir que hay vida más allá de Torvalds —la comunidad lo sabe— como dejar por escrito cómo se decide el “qué hacemos ahora” en un escenario excepcional. En el mundo corporativo se llama planificación de sucesión. En ingeniería de software suele resumirse en una métrica muy cruda: el bus factor.

¿Qué activa el protocolo?

El procedimiento se concibe como una vía de emergencia. Solo entraría en juego si quienes mantienen el repositorio principal “se vuelven incapaces o no están dispuestos” a seguir con esa responsabilidad y, además, no facilitan una transición.

En ese caso, se nombra una figura de arranque, el Organizer, que por defecto sería el organizador del último Maintainers Summit. Si eso no es posible, el plan contempla como respaldo al presidente del Technical Advisory Board (TAB) de la Linux Foundation.

El calendario: 72 horas, 15 meses y dos semanas

La receta es deliberadamente simple y con plazos definidos:

• En 72 horas, el Organizer debe abrir una discusión con las personas invitadas al último Maintainers Summit.
• Si han pasado más de 15 meses desde el último Maintainers Summit, entonces el TAB decide quiénes son los invitados (y ese grupo puede sumar a otros mantenedores si hace falta).
• Ese grupo debe reunirse (online o presencial) “lo antes posible” y evaluar opciones para la gestión del repositorio principal priorizando la salud a largo plazo del proyecto y su comunidad.
• En un plazo de dos semanas, un representante comunica por la lista de correo de la cumbre (ksummit) cuáles serán los siguientes pasos.

Además, el documento deja claro que la Linux Foundation —guiada por el TAB— apoyará e implementará lo que ese proceso determine.

Qué significa (y qué no significa) para Linux

Este movimiento no es un anuncio de retirada, ni un “relevo inminente”. Es, sobre todo, un gesto de madurez: aceptar que un proyecto crítico para internet, la nube y la industria no puede depender de que la transición ocurra “por inercia” si un día falta su figura central.

También es una señal hacia fuera. En un momento en el que la resiliencia de la cadena de suministro del software se mira con lupa, formalizar procesos de continuidad reduce incertidumbre para empresas, gobiernos y ecosistemas completos que basan productos y servicios en Linux.

Lo interesante es que el plan no inventa una nueva “constitución” del kernel: se apoya en estructuras ya existentes (Maintainers Summit, TAB) y en un mecanismo clásico de la comunidad (consenso y comunicación pública por listas de correo). Es minimalista a propósito: fija el cómo arrancar una decisión colectiva cuando el reloj corre.

---

Preguntas frecuentes

¿Esto significa que Linus Torvalds se retira del kernel?
No. El procedimiento se plantea como contingencia para un escenario extraordinario. No implica un calendario ni una transición activa.

¿Quién elige al sustituto si ocurre algo inesperado?
El proceso arranca con un Organizer (último organizador del Maintainers Summit o, en su defecto, el presidente del TAB de la Linux Foundation) y la decisión se discute con el grupo de invitados del último Maintainers Summit (o los que determine el TAB si hace mucho que no hay cumbre).

¿Por qué se habla tanto del “bus factor” en este caso?
Porque el kernel tiene un flujo de trabajo distribuido, pero una integración final centralizada. Formalizar un plan de continuidad eleva la resiliencia del proyecto ante eventos inesperados.

¿Dónde se comunica públicamente la decisión?
El plan contempla que, en un máximo de dos semanas, se comuniquen los siguientes pasos por la lista de correo ksummit (la asociada al Maintainers Summit).