Активность разработки оценивают по четырём величинам: сколько независимых авторов правят код, с какой регулярностью выходят правки, попадают ли они в ядро продукта или в оформление, и сколько недель репозиторий стоял без изменений. Число коммитов само по себе ничего не говорит — его легко набить пустыми правками. Все четыре величины берутся из публичного репозитория и проверяются без доступа к проекту.

Активность разработки — это измеримый поток изменений в публичном коде проекта за период, который описывается числом независимых авторов, регулярностью правок и долей изменений, попавших в основной продукт, а не в документацию и сайт.

Как оценить активность разработки: четыре измерения вместо одного

Счётчик коммитов на главной странице репозитория — показатель объёма, но не работы. Он растёт от переименования файлов. Он растёт от автоматических правок бота. Поэтому измерений нужно четыре, и каждое отвечает на свой вопрос.

  1. Авторы: сколько разных людей внесли правки за квартал и какая доля правок приходится на самого активного из них.
  2. Ритм: сколько недель за год прошло без единой правки и когда была последняя.
  3. Глубина: что меняется — код протокола и контрактов или README, переводы и вёрстка сайта.
  4. Состав репозиториев: ведётся ли работа в собственном коде или в форке чужого проекта без своих изменений.

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

Где брать данные: интерфейсы вместо скриншотов

Источников два. Первый — сам хостинг кода. На 17 октября 2026 года документация GitHub REST API (версия 2026-03-10) описывает пять точек статистики репозитория, и у каждой есть предел, о который спотыкаются при первой выгрузке.

Точка /stats/contributors отдаёт общее число коммитов каждого автора с недельной разбивкой, но в репозиториях с десятью тысячами коммитов и более счётчики добавленных и удалённых строк приходят нулями. Точка /stats/commit_activity даёт последний год активности по неделям. Точка /stats/participation — суммы за последние 52 недели, отдельно по владельцу и по всем участникам. Точка /stats/code_frequency работает лишь для репозиториев меньше десяти тысяч коммитов, иначе возвращает код 422. Первый запрос к любой из них часто отдаёт код 202: статистика считается в фоне, и запрос нужно повторить.

Второй — открытые таксономии репозиториев. Набор crypto-ecosystems от Electric Capital сопоставляет экосистемы и их репозитории через три команды описания: добавление экосистемы, добавление репозитория с тегами и связывание экосистем между собой иерархически. Авторы набора прямо предупреждают, что данные неполны и полными не станут. Это честная оговорка, и переносить её в собственные выводы обязательно: отсутствие репозитория в таксономии означает пробел в разметке набора, а не отсутствие разработки у проекта.

Выгрузку полезно сопоставлять с остальной картиной по проекту. Размер и оборот актива разбираем отдельно: сравнение капитализации и объёма торгов даёт масштаб, с которым соотносят размер команды разработки. Сами авторы правок — тоже проверяемая величина, и проверка команды проекта показывает, совпадают ли люди из репозитория с людьми из документа о выпуске.

Показатель Откуда берётся Чем искажается
Число авторов за квартал Список участников с недельной разбивкой коммитов Боты и сервисные учётные записи считаются как авторы
Коммиты по неделям за год Недельный ряд активности за последние 52 недели Массовый перенос файлов даёт разовый всплеск без работы
Строки кода добавлено и удалено Недельная сводка по добавлениям и удалениям В крупных репозиториях счётчики приходят нулями или запрос отклоняется
Доля правок владельца репозитория Суммы за 52 недели отдельно по владельцу и по всем Работа через организацию распределяет правки и занижает долю

Разбор на живом примере: квартал в цифрах

Числа ниже условные. Проект не назван. Они нужны для порядка счёта.

Допустим, за квартал в репозитории 240 коммитов и 9 авторов. Картина выглядит живой. Дальше смотрим разбивку: 186 правок из 240 внёс один автор, ещё 38 — автоматический бот обновления зависимостей, остальные семеро сделали по две-три правки. Реальных участников двое. Картина меняется. Из 240 коммитов 150 приходится на каталог документации и перевод интерфейса, а код контрактов не менялся одиннадцать недель.

Вывод не про темп. Он про концентрацию. Проект держится на одном человеке. Это не оценка качества кода и не прогноз, а описание устройства работы, которое дальше учитывают в рисках реализации.

Красные флаги в активности разработки

  • Весь код в форке чужого репозитория, собственных правок за год нет.
  • Более трёх четвертей правок за квартал внёс один участник.
  • Последняя правка в основном репозитории старше шести месяцев.
  • Активность целиком в репозитории сайта и документации.
  • Коммиты идут пачками по десяткам в минуту — признак переноса, а не работы.
  • Репозиторий закрыт, а документ о выпуске обещает открытый код.
Низкая активность не равна остановке проекта, а высокая не равна прогрессу. Зрелый протокол с замороженным ядром правят редко намеренно, и редкие коммиты в нём — норма. Обратная ошибка встречается чаще: ежедневные правки в репозитории лендинга выдают за разработку продукта.

Как собрать собственную сводку по разработке

  1. Выпишите адреса всех публичных репозиториев проекта и отметьте, какой из них основной.
  2. Снимите недельный ряд коммитов за 52 недели и сохраните дату выгрузки.
  3. Постройте список авторов и посчитайте долю самого активного, исключив ботов.
  4. Разметьте правки по назначению: ядро, интерфейс, документация, инфраструктура.
  5. Повторите выгрузку через квартал и сравните два среза по тем же четырём строкам.
Схема из пяти шагов: собираем список репозиториев, снимаем недельный ряд коммитов, считаем долю главного автора, размечаем правки по назначению, сравниваем два квартальных среза
Схема из пяти шагов: собираем список репозиториев, снимаем недельный ряд коммитов, считаем долю главного автора, размечаем правки по назначению, сравниваем два квартальных среза

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

Итог

Активность разработки — измеримая величина с известными ограничениями измерения. Считать по счётчику коммитов бессмысленно. Считать по числу независимых авторов, ритму правок и доле изменений в ядре можно, причём бесплатно и из открытых интерфейсов. Главный результат такой оценки обычно один и он же самый неприятный для проекта: становится видно, на скольких людях в действительности держится код и что произойдёт, если эти люди уйдут.

Материалы по теме

Частые вопросы

Можно ли оценить активность разработки пошагово без программирования?

Да, вполне. Страницы статистики репозитория показывают недельный ряд коммитов и список участников в браузере, без запросов к интерфейсу. Разметка правок по назначению делается глазами: видно, какой каталог изменён. Программирование нужно лишь для регулярной выгрузки по многим проектам сразу.

Сколько авторов считать достаточным числом?

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

Что делать, если код закрыт?

Фиксировать как факт. Картину не достраивать. Закрытый код означает, что активность разработки внешней проверке недоступна; оценивать её по пресс-релизам и дорожным картам нельзя. В сводке такая строка помечается как нераскрытая, наравне с отсутствующей датой аудита.

Учитывать ли правки автоматических ботов?

В ритм — да. В число авторов — нет. Обновления зависимостей и сборочные роботы дают ровный поток коммитов и маскируют простой живых участников. Их отделяют по имени учётной записи и считают отдельной строкой, иначе репозиторий выглядит активнее, чем он есть.

Вердикт

Из редакционной практики: самая частая ошибка при оценке разработки — доверие к одному большому числу. Разбивка по авторам и каталогам меняет вывод в обратную сторону примерно так же часто, как подтверждает его. Ограничения интерфейсов статистики при этом известны заранее и описаны в документации, так что их стоит учитывать до выгрузки, а не после. Разборы репозиториев и находки по проектам публикуем в Telegram-канале Cryptium.

Первоисточники: документация точек статистики GitHub REST API — состав выдачи и ограничения по числу коммитов; открытая таксономия crypto-ecosystems — сопоставление экосистем и репозиториев с оговоркой о неполноте. Формулировки сверены 17 октября 2026 года.