Зачем нужен свободный код и как на нем зарабатывать
Мы наблюдаем бум свободных проектов. В основном, благодаря Гитхабу. 23 декабря 2013 года на сервисе был создан 10-миллионный проект. К 23 декабря 2015 года количество проектов более чем утроится: прямо сейчас на Гитхабе 28 миллионов проектов.
Многих привлекает идея свободности, потому что она перекликается с идеей «улучшения мира», как основной мотивации продуктивной деятельности человека.
Но так как обычная работа программистов в конторах очень далека от open source, возникает вопрос, как кормиться (а желательно, и разбогатеть!), большую часть времени занимаясь свободными проектами.
Судя по последним вопросам на Тостере, у людей много ожиданий, но мало понимания в этой области. Поэтому я решил написать это эссе.
Само по себе выкладывание проекта не является улучшением мира
Польза миру это либо польза людям, либо природе, либо культуре/гуманизму, либо экономике, либо науке. Первые три категории не имеют ничего общего со свободным кодом, потому что людям, природе и культуре прекрасно помогает несвободный код. Пользу науке часто рассматривают как ту же помощь экономике, только в очень далекой перспективе, хотя большинство ученых с этим не согласно, считая познание мира самостоятельной ценностью. Но еще учитывая и то, что свободный программный проект с научной новизной — экзотика, сконцентрируемся на том, как свободный код помогает экономике.
Вы выложили код. Чем вы помогли экономике в этот момент? Ничем, поэтому и миру вы пока ничем не помогли.
Ваш проект может спасать людей от рака, быть бесплатным, экономить миллионы долларов, и при этом быть закрытым.
Сконцентрируйтесь не на том, чем вообще полезен ваш проект, а чем полезна его свободность.
Синергетический эффект свободного кода
Если ваш проект несет пользу, то его улучшение означает еще больше пользы. Пользователи свободного проекта исправляют баги, впиливают новые функции, улучшая жизнь не только себе, но и всем другим пользователям проекта. Это синергетический эффект.
Внимание. Это работает только при соблюдении следующих условий:
1. Пользователи вашего проекта (те, кому проект несет пользу) — программисты. Или, по крайней мере, существенная часть пользователей. Если вы написали замечательное приложение для домохозяек с рецептами пирогов, вы молодец, но домохозяйки не придут к вам на Гитхаб и не исправят баги в приложении.
Вывод: в свободности таких проектов, как мобильные приложения, сайты, игры, полезные программки на десктоп, софт для професионналов в областях, далеких от программирования, практически нет смысла.
2. Ваша система должна быть расширяемой, максимально дружелюбной к изменениям. На эту тему есть выдающееся выступление Гая Стила «Growing a Language» (смотреть можно с 6 минуты):
Одна из самых важных мыслей выступления: постарайтесь спроектировать систему так, чтобы функции, построенные [пользователями] поверх базовой функциональности системы, «выглядели» так же, как эта «родная» функциональность.
Вывод: уделите максимум внимания расширяемости и hackability проекта. Если это DSL, сделайте операторы перегружаемыми. Если это фреймворк, сфокусируйтесь на системе плагинов. И т. д.
С точки зрения синергетического эффекта, нет большого смысла в свободности проектов, которые не предполагают подобной расширяемости.
3. Не обязательно, но желательно, чтобы у проекта был как можно более низкий порог входа. Если проект слишком сложен, пользователи (даже программисты) не смогут самостоятельно добавить функцию или исправить баг.
Сложный код — не обязательно плохой, возможно, это прямое следствие сложности решаемой проблемы. Например, Hotspot JVM почти не извлекает выгоды из своей открытости, потому что это столь сложный проект, что единицы из миллионов его пользователей способны вникнуть и внести разумное улучшение.
Мысли вслух — а может, все потому, что Hotspot JVM написан на C++, а его пользователи — программисты на Java? Вот вам еще один вывод: если пишете компилятор, обязательно делайте раскрутку.
Впрочем, свободная среда разработки на Java IntelliJ IDEA Community Edition хоть и написана на той же самой Java, бесполезно почти. Проект слишком сложный, чтобы туда сунуться.
Проекты с очень хорошо работающим синергетическим эффектом:
Ядро Linux. Компании, системные администраторы и программисты улучшают ядро для себя, делая его лучше и для всех остальных.
Многие проекты фонда Apache.
Веб-фреймворк Flask. Пример того, как продуманная плагинная система и высококачественный, модульный код ядра сделали фреймворк почти таким же мощным, как Django, при в разы меньших усилиях основного автора.
Какие еще? Кидайте примеры в комментарии.
Открытый проект с требованиями по безопасности привлекает больше пользователей
Это польза экономике (если проект приносит пользу и у него больше пользователей, он приносит больше пользы), а так же вам, если вы хотите заработать на проекте (об этом ниже). Открытый код вызывает больше доверия: можно проверить проект на отсутствие закладок.
Шифрование, хранилка паролей, антивирус, программа, которой нужны админские привилегии и т. д.
Открытые проекты работают на имя
Не особо интересный момент. Может пригодится для устройства на обычную работу, но ведь от этого мы и хотели уйти, верно?) Для того, чтобы создать новый или развивать существующий открытый проект, никакого послужного списка не требуется.
Единственное, если вы суперзвезда Гитхаба, все ваши новые проекты автоматически привлекают много внимания. Но суперзвездам Гитхаба не нужны советы из этой статьи.
Способы прогореть на свободном проекте
Пожертвования НЕ работают.
— Да, но мой замечательный проект…
— НЕТ.
Продажа поддержки свободного проекта не работает, или работает очень плохо. Объективно, поддержка мало кому нужна: работники компаний просто спрашивают на форуме/в рассылке/баг-трекере, как сделать то-то и то-то, или описывают проблему, и авторы проекта обычно так или иначе исправляют это в бесплатном режиме — не игнорировать же «сообщество» внаглую. С консалтингом то же самое: если документация — говно, проектом вряд ли даже начнут пользоваться, а если хорошая, то и консалтинг не нужен.
Most open source companies can't thrive by selling maintenance and support subscriptions. But the cloud may be the key to revenue generation.
Единственный способ заработать на свободном проекте — сделать на его основе обычный, «скучный» бизнес
Схема такая:
- Технология поддерживает ваш обычный бизнес.
- Технология выигрывает за счет своей свободности («синергетический эффект» и/или доверие к открытости).
- Бизнес выигрывает, потому что выигрывает технология.
А что если конкуренты тоже построят на моей технологии свой бизнес?
- Во-первых, если ваш проект достиг такой популярности, что пришли люди делать на его основе бизнес, вам а) уже не нужны советы из этой статьи б) денег хватит.
- Во-вторых, клиенты доверятся все равно вам, потому что знают, что вы — автор проекта, разбираетесь во всех тонкостях, а также выбираете направление развития проекта.
Что за бизнес?
- Платные решения. Пример: компания Red Hat развивает свободный проект: операционную систему GNU/Linux. На основе свободного проекта GNU/Linux Red Hat делает платный продукт: Red Hat Enterprise Linux. GNU/Linux выигрывает за счет синергетического эффекта, опосредованно улучшая и RHEL.
Открытое ПО ≠ свободное ПО. Если грубо, то свобода — это открытость плюс бесплатность. Поэтому изначально коммерческий, но открытый проект может выигрывать за счет «доверия к открытости», описанного выше.
- Saas, дистрибуция. Пример: компания Docker развивает свободный проект Docker, в экосистеме которого живет коммерческое Saas-решение Docker Hub.
Я не специалист по Докеру, поэтому буду благодарен, если кто-то поможет разложить по полочкам этот случай. Понятно, для чего нужна бесплатность базового Докера: пользователи подсаживаются на него, а потом начинают платить за Docker Hub. Но я не очень вижу, чем помогает открытость (+ бесплатность = свобода) Докера. С моей точки зрения, он не похож на этакую hackable платформу. Хотя, судя по тому, что в проекте больше 1000 контрибьюторов (очень много), таки ей является. Что туда контрибьютят? Вот эта тысяча человек пришла, и каждый исправил по одному багу? Или добавил какой-то плагин? Я не знаю. (Ну это же не про докерфайлы, да?)
- Разработка на заказ. Тот самый банальнейший аутсорсинг, да-да. Пример: компания Chronicle Software развивает семейство свободных проектов Chronicle и выполняет на заказ разработку систем с использованием этих проектов.
- Что еще? Давайте типы скучных бизнесов в комментарии.
