Die Linux-Kernel-Community hat kürzlich offiziell einen „Projektkontinuitätsplan“ erstellt, um einen Rahmen für den Nachfolgeprozess festzulegen, wenn Linus Torvalds eines Tages nicht mehr als Top-Betreuer fungiert. Dieser Plan zielt darauf ab, zu klären, wie ein oder mehrere neue Top-Betreuer ausgewählt werden können, die in einer geordneten Übergangs- oder Notfallsituation die Linux-Mainline-Codebasis übernehmen.
Das von den Entwicklern als „Plan der Pläne“ bezeichnete Dokument wurde vom langjährigen Kernel-Mitarbeiter Dan Williams verfasst und kürzlich auf dem Linux Kernel Maintainers Summit in Tokio diskutiert. Er stellte den Vorschlag als „ein erhebendes Thema im Zusammenhang mit der Tatsache, dass wir alle sterben werden“ vor und löste wissendes Gelächter aus. In einem Interview nach dem Treffen sagte Torvalds, dass dieses Thema offiziell auf die Tagesordnung gesetzt wurde, weil sein letzter Vertrag mit der Linux Foundation im dritten Quartal des vergangenen Jahres ausgelaufen sei und die Mitglieder des technischen Beirats der Stiftung sich dieses Prozesses sehr bewusst seien. Obwohl der darauffolgende Vertrag verlängert wurde, veranlasste er die Gemeinde auch dazu, systematischer über die langfristige Fortführung des Projekts nachzudenken.
Es ist erwähnenswert, dass dieser Plan keinen „Nachfolger“ benennt, sondern sich auf die Einrichtung eines klaren Entscheidungsmechanismus konzentriert. Das Dokument sieht vor, dass im schlimmsten Fall oder bei einer ordnungsgemäßen Übergabe eine Betreuergruppe ähnlich einer „Wahlversammlung“ einberufen wird, die sich auf die Bewertung der Kandidaten konzentriert, wobei die langfristige Gesundheit des Projekts höchste Priorität hat. Einige Verteidiger des Treffens scherzten, dass diese Gruppe wie ein geheimes Treffen zur Wahl eines neuen Papstes sein könnte, bei dem alle in einem Raum eingesperrt werden und dann eine weiße Rauchwolke als Signal an die Außenwelt verwendet wird, nachdem eine Entscheidung getroffen wurde.
Aus Sicht des Risikomanagements war diese Initiative darauf ausgerichtet, das klassische Problem des „Busfaktors“ anzugehen – das heißt, was mit dem Projekt passieren würde, wenn eine Schlüsselperson „von einem Bus angefahren“ würde. Derzeit liegt der „Busfaktor“ des Projekts aufgrund seiner zentralen Stellung in der Linux-Entwicklung immer noch nahe bei 1: Wenn er plötzlich abwesend wäre, könnte dies theoretisch Auswirkungen auf den Zusammenführungs- und endgültigen Veröffentlichungsprozess haben. Im tatsächlichen Betrieb haben jedoch sowohl Torvalds als auch andere Top-Betreuer oft erwähnt, dass, wenn jemand wirklich vorübergehend die Rolle des „Top-Pinguins“ übernehmen muss, der natürlichste Kandidat mit ziemlicher Sicherheit der Kernel-Betreuer der aktuellen stabilen Version, Greg Kroah-Hartman, sein wird.
Torvalds gab auch seine eigene Antwort auf die weit verbreitete Bemerkung, dass Greg KH als „designierter Ersatzreifen“ angesehen werde. Er wies darauf hin: „Das Problem ist, dass Greg nicht von Anfang an Greg hieß. Vor Greg gab es Andrew Morton und Alan Cox; nach Greg werden es Shannon und Steve sein.“ Aus seiner Sicht kommt es nicht auf einen bestimmten Namen an, sondern darauf, ob die Entwicklungsgemeinschaft einer Person oder einer Gruppe vertrauen kann. Dieses Vertrauen basiert auf einer langfristigen Zusammenarbeit und Integration. „Man muss lange genug in der Gemeinschaft existieren, damit jeder versteht, wie man Dinge macht, aber ‚lange genug‘ bedeutet nicht, dass es dreißig Jahre sein müssen.“
Indem die Linux-Kernel-Community eine solche Reihe von Prozessen formell niederschreibt, versucht sie, jahrelangen, relativ impliziten Konsens und Konventionen in ein klar sichtbares und durchsetzbares System umzuwandeln. Jetzt, da die Größe und der Einfluss von Projekten die von gewöhnlicher Open-Source-Software bei weitem übertroffen haben, wird die Frage, wie ein Gleichgewicht zwischen der Achtung einzelner Beiträge und der Aufrechterhaltung der Stabilität technischer Richtungen hergestellt werden kann, zu einem Governance-Problem, mit dem sich Linux und sogar das gesamte Open-Source-Ökosystem auseinandersetzen müssen.