Почему компании с открытым ядром делают свои проекты только «достаточно хорошими»
25 октября 2022 г.Компании SaaS, построенные на проектах с открытым исходным кодом (также известные как компании с открытым исходным кодом), не заинтересованы в том, чтобы их основной проект был хорошим; а скорее быть достаточно хорошим.
Мало кто будет доверять продукту SaaS, созданному на основе сомнительного базового проекта, поэтому я не утверждаю, что эти проекты плохи. Скорее, они преднамеренно неполные.
Многие из этих компаний с открытым ядром (далее я буду называть их «единорогами») потратили время на создание своего базового проекта, чтобы помочь своим сообществам и повысить популярность.
Однако наступает момент, когда для бизнес-модели SaaS просто невыгодно или экономически невыгодно тратить время на создание функций или поддержку версии программного обеспечения с открытым исходным кодом (OSS). Версия OSS просто служит доказательством того, что покупатель ведет покупателя по воронке продаж.
На протяжении всей этой статьи я буду защищать это утверждение несколькими основными моментами, предлагать некоторые контраргументы и заканчивать обсуждением крайней необходимости обновления монетизации OSS.
Каннибализация
Одно из распространенных опасений единорогов заключается в том, что предложение с открытым исходным кодом снизит продажи их инструмента облачных сервисов. Этот страх небезоснователен.
Рассмотрим пример HuggingFace, чрезвычайно популярного инструмента искусственного интеллекта с более чем 70 тысячами звезд на GitHub. Они повсеместно любимы сообществом, имеют потрясающий основной проект и массовое распространение. Вы могли бы подумать, что с этими похвалами (не говоря уже об их -of-machine-learning/">оценка в $2 млрд), они будут приносить огромный доход.
Тут вы, скорее всего, ошибетесь. Согласно недавнему статья Forbes, HuggingFace принесла менее 10 миллионов долларов в 2021 году. Хотя на эту цифру нечего чихать, и я уверен, что доходы только улучшаются. на 2022 год он вряд ли выдержит титаническое внедрение и оценку OSS. С такой огромной оценкой и растущими ожиданиями дохода возникает два важных вопроса.
- Каковы основные причины?
- Почему такой принятый проект не приносит больше денег?
Ответ на оба эти вопроса заключается в том, что проект OSS слишком эффективен в том, что он делает. Независимо от того, насколько социально выгодно делать пожертвования и поддерживать компании, которые искренне заботятся о своих проектах OSS, потребители и компании редко будут делать это, поскольку наши экономические системы не стимулируют такое поведение. Хотя они предлагают ценные платные услуги, большинство пользователей обращаются к HuggingFace за предварительно обученными моделями, которые доступны бесплатно.
Сообщество HuggingFace — действительно классное место, и я болею за то, чтобы проект был успешным и прибыльным. Однако компании, которые хотят пойти по их стопам, сталкиваются с серьезной проблемой.
Сообщество — это нетривиальное дело
Таким образом, даже если существует потенциальная каннибализация, процветающие сообщества, такие как HuggingFace, в конечном итоге приведут к успешному бизнесу… верно? Большинство единорогов наивно верят, что это так, но повторить этот успех не так просто.
Хотя я уверен, что HuggingFace добьется успеха в долгосрочной перспективе, многие продукты, пытающиеся создать сообщество вокруг своей SaaS с открытым ядром, скорее всего, в конечном итоге создадут прославленный форум поддержки или место для саморекламы. Кроме того, единорогу будет сложно объединить базы пользователей SaaS и предложений с открытым исходным кодом, которые понравятся совершенно разным аудиториям.
Кроме того, такие сообщества, как HuggingFace и dbt, приносят большую пользу, помимо простой поддержки, и многие преданные своему делу люди работают исключительно в открытом доступе. - исходное предложение.
Например, dbt имеет:
- Отличная конференция в Coalesce, которой люди искренне рады каждый год
- Отличные встречи и культура вокруг них
- Прозрачная и честная ориентация на разнообразие, равенство и инклюзивность.
- Отличные бесплатные онлайн-курсы и учебные материалы.
Как указано в этом чрезвычайно продуманном сообщении-ответе на вызов сообщества dbt, генеральный директор Тристан Хэнди упоминает, что в мае у них было 10 штатных сотрудников, занятых в dbt Core, и 8 штатных сотрудников, занимающихся общественной работой. Такая приверженность организации сверху вниз впечатляет и редко встречается в небольших организациях.
В общем, для формирования здорового и динамичного сообщества требуется много самоотверженности. Если единорог не выделит время и деньги на создание этих ресурсов для людей честным образом, его сообщество не будет похоже ни на одну из историй успеха, которые были до него.
Кошмар менеджера по продукту
Так что же остается нашему единорогу? Их размещенный продукт и проект OSS диаметрально противоположны, а созданное ими сообщество представляет собой либо форум поддержки, либо безумную саморекламу, либо и то, и другое.
Что ж, дальше будет еще хуже.
Каждое теоретическое усовершенствование базового проекта ограничено временем их инженеров. Единорог должен постоянно принимать сложные решения о том, следует ли вносить каждую новую функцию в проект с открытым исходным кодом.
Каждая отдельная функция должна быть тщательно проверена, чтобы увидеть, принесет ли она прибыль в качестве собственного предложения. Простые улучшения, которые можно внедрить только в открытый исходный код, требуют выделенных инженеров или отвлечения времени, которое можно было бы потратить на проприетарные функции.
Добавьте слишком мало функций, и сообщество OSS ослабнет, а внедрение замедлится до полной остановки. Предоставьте слишком много функций, и предложение OSS запустит процесс каннибализации вашего размещенного сервиса.
Эта проблема управления продуктом может быть представлена функцией оптимизации, описанной со следующими параметрами, обычно упорядоченными по этому приоритету:
- Исправляйте основные ошибки размещенного продукта в первую очередь.
- Исправьте основные ошибки в предложении OSS как можно скорее.
- Создайте отличительные функции для размещенного продукта.
- Создайте функции для продукта OSS, которые можно будет включить в размещенный продукт.
- Улучшить самостоятельный хостинг продуктов OSS, если есть свободное время (которого обычно нет).
Не все компании соблюдают список приоритетов; Чтобы было ясно, я не утверждаю, что все SaaS-компании работают таким образом. Многие поставят свой продукт OSS на первое место, чтобы завоевать расположение сообщества. Это благородный подвиг, но он не гарантирует награды.
Дело в том, что путь к максимизации прибыли заставит единорога в конечном итоге противопоставить себя своему сообществу открытого исходного кода, нравится им это или нет. Это стало нормой, потому что венчурный капитал осознал, что сообщества с открытым исходным кодом являются мощными маркетинговыми двигателями для нового стартапа, чтобы выйти на переполненные рынки. Далее следует вопрос: как исправить эту структуру стимулов?
Контрпримеры
Прежде чем мы предложим здоровую схему монетизации для экосистемы OSS, я хотел бы признать, что есть несколько здоровых контрпримеров к тому, что я сделал.
Docker, Elastic и MongoDB — отличные примеры успеха с хостингом SaaS с открытым ядром. Однако они потенциально являются большими исключениями из этого правила. Главным отличием здесь является то, что глобальный масштаб, в котором сообщество приняло свои проекты, гарантирует, что даже если они охватят лишь небольшой процент своих пользователей, этот сегмент все равно будет приносить значительный доход.
Вот почему я верю, что HuggingFace в конечном итоге добьется успеха. Хотя каждый должен стремиться к этому, вероятность достижения такого уровня внедрения невелика и обычно является исключением. На пути к этому уровню внедрения компаниям потребуется надежная и устойчивая бизнес-модель, чтобы оставаться на плаву.
Исправление структуры стимулов
Чтобы исправить структуру стимулов, нам нужно решить две половины проблемы. Одна половина обсуждает, что мы можем сделать с компаниями, которые действительно выигрывают от открытого ядра, а другая сторона обсуждает компании, которые этого не делают.
Начнем с первого.
Соглашения о поддержке с открытым исходным кодом полезны
Во имя бесконечного быстрого роста единороги и венчурный капитал поняли, что соглашения о поддержке не могут масштабироваться экспоненциально. Они требуют большого внимания, требуют больших затрат на привлечение клиентов и не всегда стоят того бизнеса, который они приносят.
С другой стороны, облачные расходы сравнительно дешевы, требуют меньше практического внимания и могут масштабироваться в зависимости от вашей инфраструктуры и маркетингового бюджета. Это часто называют ростом, ориентированным на продукт.
Тем не менее, компании с открытым исходным кодом должны признать, что большинство их крупных сделок и логотипов связаны с контрактами на поддержку, а не с расходами на облачные технологии. Даже если ландшафт изменился со времен революции модели поддержки Red Hat, система контрактов на поддержку всегда будет сохранять мутуалистические отношения с поддержкой проекта с открытым исходным кодом. Чем лучше проект OSS, тем меньше проблем возникает и требует практического внимания. Кроме того, компании, заключившие контракты на поддержку, могут запрашивать функции, которые обычно предоставляются более широкому сообществу пользователей.
Кто-то может предположить: «Если все работает идеально, не сократят ли клиенты требуемое участие или отменят план поддержки?» Как правило, нет. Стоимость содержания экспертов обычно намного ниже, чем стоимость SaaS, и всегда необходимо создавать новые функции.
Сверхрост — это круто, но не обязательно для создания устойчивого и эффективного бизнеса. Иногда безумные стремления даже в краткосрочной перспективе приводят к крайне убыточным компаниям.
Ваш хостинг SaaS не обязательно должен быть открытым
Я работал исключительно в компаниях, основанных на проектах с открытым исходным кодом, потому что я очень люблю сообщества разработчиков открытого исходного кода и экосистемы, которые они поддерживают. Тем не менее, я видел, как многие основатели соглашаются на open-core исключительно из-за потенциальной воронки продаж, которую они могут создать с помощью своего «сообщества» с открытым исходным кодом.
Кроме того, единороги считают, что открытый исходный код автоматически означает крутой и модный. Это совершенно неправда; нет ничего менее крутого, чем проект с открытым исходным кодом, который трудно или невозможно разместить самостоятельно. Есть очень много преимуществ, которые можно получить от возможности смотреть на исходный код, большинство из которых уже зафиксировано в соответствии с требованиями безопасности.
Если вы создаете размещенный продукт, серьезно подумайте, сможете ли вы поддерживать бизнес и приносить законную пользу сообществу, прежде чем рассматривать его как открытый. Закрытый исходный код не является автоматически некрутым. Что здорово, так это искренне и честно говорить о том, как вы собираетесь монетизировать свой бизнес.
Продолжение беседы
Учитывая глубину этой темы, определенно есть что сказать о том, как мы можем исправить монетизацию с открытым исходным кодом. Я хочу, чтобы этот пост стал отправной точкой для разговора об этом, и мне бы хотелось, чтобы это развивалось в ближайшие годы.
Перекрестная публикация с: https://www.plural.sh/blog/open-core-companies/
Автор Абхи Вайдьянатха
Оригинал