В этой статье не будет психологических исследований на тему open-source и разработки.
Не будет анализа open-source проектов с помощью R или Python.
И не расскажу о том, как правильно контрибьютить.
Возможно я даже буду говорить какие-то банальные вещи.
Но я всего лишь хочу поделиться тем, как участие в open-source проектах сделало мою жизнь разработчика ярче и продуктивнее.
Впервые я узнал про мир открытого ПО где-то в году 2009, когда начал серьёзно заниматься программированием и зарабатывать этим.
Но впервые отправил pull request в open-source проект году только в 2012. Это было попытка добавления Redis в качестве провайдера для кэша в Joomla Framework. Скажем так, попытка была не самая удачная, но попробовать очень хотелось.
Вернулся я к open-source позже — в 2015.
Я долгое время пытался придумать и реализовать с друзьями и коллегами разные идеи, «замутить стартап» и тд. Но всё почему-то захлёбывалось, лично мне не хватало мотивации.
Тогда я попытался взглянуть на эту ситуацию и понять почему это происходит.
Я понял, что всё дело в том, что меня интересовали не сами идеи, стартапы, бизнес, мне была интересна разработка и программирование.
И поняв это, я решил что если мне интересно программирование как таковое, то почему бы не направить это в полезное русло и не помочь улучшить инструменты, которыми я пользуюсь. Так я начал периодически отправлять pull request'ы в проекты, которые мне нравятся (Yii2, Design Patterns, Django)
Почему это интересно?
1. Знакомство с новыми людьми
За всё время, что я контрибьютил в открытый код, я познакомился с большим числом отличных людей. Все они невероятные профессионалы, с которыми приятно общаться, делиться, узнавать новое. У каждого из нас есть возможность пообщаться с создателями любимых продуктов, получить от них отзыв. В целом коммьюнити — одна из самых важных составляющих таких проектов.
2. Участие во всемирно известных проектах
Вы можете работать в маленькой компании или жить где-то очень далеко, но у каждого есть возможность поучаствовать в развитии проектов, которыми пользуется весь мир. Facebook, Google, Ebay и другие выкладывают свои разработки во всеобщий доступ и мы имеем отличный шанс стать частью сообщества разработчиков таких интернет-гигантов.
3. Это весело
На самом деле, разработка ПО с открытым кодом зачастую бывает очень весёлым занятием, сопровождающимся живым общением.
Вот несколько примеров.
https://github.com/jglovier/gifs
https://github.com/kristopolous/BOOTSTRA.386
https://github.com/lwe/whatthecommit
https://github.com/theonion/fartscroll.js
4. Признание
Это довольно интересное и тёплое чувство, когда Ваш код вливают в ветку известного проекта. Вы понимаете, что Вы действительно хорошо поработали, что в конце концов Вы что-то можете.
Если Вы вдруг теряете интерес к программированию или Вам кажется, что у Вас что-то не получается, попробуйте Open Source — и Вы поймёте насколько «лечебным» он может быть.
Почему это полезно?
1. Новый неповторимый опыт разработки
Тот опыт, который вы получаете при разработке ПО с открытым кодом, Вы вряд ли получите где-то ещё.
Я помню как я волновался, когда отправлял свой первый pull request. Я перечитывал каждую строчку кода, проверял code-style и т.д.
Осознание того, что Ваш код увидят тысячи других разработчиков, сами создатели проекта, заставляет вас думать, что Вы пишите в своём коде и это очень важно.
Кроме того, open-source разработка прививает хорошие навыки, такие как соблюдение стандартов кода, написание тестов и многое другое.
К тому же, здесь всегда есть возможность сделать code review чужого кода, если Вы устали от непосредственно написания кода. Это тоже бывает очень полезно и для кого-то это действительно новый опыт.
2. Возможность изучить что-то новое
Лично я люблю изучать новые языки программирования. Прочитав пару-тройку книг, хочется попровать язык в реальных условиях.
Но так как мне никогда в голову не приходят хорошие идеи (ха-ха :)), я ищу интересные проекты с открытым кодом на новом языке, и пробую контрибьютить в них.
Бояться показаться новичком не стоит, никто за это журить не будет, если будут какие-то недочёты, Вы всегда можете их исправить. А если Ваш код всё же вмержили, значит Вы действительно поняли ту или иную часть языка и проекта и можете гордиться собой.
3. Отличная галочка в резюме
После того, как я начал контрибьютить, мне всё чаще и чаще пишут HRы со словами — «нам нравится Ваша активность на GitHub, приходите к нам на собеседование».
Я думаю для работодателя ссылка в Вашем резюме на Ваши pull request'ы, принятые в крупные проекты, скажет о том, что вы действительно пишите достойный код, если его одобрило большое количество людей.
Кроме того, намного круче вместо сухого, вырванного из контектста примера кода, прислать работодателю ссылку на принятый pull request.
4. Знай свой инструмент
Участие в разработке продуктов, которыми Вы постоянно пользуетесь, помогает Вам лучше понять его — как он устроен внутри, как работает, какие люди в конце концов стоят за ним.
Кроме того, Вы всегда будете знать какие новые «фичи» появляются в проекте, какие есть нерешённые проблемы и многое другое.
5. Персональное развитие
Open source разработка помогает развить не только навыки программирования. Вот, на мой взгляд, небольшой список того, какие персональные качества развиваются ещё:
- Умение общаться
- Внимательность и аккуратность
- Уровень английского языка
- ...
Этот список можно продолжать ещё.
Кроме того, я считаю, что в каждом человеке присутствует желание помогать другому человеку, и как раз-таки Open Source разработка даёт такую возможность.
Заключение
В конце я хотел бы сказать вот о чём — единственное о чём я жалею, что мне не всегда хватает свободного времени участвовать в open-source разработке. Замечательно, когда компания, в которой Вы работаете, понимает важность такого участия для разработчиков и самой компании и выделяет для этого часть рабочего времени (а я такое встречал).
Тем не менее, даже если Ваша компания не делает этого, старайтесь хоть иногда участвовать в разработке открытого ПО, это сделает Вас настоящим профессионалом и подарит отличный опыт.
Спасибо!
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (82)
VioletGiraffe
04.07.2016 14:14+5Пилю на Гитхабе свои проекты, иногда сабмичу баг-репорты в чужие. Не совсем то, что имелось в статье, но ответил «Да» :)
Shamov
04.07.2016 14:58А я контрибьютил и вмерживал чужие pull-request'ы раньше, но ответил «Нет» :) Поскольку вопрос был поставлен в настоящем времени.
andrewnester
04.07.2016 14:16+1на самом деле баг-репорты это тоже участие, это уже не пассивное использование продукта и приносит свои плоды, так что спасибо Вам!
darkAlert
04.07.2016 14:35+5Мне вот интересно, где люди находят время на участие в open source? Я когда с работы прихожу либо мысли заняты текущим проектом, либо совершенно ничего не хочется делать. На выходных же охото погулять и все такое, а не сидеть перед монитором.
andrewnester
04.07.2016 14:40+1Я когда с работы прихожу либо мысли заняты текущим проектом
в принципе как раз вот в это время я и нахожу час-другой для этого.
т.е. я стараюсь не думать о работе уже не в рабочее время, чтобы заняться своими делами, будь то участие в open-source или отдыхdarkAlert
04.07.2016 14:51+2но ведь проект на работе это тоже «твой» проект, особенно если ты занимаешь в нем одну из ключевых ролей. Я в такие моменты всегда вспоминаю сотрудников, работающих под управлением Джобса, которые были полностью увлечены создаваемыми продуктами.
andrewnester
04.07.2016 14:56+4тут уже скорее вопрос об эффективности работы. если 24 часа в сутки думать о проекте, будь то рабочий или свой собственный, это разительно снизит производительность.
проверено на опыте.
необходимо периодически переключать контексты, задачи. не говоря об отдыхе.
иногда действительно можно работать сутки напролёт, а иногда это вредит и тебе, и проекту
Lure_of_Chaos
05.07.2016 01:19можно 24 часа в сутки думать о проекте, но не над одним.
контексты нужно переключать, причем, порой, лучше будет, если это случается спонтанно
нередко погружение на 15мин эффективнее часовмучений
прилежного старания.
кроме того, различные проекты оказываются полезны другу чаще, чем можно было бы подумать.
а потому полезно участие в разработке сторонних (неважно, опен-сорс или нет, ведь лично у вас есть доступ к исходникам) проектов — будь то контрибьют и пулл-реквесты, проект «для себя» или фриланс — это всегда повод поучиться на чужих ошибках и историях успеха, попробовать набить шишек с альтернативным подходом или фреймворком\библиотекой, да и просто получить материал для неожиданных «откровений» ни с того ни с сего
Ivan_83
04.07.2016 16:36+1По работе иногда приходится что то чинить или обновлять.
За пол года по работе: два багрепорта в clang с примерами как пофиксить, одно закрыто.
Один в порты фри с обновлением либы, пока висит.
А вне работы потребовалось вакомовский планшет прикрутить во фрю, что потянуло патчи к портам: x11-server, x11-input-wacom и webcamd.
Они там пока вату катают и не влили патчи, но у меня оно вполне работает.
В целом довольно странно работать с каким то чужим кодом и быть там всем довольным, как правило это от поверхностного понимания происходящего или низких потребностей, которые полностью закрыты тем что есть.
ButscH
04.07.2016 17:17+3Я на работе веду разработку нескольких проектов, один из них написан на Laravel и за основу использует https://github.com/LaravelRUS/SleepingOwlAdmin, когда я решил использовать эту админку, то она уже не развивалась достаточно долгое время, пришлось возродить проект. Помимо этой админки у меня есть еще один проект, которому я также стараюсь уделять время https://github.com/KodiCMS/kodicms-laravel, который гораздо крупнее. Поверь мне, я очень рад, что я могу ими заниматься (и да, я нахожу на них время даже в выходные будучи женатым), ведь это развитие и мне часто предлагают различные вакансии, а благодаря этим проектам я становлюсь ценным кадром.
deksden
04.07.2016 19:11+3Можно в ходе какого-либо проекта попробовать использовать какой-либо открытый проект, и обнаружить в нём отсутствие мелкой, но тебе удобной и нужной фичи, и запилить PR на неё.
ilansk
11.11.2016 18:06С физической точки зрения время: это когда физик берет относительно себя какие-то циклические изменения за эталон, потому что они ему кажутся независимыми и сравниваем их с другими изменениями. А потом подсчитывает сколько изменений уложилось в другие изменения. Так за 1 ден происходит 24 часа, а 1 с свет проходит 300000000 км и т.д. выбор циклических изменений меняется взятых за эталон времени то же меняется: раньше секунда привязана была к вращению солнца, а теперь к Цезию-133. Мудрец был прав: в этом мире постоянны только перемены!
0xd34df00d
09.07.2016 00:16+1Они занимаются этим, когда в выходные льёт осенний дождь или метет пурга?
Хехе.
MaximKulkin
09.07.2016 00:24Ссылочку дайте. У кого-то может быть рабочий репозиторий на гитхабе, может — кому-то платят за контрибуты (да при том в собственный же репозиторий), может — кто-то правит по строчке то тут, то там, а может — он студент-no-life'ер. Разбираться надо.
0xd34df00d
09.07.2016 01:21Как ни странно.
Не рабочий репозиторий, не платят за контрибьюты. Репозитории, впрочем, почти все свои. Да и ноулайфер, пожалуй.MaximKulkin
09.07.2016 02:16Просмотрел я выборочно комиты разных дней в разные репозитории (в том числе и по выходным, где коммитов больше всего): конечно, похвально, что Вы так аккуратно описываете каждое изменение и не ленитесь коммитить, но смысла во всем этом мало. Это выглядит как: «сел», «покакал», «встал», «поковырялся в носу», «открыл воду», «помыл руки», «закрыл воду». Никому, читая логи репозитория, не нужно такой детальности. А за всеми этими деталями не видно, какие фичи есть у проекта и когда они были добавлены.
Я скорее отношусь негативно в такому стилю. Я сам делаю достаточно логически изолированные коммиты, но во всем нужно чувство меры.
Похоже, Вы специально нарабатываете себе профиль, чтобы потом на собеседованиях показывать: не важно что, но каждый день надо коммитить. И по факту, это не контрибуты в опенсоурс, со всеми ревью, прениями, переделками и пользой сообществу от того, что делаете.0xd34df00d
09.07.2016 02:24+1Это атомарные коммиты, чтобы было легко бисектить, ревертить, и так далее. Закончил мысль — поставил точку, с гита не убудет. А для фич проекта не нужно читать логи репозитория, лучше читать специально подготовленные ченджлоги.
А насчёт пользы обществу — ну, так никто и не говорил, что что-то делается ради неё. Когда-то давно я об этой пользе задумывался, а потом подумал, что для пользы у меня есть оплачиваемая работа, а тут можно что-то делать, не задумываясь об этой пользе.
Впрочем, это, например, исходники некоторой научной работы с публикуемыми (и уже опубликованными) статьями. Чем не польза обществу?Я просто arXiv не осилил
Не знаю, <a href=«https://github.com/0xd34df00d/IAmMad>это — вполне себе маленькая, обособленная и теоретически полезная библиотека. Но да, чтобы была эта пресловутая польза обществу, нужно, например, чтобы о ней знали, а этим мне заниматься уже лень.MaximKulkin
11.07.2016 11:46Я о том, что нет такого понятия «атомарные коммиты». Например, Вы исправляете форматирование во всем проекте: можете коммитить каждую строчку отдельно (атомарный коммит, чо), а можете — все сразу.
Лично я работаю так: нужно добавить нужную фичу. Надо порефакторить/поре-инжиннерить код, поправить сломавшиеся тесты, потом только добавлять новый функционал. Я не коммичу код до тех пор, пока оно не заработает и станут понятны все изменения. Только потом я стэйджу индивидуальные изменения и разбиваю их на логические коммиты.
Насчет ченджлогов: кто ж их писать будет?! Во-первых, пожалейте этого бедного человека: ему придется разгребать тонны бесполезных коммиты сообщений. Во-вторых, зачем вести отдельный лог, когда можно просто структурировать свои коммиты правильно?! Или, например, есть подозрения, что в каком-то файле ошибка и надо посмотреть кто и зачем менял конкретную строчку. Если у Вас коммиты не «поменял вот эту строчку», а «добавил вот такую фичу», проще найти концы.andrewnester
11.07.2016 11:51есть хорошая практика в больших open-source и не только проектах — пулл риквест создаётся 1 на конкретную фичу, и в пулл риквесте только 1 коммит, реализующий эту фичу
khim
11.07.2016 16:07А что делать если для реализации фичи нужно несколько тысяч строк кода написать? Разбивать на отдельные «фичи»? Разумно, да — но тогда та же проблема всплывёт на следующем уровне: возникнет вопрос — что такое «фича».
Что касается атомарности — тут всё просто: не нужно коммитить проект в «разобранном» состоянии. Любая версия должна собираться и, в идеале, проходить все тесты. В идеале — потому что может оказаться что есть какие-нибудь стресс-тесты, которые сутки ходят — их можно исключить, чтобы не тормозить разработку.
Исправлять форматирование по одной строке — бред, но если вы реально над каждой из них думали отдельно и аккуратно там пробельчики размещали — почему нет? Как верно заметили: с git'а не убудет…MaximKulkin
11.07.2016 19:57Насчет «коммитить в разобранном состоянии»: да, надо коммитить так, чтобы проект собирался и все тесты проходили. Никак не отменяет всего вышесказанного.
Насчет «если вы реально над каждой из них думали отдельно и аккуратно там пробельчики размещали — почему нет?», потому что нет. А еще забавно смотреть, когда у людей в пулреквесте видна вся борьба: коммиты «ой, у меня тут опечатка», «пофиксил тест, который сломал предыдущим коммитом», «пофиксил форматирование моего нового кода». Вот в истории совершенно необязательно видеть какой Вы растяпа.0xd34df00d
12.07.2016 03:49Ну а что же поделать, если такова история? Переписывать историю вообще не очень круто, как по мне.
Поэтому я не делаю ребейзы.khim
12.07.2016 13:40Ну а что же поделать, если такова история? Переписывать историю вообще не очень круто, как по мне.
Это, собственно, принципиальное отличие между Git'ом и Mercurial'ом.
Философия Mercurial'а — как у вас: история штука ценная, переписывать её никак нельзя.
Философия Git'а — практически полная противоположность: история штука ценная — потому нельзя её пускать на самотёк, её должны писать летописцы.
Поэтому я не делаю ребейзы.
Ну в своём проекте — это допустимо. А вообще — rebase штука полезная. Линус про это как-то писал: в своём репозитории rebase делать можно и нужно (никому не интересно поверх какой версии вы начали разрабатывать свои правки). Но когда вы их привели к состоянию, когда их «не стыдно показать» (написали хорошую историю), после этого, да, rebase делать не стоит…0xd34df00d
13.07.2016 02:59Линус про это как-то писал: в своём репозитории rebase делать можно и нужно (никому не интересно поверх какой версии вы начали разрабатывать свои правки).
Может быть интересно тимлиду, например, чтобы понять, кто из двоих накосячил.
Когда история не переписывается, то не теряется информации вообще совсем никакой, и мне это как-то интуитивно нравится больше. Ленивый я, не люблю терять информацию слишком рано :)
Тем более, что непонятно, что я теряю от мержей вместо ребейзов кроме самого факта линейности истории, что мне представляется не настолько уж важной самоцелью.khim
13.07.2016 14:15Тем более, что непонятно, что я теряю от мержей вместо ребейзов кроме самого факта линейности истории, что мне представляется не настолько уж важной самоцелью.
Вы — не теряете. Теряют другие. Вместо того, чтобы рассматривать вашу правку как что-то атомарное (и либо откатить её всю, либо оставить) они вынуждены разбирнаться в том, как вы чихали и чистили зубы.
Когда у вас будет 200 правок в день (в среднем — в какие-то дни побольше, в какие-то поменьше) вы сами захотите отказаться от того, чтобы смотреть на чужую историю. А я своя — вот она, в своей ветке git'а, её убивать никто не просит.
Ленивый я, не люблю терять информацию слишком рано :)
Никто не просит «терять информацию». Просят её убрать «с глаз долой». Ещё раз: никому не инетересно как вы там шатались из стороны в сторону при разработке ваших изменений. Хотите чтобы на них было приятно смотреть другим людям — причешите историю! Если совсем лениво — «схлопните» её, но не заставляйте других читать то, что им совсем не нужно! Они ведь — тоже ленивые!
MaximKulkin
11.07.2016 19:49Я такое видел только в проектах, которые используют Gerrit (привет, OpenStack!). Я считаю, это глупость и ограничения этой review тулзы. Но и коммитить по одной строчке — перебор. Надо искать баланс
0xd34df00d
12.07.2016 03:48Почему перебор? Атомарное изменение. Вы не можете гарантировать (ну, как проверенные доказательства гарантируют), что код точно работает после вашего изменения, поэтому вы хотите максимально облегчить себе будущему жизнь и сделать так, чтобы git bisect привёл вас максимально близко к точке поломки, например. Коммиты по три строчки в этом очень помогают, проверено опытом.
0xd34df00d
12.07.2016 03:46+1Практически вчерашний пример: такой вот revert.
Ченджлоги всё равно надо писать руками. Потому что и так никому не интересно, что вы там поменяли форматирование, исправили даты авторства в лицензии, или ещё что. Поэтому лично я пишу ченджлоги, сортируя по имени модуляgit log --format=oneline(или как его там), убирая те модули, которые только добавились в новом релизе (а чего про их изменения писать, они же новые), убирая черезgrep -vещё пару типов коммитов вроде мержей, всяких фиксов кода, «Updated documentation for the Functor typeclass», и так далее.
Собственно, суммарно на поддержание ченджлога для текущей версии, с овер 7к коммитов и двух лет разработки, у меня ушло где-то от двух до трёх часов. Писать release announcement на сайт всяко дольше и труднее будет.
Так, чтобы по описанию коммита сразу всё было понятно про все строчки, я ещё не видел. Linux Kernel, вероятно, к этому максимально близок.MaximKulkin
12.07.2016 04:33+2Оправдание лишней работы? Чендждлоги надо писать руками, но можно это делать копаясь в списке изменений в раз в 5 короче. Хорошо, что Вы можете разобраться в большом кол-ве своих коммитов. Но если Вы работаете в команде и все коммитят в Вашем стиле, я уверен, Вам придется не только читать коммиты, но и разбираться куда и зачем они (а если еще кто-то не утруждает себя написанием внятных комментариев к коммиту, то это вообще тушите свет).
0xd34df00d
13.07.2016 03:00Так если я работаю в команде, то я пишу ченджлог по тем изменениям, которые сделал я, Вася — по своим, Петя — по своим, и всё.
khim
13.07.2016 14:17Проблема в том, что разобраться в каком-нибудь изменении без контекста — та ещё проблема. А вникать в контекст всех их мелких изменений в большом проекте — жизни не хватит.
0xd34df00d
13.07.2016 16:34Так а зачем мне вникать в их изменения? А если мы вместе работали над одним либо совместными модулями, то и вникать не надо, всё и так ясно.
khim
13.07.2016 23:41Так а зачем мне вникать в их изменения?
Потому что они у вас в истории. И на одном из них что-то развалилось.
А если мы вместе работали над одним либо совместными модулями, то и вникать не надо, всё и так ясно.
Это пока у вас кода немного «всё и так ясно». Будет у вас в проекте несколько миллионов строк и тысячи коммиттеров — совсем другие песни пойдут, поверьте.
makenskiy
04.07.2016 14:51+10Понимаю что мало вероятно хабр меня поддержит, однако не могу промолчать.
По моему не большому опыту, Open Source съедает большую долю времени, и ничего не приносит взамен кроме этого самого опыта, м.б. еще туманной формулировки «Вас заметят», крайне редко, можно получить $2 от такого же человека.
Он хорош как начало, чтобы было что показать работодателю/заказчику. Однако откинув романтику, и прочее «Миру-мир», кушать хочется сейчас, а не когда-то там возможно. Опыт можно и нужно получать с денежной мотивацией, пусть маленькой. А уж, когда есть свободное время, можно заняться «Хобби», т.е. безвозмездно. Тут тоже не все однозначно, когда человек начинает работать, время всегда нет, а если есть семья, и подавно.
Сам активно пользуюсь плодами, не без этого конечно. Немного участвую в одном из проектов. Самый большой минус этого занятия (за себя говорю) — наплевательское отношение к поддержке продукта. Можно сделать вроде бы неплохую вещь, и мгновенно перегореть.andrewnester
04.07.2016 15:27+10лично для меня участие в open-source — это профессиональное развитие, которое поможет мне вместо сегодняшних X получать завтра X + 10% и кушать больше)
Но в общем и целом доля правды в Ваших словах есть
RevenantX
04.07.2016 15:56+7Я например опенсорц выделяю из своих личных домашних проектов.
Если я вдруг сделал какую-нибудь универсальную утилиту (или библиотеку), которая у меня
используется в нескольких проектах — то я просто немного оформляю README файл и выкладываю на гитхаб.
И вполне находятся люди которые ими пользуются. И если кто присылает баги — то я их чиню и для своих проектов которые используют данную библиотеку.
VioletGiraffe
04.07.2016 22:25Согласен на 100% насчёт поддержки. Единственным моим проектом, который хоть как-то взлетел и которым люди пытаются пользоваться, мне уже давно неинтересно заниматься, а интересно другими.
vitalybaev
04.07.2016 23:02+1Скажите это Тейлору Отвелу, создателю фреймворка Laravel :)
А по хорошему, надеяться на донат в OpenSource не стоит, обычно люди занимаются им не только для этого
khim
04.07.2016 23:12+3Попытка заработать напрямую на Open Source проекте — глупость несусветная. То есть если у вас в компании используется какой-нибудь GCC или Clang, то да, компания может оплатить одного-двух разработчиков инструмента. На 100 тех, кто его использует, да. Но — это редкость. А другого способа заработать на Open Source, почитай что и нету.
Воспринимайте лучше Open Source как «курсы повышения квалификации». Вы же не получаете денег, изучая какой-нибудь инструмент — обычно наоборот, за курсы ещё и платить нужно! Чтобы сделать небольшую доработку в какой-нибудь Python или Django вам потребуется столько же времени и сил как и на то, чтобы пройти соотвествующие двух-трёхнедельные курсы, а пользы — будет несравненно больше.
Ronnie_Gardocki
05.07.2016 07:48+2С точки зрения индивидуального разработчика, опенсоус бывает двух типов — участие в разработке больших проектов и запиливание вещей от своего имени.
В первом случае можно конечно делать крутые штуки, писать шикарный код и все такое, но велики шансы остаться полностью незаметным «хорошим парнем».
Во 2 случае можно в свое удовольствие пилить пет-проджекты на гитхабе или демки на codepen, и в случае их успеха ваша жизнь заметно улучшится. Я вот своему карьерному росту полностью обязан запиливанию демок на codepen, причем рост этот очень даже серьезный, в стандартных офисах будучи «прилежным работягой» о таком можно забыть.
Aingis
08.07.2016 17:30Всё так, нужно много времени и напрямую денег особо не заработать (хотя бывают случаи, когда заказывают какую-то разработку). Тем не менее время находится. Это могут быть выходные. Это может быть отпуск, когда дней через пять отдыхать становится откровенно скучно. Я так в отпусках изобретал и писал.
Опенсорсный код можно показать потенциальному работодателю, некоторые так даже просят примеры кода. Можно также рассказать, какие были интересные (сложные) проблемы, как они решались. (Особенно, если по основной работе не сталкивались с таким.)
Я лично начал поддерживать SVGO, когда посмотрел на него и удивился, почему в нём не было каких-то довольно банальных для меня вещей. Сделал пару плагинов, написал Киру deepsweet, так и стал мейнтейнером. Есть ещё идеи, но они требуют серьёзной архитектурной переработки. К сожалению, действительно, с основной работой совмещать сложно. Нужно выискивать свободное время.
niknik3135
04.07.2016 16:20+1Часто бывает желание присоединиться к какому-нибудь проекту (как раз по верно описанным автором причинам), но элементарно не знаю к какому. В крупные типа Postgres далекому человеку войти сложно да и желающих, наверное, много, а о начинающих и небольших банально не от кого узнать, если в проекте нет твоих знакомых. Все таки это еще та социальная сеть.
andrewnester
04.07.2016 16:23крупные типа Postgres далекому человеку войти сложно да и желающих, наверное, много
ну почему же сложно, если Вы более-менее хорошо знакомы с языком, на котором написан проект, и самим проектом, то всё вполне легко.
Например, тот же Django для новичков предлагает так называемые «easy picking» тикеты — простые тикеты, которые легко решаются и помогают начать контрибьютить в Django.
просто выбирайте проект, который Вам нравится, и дерзайте, попытка не пытка как говорится :)
namc
04.07.2016 23:13Кстати, может знаете, есть ли 'easy picking' для RoR?
andrewnester
04.07.2016 23:17+1выглядит как будто нет, но дока как контрибьютить в целом у них не плохая http://guides.rubyonrails.org/contributing_to_ruby_on_rails.html#helping-to-resolve-existing-issues
Wedmer
04.07.2016 16:25+2А вы попробуйте те проекты, без которых вы и дня не проживете) Или те, с которыми приходится работать чаще всего.
Для меня таким проектом стал OpenWrt.
Ivan_83
04.07.2016 17:40+7Всем плевать кто ты и что ты раньше делал.
Главное насколько качественный от тебя код и насколько ты сам адекватен.
И тут как с девушками: нужно пробовать, и даже отказ лучше чем ничего.
Есть некоторые проекты в которых мало ресурсов для ревью кода, и там патчи могут висеть годами, даже качественные и по теме.RomanArzumanyan
04.07.2016 18:34Всем плевать кто ты и что ты раньше делал.
Главное насколько качественный от тебя код и насколько ты сам адекватен.
Противоречиво. Зачем тогда резюме смотрят?
darkAlert
04.07.2016 17:30Господа, ответьте честно — правда, что среди разработчиков есть такие люди, которые выходные дни проводят за написанием кода и считают это отдыхом и развлечением? Т.е. для таких людей хобби совпадает с основной профессией. И правда, что такие разработчики и есть профессионалы высочайшего уровня, до которого обычным смертным никогда не дорасти (если также не задротить)?
andrewnester
04.07.2016 17:33+3выходные в основном провожу отдыхая и занимаясь всякими разными несвязанными с программированием делами.
но вот вечерок-другой могу потратить на свой проект, изучения нового языка, контрибьютинг.
и да, это даёт какую-то отдушину.
недавно, если не ошибаюсь на Хабре, была статья, в которой была фраза (дословно не помню) — «Чем программист отличается от любого другого работника? Он в рабочее время пишет код и в свободное… он тоже пишет код»
webkumo
04.07.2016 18:05+2Ну вот только не надо создавать иллюзий. Слесарь тоже «на работе слесарит и дома слесарит»… Хороший слесарь. Т.е. по факту выруливаем к сентенции «профессионал бытовые проблемы (решаемые его областью деятельности) решает сам». И бывает от этого доволен. У хорошего мебельщика дома мебель тоже будет отличная.
andrewnester
04.07.2016 18:26+1согласен, если человек любят своё занятие, то и после работы он легко может им заниматься, неважно слесарь он, повар или программист.
просто в большинстве случаев программистам нравится их работа, поскольку программировать «через силу», как мне кажется, получится вряд ли.
andrewnester
04.07.2016 18:03+2И правда, что такие разработчики и есть профессионалы высочайшего уровня, до которого обычным смертным никогда не дорасти (если также не задротить)?
на мой взгляд, это не так.
профессионализм не зависит от этого.
если вам нравится то, что вы делаете и вы постоянно развиваетесь (читаете, учите и т.д.) — вы и есть профессионал
RubaXa
04.07.2016 18:06+6Да, есть, для меня хобби стало работой, насчет уровня ничего сказать немогу, но
эта картинка никогда не была шуткой
andrewnester
04.07.2016 18:11+1Идеальный вариант выделять open source в рамках задач компании, вот тогда хорошо.
собственно, это и написано в заключении :)
Oxoron
04.07.2016 18:13Идеальный вариант выделять open source в рамках задач компании, вот тогда хорошо.
Вопрос в том, как уговорить начальство выделить код в OpenSource. Какая мотивация у лида\архитектора\менеджера?andrewnester
04.07.2016 18:23+1я бы из пунктов, которые их могут мотивировать выделили бы
- Повышение квалификации сотрудников
- Повышение мотивированности сотрудников, повышение их заинтересованности
- Прямое доказательство компетентности сотрудников для потенциальных заказчиков (мол смотрите, наши разработчики вон в каких проектах участвуют)
RomanArzumanyan
04.07.2016 18:30+2«Если взлетит, то наш код протестируют сотни доброльцев. Если нет — ничего не потеряем».
ИМХО, тут, скорее, важна политика компании к open source'у как таковому. Например, если компания делает деньги на open source продуктах, то скорее всего, upstream'ить разрешат. Плюс это здорово развивает разработчиков — прививает аккуратность в выборе софтверных лицензий и прочего.
RubaXa
04.07.2016 18:31+1Прежде всего надо разобраться, почему вы решили, что нужно разрабатывать с нуля? Почему не выбрано одно из существующий решений (всегда что-то существует)?
Ну, а дальше:
— Писать общее решение, а не решать узкую задачу (т.е. писать в отрыве от проекта)
— Писать тесты и документацию.
— Продвигать
— Поддерживать 7/24.
И вот тогда можно начинать думать о open source, тогда он выполнит свою функцию, раскроет узкие места/баги вашего решения, покажет неожиданные векторы развития и применения.
khim
04.07.2016 23:24+1Вопрос в том, как уговорить начальство выделить код в OpenSource. Какая мотивация у лида\архитектора\менеджера?
Экономия денег, однако. Ничего другое бизнесу не интересно.
Вопрос, который нужно задать себе, очень прост: вот эта вот шняга, которую мы тут делаем — это наше «Ноу-Хау», которое мы продаём или вспомогательная служба, которую мы можем отдать на откуп фрилансерам? А если это — не что-то, что мы продаём, то, может быть, дешевле вот этот вот «что-то» разрабатывать совместно с конкурентами?
Оказывается что ответ на оба вопроса положителей гораздо чаще, чем кажется на первый взгляд. Каждый раз, когда заходит вопрос о том, чтобы отправить задачу что-то на «аутсорс» стоит одновременно посмотреть — а нельзя ли «вот это вот» превратить в Open Source?
P.S. Если ваша компания отдаёт «на аутсорс» то, на чём она зарабатывает деньги, то у меня для вас плохие новости…Oxoron
05.07.2016 09:54А какие есть недостатки у OpenSource для компании? И как их обходить.
Я пока вижу затраты времени, и шанс того, что развитие либы пойдет «не туда». Да и внесение изменений может замедлиться.
P.S. Моя компания занимается тем, что сдает за процент сотрудников-аутсорсеров. И мой текущий клиент вполне себе доволен: я работаю с кодом, а он это дело контролирует (сам программер, так что реально контролирует).khim
05.07.2016 11:40+1А какие есть недостатки у OpenSource для компании? И как их обходить.
Собственно тот факт, что соответствующий код будет доступен «без оплаты» конкурентам. Если это что-то, что позволяет вам делать ваш продукт лучше/дешевле, чем у конкурентов то ответ как бы самоочевиден, нэ?
Я пока вижу затраты времени, и шанс того, что развитие либы пойдет «не туда». Да и внесение изменений может замедлиться.
А тут как бы «кто первый встал — того и тапки». Если вы превратили свой проект в Open-Source то вы и решаете — куда он идёт. Конечно если проект становится реально большим, то это становится делать сложнее — но до этого ещё дорасти нужно.
А вот если аналогичный проект уже кто-то запилил и «набрал критическую массу», то у вас как раз будут проблемы — либо вы будете должны сделать что-то, что резко лучше уже существующего (как пример — ninja), либо вам придётся отказаться от своего проекта и начать использовать то же, что используют другие (скажем JSON вместо PB).
P.S. Моя компания занимается тем, что сдает за процент сотрудников-аутсорсеров.
Вот для вас — как раз ситуация сложнее, но принцип тот же: вещи, которые вы используете как базу для того, чтобы продавать ваши услуги заказчикам — нельзя пускать в Open Source, какие-то вспомогательные вещи, которые вашим сотрудникам нужны, но за которые непосредственно заказчик не платит — можно и нужно. Но тут уже надо быть аккуратнее: вполне может оказаться что-то какая-нибудь не слишком сложная библиотечка, вокруг которой вы всё и строите — и есть, на самом деле, ваше «ноу-хау», из-за которого к вам клиенты обращаются. Так что вам — сложнее.
MonkAlex
04.07.2016 18:08+2На первый вопрос — да.
Я пишу код 5 дней в неделю и вполне могу потратить 1 или 2 выходных на код же.
Ничем серьезным правда не занимаюсь, но в этом и соль, никакой обязаловки, пиши что нравится.
akardapolov
04.07.2016 19:27+2Один из способов сменить вид деятельности. Основная работа, бывает, надоедает до чертиков — вот, одно из направлений (полезных!) сменить активность. Как спорт, только развивает другие группы мыщц :)
VioletGiraffe
04.07.2016 22:33+1Иногда мне хочется в свободное время поиграть в компьютерную игру, иногда — посмотреть сериал, иногда — сесть и допилить что-то в одном из своих проектов. Это всё происходит волнами, но в среднем за год получается примерно 40% игры / 40 % кодинг / 20% сериалы — просто мало хороших сериалов :) Другие виды времяпрепровождения в нерабочее время у меня отнимают несоизмеримо меньше времени.
Естественно, во время кодинга я слушаю музыку, а также нередко отвлекаюсь на интернет/ютуб и т. д., т. е. это не 100% работа в IDE.
nzeemin
05.07.2016 02:10Да, дома пишу свои хобби-проекты. Неторопясь. Один из них был начат в 2006 году, до сих пор развивается.
gricom
04.07.2016 19:42+2Контрибьютил в closed-source проект (Oracle Coherence) баг репорт с описанием фикса, патч не присылал, ибо по лицензии нельзя декомпилить код, поэтому написал пару юнит-тестов, которые указывали чуть ли не на строчку в исходниках, которую надо пофиксить.
Adnako
05.07.2016 00:12-2> Это весело
Есть мнение, что слово «fun» нельзя просто так взять и перевести на русский как «весело».
Честно положа руку на орган — такой перевод — признак пофигизма.
Постарайтесь понять смысл и передать его вместо дословного, но идиотического «весело».
Прямо бесит уже.MonkAlex
05.07.2016 06:03+1Можно. Особенно, если вы без контекста это делаете. Потому что это весело =)
ivlis
05.07.2016 07:34+3Куча людей пишут, что они покупают кофе следующему в очереди просто из доброты. Я регулярно покупаю кофе. Мне ни разу из впереди стоящих не купил кофе. :looks suspicious:
MaximKulkin
05.07.2016 11:56+2У меня нет идеи фикс — срочно кому-нибудь что-нибудь законтрибьютить. Я давно и успешно трудоустроен и я предпочитаю выкладываться на работе. Иногда, конечно, работа надоедает и хочется отдушины — сделать что-нибудь полезное.
Но я хочу предостеречь людей, неопытных в опенсоурсе: это не всегда те розовые сопли, о которых так любят тут рассказывать. Да, вы будете знакомиться с новыми людьми. Но, не радуйтесь: не все люди таки интересные, чтобы с ними знакомиться. А иногда придется. И в ваших пул-реквестах будут появляться люди, которые с пеной у рта будут доказывать Вам какую-нибудь чушь. Или требовать, чтобы Вы в своем пул-реквесте починили какой-нибудь не относящийся в теме Вашего пул-реквеста баг, добавили какую-нибудь абсурдную фичу или что-нибудь типа того. И они будут ставить Вам "-1" только потому, что могут.
Потом Вам придется ждать, возможно, месяцами, когда у правильных людей дойдут руки, чтобы посмотреть Ваш пул-реквест, выдать Вам парочку указаний на переделку и опять пропасть на месяцок-другой. Все это время Ваш код будет обрастать конфликтами (потому что кто-то другой дождался-таки мержа его PR), Вы будете периодически заниматься обновлением Вашего PR.
Я не занимаюсь правкой опечаток или дописанием документации. Чаще всего, я или нахожу баг в библиотеке, которую сам использую, или хочу добавить в нее новый функционал. С багами проще, а вот с функционалом. Запасайтесь нервами, они Вам понадобятся.andrewnester
05.07.2016 12:13в общем и целом такое бывает конечно.
но опен-сорс — это свобода. если Вас что-то не устраивает можно перейти на другой проект.
слава богу, мне всегда попадались адекватные люди, которые делали замечания по делу, с которыми было приятно общатьсяaezhko
05.07.2016 15:33+2Справедливости ради отмечу, что работа «на дядю» — тоже свобода. Если Вас что-то не устраивает, можно перейти к другому дяде.
andrewnester
05.07.2016 15:40ну с этим несколько сложнее — есть контракты, договора, так быстро может не получится
aezhko
05.07.2016 15:44Так и в работе над открытым продуктом тоже могут быть свои обязательства, которые необходимо завершить перед выходом: например, почти пофикшенный баг еще не оформлен в виде пулл-реквеста.
MaximKulkin
05.07.2016 20:24+1Опенсурс — это свобода, когда Вы, ковыряясь в носу, не знаете чем себя занять. А когда Вы используете опенсурс компоненты и пытаетесь их улучшить (не только для себя, но и для других; и не хотите поддерживать Ваши приватные патчи и заниматься обновлением их с каждым новым релизом библиотеки), то внезапно нет у Вас никакой свободы: иногда нельзя просто так взять и переписать весь Ваш проект на другую похожую библиотеку, одновременно дописав в нее все то, что отсутствует во второй по сравнению с первой библиотекой (ведь Вы выбрали первую из-за ее фич, которых нет у других). Лучший выход — это держать свой приватный форк и одновременно пушить изменения в upstream. Это месяцы времени и уйма нервов. Вот я о чем.
claygod
Open Source конечно не панацея, но начинать лучше именно с таких проектов, а уж потом…
andrewnester
как я писал, это очень полезно при изучении новых языков, вам всегда укажут на ваши недочёты и огрехи, что вряд ли будет при написании собственного проекта, который может остаться «вещью в себе».