Research Notes: Geschützte Verantwortung in Software

Linux: Integration durch Maintainer

Die offizielle Entwicklungsdokumentation des Linux-Kernels beschreibt eine Hierarchie von Maintainern. Subsystem-Maintainer wählen und integrieren Patches für ihre Bereiche; Maintainer höherer Ebenen bitten Linus Torvalds, die ausgewählten Änderungen in das Mainline-Repository zu übernehmen. Nur Torvalds kann Patches in dieses Repository aufnehmen, während die Kette vertrauter Maintainer die Größe des Projekts handhabbar macht.

Das belegt einen begrenzten Punkt: Verteilte Beiträge beseitigen Integrationsverantwortung nicht. Der Kernel zeigt weder, dass eine Person jede Zeile prüft, noch dass sie das gesamte System im Kopf behält. Er zeigt eine Struktur, in der die Verantwortung für die Annahme von Arbeit ausdrücklich zugeordnet bleibt.

Redis und id Software: zusammenhängende Verantwortungsbereiche

Redis wurde von Salvatore Sanfilippo geschaffen, bekannt als antirez. Die Projektgeschichte dokumentiert diesen Ursprung und die spätere Entwicklung. Der Essay verwendet Redis als Beispiel für ein Werkzeug, dessen ursprüngliche Form das Urteil eines zusammenhängenden Entwurfs trägt — nicht als Behauptung, eine Person habe jede spätere Zeile geschrieben.

John Carmacks Engine-Arbeit bei id Software bietet ein verwandtes Beispiel aus einem kleinen Team mit klar getrennten Bereichen. Nicht alle Teammitglieder mussten Carmacks technisches Bild teilen. Entscheidend war, dass er die Engine verantwortlich weiterentwickeln konnte, ohne jede technische Entscheidung zum Gegenstand eines Abstimmungsprozesses zu machen. David Kushners Masters of Doom dokumentiert die beteiligten Personen und ihre Rollen.

Was diese Fälle nicht belegen

Sie belegen nicht, dass bahnbrechende Software grundsätzlich von Einzelpersonen stammt, dass große Teams keine ausgezeichnete Software hervorbringen können oder dass jedes Projekt einen einzelnen Herrscher braucht. Der Storypoint-Gegensatz im Essay ist ein hypothetischer Vergleich, kein Bericht über id Softwares tatsächlichen Arbeitsprozess.

Die Fälle stützen den engeren Mechanismus geschützter Verantwortung: klare Grenzen, innerhalb derer eine Person oder eine kleine Gruppe einen bedeutsamen zusammenhängenden Bereich verstehen, entscheiden und verantworten kann.

Quellen

• Linux-Kernel-Entwicklungsgemeinschaft, „How the development process works“, insbesondere Abschnitte 2.2 und 2.3.
• Redis-Quellrepository, Projektgeschichte und gegenwärtige Entwicklung.
• David Kushner, Masters of Doom: How Two Guys Created an Empire and Transformed Pop Culture, 2003.