Каждые два месяца на GitHub появляется новый "убийца" Claude и Cursor. Почему я не подключаю OpenHuman к своим Gmail и Slack

Я каждую неделю смотрю GitHub Trending.

Раз в неделю вижу проект, который действительно решает реальную проблему.

Раз в два появляется «убийца» Claude, Cursor или Cowork с громким позиционированием. Каждый такой проект уверенно объявляет конец эпохи больших платформ.

Каждые два месяца на GitHub появляется новый "убийца" Claude и Cursor. Почему я не подключаю OpenHuman к своим Gmail и Slack

На этой неделе очередной «убийца» вышел в свет. OpenHuman, версия 0.53.43, релиз 13 мая.

118 коннекторов к сторонним сервисам через one-click OAuth: Gmail, GitHub, Slack, Notion, Stripe, Google Calendar, Drive, Linear, Jira.

Стартовый счёт около 10K звёзд, идёт в trending.

Цитата с их README говорит сама за себя: «Большинство агентов стартуют холодными. Hermes учится, наблюдая за вашей работой. OpenClaw ждёт, пока плагины подгрузят контекст».

Обещание OpenHuman: агент работает с первой минуты, читая контекст напрямую из ваших сервисов.

Сильное заявление. Стоит ли сейчас инвестировать в этот проект своё время и подключать к нему свои рабочие данные?

Я считаю, что нет. И в этой статье хочу разобрать почему. Не потому что OpenHuman плохой проект. Возможно он окажется хорошим. Сейчас мы этого не знаем, и в этом вся суть.

Паттерн «нового убийцы» с GitHub Trending

Сначала про паттерн в целом. За последние полгода я наблюдал три такие истории в одной и той же категории «AI-агенты для knowledge work».

В январе вышел OpenClaw. За четыре месяца набрал 372 000 звёзд. Стал самым быстрорастущим open-source проектом в истории GitHub. Сейчас живёт и развивается.

В марте вышел Hermes Agent от Nous Research. 153 000 звёзд. Подход другой: глубина вместо ширины, агент дообучает себя на ваших задачах. Тоже живёт.

На этой неделе вышел OpenHuman. Пока 10k звёзд, но динамика взрывная. Если повторит траекторию OpenClaw, через месяц будет 50-100 тысяч.

Это вершина айсберга. На каждый такой запоминающийся проект приходится 10-15 менее раскрученных, которые умирают на третьей-шестой неделе. И ещё сотня, которая вообще не выходит за пределы родного reddit-треда.

Когда я смотрю на такой проект в первый день жизни, мне нужно ответить на один вопрос. Какая вероятность, что через шесть месяцев он всё ещё будет жив, активно поддерживаться и пройдёт независимый security-аудит. Сейчас, в момент пика хайпа, эту вероятность оценить честно нельзя.

Дальше по статистике последних 5 лет open-source dev-tools-рынка, с любым «убийцей» происходит один из трёх сценариев.

Сценарий 1.

Большая платформа замечает выгоду нового проекта и добавляет себе.
Так Anthropic в январе добавил /goal и Agent View в Claude Code за две недели после того, как похожий функционал вышел у конкурента.
Так Microsoft встроил Cowork-режим в Copilot, увидев успех Claude Cowork.
Большие платформы быстро копируют то, что работает. У них есть штат, ресурсы, дистрибуция и юридическая защита. Новый проект остаётся с одной фичей, которую все теперь имеют.

Сценарий 2.

Проект превращается в нишевый инструмент для энтузиастов.
Не умирает, но и не доходит до production-категории.
Команда увлекается экспериментами, не структурирует поддержку, обслуживание накапливается долгом.
Через год это «классный pet project», в котором никто не хочет ставить production-нагрузку.

Сценарий 3.

Проект схлопывается из-за неустойчивой команды или security-инцидента.
Один из основателей уходит, второй выгорает, остаётся один.
Или коннектор отправляет данные пользователей не туда из-за бага. Или приходит CVE с критической оценкой, и доверие падает за неделю.
Это самый болезненный сценарий для тех, кто успел подключить.

С OpenHuman сейчас идёт первая стадия. Какой из трёх сценариев его ждёт, мы не знаем.

Что обещает OpenHuman и где это потенциально опасно

Я ещё раз посмотрел их README и репозиторий с критическим прищуром. Концепция элегантная: не учить агента контексту через плагины и месяцы наблюдений, а напрямую читать рабочие сервисы пользователя через one-click OAuth. С первой минуты агент видит вашу почту, календарь, GitHub, Slack, Notion. С точки зрения user experience это шаг вперёд.

С точки зрения безопасности это шаг назад на несколько лет.

Разберу по пунктам, почему именно. Это конкретные риски, не абстрактные опасения.

Поверхность атаки.
118 OAuth-коннекторов это 118 потенциальных входов для атакующего.
Если в любом из них есть уязвимость или там утечёт токен, через эту дверь можно достать ваши Gmail, банковские транзакции через Stripe, истории Slack-чатов с командой.
Большая платформа типа Anthropic тратит миллионы долларов в год на security-команду и независимый аудит каждого коннектора.
У OpenHuman сейчас команда из нескольких человек.
Можно ли доверить им свои Gmail и Stripe?
Я скажу честно: нельзя. Не потому что они плохие, а потому что эта работа дороже, чем они могут себе позволить на 10k звёзд.

Стабильность кодовой базы.
Версия 0.53.43 это интересная подсказка.
Семь месяцев жизни проекта, и 53 минорных релиза.
То есть в среднем 7-8 релизов в месяц.
Это значит, что команда шипит быстро. Это же значит, что ломают часто.
Для personal use это нормально: сломали, починили, перезапустил. Для production-нагрузки на твои рабочие данные это плохая идея. Бэкап последней рабочей версии у пользователя обычно отсутствует, и поэтому одна неудачная миграция данных может стоить недели разбирательств.

Безопасность как процесс.
Это пункт, который собственники бизнеса обычно недооценивают.
У Anthropic есть публичная security-программа, bug bounty, регулярные аудиты, ответственность перед регуляторами в США и Европе.
У Microsoft и Google ровно то же самое, плюс юридические команды размером с небольшую страну.
У молодого open-source проекта команда из 3-5 человек без формальных обязательств. Если завтра выяснится, что их коннектор передавал ваши данные третьей стороне (намеренно или из-за бага), у вас нет инстанции, которой можно предъявить иск. У вас нет страховки. У вас нет публичного отчёта об инцидентах.

Где их реальный пик.
Они выигрывают на одной фразе «не нужно настраивать».
Это сильное преимущество, но узкое. Anthropic выигрывает на построенной экосистеме: 14 000+ MCP-серверов в реестре, интеграции с PwC, SAP, Microsoft, Apple. Если у вас уже есть базовая методология работы с AI (а если нет, читайте мою предыдущую статью про кейс Intercom), вы получите 80% выгоды OpenHuman через Claude Cowork плюс правильно подобранные MCP-коннекторы. Без всех рисков молодого проекта.

Когда вернуться к OpenHuman

Я не хочу ставить крест на проекте. Они могут оказаться правы и стать новой большой платформой. Тогда я хочу подключиться рано, до того как стоимость зайдёт на массовый уровень.

Триггеры, при которых я повторно посмотрю проект через 2-3 месяца.

Проект выжил. Не закрыт, не заброшен. Команда отвечает на issues и публикует регулярные release notes.

Прошёл хотя бы один независимый security-аудит. В идеале от известной компании типа Trail of Bits или NCC Group. Аудит должен быть публичным, чтобы я мог прочитать выводы.

Перевалил за 50 000 звёзд на GitHub. Это не идеальная метрика, но косвенно показывает, что сообщество достаточно активно, чтобы кто-то быстро заметил инцидент и поднял шум.

Появился список крупных клиентов с реальной production-нагрузкой. Не «команда из 5 человек попробовала», а компании уровня 100+ человек, которые поставили проект в свой стек.

Если эти четыре условия выполняются через 2-3 месяца, проект становится кандидатом на пилот. Не на полноценное внедрение, а именно на пилот с ограниченной поверхностью.

До этого момента OpenHuman у меня на радаре, не в работе.

Чек-лист собственника: 5 вопросов перед подключением любого нового AI-инструмента к рабочим данным

OpenHuman это конкретный кейс этой недели. Через месяц на его месте будет другой проект. Через три месяца ещё один. Чтобы не каждый раз изобретать оценку заново, я для себя выработал чек-лист, и он работает на любую категорию AI-инструментов: агентов, MCP-серверов, скиллов из marketplace, browser-extension'ов.

Вопрос 1. Сколько проекту лет, и в какой он версии? Минимум 6 месяцев в стабильной версии 1.0 или выше для production-использования. Версия 0.x значит «всё ещё бета», это не подходит для рабочих данных. Меньше 6 месяцев значит «не было полного цикла обнаружения и исправления первых критических багов».

Вопрос 2. Сколько звёзд и сколько коммитов в неделю? Минимум 10 000 звёзд для personal use, минимум 50 000 для production. Активность: минимум 5-10 коммитов в неделю в основной ветке. Если только редкие коммиты, проект скорее всего умирает.

Вопрос 3. Есть ли публичная security-программа? Должен быть отдельный документ SECURITY.md с указанием куда сообщать об уязвимостях, какая политика disclosure, есть ли bug bounty. Если нет, проект не готов к production.

Вопрос 4. Кто за этим стоит и есть ли у них коммерческая модель? Должна быть видимая команда с открытыми профилями. В идеале коммерческая модель: подписка, enterprise-план, или фонды. «Хобби в свободное время» это красный флаг для долгосрочной работы.

Вопрос 5. К каким моим данным проект получит доступ? Самый главный вопрос. Если новый AI-инструмент просит доступ к Gmail, к платёжной системе, к закрытым репозиториям с коммерческим кодом, это совсем другой уровень риска, чем если он просит доступ к календарю или к публичному репозиторию. Чем чувствительнее данные, тем строже фильтр по вопросам 1-4.

Я прогоняю любой новый AI-инструмент через этот чек-лист за 10-15 минут. Если хотя бы один пункт не выполняется, проект не подключается к моим рабочим данным. Точка.

Это не паранойя. Это разумная гигиена в эпоху, когда количество новых AI-проектов выросло в 10-15 раз за последние два года.

Главный тезис, ради которого я пишу эту статью

Я не против open-source агентов. Я очень люблю open-source и в большинстве случаев его рекомендую. Linux, Postgres, Ruby on Rails, React, Python это инфраструктура моих проектов и проектов моих клиентов. Без open-source современный бизнес 10-200 человек просто не работает.

Но с приходом AI в разработку произошёл качественный сдвиг. Количество проектов, которые могут нанести больше вреда чем пользы, выросло несоизмеримо. Не в два раза, не в пять, а в десятки раз. Почему?

Потому что AI ускоряет разработку нового проекта в разы. Где раньше команде из 3 человек требовалось 6 месяцев на MVP, сейчас один человек с Claude Code или Cursor собирает рабочий прототип за две недели. Это великолепно для скорости инноваций. Это плохо для безопасности экосистемы. Безопасность не масштабируется так же быстро. Security-аудит остаётся медленным процессом. Bug bounty остаётся медленным процессом. Сообщество, которое замечает плохие практики в open-source, остаётся медленным механизмом.

В результате на GitHub каждый день появляется десятки AI-инструментов, которые технически работают, но не прошли никакой проверки. Часть из них совершенно безобидна. Часть из них украдёт ваши OAuth-токены при первой возможности и продаст в даркнете. Различить эти две категории на старте невозможно.

Я наблюдаю эту тенденцию третий год подряд, и она усиливается. В мае 2026 в одной только npm-экосистеме произошла координированная supply-chain атака, в которой пострадало 400+ пакетов через self-spreading worm. Атакующие подписали свои malicious пакеты валидным SLSA provenance: enterprise-схема защиты не сработала. Через две недели они выложили исходный код атаки в открытый доступ. Любой студент может теперь это повторить.

Это новая реальность. Если ваш бизнес зависит от AI-инструментов (а я уверен, что зависит, или скоро будет зависеть), у вас должна быть собственная дисциплина оценки этих инструментов. Чек-лист выше это начальный набор. Минимум, который защитит от очевидных рисков.

OpenHuman через год может стать большим хорошим проектом. Может умереть. Может схлопнуться из-за инцидента. Любой из трёх сценариев одинаково вероятен сегодня. Решение «подключаю / не подключаю сейчас» это решение про управление риском, не про оценку технологии.

Я не подключаю. Через 2-3 месяца посмотрю снова.

В моём Telegram-канале t.me/gorilla_under_hood я выкладываю каждую неделю разбор новых AI-инструментов, которые попадают на GitHub Trending. Не с маркетинговой стороны, а с точки зрения собственника, который думает «подключать ли это к рабочим данным». Подписывайтесь, если эта оптика вам близка.

3
Начать дискуссию