Разработчики flask-base рассказывают, как они продвигали свой проект.

Самой важной частью продвижения было создание хорошего README.

README — это первое, что видят посетители репозитория. Он должен отвечать на все их вопросы. У популярных проектов README обычно строится по такой структуре:

1. Название. Можно нарисовать логотип, тогда проект будет казаться более серьезным.
2. Короткое описание. Оно должно помещаться в твит. Ради этого можно пожертвовать деталями.
3. Бейджи, которые показывают качество кода. Когда значки говорят, что билд зеленый, тестовое покрытие высокое, а статический анализ не находит проблем, это сразу вызывает доверие. Пользователю не приходится заглядывать в исходники, чтобы убедиться, что код написан хорошо.
4. Ссылка на документацию, которая рассказывает, как пользоваться проектом. Написать хорошую документацию тяжело, но критически важно для успеха проекта.
5. Список фич. Не обязательно полный, оптимальный размер — до десяти.
6. Пример работы. В идеале это должна быть гифка, которая показывает, как работает проект. Ничего страшного, если даже на гифке будет просто показана консоль. Картинка произведет большее впечатление, чем если написать то же самое текстом.
7. Инструкции по установке с командами, которые пользователь должен ввести, чтобы на его компьютере всё заработало.

Робби Рассел, создатель Oh My Zsh, рассказывает историю проекта.

Изначально Oh My Zsh был репозиторием на гитхабе, куда Рассел скинул свои настройки zsh для коллег.

In my scenario, I wanted 1–2 people on my team to use my scripts. The project was a success in under 24 hours. Everything since has been extra-credit.

Со временем проект превратился во фреймворк для управления настройками, оброс сотнями плагинов и тем. Он стал очень популярным: 35000 звезд и 10000 форков на данный момент и стабильное первое место в разделе Shell.

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

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

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

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

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

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

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

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

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