Konzepte

Der Gesundheitsindex

Wie inspect.software den 1–100-Index für Open-Source-Gesundheit berechnet — Komponenten, Metriken, gewichtete Kategorien und die Regeln für fehlende Daten.

Methodik v1.13.0Aktualisiert 2026-07-13

Jedes Repository im öffentlichen Register trägt einen Gesundheitsindex: eine einzelne ganze Zahl zwischen 1 und 100, die öffentlich sichtbare Engineering-, Pflege-, Sicherheits- und Governance-Praxis zusammenfasst. Der Index existiert, damit eine Bibliothek auf einen Blick mit ihren Alternativen verglichen werden kann — er ist jedoch die Spitze einer vollständig transparenten Hierarchie, nie eine Blackbox.

Signale, keine Garantien. Ein hoher Index spiegelt öffentlich sichtbare gute Praxis wider. Er ist kein Code-Audit und keine Sicherheitsgarantie — siehe wie die Ergebnisse zu lesen sind.

Die dreistufige Hierarchie

Der Index wird über drei dokumentierte Ebenen aggregiert:

  1. Komponenten — einzelne beobachtbare Fakten (eine Lizenzdatei existiert, das jüngste Release erschien vor 40 Tagen, der Bus-Faktor beträgt 3). Jede Komponente trägt ein festes Gewicht innerhalb ihrer Metrik.
  2. Metriken — gewichtete Summen von Komponenten, jede eine ganze Zahl in 1–100. Beispiele: Entwicklungsaktivität, Maintainer-Resilienz, Sicherheitslage.
  3. Kategorien — gewichtete Mittel ihrer Metriken, ebenfalls in 1–100. Die fünf gewichteten Kategorien sind Vitalität, Community & Verbreitung, Nachhaltigkeit & Governance, Engineering-Qualität und Sicherheit. Eine sechste, KI-Bereitschaft, ist ein unabhängiges Badge mit Gewicht 0.

Der gesamte Gesundheitsindex ist das gewichtete Mittel der verfügbaren Kategorien:

KategorieGewicht im Gesamtindex
Nachhaltigkeit & Governance24%
Vitalität22%
Engineering-Qualität20%
Community & Verbreitung18%
Sicherheit16%
KI-Bereitschaft0% — unabhängiges Badge

Das effektive Gewicht einer Metrik im Gesamtindex ist Kategoriegewicht × Gewicht innerhalb der Kategorie. Jeder Bericht zeigt diese Zahl auf jeder Metrikkarte, und jeder veröffentlichte Wert wird einer von fünf Bewertungsstufen zugeordnet.

Fehlende Daten sind niemals eine Null

Sind die zugrunde liegenden Daten einer Komponente nicht verfügbar — eine Registry veröffentlicht keine Download-Zahlen, die Liste der Beitragenden lässt sich nicht erheben — wird die Komponente ausgeschlossen und die verbleibenden Gewichte renormalisiert. Dieselbe Regel gilt eine Ebene höher: Eine Metrik ohne Daten wird null, und ihre Kategorie verteilt das Gewicht um; eine Kategorie ohne bewertbare Metrik entfällt aus dem Gesamtindex.

Diese Regel ist zentral für die Fairness. Ein Projekt wird nur an dem gemessen, was tatsächlich beobachtbar ist, und Abwesenheit von Evidenz wird als Abwesenheit berichtet — das Feld note der Metrik verzeichnet jede Renormalisierung, sodass stets erkennbar bleibt, was gemessen wurde und was nicht.

Einen Bericht lesen

  • Das Profil lesen, nicht nur die Zahl. Eine 74 aus ausgewogenen Kategorien ist etwas anderes als eine 74, die einen Sicherheitswert von 25 verdeckt. Das Radardiagramm des Berichts macht Spitzen-und-Krater- Profile sofort sichtbar.
  • Die Stufen prüfen. Werte werden fünf standardisierten Stufen von excellent bis critical zugeordnet; die Stufengrenzen sind Teil der versionierten Methodik.
  • Alles nachrechnen. Jede Metrik gibt ihre Eingaben und die Punkte je Komponente im Bericht wieder, sodass jeder veröffentlichte Wert aus dem data-Abschnitt des JSON-Berichts von Hand verifiziert werden kann.

Versionierung

Formeln, Gewichte und Stufengrenzen werden als Ganzes versioniert. Jede Änderung erhöht die in jedem Bericht verzeichnete Metrikversion, und die vollständige Historie ist öffentlich — siehe Methodikversionen. Teile der Methodik können je Scan abgeschaltet werden; der Bericht dokumentiert dann genau, was deaktiviert war — siehe Scan-Konfiguration.

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.