Исследование экономической эффективности моделей разработки открытых проектов
Генрик Инго (Henrik Ingo), исполнительный директор компании Monty Program AB, занимающейся развитием СУБД MariaDB и предоставлением альтернативной поддержки MySQL, опубликовал результаты исследования, оценивающего с экономической точки зрения наиболее популярные проекты СПО, сравнивая модели управления и размеры сообществ разработчиков, а также рассчитывая рыночную стоимость большого сообщества.Изучив более или менее полный список наиболее популярных открытых проектов и сопоставив их размеры с моделью управления, эксперты получили однозначные, и, возможно, в каком-то смысле неожиданные результаты:
- Существует 9 проектов (Linux-ядро, KDE, Apache, Eclipse, Perl+CPAN, Mozilla+Addons, Gnome, Drupal и GNU), которые выделяются на фоне остальных как просто огромные - примерно в 10 раз больше других. Эти проекты, занесённые в категорию "XtraLarge", развиваются по модели коллективной разработки сообществом под управлением некоммерческого фонда или организации. Ни один проект, разрабатываемый каким-то одним-единственным вендором, на сегодняшний день и близко не подошёл к подобным масштабам.
- Похоже, что существует "невидимый предел", ограничивающий рост крупных проектов, управляемых только одним вендором (MySQL, Qt, OpenOffice, Mono, JBoss);
- На фоне хорошо известного и непостижимого масштаба и скорости развития Linux-ядра, и того факта, что преимущества проекта, управляемого на основе коллективного сотрудничества, стали восприниматься как общеизвестные истины, факт существования девяти проектов, бесспорно выделяющихся на фоне других, стал удивительным статистическим открытием. Это очень серьёзный результат, свидетельствующий в пользу модели управления некоммерческим фондом/организацией.
- Другим фактом, подкрепляющим этот результат, является чёткий отрыв между группой проектов XtraLarge и другими проектами, что укрепляет доверие к правильности полученных результатов. Даже если допустить, что данные, лежащие в основе этого заключения, не совсем точны, всё равно ясно, что ошибок, которыми можно было бы объяснить разницу подобного масштаба, в процессе исследования допущено быть не могло.
- Модульная архитектура является обязательным условием процветания и развития open source проекта. Конечно, это рекомендуется для любого программного продукта, но в open source это является предпосылкой для распределённой разработки, типичной для проектов СПО. Легко заметить, что все проекты в категории XtraLarge либо имеют модульную архитектуру (Linux, Eclipse, Perl+CPAN, Mozilla+Addons, Drupal) либо состоят из набора отдельных программ (KDE, Apache, Perl+CPAN, Gnome и GNU).
OpenJDK, подконтрольный компании Oracle, возможно станет исключением из правила, особенно с того момента, как IBM отказалась от поддержки Apache Harmony в пользу OpenJDK. Хотя вокруг OpenJDK и существует сообщество масштаба проектов категории XtraLarge, что является впечатляющим достижением Sun и Oracle, тем не менее путь развития этого проекта не может считаться типичным для основной массы проектов в open source: Java приобрела сегодняшние масштабы и значение будучи проприетарным продуктом, а прекращение поддержки Apache Harmony компанией IBM явно стало итогом какого-то неофициального и довольного серьёзного давления со стороны Oracle. Подобная стратегия грубой силы просто невозможна в большинстве открытых проектов, имеющих тенденцию к попаданию в категорию XtraLarge.
Сравнение относительной массы инвестиций Red Hat и Novell в разработку Linux-ядро показало, что как первый так и второй по величине эти Linux-вендоры совершенно очевидно имеют прибыль от внесения своей доли в коллективное сотрудничество. Red Hat - это крупнейший разработчик Linux-ядра, на чью долю приходится 12% всего вклада, и который владеет гораздо большим, относительно размера вклада, процентом рынка - 62%, что позволяет утверждать о леверидже (соотношение вложений к полученному доходу) равном 5x. У Novell значение почти такое же большое, с 7.6% долевого вклада в разработку компания владеет 29% рынка, соответственно леверидж равен примерно 4x.
Далее был сделан вывод о том, что, если бы Linux-ядро развивалось только усилиями RedHat, как единственного вендора, то потраченные на разработку усилия в итоге были бы в 10 раз меньше объёма работы всего Linux-комьюнити сегодня, что не противоречит вышеуказанному наблюдению о том, что XtraLarge комьюнити/проекты в 10 раз больше проектов, управляемых одним-единственным вендором.
Из всего вышесказанного проистекает очевидная рекомендация для вендоров, участвующих в open source-разработках и бизнесе: необходима ориентация на участие в проектах, развиваемых коллективом сотрудничающих друг с другом членов сообщества. Стандартная и привычная форма управления в таких проектах - некоммерческая организация. Поскольку изначальный единственный вендор, как правило, является и самым вероятным кандидатом на роль ведущего вендора также и в совместно развиваемом проекте, то этот вендор может практически рассчитывать на десятикратный рост как проекта так и продукта, но также и на 10-кратное увеличение целевого рынка, доля в 50% от которого ожидаемо будет принадлежать этом вендору.
При расчётах применялась следующая методология: было использовано несколько списков проектов СПО из которых были выделены самые популярные проекты в мире. Были использованы источники, перечисляющие самые популярные пакеты в Debian и Ubuntu, список наиболее часто скачиваемых программ на SourceForge, дополненные коротким списком больших и важных проектов, не выявленных в вышеуказанных выборках
Далее были оценены размеры сообщества для каждого из выбранных проектов. Для наиболее крупных проектов (Linux, Apache, KDE, Gnome и Eclipse) были сделаны отдельные замеры и подсчёты по объёму и структуре процесса разработки, для остальных проектов были использованы данные OHLOH.net. После промежуточных таблиц и графиков проекты в итоге были сгруппированы по размеру, с категориями XtraLarge, Large и Medium (огромный, крупный и средний), а также скорректированы относительно модели управления, которая, согласно известным данным, применяется в каждом проекте.
| Размер сообщества | Некоммерческая организация | Вендор | "Просто проект" |
| Огромный 1000+ разработчиков 100+ коммитов/день | Linux-ядро, KDE, Apache, Eclipse,Perl+CPAN, Mozilla+Addons, Gnome, Drupal | - | - |
| Крупный 20-200 разработчиков 50-100 коммитов | GCC, PHP+PEAR, Python, Samba | MySQL, Qt, OpenOffice, Mono, JBoss | - |
| Средний | GIMP | Subversion, GhostScript, Wordpress | phpMyAdmin |
| нет данных | Xorg, инструментарий GNU | OpenJDK | - |
Некоторые наблюдения и замечания:
- У всех больших проектов существует та или иная форма управления, в виде единичного вендора или не-коммерческой организации. В топовой категории XtraLarge разместилось 9 проектов (считая и GNU, для которой данных нет).
- OpenJDK может стать первым проектом, управляемым единичным вендором, который, судя по тенденции развития, перейдёт в категорию XtraLarge
Крупные проекты, управляемые единичным вендором, имеют тенденцию к противоречивости:
- MySQL: финансовая звезда, но на текущий момент претерпел несколько форков; огромные усилия прилагаются на текущий момент просто к тому, чтобы проект остался жив.
- OpenOffice: типичный проект для Sun, застой и отсутствие менеджмента с 2000 года; на сегодня создан удачный форк, все дистрибутивы немедленно подключились к разработке и 77 новых контрибуторов присоединилось к проекту в течение 2 месяцев.
- Mono: фундаменталисты из FOSS всё равно бойкотируют проект по причине его .NET-корней, но остальное сообщество факт управления единственным вендором не волнует.
- Qt: технически совершенен, но потерял тотальное доминирование, разделив рынок с GTK+ (в результате слишком плотного контроля со стороны Trolltech). С финансовой стороны всё в порядке, проект куплен компанией Nokia в 2008 году;
- JBoss: спорных моментов со стороны комьюнити не возникало, но пережил атаку (и выжил) со стороны Apache Geronimo, проекта, до недавнего времени развиваемого компанией IBM.
- OpenJDK: после того, как Oracle заставила IBM стать контрибутором проекта, скорей всего перейдёт в категорию "XtraLarge ".
Полный текст статьи читайте на OpenNet
