Половина коммитов — от 3,35% участников: исследование проектов Apache

Разбираем исследование 263 проектов Apache: кто вносил основную часть коммитов и почему это не рейтинг ценности разработчиков.

Open source часто описывают как «базар»: множество людей свободно присоединяются к общему делу, и из их независимых усилий вырастает сложное программное обеспечение. Но насколько равномерно распределена реальная работа?

Авторы исследования — Tadeusz Chełkowski, Peter Gloor и Dariusz Jemielniak — проанализировали 263 отобранных проекта Apache Software Foundation. В этой выборке активность была крайне неравномерной: на 156 из 4 661 учётной записи пришлось 50,13% всех коммитов.

Что именно исследовали

Работа опубликована в PLOS ONE в 2016 году. Авторы использовали срез базы OpenHub за июнь 2014 года. OpenHub собирал историю из репозиториев разных систем контроля версий, включая Git, Subversion, CVS, Mercurial и Bazaar.

После фильтрации в выборке остались:

• 263 проекта Apache;
• 1 348 405 коммитов;
• 4 661 уникальная учётная запись авторов коммитов;
• 10 045 099 строк исходного кода по оценке OpenHub.

В выборку вошли официальные проекты ASF, не находившиеся в инкубаторе и не перенесённые в Attic; объединённые проекты не считались отдельными, а проекты с одним коммитом исключались.

Один человек мог делать коммиты в несколько проектов. Авторы удалили 77 записей без корректного имени пользователя и в отдельных случаях объединяли разные имена одного человека. Поэтому единицей анализа разумнее считать очищенную учётную запись OpenHub, а не гарантированно уникального человека. Автоматически собранные данные для выбранных проектов сверили с их репозиториями; единственным найденным расхождением была задержка обновления OpenHub. Отдельно три разработчика подтвердили показанные им записи о коммитах.

Коммит в этой работе — показатель активности, а не ценности. Авторы не пытались решить, какой коммит важнее, сложнее или полезнее. Они считали сами события в истории репозитория.

Половина коммитов — от 3,35% участников

Распределение оказалось сильно смещено в сторону малой группы очень активных авторов:

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

Неравенство видно не только в общей сумме

Чтобы не ограничиваться общим числом коммитов, авторы рассчитали коэффициент Джини для каждого проекта. Нуль здесь означает полное равенство, а единица — предельную концентрацию активности.

Из 263 проектов:

• 100 проектов, или 38,02%, попали в диапазон Джини 0,7–0,8;
• 234 проекта, или 88,97%, — в диапазон 0,6–0,9;
• только 9,51% проектов имели коэффициент ниже 0,6.

В исследованной выборке Apache Camel имел самую высокую концентрацию — 0,919. Самое равномерное распределение было у Portal JSF Bridge — 0,301. Это не рейтинг качества проектов: коэффициент говорит только о распределении коммитов между участниками.

Размер проекта сам по себе не объяснил этот перекос. Авторы не нашли заметной корреляции между коэффициентом Джини и числом строк кода, числом участников или числом коммитов. Коэффициенты корреляции составили 0,1189, 0,1255 и 0,1658 соответственно.

Самый активный не всегда самый центральный

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

Корреляция между числом коммитов разработчика и его посреднической центральностью была статистически значимой, но слабой: r = 0,222. Иными словами, большое число коммитов не гарантировало центральное положение в этой сети. Участник, связывавший несколько проектов, мог иметь высокую центральность и при меньшем количестве коммитов.

Здесь тоже важна осторожность: центральность в графе не равна человеческой значимости, экспертности или влиянию на решения. Это только свойство построенной авторами сети.

Что из этого может вынести инженерная команда

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

1. Смотрите не только на общее число участников

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

2. Не превращайте коммиты в рейтинг людей

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

3. Проверяйте, где сосредоточены знания и полномочия

Сильно неравномерная история изменений сама по себе не доказывает хрупкость проекта. Но она даёт повод задать дополнительные вопросы. Может ли кто-то ещё выпустить релиз? Документированы ли критические решения? Есть ли резервные мейнтейнеры? Эти проверки выходят за пределы исходной статьи, но помогают превратить наблюдение в инженерное действие.

4. Считайте невидимую работу отдельно

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

Чего исследование не доказывает

Яркие числа легко перевести в слишком сильные утверждения. Поэтому зафиксируем границы работы.

1. Коммит не равен вкладу. Не учтены многие виды работы, а размер и ценность коммитов не взвешивались.
2. Данные не описывают весь open source. Выборка ограничена проектами Apache Software Foundation. Это крупная и относительно однородная выборка, но она не гарантирует те же пропорции в других экосистемах.
3. Это исторический срез. База была снята в июне 2014 года. По этой статье нельзя делать вывод о точном распределении активности сегодня.
4. Корреляция не доказывает причину. Анализ описывает структуру данных, но не показывает, почему одни люди вносят больше коммитов, чем другие.
5. Неравенство не равно проблеме. Работа не доказывает, что каждая концентрация коммитов вредит проекту. Она только показывает, что образ равномерной массовой работы не совпадает с измеренной историей коммитов.

Главный вывод

Сила open source не обязательно в том, что все участники делают поровну. В исследованных проектах Apache наблюдалась другая структура: большое сообщество и малая группа, на которую пришлась основная часть коммитов.

Для инженера важен не только сам результат, но и дисциплина чтения метрик. Коммиты помогают увидеть часть работы, но не всю систему целиком. Хороший вопрос не «кто сделал больше коммитов?», а «что именно мы хотим узнать и какие данные для этого нужны?».

---

Источник и условия адаптации

Этот текст — русскоязычная редакционная адаптация статьи Tadeusz Chełkowski, Peter Gloor и Dariusz Jemielniak «Inequalities in Open Source Software Development: Analysis of Contributor’s Commits in Apache Software Foundation Projects», PLOS ONE 11(4): e0152976 (2016), DOI: 10.1371/journal.pone.0152976.

Оригинал распространяется по лицензии Creative Commons Attribution 4.0 International. Текст переведён, сокращён, перестроен и дополнен редакционными пояснениями. Упоминание авторов не означает их участия в подготовке или одобрения этой адаптации.