Как и на чем зарабатывают в Open Source

Эта статья о том, что Вы тоже можете получать прибыль, создавая прекрасные open-source программы. Но если Вы не являетесь разработчиком ПО, возможно вам следует посвятить свободную минутку другой Web-странице, а не этой.

Когда я говорю о заработке на открытых проектах, я вовсе не призываю Вас приложиться к щедрой кормушке Mozilla Foundation. Это ведь будет как обычная работа, разве что пинков от руководства поменьше. И я не имею ввиду участие в частично (но вечно недостаточно) спонсируемых проектах под крылом гигантов вроде Sun или Apple.

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

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

Для начала стоит понять кое-что из экономики

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

Если Вы разрабатываете закрытые программы, Вы можете продавать тысячи копий.

В случае открытых программ, Вы можете продать первую копию, но остальные придется раздать бесплатно. Поэтому если Вы контрактник в open-source, вашим клиентом будет не средняя домохозяйка — нет, никаких плагинов к Pidgin или синхронизаторов для iPod. Ваш клиент — это шеф крупной компании, желающий сэкономить серьезные деньги с Вашей помощью.

Далеко не каждая компания готова платить вам за open-source разработку для неё. Прежде всего, такая компания должна иметь необходимость и стремление исправлять проблемы самостоятельно. Обычно это значит, что возникающие проблемы должны решаться быстро, независимо от времени суток.

Если исправление ошибки в программе «может подождать до понедельника», то компания скорее купит готовое решение, чем будет связываться с собственной разработкой. Все-таки на разработку готового (закрытого) ПО обычно тратятся большие деньги, чем непрофильная компания может себе позволить.

Читайте также:  Сравнение Unity и KDE особенности производительности интерфейсов и их отличия

Я полагаю что именно возможность быстрого исправления ошибок помогла open-source достичь такой популярности в мире web-серверов. Многие интернет компании зарабатывают тысячи долларов в час, и каждая минута простоя грозит потерей прибыли. В такой ситуации глупо ждать пока кто-другой придет и поймет что случилось и как это исправить.

Компания, использующая open-source в своей работе, должна быть достаточно велика, чтобы иметь несколько разработчиков в штате (как минимум для быстрого исправления ошибок), но не слишком много — иначе им будет проще все сделать своими силами. Так что у тех, кто может нанять Вас для контракта, уже есть от одного до пары десятков собственных инженеров.

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

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

Ключ к этому — стать экспертом в чем-либо. Желательно экспертом с мировым именем. Для этого не надо знать эту область лучше всех; достаточно чтобы Вы могли показать — ваш уровень не хуже других в этой области. Не надо доказывать что Вы лучший — надо чтобы никто не мог доказать что он лучше Вас.

Лично я стал таким экспертом случайно

Садитесь поближе, молодежь, я расскажу вам историю. Однажды, давным-давно (2006), я работал в Большом Интернет Магазине. Мои коллеги часто обсуждали вещи, которые я не понимал — звучали термины «неблокирующие сокеты», «дублирование хендла», и другие, бывшие для меня китайской грамотой. Пытаясь понять этот язык, я стал читать, искать в интернете, и обнаружилось что они обсуждают не письмена с Розеттского камня, и не тайные масонские заклинания — а всего лишь тонкости сетевого программирования под UNIX.

Я стал изучать глубже, просто чтобы стать «своим». Прочитал книжку по UNIX, еще одну по сетям, поигрался с кодом дома. И обнаружил что написать даже простейшую серверную программу — занятие не из легких. То есть в целом она работала, но при общении с отдельными браузерами появлялись ошибки. И я решил что пусть со всем этим разбирается кто-нибудь другой.

Читайте также:  Как удалить LibreOffice Astra Linux

В то время я наткнулся на Nginx — веб сервер с забавным именем. И решил попробовать писать свои программки как расширения Nginx, а не возиться с самостоятельными приложениями. К сожалению, в интернете не нашлось никакой документации о написании таких расширений, так что я углубился в исходники, а все найденное записывал себе в блокнот.

После пары вечеров и выходных за этими занятиями, я получил вполне ясное представление о том что мне было нужно. Правда, выяснить все подробности оказалось сложнее чем я ожидал — у Nginx были русские корни, а потому английских комментариев почти не было, а многие переменные имели имена из одной или двух букв. Или больше, но это ничуть не помогало — например «nldcf».

Результатом нескольких недель усилий стало моё первое расширение, включающее около 100 строк кода. Больше всего сил было потрачено на записи, которых набралось несколько страниц. И однажды днем, когда мне нечего было делать, я их набрал, и чего терять, выложил в интернет. В то время у меня даже не было своей странички, так что я просто послал в список рассылки, посвященный Nginx, статью «Emiller’s Balls Out Guide to Nginx Module Development (DRAFT)» (Безбашенное руководство по написанию модулей Nginx).

Мое руководство быстро стало популярным в России — я с удовольствием видел название «Emiller’s Balls Out Guide» на нескольких русских сайтах для разработчиков. А из англоязычного мира ко мне тонкой струйкой потекли вопросы о внутренностях Nginx. Оказалось что никто по эту сторону границы с Россией не писал таких расширений до сих пор, и я вдруг стал экспертом в такой узкой области.

И оказалось, что людям такой эксперт был нужен

Через пару дней после выхода моей статьи, я получил письмо с предложением написать расширение для одного стартапа. У них было много разработчиков; но вместо того чтобы усадить их на пару недель за изучение внутренностей Nginx, руководству было выгодней нанять меня (эксперта, ага) чтобы сделать работу. И еще они хотели чтобы результат был open-source. В то время я очень хотел купить MacBook Pro, так что я назвал цену ноутбука плюс налоги, и они согласились.

Если Вы разработчик, который до сих пор не работал по контракту, и никогда не получал денег по ставке «эксперта», Вы меня поймете. Над своим первым оплаченным модулем я работал усерднее, наверное, чем когда либо в жизни. Это очень вдохновляет — знать что чем быстрее я закончу, тем быстрее получу деньги, хотя это чувство и с примесью жадности.

Читайте также:  Полное руководство по автоматическому запуску виртуальной машины VirtualBox в Linux

Вдохновляет — не совсем правильное слово: ты чувствуешь себя целеустремленным, полным энергии, окрыленным; это бьет как двойная порция любви и колы. Кажется, что в голове открылся новый Центр Вознаграждения — вдвое больше чем старый и с дополнительной парковой. И это было хорошо. Хорошо как золото. Хорошо как жадность. Хорошо как Бог. Я был Александром Невским, а Си был моим мечом.

Я отправил законченный продукт через 4 дня, хотя план был на 4 недели, а несколько следующих дней, отдыхая от «отравления кодом», провел глядя «Доктор Хаус». Когда я получал свой чек, шеф компании сказал что им очень понравилась моя работа, и они добвили к сумме еще 500$ — просто в знак благоданости.

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

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

Хороший учитель лучше чем лучший студент. Чтобы прослыть экспертом, пишите о том, что вы узнали. Объясняйте все в руководствах. Участвуйте в списках рассылки. Приезжайте на конференции.

Большие замки хранят маленькие секреты

Не раскрывайте всего что знаете. Не доставайте из рукава последний туз. Наоборот, полезно упомянуть что «мелкие детали опущены».

Люди ходят к шарлатану в офис, а не к доктору домой. Не прячьтесь и не скромничайте. Сделайте сайт, рассказывающий о том кто Вы и чем занимаетесь. Люди не будут нанимать телепатов чтобы Вас искать.

Сегодня шов, завтра костюм. Компании, нанимающее Вас, могут иметь несколько проектов. И для начала они всегда предложат Вам тот, что поменьше. Если это небольшая работа, возьмите за нее соответствующие деньги. Если сможете произвести впечатление, следующий раз можете получить более перспективный контракт.

И напоследок, небольшой совет своими словами

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

В мире есть место для нeзависимых open-source котрактников. Я не знаю как много места. И я не знаю насколько долго это продлится. Но теперь Вы знаете как я стал тем кто я есть.