GitHub как бесплатное исследование рынка: нашёл инструмент, который ищет боли пользователей по Issues

Есть довольно простой способ искать идеи для новых продуктов: не спрашивать людей, чего им не хватает, а посмотреть, на что они уже жалуются.

На GitHub таких жалоб миллионы.

«После обновления всё сломалось».

«Почему до сих пор нет этой функции?»

«Приходится использовать костыль через три библиотеки».

«Есть нормальная альтернатива?»

По сути, Issues крупных open-source проектов — огромная база пользовательских проблем. Только читать её руками довольно быстро надоедает.

Недавно наткнулся на open-source проект gh-pain-intel, который пытается автоматизировать этот процесс с помощью LLM.

Вы указываете GitHub-репозитории, которые хотите исследовать.

Например:

ollama/ollama

или несколько конкурирующих проектов сразу.

Сервис забирает свежие Issues и комментарии, после чего прогоняет их через языковую модель.

Каждую проблему он пытается классифицировать:

Плюс определяет настроение автора и выставляет проблеме условную «болезненность» от 1 до 5.

Но интереснее начинается дальше.

Модель собирает похожие жалобы в группы.

Вместо 800 Issues можно получить примерно такую картину:

74 жалобы связаны с потреблением памяти.51 пользователь просит нормальную работу с несколькими GPU.38 человек недовольны скоростью загрузки моделей.27 обсуждают отсутствие удобного управления моделями внутри команды.

И вот это уже похоже не на список багов, а на маленькое исследование рынка.

Представим, что я хочу сделать новый инструмент вокруг локальных LLM.

Самый очевидный путь — придумать десять идей самому.

Менеджер моделей.

Веб-интерфейс.

Облачная синхронизация.

Мониторинг GPU.

Командный доступ.

Что-нибудь ещё.

Проблема в том, что половина этих идей может никому не быть нужна.

Другой вариант — взять Ollama, LM Studio, vLLM и несколько других популярных проектов и посмотреть, о чём пользователи регулярно пишут последние три месяца.

Если одна и та же проблема всплывает десятки раз в разных репозиториях, это уже интересный сигнал.

Не гарантия бизнеса на миллиард, конечно. Но гораздо полезнее, чем очередной мозговой штурм на тему «какой SaaS сейчас запустить».

Сам проект написан на Python и использует Streamlit.

Схема примерно такая:

GitHub Issues → очистка данных → LLM-классификация → кластеризация тем → анализ → Markdown-отчёт.

Есть поддержка разных моделей.

Можно использовать OpenAI, Claude, Gemini, DeepSeek, Kimi, Qwen, Grok, OpenRouter и другие OpenAI-compatible API.

И отдельно мне понравилось, что предусмотрена Ollama.

То есть весь анализ можно гонять локально и вообще не платить за API, если под рукой есть нормальная модель.

Для большого исследования это может быть полезно: несколько тысяч Issues довольно быстро начинают превращаться в приличный объём токенов.

На главной инструмент показывает GitHub Trending и проекты, которые быстрее всего набирают звёзды за сутки.

Идея здесь простая.

Сначала можно увидеть быстро растущий open-source проект, а потом буквально в один клик отправить его Issues на анализ.

Получается маленький конвейер:

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

Мне кажется, именно так этот инструмент и интереснее всего использовать.

Не как анализатор багов, а как своеобразный радар продуктовых возможностей.

Допустим, появился новый популярный AI-фреймворк.

У него за месяц возникло 1500 Issues.

Руками их никто читать не будет.

А здесь можно попытаться быстро понять:

какие проблемы повторяются;

какие функции люди требуют чаще всего;

где пользователи особенно раздражены;

что приходится решать сторонними инструментами;

какие темы начали появляться только в последние недели.

Особенно интересен последний пункт.

Если проблема появилась недавно и число жалоб быстро растёт, рядом иногда возникает отдельная ниша.

Очень многие небольшие SaaS именно так и появляются: кто-то устал вручную обходить ограничение другого продукта и сделал нормальный инструмент.

LLM здесь ничего магического не знает.

Она может неправильно объединить Issues, переоценить важность громкой жалобы или, наоборот, пропустить действительно серьёзную проблему.

Количество Issues тоже не равно размеру рынка.

Сто разработчиков могут активно обсуждать одну проблему, но платить за её решение никто не станет.

Поэтому я бы воспринимал такой анализ как первый фильтр.

Нашёл интересную боль → пошёл читать оригинальные Issues → посмотрел конкурентов → проверил поисковый спрос → поговорил с пользователями.

Вот тогда уже можно делать выводы.

Мы привыкли использовать LLM для генерации текста, кода и картинок.

А мне сейчас гораздо интереснее другой класс инструментов: когда модель сидит поверх большого массива неструктурированных данных и вытаскивает из него закономерности.

GitHub в этом смысле почти идеальный источник.

Люди приходят туда не отвечать на маркетинговые опросы. Они приходят, потому что у них уже что-то не работает.

А значит, данные там довольно «грязные», зато настоящие.

И если научиться нормально их фильтровать, GitHub можно использовать почти как бесплатную систему исследования рынка.

gh-pain-intel как раз показывает, как это можно сделать относительно простым пайплайном.

Репозиторий: https://github.com/Mocas-12/gh-pain-intel

Хочу прогнать через gh-pain-intel несколько крупных AI-проектов и посмотреть, можно ли таким способом действительно находить идеи для продуктов, а не только красивые графики.

Результаты экспериментов буду выкладывать в своём Telegram: что нашлось, какие боли повторяются, какие идеи из этого можно вытащить и где LLM откровенно ошибается.

Там же каждый день публикую интересные open-source проекты, инструменты для ИИ и автоматизации, локальные модели и свои эксперименты с ними.