- Der Bus Factor ist die Mindestzahl an Personen, deren Ausfall ein Produkt stoppt. Bei bekannten Open-Source-Projekten liegt er meist bei eins oder zwei.
- Aus der Git-Historie lässt er sich mit Bordmitteln abschätzen: Commit-Verteilung pro Autor und pro Datei, ohne zusätzliches Werkzeug.
- Bei Bewertung, Due Diligence und Roadmap-Planung ist ein niedriger Bus Factor ein Preisfaktor, kein Stilfehler.
- Pairing, Reviews, Dokumentation und KI-gestütztes Code-Verständnis senken ihn. KI verkürzt dabei die Einstiegszeit, ersetzt aber nicht das Urteil.
1. Was der Bus Factor misst
Der Begriff entstand 1994 in einer Diskussion auf der Mailingliste der Python-Community. Die Sorge damals: Wie abhängig ist das noch junge Projekt von seinem Erfinder Guido van Rossum, und was passiert, wenn er wegfällt? Aus dieser Frage wurde eine Metrik, die je nach Autor auch "Truck Factor" oder "Lottery Factor" heißt, je nachdem, welches Unglück sich jemand vorstellt.
Formal ist der Bus Factor die kleinste Anzahl an Personen, deren gleichzeitiger Ausfall ein Projekt handlungsunfähig macht. Nicht Personalabbau im Allgemeinen zählt, sondern der Verlust von Wissen und Zugriff, das sonst niemand hat. Ein Team aus zehn Entwicklern kann trotzdem einen Bus Factor von eins haben, wenn nur eine einzige Person das Abrechnungssystem wirklich versteht.
Wie verbreitet das ist, zeigt eine Untersuchung von 133 populären GitHub-Projekten: 46 Prozent hatten einen Bus Factor von eins, weitere 28 Prozent einen von zwei. Rund drei Viertel bekannter Open-Source-Projekte hingen also an ein oder zwei Personen. Kommerzielle Software, die nie systematisch geprüft wird, dürfte nicht besser dastehen.
Bekanntestes Beispiel: Vor der Heartbleed-Lücke 2014 pflegten zwei ehrenamtliche Entwickler die Verschlüsselungsbibliothek OpenSSL, die zu dem Zeitpunkt rund zwei Drittel aller Webserver absicherte, bei etwa 2.000 US-Dollar Spenden pro Jahr. Nach dem Vorfall finanzierte die Linux Foundation über ihre Core Infrastructure Initiative bezahlte Stellen, und das Projekt wuchs bis Ende desselben Jahres auf 15 Mitwirkende.
2. Wie man ihn aus der Git-Historie misst
Ein Bus Factor lässt sich nicht auf die Kommastelle berechnen, aber aus der Git-Historie grob und ohne zusätzliches Werkzeug abschätzen.
Beitragskonzentration über das ganze Repository
git shortlog -sn --all zählt Commits pro Autor für das gesamte Repository. Das ist eine grobe erste Näherung: Wer zehnmal so viele Commits hat wie jeder andere, trägt vermutlich auch deutlich mehr Wissen. Die Zahl täuscht aber, wenn eine Person viele kleine Formatierungs-Commits macht und eine andere selten, aber genau an der kritischsten Stelle.
Autoren je Datei oder Modul
Genauer wird es auf Datei- oder Modulebene: git log --format='%an' -- pfad/datei | sort | uniq -c | sort -rn zeigt, wer an einer bestimmten Datei tatsächlich gearbeitet hat. Wiederholt für die Kerndateien eines Produkts, etwa das Zahlungsmodul oder den Authentifizierungs-Code, ergibt das ein Bild: Stehen dort immer dieselben ein oder zwei Namen, ist das ein Bus Factor von eins für genau den Teil des Systems, der am meisten wehtut, wenn er ausfällt. Diese Wissenskonzentration ist auch Teil dessen, was technische Schulden im Betrieb so teuer macht: Niemand traut sich mehr an den Code, der am dringendsten Pflege bräuchte.
Aus der Praxis: Historische Commit-Zahlen überschätzen den Bus Factor, wenn eine Person das Projekt längst verlassen hat. Sinnvoller ist ein Zeitfenster: git log --since="12 months ago" --format='%an' -- pfad/ | sort | uniq -c | sort -rn zeigt, wer eine Datei aktuell trägt, nicht wer sie einmal geschrieben hat. Für die genauere, aber langsamere Antwort auf Zeilenebene liefert git blame die aktuellen Autoren jeder einzelnen Zeile.
| Bus Factor | Risiko | Typische Situation |
|---|---|---|
| 1 | Kritisch | Eine Person hält Wissen, Zugriff oder beides allein |
| 2-3 | Erhöht | Wissen liegt bei wenigen, Rotation fehlt |
| 4+ | Tragfähig | Mehrere Personen könnten jeden kritischen Teil übernehmen |
3. Was er für Bewertung, Diligence und Planung bedeutet
Bewertung und Due Diligence
Für ein internes Team ist ein niedriger Bus Factor unangenehm. Für eine Bewertung, eine Fusion oder eine Investitionsentscheidung ist er ein Preisfaktor. Wer ein Unternehmen kauft oder finanziert, das an einer einzigen Person hängt, übernimmt ein Risiko, das sich nicht im Bilanzbericht zeigt, aber im Kaufpreis landet. In der Due Diligence gehört die Frage, wer diesen Code wirklich versteht, deshalb neben Lizenzprüfung und Testabdeckung ins Standardprogramm, nicht als Kür, sondern als Pflichtpunkt.
Planung und Roadmap
Auch ohne Übernahme zeigt sich das Risiko in der Roadmap. Ein Release, der an eine Person gebunden ist, verschiebt sich, sobald diese Person krank wird, kündigt oder schlicht Urlaub macht. Was in der Planung wie ein Fixdatum aussieht, ist in Wahrheit eine Wette auf die Verfügbarkeit einer einzelnen Person. Das trifft Softwareentwicklung besonders dann, wenn ein Produkt über Jahre gewachsen ist und Entscheidungen von damals heute niemand mehr einordnen kann.
4. Wie man ihn senkt
Der Bus Factor sinkt nicht durch Zufall, sondern durch Praktiken, die alle denselben Effekt haben: Wissen verlässt einen einzelnen Kopf und wird geteilt.
Pairing und Reviews als Wissenstransfer
Pair Programming an kritischen Stellen ist der direkteste Weg, weil zwei Personen gleichzeitig denselben Code verstehen. Wo Pairing zu teuer ist, leistet ein Code Review einen Teil der Arbeit, vorausgesetzt, der Reviewer liest wirklich und fragt nach, statt nur zuzustimmen. Rotierende Zuständigkeit für Module verhindert, dass sich Wissen über Jahre bei einer Person sammelt. Wenn intern niemand die Kapazität hat, diese Rolle dauerhaft zu übernehmen, deckt ein Fractional CTO genau diese Lücke, von außen, aber mit Verantwortung.
Dokumentation, die tatsächlich gelesen wird
Vollständige Dokumentation liest niemand. Wirksam ist die kurze Entscheidungsnotiz an der Stelle, wo eine Lösung nicht offensichtlich ist: warum diese Bibliothek, warum dieser Workaround, welche Annahme dahintersteckt. Genau dieses Wissen fehlt beim Onboarding am meisten, weil es im Code selbst nicht sichtbar ist.
Was KI-gestütztes Code-Verständnis leisten kann und wo es endet
Ein Coding-Agent kann eine unbekannte Codebase in Stunden statt Wochen erschließen: Aufrufketten nachverfolgen, Muster erkennen, eine erste Einordnung liefern. Das senkt die Zeit, bis eine zweite Person produktiv wird, spürbar. Was ein Agent nicht liefert, ist das Urteil, ob eine gefundene Struktur Absicht oder Unfall war. Diese Einordnung bleibt Erfahrungssache und genau die Grenze, an der auch automatisierte Analyse endet, wie Was KI in einer Codebase findet, und was nicht zeigt. Ein KI-Workshop für das bestehende Team baut diese Fähigkeit intern auf, ein Interim CTO bringt sie sofort mit, wenn dafür keine Zeit bleibt.
Fazit
Der Bus Factor ist keine akademische Zahl, sondern eine Frage, die sich mit Bordmitteln beantworten lässt: Wer hält dieses Produkt tatsächlich am Laufen, und was passiert, wenn diese Person morgen nicht mehr verfügbar ist? Wer die Antwort nicht kennt, plant auf einer Annahme, die niemand geprüft hat.
Vor einem Release, einer Investitionsentscheidung oder einer Vorstandsrunde lohnt sich ein genauerer Blick auf genau diese Konzentration. Wissenskonzentration ist Teil des Samplings bei der Codebase Decision in drei Tagen, neben Architektur, Testabdeckung und den Stellen, an denen ein Refactor mehr kostet als ein Neubau.