Entwicklungsaktivität beantwortet die erste Frage, die an eine Open-Source-Abhängigkeit gestellt wird: Wird aktiv Code geschrieben? Die Metrik liest die Push- und Commit-Historie des Repositorys über das letzte Jahr und belohnt Aktualität, Rhythmus und Volumen — in dieser Reihenfolge der Gewichtung.
- Kategorie: Vitalität (60% innerhalb der Kategorie)
- Gewicht im Gesamtindex: 13,2% — die gewichtigste einzelne Repository-Metrik
- Metrikschlüssel:
development_activity
Wie der Wert berechnet wird
| Komponente | Gewicht | Kriterien |
|---|---|---|
| Push-Aktualität | 36 | dieselben Schwellwerte wie v0.9.0, skaliert auf 36 Punkte |
| Commit-Rhythmus | 36 | Anteil der letzten 52 Wochen mit mindestens einem Commit |
| Commit-Volumen | 18 | logarithmisch skaliert; rund 100 Commits pro Jahr bringen die volle Punktzahl |
| OpenSSF Scorecard: Maintained | 10 | Scorecard-Ergebnis 0–10, skaliert auf 10 Punkte |
Der Wert ist die gewichtete Summe, gerundet und auf 1–100 begrenzt, und wird einer Bewertungsstufe zugeordnet. Komponenten ohne Daten werden ausgeschlossen und die verbleibenden Gewichte renormalisiert (siehe der Gesundheitsindex).
Maintained ist geteilte Evidenz, kein Ersatz für die eigene Commit-Historie des Scanners: Es bleibt zugleich eine vollwertige Komponente der Sicherheitslage. Ist Scorecard nicht verfügbar oder markiert den Check als n/a, wird diese Komponente ausgeschlossen.
Warum der Rhythmus das Volumen überwiegt
Ein Repository mit einem Commit in jeder Woche eines Jahres ist verlässlichere Wartungsevidenz als dieselbe Zahl von Commits in einem einzigen Schub. Der Rhythmus misst anhaltende Aufmerksamkeit; das Volumen ist gerade deshalb logarithmisch skaliert, damit sich die Commit-Zahl nicht zu einem hohen Wert aufblähen lässt — der Unterschied zwischen 100 und 1.000 Commits pro Jahr ist mit Absicht klein.
Das Ergebnis lesen
- Die Aktualität dominiert kurzfristige Veränderung. Ein Projekt, das sechs Monate pausiert, verliert zuerst die Aktualitätskomponente; der Rhythmus zerfällt anschließend, während sich inaktive Wochen ansammeln.
- Wirklich fertige Software existiert. Eine stabile, funktional vollständige Bibliothek kann sich hier niedrig lesen und dennoch sicher nutzbar bleiben — deshalb ist die Entwicklungsaktivität eine Metrik innerhalb eines gewichteten Index, kein Urteil. Quer zu lesen mit Release-Disziplin und Reaktionsfähigkeit.
- Monorepos und Spiegel: Aktivität wird aus dem geprüften Repository gelesen; Arbeit, die in einem anderen Repository stattfindet, zählt nicht.
Den Wert verbessern
- Gepflegte Arbeit kontinuierlich mergen, statt langlebige Branches aufzustauen.
- Mindestens einen wöchentlichen Herzschlag echter Änderungen halten, wo das Projekt tatsächlich Wartung braucht — Abhängigkeitsaktualisierungen und Bugfixes zählen.
- Leere Aktivität vermeiden: Die logarithmische Skala des Volumens macht synthetische Commit-Inflation nahezu wertlos.
Verwandt: Release-Disziplin · Vitalität