Почему участие в Open Source проектах это интересно и полезно. Знакомство с новыми людьми. Коммиты и пуш

Разработчика из США, который описал личный опыт участия в open source проекте. Из этого материала вы узнаете:

• что такое open source проекты;
• как вы можете внести свой вклад;
• где искать проекты и задачи.

Почему стоит браться за open source проекты?

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

Open source проект на пальцах

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

А теперь представьте более радостную картину: группа добровольцев взяла под свою ответственность содержание своего любимого парка. Она регулярно выделяет средства, чтобы превратить нечто неухоженное и заброшенное во что-то очень красивое и полезное другим людям. И делает это не только ради личного удовольствия, но и к радости общественности. Скорее всего, ваш любимый парк содержат на наши с вами налоги, но в целом приведенная выше ситуация описывает то, как работают open source проекты. Хотя любое программное обеспечение, по сути, рассчитано на конечного пользователя, как разработчик вы можете внести свой вклад в open source проект, тем самым сделать мир лучше с помощью нового доступного ПО. Если вы хотите принять участие в open source проекте, нужно понять, кто его курирует и постараться наладить взаимодействие с этими людьми. Я вовсе не имею в виду, замучить их до полусмерти вопросами и ожидать всеобъемлющей опеки во время работы. Вы - взрослый самостоятельный человек (даже если вдруг ещё не взрослый, то быть самостоятельным - отличная идея!). Надеюсь, вам уже не нужно вести за руку и расписывать каждый шаг. В этом я вам не помощник. Зато я могу дать вам несколько дельных советов, которые помогут вам при попытке внести свой первый вклад и потенциально включить ваш кусок кода в проект с открытым исходным кодом.

Поиск проекта

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

Где искать проекты Open Source

Их можно найти в открытых репозиториях GitHub. Собственно, там все их и ищут. Там очень много .

Поиск хорошей первой задачи

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

Когда вы найдете подходящую задачу, напишите комментарий кураторам проекта о том, что вы хотели бы над ней поработать. Чаще всего вам дадут добро, но возможно по какой-то причине попросят выбрать другой вариант. Не думайте, что вы не можете начать пока не пришел ответ, но будьте гибкими, если вас попросят остановиться и заняться чем-то другим. Для моего первого задания я выбрал то, где было необходимо немножко подправить css. Мне казалось, что я могу это реализовать и это не угнетало меня.

Начало и ознакомление

Начало работы в проекте может казаться обманчиво легким, но при этом иметь много подводных камней. Когда вы выбрали задачу для решения, вам нужно развернуть проект на своей машине. Скорее всего, исходники проекта будут «тяжелыми» (хотя это зависит от проекта). Возможно, вам придется установить большое количество зависимостей просто для того что бы запустить проект.

В проекте, на который я попал, таких моментов было немного, но это не значит что это было просто. Например, нам пришлось установить специфические версии Ruby и специфические версии Rails, PostgreSQL, Phantom JS и Gemfile с перечнем Gems для инсталляции. Казалось, что это не так уж и много требований, но я столкнулся с большой проблемой с поиском специфической версии Ruby, необходимой для разработки проекта и работающей на моем компьютере. Наконец, я использовал RVM для переключения версий: это еще одна вещь которой я научился, только для того чтобы просто установить проект и заставить его работать на компьютере. Когда же я запустил проект, то увидел, что тот написан на Angular и Coffee Script, с применением Active Record для взаимодействия с данными поступающими из бек-энда. Это были новые для нас вещи, и с ними нужно было разобраться самостоятельно до начала работы над проектом.

Поиск других задач

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

Когда вы оформляете и записываете новую задачу, убедитесь, что вы как можно более подробно описали её. Используйте скриншоты, чтобы наглядно показать, что вы пытаетесь сказать и максимально упростить понимание вопроса постороннему, который заглянет на сайт и увидит описываемую проблему. В моем случае я закончил, добавив две дополнительных задачи, кроме той, что была закреплена за мной. Я даже не смог сделать пул реквест (это было связано с ограничениями безопасности). Мне казалось, что я сделал два шага назад для проекта, но на самом деле описание и оформление задач все равно двигает проект вперед. Создание pull request (PR) Вы решили поставленную перед вами задачу. Прежде, чем писать отчёт о проделанной работе, покажите решение тому, кто сможет его оценить. Предварительный просмотр - отличная идея всегда, но для вашего первого вклада в открытый проект он просто необходим . Вы же не хотите краснеть из-за недоработанного или неправильно работающего куска кода? По этой же причине кураторы проекта предложат вам пройти все необходимые тесты перед пул реквестом. Поэтому проверьте себя загодя, чтобы быть уверенным в своей работе и поправить её в случае необходимости до получения подтверждения от кураторов. Убедитесь, что вы придерживаетесь названий или стилистики, которая принята кураторами проекта. Вы можете найти информацию в файле CONTRIBUTING.md , он есть в большинстве проектов. Также там вы сможете уточнить, в каком виде вы должны создавать commit message, как должно выглядеть описание вашего pull request и как оформить новую задачу.

Покинуть задачу

Иногда понимаете, что не справляетесь со взятой задачей. Или вам казалось, что у вас есть время на проект, но на деле его не оказалось, вам на голову свалилась срочная работа и вам нужно заняться ею. Это в норме вещей. Главное, отпишитесь от задачи и оставьте сообщение кураторам, чтобы они знали, что вы не сможете продолжать заниматься проектом. Но ни в коем случае не бросайте задачу, не сообщив кураторам и не отписавшись от неё.

Заключение

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

Что ещё почитать:

Один из докладов на прошедшей в Остине конференции OSCON (Open Source Convention) был посвящён весьма важному вопросу - началу работы в открытом проекте. Свои рекомендации новичкам дала программист Puppet Labs Люси Вайман.

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

Прежде всего, Open Source позволяет избежать изобретения колеса. Например, совершенно незачем создавать собственную ОС с нуля, если можно использовать ядро Linux в качестве основы.

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

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

Часто забывается, что свобода и ответственность - две стороны одной медали. Продукт не может быть бесплатным, но специфика Open Source заключается в том, что пользователю предлагается оплатить его добровольно и любым удобным для себя способом.

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

Наконец, Open Source - прекрасный способ узнать что-то новое. Это особенно актуально для начинающих программистов, одна из главных задач которых - получать необходимые для успешной работы знания.

Но что делать человеку, который боится показаться некомпетентным или не чувствует в себе достаточно сил, чтобы вносить какой-либо заметный вклад в открытый проект? Вайман предлагает несколько способов, которые позволят поддержать Open Source даже человеку, не обладающими навыками программирования.

Во-первых, тестирование. Причём понимать это следует в расширенном смысле - тестеры не только помогают обнаружить ошибки в коде, но и выносят на обсуждения предложения по улучшению функциональности.

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

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

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

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

Поддержка сообщества традиционно является сильной стороной Open Source. Подобная работа очень нужна и всегда воспринимается с благодарностью всеми участниками проекта.

В-четвёртых, обучение. Проведение семинаров и конференций очень способствует продвижению как конкретного решения, так и всего Open Source.

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

В-пятых, дизайн. В этом нуждается практически любой открытый проект.

Логотип, значки, другие элементы визуального оформления приложения - всё это делает проект действительно профессиональным.

Таким образом, Вайман уверена, что в мире Open Source найдётся место всем. Было бы желание, а возможность есть.

Свободное программное обеспечение - неотъемлемая часть бизнеса Google. В этой компании проекты буквально рождаются и умирают с open source. Без Linux и открытого ПО не существовало бы компании Google в том виде, в каком мы её знаем. Google не только использует СПО в повседневной деятельности, но и постоянно выкладывает в открытое достояние собственные наработки. Например, за три месяца текущего года Google открыла Chrome для iOS , Upspin (фреймворк для глобального единого пространства имён), E2EMail (экспериментальный почтовый сервис с оконечным шифрованием), перцептуальный JPEG-энкодер Guetzli . Это только самые крупные проекты, которыми Google поделилась с сообществом в 2017 году.

Всего за время своей работы Google опубликовала код уже более 2000 проектов. Только как их посмотреть? Теперь вдобавок к репозиториям на GitHub все open source проекты Google доступны по единому адресу . Это новый портал свободного программного обеспечения поисковой компании.

В Уилл Норрис (Will Norris), разработчик группы Google Open Source Programs Office, пишет: «Свободное и открытое программное обеспечение лежало в нашем техническом и организационном основании с самого начала существования Google. Начиная с серверов под Linux, и заканчивая внутренней корпоративной культурой Google, когда кто угодно из другой команды разработки может выпустить патч для вашего кода. Open source является частью всего, что мы делаем. В обмен, мы публикуем миллионы строк open source кода, поддерживаем программы вроде Google Summer of Code и Google Code-in , спонсируем проекты open source и сообщества через организации вроде Software Freedom Conservancy , Apache Software Foundation и ».

И вот сейчас, спустя 18 лет после своего основания, компания Google открыла портал , который объединяет все открытые проекты Google, с сопутствующей информацией об использовании, выпуске и поддержке свободного программного обеспечения.

Зачем Google делает это? Если верить сайту, компания уверена, что СПО является всеобщим благом . Когда софт открыт и доступен для всех, это поощряет сотрудничество и продвижение технологий и «решает реальные мировые проблемы».

Наверное, так оно и есть на самом деле.

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

Уилл Норрис пишет, что компания не знает, какие проекты станут популярными и получат всеобщее признание, поэтому они поощряют своих сотрудников публиковать весь код, какой только возможно . Соответственно, здесь можно найти разные проекты по масштабу и уровню поддержки. Есть и крупные известные проекты вроде , и , есть и маленькие «любительские» проекты, которые сотрудники, вероятно, создали в свободное от основных обязанностей время (20% времени рабочего программисты Google могут работать над проектами на своё усмотрение). Например, и . Некоторые из проектов полностью поддерживаются и развиваются сотрудниками Google и сообществом, другие являются экспериментальными, сделанными просто ради удовольствия.

Есть кое-что ещё. Новый портал Google - это не просто собрание открытых проектов, сделанных в компании. Здесь компания ещё и делится своим опытом и корпоративными практиками разработки открытого программного обеспечения. В опубликована копия всей внутренней документации Google по разработке open source (за исключением нескольких документов). Это именно то, что видят и читают сотрудники компании. Здесь несколько разделов. Один из них посвящён - в том числе создание патчей для больших проектов и написание собственных маленьких проектов в 20% свободного времени. Другой раздел объясняет практики OSS внутри компании. Там разъясняется, под какими лицензиями можно брать и использовать код. Например, код под лицензиями AGPL использовать . Здесь размещён тщательно отобранный каталог из тысяч пакетов, рекомендованных для использования. Наконец, третий раздел посвящён инициатив свободного ПО: различным студенческим программам, проводимым мероприятиям, выдаваемым грантам и т. д.

Очевидно, что Google видит свободное ПО как неотъемлемую часть своей деятельности - и стремится максимально поддерживать и использовать его.

Open source становится важной частью бизнеса не только Google, но и многих других компаний. Как и предсказывали отцы-основатели, свободный софт распространяется как вирус, заставляя создателей производных программ тоже выпускать их под свободными лицензиями. Как сказал исполнительный директор Linux Foundation Джим Землин (Jim Zemlin), свободное ПО станет новым . Он имеет в виду, что 80% ценности любых технологий - от смартфонов или других сфер ИТ - будет происходить от свободного софта, и только 20% - от проприетарного. Процесс постепенно идёт. Исследования показывают, что в 2015 году .

• Tutorial

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

Для начала хочу сказать, что по адресу www.chromium.org/Home находятся подробнейшие инструкции на все случаи жизни - начиная от получения исходного кода и заканчивая инструкциями по отправке ваших патчей на коммит. Кроме того, рекомендую прочитать этот документ и пройтись по ссылкам в нем.

Процесс для независимого разработчика состоит из следующих шагов:

1. Собрать Хромиум.
2. Выбрать баг из Issues List.
3. Исправить баг, протестировать.
4. Отправить баг на ревью.
5. Исправить review issues, перейти к шагу 4.
6. Попросить ревьюера закоммитить ваш код.
7. Наслаждаться результатом.

Ниже - подробнее о каждом из шагов.

Шаг 1. Собрать Хромиум

Для сборки требуется достаточно современный компьютер, различные документы на вышеуказанном сайте рекомендуют многоядерный процессор и не менее 8 Гб памяти. Кроме того, потребуется около 60 Гб свободного пространства на жестком диске, в качестве которого рекомендуют использовать отдельный SSD.

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

Мне удалось собрать Хром под Windows и Linux. Под Mac OS не удалось провести линковку, хотя компиляция прошла успешно.

Для сборки под Windows использовался компьютер пятилетней давности с двухядерным процессором и 3 Гб памяти. Полная сборка заняла около 6 часов (не могу сказать точнее, я ставил билд на ночь), плюс линковка - более получаса (на 32 битах оказалось невозможным включить инкрементальную линковку).

Для сборки версии под Линукс был арендован виртуальный сервер в облаке у одного из российских хостеров. Ресурсы там выделяются по запросу и при билде использовалось около 8 Гб памяти и 8 ядер процессора. Оплата там снимается за использованные ресурсы и билд с нуля обошелся, кажется, в 35 рублей. Время полного билда - около часа.

Для сборки под Mac OS использовался хакинтош в виртуальной машине, компиляция заняла больше десяти часов. Я не стал тестировать сборку под этой ОС, лишь убедился, что мои изменения не сломали билд.

Как сказал мне один из работников Google, разработчики, работающие над Хромом, используют два билд бокса с разными операционными системами на их собственный выбор. Он также добавил, что Chrome отличается от Chromium лишь наличием нескольких проприетарных модулей и логотипом. Процесс работы сотрудника Google над Chrome полностью совпадает с процессом работы независимого контрибьютора за исключением того, что сотрудник Google имеет доступ к некоторым закрытым записям в баг-трекере, связанным, например, с безопасностью.

Шаг 2. Выбрать баг из Issues List

Если сборка прошла успешно, вы можете найти открытый баг и попытаться его исправить. Все дефекты, относящиеся к браузеру, находятся в баг-трекере по адресу code.google.com/p/chromium/issues/list .

Начинающим разработчикам рекомендуется выбирать баги с меткой GoodFirstBug . Предполагается, что задачи с этой меткой проще и человек, имеющий слабое представление о коде, сможет достаточно быстро с ними разобраться.

Шаг 3. Исправить баг, протестировать

На этом шаге у вас уже есть работающая сборка и выбранный баг. Все, что вам остается, это попытаться воспроизвести баг и выяснить его причину, пользуясь отладчиком и здавым смыслом. Я пользовался Microsoft Visual C++ 2008 Express Edition (в данный момент они рекомендуют использовать версию 2010).

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

Если это ваш первый фикс бага в проекте, то помимо изменений в коде вам необходимо внести ваше имя в файл AUTHORS и включить это изменение в ваш коммит.

Шаг 4. Отправить баг на ревью

Ревью кода перед коммитом в проекте обязательно. Если у автора кода нет прав на запись в репозиторий (а это как раз наш случай), то именно ревьюер, как правило, коммитит код.

Шаг 5. Исправить review issues, перейти к шагу 4

Ревьюеры обычно отвечают на письма в течении 24-48 часов. В моих случаях было несколько раундов ревью, и, насколько я понимаю, это распространенная практика. После того, как все ревьюеры ответят LGTM (looks good to me), вы можете попросить одного из них закоммитить ваш код.

Шаг 6. Попросить ревьюера закоммитить ваш код

Я обычно просто писал что-то вроде “Could you please commit it for me?” и получал через некоторое время письма от tryserver, а потом от commit-bot о том, что код попал в репозиторий.

Шаг 7. Наслаждаться результатом

В целом весь процесс оставил у меня самые положительные впечатления. Код качественный, все организационные и технические моменты подробно задокументированы на сайте chromium.org и в исходном коде. Утилиты удобные, а люди - дружелюбные.

С удовольствием отвечу на вопросы в комментариях.

Теги:

• chromium
• google chrome

Добавить метки

Это не пустой призыв, в данном посте я расскажу какие бонусы приносят бесплатные сервисы и open source проекты…

И так начну со перечисления своих проектов (я не скромный и плодовитый):

• Бесплатные сервис: Charts Builder (~3 000 посещений)
• jQuery плагины: (a) Slideshow (~2 500 скачиваний), (a) Sexy Images (~500), jQuery iPhone UI (~3 500)
• WordPress плагины: (a) Slideshow (~14 000) и (a) QR Code (~300)
• WordPress темы: Constructor (~200 000), Black Urban (~16 000)
• PHP библиотеки: ZFCore (~800), jQuery PHP (~7 500), Yandex XML (~700), (~1 200)
• Разное: iCMS (~700)

Теперь о плюшках, которые мне дал каждый из этих проектов:

Опыт разработки

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

// Create new instance of Yandex class $Yandex = new Yandex(); // Set Query $Yandex -> query($query) -> host($host) // set one host or multihost -> page($page) // set current page -> limit(10) // set page limit -> geo($geo) // set geo region - http://search.yaca.yandex.ru/geo.c2n -> cat($cat) // set category - http://search.yaca.yandex.ru/cat.c2n -> request() // send request ;

Опыт общения

В моей повседневной работе я редко общаюсь непосредственно с заказчиками, а вот занимаясь поддержкой своих проектов — постоянно. Кто-то что-то спрашивает, кто просит о фичах, а кто указывает и на ошибки. Помню было время, когда каждый баг или изменение функционала в рабочих проектах воспринимался в штыки, с open source проектом такой фокус не пройдет, ты либо адекватно реагируешь, либо теряешь пользователя. Такой расклад достаточно хорошо дисциплинирует. В моем почтовом ящике нет не отвеченных писем, хотя иногда и приходится начинать письмо с фразы «sorry for the late reply letter».

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

Thats all when ANTON says anything listen to him he is always right:D

Монетизация

Сервис Charts Builder, как и большинство домашних страниц монетезированы при помощи Google AdSense, кое-где висит Text-Ads-Links , выхлоп при этом составляет ~$20 с AdSense и $60 с Text-Ads-Links в месяц (это всего 8 ссылок).

Конечно какие-нибудь true-сеошники скажут, что это мизерный заработок и посоветуют SAPE, XAP, Бегун и т.д, или еще какую иную систему, но я то уже многое перепробовал, и могу сказать, что рекламируете вы эти продукты исключительно с реферальными ссылками (хотя по началу отдача впечатляет, пока пузомерки не сдуются).

На каждой домашней страничке проекта у меня висит кнопочка «PayPal Donate» — именно она приносит свои плоды. С момента ее появления, а это декабрь 2009, мне накапало от сознательных людей ~$600. Для более активной стимуляции пользователей стандартная кнопка была заменена на progress bar :

Так же планирую открыть открыл страничку со списком всех благодетелей, хотя конечно это больше походить на покупку ссылки, но кого это интересует? Подобным образом сделана страничка проекта :

Бонусы

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

Ну еще бонус – мне вот недавно понравилась IDE PHPStorm , и у меня сейчас установлена бесплатная лицензионная версия для open source разработчиков:

У разработчиков WordPress тем есть дополнительный бонус в виде входящих ссылок (SEO специалисты смогут перевести эти цифры в деньги):

Трудозатраты

Тут все не так безоблачно, на разработку и на поддержку проектов естественно требуется время. Я могу рассказать о создании сервиса http://charts.hohli.com , просто тут не было поддержки и каких либо изменений, лишь разработка и отдача. Разработка заняла у меня один воскресный день, именно так, я просто читал новости, увидел сообщение о выходе нового Google Charts API и целый день потратил на разработку. Стоимость моего выходного дня — €165. В дальнейшем, поднабравшись опыта, сервис был обновлен за 16 часов — +€150.

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

Раскруткой проектов практически не занимаюсь, статья в блоге + статья на хабре , вот и всё.

P.S.

В действительности, большинство моих проектов — это изучение нового, просто не хочется тратить время на простенькие примеры «hello world», ведь хочется создать действительно что-то полезное. Учил Google Chart API — создал charts.hohli.com , надо было подучить WordPress — вот вам Конструктор , изучал возможности jQuery UI — вот и iPhone UI подоспел, примеров могу приводить много.