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.
Drei Fragen werden unabhängig beantwortet, und ein Repository kann mehr als eine mit Ja beantworten:
| Frage | Trifft zu auf | Was dadurch erwartbar wird |
|---|---|---|
| Als Code eingebunden | Bibliothek, Framework, SDK, API-Client, Middleware, Treiber | Eine stabile Schnittstelle, ein Changelog, eine Versionierung, auf die sich andere Software stützen kann |
| Als Programm ausgeführt | Kommandozeilenwerkzeug, Terminal-Oberfläche, Desktop- und mobile Anwendung, Weboberfläche, Netzwerkdienst, Chatbot, MCP-Server | Festgeschriebene Abhängigkeiten, saubere Auslieferung und Konfiguration |
| In einen Host installiert | Plugin, Erweiterung, Theme, Editor-Werkzeuge | Der Host gibt Vertrauensmodell und Release-Takt vor |
Wo beides zutrifft, gilt beides: Ein Hybrid schuldet die Pflichten jeder Lesart, die er trägt, nie die nachsichtigste davon.
Die Labels
| Als Code eingebunden | Als Programm ausgeführt | In einen Host installiert |
|---|---|---|
| Bibliothek | Kommandozeilenwerkzeug | Plugin |
| Framework | Terminal-Oberfläche | Erweiterung |
| SDK | Desktop-Anwendung | Theme |
| API-Client | Mobile Anwendung | Editor-Werkzeuge |
| Middleware | Weboberfläche | |
| Treiber | Netzwerkdienst | |
| Chatbot | ||
| MCP-Server |
Notebook ist ein eigenes Label und gehört zu keiner der drei Gruppen: Es wird von einem Menschen gelesen und ausgeführt, von nichts importiert und nirgendwo installiert.
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 Metrik-Version 2.3.0. 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
Nichts. Mit Metrik-Version 2.3.0 wird die Klassifikation als Datum veröffentlicht — metrics.classification in jedem Bericht, zusammen mit den Belegen, die sie erzeugt haben — und keine Metrik liest sie. Die Anbindung an die Metriken, die von ihr abhängen, beginnend mit der Erwartung an Lockdateien, ist eine eigene Änderung und wird in den Methodikversionen vermerkt, sobald sie erfolgt.