OpenStack — две стороны одной медали | Открытые системы. СУБД

Программное обеспечение с открытым кодом оказывает колоссальное влияние на ИТ и общество [1], встраиваясь в инфраструктуру повседневной жизни общества, — по данным различных исследований, больше 90% программных продуктов содержат сегодня компоненты с открытым кодом [2]. Своему успеху они изначально были обязаны добровольным участникам со всего мира, которые реализуют в таких продуктах новые идеи, обеспечивая низкую стоимость и высокое качество Open Source.

Видя перспективы открытого кода, многочисленные компании построили на экосистемах открытого ПО свои бизнес-модели, ориентируясь на возможности инновации [3], уменьшение затрат или получение дохода от вспомогательных услуг. Для достижения своих целей такие компании нанимают разработчиков, которые участвуют в развитии проектов в рамках экосистем открытого кода. Многие известные подобные экосистемы, в том числе Linux, Android и OpenStack, развиваются главным образом благодаря взаимодействию в ее рамках коммерческих компаний разного профиля. В частности, в каждую новую версию OpenStack — комплекса проектов для создания инфраструктурных облачных сервисов и облачных хранилищ — компании вносят в среднем больше 90% кода. Программное обеспечение Open Source с активным коммерческим участием стали называть Open Source Software (OSS) 2.0.

В отличие от волонтеров, главная мотивация коммерческих компаний — получение прибыли. Компании, участвующие в разработке Open Source, могут пытаться контролировать направление развития проекта с целью повышения доходов или отзывать сотрудников во избежание провальных инвестиций. Соответственно, коммерческое участие, с одной стороны, ускоряет разработку, с другой — создает сложности и риски для долгосрочного устойчивого развития критически важных экосистем Open Source.

Чтобы разобраться в специфике совместного участия различных компаний в обширной экосистеме открытого кода OpenStack, была проведена серия исследований. История фиксаций кода OpenStack позволила проанализировать, каким образом в рамках проектов выполняются различные задачи разработки. Также был проведен опрос среди разработчиков — выяснялись их мнения о том, каким образом доминирование коммерческих компаний отражается на проектах с открытым кодом.

Характеристики коммерческого участия

Рис. 1. Ландшафт коммерческого участия в 14-м релизе OpenStack

На рис. 1 представлен ландшафт экосистемы OpenStack — 250 компаний, внесших вклад в 817 проектов 14-го релиза, который характеризовался наибольшей активностью участников за всю историю OpenStack. Выделены восемь моделей участия, три типа взаимодействия и четыре предпочтительных вида задач.

Доля коммерческого участия

За период со времени запуска OpenStack по август 2018 года вышло восемь версий проекта, в создании которых участвовали 490 компаний. В среднем в работе над каждой версией принимали участие 130 коммерческих компаний, которые внесли гораздо больший вклад, чем волонтеры, и сыграли критически важную роль в развитии OpenStack, что подтверждается количеством разработчиков, фиксаций и задач.

Рис. 2. Соотношение объема разработки компаний и волонтеров

Средняя доля корпоративных разработчиков в каждом релизе составляла 80%, а доля выполненных ими фиксаций — 90%. На рис. 2 также представлено сравнение различных задач разработки, выполненных компаниями и добровольцами в 14-м релизе OpenStack. Можно видеть, что большая часть (91%) деятельности всех типов выполнялась именно компаниями.

Объем участия зависит от модели

К OpenStack присоединились сотни компаний из разных сфер бизнеса, в том числе поставщики оборудования вроде Dell, производители процессоров наподобие Intel, разработчики ПО, такие как Red Hat и операторы платформ электронной коммерции вроде eBay. Они подключаются к OpenStack исходя из разных коммерческих потребностей, выбирают разные проекты и задачи, работая над ними по разным схемам.

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

Некоторые компании получают доход напрямую, предлагая пользователям комплексные облачные решения, в том числе сервисы частного и общедоступного облака, услуги развертывания и сопровождения и др. Некоторые компании пользуются OpenStack в собственной рабочей среде, применяя продукты экосистемы открытого кода и внося в нее свой вклад. Компании, получающие прибыль непосредственно от OpenStack, обычно активно участвуют в различных проектах экосистемы и предлагают множество доработок. Те же, перед кем стоят задачи интеграции, выбирают конкретные проекты и ограниченно участвуют только в них. Небольшой объем доработок также вносится представителями пользовательских сообществ и исследовательских организаций.

Взаимодействие и изолированное участие

Опыт компаний, специализирующихся в какой-то одной области, весьма ценен для экосистемы открытого кода, и взаимодействие компаний разного профиля сильно способствует развитию такой экосистемы. Большинство участников OpenStack сотрудничают с другими, в том числе с конкурентами. В рамках некоторых партнерств идет активное целенаправленное развитие конкретных проектов. К примеру, Walmart пользуется дистрибутивом OpenStack от Rackspace, и обе компании делают большой вклад в развитие проекта Ansible, который был основан Rackspace для автоматизации развертывания дистрибутивов OpenStack. Некоторые партнерства, однако, могут быть пассивными и случайными. К примеру, HP и IBM предлагают вычислительные сервисы в составе своих решений OpenStack, в связи с чем обе компании вносят доработки в Nova — проект вычислительной инфраструктуры в составе OpenStack. Подобный характер взаимодействия часто встречается в крупных экосистемах Open Source.

Некоторые компании могут оставаться единственными участниками проектов, особенно когда такой проект отвечает их собственным интересам. К примеру, компания Linbit, поставщик программно-конфигурируемого хранилища, основала и в одиночку выпустила уже шесть релизов проекта drbd-devstack, плагина, который помогает устанавливать бэкенд Linbit Distributed Replicated Block Device для сервиса блочного хранилища OpenStack. Подобные проекты остаются лишь архивами открытого кода, не предоставляя истинных преимуществ Open Source, таких как разработка силами пользователей. Благодаря кооперации одиночные проекты могли бы развиваться эффективнее.

Отличие предпочтений в задачах разработки

OpenStack – две стороны одной медали

В ходе подготовки нового релиза нужно решать разные задачи разработки, например, исправление ошибок и реализация новых функций. В таблице перечислены четыре главные задачи, которые выбирают разные компании: устранение ошибок, разработка функций, реорганизация и параллельная работа над исправлениями и новой функциональностью. Самая популярная задача — исправление ошибок, в этом случае 95% фиксаций кода направлены на устранение дефектов. Обычно это устранение проблем, самостоятельно обнаруженных компанией при использовании OpenStack. Такие компании, вносящие эпизодический вклад в проекты, вряд ли надолго в них задержатся. Около трети всех компаний предпочитают преимущественно заниматься исправлением ошибок и реализацией новых функций и в значительно меньшей степени решать задачи реорганизации — эти три типа задач аналогичным образом распределены в рамках проекта в целом.

По-видимому, бизнес-стратегии таких компаний в отношении OpenStack согласуются с маршрутом развития экосистемы в целом или не влияют на выбор задач разработки. Некоторые компании в основном сосредоточены на новых функциях в связи с реализацией собственных новых проектов или наличием конкретных целей относительно OpenStack, например, ввиду планов по интеграции OpenStack с бизнесом компании она реализует новые плагины или драйверы. Небольшое количество компаний занимается преимущественно задачами реорганизации, например, переименованием, в ограниченном числе проектов. Единственное предпочтение среди всех задач разработки проектов OpenStack имеют 89 из 222 компаний (38%). Обычно такие компании участвуют в проектах на краткосрочной основе.

Дилемма: коммерция и Open Source

Коммерческое участие в экосистемах открытого кода — палка о двух концах. Установлено, что многообразие коммерческих компаний, занятых в проекте Open Source, положительно влияет на число добровольных участников, но в реальности большинство проектов OpenStack сильно зависят лишь от какой-либо одной компании, которая вносит больше половины фиксаций кода. Когда в разработке доминирует единственная компания, это создает угрозу многообразию — ключу к жизнеспособности сообщества открытого кода.

Среди разработчиков OpenStack был проведен опрос по поводу влияния господства одной компании на развитие проекта с открытым кодом. Больше половины считают, что такое доминирование мешает присоединению других участников — мелкие разработчики избегают подключаться к проекту, чтобы не стать «бесплатной рабочей силой» для главного спонсора. Статистика OpenStack показывает сильную обратную корреляцию между господством одной компании и числом других участников в проектах экосистемы. Если такое доминирование продолжительно, проект Open Source утрачивает преимущества, обеспечиваемые совместной разработкой, и по мере ухода мелких участников рискует быть заброшенным.

Поскольку компании руководствуются соображениями прибыли, когда кто-то из них достигает своих бизнес-целей в отношении OpenStack или выясняется, что таких целей достичь нельзя, такой участник выходит из проекта. В компании Aeode, например, объясняют ее уход из OpenStack провалом попытки создать коммерческое общедоступное облако. Подобное происходит часто — больше половины компаний, подключившихся к какой-либо версии OpenStack, позднее вышли из экосистемы. Высокая текучка компаний может привести к снижению качества кода (поскольку код, изначально внесенный краткосрочными участниками, остается без изменений) и продуктивности (из-за быстрого оттока разработчиков). Для проектов, развиваемых единственной компанией, риск прекращения особенно велик. В частности, в составе седьмого релиза OpenStack компания Rackspace начала проект под названием quark по созданию сервиса обеспечения масштабируемости сетей, а на 15-м релизе она его покинула, и с тех пор он неактивен. Уход на полпути негативно влияет на сообщество открытого кода и приводит к тому, что изначальные вложения времени и кадровых ресурсов пропадают. При этом стоит отметить, что планирование стратегии долговременного участия может быть непростым.

Баланс коммерческого участия и устойчивости

Итак, коммерческое участие может обеспечить процветание сообщества Open Source, но может и создать риски для его долгосрочной устойчивости. Чтобы избежать этого, нужно следить за соответствующими признаками и при необходимости принимать меры.

Шаткий баланс между прибылью и устойчивостью

При вступлении в проект Open Source или корректировке существующей стратегии участия компании могут придерживаться правил, диктуемых различными моделями участия и сотрудничества. Отправной точкой при этом будут цели компании в отношении проекта Open Source, а конечной — выбор проектов, задач разработки и партнеров по совместной работе. К примеру, если стоит цель задействовать продукт с открытым кодом в собственной рабочей среде, то компании нужно вносить большой вклад в соответствующую экосистему, чтобы быть в курсе развития ее проектов, и выстраивать сотрудничество с поставщиками решений на основе ПО с открытым кодом для обеспечения оперативной реакции на свои запросы. Оценка характеристик участия (интенсивности, масштаба и целенаправленности), партнерских связей и предпочтений в задачах позволит выстроить систему мониторинга, помогающую участнику реализовать свою роль в развитии экосистемы открытого кода и перенимать опыт других компаний с целью повышения эффективности и качества вклада в проекты.

Стоит отметить, что активность OpenStack в целом уменьшается: если в 14-й релиз сделали вклад 222 компании, то в 24-й — только 86. Возможно, это происходит по технологическим причинам, а возможно, снижение указывает на низкую эффективность коммерческого участия в OpenStack. В частности, часто встречается доминирование какой-либо одной компании в разработке проекта для максимизации прибыли или быстрого достижения коммерческих целей, а именно, в разработке 70% проектов каждой версии OpenStack преобладает какая-либо одна компания. Это удерживает от присоединения другие компании и добровольных участников, что ведет к утрате преимуществ открытого кода, обеспечиваемых пользовательской инновацией. Кроме того, когда главенствующая компания покидает проект, возникает риск для его устойчивости. Соответственно, опыт OpenStack не стоит копировать в других экосистемах — их коммерческим участникам следует уравновешивать краткосрочную выгоду и долгосрочную устойчивость.

Для принятия решений о корректировках в системе мониторинга можно устанавливать «линии тревожной сигнализации». Например, если проект целиком развивается и поддерживается силами одной компании — это сигнал о том, что он не привлекает других участников. Другой возможный сигнал — малый объем сотрудничества, ведь при большом количестве партнеров растет эффективность разработки. Еще один тревожный знак — фокусировка лишь на одной задаче, поскольку в таких случаях участие обычно краткосрочное. Чтобы обеспечить взаимную выгоду коммерческих участников и сообщества, компаниям нужно оценивать влияние своего участия в проектах OpenSource и тщательно балансировать соображения выгоды и устойчивой эволюции экосистемы.

Регулирование коммерческого участия сообществом

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

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

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

***

Коммерческие компании присоединяются к проектам открытого кода ради преимуществ Open Source, в том числе обновлений, которые создаются силами пользователей, и низких затрат на исследования и разработку. Движимые своими бизнес-потребностями, компании вносят вклад различного масштаба, формируя оживленную экосистему, как в случае OpenStack. Но ориентация на прибыль неизбежно создает риски для сообщества. Компании начинают контролировать направление развития проекта, играя в нем доминирующую роль, и тем самым наносят ущерб многообразию сообщества, вызывая уменьшение притока волонтеров. Возглавив какой-либо проект, компания может со временем его покинуть и обречь на прекращение. Чтобы обеспечить нужный баланс коммерческого участия в проектах открытого кода, можно следовать определенным правилам. В частности, сообщество может тщательно контролировать деятельность компаний и принимать меры при появлении тревожных сигналов. В целом достаточно спорная тема сообщества открытого кода, существующего в условиях активного участия коммерческих компаний, требует постоянного анализа.

Литература

1. Zhou M., Chen Q., Mockus A., Wu F. On the scalability of Linux kernel maintainers’ work. In Proc. 2017 11th Joint Meeting Found. Softw. Eng., ACM, pp. 27–37. DOI: 10.1145/3106237.3106287.

2. Harutyunyan N. Managing your open source supply chain-why and how? // Computer. 2020, vol. 53, no. 6, pp. 77–81. DOI: 10.1109/MC.2020.2983530.

3. Harhoff D., Henkel J., Von Hippel E. Profiting from voluntary information spillovers: How users benefit by freely revealing their innovations // Res. Policy. 2003, vol. 32, no. 10, pp. 1753–1769. DOI: 10.1016/S0048-7333(03)00061-1.

Юйся Чжан (yuxiazh@bit.edu.cn) – доцент, Хао Хэ (heh@pku.edu.cn) – научный сотрудник, Минхуэй Чжоу (zhmh@pku.edu.cn) – профессор, Пекинский университет.