15 Open-Source-Orchestratoren, eine Tabelle mit Zahlen vom selben Tag, 2026-09-22

Alle sind GitHub-API-Werte vom 2026-09-22, wobei hinter jeder Zahl der Abruftag steht. Ob Sie sie verwenden können, hängt vom Zweck ab: als Größenordnung und relative Position ändert ein Tag nichts am Ergebnis (Orca 75,454 gegenüber dem Zweitplatzierten mit 28,168); als exakte Zahl nein – allein Orca hat innerhalb desselben Tages 1,700 dazugewonnen. Zum Zitieren gehen Sie zurück zum Archiv vom 2026-09-22 oder rufen die Werte heute selbst ab. Geprüft am 2026-10-19.

Nein. NOASSERTION heißt nur, dass der automatische Abgleich von GitHub die LICENSE-Datei keiner bekannten Lizenz zuordnen konnte; 3 der 15 Projekte sind in der Tabelle so markiert. Beim erneuten Blick auf deren READMEs am 2026-10-19 steht im Abschnitt von cmux, dass es unter GPL-3.0-or-later offen ist, und im selben Absatz, dass seine Server-Software unter BSL 1.1 läuft; Superset schreibt, dass die ganze App im Repository unter Elastic License 2.0 steht, und als einzige Ausnahme das Verpacken von Superset selbst als einen Dienst, den Sie an andere verkaufen; beim Worktrunk-Badge steht MIT OR Apache-2.0. Lesen Sie diese Spalte also aus dem README oder aus der LICENSE-Datei des Repositorys – ein Erkennungsfehler ist keine fehlende Lizenz.

7 unter MIT, 5 unter Apache-2.0, 1 unter AGPL-3.0 (claude-squad); bei Worktrunk wählen Sie zwischen MIT oder Apache-2.0; cmux steht laut README unter GPL-3.0-or-later und Superset unter Elastic License 2.0. Über die Klauselnamen hinaus sagen diese READMEs auch, was die jeweilige Klausel tatsächlich erlaubt und verbietet: Superset schreibt, dass Sie die App unter ELv2 nutzen, forken, ändern und für Ihr Team selbst hosten können; cmux stellt seine Server-Software unter die Business Source License 1.1 – lesen, ändern und außerhalb des Produktivbetriebs ausführen ist erlaubt, für den Produktivbetrieb oder eigenes Hosten brauchen Sie eine kommerzielle Lizenz, und derselbe Abschnitt sagt, dass für Organisationen, die GPL nicht einhalten können, kommerzielle Bedingungen möglich sind; bei MIT und Apache-2.0 gibt die README eine einzeilige Lizenzzeile und überlässt den Wortlaut der Klausel der LICENSE-Datei, auf die sie selbst verlinkt (bei emdash und agent-orchestrator ist es genauso). Bei AGPL geht es um die Pflicht zur Quellcode-Bereitstellung, wenn Sie über ein Netzwerk bereitstellen, ELv2 verbietet ausdrücklich, das Produkt selbst als Dienst weiterzuverkaufen, bei GPL um deren Weitergabebedingungen – keine der drei verhält sich wie das „einfach nutzbare“ MIT, und der interne Betrieb unterscheidet sich vom Angebot als Dienst. Der vollständige Wortlaut steht in der LICENSE und der README jedes Repositorys. Die Lizenzverteilung ist am 2026-10-19 geprüft, die zitierten README-Sätze stammen vom Abruf am 2026-10-19.

Öffentlich auffindbar ist lediglich der Bericht eines Nutzers, kein Benchmark. Orca-Issue #10769 (eröffnet am 2026-07-26, am Abrufstag noch offen) nannte damals: In einem Repository mit 297 aktiven Worktrees stieg der Median eines git commit von etwa 1.5s auf 8.9s, Spitze 21.6s, .git bei 1.1G; als Ursache wurde eine beeinträchtigte automatische Wartung des gemeinsamen Objektspeichers genannt. Diese Kausalkette hat der Berichtende später selbst widerrufen: Oben in desselben Textes steht inzwischen sein Nachtrag, wonach eine spätere Messung die ursprüngliche Kausalbehauptung widerlegte, die 301 Worktrees laut Messung nicht der treibende Faktor waren, das Ergänzen von --indexed-objects die Kosten des Aufzählens kaum veränderte und die rund 35s im --reflog steckten, das 7 330 reflog-Dateien aufzählen musste – die meisten stammen aus von Orca verwalteten Fork-Remotes, die jeden Zweig holten, ein einzelner Fork steuerte 2 470 refs und reflog-Dateien bei. Der Nachtrag sagt auch, dass die Zahl der Worktrees als Kontext nützlich bleibt, die Daten einen Schwellwert wie ~100 als Vorhersage für die Git-Kosten aber nicht tragen, und dass der ursprüngliche Bericht als Untersuchungsgeschichte stehen bleibt. Offen bleibt die Produktfrage: langsame Git-Operationen sind in der UI unsichtbar, und vom Symptom zur Gesundheit des Arbeitsverzeichnisses wie des gemeinsamen Speichers führt kein Weg. Die genannte Richtung ist, das Holen verwalteter Forks mit --no-tags auf genau den Zweig zu verengen und die dafür in Frage kommenden, von Orca erzeugten Commits und Abrufe die automatische Wartung nicht auf dem kritischen Pfad auslösen zu lassen. Es bleibt ein Repository an einem Tag, von einem Nutzer berichtet; andere Repository-Größen und Worktree-Anzahlen werden abweichen, und es beschreibt nur Orca. Ob Sie davon betroffen sind, lesen Sie an der Zahl der refs und reflog-Einträge in Ihrem Repository ab und daran, wie viele Zweige ein verwalteter Fork holt – nicht an der Zahl der Worktrees. Nachgeprüft am 2026-10-19.

Die Tabelle zeigt selbst die andere Richtung: 3 mit letztem Push vor 2026-06-01, darunter crystal mit ★3,120, dessen jüngstes Release vom 2026-02-26 stammt, während das abschließende sculptor mit ★232 am 2026-09-21 ein Release veröffentlicht hat – näher an heute als mehrere mit mehr Sternen. Beim erneuten Abruf am 2026-10-19 standen bei sculptor ★240, und an diesem Tag kam sculptor-v0.49.0rc2 heraus; im neu abgerufenen README von crystal steht, dass es zugunsten von Nimbalyst eingestellt wurde, und das README von nimbalyst mit ★1,935 kam im selben Durchgang dazu. Tools wählt man nach passenden Rahmenbedingungen (Lizenz, Form, Größe Ihres Repositorys) und nach Pflegezustand; Sterne sind ein Nebenprodukt der Suchpopularität.

Beim Abruf vom 2026-09-22 wurden 11 vollständige READMEs wortweise geprüft; für die übrigen 4 (nimbalyst, parallel-code, uzi, terragon-oss) lagen nur API-Metadaten vor, deshalb stand in den drei Spalten „nicht abgerufen“. Im Abruf vom 2026-10-19 wurden alle 4 READMEs nachgeholt und die Zellen nach den Sätzen von diesem Tag gefüllt, mit dem Abrufdatum in der Zeile; die anderen 11 Zeilen behalten ihre Anker vom 2026-09-22. Diese drei Spalten beantworten eine Frage: Enthält die README dieses Repositorys diesen Satz? Eine Zelle füllt sich nur, wenn ein Satz da ist, und die Formulierung des einen Repositorys wird nie auf das andere übertragen – der teuerste Fehler in einem Vergleich ist, einem Gegenstand etwas in den Mund zu legen, das er nie gesagt hat.