Проверяем фактор автобуса для опенсорсных проектов

Из Википедии: фактор автобуса (англ. 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.

Выполнение анализа

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