Приглашение к новой дискуссии:
О жизненном цикле и open source

Сергей Кузнецов

2006-10-29

Миф: Программные продукты категории open source создаются из интереса разработчиков, благодаря их энтузиазму и по причине неприятия ими коммерческого программного обеспечения

У любого программного продукта существует жизненный цикл, состоящий из следующих этапов: проектирование-разработка-отладка-тестирование-внедрение-сопровождение. Последний этап является циклическим и состоит из следующих шагов:

1. Сбор данных об ошибках
2. Сбор замечаний о функциональности
3. Исправление ошибок
4. При накоплении некоторого объема исправлений выпуск промежуточной версии. Переход на шаг 1. Иначе шаг 5.
5. При накоплении некоторого объема замечаний проектирование и разработка новой версии. Иначе шаг 1.
6. Отладка, тестирование, внедрение новой версии. Переход на шаг 1.

Только при поддержке подобного жизненного цикла программа может существовать и использоваться на протяжении долгого времени. Проект может начаться по любой причине (в том числе, и из интереса и энтузиазма), но жизненный цикл должен поддерживаться. Известно, что в коммерческих системах на первые два этапа жизненного цикла программного продукта тратится не более одной трети средств (человеческих и материальных) от общей суммы затрат. Непонятно, почему это соотношение может не выдерживаться для проектов open source.

А теперь заметим, что интерес и энтузиазм программистов присутствует именно на этих первых этапах. Интересно реализовать свою идею и увидеть действительно работающую систему. После этого начинается рутинная, повторяющаяся работа. Если программный продукт не очень большой, то некоторое время эту рутинную работу может выдерживать человек (или группа людей), инициировавший проект. В лучшем случае терпения хватает до конца жизненного цикла продукта, когда его дальнейшая поддержка становится нецелесообразной. Иначе продукт сходит со сцены раньше времени.

С большими продуктами ситуация гораздо сложнее. Для сопровождения требуется достаточно много людей. Если первые два шага теоретически можно выполнить за счет энтузиазма в свободное время или на деньги какого-либо инвестора-альтруиста, то для сопровождения (а может быть, и тестирования) требуются высококвалифицированные специалисты, которым нужно платить деньги, соответствующие их квалификации. Кроме того, на этапе сопровождения должен иметься менеджер проекта. Без единоличного надзора вряд ли удастся соблюсти последовательность шагов и их своевременное выполнение. Для сопровождения крупного программного времени требуется работа нескольких человек в режиме полной занятости.

В целом получается, что если большой проект категории open source доходит до фазы сопровождения, то начинают действовать общие правила поддержки жизненного цикла программных продуктов: должна иметься команда квалифицированных программистов под присмотром опытного менеджера. В лучшем случае в эту команду может войти часть исходных разработчиков, но нужно понимать, что сопровождать программный продукт далеко не так интересно, как проектировать и разрабатывать.

По-видимому, организация фазы сопровождения – это наиболее сложная проблема проектов open source. Требуется придумать нетривиальную бизнес-модель, которая позволит зарабатывать деньги (хотя бы для оплаты труда команды сопровождения) за счет наличия программного продукта, распространяемого бесплатно. Поскольку лично мне очень близка эта проблема, мне нравится слушать доклады, в которых подход open source трактуется как особая форма софтверного бизнеса. Другими словами, можно являться идейным и убежденным сторонником движения open source, можно инициировать интереснейшие проекты, но без тщательного выбора бизнес-модели таких проектов (если они достаточно крупные) вряд ли они смогут существовать на протяжении долгого времени.

Комментарии