GitHub — это не только крупнейший веб‑сервис для хостинга IT‑проектов и своего рода социальная сеть для программистов, а целая вселенная, образованная миллионами репозиториев, со своими звёздами, форками, пул‑реквестами… Наша студенческая команда Политеха (Эрнест Сагидуллин, Ирина Ситаева и Виталий Васильев) решила заняться изучением этой вселенной. Начали мы с самого актуального вопроса: что делает один проект сверхпопулярным, а другой — пыльным архивом? Для решения этой задачи мы не просто собрали кучу метрик, а разработали полноценное приложение для загрузки, анализа и визуализации данных с предсказанием популярности.
В начале работы над проектом мы изучили существующую на просторах интернета информацию и обнаружили два подхода: у одних авторов преобладали сухие цифры (они считали звёзды, форки, коммиты), а другие подходили с лингвистической точки зрения и анализировали README и issues в отрыве от метрик. Мы решили сочетать использование числового и смыслового анализа.
По нашему замыслу, этот проект пригодится разработчикам как инструмент оценки потенциала библиотеки, прежде чем использовать её в проекте, владельцам репозиториев — правильно вести проект (учитывать влияние оформления, лицензии, CI/CD) и всем тем, кто хочет в топ — рекомендации по привлечению контрибьюторов.
Приложение написано на Python 3.9 в объектно‑ориентированной парадигме с разделением логически связанных разделов кода по модулям, данные хранятся в СУБД PostgreSQL 18.2 и анализируются в Metabase v0.60.3.5, также задействован Jupyter Notebook v6.
Для сбора данных использовался REST API платформы GitHub, который накладывает ряд ограничений, влияющих на скорость и полноту получения информации о репозиториях:
Без использования токена лимит составляет 60 запросов в час, а с ним увеличивается до 5000 запросов в час. Чтобы повысить скорость сбора данных, в работе использовалось несколько токенов доступа.
GitHub API выдает данные страницами, максимальное количество элементов на одной странице ограничено до 100 записей. То есть, чтобы получить полный набор данных, необходимо использовать последовательный перебор страниц. Однако для некоторых методов API (в т.ч. search) есть ограничение на глубину выборки — доступно не более 1000 результатов поиска на один тип запроса, это связано с внутренними ограничениями индексирования на стороне GitHub.
Дополнительно, ограничения касаются параллельного выполнения запросов, при высокой частоте обращений с одного IP‑адреса возможна временная блокировка запросов. Кроме того, следует учитывать, что часть данных недоступна из‑за настроек приватности репозиториев.
Структура таблицы с данными.
Название признака | Тип | Описание |
github_id | int | Идентификатор репозитория на платформе GitHub |
readme | text | Текст файла README, содержащий основную информацию о проекте |
releases_count | int | Количество релизов, которые были выпущены командой на момент сбора данных |
subscribers_count | int | Количество пользователей, которые отслеживают обновления по репозиторию |
stargazers_count | int | Количество звезд, поставленных репозиторию пользователями |
forks_count | int | Количество копий репозитория, сделанных пользователями |
created_at | datetime | Дата и время создания репозитория |
license_spdx_id | string | Идентификатор лицензии, по которой распространяется ПО |
topics | json | Массив строк, содержащий ключевые слова, которые характеризуют назначение репозитория |
pushed_at | datetime | Дата последнего обновления в репозитории на момент сбора данных |
languages_map | json | Словарь, в котором каждому языку программирования сопоставлена процентная доля в файлах репозитория |
full_name | string | Полное имя репозитория, содержащее username владельца и название |
contributors_count | int | Количество участников, которые вносили изменения в файлы репозитория |
owner_location | string | Местоположение владельца репозитория, указанное в его профиле на GitHub |
description | text | Текст, содержащий описание репозитория для других пользователей |
owner_type | string | Тип владельца репозитория: организация или обычный пользователь |
size | int | Совокупный размер файлов репозитория в килобайтах |
has_github_actions | bool | Логический признак, показывающий, используются ли в репозитории GitHub Actions для автоматизации CI/CD процессов |
recent_commits | json | Массив структурированных объектов, содержащих информацию о последних 30 коммитах репозитория (см табл. 2) |
commit_stats | json | Структура типа ключ‑значение, содержащая агрегированную статистику по коммитам репозитория (см табл. 3) |
root_contents | json | Массив структурированных объектов, содержащих сведения о файлах и директориях корневого уровня репозитория (см табл. 4.) |
recent_pull_requests | json | Массив структурированных объектов, содержащих информацию о последних 30 pull‑реквестах репозитория (см табл. 5) |
pull_request_stats | json | Структура типа ключ‑значение, содержащая агрегированную статистику по pull‑реквестам репозитория (см табл. 6) |
recent_issues | json | Массив структурированных объектов, которые содержат информацию о последних 30 issues репозитория (см табл. 7) |
issue_stats | json | Структура типа ключ‑значение, содержащая агрегированную статистику по issues репозитория (см табл. 8) |
За получение данных из внешнего источника отвечают два взаимосвязанных компонента: GitHubAPI и GitHubFetcher. Модуль GitHubAPI реализует взаимодействие с REST API GitHub, содержит методы для загрузки как общей информации о репозиториях, так и других связанных сущностей, включая коммиты, pull‑реквесты, issues и другие. Модуль GitHubFetcher использует GitHubAPI для массового сбора данных, то есть выполняет последовательный обход репозиториев по заданному временному интервалу и страницам поиска с учетом ограничений источника данных. После получения полного набора данных о репозиториях они преобразуются в ORM‑модель Repository, соответствующую таблице в базе данных. Для работы с данными используется библиотека SQLAlchemy. Класс Database отвечает за создание подключения к базе данных, инициализацию таблиц и управление сессиями. Логика взаимодействия с базой данных выделена в отдельный модуль RepositoryService, который реализует необходимые CRUD‑операции: добавление одного или нескольких репозиториев, чтение записей, обновление и удаление данных.
Для исследования собранных данных используется среда Jupyter Notebook, которая обеспечивает подключение к PostgreSQL. В этой среде реализуется предобработка данных, статистический анализ, а также построение моделей и дополнительных визуализаций. Для визуализации и построения дашбордов применяется сервис Metabase, подключённый к базе данных.
В результате изучения 60 тыс. популярных репозиториев с количеством звёзд больше 1000 за всё время существования GitHub мы сделали ряд интересных наблюдений. Среднее количество релизов составило по 42 на репозиторий (стандартная ошибка 1,3), количество уникальных контрибьюторов 100 (0,9), количество звезд 4,5 тыс. (42), количество копий 744 (10), количество участников 77 ( 1,6), размер репозитория со всеми изменениями 108 Мб (4 Мб).
Построенная матрица корреляции Пирсона для всех числовых признаков выявила сильную положительную связь между количеством форков и количеством звезд и слабую положительную зависимость количества звезд от возраста проекта, что опровергает расхожее мнение о большей популярности старых проектов.
Подтверждена лидирующая роль языка программирования Python, которая составила 28% от общего количества репозиториев, лишь немного отстаёт от него JavaScript — 22%, что тоже является весьма существенным распространением, далее уже со значительным отрывом идут TypeScript — 14%, Go — 10% и Java — 8%, каждый из которых оказался в два раза менее распространённым, чем лидеры списка. Следует отметить, что более трети репозиториев используют несколько языков. Поскольку GitHub изначально создавался как открытый проект, лицензия MIT License встречается в половине репозиториев — 52%, остальные же делят между собой вторую половину Apache License 2.0 — 22%, GNU General Public License v3.0 — 10%, BSD 3-Clause — 5%, другие (GPL v2, AGPL, LGPL и пр.) — 11%.
Далее приведены некоторые примеры анализа и визуализации данных, в частности гистограмма прогнозирования популярности.
Проведённый семантический анализ полученных данных показал два кластера со схожим распределением характеристик, что на данном этапе исследования не позволило установить значимые признаки, влияющие на популярность.
Практические советы для популяризации репозитория:
Привлекайте больше контрибьюторов.
Напишите внятный README.
Сливайте PR хотя бы раз в неделю.
Автоматизируйте рабочие процессы с помощью GitHub Actions.
Используйте лицензию MIT.
