Repository-Metriken

Maintainer-Resilienz

Wie inspect.software Bus-Faktor, Konzentration und Breite der Beitragenden misst — ob ein Projekt den Verlust seines wichtigsten Maintainers übersteht. 7,2% des Index.

Methodik v1.13.0Aktualisiert 2026-07-18

Maintainer-Resilienz stellt die unbequeme Frage: Kann dieses Projekt den Verlust seiner wichtigsten Person überstehen? Das gemessene Muster — ein einzelner Maintainer, der im Wesentlichen die gesamte Arbeit trägt — ist der häufigste strukturelle Ausfallmodus in Open Source und bleibt in Commit-Zahlen und Stars unsichtbar.

  • Kategorie: Nachhaltigkeit & Governance (30% innerhalb der Kategorie)
  • Gewicht im Gesamtindex: 7,2%
  • Metrikschlüssel: maintainer_resilience
  • null, wenn die Liste der Beitragenden nicht verfügbar ist

Wie der Wert berechnet wird

KomponenteGewichtKriterien
Bus-Faktor54Bus-Faktor-Kurve aus v0.9.0, skaliert auf 54 Punkte
Commit-Verteilung22,5(1 − top contributor's share of commits) × 22.5
Breite der Beitragenden13,5min(13.5, contributors sampled × 1.35)
OpenSSF Scorecard: Contributors10Scorecard-Ergebnis 0–10, skaliert auf 10 Punkte

Der Bus-Faktor ist die kleinste Zahl von Beitragenden, die zusammen den Großteil der Arbeit leisten — die Zahl der Personen, deren Ausscheiden das Projekt zum Stillstand brächte.

Die Scorecard-Komponente misst beitragende Organisationen/Unternehmen — ein nützliches ergänzendes Signal institutioneller Resilienz. Sie bleibt zugleich Teil der Sicherheit und wird hier ausgeschlossen, wenn sie nicht verfügbar ist oder n/a meldet.

Warum die Kurve so geformt ist

Der Sprung von einem Bus-Faktor von 1 auf 2 (10 → 28 Punkte) ist der größte Einzelschritt der Methodik, weil er die größte reale Risikominderung ist: der Unterschied zwischen einem Projekt mit einem Single Point of Failure und einem ohne. Jenseits von 4–5 nimmt der Ertrag ab — sobald mehrere Personen die Arbeit wirklich teilen, ändert weiterer Zuwachs wenig.

Die Commit-Verteilung ergänzt den Bus-Faktor: Ein Projekt kann technisch fünf Beitragende haben, während eine Person 95% der Änderungen verfasst. Die Verteilungskomponente macht diese Konzentration sichtbar.

Das Ergebnis lesen

  • Ein niedriger Wert bei einem Projekt mit hoher Vitalität ist das klassische Solo-Maintainer-Profil: heute produktiv, morgen fragil.
  • Quer lesen mit der Trägerschaft — organisatorische Rückendeckung mindert das hier gemessene Risiko, beseitigt es aber nicht.
  • Die Daten der Beitragenden werden aus der öffentlichen Historie des Repositorys erhoben; Bots sind Teil des beobachtbaren Bestands, und die Eingaben werden im Bericht wiedergegeben.
  • Für die angezeigten zehn wichtigsten Beitragenden erfassen authentifizierte Scans außerdem den selbst veröffentlichten GitHub-Namen, Standort, das Unternehmen und öffentliche Organisationsmitgliedschaften in einer gebündelten Anfrage. Diese Anreicherung fließt nicht in die Bewertung ein und wird in öffentlichen API- und HTML-Berichten ausgeblendet; sie unterstützt interne Identitätsauflösung, ohne die Bus-Faktor-Berechnung zu verändern.

Den Wert verbessern

  • Review- und Merge-Rechte an mindestens eine weitere Person vergeben — den Bus-Faktor von 1 auf 2 zu heben ist der größte verfügbare Einzelgewinn.
  • Arbeit aktiv verteilen: Reviews und Releases über mehrere Maintainer leiten statt durch eine Person.
  • Wiederkehrende Beitragende zu Maintainern machen; Breite zählt, und die Pipeline beginnt bei der Community-Gesundheit.

Verwandt: Trägerschaft · Nachhaltigkeit & Governance

Von inspect.software veröffentlichte Ergebnisse sind Signale, keine Garantien — siehe wie sie zu lesen sind. Die vollständige Methodik ist versioniert und öffentlich: Methodik v1.13.0.