Ссылка первая. Презентация Michael Widenius (отца MySQL и MariaDB) "How to create a successful open source project" с конференции OSCON 2013.
Ссылка вторая. Запись в блоге все того же Michael Widenius кастельно новой бизнес-модели: Business Source (A software license with some Open Source aspects).
Ссылка третья. Статья Michael Widenius и Linus Nyman, более подробно рассказывающая о понятии Business Source: "Introducing “Business Source”: The Future of Corporate Open Source Licensing?"
Коротко о том, что за идея лежит в основе Business Source.
Есть три устоявшиеся модели заработка на основе Open Source разработок:
1. Получение денег не за сам продукт (который полностью открыт), а за сопутствующие "услуги": обучение/консультирование, техподдержка, разработка кастомных версий или внедрение на площадке заказчика. Характеризуется невысокой долей прибыльности и высокими затратами -- необходимо вести и разработку продукта, и те самые дополнительные услуги. Зато при этом пользователи продукта имеют в своем распоряжении весь продукт, что стимулирует их участвовать в разработке (тем самым беря на себя часть издержек разработчика продукта). Так же клиенты защищены от т.н. vendor lock (опять же потому, что код всего продукта полностью свободен).
2. Разделение продукта на открытую составляющую и закрытую (т.н. модель Open Core). Клиенты бесплатно пользуются полностью открытой частью продукта, но вынуждены платить за использование закрытой части. При этом необязательно клиенты получают доступ к исходникам этой закрытой части. Примером продукта на модели Open Core является EnterpriseDB, где бизнес строится вокруг платных дополнений к открытой PostgeSQL. Достоинством этой модели для производителя продукта является более высокая (по сравнению с первой моделью) прибыльность. Но, с другой стороны, клиенты находятся в зависимости от поставщика закрытой части (т.е. такой же vendor lock, как и в случае с полностью проприетарными продуктами). Плюс, если у клиентов нет доступа к исходникам закрытой части, то они не могут принимать участие в их разработке/развитии, тем самым производитель продукта сам несет все издержки по его разработке.
3. Двойное лицензирование. Для некоммерческого использования продукт распространяется, как правило, под GPL лицензией. Для коммерческого использования продукт поставляется под отдельной лицензией, за которую нужно платить. Яркий пример: библиотека Qt, которая очень долгое время была под GPL и отдельной коммерческой лицензией. Эта модель так же более прибыльная, чем первая. Но при этом у клиентов нет vendor lock-а, клиенту доступен весь исходный код, что может сподвигнуть клиента на помощь в разработке/сопровождении продукта. Однако, тут могут возникнуть проблемы с тем, на каких условиях перелицензируется код, получаемый в виде патчей от клиентов: если все права передаются производителю продукта, то у клиента снижается стимул заниматься этими патчами.
К этим моделям предлагается еще одна: весь код продукта распространяется под специальной двойной лицензией. Эта лицензия для бОльшей части пользователей продукта оставляет возможность бесплатного использования продукта. Но малой части (рекомендуется ориентироваться на диапазон в рамках 1/1000..1/100 от общего количества) пользователей нужно платить за продукт. В простейшем случае обычное двойное лицензирование: некоммерческое использование бесплатно, коммерческое платно.
Но весь фокус в том, что в лицензии сразу указывается срок, по истечении которого код автоматически перелецензируется под послностью открытой лицензией. Например, выпускается код в 2013, в тексте лицензии указано, что код становится полностью свободным в 2017.
Такая модель должна позволить получить такую же прибыльность, как и в случае с простой моделью двойного лицензирования. Но при этом клиенты продукта стимулируются на внесение в него правок, т.к. они знают, что со временем весь код перейдет в их полное распоряжение, даже если сейчас они полностью передают права на патч производителю продукта.
Комментариев нет:
Отправить комментарий