Was der Katalog sagt, und woher er es weiß.

Was ein Eintrag angibt

Jedes Tool ist eine kleine YAML-Datei unter data/tools/. Sie nennt das Tool, sein GitHub-Repository, seine Kategorie, die Tools, die es ersetzt, mit einem Ersatzgrad je Tool, und eine Verbindung, wenn es eine gibt. Mehr lässt sich in einem Beitrag nicht angeben.

Ein Eintrag nennt nie Sterne, eine Lizenz, eine Version oder eine Beschreibung. Das Schema lehnt sie ab, damit ein Pull Request keine Sternzahl aufblähen und kein Release behaupten kann, das es nicht gibt.

Der nächtliche Abgleich

Jede Nacht, und immer wenn sich die Katalogdaten auf dem main-Branch ändern, liest der Refresh jedes gelistete Repository über die GitHub-API aus:

• Beschreibung, Homepage, Sprache, Lizenz, Sterne, Forks und Topics
• ob das Repository archiviert ist, und das Datum seines letzten Push
• das neueste Release, oder den neuesten Tag, wenn es kein Release gibt, und ob es signiert ist
• die letzten fünf veröffentlichten Releases, die auf der Tool-Seite stehen
• die Autoren der Commits auf dem Standard-Branch in den letzten 90 Tagen, von denen nur die Anzahl bleibt
• die Namen der Dateien am neuesten Release, gelesen auf die Betriebssysteme und Architekturen hin, die sie nennen
• die Maintainer-Datei, beschrieben unter Von den Maintainern bestätigt

Die Tool-Seite macht daraus, wie lebendig ein Projekt ist, nie eine Bewertung. Sein Alter zählt ab der Erstellung des Repositorys. Der Release-Rhythmus ist der mittlere Abstand (Median) zwischen den letzten stabilen Releases und erscheint ab drei. Aktive Mitwirkende sind die verschiedenen Commit-Autoren auf dem Standard-Branch in den letzten 90 Tagen: Konten, deren Name auf [bot] endet, zählen nicht, und ein Commit ohne verknüpftes GitHub-Konto zählt über seine E-Mail, die nie veröffentlicht wird. Gelesen werden nur die letzten 500 Commits, ein aktiveres Projekt zeigt daher eine Untergrenze wie 40+. Ein Squash-Merge-Workflow rechnet jeden Pull Request einem einzigen Autor zu, auch wenn mehrere daran geschrieben haben, und bei einem Tool in einem Monorepo gilt die Zahl für das ganze Repository, was die Seite dazusagt. Plattformen erscheinen nur, wenn die Dateinamen des neuesten Releases sie nennen, und geraten wird nichts, auch nicht bei einem Tool in einem Monorepo, dessen neuestes Release zu einem anderen Paket gehören kann.

Wenn sich etwas geändert hat, committet der Refresh den neuen Katalog und ein neuer Build dieser Seite geht raus. Gibt GitHub das Repository eines gelisteten Tools nicht mehr zurück, weil es gelöscht oder auf privat gestellt wurde, behält das Tool seine zuletzt veröffentlichten Daten und ein Pull Request, der seinen Eintrag entfernt, wird geöffnet, damit ein Mensch entscheidet: Ein Tool verlässt den Katalog nur über einen solchen Pull Request.

Jeder Refresh vergleicht außerdem den neuen Katalog mit dem vorherigen und hält fest, was sich geändert hat: eine Lizenz, ein Repository-Name, eine Archivierung, ein neues Release, ein Tool, das dazukommt oder geht. Die Seite Was sich geändert hat listet das nach Tagen, mit einem RSS-Feed für den ganzen Katalog, einem pro Tool und einem pro Kategorie. Eine Änderung der Sterne zählt nie.

Zwischen zwei nächtlichen Läufen aktualisiert ein veröffentlichtes Release sein Tool innerhalb weniger Minuten, wenn im Repository die GitHub App awesome-alternatives installiert ist oder der Release-Workflow refresh-action ausführt.

Kennzeichen

✓ signiert

Steht neben der neuesten Version. Der Tag trägt eine Signatur, die GitHub geprüft hat, oder bei einem Lightweight-Tag der Commit, auf den er zeigt. Geprüft wird nur das neueste Release.

Von den Maintainern bestätigt

Das Repository des Tools selbst trägt im Wurzelverzeichnis seines Standard-Branch die Datei .awesome-alternatives mit dem Feldslug: auf diesen Eintrag gesetzt. Nur wer Schreibrechte auf das Repository hat, kann sie anlegen, also sagt das Kennzeichen, dass die Maintainer hinter dem Eintrag stehen. Der Abgleich liest die Datei jede Nacht.Das Kennzeichen wird auch gesetzt, wenn die GitHub App awesome-alternatives im Repository installiert ist, denn dafür braucht es Adminrechte.Die Datei datiert die Bestätigung auf ihren letzten Commit, und ein danach bearbeiteter Eintrag zeigt „seit der Bestätigung bearbeitet“, bis die Maintainer die Datei erneut committen, wofür ein datierter #-Kommentar genügt.In jeder Liste steht ein bestätigtes Tool vor nicht bestätigten mit demselben Ersatzgrad, die Sterne ordnen den Rest. Vor einen besseren Ersatz rückt es nie.

archiviert

Das Repository ist archiviert und bekommt keine Änderungen mehr. Ein archiviertes Tool ist genau das, wovon Leute wegwollen, deshalb wird es nur als etwas aufgenommen, das andere Einträge ersetzen, nie als Alternative, und es löst die Warnung seit einem Jahr kein Push nicht aus.

Other

Steht als Lizenz, wenn GitHub eine erkennt, sie aber keinem SPDX-Bezeichner zuordnen kann. Erkennt GitHub keine, steht am Tool Keine erkannt und es löst die Warnung keine Lizenz erkannt aus.

Ersatzgrade

Jeder Ersatz trägt genau einen, vergeben von der Person, die den Eintrag anlegt.

Drop-in

Übernimmt Konfiguration oder Schnittstelle des Originals unverändert: das Tool lässt sich austauschen, ohne am Setup etwas zu ändern. Wer in der Suche nach einem Drop-in fragt, bekommt nur diese.

Vollwertiger Ersatz

Erledigt dieselbe Aufgabe, auf eigene Weise. Die Konfiguration muss migriert werden.

Teilweise

Erledigt einen Teil der Aufgabe. Die Notiz unter dem Tool sagt, welchen.

Warnungen

Eine Warnung entfernt nie ein Tool. Sie ist etwas, das ein Maintainer vor dem Merge eines Pull Requests ansieht, und etwas, das man wissen will, bevor man sich auf das Tool verlässt.

Repository verschoben

Das Repository liegt jetzt unter einem anderen Namen oder Besitzer. GitHub leitet die alte Adresse weiter, der Eintrag sollte trotzdem aktualisiert werden.

Keine Lizenz erkannt

GitHub erkennt keine Lizenz, damit ist unklar, unter welchen Bedingungen sich der Code nutzen lässt.

Weder Release noch Tag

Das Repository hat weder ein Release noch einen Tag, es gibt also keine Version zum Pinnen.

Seit einem Jahr kein Push

Seit mehr als 365 Tagen wurde nichts gepusht. Archivierte Repositories sind hiervon ausgenommen.

Auffälliger Sterne-Anstieg

Ein Tag, der 50 oder mehr Sterne brachte und mindestens das 5-Fache des üblichen täglichen Tempos des Tools im letzten Monat, und mindestens 3 % der Sterne, die es am Vortag hatte, damit ein gewöhnlich guter Tag eines großen Projekts nicht zählt. Gekaufte Sterne treffen schubweise ein, ein Launch auf Hacker News aber auch, deshalb entscheidet hier ein Mensch. GitHub zeigt nicht mehr an, wer ein Repository mit einem Stern markiert hat, also speichert der nächtliche Abgleich die Sternzahl jedes Tages und vergleicht die Tage. Er braucht eine Woche dieser Historie, bevor er urteilt, ein Tool wird also erst geprüft, wenn es gelistet ist.

Neues Repository

Das Repository ist jünger als 30 Tage; die Markierung zeigt den Tag seiner Erstellung. Bei so wenig Verlauf sagen Sterne, Releases und Aktivität noch wenig aus. Die Markierung verschwindet von selbst, sobald das Repository alt genug ist.

Andere Probleme blockieren stattdessen den Pull Request: ein Repository, das privat ist, ein Fork, archiviert und trotzdem als Alternative angeboten oder bereits unter einem anderen Slug gelistet. Der Leitfaden für Beiträge listet jede Prüfung auf.

Verbindung zum Tool

Das Feld für die Verbindung gibt eine Beziehung zwischen einem Tool und diesem Verzeichnis oder den Personen dahinter an, etwa ein Tool der Betreuer von awesome-alternatives. Hat ein Eintrag eine, zeigt die Tool-Seite sie im Wortlaut. Ein Tool, das man pflegt und listet, ist keine solche Verbindung: Man lässt den Eintrag stattdessen verifizieren, und seine Seite zeigt, dass seine Betreuer dafür einstehen.

Wie die Suche funktioniert

Die Anfrage wird zuerst als Stichwörter gelesen: die Namen der Tools, die andere ersetzen, die Sprachen und Lizenzen im Katalog und „drop in“. Wird kein zu ersetzendes Tool genannt, vergleicht ein kleines mehrsprachiges Embedding-Modell auf dem Suchserver die Anfrage mit der Beschreibung jedes Tools, sodass eine Anfrage in jeder Sprache der Website dieselben Tools findet wie ihre englische Fassung, obwohl die Beschreibungen selbst auf Englisch bleiben, so wie GitHub sie liefert. Sticht ein zu ersetzendes Tool klar heraus, wird es genommen, sonst werden die Ergebnisse danach sortiert, wie nah sie an der Anfrage liegen. Erst wenn beide Schritte kein zu ersetzendes Tool finden und der Server einen Schlüssel dafür hat, geht der Text der Anfrage an Jev, einen externen Dienst, der ihn liest. Dessen Lesart bleibt einen Tag lang auf dem Server zwischengespeichert. Die Datenschutzerklärung sagt, was gesendet und was aufbewahrt wird.

Manche Wörter werden zu Filtern, in jeder Sprache der Seite. „Open Source“ behält Tools mit offener Lizenz. „Gepflegt“ lässt archivierte Tools weg und solche ohne Push seit 365 Tagen. „Selbst gehostet“ behält Tools aus Kategorien von Diensten, die du selbst betreibst. Eine Art zu deployen, etwa Docker, Docker Compose, Kubernetes, Helm oder eine einzelne Binärdatei, behält die Tools, die sie angeben. Eine Plattform, etwa Linux oder ARM, wird erkannt, aber noch nicht geprüft, und die Ergebnisse sagen das, statt so zu tun als ob.

Aus einem KI-Agenten

Der Katalog ist auch ein Model-Context-Protocol-Server (MCP) unter https://awesome-alternatives.com/api/mcp, über Streamable HTTP, ohne Schlüssel und ohne Konto. Ein Agent kann dort Alternativen zu einem Tool oder Produkt finden, Tools nach Kategorie, Sprache oder Lizenz auflisten und die Angaben zu einem Tool lesen. Das Such-Tool liest Anfragen nur mit Stichwörtern und dem Modell auf diesem Server, nie mit Jev, und ist pro Adresse begrenzt; die anderen Tools sind es nicht.

In Claude Code eintragen: claude mcp add --transport http awesome-alternatives https://awesome-alternatives.com/api/mcp

Lizenzen

Die Katalogdaten stehen unter CC BY-SA 4.0: Sie dürfen sie frei weiterverwenden, mit einem Link auf awesome-alternatives.com und unter derselben Lizenz. Der Code der Seite, der API und der Skripte steht unter der GNU AGPL v3.