Ein Repository ist nicht einfach „ein Projekt“. Es baut etwas, und was es baut, entscheidet darüber, welche Praktiken vernünftigerweise von ihm zu erwarten sind. Von einer veröffentlichten Bibliothek wird erwartet, dass sie keine Lockdatei einträgt — die darin festgeschriebenen Versionen ignoriert jeder, der sie installiert. Von der Anwendung daneben im Katalog wird das Gegenteil erwartet, denn die von ihr festgeschriebenen Versionen sind genau das, was ausgeliefert wird. Beide nach einer Regel zu beurteilen heißt, eine von beiden falsch zu lesen.
Bis Metrik-Version 2.3.0 stand ein einziger Näherungswert für diese Frage: Veröffentlicht das Repository ein Paket in einer Registry? Damit liest sich jedes Kommandozeilenwerkzeug auf PyPI als Bibliothek, und jede Anwendung, die nebenbei ein Hilfspaket ausliefert, ebenso.
Jede Lesart, die die Belege stützen
Die Klassifikation ist mehrwertig. Software, die zugleich veröffentlichte Bibliothek und ausführbares Werkzeug ist, ist der Normalfall und kein aufzulösender Widerspruch: ripgrep ist Crate und Binary, esbuild ist npm-Paket und ausführbare Datei. Ein Repository behält daher jede Lesart, die seine Belege stützen.
Das Vokabular ist ein zweistufiger Baum. Die oberste Ebene beantwortet die Frage, auf die es ankommt — wie die Software konsumiert wird —, und ein Repository kann mehr als einen Zweig tragen:
| Oberste Ebene | Was dadurch erwartbar wird |
|---|---|
| Bibliothek — als Code eingebunden | Eine stabile Schnittstelle, ein Changelog, eine Versionierung, auf die sich andere Software stützen kann |
| Anwendung — als Programm ausgeführt | Festgeschriebene Abhängigkeiten, saubere Auslieferung und Konfiguration |
| Host-Erweiterung — in einen Host installiert | Der Host gibt Vertrauensmodell und Release-Takt vor |
| Notebook | Nichts davon — es wird von einem Menschen gelesen und ausgeführt, von nichts importiert und nirgendwo installiert |
Wo beides zutrifft, gilt beides: Ein Hybrid schuldet die Pflichten jeder Lesart, die er trägt, nie die nachsichtigste davon.
Die Untertypen
Untertypen gibt es nur dort, wo die feinere Antwort ändert, was zu erwarten ist: die Oberflächenmodalität einer Anwendung, oder die Host-Klasse, von der eine Erweiterung ihre Vertrauensfläche erbt.
| Anwendung | Host-Erweiterung |
|---|---|
| Kommandozeilenwerkzeug | Plugin |
| Terminal-Oberfläche | Browser-Erweiterung |
| Desktop | Editor-Erweiterung |
| Mobil | Theme |
| Weboberfläche | |
| Netzwerkdienst | |
| Chatbot | |
| MCP-Server |
Bibliothek hat absichtlich keine Untertypen. Frühere Fassungen unterschieden Framework, SDK, API-Client, Middleware und Treiber — und diese Grenzen existieren nicht: axios ist API-Client und Bibliothek, flask ist Framework und Bibliothek — eine Frage ohne richtige Antwort. Womit eine Bibliothek sich verbindet, wird andernorts als Integrationsfakt festgehalten, nicht hier.
Die Antwort darf auf der obersten Ebene stehen bleiben. Ein Cargo-Binary-Target und Gos cmd/-Layout beweisen, dass das Repository eine ausführbare Datei baut — nicht, ob sie ein Kommandozeilenwerkzeug oder ein Server ist. Ein solches Repository wird schlicht als Anwendung klassifiziert und erhält den Untertyp erst, wenn eigene Belege dafür vorliegen. Eine allgemeine, belegte Antwort schlägt eine spezifische, die geraten wäre.
Wie die Antwort zustande kommt
Belege sind nach ihrer Belastbarkeit geordnet, und kein einzelnes schwaches Signal erzeugt ein Label.
| Beleg | Beispiele | Gewicht |
|---|---|---|
| Im Build-Manifest erklärt | ein npm-bin-Eintrag, ein console_scripts-Einstiegspunkt, <OutputType>Exe</OutputType>, Composers type, Mavens <packaging>, ein Cargo-[lib]-Target | Entscheidend |
| Von der Registry erklärt | ein Packagist-Typ, ein NuGet-Pakettyp, eine crates.io-Kategorie | Stark |
| Deklarierte Abhängigkeiten | ein Web-Framework, ein CLI-Argumentparser, ein Chat-Plattform-Client | Mittel |
| Dateibaumstruktur | cmd/…/main.go, src-tauri/, ein Helm-Chart, ein Browser-Extension-Manifest | Unterstützend |
| Repository-Topics und Registry-Schlagwörter | cli, wordpress-plugin, self-hosted | Schwach — selbst vergeben |
| Die Repository-Beschreibung | „a CLI for…“, „a library for…“ | Schwach — selbst vergeben |
Die ersten beiden wiegen am schwersten, weil sie keine Meinung sind: Wer <OutputType>Exe</OutputType> schreibt, beschreibt die Software nicht — sonst würde der Build nicht funktionieren. Ein Topic ist eine Meinung, und zwei übereinstimmende Topics sind das Minimum, das überhaupt etwas trägt.
Belege wirken auch in die Gegenrichtung. Ein Cargo-Paket mit publish = false, ein Composer-type project, ein .NET-Tool, ein Maven-war — jedes davon schließt aus, etwas zu sein, worauf sich andere Software stützen kann, wie das Repository sonst auch aussehen mag.
Wenn die Antwort fehlt
Drei Situationen ergeben keine Klassifikation, und alle drei sind gewöhnlich:
- Der Bericht ist älter als die Klassifikation. Jeder gespeicherte Bericht wurde aus den bereits vorhandenen Fakten neu klassifiziert, aber die Manifest-Belege entstehen während eines Scans — früher erhobene Berichte tragen daher nur die schwächeren Stufen und erhalten die volle Lesart bei der nächsten Prüfung des Repositorys.
- Die Belege beantworten die Frage nicht. Viele Repositories veröffentlichen kein Manifest, tragen keine aussagekräftigen Topics und beschreiben sich in Prosa, die strukturell nichts feststellt.
- Die Antwort wäre geraten. Wo Signale vorhanden, aber zu schwach für die Schwelle sind, wird nichts behauptet.
In allen drei Fällen zeigt der Bericht schlicht keine Klassifikation. Abwesenheit wird nie als Befund dargestellt, es wird nichts darauf bewertet, und ein Repository ohne Klassifikation wird in keiner Weise markiert, zurückgestuft oder benachteiligt.
Repositories, die mehreres bauen
Ein Monorepo mit einem auslieferbaren Dienst neben drei veröffentlichten Bibliotheken ist nicht ein Artefakt, und es auf eine einzige Antwort zu verdichten würde die Tatsache verlieren, dass beide Lesarten zutreffen. Jedes Manifest wird deshalb anhand seiner eigenen Erklärungen klassifiziert, und das Repository trägt die Vereinigung.
Eine Folge sei ausdrücklich genannt: Das einzelne primäre Label eines solchen Repositorys ist das am besten belegte — in einem großen Monorepo kann das ein veröffentlichtes Build-Werkzeug sein statt des Produkts, für das das Projekt bekannt ist. Das primäre Label dient der Darstellung und der Gruppierung vergleichbarer Repositories; es ist nie die Grundlage einer Bewertung.
Was es heute beeinflusst
Einen Check, unter einer stehenden Regel. Seit Metrik-Version 2.5.0 liest die Lockdatei-Erwartung des Sicherheitslage-Fallbacks die Klassifikation: Ein veröffentlichtes Paket, dessen Manifest eine ausführbare Datei erklärt, zählt als Anwendung und behält die Erwartung — wo die Veröffentlichung allein sie bisher aufhob.
Die stehende Regel lautet: Bewertung liest ausschließlich Manifest-Erklärungen. Ein aus Dateistruktur, Topics oder Beschreibung abgeleitetes Label wird angezeigt und festgehalten, bewegt aber nie einen Wert — das kann nur, was ein Build-Manifest ausdrücklich erklärt (ein bin-Eintrag, ein Console-Script-Einstiegspunkt, ein OutputType). Alles andere an der Klassifikation bleibt Datum: metrics.classification in jedem Bericht, zusammen mit den Belegen, die sie erzeugt haben. Weitere Anbindungen werden in den Methodikversionen vermerkt, sobald sie erfolgen.
Verwandt: unterstützte Ökosysteme · der Gesundheitsindex · Sicherheitslage · Scan-Konfiguration · Signale, keine Garantien