For over three decades, the Linux kernel has existed with an as obvious as uncomfortable reality: the final say on which changes enter the main branch usually passes through a single person. Linus Torvalds, the project’s creator and “final” maintainer since 1991, has been—practically—the point of final approval in a worldwide workflow involving hundreds of developers and more than a hundred maintainers.
Now, and for the first time explicitly, the community has documented a continuity procedure for the canonical kernel repository: a plan designed to activate only if the main maintainer cannot (or does not want to) continue in that role and no “normal” and orderly transition exists.
A “plan for the plan,” but already in writing
The new document, incorporated into the official kernel documentation, stems from a very specific snapshot: Linux is a highly distributed project, where each subsystem has its responsible parties, but the final step—integrating changes into mainline—remains centralized. The document even recalls previous precedents where other individuals have carried out that work when necessary (notably, the 4.19 cycle in 2018).
The key point isn’t so much discovering that there’s life beyond Torvalds—everyone in the community knows that—as it is putting in writing how the “what do we do now” decision is made in an exceptional scenario. In corporate language, it’s called succession planning. In software engineering, it’s often summarized by a very blunt metric: the bus factor.
What activates the protocol?
The procedure is conceived as an emergency measure. It would only come into play if those maintaining the main repository are “unable or unwilling” to continue with that responsibility and, additionally, do not facilitate a transition.
In that case, a starter figure is appointed—the Organizer—who by default would be the organizer of the last Maintainers Summit. If that’s not possible, the plan considers the President of the Technical Advisory Board (TAB) of the Linux Foundation as a backup.
The timeline: 72 hours, 15 months, and two weeks
The approach is deliberately simple, with clear deadlines:
- Within 72 hours, the Organizer must open a discussion with the invitees from the last Maintainers Summit.
- If more than 15 months have passed since the last Maintainers Summit, then the TAB will decide who the invitees are (and this group can add other maintainers if needed).
- This group must meet (online or in person) “as soon as possible” to evaluate options for managing the main repository, prioritizing the project’s and community’s long-term health.
- Within two weeks, a representative will communicate via the summit’s mailing list (ksummit) what the next steps are.
Additionally, the document clarifies that the Linux Foundation—guided by the TAB—will support and implement whatever that process determines.
What it means (and what it doesn’t mean) for Linux
This move is not an announcement of retirement nor an “imminent succession.” It is, above all, a sign of maturity: accepting that a critical project for the internet, cloud, and industry cannot rely on the assumption that transition occurs “by inertia” if its central figure is missing one day.
It’s also an outward signal. At a time when supply chain resilience for software is scrutinized, formalizing continuity processes reduces uncertainty for companies, governments, and entire ecosystems that base products and services on Linux.
What’s interesting is that the plan doesn’t invent a new “constitution” for the kernel; it relies on existing structures (Maintainers Summit, TAB) and a classic community mechanism (consensus and public communication via mailing lists). It’s intentionally minimalist: it sets the how to initiate a collective decision when time runs out.
Frequently Asked Questions
Does this mean Linus Torvalds is stepping down from the kernel?
No. The procedure is a contingency for an extraordinary scenario. It does not imply an active timetable or transition.
Who picks the successor if something unexpected happens?
The process starts with an Organizer (the last Maintainers Summit organizer or, failing that, the president of the Linux Foundation’s TAB), and the decision is discussed with the group of invitees from the last Maintainers Summit (or those determined by the TAB if a summit hasn’t happened in a while).
Why is there so much talk about the “bus factor” in this case?
Because the kernel has a distributed workflow, but final integration remains centralized. Formalizing a continuity plan enhances the project’s resilience against unexpected events.
Where is the decision communicated publicly?
The plan states that, within a maximum of two weeks, the next steps will be announced on the ksummit mailing list (the one associated with the Maintainers Summit).