The Linux kernel prepares for a “day after” Linus Torvalds

For more than three decades, the Linux kernel has grown with a comfortable paradox: a massive project maintained by hundreds of people worldwide, yet with a final, centralised step that has effectively passed through the hands of a near-single figure. Linus Torvalds didn’t just write the first lines of code; since 1991, he has also been the final integrator of the mainline tree—the canonical repository that decides what lands and what doesn’t.

That centrality—both efficient and fragile—now has a formal answer. The kernel community has documented a continuity procedure: a “plan to activate a plan” in case there is no orderly transition one day, whether due to retirement, incapacity, or any scenario that leaves the stewardship of the canonical repository in limbo.

It’s not a dramatic turn and it doesn’t crown an heir. It’s what a mature, industrial-grade project does: accept that even strong informal institutions need a protocol once time passes and the software stops being a hobby and becomes critical infrastructure.

Linux: from “personal project” to digital backbone

It’s easy to forget that Linux began as a small kernel in the era of newsgroups and mailing lists. What followed was organic growth: first in universities and technical environments, then as a foundation for servers, networking and supercomputing, and later as an indirect pillar of the mobile world (through Android) and the cloud.

The impact is obvious to anyone running production systems: Linux isn’t “just another operating system”. It’s a de facto standard in data centres, a structural ingredient in the software supply chain, and a layer on which essential services are built. When something like that depends—at the very last step—on a single central figure, a familiar risk concept comes into play: the bus factor.

The bus factor of mainline

Kernel development is distributed: subsystem maintainers, intermediate trees, public review, pull requests, and an engineering culture that has turned Linux into a remarkably effective social machine. Still, the final step—merging into mainline—has historically been the “good bottleneck”: a consistency filter that keeps the project coherent in both technical direction and style.

The uncomfortable question is not whether the community has the talent to keep going. The question is what happens if, when the time comes, there is no transition “with a script”—or if the person responsible for mainline cannot (or does not want to) facilitate it. That is the gap the new document is designed to close.

What the continuity procedure establishes

The text has been added to kernel documentation as “Linux kernel project continuity”, describing an emergency mechanism that is intended to be activated only if there is no smooth transition.

The logic is straightforward:

• An Organizer is designated to kick off the process. The document defines this role as the most recent Linux Maintainers Summit organizer, with the chair of the Linux Foundation Technical Advisory Board (TAB) as an alternative.
• That Organizer has 72 hours to initiate discussion with the invitees of the most recent Maintainers Summit.
• If more than 15 months have passed since the last Maintainers Summit, the TAB determines the set of invitees.
• The group may include additional maintainers if needed.
• Within two weeks, a representative of the group communicates next steps to the wider community via GitHub Linus y System Administration