Хонли Лай, один из двух основателей Phusion, рассказывает, как они строили компанию вокруг опенсорсного проекта.

Phusion разработали веб-сервер Passenger и стали пробовать различные способы заработать на нем.

Ранние бизнес-модели:

1. Консалтинг и аутсорсинговая разработка. Passenger выполнял только маркетинговую функцию: привлекал заказчиков и показывал компетентность разработчиков. Эта модель давала доход, но имела много недостатков. Нестабильный и непредсказуемый поток заказов. Сложности работы с клиентами (дедлайны, меняющиеся требования). Неприятнее всего было то, что консалтинг не оставлял времени на дальнейшую разработку Passenger.
2. Контракты на поддержку. Passenger оказался «слишком хорош»: у пользователей не возникало проблем, которые заставили бы обращаться за поддержкой. Да и пользователи в основном были достаточно технически продвинуты, и им не требовалась регулярная поддержка. Максимум — одноразовая консультация по решению какого-то вопроса. Со временем во Phusion поняли, что контракты на поддержку работают скорее как страховка. Их покупают те, кому нужна безопасность и гарантии. Поэтому пользуются этой услугой не-айти-компании: банки, госорганы. И, как и со страховкой, для продажи поддержки нужны менеджеры по продажам.
3. Пожертвования. Донат просто не работает.

Поздние бизнес-модели:

1. Премиум-версия с дополнительными возможностями. Это распространенный в опенсорсе подход. Phusion боялись, что сообщество плохо отнесется к появлению премиум-версии, но оно, наоборот, поддержало разработчиков. Благодаря прямой оплате, появилась возможность добавить в Passenger возможности, которые до этого приходилось откладывать на будущее.
2. Платные сервисы. Идея в том, что если у продукта достаточно много пользователей, то появится достаточный спрос на связанные сервисы (хостинг, мониторинг, аналитика). Так был разработан Union Station — программа для анализа производительности, интегрируемая с Passenger.

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

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