ЯдроКодаподготовка к экзаменам
Подготавливаем текст, источники и редакционные примечания без изменения разметки страницы.
Автор: Казачкин Даниил Михайлович · Обновлено
Разбираем исследование 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.
После фильтрации в выборке остались:
В выборку вошли официальные проекты ASF, не находившиеся в инкубаторе и не перенесённые в Attic; объединённые проекты не считались отдельными, а проекты с одним коммитом исключались.
Один человек мог делать коммиты в несколько проектов. Авторы удалили 77 записей без корректного имени пользователя и в отдельных случаях объединяли разные имена одного человека. Поэтому единицей анализа разумнее считать очищенную учётную запись OpenHub, а не гарантированно уникального человека. Автоматически собранные данные для выбранных проектов сверили с их репозиториями; единственным найденным расхождением была задержка обновления OpenHub. Отдельно три разработчика подтвердили показанные им записи о коммитах.
Коммит в этой работе — показатель активности, а не ценности. Авторы не пытались решить, какой коммит важнее, сложнее или полезнее. Они считали сами события в истории репозитория.
Распределение оказалось сильно смещено в сторону малой группы очень активных авторов:
| Группа | Доля участников | Доля коммитов |
|---|---|---|
| 156 самых активных участников | 3,35% | 50,13% |
| 2 786 участников с 1–50 коммитами | 59,77% | 2,27% |
Эти числа не означают, что малоактивные участники «бесполезны». Один коммит может исправить критическую ошибку, а сотни мелких коммитов могут быть механическими. Исследование показывает неравенство частоты, но не измеряет качество вклада.
Чтобы не ограничиваться общим числом коммитов, авторы рассчитали коэффициент Джини для каждого проекта. Нуль здесь означает полное равенство, а единица — предельную концентрацию активности.
Из 263 проектов:
В исследованной выборке Apache Camel имел самую высокую концентрацию — 0,919. Самое равномерное распределение было у Portal JSF Bridge — 0,301. Это не рейтинг качества проектов: коэффициент говорит только о распределении коммитов между участниками.
Размер проекта сам по себе не объяснил этот перекос. Авторы не нашли заметной корреляции между коэффициентом Джини и числом строк кода, числом участников или числом коммитов. Коэффициенты корреляции составили 0,1189, 0,1255 и 0,1658 соответственно.
Ещё один слой анализа — двудольная сеть из участников и проектов. Связь появлялась, если участник делал коммиты в проект. Затем авторы рассчитали посредническую центральность: упрощённо, насколько часто узел лежит на кратчайших путях между другими узлами.
Корреляция между числом коммитов разработчика и его посреднической центральностью была статистически значимой, но слабой: r = 0,222. Иными словами, большое число коммитов не гарантировало центральное положение в этой сети. Участник, связывавший несколько проектов, мог иметь высокую центральность и при меньшем количестве коммитов.
Здесь тоже важна осторожность: центральность в графе не равна человеческой значимости, экспертности или влиянию на решения. Это только свойство построенной авторами сети.
Само исследование не проверяло процессы конкретной команды и не измеряло риск потери знаний, выгорание мейнтейнеров или скорость онбординга. Поэтому следующие пункты — редакционные выводы, а не результаты статьи.
Большое сообщество не обязательно означает, что текущая работа равномерно распределена. При оценке устойчивости проекта полезно отдельно исследовать, кто регулярно рецензирует изменения, выпускает релизы, разбирает отчёты об ошибках и отвечает за критичные части системы. Эти сигналы не измерялись в исходной работе, но помогают не переоценивать само число зарегистрированных участников.
Авторы намеренно считали активность, а не ценность. Тот же принцип полезен в практике: метрика должна отвечать на конкретный вопрос. Число коммитов может показать частоту зафиксированных изменений, но не даёт готовой оценки их сложности, качества или влияния.
Сильно неравномерная история изменений сама по себе не доказывает хрупкость проекта. Но она даёт повод задать дополнительные вопросы. Может ли кто-то ещё выпустить релиз? Документированы ли критические решения? Есть ли резервные мейнтейнеры? Эти проверки выходят за пределы исходной статьи, но помогают превратить наблюдение в инженерное действие.
Работа с вопросами пользователей, рецензирование, подготовка документации, обсуждение архитектуры и помощь новичкам могут почти не попадать в историю кода. Если смотреть только на коммиты, можно недооценить людей, которые держат сообщество в рабочем состоянии.
Яркие числа легко перевести в слишком сильные утверждения. Поэтому зафиксируем границы работы.
Сила 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. Текст переведён, сокращён, перестроен и дополнен редакционными пояснениями. Упоминание авторов не означает их участия в подготовке или одобрения этой адаптации.
Chełkowski T, Gloor P, Jemielniak D. Inequalities in Open Source Software Development: Analysis of Contributor’s Commits in Apache Software Foundation Projects. PLOS ONE 11(4): e0152976 (2016). https://doi.org/10.1371/journal.pone.0152976. CC BY 4.0. Русскоязычная адаптация подготовлена редакцией ЯдроКода. Упоминание авторов не означает их участия в подготовке или одобрения этой адаптации.
© 2016 Chełkowski et al.
Русскоязычная авторская адаптация: текст переведён, сокращён, перестроен и дополнен редакционными пояснениями. Длинные цитаты из оригинала не использованы.
Иллюстрации и схемы оригинала не переиспользуются. При необходимости для публикации создаются собственные схемы по проверенным числовым данным.