Vitalität beantwortet die grundlegendste Frage zu einem Open-Source-Projekt: Lebt es? Code, der sich nicht mehr bewegt, nimmt keine Fehlerberichte, Sicherheitskorrekturen und Kompatibilitätsarbeit mehr auf — und die Abhängigkeit von einem ruhenden Projekt ist eines der häufigsten und am wenigsten sichtbaren Risiken in einer Software-Lieferkette.
Die Kategorie trägt 22% des gesamten Gesundheitsindex, übertroffen nur von Nachhaltigkeit & Governance.
Metriken in dieser Kategorie
| Metrik | Gewicht in der Kategorie | Gewicht im Gesamtindex |
|---|---|---|
| Entwicklungsaktivität | 60% | 13,2% |
| Release-Disziplin | 40% | 8,8% |
Entwicklungsaktivität misst, ob Code geschrieben wird: Aktualität des letzten Push, wöchentliche Commit-Kadenz über das letzte Jahr und Commit-Volumen. Release-Disziplin misst, ob diese Arbeit die Nutzer tatsächlich als versionierte Releases erreicht — Aktualität und Kadenz der veröffentlichten Releases.
Die Scorecard-Prüfungen Maintained und Signed-Releases dienen in diesen beiden Metriken zugleich als geteilte Evidenz. Damit dürfen beobachtbare Pflege und Release-Herkunft bewusst sowohl Vitalität als auch Sicherheit beeinflussen, mit unterschiedlichen Gewichten.
Die Trennung ist Absicht. Ein Repository kann ständige Commits zeigen und doch nie ein Release schneiden, das Nutzer übernehmen können; ein anderes kann ordentliche Quartals-Releases aus einem wenig frequentierten Default-Branch veröffentlichen. Gesunde Projekte tun beides, und die Kategorie belohnt genau diese Kombination.
Den Kategoriewert lesen
- Eine hohe Vitalität bei schwacher Governance kennzeichnet oft ein schnell voranschreitendes Projekt, das von einer einzigen Person getragen wird — gegenzuprüfen mit Maintainer-Resilienz.
- Eine niedrige Vitalität bei einer ausgereiften Bibliothek ist nicht automatisch fatal: Manche grundlegenden Pakete sind tatsächlich fertig und ändern sich selten. Die Kategorie berichtet beobachtbare Bewegung; das Urteil, ob Bewegung erforderlich ist, liegt beim Leser.
- Sind keine Release-Daten verfügbar, wird die Release-Disziplin
null, und die Kategorie renormalisiert allein auf die Entwicklungsaktivität — die Anmerkungen des Berichts weisen dies aus (siehe der Gesundheitsindex).
Vitalität verbessern
- Den Default-Branch in Bewegung halten: gepflegte Arbeit regelmäßig mergen, statt Änderungen über Monate anzusammeln.
- Versionierte Releases in einer vorhersehbaren Kadenz veröffentlichen, auch bei kleinen Änderungen; Aktualität und Rhythmus zählen beide.
- Befindet sich ein Projekt absichtlich im Wartungsmodus, sollte dies im README stehen — das Register kann Absichten nicht lesen, nachgelagerte Nutzer aber schon.
Verwandt: Bewertungsstufen · Methodikversionen