Der Linux-Kernel, die Basis für zahlreiche offene Betriebssysteme, ist eine offene Entwicklung. Jeder, der will, kann den Code herunterladen und ihn verbessern und erweitern. Sollen eigene Umsetzungen in das Hauptprojekt einfließen, entscheidet eine höhere Instanz: Die sogenannten Subsystem-Maintainer. Sie prüfen eingereichten Code und geben ihn an die "Chefetage" rund um Linus Torvalds weiter.

Doch dieses System hat ein Problem, erklärt nun Daniel Vetter, der selbst ein Maintainer ist. Die Kontrolleure seien zunehmend von der Arbeitslast überfordert, was indirekt zu Qualitätsproblemen führen könnte. Die Maintainer selbst kommen aus den Reihen der Nutzer, die sich zuvor schon aktiv und erfolgreich an der Weiterentwicklung von Linux beteiligt haben. Es handelt sich um Entwickler, die qualitativ hochwertigen Code schreiben,

Maintainer auf dem Weg zum "Flaschenhals"

Dass diese nun immer stärker damit befasst sind, Einreichungen zu prüfen, führt dazu, dass sie selber immer weniger beisteuern, so Vetters Analyse. Grund ist, dass der Kernel immer umfangreicher wird und dementsprechend auch mehr Verbesserungen und Patches eingereicht werden.

Seine Beobachtungen basieren auf einer Auswertung von Pull-Requests für den Linux-Kernel. Würde man die aktuelle Entwicklung "naiv extrapolieren", wären im Jahr 2025 die meisten Kernel-Maintainer nur noch ein "Flaschenhals", der die Weiterentwicklung verzögert, weil man nur noch anderer Leute Einreichungen prüft und gleichzeitig selber nichts mehr produziert.

Wenige Checks für Maintainer-Code

Zudem will Vetter ein weiteres Problem identifiziert haben. Schreibt doch einmal ein Maintainer selbst neuen Code, so werde dieser offenbar nicht so genau überprüft, wie Commits von nicht privilegierten Entwicklern. Mitunter fließt ihr Code sogar ganz ohne Prüfung ein, was sich ebenfalls negativ auf die Qualität auswirken kann.

Die Situation unterscheide sich aber von Subsystem zu Subsystem. Im Segment für Grafiktreiber werden demnach 83 Prozent der Maintainer-Commits von direkten Kollegen gecheckt. Beim Subsystem für Netzwerk-Komponenten seien es hingegen nur neun Prozent. Insgesamt, bezogen auf das gesamte Kernel-Projekt, würde die Anzahl der Überprüfungen aber steigen.

Für beide Situationen hat Vetter auch einen Lösungsvorschlag. Er regt an, dass Maintainer andere Entwickler zu Junior-Maintainer ausbilden, um die Arbeitslast besser zu verteilen. Das würde häufigere Codechecks ermöglichen und mehr Zeit schaffen, damit Maintainer selber wieder mehr zur Entwicklung beitragen können.