[Перевод] Проверяем фактор автобуса для опенсорсных проектов
Из Википедии: фактор автобуса (англ. bus factor, либо truck factor) проекта — это мера сосредоточения информации среди отдельных членов проекта; фактор показывает количество участников проекта, после потери которых (в оригинале — «попадания» которых под автобус или грузовик, варианты: увольнения, заболевания, рождения у них ребёнка, наступления несчастного случая и других форс-мажорных обстоятельств) проект не сможет быть завершён оставшимися участниками.
Мотивация
Во всех компаниях, где я работал (в строительстве и разработке ПО), в тот или иной момент времени возникал вопрос «фактора автобуса» в управлении разработкой проектов.
Инженеру-строителю вычислить его было крайне сложно, потому что наша отчётная документация была сильно распределена между сотрудниками и существовал дефицит документации. Единственный раз, когда это стало очевидно, случился после увольнения одного из сотрудников — спустя полгода возник срочный запрос RFI (запрос информации) по чьему-то пакету расчётов (хотя официальный пакет должен быть подписан инженером-проектировщиком, а не инженером, непосредственно отвечающим за расчёты). После таких инцидентов нам обещали улучшить документацию, но это неизбежно отходило на второй план, когда все участники группы переходили на новые проекты даже без итогового совещания. Я был свидетелем того, как в долговременных проектах инженерный состав менялся на 100%, поэтому это ужасный антипаттерн.
В разработке ПО можно провести множество параллелей, но по природе нашей работы поставка выпущенного кода — это единственный способ измерения фактора автобуса. По крайней мере, именно её изучали многие исследователи, в том числе и в научной статье, имеющей большое количество цитирований (156, согласно Google Scholar!) с момента её публикации в 2016 году (препринт выпустили в 2015 году). Ша отправил мне статью, а после того, как мы обнаружили её исходные данные и исходный код, это стало идеальным проектом на выходные, который бы позволил, как минимум, получить представление об интересных метриках open source.
В статье используется концепция степени авторства (degree of authorship, DOA), вычисляемая по следующей формуле:
Вычисление фактора автобуса «основано на предположении о покрытии: система столкнётся с серьёзными задержками или имеет вероятность прекращения работы, если текущее множество авторов покрывает менее 50% текущего множества файлов в системе». То есть алгоритм урезает участие в проекте на основании DOA, пока не останется меньше 50% от изначальных файлов.
Методики
Первым делом надо было проверить, можно ли вообще собрать код. Сам алгоритм не менялся с 2018 года, но я редко собираю код на Java. К счастью, инструкции из README сработали почти полностью. В тех же инструкциях, что и для локальной сборки, есть команды docker, но я решил просто создать локальную сборку.
Некоторые из команд были привередливы к директориям вызова. В частности, commit_log_script.sh должен выполняться внутри директории scripts, потому что в противном случае мы получим такую ошибку:
awk: can't open file /Users/mclare/workspaces/Truck-Factor/gittruckfactor/log.awk
source line number 1 source file /Users/mclare/workspaces/Truck-Factor/gittruckfactor/log.awkЗатем нужно выполнить саму программу:
mvn package
cd Truck-Factor/gittruckfactor
java -jar ./target/gittruckfactor-1.0.jar ~/workspaces/numpy ~/workspaces/numpyВывод в случае удачного выполнения будет выглядеть примерно так:
TF = 9 (coverage = 48.74%)
TF authors (Developer;Files;Percentage):
Charles Harris;206;15.28
Bas van Beek;204;15.13
Sebastian Berg;142;10.53
Sayed Adel;138;10.24
Travis Oliphant;116;8.61
Rohit Goswami;87;6.45
Mateusz Sokoł;82;6.08
David Cournapeau;75;5.56
Matti Picus;70;5.19Попробовав её на одном пакете, я захотел проверить все репозитории из исходной статьи, в том числе и parallel, а также другие инструменты командной строки.
Оказалось, что все репозитории из статьи используют веб-сайт, который загружает интерактивные графики D3 на основании скачанных CSV. Мне достаточно было извлечь первый столбец загруженного CSV, который я сохранял в файл (repo_list.txt) для дальнейшего использования.
Клонирование репозиториев
parallel -j 8 git clone ::: $(cat ../meta/repo_list.txt)Эти репозитории весят примерно 64 ГБ!
Для клонирования репозиториев потребовалось большое количество ресурсов. Несмотря на то, что я настроил 8 jobs, процесс клонирования/сборки сразу же «съел» почти все ресурсы моего CPU.
Вывод HTOP
Выполнение анализа
ls ../cloned_repos | xargs -I {} echo "java -jar ./target/gittruckfactor-1.0.jar /Users/mclare/Truck-Factor/cloned_repos/{} {} > results_linguist/{}.txt" | parallel -j 8Рекомендую поначалу выполнять шелл-скрипты с echo, чтобы ещё раз убедиться, что результат получается именно таким, как вы ожидали.
Благодаря параллелизации на выполнение этой команды понадобилось всего около четырёх минут (репозиторий platform_framework_base отставал примерно на две минуты).
Вопросы исходного исследования
Чтобы успеть завершить этот проект за двое суток, мы выбрали следующие первоначальные вопросы:
Как выполнение анализа с помощью
linguistменяет результаты?Что мы ожидаем увидеть от этих результатов для соответствующих пакетов спустя восемь лет?
Результаты
Проведя анализ с помощью linguist, я заметил существенные изменения в покрытии кода и в самом факторе автобуса. В целом я ожидал, что linguist снизит фактор автобуса, поскольку он должен удалить некритичные файлы, например, документацию. Однако в нескольких случаях прогон анализа linguist не возвращал вообще никакого фактора автобуса. В других случаях фактор автобуса даже увеличился. Это меня удивило и заслуживает дополнительного анализа действий linguist, а также удаляемых им из репозиториев файлов.
Я ожидал, что во многих проверенных репозиториях фактор автобуса должен уменьшиться. Прошлое десятилетие показало, насколько сложно быть мейнтейнером опенсорсных проектов, учитывая текущую экономическую ситуацию. Самое неожиданное изменение фактора автобуса произошло в репозитории исходников Linux. В научной статье этот фактор был равен 57, в моём первоначальном анализе он уменьшился до 12, а в анализе linguist — вообще до 8. Примерно в 30% проектов вообще не случилось никаких изменений (в основном в тех, где фактор автобуса равен 1), В 15% он увеличился на 1 (хотя в них изначально фактор был равен всего 1–3), а в 20% уменьшился на 1 или большее значение.
В оригинале статьи вы можете изучить результаты самостоятельно, выбрав в раскрывающихся меню два разных датасета.
На графике ниже показана диаграмма трёх отдельных датасетов, которая также демонстрирует, что существенных улучшений по снижению количества проектов с низким фактором автобуса не произошло.
Дальнейшая работа
На самом деле, это лишь начало исследований того, как подобные инструменты можно использовать для оценки уровня здоровья опенсорсных проектов.
Мне бросился в глаза важный недостающий аспект: анализ проводится только для авторства как метрики, но не для ревью. Можно надеяться, что в случае существенных изменений процесс ревью кода приводит к обмену знаниями, но я не знаю, была ли эта информация получена из логов git, и можно ли это вообще сделать простым способом.
Другие исследовательские вопросы на будущее:
Можно ли воспроизвести результаты научной статьи? (Это непросто, даты получения информации из github не указаны ни в данных, ни в самой научной статье)
Что можно получить из настройки псевдонимов разработчиков в соответствии с опциональными настройками репозиториев? Увеличит ли это потенциально фактор автобуса благодаря объединению действий одного человека?
Можем ли мы воспроизвести другие графики из исходных данных с использованием других данных из Github API, например, графики количества разработчиков?
Может ли мы глубже понять метрику degree of authorship (DOA)? Похоже, существуют магические числа, которые могут указывать на некую линейную регрессию. Кажется, они взяты из других статей.
Можно ли использовать более свежие статьи, ссылающиеся на эту, чтобы лучше оценить характеристики опенсорсных проектов?
Прочие примечания
Другой взгляд на этот эксперимент можно найти в блоге Ша
Для генерации графиков я использовал Observable Plot. Забавно, что D3 оказался одним из тех репозиториев, фактор автобуса которых не изменился и остался равным 1!
Мы форкнули исходный репозиторий и изложили наши находки в spite-driven-development/Truck-Factor
