Max Home IndustryВ эпоху, когда мы все больше полагаемся на программное обеспечение с открытым исходным кодом, важно знать, как нанимать и удерживать основных разработчиков — тех, которые являются ключом к выживанию, устойчивости и успеху проекта. Попытка сделать это исходит из Бразилии, которая будет представлена в Швеции.
Джейлтон Коэльо, Марко Тулио Валенте, Лусиана Л. Сильва, Андре Хора хотели понять, что мотивирует разработчиков брать на себя ключевую роль в проектах с открытым исходным кодом (FLOSS). Их доклад, содержащий результаты опроса 52 разработчиков, которые были основными участниками проектов GitHub, был принят на CHASE 2018: 11 — й Международный семинар по кооперативным и человеческим аспектам разработки программного обеспечения, который является частью 40-й Международной конференции по разработке программного обеспечения, проходящей 27 мая-3 июня 2018 года в Гетеборге, Швеция.
Опрос начался с предпосылки, на которую указывали предыдущие исследования, что большинство проектов GitHub зависят только от одного или двух основных разработчиков, определяя «основных разработчиков» как:
те, кто отвечает за разработку, внедрение и поддержание наиболее важных функций в проекте, а также отвечает за управление проектом, планирование и управление его эволюцией
Для исследования команда рассмотрела 5000 лучших проектов GitHub, ранжированных по популярности с использованием их количества звезд. Затем они отбросили непрограммные проекты, такие как книги и списки (61 репозиторий), неактивные проекты без фиксаций за последние 6 месяцев (830 репозиториев); незрелые проекты менее 3 лет (1450 репозиториев). Они также проигнорировали проекты без кода в топ-100 самых популярных языков в индексе TIOBE, что привело к 397 проектам в HTML. CSS и Markdown удаляются. В результате осталось 2262 проекта, из которых 1256 репозиториев (55%) принадлежат организациям и 1006 (45%) — отдельным пользователям. Проекты в основном реализуются на JavaScript (696 проектов, 31%), за ними следуют Ruby (232 проекта, 10%) и Python (230 проектов, 10%).
Графики скрипки ниже показывают распределение возраста (в месяцах), количества участников, количества коммитов и количества звезд выбранных проектов без учета выбросов. Медианные показатели составляют 59 месяцев, 50 участников, 826 коммитов и 3,1 тыс. звезд соответственно.
Чтобы определить основных разработчиков, исследователи рассмотрели долю коммитов, сделанных каждым участником проекта. Используя их настроенную эвристику на основе коммитов, более половины проектов имели только одного или двух основных разработчиков, и средний процент коммитов основных команд составляет 81%, а средний процент коммитов выбранных основных разработчиков составляет 19%.
Исследование фокусируется на мотивации тех, кто недавно стал основными участниками, и поэтому следующим шагом был отбор разработчиков, которые стали основными участниками в последний год каждого проекта. Таким образом, у них остался список из 380 разработчиков. После удаления тех, у кого не было публичного адреса электронной почты на GitHub, остался 151 потенциальный участник опроса.
Этим участникам было отправлено электронное письмо с двумя частями. Во-первых, он включал имя разработчика и данные о его/ее проценте коммитов в проекте. Вторая часть включала три открытых вопроса о его/ее вкладе в проект:
Что побудило вас внести свой вклад в этот проект?
Какие характеристики и практики проекта помогли вам внести свой вклад?
С какими основными препятствиями вы столкнулись, чтобы внести свой вклад?
В общей сложности было получено 52 ответа (охватывающих различные проекты), т. е. доля ответов составила 34%
Вопросы были открытыми, поэтому для интерпретации ответов на опрос использовался тематический анализ. Результаты обобщены в трех таблицах.
Общее число мотиваций в этой таблице составляет 66 , что на 14 больше, чем число респондентов, участвовавших в опросе, поскольку из ответа человека можно извлечь более одной темы. Наиболее распространенной причиной участия в проектах FLOSS было добавление необходимых функций или в целом повышение производительности проекта, который они фактически использовали. Следующей наиболее цитируемой причиной была приверженность идеалу открытого исходного кода, выраженному в этом ответе:
Я также влюблен в идею о том, чтобы люди бесплатно делились инструментами, чтобы помочь построить лучший мир и способствовать научному развитию и улучшению жизни людей.
Анализ характеристик и практики, которые помогали или мешали отдельным лицам вносить свой вклад, был разделен на технические и нетехнические, и именно последние преобладали.
Среди этих основных вкладчиков положительные факторы упоминаются чаще, чем отрицательные. Общее число ответов в таблице 2 составляет 77, 50 технических и 27 нетехнических. В таблице 3 приведено только 60 ответов, и опять же 27 из них являются нетехническими, а остальные 22-техническими.
Наиболее распространенным ответом за обе таблицы является «Дружественное сообщество», упомянутое 13 людьми. Напротив, есть только 4 комментария о конфликте или враждебности. Главная негативная нетехническая тема «Нехватка времени у руководителей проектов» упоминалась 8 раз, в то время как обратный позитивный аспект «Доступность арендаторов проектов» упоминался 11 раз. Среди технических препятствий преобладали размер и качество кодовой базы или дизайна проекта, а затем нехватка документации, упомянутая 3 раза, наравне с отсутствием тестов и языка программирования. С другой стороны, «Документация» была признана полезной 8 людьми, а модульные тесты-9 людьми. Только 3 ответа сочли язык программирования полезной характеристикой.
Конечно, проблема с заданием открытых вопросов заключается в том, что вы полагаетесь на воображение людей, чтобы найти ответы. Если бы были конкретные вопросы по основным техническим и нетехническим аспектам-возможно, шкалам Лайкерта для качества кодовой базы, Языка программирования, Документации, Дружелюбия Сообщества, доступности руководителей проектов, — картина могла бы быть иной.
С другой стороны, сила такого опроса заключается в том, что исследователи не заранее оценивают ответы. Их статья на Chase 2018 имеет название Как привлечь основных разработчиков к FLOSS? Дистилляция их выводов из этого опроса должна дать некоторые хорошие, даже если довольно очевидные, указатели, в том числе:
Создайте дружественное сообщество
Убедитесь, что руководители проектов реагируют на участников
Избегайте сложности проекта
Держите код ясным и чистым
Включить модульное тестирование
Предоставьте полную документацию
Смогут ли они также придумать стратегию для достижения всех этих целей одновременно-это другой вопрос!