GitHub-Repo-Risikoscore

Repo einfügen, Risikoscore aus Lizenz, Commit-Aktivität, Contributors und Sternen bekommen — mit optionalen Tiefenchecks für Security Advisories, Bus-Faktor und Community-Health — bevor ein Entwickler ein Ja oder Nein hört.

Maschinell aus dem Englischen übersetzt, vom Autor geprüft. Englisches Original

Ein Entwickler will ein GitHub-Repo in den Stack ziehen. Bevor die eigentliche Prüfung beginnt, braucht es einen schnellen ersten Eindruck: Gibt es überhaupt eine nutzbare Lizenz, pflegt das noch jemand, und würde das Projekt überleben, wenn der einzige Maintainer geht.

Was berechnet wird

URL oder einfach owner/repo eingeben — auch ein Link direkt aus dem Issues- oder Pull-Requests-Tab funktioniert, der zusätzliche Pfad wird ignoriert. Das Tool ruft die GitHub-API direkt aus dem Browser auf — nichts läuft über meinen Server — und holt automatisch sechs Signale, alle kostenlos in derselben Handvoll Requests:

Lizenz — ob GitHub überhaupt eine OSI-artige FOSS-Lizenz erkannt hat. Keine Lizenz heißt im Zweifel “alle Rechte vorbehalten”, egal was im README steht.
Letzter Commit auf dem Default-Branch — Aktualität als Indikator, ob das Projekt noch lebt.
Contributors — die öffentliche GitHub-API kennt keine “Maintainer”-Rolle, deshalb ist die Contributor-Zahl der beste verfügbare Proxy für den Bus-Faktor. Ein Repo mit einem Contributor ist einen Rücktritt von unmaintained entfernt.
Sterne und Forks — für sich genommen schwache Signale, aber Forks filtern reines Bookmarking raus: Wer forkt, baut tatsächlich auf dem Code auf.
Repo-Alter — nur als Kontext, nicht bewertet. Alt kann stabil oder verwaist heißen, jung kann frisch oder unreif heißen — hier gibt es keine saubere “gut”-Richtung.

Jedes bewertete Signal wird gewichtet und zu einem Score von 0–100 kombiniert. Eine fehlende oder keine FOSS-Lizenz deckelt den Score hart, egal wie gut die anderen Werte aussehen — ein populäres, aktiv gepflegtes Repo ohne Lizenz ist trotzdem ein rechtliches Problem, eher ein größeres, weil alle davon ausgehen, dass es schon passt.

Optionale Tiefenchecks

Vier weitere Signale stecken hinter Checkboxen, standardmäßig aus, weil jedes einen zusätzlichen GitHub-API-Call gegen das anonyme 60/Stunde-Budget kostet:

Community-Profil-Health — GitHubs eigener Summenscore dafür, ob README, LICENSE, CONTRIBUTING und eine Security-Policy existieren.
Öffentliche Security Advisories — veröffentlichte GHSA-Einträge zum Repo. Eine öffentliche kritische Advisory deckelt den Score genauso wie eine fehlende Lizenz.
Bus-Faktor — der Commit-Anteil des Top-Contributors, aus den Commit-Stats statt aus der rohen Contributor-Liste. Ein Repo kann “12 Contributors” zeigen und trotzdem zu 95 % von einer Person stammen; das fängt genau das ab.
Commit-Trend — Commit-Volumen der letzten 12 Wochen, um nachhaltige Aktivität von einem einzelnen Commit zu unterscheiden, der ein sonst totes Repo kurz vor der Prüfung wiederbelebt hat.

Wird eine dieser Checkboxen aktiviert, fließt sie in den Score ein; bleiben sie aus, geben die sechs Kernsignale trotzdem einen brauchbaren Eindruck.

Was es nicht macht

Es liest keinen Code, schaut nicht in den Issue-Tracker und bewertet nicht, ob die Lizenzbedingungen zum eigenen Anwendungsfall passen (GPL in einem proprietären Produkt ist ein anderes Thema als GPL in einem internen Tool). Anonyme GitHub-API-Aufrufe sind auf 60 Requests/Stunde pro IP begrenzt; bei Bedarf einen Personal Access Token einfügen (für öffentliche Repos ohne Scopes) — der bleibt im Browser und geht direkt an api.github.com.

Der Score ist ein Filter für die offensichtlichen Neins, kein Ersatz dafür, Lizenz und Commit-Historie selbst zu lesen.