Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 84
Open Source конечно не панацея, но начинать лучше именно с таких проектов, а уж потом…
Пилю на Гитхабе свои проекты, иногда сабмичу баг-репорты в чужие. Не совсем то, что имелось в статье, но ответил «Да» :)
на самом деле баг-репорты это тоже участие, это уже не пассивное использование продукта и приносит свои плоды, так что спасибо Вам!
Мне вот интересно, где люди находят время на участие в open source? Я когда с работы прихожу либо мысли заняты текущим проектом, либо совершенно ничего не хочется делать. На выходных же охото погулять и все такое, а не сидеть перед монитором.
Я когда с работы прихожу либо мысли заняты текущим проектом
в принципе как раз вот в это время я и нахожу час-другой для этого.
т.е. я стараюсь не думать о работе уже не в рабочее время, чтобы заняться своими делами, будь то участие в open-source или отдых
но ведь проект на работе это тоже «твой» проект, особенно если ты занимаешь в нем одну из ключевых ролей. Я в такие моменты всегда вспоминаю сотрудников, работающих под управлением Джобса, которые были полностью увлечены создаваемыми продуктами.
тут уже скорее вопрос об эффективности работы. если 24 часа в сутки думать о проекте, будь то рабочий или свой собственный, это разительно снизит производительность.
проверено на опыте.
необходимо периодически переключать контексты, задачи. не говоря об отдыхе.
иногда действительно можно работать сутки напролёт, а иногда это вредит и тебе, и проекту
проверено на опыте.
необходимо периодически переключать контексты, задачи. не говоря об отдыхе.
иногда действительно можно работать сутки напролёт, а иногда это вредит и тебе, и проекту
можно 24 часа в сутки думать о проекте, но не над одним.
контексты нужно переключать, причем, порой, лучше будет, если это случается спонтанно
нередко погружение на 15мин эффективнее часов
кроме того, различные проекты оказываются полезны другу чаще, чем можно было бы подумать.
а потому полезно участие в разработке сторонних (неважно, опен-сорс или нет, ведь лично у вас есть доступ к исходникам) проектов — будь то контрибьют и пулл-реквесты, проект «для себя» или фриланс — это всегда повод поучиться на чужих ошибках и историях успеха, попробовать набить шишек с альтернативным подходом или фреймворком\библиотекой, да и просто получить материал для неожиданных «откровений» ни с того ни с сего
контексты нужно переключать, причем, порой, лучше будет, если это случается спонтанно
нередко погружение на 15мин эффективнее часов
мученийприлежного старания.
кроме того, различные проекты оказываются полезны другу чаще, чем можно было бы подумать.
а потому полезно участие в разработке сторонних (неважно, опен-сорс или нет, ведь лично у вас есть доступ к исходникам) проектов — будь то контрибьют и пулл-реквесты, проект «для себя» или фриланс — это всегда повод поучиться на чужих ошибках и историях успеха, попробовать набить шишек с альтернативным подходом или фреймворком\библиотекой, да и просто получить материал для неожиданных «откровений» ни с того ни с сего
Я на работе веду разработку нескольких проектов, один из них написан на Laravel и за основу использует https://github.com/LaravelRUS/SleepingOwlAdmin, когда я решил использовать эту админку, то она уже не развивалась достаточно долгое время, пришлось возродить проект. Помимо этой админки у меня есть еще один проект, которому я также стараюсь уделять время https://github.com/KodiCMS/kodicms-laravel, который гораздо крупнее. Поверь мне, я очень рад, что я могу ими заниматься (и да, я нахожу на них время даже в выходные будучи женатым), ведь это развитие и мне часто предлагают различные вакансии, а благодаря этим проектам я становлюсь ценным кадром.
Можно в ходе какого-либо проекта попробовать использовать какой-либо открытый проект, и обнаружить в нём отсутствие мелкой, но тебе удобной и нужной фичи, и запилить PR на неё.
Они занимаются этим, когда в выходные льёт осенний дождь или метет пурга? Хорошо бы проверить это — связать активность с погодой в регионах мира, скажем с помощью RAW, ROOT…
Это я про "Я когда с работы прихожу либо мысли заняты текущим проектом, либо совершенно ничего не хочется делать. На выходных же охото погулять и все такое, а не сидеть перед монитором." — попал просто не туда, куда хотел.
Ссылочку дайте. У кого-то может быть рабочий репозиторий на гитхабе, может — кому-то платят за контрибуты (да при том в собственный же репозиторий), может — кто-то правит по строчке то тут, то там, а может — он студент-no-life'ер. Разбираться надо.
Просмотрел я выборочно комиты разных дней в разные репозитории (в том числе и по выходным, где коммитов больше всего): конечно, похвально, что Вы так аккуратно описываете каждое изменение и не ленитесь коммитить, но смысла во всем этом мало. Это выглядит как: «сел», «покакал», «встал», «поковырялся в носу», «открыл воду», «помыл руки», «закрыл воду». Никому, читая логи репозитория, не нужно такой детальности. А за всеми этими деталями не видно, какие фичи есть у проекта и когда они были добавлены.
Я скорее отношусь негативно в такому стилю. Я сам делаю достаточно логически изолированные коммиты, но во всем нужно чувство меры.
Похоже, Вы специально нарабатываете себе профиль, чтобы потом на собеседованиях показывать: не важно что, но каждый день надо коммитить. И по факту, это не контрибуты в опенсоурс, со всеми ревью, прениями, переделками и пользой сообществу от того, что делаете.
Я скорее отношусь негативно в такому стилю. Я сам делаю достаточно логически изолированные коммиты, но во всем нужно чувство меры.
Похоже, Вы специально нарабатываете себе профиль, чтобы потом на собеседованиях показывать: не важно что, но каждый день надо коммитить. И по факту, это не контрибуты в опенсоурс, со всеми ревью, прениями, переделками и пользой сообществу от того, что делаете.
Я о том, что нет такого понятия «атомарные коммиты». Например, Вы исправляете форматирование во всем проекте: можете коммитить каждую строчку отдельно (атомарный коммит, чо), а можете — все сразу.
Лично я работаю так: нужно добавить нужную фичу. Надо порефакторить/поре-инжиннерить код, поправить сломавшиеся тесты, потом только добавлять новый функционал. Я не коммичу код до тех пор, пока оно не заработает и станут понятны все изменения. Только потом я стэйджу индивидуальные изменения и разбиваю их на логические коммиты.
Насчет ченджлогов: кто ж их писать будет?! Во-первых, пожалейте этого бедного человека: ему придется разгребать тонны бесполезных коммиты сообщений. Во-вторых, зачем вести отдельный лог, когда можно просто структурировать свои коммиты правильно?! Или, например, есть подозрения, что в каком-то файле ошибка и надо посмотреть кто и зачем менял конкретную строчку. Если у Вас коммиты не «поменял вот эту строчку», а «добавил вот такую фичу», проще найти концы.
Лично я работаю так: нужно добавить нужную фичу. Надо порефакторить/поре-инжиннерить код, поправить сломавшиеся тесты, потом только добавлять новый функционал. Я не коммичу код до тех пор, пока оно не заработает и станут понятны все изменения. Только потом я стэйджу индивидуальные изменения и разбиваю их на логические коммиты.
Насчет ченджлогов: кто ж их писать будет?! Во-первых, пожалейте этого бедного человека: ему придется разгребать тонны бесполезных коммиты сообщений. Во-вторых, зачем вести отдельный лог, когда можно просто структурировать свои коммиты правильно?! Или, например, есть подозрения, что в каком-то файле ошибка и надо посмотреть кто и зачем менял конкретную строчку. Если у Вас коммиты не «поменял вот эту строчку», а «добавил вот такую фичу», проще найти концы.
есть хорошая практика в больших open-source и не только проектах — пулл риквест создаётся 1 на конкретную фичу, и в пулл риквесте только 1 коммит, реализующий эту фичу
А что делать если для реализации фичи нужно несколько тысяч строк кода написать? Разбивать на отдельные «фичи»? Разумно, да — но тогда та же проблема всплывёт на следующем уровне: возникнет вопрос — что такое «фича».
Что касается атомарности — тут всё просто: не нужно коммитить проект в «разобранном» состоянии. Любая версия должна собираться и, в идеале, проходить все тесты. В идеале — потому что может оказаться что есть какие-нибудь стресс-тесты, которые сутки ходят — их можно исключить, чтобы не тормозить разработку.
Исправлять форматирование по одной строке — бред, но если вы реально над каждой из них думали отдельно и аккуратно там пробельчики размещали — почему нет? Как верно заметили: с git'а не убудет…
Что касается атомарности — тут всё просто: не нужно коммитить проект в «разобранном» состоянии. Любая версия должна собираться и, в идеале, проходить все тесты. В идеале — потому что может оказаться что есть какие-нибудь стресс-тесты, которые сутки ходят — их можно исключить, чтобы не тормозить разработку.
Исправлять форматирование по одной строке — бред, но если вы реально над каждой из них думали отдельно и аккуратно там пробельчики размещали — почему нет? Как верно заметили: с git'а не убудет…
Насчет «коммитить в разобранном состоянии»: да, надо коммитить так, чтобы проект собирался и все тесты проходили. Никак не отменяет всего вышесказанного.
Насчет «если вы реально над каждой из них думали отдельно и аккуратно там пробельчики размещали — почему нет?», потому что нет. А еще забавно смотреть, когда у людей в пулреквесте видна вся борьба: коммиты «ой, у меня тут опечатка», «пофиксил тест, который сломал предыдущим коммитом», «пофиксил форматирование моего нового кода». Вот в истории совершенно необязательно видеть какой Вы растяпа.
Насчет «если вы реально над каждой из них думали отдельно и аккуратно там пробельчики размещали — почему нет?», потому что нет. А еще забавно смотреть, когда у людей в пулреквесте видна вся борьба: коммиты «ой, у меня тут опечатка», «пофиксил тест, который сломал предыдущим коммитом», «пофиксил форматирование моего нового кода». Вот в истории совершенно необязательно видеть какой Вы растяпа.
Ну а что же поделать, если такова история? Переписывать историю вообще не очень круто, как по мне.Это, собственно, принципиальное отличие между Git'ом и Mercurial'ом.
Философия Mercurial'а — как у вас: история штука ценная, переписывать её никак нельзя.
Философия Git'а — практически полная противоположность: история штука ценная — потому нельзя её пускать на самотёк, её должны писать летописцы.
Поэтому я не делаю ребейзы.Ну в своём проекте — это допустимо. А вообще — rebase штука полезная. Линус про это как-то писал: в своём репозитории rebase делать можно и нужно (никому не интересно поверх какой версии вы начали разрабатывать свои правки). Но когда вы их привели к состоянию, когда их «не стыдно показать» (написали хорошую историю), после этого, да, rebase делать не стоит…
Тем более, что непонятно, что я теряю от мержей вместо ребейзов кроме самого факта линейности истории, что мне представляется не настолько уж важной самоцелью.Вы — не теряете. Теряют другие. Вместо того, чтобы рассматривать вашу правку как что-то атомарное (и либо откатить её всю, либо оставить) они вынуждены разбирнаться в том, как вы чихали и чистили зубы.
Когда у вас будет 200 правок в день (в среднем — в какие-то дни побольше, в какие-то поменьше) вы сами захотите отказаться от того, чтобы смотреть на чужую историю. А я своя — вот она, в своей ветке git'а, её убивать никто не просит.
Ленивый я, не люблю терять информацию слишком рано :)Никто не просит «терять информацию». Просят её убрать «с глаз долой». Ещё раз: никому не инетересно как вы там шатались из стороны в сторону при разработке ваших изменений. Хотите чтобы на них было приятно смотреть другим людям — причешите историю! Если совсем лениво — «схлопните» её, но не заставляйте других читать то, что им совсем не нужно! Они ведь — тоже ленивые!
Я такое видел только в проектах, которые используют Gerrit (привет, OpenStack!). Я считаю, это глупость и ограничения этой review тулзы. Но и коммитить по одной строчке — перебор. Надо искать баланс
Оправдание лишней работы? Чендждлоги надо писать руками, но можно это делать копаясь в списке изменений в раз в 5 короче. Хорошо, что Вы можете разобраться в большом кол-ве своих коммитов. Но если Вы работаете в команде и все коммитят в Вашем стиле, я уверен, Вам придется не только читать коммиты, но и разбираться куда и зачем они (а если еще кто-то не утруждает себя написанием внятных комментариев к коммиту, то это вообще тушите свет).
Проблема в том, что разобраться в каком-нибудь изменении без контекста — та ещё проблема. А вникать в контекст всех их мелких изменений в большом проекте — жизни не хватит.
Так а зачем мне вникать в их изменения?Потому что они у вас в истории. И на одном из них что-то развалилось.
А если мы вместе работали над одним либо совместными модулями, то и вникать не надо, всё и так ясно.Это пока у вас кода немного «всё и так ясно». Будет у вас в проекте несколько миллионов строк и тысячи коммиттеров — совсем другие песни пойдут, поверьте.
Понимаю что мало вероятно хабр меня поддержит, однако не могу промолчать.
По моему не большому опыту, Open Source съедает большую долю времени, и ничего не приносит взамен кроме этого самого опыта, м.б. еще туманной формулировки «Вас заметят», крайне редко, можно получить $2 от такого же человека.
Он хорош как начало, чтобы было что показать работодателю/заказчику. Однако откинув романтику, и прочее «Миру-мир», кушать хочется сейчас, а не когда-то там возможно. Опыт можно и нужно получать с денежной мотивацией, пусть маленькой. А уж, когда есть свободное время, можно заняться «Хобби», т.е. безвозмездно. Тут тоже не все однозначно, когда человек начинает работать, время всегда нет, а если есть семья, и подавно.
Сам активно пользуюсь плодами, не без этого конечно. Немного участвую в одном из проектов. Самый большой минус этого занятия (за себя говорю) — наплевательское отношение к поддержке продукта. Можно сделать вроде бы неплохую вещь, и мгновенно перегореть.
По моему не большому опыту, Open Source съедает большую долю времени, и ничего не приносит взамен кроме этого самого опыта, м.б. еще туманной формулировки «Вас заметят», крайне редко, можно получить $2 от такого же человека.
Он хорош как начало, чтобы было что показать работодателю/заказчику. Однако откинув романтику, и прочее «Миру-мир», кушать хочется сейчас, а не когда-то там возможно. Опыт можно и нужно получать с денежной мотивацией, пусть маленькой. А уж, когда есть свободное время, можно заняться «Хобби», т.е. безвозмездно. Тут тоже не все однозначно, когда человек начинает работать, время всегда нет, а если есть семья, и подавно.
Сам активно пользуюсь плодами, не без этого конечно. Немного участвую в одном из проектов. Самый большой минус этого занятия (за себя говорю) — наплевательское отношение к поддержке продукта. Можно сделать вроде бы неплохую вещь, и мгновенно перегореть.
лично для меня участие в open-source — это профессиональное развитие, которое поможет мне вместо сегодняшних X получать завтра X + 10% и кушать больше)
Но в общем и целом доля правды в Ваших словах есть
Но в общем и целом доля правды в Ваших словах есть
Я например опенсорц выделяю из своих личных домашних проектов.
Если я вдруг сделал какую-нибудь универсальную утилиту (или библиотеку), которая у меня
используется в нескольких проектах — то я просто немного оформляю README файл и выкладываю на гитхаб.
И вполне находятся люди которые ими пользуются. И если кто присылает баги — то я их чиню и для своих проектов которые используют данную библиотеку.
Если я вдруг сделал какую-нибудь универсальную утилиту (или библиотеку), которая у меня
используется в нескольких проектах — то я просто немного оформляю README файл и выкладываю на гитхаб.
И вполне находятся люди которые ими пользуются. И если кто присылает баги — то я их чиню и для своих проектов которые используют данную библиотеку.
Согласен на 100% насчёт поддержки. Единственным моим проектом, который хоть как-то взлетел и которым люди пытаются пользоваться, мне уже давно неинтересно заниматься, а интересно другими.
Скажите это Тейлору Отвелу, создателю фреймворка Laravel :)
А по хорошему, надеяться на донат в OpenSource не стоит, обычно люди занимаются им не только для этого
А по хорошему, надеяться на донат в OpenSource не стоит, обычно люди занимаются им не только для этого
Попытка заработать напрямую на Open Source проекте — глупость несусветная. То есть если у вас в компании используется какой-нибудь GCC или Clang, то да, компания может оплатить одного-двух разработчиков инструмента. На 100 тех, кто его использует, да. Но — это редкость. А другого способа заработать на Open Source, почитай что и нету.
Воспринимайте лучше Open Source как «курсы повышения квалификации». Вы же не получаете денег, изучая какой-нибудь инструмент — обычно наоборот, за курсы ещё и платить нужно! Чтобы сделать небольшую доработку в какой-нибудь Python или Django вам потребуется столько же времени и сил как и на то, чтобы пройти соотвествующие двух-трёхнедельные курсы, а пользы — будет несравненно больше.
Воспринимайте лучше Open Source как «курсы повышения квалификации». Вы же не получаете денег, изучая какой-нибудь инструмент — обычно наоборот, за курсы ещё и платить нужно! Чтобы сделать небольшую доработку в какой-нибудь Python или Django вам потребуется столько же времени и сил как и на то, чтобы пройти соотвествующие двух-трёхнедельные курсы, а пользы — будет несравненно больше.
С точки зрения индивидуального разработчика, опенсоус бывает двух типов — участие в разработке больших проектов и запиливание вещей от своего имени.
В первом случае можно конечно делать крутые штуки, писать шикарный код и все такое, но велики шансы остаться полностью незаметным «хорошим парнем».
Во 2 случае можно в свое удовольствие пилить пет-проджекты на гитхабе или демки на codepen, и в случае их успеха ваша жизнь заметно улучшится. Я вот своему карьерному росту полностью обязан запиливанию демок на codepen, причем рост этот очень даже серьезный, в стандартных офисах будучи «прилежным работягой» о таком можно забыть.
В первом случае можно конечно делать крутые штуки, писать шикарный код и все такое, но велики шансы остаться полностью незаметным «хорошим парнем».
Во 2 случае можно в свое удовольствие пилить пет-проджекты на гитхабе или демки на codepen, и в случае их успеха ваша жизнь заметно улучшится. Я вот своему карьерному росту полностью обязан запиливанию демок на codepen, причем рост этот очень даже серьезный, в стандартных офисах будучи «прилежным работягой» о таком можно забыть.
Часто бывает желание присоединиться к какому-нибудь проекту (как раз по верно описанным автором причинам), но элементарно не знаю к какому. В крупные типа Postgres далекому человеку войти сложно да и желающих, наверное, много, а о начинающих и небольших банально не от кого узнать, если в проекте нет твоих знакомых. Все таки это еще та социальная сеть.
крупные типа Postgres далекому человеку войти сложно да и желающих, наверное, много
ну почему же сложно, если Вы более-менее хорошо знакомы с языком, на котором написан проект, и самим проектом, то всё вполне легко.
Например, тот же Django для новичков предлагает так называемые «easy picking» тикеты — простые тикеты, которые легко решаются и помогают начать контрибьютить в Django.
просто выбирайте проект, который Вам нравится, и дерзайте, попытка не пытка как говорится :)
А вы попробуйте те проекты, без которых вы и дня не проживете) Или те, с которыми приходится работать чаще всего.
Для меня таким проектом стал OpenWrt.
Для меня таким проектом стал OpenWrt.
Господа, ответьте честно — правда, что среди разработчиков есть такие люди, которые выходные дни проводят за написанием кода и считают это отдыхом и развлечением? Т.е. для таких людей хобби совпадает с основной профессией. И правда, что такие разработчики и есть профессионалы высочайшего уровня, до которого обычным смертным никогда не дорасти (если также не задротить)?
выходные в основном провожу отдыхая и занимаясь всякими разными несвязанными с программированием делами.
но вот вечерок-другой могу потратить на свой проект, изучения нового языка, контрибьютинг.
и да, это даёт какую-то отдушину.
недавно, если не ошибаюсь на Хабре, была статья, в которой была фраза (дословно не помню) — «Чем программист отличается от любого другого работника? Он в рабочее время пишет код и в свободное… он тоже пишет код»
но вот вечерок-другой могу потратить на свой проект, изучения нового языка, контрибьютинг.
и да, это даёт какую-то отдушину.
недавно, если не ошибаюсь на Хабре, была статья, в которой была фраза (дословно не помню) — «Чем программист отличается от любого другого работника? Он в рабочее время пишет код и в свободное… он тоже пишет код»
Ну вот только не надо создавать иллюзий. Слесарь тоже «на работе слесарит и дома слесарит»… Хороший слесарь. Т.е. по факту выруливаем к сентенции «профессионал бытовые проблемы (решаемые его областью деятельности) решает сам». И бывает от этого доволен. У хорошего мебельщика дома мебель тоже будет отличная.
И правда, что такие разработчики и есть профессионалы высочайшего уровня, до которого обычным смертным никогда не дорасти (если также не задротить)?
на мой взгляд, это не так.
профессионализм не зависит от этого.
если вам нравится то, что вы делаете и вы постоянно развиваетесь (читаете, учите и т.д.) — вы и есть профессионал
Да, есть, для меня хобби стало работой, насчет уровня ничего сказать немогу, но
Но вот с автором статьи не очень-то и согласен, возможно эпизодическое участие в сторонних проекта может и фан, но в какой-то момент open source начинает требовать слишком много внимания не давая ничего в замен, ни опыта, ни развлечения.
Идеальный вариант выделять open source в рамках задач компании, вот тогда хорошо.
эта картинка никогда не была шуткой
Но вот с автором статьи не очень-то и согласен, возможно эпизодическое участие в сторонних проекта может и фан, но в какой-то момент open source начинает требовать слишком много внимания не давая ничего в замен, ни опыта, ни развлечения.
Идеальный вариант выделять open source в рамках задач компании, вот тогда хорошо.
Идеальный вариант выделять open source в рамках задач компании, вот тогда хорошо.
собственно, это и написано в заключении :)
Идеальный вариант выделять open source в рамках задач компании, вот тогда хорошо.
Вопрос в том, как уговорить начальство выделить код в OpenSource. Какая мотивация у лида\архитектора\менеджера?
я бы из пунктов, которые их могут мотивировать выделили бы
- Повышение квалификации сотрудников
- Повышение мотивированности сотрудников, повышение их заинтересованности
- Прямое доказательство компетентности сотрудников для потенциальных заказчиков (мол смотрите, наши разработчики вон в каких проектах участвуют)
«Если взлетит, то наш код протестируют сотни доброльцев. Если нет — ничего не потеряем».
ИМХО, тут, скорее, важна политика компании к open source'у как таковому. Например, если компания делает деньги на open source продуктах, то скорее всего, upstream'ить разрешат. Плюс это здорово развивает разработчиков — прививает аккуратность в выборе софтверных лицензий и прочего.
ИМХО, тут, скорее, важна политика компании к open source'у как таковому. Например, если компания делает деньги на open source продуктах, то скорее всего, upstream'ить разрешат. Плюс это здорово развивает разработчиков — прививает аккуратность в выборе софтверных лицензий и прочего.
Прежде всего надо разобраться, почему вы решили, что нужно разрабатывать с нуля? Почему не выбрано одно из существующий решений (всегда что-то существует)?
Ну, а дальше:
— Писать общее решение, а не решать узкую задачу (т.е. писать в отрыве от проекта)
— Писать тесты и документацию.
— Продвигать
— Поддерживать 7/24.
И вот тогда можно начинать думать о open source, тогда он выполнит свою функцию, раскроет узкие места/баги вашего решения, покажет неожиданные векторы развития и применения.
Ну, а дальше:
— Писать общее решение, а не решать узкую задачу (т.е. писать в отрыве от проекта)
— Писать тесты и документацию.
— Продвигать
— Поддерживать 7/24.
И вот тогда можно начинать думать о open source, тогда он выполнит свою функцию, раскроет узкие места/баги вашего решения, покажет неожиданные векторы развития и применения.
Вопрос в том, как уговорить начальство выделить код в OpenSource. Какая мотивация у лида\архитектора\менеджера?Экономия денег, однако. Ничего другое бизнесу не интересно.
Вопрос, который нужно задать себе, очень прост: вот эта вот шняга, которую мы тут делаем — это наше «Ноу-Хау», которое мы продаём или вспомогательная служба, которую мы можем отдать на откуп фрилансерам? А если это — не что-то, что мы продаём, то, может быть, дешевле вот этот вот «что-то» разрабатывать совместно с конкурентами?
Оказывается что ответ на оба вопроса положителей гораздо чаще, чем кажется на первый взгляд. Каждый раз, когда заходит вопрос о том, чтобы отправить задачу что-то на «аутсорс» стоит одновременно посмотреть — а нельзя ли «вот это вот» превратить в Open Source?
P.S. Если ваша компания отдаёт «на аутсорс» то, на чём она зарабатывает деньги, то у меня для вас плохие новости…
А какие есть недостатки у OpenSource для компании? И как их обходить.
Я пока вижу затраты времени, и шанс того, что развитие либы пойдет «не туда». Да и внесение изменений может замедлиться.
P.S. Моя компания занимается тем, что сдает за процент сотрудников-аутсорсеров. И мой текущий клиент вполне себе доволен: я работаю с кодом, а он это дело контролирует (сам программер, так что реально контролирует).
Я пока вижу затраты времени, и шанс того, что развитие либы пойдет «не туда». Да и внесение изменений может замедлиться.
P.S. Моя компания занимается тем, что сдает за процент сотрудников-аутсорсеров. И мой текущий клиент вполне себе доволен: я работаю с кодом, а он это дело контролирует (сам программер, так что реально контролирует).
А какие есть недостатки у OpenSource для компании? И как их обходить.Собственно тот факт, что соответствующий код будет доступен «без оплаты» конкурентам. Если это что-то, что позволяет вам делать ваш продукт лучше/дешевле, чем у конкурентов то ответ как бы самоочевиден, нэ?
Я пока вижу затраты времени, и шанс того, что развитие либы пойдет «не туда». Да и внесение изменений может замедлиться.А тут как бы «кто первый встал — того и тапки». Если вы превратили свой проект в Open-Source то вы и решаете — куда он идёт. Конечно если проект становится реально большим, то это становится делать сложнее — но до этого ещё дорасти нужно.
А вот если аналогичный проект уже кто-то запилил и «набрал критическую массу», то у вас как раз будут проблемы — либо вы будете должны сделать что-то, что резко лучше уже существующего (как пример — ninja), либо вам придётся отказаться от своего проекта и начать использовать то же, что используют другие (скажем JSON вместо PB).
P.S. Моя компания занимается тем, что сдает за процент сотрудников-аутсорсеров.Вот для вас — как раз ситуация сложнее, но принцип тот же: вещи, которые вы используете как базу для того, чтобы продавать ваши услуги заказчикам — нельзя пускать в Open Source, какие-то вспомогательные вещи, которые вашим сотрудникам нужны, но за которые непосредственно заказчик не платит — можно и нужно. Но тут уже надо быть аккуратнее: вполне может оказаться что-то какая-нибудь не слишком сложная библиотечка, вокруг которой вы всё и строите — и есть, на самом деле, ваше «ноу-хау», из-за которого к вам клиенты обращаются. Так что вам — сложнее.
На первый вопрос — да.
Я пишу код 5 дней в неделю и вполне могу потратить 1 или 2 выходных на код же.
Ничем серьезным правда не занимаюсь, но в этом и соль, никакой обязаловки, пиши что нравится.
Я пишу код 5 дней в неделю и вполне могу потратить 1 или 2 выходных на код же.
Ничем серьезным правда не занимаюсь, но в этом и соль, никакой обязаловки, пиши что нравится.
Один из способов сменить вид деятельности. Основная работа, бывает, надоедает до чертиков — вот, одно из направлений (полезных!) сменить активность. Как спорт, только развивает другие группы мыщц :)
Иногда мне хочется в свободное время поиграть в компьютерную игру, иногда — посмотреть сериал, иногда — сесть и допилить что-то в одном из своих проектов. Это всё происходит волнами, но в среднем за год получается примерно 40% игры / 40 % кодинг / 20% сериалы — просто мало хороших сериалов :) Другие виды времяпрепровождения в нерабочее время у меня отнимают несоизмеримо меньше времени.
Естественно, во время кодинга я слушаю музыку, а также нередко отвлекаюсь на интернет/ютуб и т. д., т. е. это не 100% работа в IDE.
Естественно, во время кодинга я слушаю музыку, а также нередко отвлекаюсь на интернет/ютуб и т. д., т. е. это не 100% работа в IDE.
Да, дома пишу свои хобби-проекты. Неторопясь. Один из них был начат в 2006 году, до сих пор развивается.
Контрибьютил в closed-source проект (Oracle Coherence) баг репорт с описанием фикса, патч не присылал, ибо по лицензии нельзя декомпилить код, поэтому написал пару юнит-тестов, которые указывали чуть ли не на строчку в исходниках, которую надо пофиксить.
> Это весело
Есть мнение, что слово «fun» нельзя просто так взять и перевести на русский как «весело».
Честно положа руку на орган — такой перевод — признак пофигизма.
Постарайтесь понять смысл и передать его вместо дословного, но идиотического «весело».
Прямо бесит уже.
Есть мнение, что слово «fun» нельзя просто так взять и перевести на русский как «весело».
Честно положа руку на орган — такой перевод — признак пофигизма.
Постарайтесь понять смысл и передать его вместо дословного, но идиотического «весело».
Прямо бесит уже.
Куча людей пишут, что они покупают кофе следующему в очереди просто из доброты. Я регулярно покупаю кофе. Мне ни разу из впереди стоящих не купил кофе. :looks suspicious:
У меня нет идеи фикс — срочно кому-нибудь что-нибудь законтрибьютить. Я давно и успешно трудоустроен и я предпочитаю выкладываться на работе. Иногда, конечно, работа надоедает и хочется отдушины — сделать что-нибудь полезное.
Но я хочу предостеречь людей, неопытных в опенсоурсе: это не всегда те розовые сопли, о которых так любят тут рассказывать. Да, вы будете знакомиться с новыми людьми. Но, не радуйтесь: не все люди таки интересные, чтобы с ними знакомиться. А иногда придется. И в ваших пул-реквестах будут появляться люди, которые с пеной у рта будут доказывать Вам какую-нибудь чушь. Или требовать, чтобы Вы в своем пул-реквесте починили какой-нибудь не относящийся в теме Вашего пул-реквеста баг, добавили какую-нибудь абсурдную фичу или что-нибудь типа того. И они будут ставить Вам "-1" только потому, что могут.
Потом Вам придется ждать, возможно, месяцами, когда у правильных людей дойдут руки, чтобы посмотреть Ваш пул-реквест, выдать Вам парочку указаний на переделку и опять пропасть на месяцок-другой. Все это время Ваш код будет обрастать конфликтами (потому что кто-то другой дождался-таки мержа его PR), Вы будете периодически заниматься обновлением Вашего PR.
Я не занимаюсь правкой опечаток или дописанием документации. Чаще всего, я или нахожу баг в библиотеке, которую сам использую, или хочу добавить в нее новый функционал. С багами проще, а вот с функционалом. Запасайтесь нервами, они Вам понадобятся.
Но я хочу предостеречь людей, неопытных в опенсоурсе: это не всегда те розовые сопли, о которых так любят тут рассказывать. Да, вы будете знакомиться с новыми людьми. Но, не радуйтесь: не все люди таки интересные, чтобы с ними знакомиться. А иногда придется. И в ваших пул-реквестах будут появляться люди, которые с пеной у рта будут доказывать Вам какую-нибудь чушь. Или требовать, чтобы Вы в своем пул-реквесте починили какой-нибудь не относящийся в теме Вашего пул-реквеста баг, добавили какую-нибудь абсурдную фичу или что-нибудь типа того. И они будут ставить Вам "-1" только потому, что могут.
Потом Вам придется ждать, возможно, месяцами, когда у правильных людей дойдут руки, чтобы посмотреть Ваш пул-реквест, выдать Вам парочку указаний на переделку и опять пропасть на месяцок-другой. Все это время Ваш код будет обрастать конфликтами (потому что кто-то другой дождался-таки мержа его PR), Вы будете периодически заниматься обновлением Вашего PR.
Я не занимаюсь правкой опечаток или дописанием документации. Чаще всего, я или нахожу баг в библиотеке, которую сам использую, или хочу добавить в нее новый функционал. С багами проще, а вот с функционалом. Запасайтесь нервами, они Вам понадобятся.
в общем и целом такое бывает конечно.
но опен-сорс — это свобода. если Вас что-то не устраивает можно перейти на другой проект.
слава богу, мне всегда попадались адекватные люди, которые делали замечания по делу, с которыми было приятно общаться
но опен-сорс — это свобода. если Вас что-то не устраивает можно перейти на другой проект.
слава богу, мне всегда попадались адекватные люди, которые делали замечания по делу, с которыми было приятно общаться
Справедливости ради отмечу, что работа «на дядю» — тоже свобода. Если Вас что-то не устраивает, можно перейти к другому дяде.
Опенсурс — это свобода, когда Вы, ковыряясь в носу, не знаете чем себя занять. А когда Вы используете опенсурс компоненты и пытаетесь их улучшить (не только для себя, но и для других; и не хотите поддерживать Ваши приватные патчи и заниматься обновлением их с каждым новым релизом библиотеки), то внезапно нет у Вас никакой свободы: иногда нельзя просто так взять и переписать весь Ваш проект на другую похожую библиотеку, одновременно дописав в нее все то, что отсутствует во второй по сравнению с первой библиотекой (ведь Вы выбрали первую из-за ее фич, которых нет у других). Лучший выход — это держать свой приватный форк и одновременно пушить изменения в upstream. Это месяцы времени и уйма нервов. Вот я о чем.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему участие в Open Source проектах это интересно и полезно