The Linux Kernel's Succession Plan: Inside the 72-Hour Protocol for Replacing Linus Torvalds
#Infrastructure

The Linux Kernel's Succession Plan: Inside the 72-Hour Protocol for Replacing Linus Torvalds

Startups Reporter
3 min read

A leaked kernel document reveals the exact contingency plan if Linus Torvalds steps away from maintaining the mainline repository, showing how the project handles its most critical single point of failure.

The Linux kernel source tree contains a document that answers a question many in open source have asked: what happens if Linus Torvalds can no longer maintain the kernel? The file, titled conclave.rst and located in the kernel's documentation hierarchy, outlines a formal succession protocol that activates within 72 hours of a crisis.

This isn't theoretical. The process was stress-tested during the 4.19 release when Torvalds took a brief hiatus, demonstrating that the project could function without its creator. But the documented procedure goes further, establishing a permanent mechanism for what could be the most significant transition in open source history.

The 72-Hour Clock

The protocol begins with a strict timeline. Within 72 hours of recognizing that the top-level maintainer is "unwilling or unable" to continue, a designated organizer must convene a meeting. The organizer is typically the last Maintainers Summit organizer or, as a backup, the Linux Foundation Technical Advisory Board (TAB) Chair.

This initial contact targets a specific group: the invitees from the most recently concluded Maintainers Summit. These aren't just any developers—they're the core maintainers who have already been vetted through the summit selection process. If no summit has occurred in the last 15 months, the TAB steps in to determine who should attend.

The Conclave

The meeting itself has clear parameters:

  • Participants: Summit invitees plus TAB members, with permission to bring in other maintainers as needed
  • Chair: The organizer who called the meeting
  • Mandate: Consider options for ongoing management that maximize "long term health of the project and its community"
  • Timeline: Two weeks to produce a plan

This isn't a rubber stamp. The group must evaluate structural options: single maintainer replacement, a small committee, distributed leadership, or other models. The constraint is that whatever emerges must serve the project's health, not just convenience.

From Conclave to Community

Within two weeks, a representative must communicate the next steps to the broader community using the [email protected] mailing list. This isn't a private decision—it becomes public knowledge through the official channel.

The Linux Foundation, guided by the TAB, then takes responsibility for implementing the plan. This gives the technical decision institutional backing and resources.

What This Reveals About Kernel Governance

The document exposes several interesting aspects of kernel governance:

Centralization Despite Distribution: The kernel is famously distributed with over 100 maintainers, but the final integration step remains centralized. The contingency plan acknowledges this bottleneck while trying to make the succession process itself distributed and meritocratic.

Precedent Over Personality: By codifying this process, the project separates the role from the individual. The expectation is that "it maximizes the long term health of the project and its community," not that it preserves any particular person's vision.

Institutional Backing: The Linux Foundation's role is supportive, not directive. The technical community makes the decision; the Foundation provides the mechanism to implement it.

The 4.19 Test Case

The document references the 4.19 release as proof this isn't just paperwork. When Torvalds stepped back briefly, others were able to handle the final integration. The experience likely informed the formalization of this process.

Why This Matters

For a project that underpins virtually all modern computing infrastructure, having a documented succession plan isn't optional—it's a requirement for long-term stability. The fact that this process exists, is written down, and has been tested suggests a maturity that many open source projects lack.

The protocol also reflects a realistic understanding of human factors: 72 hours is fast enough to prevent paralysis but slow enough to avoid panic decisions. Two weeks provides time for deliberation without allowing the project to drift.

The full document is available in the Linux kernel source tree under Documentation/process/conclave.rst.

Comments

Loading comments...