Отличная статья про участие в разработке OpenSource проекта.
У многих совершенно неверное представление о сообществе OpenSource и участии в разработке крупных проектов. Удивительно, как вышло, что OpenSource community без всякого PR (public relations) умудрились создать себе репутацию, которая рядом не лежала с реальностью. Для многих OpenSource — нечто белое и пушистое. На словах: "участвуйте в разработке открытых проектов, мы вам поможем, расскажем, покажем, направим, присылайте Push Request'ы, мы их отрецензируем и примем"...
Ага, щас. На деле в OpenSource ты нафиг никому не нужен. Почти везде тебе никто ничего не будет рассказывать (даже если спросишь) — разбирайся сам (9 из 10 разработчиков ответят, что у них нет времени или вообще не ответят). Твой PR никому не нужен, вместо рецензии на него ты легко можешь получить кучу пурги, не имеющей к нему никакого отношения (чувак тупо не разобрался, что делает твой PR, но к чему-то придрался, потому что PR расходится с его представлениями о прекрасном), когда ты поправишь PR кто-то другой докопается еще до чего-то (или предложит все вернуть обратно). Совсем забавно, когда эти двое начнут рассказывать, что PR в принципе можно принять, но все это они делают, чтобы "сэкономить твое время" (причем, на территории СНГ лицемерие еще только развивается, а на западе оно давно на грани полнейшей шизы, когда говорят одно, а делают ровно противоположное и это противоречие очевидно). Также, есть куча умников, которые воспринимают тезис "в OpenSource тебе никто ничего не должен" таким образом, что с тобой даже разговаривать по человечески не обязаны и могут просто послать на... потому что их подход "я в проекте царь и бох, поэтому творю, что хочу" (в коммерческой разработке против этого есть тормоза — тут бывает полный беспредел). В результате, чтобы добавить свой код в OpenSource проект (далеко не с первой попытки) придется потратить довольно много усилий и большую часть не на разработку.
Разумеется, все проекты разные и правила в них разные, но обычно проще поддерживать свой форк, чем пытаться передать код в OpenSource проект (и чем крупнее проект, тем больше бюрократии). При этом у крупного бизнеса с этим никаких сложностей. У них либо ведущие разработчики на зарплате, либо они найдут к ним подход и могут, даже, добавить в проект не работающий код (а в это время твой PR в соседней ветке будут "критиковать" по любому поводу, а повод всегда найдется).
В общем, мой посыл:
OpenSource далеко не такой белый и пушистый, как многим кажется, и нужно воспринимать его более реалистично.
Участие в разработке OpenSource проектов полезно, как для повышения технических навыков, так и для мировоззрения (в смысле более реалистично начинаешь смотреть на вещи, различаешь слова и реальность).
как то подавался на одну вакансию родом из мск, а попой в сфба
у них продукт опенсорс
собеседование из двух слов
ну вот у нас на гитхабе полно открытых тикетов по продукту
вы с годик поопенсорсте наш продукт на дурняк(денег платить не будем)
а через годик мы вас может быть на полную ставку в компанию возьмем
Здравствуйте, Reset, Вы писали:
R>При этом у крупного бизнеса с этим никаких сложностей. У них либо ведущие разработчики на зарплате, либо они найдут к ним подход и могут, даже, добавить в проект не работающий код (а в это время твой PR в соседней ветке будут "критиковать" по любому поводу, а повод всегда найдется).
Главная и основная цель существования Open Source — это уничтожение малого бизнеса в айти (кто помнит watcom c compiler?), защита крупного бизнеса от опасности, что мелкий их потеснит, уничтожение самого рынка для малого бизнеса и снижение затрат для крупного бизнеса — так бы они были вынуждены поддерживать свои собственные компиляторы, платить специалистам по компиляторам, а не индусам за фронтенд, а сейчас у них есть общий gcc и специалистов нужно меньше.
Здравствуйте, Reset, Вы писали:
R>Отличная статья про участие в разработке OpenSource проекта.
И исходная статья, и этот топик однобоко рассматривают open source с точки зрения стороннего контрибьютора — но не со стороны мейнтейнера.
На последнюю тему могу предложить доклад Адама Ситника (там ближе к концу раздел «The bad part of being the maintainer»).
Opensource, как и всё что долго живёт, прошло и проходит несколько существенно разных этапов.
Первый — когда ранний FSF Столлмана делал gcc и комплекты юзерских утилит, он просто реализовывал открыто то, что реально стоило уже ничего, но никто пока не решился сделать открытую версию — но вместо этого фирмы, полные некомпетентных разработчиков, продавали дерьмовые продукты за тонны нефти. Один gcc убил десятки коммерческих компиляторов — просто потому, что они стали тупо бессмысленны, и выживали те, что реально начали превосходить по качеству.
Но бо́льшая часть продуктов спокойно могла быть сделана одним человеком без напряга, часто в свободное время, и делалась (примеров масса — gcc ранний, groff, почти весь софт Internet вроде почтовиков...) Для передовых продуктов это 80-е и часть 90-х.
(Реально можно ещё считать нулевой — когда не оформилась схема продажи софта, потому что он был неотъемлем от железа — но это было ad-hoc и без идеологии. Поэтому его пропустим.)
Второй — это когда поднялась сложность и началась потребность работать командами и вкладывать существенные деньги в развитие, для анализа подходов, сбора требований, оптимизации и повышения производительности. Примеры — Linux, FreeBSD, apache, nginx. Для флагманских продуктов это 90-е и 2000-е. Уже в начале этого пути собралась полноценная экосистема, которая спокойно бы выжила и была способна обслужить потребителей всех видов, если бы весь прочий софт мистически исчез — как минимум на 1995 это было бы тяжёлый вой, на 2000 просто вой, но ничего фатального для прогресса не случилось бы.
Третий — наблюдаем сейчас — когда у флагманских продуктов настолько высокая сложность, что требуются уже серьёзные усилия на организацию проектов и затраты на развитие. Как правило, играют бизнес-модели разного типа — кто-то на коммерческой поддержке, кто-то на параллельной более богатой версии, кто-то на требовании обратного вклада от кастомизаторов, которые зарабатывают на своих услугах; часто это комбинируется.
Проблемы, описанные вами, происходят из нескольких факторов:
1. Ниш, где бы подошёл подход первого этапа, уже нет (как обычно, любое обобщение считать правильным на 95-99%, включая это). Новые ниши могут быть открыты только коллективами. Старые все покрыты как проприетарщиной, так и opensource. Прорывы-исключения редки.
2. Человеческие коллективы страдают от общеизвестных человеческих проблем, но в отсутствие работающей регуляции усиливаются — а если у продукта координация страдает, то это становится очень хорошо видимым.
R>Ага, щас. На деле в OpenSource ты нафиг никому не нужен. Почти везде тебе никто ничего не будет рассказывать (даже если спросишь) — разбирайся сам (9 из 10 разработчиков ответят, что у них нет времени или вообще не ответят). Твой PR никому не нужен, вместо рецензии на него ты легко можешь получить кучу пурги, не имеющей к нему никакого отношения (чувак тупо не разобрался, что делает твой PR, но к чему-то придрался, потому что PR расходится с его представлениями о прекрасном), когда ты поправишь PR кто-то другой докопается еще до чего-то (или предложит все вернуть обратно). Совсем забавно, когда эти двое начнут рассказывать, что PR в принципе можно принять, но все это они делают, чтобы "сэкономить твое время" (причем, на территории СНГ лицемерие еще только развивается, а на западе оно давно на грани полнейшей шизы, когда говорят одно, а делают ровно противоположное и это противоречие очевидно). Также, есть куча умников, которые воспринимают тезис "в OpenSource тебе никто ничего не должен" таким образом, что с тобой даже разговаривать по человечески не обязаны и могут просто послать на... потому что их подход "я в проекте царь и бох, поэтому творю, что хочу" (в коммерческой разработке против этого есть тормоза — тут бывает полный беспредел). В результате, чтобы добавить свой код в OpenSource проект (далеко не с первой попытки) придется потратить довольно много усилий и большую часть не на разработку.
Про "в коммерческой разработке против этого есть тормоза" — рассказывайте тем, кто поверит в эти сказки. Многолетнее наплевательство на жалобы клиентов потому, что не смогли убедить пня в руководстве, или до верха просто не дошли плачи — это норма. Только в случае opensource вы можете хотя бы форкнуть. А с проприетарщиной и этой возможности нет.
Проблема в общем, конечно, есть — на того, кто работает не за деньги, а за собственный интерес, надо влиять не деньгами, а этически и морально — а интересы, этика и мораль у всех разные, в отличие от денег, которые универсальны. Но, повторюсь, открытость кода спасает. Случаи, когда тот, кому отказали в осмысленном пожелании, делал форк и перетягивал основную прежнюю команду — уже исчисляются десятками и сотнями.
R>Разумеется, все проекты разные и правила в них разные, но обычно проще поддерживать свой форк, чем пытаться передать код в OpenSource проект (и чем крупнее проект, тем больше бюрократии).
Бюрократия необходима для защиты от юридического хакерства захватчиков, а не сама по себе.
R> При этом у крупного бизнеса с этим никаких сложностей. У них либо ведущие разработчики на зарплате, либо они найдут к ним подход и могут, даже, добавить в проект не работающий код (а в это время твой PR в соседней ветке будут "критиковать" по любому поводу, а повод всегда найдется).
Агащазз. Если твоё предложение идёт вразрез с общим подходом — будет то же самое.
R>* OpenSource далеко не такой белый и пушистый, как многим кажется, и нужно воспринимать его более реалистично.
Реалистично надо воспринимать всегда. Но подход идёт миру в целом на пользу.
R> Участие в разработке OpenSource проектов полезно, как для повышения технических навыков, так и для мировоззрения (в смысле более реалистично начинаешь смотреть на вещи, различаешь слова и реальность).
Да. Это лучше, чем цинизм, которого наберёшься при работе на крупного частного диверсанта.
Здравствуйте, Reset, Вы писали:
GIV>>Офигеть, чел научился git merge делать.
R>Скорее rebase, rebase -i, cherry-pick и много чего другого (ты же в курсе, да, что merge conflicts бывают и в rebase тоже).
R>Это у коммерсантов многие даже лиды дальше merge не продвинулись.
Это только говорит о том, что процессы в компании работают как надо. А вот если на проекте все мастера черри-пика и разрешения конфликтов то тут как раз повод задуматься.
N>Про "в коммерческой разработке против этого есть тормоза" — рассказывайте тем, кто поверит в эти сказки. Многолетнее наплевательство на жалобы клиентов потому, что не смогли убедить пня в руководстве, или до верха просто не дошли плачи — это норма. Только в случае opensource вы можете хотя бы форкнуть.
Не понимаю, как люди говорят про одни сказки, и тут же начинают рассказывать другие. Причем прямо в тексте про сложность проектов и необходимости команд для работы над ними. Много ли мало-мальски сложных опенсорсов проектов действительно хоть кем-то форкнуты (и дальше развиваются). Доли процента.
Абсолютно стандартная ситуация: опенсорс так же забивает большой и толстый болт на любые чаяния кого бы то ни было. В случае с коммерческим софтом у тебя хоть есть возможность заплатить, чтобы тебе что-то сделали (на самом деле, это тоже в большой степени сказка).
Самый наглядный пример, от которого мы страдаем (на самом деле не страдаем) уже год — Google Dataflow, который построен на Apache Beam. Официально поддерживаемая версия — Java 8, поддержка которой закончилась год тому назад. Стоит ли говорить, что Java 11, которая LTS, выпущена в сентябре 2018, а поддержка ее — до сих пор находится на Roadmap'е и пока даже близко не видно, когда она будет реализована. Я вот прям вижу, как наша компания с 80 разработчиками все бросает, форкает этот проект и следующие два года пилит поддержку Java 11. А потом, видать, пытается свой форк протолкнуть в Гугл.
N>>Про "в коммерческой разработке против этого есть тормоза" — рассказывайте тем, кто поверит в эти сказки. Многолетнее наплевательство на жалобы клиентов потому, что не смогли убедить пня в руководстве, или до верха просто не дошли плачи — это норма. Только в случае opensource вы можете хотя бы форкнуть.
M>Не понимаю, как люди говорят про одни сказки, и тут же начинают рассказывать другие. Причем прямо в тексте про сложность проектов и необходимости команд для работы над ними. Много ли мало-мальски сложных опенсорсов проектов действительно хоть кем-то форкнуты (и дальше развиваются). Доли процента.
Одно дело форкнуть и развивать другое дело форкнуть и пофиксить баг. Я так делал (тоже апачевский проект). Параллельно отправил патч, когда его залили и срелизили (через год) я удалил форк.
Этот год мы жили с форком, я туда пару раз смержил обновления (CVE всякие в основном). Для фикса CVE тоже форкал бывало и затыкал, но там майнтейнеры сами нормальный фикс вскоре выпускали без моего участия.
Здравствуйте, Reset, Вы писали:
R>Ага, щас. На деле в OpenSource ты нафиг никому не нужен.
В данном хабре речь идёт о софте, который разрабатывается консорциумом компаний. Его пишут разработчики, которым платят зарплату и у которых есть сроки и планы. Так как там участвует куча компаний, то и появилась соответствующая бюрократия.
Здравствуйте, reversecode, Вы писали:
R>у ваткома была узкая ниша прибитая гвоздями к досу, который он сильно расширял по ресурсам R>дос умер и вместе с ним ватком
Здравствуйте, sergey2b, Вы писали:
S>Здравствуйте, reversecode, Вы писали:
R>>у ваткома была узкая ниша прибитая гвоздями к досу, который он сильно расширял по ресурсам R>>дос умер и вместе с ним ватком
S>что не так было с Borland C++
С ним было все не так
Под занавес (я именно про Borland C++, а не BCB), он превратился в лютый ужоснах.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
GIV> А вот если на проекте все мастера черри-пика и разрешения конфликтов то тут как раз повод задуматься.
В случае Open Source проекта — владение cherry-pick объективная необходимость (и я это утверждаю без какого-либо негатива). Когда ты один из основных разработчиков в Open Source проекте — у тебя нет сложностей добавить туда любой код (на самом деле у тебя одна сложность — недостаток времени, ибо такие люди впахивают по 160 часов в неделю и могут делать десятки коммитов в день). А если ты обычный контрибьютор — твой PR может пролежать пару месяцев пока до него дойдут проверяющие и тут либо ты проявишь чудеса rebase -i и cherry-pick (потому что HEAD ушел далеко вперед, а PR не rebase'ится на HEAD), либо твой PR не будут даже проверять (потому что он никому не нужен). У коммерсантов такие фокусы не нужны — там по-другому устроены процессы.
R>>Ага, щас. На деле в OpenSource ты нафиг никому не нужен. C>В данном хабре речь идёт о софте, который разрабатывается консорциумом компаний. Его пишут разработчики, которым платят зарплату и у которых есть сроки и планы. Так как там участвует куча компаний, то и появилась соответствующая бюрократия.
В данном проекте одни причины для бюрократии, в другом — другие, но в результате в сколько-нибудь крупном Open Source проекте бюрократия — скорее правило, чем исключение.
P.S. Для меня бюрократия — это неоправданные сложности. Если у админов/мейнтейнеров в Open Source проектах не хватает времени и тот же login для sso тебе создают неделю или требуют что-то подписать по понятной причине — это не имеет отношения к бюрократии. А вот когда чувак с синдромом вахтера начинает придираться и требовать от тебя чего-то неразумного — вот это напрягает и после очередной итерации вызывает вопрос: "А зачем мне все это нужно, если есть способы попроще?"
Здравствуйте, Reset, Вы писали:
GIV>> А вот если на проекте все мастера черри-пика и разрешения конфликтов то тут как раз повод задуматься.
R>В случае Open Source проекта — владение cherry-pick объективная необходимость (и я это утверждаю без какого-либо негатива). Когда ты один из основных разработчиков в Open Source проекте — у тебя нет сложностей добавить туда любой код (на самом деле у тебя одна сложность — недостаток времени, ибо такие люди впахивают по 160 часов в неделю и могут делать десятки коммитов в день). А если ты обычный контрибьютор — твой PR может пролежать пару месяцев пока до него дойдут проверяющие и тут либо ты проявишь чудеса rebase -i и cherry-pick (потому что HEAD ушел далеко вперед), либо твой PR не будут даже проверять (потому что он никому не нужен). У коммерсантов такие фокусы не нужны — там по-другому устроены процессы.
Именно это я и имел ввиду. Такое и у комерсов бывает если делать по бранчу на кастомера, пилить ему уникальные фичи и еще как-то что-то из baseline тащить.
