15 open-source оркестраторов — числа одного дня, 2026-09-22

Все это значения GitHub API за 2026-09-22, дата выгрузки подписана у каждого числа. Можно ли ими пользоваться — зависит от задачи: как порядок величины и relative расположение, один день вывод не меняет (Orca 75,454 против 28,168 у второго); как точная цифра — нет, только у Orca прирост за тот же день составил 1,700. Для цитаты вернитесь к архиву 2026-09-22 или возьмите API сами. Сверено 2026-10-19.

Нет. NOASSERTION означает лишь, что автоопределение GitHub не сопоставило файл LICENSE с известной лицензией; среди 15 в таблице так помечены 3 проекта. Если 2026-10-19 снова посмотреть их README: в разделе cmux сказано, что он открыт под GPL-3.0-or-later, и в том же абзаце — что его server-софт идёт под BSL 1.1; Superset пишет, что всё приложение лежит в репозитории под Elastic License 2.0, и единственное исключение — перепаковать сам Superset в сервис, который вы продаёте другим; на значке Worktrunk написано MIT OR Apache-2.0. Так что читайте эту колонку либо по README, либо по файлу LICENSE: сбой распознавания — это не отсутствие лицензии.

7 — MIT, 5 — Apache-2.0, 1 — AGPL-3.0 (claude-squad); Worktrunk — на выбор MIT или Apache-2.0; cmux по README — GPL-3.0-or-later, Superset — Elastic License 2.0. Кроме названий клауз эти README говорят и о том, что каждая клауза фактически разрешает и что запрещает: Superset пишет, что под ELv2 приложение можно использовать, форкать, изменять и поднимать самостоятельно для своей команды; cmux переводит свой server-софт под Business Source License 1.1 — читать, править и запускать вне продуктивной эксплуатации разрешено, а для продуктового использования или самостоятельного хостинга нужна коммерческая лицензия, и в том же абзаце сказано, что тем организациям, которые не могут соблюдать GPL, могут предложить коммерческие условия; на стороне MIT и Apache-2.0 README оставляет однострочное заявление о лицензии, а текст условий отдаёт файлу LICENSE, на который сама ссылается (так и у emdash, и у agent-orchestrator). AGPL про обязанность дать исходники при сетевой выдаче, ELv2 прямо запрещает перепродавать сам продукт как сервис, GPL про зараживающие условия — ни одна из трёх не ведёт себя как «просто бери и используй» MIT, а внутреннее использование отличается от предоставления сервиса. Полный текст условий лежит в LICENSE и README каждого репозитория. Распределение лицензий сверено 2026-10-19, приведённые строки README взяты при выгрузке 2026-10-19.

В открытом доступе — рассказ пользователя, а не замер. В issue Orca #10769 (от 2026-07-26, на день выгрузки open) автор сначала писал: в одном репозитории при 297 живых worktree медиана git commit ушла с ~1.5s до 8.9s, пик 21.6s, .git 1.1G, а причина — деградация автообслуживания общего объектного хранилища. Позже он сам опроверг эту связь: теперь в начале того же текста стоит его приписка, где последующие замеры опровергли исходный причинный вывод, 301 worktree не оказались измеренной причиной, добавление --indexed-objects почти не меняло стоимость перечисления, а ~35s уходили на --reflog, которому надо было перечислить 7 330 файлов reflog. Большинство создали fork-remote под управлением Orca, тянувшие все ветки, и один форк дал 2 470 refs и файлов reflog. В приписке есть и то, что число worktree остаётся полезным контекстом, что эти данные не поддерживают порог вроде ~100 как предиктор стоимости Git, и что исходный отчёт оставлен как история расследования. Живым остаётся вопрос продукта: медленные операции Git не видны в UI, и от симптома нет пути к здоровью рабочего пространства и общего хранилища. Указанное направление — сузить тягу управляемых форков до нужной ветки с --no-tags и не давать подходящим под условие операциям commit и fetch от Orca запускать автообслуживание на критическом пути. Это по-прежнему один репозиторий и один день со слов одного пользователя; при других размерах репозитория и другом числе worktree всё будет иначе, и касается это только Orca. Хотите понять, коснётся ли это вас — смотрите на масштаб refs и reflog в своём репозитории и на то, сколько веток тянет управляемый форк, а не на число worktree. Перепроверено 2026-10-19.

Таблица как раз даёт обратный пример: у 3 последний push раньше 2026-06-01, в том числе crystal с ★3,120 и релизом от 2026-02-26, тогда как замыкающий sculptor при ★232 выкатил релиз 2026-09-21 — свежее, чем у некоторых с большим числом звёзд. При перечитывании тех же эндпоинтов 2026-10-19 у sculptor стало ★240, и в тот же день вышел sculptor-v0.49.0rc2; в заново взятом README crystal сказано, что проект устарел и заменён на Nimbalyst, а README nimbalyst с ★1,935 подтянули в том же заходе. Инструмент выбирают по совпадению ограничений (лицензия, формат, размер вашего репозитория) и по сопровождению; звёзды — побочный продукт поисковой популярности.

В выгрузке 2026-09-22 сверены пословно 11 README целиком; у остальных 4 (nimbalyst, parallel-code, uzi, terragon-oss) были только метаданные API, и в трёх колонках стояло «не брали». В заходе 2026-10-19 все 4 README подтянули и заполнили эти клетки по строкам того дня, подписав дату выгрузки в строке; остальные 11 строк хранят свои якоря 2026-09-22. Те три колонки отвечают на один вопрос: есть ли такая строка в README этого репозитория. Клетку заполняют только когда есть строка, и формулировку одного репозитория никогда не переносят на другой: самая дорогая ошибка в сравнении — заставить оцениваемого сказать то, чего он не говорил.