LiveStreet

Я получаю письма от незнакомых людей, спрашивающих, могут ли они мне заплатить за доработку моего любимого открытого программного обеспечения. Да, правильно. Я получаю деньги. Я получаю работу, доставляющую мне удовольствие. Я получаю хорошее программное обеспечение. И я могу делиться им с кем угодно по моему желанию. Это — одна из величайших экономических схем в мире, на одном уровне с поместным дворянством, коррумпированным чиновником, или Дэйвом Бэрри.

Эта статья — о том, как и вы можете зарабатывать, создавая хорошие открытые программы. Если вы — не разработчик, наверное, вам стоит следующие несколько минут своего свободного времени провести, открыв другую страничку. Я рекомендую По-настоящему Большую Клавишу, Которая Не Делает Ничего.
Говоря об оплате за забавы с открытыми проектами, я не имею в виду присасывание к большой обвисшей груди Mozilla Foundation. Ведь тогда это была бы обычная работа, за исключением того, что здесь никакой Акционер не держит зад Менеджмента над раскаленной плитой. И я также не подразумеваю, что вы должны укрыться в крыле «сообщество» Департамента Хронически Недофинансируемых Проектов, например, Sun Microsystems или Apple Computer. Что я имею в виду — это проснуться с утра, подойти к компьютеру, и наваять немного кода перед завтраком. Я имею в виду — отказываться от проектов, которые не выглядят интересными. Я имею в виду — получать оплату пропорционально сделанной работе. Иными словами — подрядную работу.

Я не ставил перед собой цели стать Open source-подрядчиком. Просто так вышло, как, например, секс со значительно старшей соседкой. Если бы я хотел стать хорошим подрядчиком, подрядчиком на полный день, наверное, я мог бы делать намного больше. Я дойду и до этого. Ниже — смесь проверенных и непроверенных советов. Я думаю, все они достаточно хороши. Дорога нелегка, и она — не для каждого.

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

Если вы пишете проприетарное ПО, вы можете продавать тысячи копий. Если вы пишете открытое ПО, вы можете продать первую копию, но вам придется раздать все последующие. Так что, как Open source-подрядчик, вы не будете писать программы для Избалованного Потребителя. Никаких плагинов к Pidgin, никаких виджетов для Gnome, никаких синхронизаторов для iPod или еще чего-то в том же роде. Вы будете писать ПО для технического директора единственной компании, могущей сберечь серьезные деньги благодаря вашим усилиям.

Чтобы писать открытое ПО для компании, нужна особая комбинация обстоятельств. Компания должна иметь культуру самостоятельного решения проблем. Это, как правило, подразумевает решение проблемы немедленно, в любую минуту, днем или ночью. Если ошибки в программе могут «недельку подождать», тогда, пожалуй, компании лучше покупать ПО у дистрибьютора, а не разрабатывать его самостоятельно или использовать открытое решение. В целом, проприетарное ПО можно создавать, имея больше ресурсов.

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

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

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

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

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

Я стал экспертом случайно. Ну давайте, молодежь, собирайтесь, я расскажу вам легенду. Однажды, очень давно (2006), я работал на Большого Интернет-Продавца. Мои коллеги часто говорили о предметах, которые мне были непонятны — “неблокирующих сокетах”, “дублирующихся дескрипторах файла” и о других вещах, звучащих так же призрачно, как и движения каратиста. В попытке раскодировать этот странный язык, я покопался немного в гугле и нашел, что мои коллеги обсуждали не правила маркиза Квинсбери, и не масонские тайны, а такой близкий к ним предмет, как сетевое программирование UNIX. Я продолжил копать глубже, в первую очередь для того, чтобы быть в курсе дел. Я прочел книгу по UNIX и по компьютерным сетям, и немного побаловался практикой на домашней машине. Но мне трудно было писать даже элементарные серверные программы. Они, в основном, работали, но давали сбои при работе с определенными веб-браузерами. Поэтому я решил, что лучше бы с клиентскими ошибками имела дело программа кого-то другого.

В то же время, я как-то игрался с Nginx, веб-сервером с забавным именем. Я решил, что вычислю, как писать мои игрушечные программы так, чтобы они были приложениями к Nginx, а не отдельными программами. К сожалению, в Интернете я не смог найти никаких документов про написание приложений к Nginx, поэтому я писал код наощупь и набрасывал краткие заметки в записной книжке. После того, как я провел за этим занятием несколько вечеров и парочку суббот, у меня сформировалась достаточно четкая идея относительно того, как написать приложение. Постичь детали было намного труднее, чем я ожидал вначале; исходный код Nginx, российского происхождения, имел очень мало комментариев на английском, и очень много переменных, имеющих одно- или двузначные названия. Или чуть более длинные, но такие же туманные, как, например “nldcf”.

Мое первое приложение для Nginx, плод нескольких недель стараний, представлял собой около 100 строк кода. Большинство усилий выразилось в записях, которых набралось на несколько страниц. И как-то вечером, не имея, чем заняться, я эти записи напечатал и подумал — елки-палки, да размещу я их on-line. Кстати, на то время у меня не было домашней странички, так что я просто разослал по списку рассылки Nginx ссылку на “Супер-руководство Эвана Миллера по разработке модулей Nginx (ЧЕРНОВИК).”

Мое руководство немедленно стало хитом в России — фраза “Супер-руководство Эвана Миллера” в окружении текста на кириллице на нескольких российских технических сайтах приятно щекотала самолюбие — и в англоговорящем мире я столкнулся со струйкой вопросов про «начинку» Nginx. Вероятно, еще никто по эту сторону Петербурга до меня модулей к Nginx не писал, и вот так внезапно я стал экспертом в данной узкой области.

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

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

Я сделал работу за четыре дня вместо четырех недель, и пришлось провести парочку дней для излечения от интоксикации кодом (т.е., посмотрев много серий House). Когда я пришел за чеком, технический директор мне сказал, что компании настолько понравилась моя работа, что они дают мне еще 500 баксов сверху просто в благодарность.

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

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

* На кухне шеф-повара нож, который может резать все, не режет ничего.
* Хороший учитель — лучше, чем великий ученик.
* За большими замками прячутся маленькие секреты.
* Большинство идут к шарлатану в офис, а не к доктору на дом.
* Сегодня — стежок, завтра — костюм.

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

Хороший учитель — лучше, чем великий ученик. Чтобы стать известным, как «эксперт», пишите о том, о чем вы знаете. Давайте пояснения в руководствах. Участвуйте в списках рассылки. Приходите на конференции. Но помните…

За большими замками прячутся маленькие секреты. Не делитесь всеми своими знаниями. Неплохо бы припрятать немного колдовства в рукаве. Еще лучше вскользь упомянуть, что вы опускаете какие-то “детали”.

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

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

И, наконец, один совет не в форме афоризма:

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

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

Ну, конечно, за исключением одной-двух деталей…

источник