Методы оценки жизнеспособности проектов (часть 2)

fountain

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

Нужно ли вообще опираться на участников проекта при оценке его жизнеспособности?

Дифференциация участников полезна, но недостаточна. Как бы мне ни нравилась идея использования принципов сохранения биоразнообразия для оценки устойчивости открытых экосистем, в действительности они применимы только к экосистемам.

Оноэ с коллегами изучали только проекты с количеством участников более 100 человек. Для многих проектов с открытым кодом – даже популярных и широко используемых – эта модель не подходит. Существует множество гораздо меньших библиотек, в которых лишь несколько участников и всего один или два ведущих разработчика. Ведущие разработчики небольших проектов могут меньше заботиться о количестве участников, привлечённых и оставшихся в проекте, и больше – об их регулярной активности. Не все проекты развиваются до уровня Django.

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

Допустим, вы ищете конкретную библиотеку для использования на GitHub. Нашли несколько подходящих. Из двух одинаковых проектов, какой лучше выбрать?

Задайте любому разработчику этот вопрос и вам наверняка ответят следующее:

last-commit.png

Выделено: «Последний коммит добавлен день назад»

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

Важность даты последнего коммита предполагает, что ключевым показателем жизнеспособности проекта должен считаться статус «выполнено». Способ выполнения при этом зависит от размеров и задач проекта.

Как можно отследить активность проекта? Сая Оноэ с коллегами предлагает ещё один альтернативный подход, с применением нового показателя: GPPR (Gross Product Pull Requests, Общее количество запросов на включение кода).

Именно запросы на включение кода, а не количество или качество участников проекта, лучше влияют на результат. Неважно, сколько человек принимает участие в проекте или сколько часов они ему посвящают, если все запросы на включение кода при этом просматриваются и выполняются. В силу своей универсальности этот показатель также не зависит от размеров проекта.

Вдохновившись выступлением Ханса Рослинга о Здоровье и богатстве стран, в котором он высказал предположение, что уровень здоровья нации тесно связан с уровнем её благосостояния, Оноэ с коллегами используют показатель GPPR для определения уровня «благосостояния» проектов с открытым кодом:

  • Благосостояние: общее количество запросов на включение кода (GPPR), определяемое как количество запросов, выполненных за месяц.
  • Здоровье: сочетание следующих факторов: 1) доля вклада (определяемая как труд) каждого участника; 2) привлечение новых участников в сообщество [т. е. уровень магнетизма], 3) активная деятельность опытных участников [т. е. уровень клейкости].

С помощью этих определений они описывают поведение некоторых проектов. Например, в их исследовании проект d3 демонстрирует низкую, но регулярную активность, которую проявляют опытные участники.

Хотя здесь есть, что улучшить, лично я для оценки жизнеспособности проекта предпочитаю подход, опирающийся на коммиты и/или запросы на включение кода, которые прошли слияние. В противоположность подсчёту количества участников, статус «выполнено» кажется более надёжным показателем, подходящим для современных открытых проектов любой формы и размера. Такой подход также открывает возможности для более широкого рассмотрения бизнес-моделей стабильных проектов, вместо простого предположения, что для жизнеспособного развития проектам нужно удовлетворять запросы как можно большего количества участников.

Предложения по дальнейшему улучшению

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

Если жизнеспособность равна выживаемости, притом, что активность не обязательно означает жизнеспособность, то такой подход, кажется, лучше всего отвечает на первоначальный вопрос: «Как узнать, что проект успешен?»

Вы можете возразить, например, что, если уделять слишком много внимания коммитам, то игнорируется вклад нетехнических участников (внёсших комментарии или рецензии кода). Однако при другой крайности – множестве комментариев и рецензий, но отсутствии выполненных работ – проект почти наверняка окажется нежизнеспособным.

Кроме того, можно рассмотреть, как соотносятся между собой активность и популярность. Кто-то скажет (по крайней мере, для прикладных проектов), что популярность тоже зависит от активности. Если проект активно не развивается, то его популярность со временем снизится. (И наоборот: активный проект со снижающейся популярностью может демонстрировать «снижение жизнеспособности», как реликтовые леса. Пользователи из таких проектов уходят в другие проекты, которые лучше отвечают их потребностям).

Но всё же эффективно рассматривать активность проекта в сочетании с другими показателями. Как показано во втором варианте модели Оноэ, совокупность вкладов технических и нетехнических участников даёт более полное понимание происходящего. Однако в конечном счёте важнейшим показателем для отслеживания жизнеспособности проекта остаётся статус «выполнено».

Несколько предложений по дальнейшему улучшению:

  • Какой должна быть степень детализации? Например, может быть один крупный запрос на включение кода, который требует времени для слияния, и несколько мелких запросов. Коммиты более детальны, но неодинаковы по размеру. (Справедливости ради надо сказать, что показатель ВВП тоже не всегда учитывает «содержательность» потраченных долларов, поэтому, возможно, простые показатели лучше подходят для сравнительного анализа).
  • Обращайте внимание на интенсивность работы, а не абсолютные цифры: было бы интересно сравнить проекты со стабильной, но низкой активностью и проекты с хаотичными всплесками бурной деятельности. Наподобие модели Ямашиты, возможно, здесь будет несколько уровней жизнеспособности проектов?
  • Что насчёт стабильных проектов? Это меня больше всего беспокоит в использовании показателей активности. Если проект стабильно функционирует и широко используется, но уже почти не требует доработки, его нельзя отмести из-за низкой активности. На мой взгляд, это лучший аргумент для включения в анализ не только запросов на исправление кода, но и присылаемых пользователями сообщений об ошибках, даже если в них меньше ценности. Сообщения об ошибках могут рассказать, является проект стабильным или застойным. Например, если проект малоактивен и содержит много открытых, не остающихся без ответа сообщений, это может означать, что в нём нет ведущих разработчиков.

А отсутствие новых сообщений об ошибках и запросов на включение кода, но стабильные просмотры и выполнение сообщений/запросов, может указывать на жизнеспособность проекта.

 

Источник

 



Рубрики:Анализ, Инвестиции, Мнение, Теория

Метки:

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s