Но сначала определимся, что 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.
