884
0
0
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники
Назад

Как делать бизнес с помощью open source и почему это проблема, а не счастье?

Время чтения 2 минуты
Нет времени читать?
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники
884
0
0
Нет времени читать?
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники

Всем здравствуйте, на связи Андрей Федоров с очередной статьей про то, чем богата жизнь open source. В предыдущей статье я писал, что 2023-й, на мой взгляд, стал годом водораздела, что открытое ПО вступило в новую эру. Стало понятно, что подобным проектам нужна бизнес-стратегия. В этой статье поговорим про то, как сегодня делают бизнес на open source.

Как делать бизнес с помощью open source и почему это проблема, а не счастье?

Но сначала определимся, что open source — это не бизнес-модель, а модель распространения программного обеспечения. 

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

Параллельно развивались Red Hat, GitLab, HashiCorp и многие другие успешные компании, использовавшие различные бизнес-модели для своих open source проектов. Разумеется, все они предлагали и предлагают свои продукты и услуги большому сообществу инженеров и других пользователей и не чуждаются коммерческой разработки по необходимости. Но главная их заслуга в том, что они нашли правильную для себя бизнес-модель. 

Рассмотрим несколько основных. 

Какие бизнес-модели используют крупные разработчики open source 

Open Core. Самая зрелая модель, успешно опробованная и продвинутая в массы Red Hat, подразумевает отдельные версии для сообщества и корпоративных клиентов. 

Community-версия чаще всего лежит на GitHub, а Enterprise-версия доступна для заказа на сайте компании. Обычно Community достаточно для полноценного функционирования и расширения системы, а в Enterprise включены дополнительные возможности, актуальные для больших компаний, техподдержка различных уровней, оформление договора и другие важные для бизнеса вещи. Бизнес хочет внедрять решения и иметь гарантии юридического плана. 

Из популярных мировых проектов это Confluent, GitLab, MongoDB (до недавних пор, когда они сменили лицензию на SSPL), Elastic (до недавних пор). Крупные российские — Deckhouse от компании «Флант», Tarantool от VK, Postgres Professional, Arenadata. Все эти компании также занимаются профессиональным консалтингом и внедрением. 

Консалтинг. В отличие от Open Core, в данной модели необязательно вообще что-то разрабатывать, хотя это и считается хорошим тоном. 

Профессиональный консалтинг может осуществлять любая компания с командой экспертов. Обычно это дополнительный доход для Open Core модели. Здесь вспомним Percona, Cloudera. 

Облачный сервис. После того как облачные провайдеры, такие как Azure, AWS, GCP и целая плеяда более мелких компаний, начали инвестировать в PaaS-сервисы, возникла дилемма. На тот момент (это был примерно 2017 год) уже не было модно писать свои проприетарные сервисы со своими проприетарными протоколами. Они часто были несовместимы с различными открытыми стандартами и вызывали вопросы у разработчиков по их будущему. Всё это привело к настолько большим изменениям, что я решил вынести это в отдельный раздел. 

Облака раздора

Создание managed-сервисов типа Azure Kubernetes Service, сервисов на основе Elastic всколыхнуло open source сообщество. В попытке защитить свои коммерческие интересы компания HashiCorp, разработчик Terraform, в августе 2023-го сменила свою лицензию с copyleft на Business Source License (BSL). Суть лицензии за вычетом нюансов: больше ограничений на то, как внешние пользователи коммерциализируют разработку HashiCorp, особенно в областях с потенциальной для них конкуренцией. Это не просто не улучшило, но ухудшило ситуацию, так как у облачных вендоров оказалось достаточно ресурсов для собственной разработки, а сообщество и клиенты не оценили внезапных смен лицензии. Часть вендоров форкнула Terraform в OpenTF, переименовала в OpenTofu и отдала под шефство Linux Foundation. 

В 2019-м компания Sentry перешла с BSD 3-Clause на BSL по примерно тем же причинам, что и HashiCorp. Но, вероятно решив сгладить переход, создала новую лицензию Functional Source License (FSL), похожую на BSL, только с нюансами. Например, в BSL откат на Apache-лицензию через четыре года, а в FSL — через два. Тем же путем пошли MongoDB, CockroachDB и многие другие. В 2024-м аналогичный шаг сделал Redis. 

Сложно однозначно сказать, какая из моделей более выгодна. Например, в Open Core достаточно сложно определить границу между тем, что лежит на GitHub, и тем, что продается. Также надо постоянно обучать сотрудников, включая разработчиков, которые не всегда понимают бизнес-приоритеты и могут выкатить нужную для Enterprise фичу в open source. 

С другой стороны, профессиональный консалтинг — дело затратное и непрогнозируемое по проектам. Компании необходимо постоянно держать штат высококвалифицированных специалистов. С учетом затрат на оплату их труда доход может не давать впечатляющих цифр. Например, в 2021 году HashiCorp сообщал, что консалтинг принес 5 миллионов долларов, тогда как техподдержка и лицензии — почти 200 миллионов. 

Заключение 

Jacob Kaplan-Moss, один из создателей Django и важный деятель в Django Software Foundation, резюмировал свой обзор проблем с open source тем, что каждая найденная модель каждым разработчиком — это победа для всех нас. Это хорошо отражает текущую ситуацию: мы ищем путь там, где перепуталось слишком много интересов. 

Мир разделился на несколько лагерей. Первый лагерь, индивидуальные мейнтейнеры и контрибьюторы, недоволен отсутствием вклада от пользователей. 

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

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

Обращу внимание, что даже эта ситуация — блеклый аналог реальной юридической жизни. В реальной жизни мы сталкиваемся с тем, что сначала продукт становится свободным, его начинают активно использовать и продавать, а потом вводят закон, продлевающий авторское право (и лицензию) на 50 лет. В эту тему я углубляться не буду, замечательно ситуация описана в статье «Как в СССР копирайт продлевали».

Неудачные коммуникации, поспешные выводы и большое внимание со стороны СМИ, часть из которых вынуждена делать выводы на основе неполных данных, делают свое дело: риски повышаются. И, возможно, единственный выход — это превратить проекты с open source лицензиями в non-profit. 

Комментарии0
Тоже интересно
Комментировать
Поделиться
Скопировать ссылку
Telegram
WhatsApp
Vkontakte
Одноклассники