Repository-Metriken

Verwaisung

Wie inspect.software entscheidet, dass ein Projekt ohne Pflege zurückblieb — warum Stille allein nie der Befund ist, was als unerfüllte Pflicht gilt und was die Bewertung zurückhält.

Methodik v1.13.0Aktualisiert 2026-07-21

Jedes Werkzeug in diesem Feld beantwortet die Frage mit einer Zahl — Tagen seit dem letzten Commit — und jedes irrt sich bei denselben Projekten. Eine kleine, vollständige Bibliothek, die seit drei Jahren keine Änderung brauchte, ist nicht verwaist. Sie ist fertig. Sie für tot zu erklären kostet ein Verzeichnis seine Glaubwürdigkeit genau bei der Software, die das meiste Vertrauen verdient.

Stille ist hier deshalb nie der Befund. Die Bewertung beruht auf einem anderen Satz:

Verwaisung ist eine unerfüllte Pflicht, nicht die Abwesenheit von Lärm.

Ein Projekt geht Pflichten ein, wenn Arbeit von außen eintrifft — ein Pull Request, der Review will, ein Issue, das eine Antwort will, ein veröffentlichter Fix für eine Schwachstelle in etwas, das es ausliefert. Ein stilles Projekt ohne solche Forderungen schuldet niemandem etwas und kann niemanden im Stich lassen. Ein stilles Projekt mit fünfzehn Pull Requests, die seit zwei Jahren niemand angesehen hat, und einem jahrealten Advisory, dessen Patch in derselben Woche erschien, ruht nicht.

  • Kategorie: Vitalität (0% innerhalb der Kategorie)
  • Wirkung: ein Multiplikator auf die Gesamtbewertung, in den schwersten Zuständen zusätzlich eine Obergrenze
  • Metrik-Schlüssel: abandonment

Was die Bewertung liest

Erklärt. Die Betreuung hat es selbst gesagt. GitHubs Archiv-Flag oder eine Registry-Deprecation über alle Pakete, die das Repository veröffentlicht. Nichts wird gefolgert und nichts muss bestätigt werden — das Verzeichnis zitiert seinen Gegenstand.

Dürre. Lange kein menschlicher Commit. Bewusst nicht die Push-Aktualität des Repositorys, die den Versionssprung eines Abhängigkeits-Bots als Lebenszeichen zählt: Projekte, deren einzige Aktivität eines Jahres automatisierte Updates waren, melden einen letzten Push von wenigen Tagen. Die Autorschaft wird pro Commit gelesen, automatisierte Autoren werden ausgeschlossen. Dürre ist eine notwendige Bedingung und für sich allein nie ein Befund.

Unerfüllte Pflichten. Die bestätigenden Signale — unbeantwortete Pull Requests, unbeantwortete Issues, ein veröffentlichter Fix, der nicht eingespielt wurde, stehende Releases, defekte Continuous Integration, ein abwesender einziger Betreuer, oder OpenSSF Scorecard, das das Projekt unabhängig als ungepflegt meldet. Jedes ist eine Pflicht, der das Projekt sichtbar nicht nachkommt.

Schutzgründe. Belege, dass noch jemand da ist oder dass nichts verlangt wird: eine Betreuung, die noch antwortet, nichts Offenes zu beantworten, ein Release innerhalb des Jahres, keine betroffene Abhängigkeit. Zwei Schutzgründe halten das Ergebnis unterhalb eines Befundes, wie viele Pflichtsignale auch ausgelöst haben, denn beide Lesarten — jemand antwortet und niemand fragt — erklären die Stille vollständig.

Was die Zustände bedeuten

ZustandBedeutung
maintainedMenschliche Arbeit ist aktuell; kein Befund
unverifiedDie erhobenen Belege können die Frage nicht beantworten
dormantStill, aber erklärt — durch Schutzgründe gehalten oder nichts geschuldet
abandonedDürre plus unerfüllte Pflichten, unwidersprochen
declaredDie Betreuung hat archiviert oder die Pakete als veraltet markiert

Alles, was die Daten nicht beantworten können, ist unverified und kostet das Repository nichts. Ein nicht authentifizierter Scan liest weder Commit-Stichprobe noch Tracker-Warteschlangen und kann zu keinem Schluss kommen — festgehalten als Abwesenheit von Belegen, nicht als Beleg für Abwesenheit.

Das Ergebnis lesen

  • Der Hinweis nennt seine Belege. Die Dauer der Dürre steht neben den Pflichten, damit der Befund geprüft und nicht geglaubt werden muss.
  • Die Dürre kann eine Untergrenze sein. Die Commit-Stichprobe ist begrenzt; enthält sie gar keinen menschlichen Commit, liegt die wahre Lücke vor dem Fenster und wird als mindestens so lang berichtet.
  • Ein Befund ist kein Urteil über die Betreuenden. Projekte werden aus gewöhnlichen Gründen aufgegeben — Stellen wechseln, Interesse wandert, Menschen erkranken. Das Verzeichnis hält fest, was ein Nutzer vorfände, nicht warum.
  • Automatisierung rettet ein Projekt hier nicht und verurteilt es auch nicht. Bot-Commits sind aus der Dürre-Rechnung ausgeschlossen, sodass ein von einem Abhängigkeits-Bot warm gehaltenes Repository so still liest, wie es tatsächlich ist. Starke Automatisierung neben aktueller menschlicher Arbeit ist überhaupt kein Signal — siehe Entwicklungsaktivität.

Den Wert verbessern

  • Beantworten Sie Offenes oder schließen Sie es. Eine unbeantwortete Warteschlange ist der stärkste einzelne Beitrag zu einem Befund.
  • Spielen Sie veröffentlichte Sicherheitsfixes für Abhängigkeiten ein oder legen Sie dar, warum sie nicht zutreffen.
  • Ist das Projekt fertig statt verwaist, sagen Sie es: Archivieren oder das Markieren der Pakete als veraltet ersetzt eine Folgerung durch eine Tatsache.

Verwandt: Entwicklungsaktivität · Betreuer-Resilienz · Vitalität

Wo dies festgestellt wurde

280 Repositories im öffentlichen Register tragen diesen Befund.

Alle 280 im Katalog ansehen

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.