В поисках идеальной модели лицензирования

в 12:35, , рубрики: open source, лицензирование, сообщество

Наверняка вы знаете о лицензиях MIT, GPL, BSD, Apache и тому подобных. Предполагаю, что превалирующее большинство читателей этой статьи ярые приверженцы Open Source и ненавидят проприетарщину. Правда, некоторые люди не особо различают понятия “открытый” и “бесплатный” софт, но не суть. Я предлагаю обсудить плюсы и минусы текущих подходов, и поразмыслить об устройстве более эффективной экосистемы разработки сложных программных продуктов сообществом независимых разработчиков.
В поисках идеальной модели лицензирования - 1

Пропускаем картинку для привлечения внимания

Лицензирование и монетизация сегодня

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

Теперь о лицензиях. Крайние полюса — это GPL, которая всячески препятствует программисту в защите своих разработок, и проприетарное ПО, с закрытым исходным кодом и в довесок с юридическо-административным аппаратом. Остальные модели лицензировании болтаются где-то в эпсилон-окрестностях. Мне же кажется, что истина где-то посередине.

Зачем придумывать что-то новое, скажете вы, вот, мол посмотрите как все классно у Линукса. Система развивается, все хорошо, вокруг операционки крутятся компании, зарабатывают бабки, некоторые даже особо отличились. Но если присмотреться внимательнее, то увидите, что основной вклад вносят крупные корпорации Intel, Red Hat, Samsung, IBM и т.д. К тому же, Red Hat продает свой Enterpise, как бы завуалировано это не звучало: вы покупаете пакет услуг, но если не нравится, то берите другие дистрибутивы ибо, внезапно, корпоративное соглашение Red Hat дополняет универсальную общественную лицензию GNU GPL.

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

Приведу слова Сергея Голубева:

“Открытая модель способствует вовлечению в разработку бесплатных помощников, но не гарантирует проекту прибыли. Закрытая — способствует получению денег, но исключает создание сообщества. И то, и другое — неэффективно, поэтому реалии требуют нахождения баланса интересов.”

В качестве примера рассмотрим ситуацию с Drupal: декларируется наличие тысяч готовых модулей на все случаи жизни, но активно разрабатываются лишь сотня-другая, остальные заброшены, потому что разработчики не мотивированы их поддерживать и, зачастую, написаны модули под какую-то частную задачу, а выложены просто из-за повышенного чувства собственной важности.
Еще вопрос: почему же руководители веб-студий зачастую используют платные CMS, когда можно использовать бесплатные? Может потому, что им так проще организовать продажи и окупить зарплату продавца уже на этапе продажи коробки, а может он действительно получает лучшее качество продукта?

Устройство рынка

Для примера возьмем всем известный рынок сайтостроения. Клиентским бюджетом распоряжаются веб-студии и справедливо оставляют себе основную часть пирога:
В поисках идеальной модели лицензирования - 2

И из этого пирога разработчикам достается мизерная часть или совсем ничего, если это открытый и бесплатный софт :(

Как же выкручиваются производители бесплатного ПО:

  • Самое очевидное: сами занимаются созданием сайтов;
  • Предоставляют бесплатное решение в облаке. Клиенты: частники и малый бизнес. Выжить можно только за счет массовости.
  • Подбирают прочие крошки со стола, например, темы оформления. Не особо устойчиво, всё равно переделывать под конкретный проект и поэтому проще содрать идею, чем платить.
  • Обучение, консалтинг. В России с этим несколько сложнее.
  • Предоставление платных версий бесплатной программы. Тут проблемы с лицензированием и защитой от воровства. Код-то открытый.
  • Платные инструменты для работы с бесплатным ПО, например, среда разработки.
  • Ну и для полноты модели: продажа железа, рекламы и данных (не код)

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

Экосистема открытого сообщества будущего

Давайте перейдем к конкретике. Для примера возьмем разработку некого фреймворка для многофункциональных бизнес-систем. Она может включать коммерцию, управление бизнес процессами и сотрудниками, создание сообществ и т.д. Причем, не отдельные куски типа CMS, CRM, а объединенную единой логикой систему (операционную среду для бизнес-приложений).
Как создать условия, чтобы разработчики отдавали на открытый рынок свои наработки и знали, что каждое использование принесет им определенный доход, но, в то же время, затраты на разработку должны быть минимальны? Вполне жизнеспособным вариантом может оказаться идея, что ядро фреймворка должно быть совершенно бесплатным, а решения и модули платными.

В реальной жизни существуют следующие процессы:

  • Разработка архитектуры фреймворка и базовых решений.
  • Разработка модулей и решений.
  • Распространение (продажа) кода.
  • Обновления кода.
  • Хостинг.
  • Облачные услуги.
  • Контроль соблюдения условий лицензий (авторское право, воровство).
  • Внедрения, консалтинг, обучение, сопутствующие услуги, например, продажа дизайна.
  • Эксплуатация.

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

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

Схема распределения финансов

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

Разработка

Разработчики создают отдельные модули для для своих или чужих решений, назначают им цены. Естественным механизмом регулирования цены станет конкуренция со стороны других разработчиков. Цена должна быть такой, чтобы разработчику решения или сборки выгоднее и быстрее было включить в поставку чужой модуль, чем писать свой. Это может выглядеть, например, так:

В поисках идеальной модели лицензирования - 3
владелец модуля получает 60% от выручки за минусом скидок и налогов.
разработчик решения получает 10% от продаж специализированных модулей созданных для этого решения другими разработчиками.
Сообщество (некоммерческая организация) получает остальное.

Внедренцы (продажники). Для профессиональных игроков рынка предусмотрены особые условия (скидка), по которым они продают решения конечным потребителям. Таким образом, они получают выгоду уже на стадии продажи, аналогично продажам коммерческих продуктов.

Облачные сервисы. Некоторые (лицензированные) организации будут предоставлять услуги в облаке. Им также потребуются особые условия.

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

Поддержка

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

Дополнительно необходимо ввести новый вид услуги, который позволит продавцам (например, облачникам) давать более-менее приличные SLA. Т.е. разработчик не просто делает модуль и пытается заработать на нем денег по старинке, а обещает второй вариант поддержки, который сложнее, но позволяет зарабатывать больше.

Мысли по организации

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

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

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

Кто готов сделать что-нибудь в этом направлении? А что именно?

Автор: IvanKlut

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js