Мы дожили до момента, когда для отправки своего коммита в популярный проект, не нужно подписывать бумажный отказ от прав на код, как это бывало в случае с GNU-проектами. Заходи на Github, ищи. Выбирай, что нравится, клонируй, создавай пул реквест, чувствуй себя гордым контрибьютором. Но если хочется не только чувствовать, но и быть, то все несколько сложнее...
Я бы условно поделил поделил вклад в развитие опенсорса на 3 группы. Для души - когда хочешь помочь проекту, который считаешь полезным, пусть и не будешь им пользоваться. Сюда относятся в основном мелкие багфиксы. Второй вид - для карьеры, это случай, когда бы вы(будучи в здравом уме и свободе действий) отобрали у фреймворка звездочку, а не поставили, но принятые коммиты в этого корпоративного монстра могут благосклонно сказаться на вашем портфолио. Третий вид вклада - для себя. Когда вы пользуетесь программой с открытым исходным кодом, накладываете одни и те же свои патчи от релиза к релизу, и начинаете подозревать, что этот функционал может пригодиться не только вам.
Для каждого случая у меня была своя мотивация, свой запас терпения и свое желание идти на уступки. И в каждом из трех случаев я сдался, хотя я пытался контрибьютить примерно в 50 разных проектов - от консольных утилит типа wget и до фреймворка QT. Теперь подробнее о том с какими типами проблем я столкнулся.
Великий индийский репозиторий
Популярные проекты притягивают карьеристов. Вклад в них давно стал способом делать карьеру при крайне сомнительной или околонулевой ценности самого вклада. Исправление опечаток - это еще самое безобидное что можно увидеть среди висящих PR. Создание хэлперов и оберток - полбеды, ведь все еще легко фильтруется.
Гораздо хуже когда вся азиатская братия начинает решать архитектурные вопросы и запиливать целые подсистемы. Допустим у нас есть php фреймворк, сам по себе неплохой, и он потихоньку обрастает всякой мишурой, которая вроде бы и нужна, но по настроению. Очередной Crawler, сборщик фронтенда(дай бог чтобы это просто была обертка вокруг нормального!).
В зависимости от настойчивости и многочисленности диаспоры в ветке обсуждения PR, такие контрибуции порой проскакивают. На их фоне твои PR просто тонут. По этой же причине чинить баги даже по заведенным Issue - это скорее работа на скорость, чем на качество.
Это никому не нужно
Можно 5 лет сатанеть от неудобного поведения программы, от не хватающего хэлпера или фасада, потом наконец решиться и написать патч, сделать PR, получить отказ, посмотреть другие отклоненные PR... И понять что ты не просто шизик, вас тут целая палата - настолько удивительные PR по добавлению функционала, что казалось бы никто в здравом уме такого делать не будет. Но они делают. И ты вместе с ними. У тебя за спиной летая по комнате ехидно хихикает МУМЬ.
Свое видение
Особенно это касается фреймворков. Те кто создает фреймворки и те, кто решает задачи с их помощью, это 2 разных категории людей со своими мышлениями. Практики и архитекторы. Или даже Архитекторы и архитекторы. А у двух архитекторов редко получается одно и то же видение архитектуры, даже для простых случаев.
Архитектурно что-то меняющие PR - последнее дело, когда больше нечего пить. Или когда просто хочется потроллить своим PR автора проекта. Принять не примут. Но может быть на том конце земного шара у кого-то полыхнет.
Фрагменты из запредельного
Иногда астронавты архитектуры улетают гораздо дальше стратосферы. Там они не погибают от недостатка воздуха, но выживают, и достигают такого уровня просветления, что их подходы и архитектура становится понятной лишь им одним. В этом случае попытки закомитить в очередной кластер метапарадигм обречены на провал. Ведь вы способны мыслить только в рамках своей парадигмы.
Это сделал я!
Особенно этим страдают азиаты. Суть в том, что ты присылаешь PR, его отклоняют, причем без объяснений. Ты вздыхаешь и начинаешь делать сборку проекта из своего форка, со всем нужными тебе своими патчами. Через некоторое время ты замечаешь куски своего же переписанного кода в проекте-родителе. Чтобы страдать от синдрома Not Invented Here, вовсе необязательно работать в крупной амбициозной корпорации.
Линия партии
Бывает что автор проекта зациклен на чем-то одном. Портировании на питон третьей версии, например. И все фичи и багфиксы не относящиеся к этой священной цели, безжалостно отклоняются. Или, например, у нас есть список Issue и работаем строго по ним. Баги - не баги, у нас есть цель. Великая и светлая.
Honeypot для мотивированных
Бывает что PR раз за разом отклоняются. Молча и в никуда. Без объяснения причин. Абсолютно все. Единственный раз когда я видел этому какое-то обоснование - автор несколько лет в свободное время перелопачивал архитектуру проекта, так что большая часть присланных патчей и правда была по итогу бесполезной.
Тяжело сказать, что в голове у автора в таком случае. Просто всегда нужно помнить, что все твои усилия могут выкинуть в мусор потому что просто потому что.
PR длинною в жизнь
Самый долгий срок, в течение которого мой PR висел забытым, это 3 года. Я даже не понял о чем речь, когда получил письмо одобрения PR. Потом я не понял зачем я это писал, но писал это очевидно я, а значит у меня были на это какие-то причины. Я даже когда-то этим пользовался. Ну да и бог с ним.
Суть заключается в том, что у автора помимо Github есть еще и жизнь, которую он не спешит разменивать на Github. И он при этом достаточно умен, чтобы зарегать Github на отдельную почту, чтобы та не отвлекала человека от его жизни. Кто-то вовсю наяривает на вечнозеленую активити, а кто-то воспринимает Github как место, куда можно заглянуть по настроению.
Так и что же в итоге?
Больше я не коммичу во фреймворки, только если это не занимает больше 20 минут, и там действительно неординарный баг. Не примут, так хотя бы заведут issue в котором пофиксят как посчитают нужным. Ведь даже при правильно оформленном фиксе, тебя могут попросить писать еще и тесты, на которые нужно будет потратить еще несколько часов. А потом все равно все обернется реджектом и строчкой в секции Caveats/Errata.
В популярные проекты, ориентированные на простых пользователей, я коммичу из расчета, что я сам буду этим пользоваться, и делаю патчи из расчета, что буду потом подтягивать изменения из апстрима и мержить. Примут - хорошо, нет - я все равно получу нужный мне функционал.
Приятней всего комитить во всякую мелочь. Если она тебе полезна и там полтора контрибьютора. Авторы благодарны, что хоть кто-то использует их проект. Тебе не нужно поддерживать форк. Все довольны. Выхлоп для карьеры нулевой. Требования к качеству кода околонулевые.
Кстати, о выхлопе для карьеры. Я думаю что сегодня порог пропуска вашего PR в топовый проект просто не стоит усилий затраченных на это. Я не про случай, когда вы пользуетесь чем-то, и вам "повезло" нарваться на баг и починить его первым. А про попытки развивать проект, делать его лучше. Опять же в общем случае, там все схвачено тусовочкой, и то что пропустят сильно зависит от того насколько вы близки к этой тусовке. Но если вы активно используете условный PostgreSQL на больших кластерах, буквально живете этим, ловите редчайший проблемы для редких ситуаций, то это другой разговор. Люди строчащие коммиты в серьезный проект по КД обычно имеют для этого подходящую работу и ресурсную базу. Или социальную базу.
Так вот о карьере. Задачки с литкода дают куда больший карьерный выхлоп. А если хотите развивать швабодный софт, то будьте готовы что плоды ваших трудов будут никому не нужны. Поэтому постарайтесь, чтобы они были нужны хотя бы вам.
Не слушайте работодателей, говорящих, что коммит в опенсорс делает вас хорошим программистом. Только программистом готовым всрать свое время в никуда при огромных рисках. Даже идейность разбивается о современные реалии контрибьюта в крупные проекты.
Комментарии (87)
ryo_oh_ki
16.10.2021 09:04+6А как думаете, к какому случаю относится этот отклонённый репорт и пулриквест:
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/10590
(суть репорта: Notepad++ принимает текст из буфера обмена без его проверки на размер, надеется, что в конце буфера всегда будет нулевой терминатор)
Сколько я не думал, так и не понял почему владелец репы так поступил. Баг же фактически есть, и если нет времени его сейчас фиксить (хотя полный отчёт, и тест, и пулреквест уже есть), то пусть бы висел в открытых... ????
monester
16.10.2021 09:33+24Ваш пул реквест был отклонен по нескольким причинам:
несоблюдение правил комьюнити по оформлению PR и Issues
неадекватное поведение в комментариях - наличие проблемы очевидно только вам, но не всем
проблема создана искуственно, т.е. в реальной жизни этот сценарий маловероятен
приложение не упало после этого, а просто вставило мусор, т.е. даже если кто-то это сделает то вреда не будет
и самая главная причина - ревьювер не смог повторить эту проблема, поэтому отказ
ryo_oh_ki
16.10.2021 09:42+10Да, наверное так и есть.
Но проблема была встречена в реальных условиях, при создании сторонней программы и практически случайном вставке текста из неё в Notepad++. По сути Notepad++ со своим багом помог найти баг о потерянном нулевом терминаторе той программы. ????
Но потом я подумал, что в современных условиях переполнение буфера, в любом виде, рано или поздно будет как-нибудь зловредно использовано и решил помочь любимому Notepad++. А раз баг уже подтверждён в коде и исправления тривиальны, то пошёл по минимальному пути.
Mingun
16.10.2021 12:51+9Там в этой дискуссии оба хороши. Автор понадеялся, что описав проблему не в соответствии с шаблоном ее тут же пофиксят (хинт — ни в коем случае так не делать. Нечего написать в шаблон — так и напишите, что не понимаете, что туда писать. Так по крайней мере не будет выглядеть, что вы умнее авторов проекта и указываете им, как делать свой проект).
Отклонивший тоже хорош — проигнорировал явно бесполезный вызов в коде (возможно, если бы автор воспользовался возможностями GitHub-а вставки перманентной ссылки на код, этого бы не случилось. Да даже просто сделать PR, а не issue. Поэтому второй совет — изучайте используемый инструмент!). Уверен, сообщи ему об этом статический анализатор, это было бы исправлено.
JayDi
17.10.2021 00:51+2Плюс код был некорректно оформлен (не соблюдено форматирование, используемое в проекте).
apapacy
16.10.2021 09:20У самого был реквест по багу https://github.com/sonata-project/SonataAdminBundle/pull/4498 который и не приняли и сами баг не фиксили хотя репортов было несколько. Мотивация конечно у меня была и тщеславие. Но нужно было и практически пофиксить баг так как в админке тупо не работали селекты. Пришлось отказаться от этого бандла. Через несколько лет кто то сделал эту самую правку.
Были и другие случаи. Предлагали дать правки в очень престижный проект просто чтобы расширить число контрибьбторов. Это такая же важная метрика как и количество звёзд или скачиваний. Отказался так как немного устал на тот момент.
MinimumLaw
16.10.2021 10:04+18Хм... Подумаешь - отклонили PR. Все, жизнь закончена, меня не ценят и,не любят... "Разбежавшись прыгнуть со скалы" (с)
Дышим глубже. Даже если от версии к версии накатывается один и тот же патч совсем не факт, что это нужно кому-то кроме тебя. И падение приложения у тебя совсем не означает что оно падает у всех. Потому главное,. что осваивает программист при работе с OpenSource это навыки командной работы. Второе - это умение понимать и исправлять чужой код. Да так, чтоб без лишних слов, да так чтоб код оставался понятным и соответствовал стилю проекта (а они разные у разных проектов). И только в последнюю очередь развитие и новые фичи.
Имейте в виду, что рассматривая ваш вклад в OpenSource рассматривают именно эти моменты. И они реально ценны. Во всяком случае для меня. Руководителя небольшой группы разработчиков внутри не самой маленькой организации. За остальных, конечно, не скажу. Может у других и иначе.
Moskus
16.10.2021 10:36Напомню еще один эффект, который менее распространен в разработке софта, но заметно чаще встречается в коллаборативных проектах другого рода. Там все чаще и чаще оказывается, что контрибьюторы и мейнтейнеры делятся на две категории:
те, кто все еще понимает задачу проекта буквально - "создать качественный набор данных, описывающий биоразнообразие в штате Мэриленд", например,
и те, кто без конкретной декларации такого смещения задачи, свято уверены в том, что проект существует только для того, чтобы "популяризировать (тут вписать область деятельности проекта), то есть на качество результата им вообще плевать.
Конечно, не всему opensource software это угрожает в принципе, но отдельные проекты, где так или иначе декларируется образовательная цель или популяризация чего-нибудь - точно под угрозой подобного. Хотя это, конечно, и не так важно, как может быть в других областях.
Izaron
16.10.2021 11:37+5У меня история open source намного менее насыщенная. Я просто при очередном желании контрибьютить куда-нибудь сталкивался с подмножеством проблем из списка:
Неуловимый Джо: В подавляющем большинстве случаев проектом пользуется полтора человека на Земле. Раз уж мы хотим тратить свое драгоценное время, не лучше ли контрибьютить в то, чем косвенно пользуются миллиарды людей?
Trust me, I'm an engineer: Отсутствие на момент старта проекта каких-то фич в языке или Генеральная Линия Партии приводит к велосипедам уровня поддержки ООП в Си. В итоге от чтения исходников кровоточат глаза.
Nothing To Do Here: Всё самое содержательное написано в первые пару лет проекта, ничего нового особо не напишешь, "всё уже украдено до нас". Часто идёт в ногу с ревью PR раз в квартал.
Атлант расправил плечи: Проект билдится около 8 часов, и то приходится отключать debug-символы, чтобы он собрался в бинарник без сжирания всего RAM.
Ты не пройдёшь!: Иногда проект имеет высокий порог входа настолько, что надо несколько месяцев/лет учить матчасть (ядро ОС, компиляторы и т.д.) Такие проекты часто разрабатывают люди из Microsoft/Google/Apple/etc. на зарплате, потому что за "спасибо" - никому не сдалось.
Где деньги, Лебовски?: На факт контрибьютинга в open source всем пофигу, работодатели не выстраиваются в очередь, и офферы не начнут приходить рекой.
slonopotamus
16.10.2021 12:07+11Вы уверены что у вас есть желание контрибутить, а не _искать причины чтобы не контрибутить_?
Как вообще это работает? Вы просто сели и такой абстрактно "хочу что-нибудь куда-нибудь законтрибутить"?
action52champion Автор
16.10.2021 12:15+1Уверен в том, что нужно потихонечку бороться с шизой типа "интересных проектов" и "хороший программист обязан контрибутить в опенсорс".
fiftin
16.10.2021 23:27+5Я считаю что любой программист должен контрибьютить в open source, потому что сейчас все используют open source для написания приложений. Нужно быть благодарным.
Это как с торрентом - я скачал фильм, а вот раздавать не буду. Т. е. пользоваться результатами чужого труда норм, а самому сделать вклад - нафиг надо?
Yser
17.10.2021 03:55+6какая интересная безапеляционная логика у вас.
все используют open source для написания приложений. Нужно быть благодарным.
Прям все и везде? И "опенсорс" не всегда подразумевает бесплатность, ну да ладно.
Это как с торрентом - я скачал фильм, а вот раздавать не буду. Т. е. пользоваться результатами чужого труда норм, а самому сделать вклад - нафиг надо?
Вот на этом месте у меня выражение лица стало как у того ирландца, которому в одно ухо сказали "ты выиграл миллион долларов", а в другое "через минуту ты умрешь".
Как насчет всех тех кто создал тот самый фильм, который вы скачали, и с такой благодарностью раздаете?)fiftin
17.10.2021 10:05-2Прям все и везде?
Да, за исключением, возможно, каких-то очень узкоспециализированных решений (может для Спирита и Оппотьюнити и не использовался открытый код)
Вот на этом месте у меня выражение лица стало как у того ирландца, которому в одно ухо сказали "ты выиграл миллион долларов", а в другое "через минуту ты умрешь".
Как насчет всех тех кто создал тот самый фильм, который вы скачали, и с такой благодарностью раздаете?)Это только пример, новые фильмы я смотрю в кино, старые на Kinopoisk/Ivi. На торренте скачиваю то, чего в других местах не нашел (ок, не всегда, и не всегда раздаю:)).
А вы, я так понимаю, скачиваете, но не раздаете?
schamberg97
17.10.2021 12:40+1С другой стороны вам бесплатно дали яблоко. Подарили. Обязаны ли вы ответить взаимностью? Нет. Это лишь рекомендовано, но не предписано.
Так же и с Open Source. Риск, что взаимностью не ответят есть всегда. И это нормально.
Касательно же торрентов - пример плохой. Взял, слил чужую интеллектуальную собственность и/или сконвертировал avi в mp4 или любой другой формат - прямо адский труд. Автор герой просто. Геракл, не иначе
fiftin
17.10.2021 23:31-2С другой стороны вам бесплатно дали яблоко. Подарили.
Вам его никто не дарил, вы его сами взяли. Это как человек посадил яблоню, и разрешил срывать яблоки всем. И вот вы ходите и постоянно срываете яблоки. Как бы ничего такого, он сам разрешил, но по человечески, как-то плохо постоянно пользоваться, но ничего не давать взамен.
Касательно же торрентов - пример плохой.
Пример хороший, просто вы его неправильно поняли. Я не про автора, а про таких же пользователей торрента как вы, это они раздают, а не автор. Вот вы постоянно у кого-то скачиваете, пользуетесь добротой людей, а сами ничего не раздаете, как-то не хорошо так поступать.
mrsantak
17.10.2021 16:43+2А я считаю, что любой программист должен open source ровно столько, сколько написано в лицензии тех open source продуктов, которыми этот программист пользовался. Хотите чтобы все пользователи вашей библиотеки контрибьютили в ваш проект - так и пишите в лицензии.
Izaron
16.10.2021 13:55-4Вы уверены что у вас есть желание контрибутить, а не _искать причины чтобы не контрибутить_?
Не могли бы вы развернуть мысль? Вас смущает факт, что у некоторых людей время дорогое и они не будут его тратить на деятельность без выхлопа?
tyomitch
16.10.2021 14:06+9Поиск причин не контрибутить — это и есть деятельность без выхлопа.
Izaron
16.10.2021 14:16-3Но вы же прочитали мой комментарий, который я написал за пару минут, и ответили на него? Вот ненулевой выхлоп. А код, на который вы потратили кучу времени, я никогда не прочитаю и на меня он не повлияет. Вот и нулевой выхлоп =)
F0iL
16.10.2021 22:19+2А код, на который вы потратили кучу времени, я никогда не прочитаю и на меня он не повлияет. Вот и нулевой выхлоп =)
Зато он повлияет на самого автора кода. Даст ему новый опыт разработки, даст ему удовлетворение от самого процесса копания и решения задачи. Вот и ненулевой выхлоп.
tyomitch
16.10.2021 22:45+2Кроме всего перечисленного, автор кода получает ещё и исправленную/доработанную программу в свое распоряжение, иначе можно до морковкина заговения ждать её починки кем-то другим.
slonopotamus
16.10.2021 15:02+11у некоторых людей время дорогое и они не будут его тратить на деятельность без выхлопа
Вы как-то узко ограничиваете причины написать код чисто экономическими соображениями. Человек сам для себя определяет что он считает выхлопом, а что нет. И критерии отнюдь не ограничиваются деньгами. Люди слушают/играют музыку, читают художественную литературу, клеят модельки, ходят в походы, поют, выращивают цветы, занимаются вышиванием, да всё что угодно. И делают всё это не из-за денег, а потому что "им это интересно". Just for fun. И я не верю что у вас нет подобных занятий, когда вы умышленно тратите время на деятельность, не приносящую денег (а то и наоборот, требующую их на инструменты/материалы). Так вот, некоторые люди видят fun в создании свободных программ. Если вы его не видите - ну ничего страшного, занимайтесь своим любимым делом.
Alexey2005
16.10.2021 17:29+6Проект билдится около 8 часов, и то приходится отключать debug-символы, чтобы он собрался в бинарник без сжирания всего RAM.
Обычно в таких случаях проще поправить баг патчем непосредственно бинарника, благо отладчики и дизассемблеры развились очень и очень сильно… в отличие от убогого инструментария C++, который так и застрял в начале 90-х. Нормальной работы с зависимостями там нет и по сей день, как нет и возможности проверить наличие всего необходимого ДО начала компиляции, вместо того чтобы вываливаться с ошибкой сборки через 6 часов после старта из-за того, что какая-то библиотека или иной компонент не найдены/не той версии.
В качестве примера могу вспомнить библиотеку torch, в которой я правил раздражающий баг с неуместными варнингами, зафлуживающими весь output, именно патчем бинарного libtorch_cpu.so. Собранная библиотечка представляет собой блоб на ~355 Мб бинарного кода(!), но при этом благодаря современным средствам реверсинжениринга поиск и правка бага заняли всего лишь около полутора часов, при том что из исходников проект собирать не менее 12 часов, это если он вообще соберётся с первого раза, а не вывалится часов через 5-7, как это обычно происходит с плюсовыми проектами.elektroschwein
16.10.2021 17:50+5Практически во всех приличных проектах проверка "есть ли на хост-системе все необходимые зависимости нужных версий" выполняется на этапе ./configure средствами autotools/cmake/scons/etc., так что тут никаких неожиданностей.
А бинарые патчи, если мы ведем речь про opensource и про использование результатов нашего труда другими людьми, это путь в никуда: бинарный патч сработает только на бинарнике ровно той же минорной версии (и может сломаться при малейшем изменении), собранной тем же компилятором, с теми же флагами и только под ту же платформу.
Да и в мире C++ хорошие подвижки есть, набирает популярность Conan, а самое главное, в C++20 наконец-то утвердили модули (алилуя!).
tyomitch
16.10.2021 17:59+3Если речь не о сценарии «пропатчил и удалил», то инкрементальная компиляция приходит на помощь: хоть первая сборка и займёт часы, зато каждая следующая — считаные минуты.
0xd34df00d
16.10.2021 18:05+16В подавляющем большинстве случаев проектом пользуется полтора человека на Земле. Раз уж мы хотим тратить свое драгоценное время, не лучше ли контрибьютить в то, чем косвенно пользуются миллиарды людей?
Не лучше. Я предпочту тратить свое время на то, что интересно и доставляет удовольствие лично мне. Так выходит, что количество пользователей не является для этого фактором.
На факт контрибьютинга в open source всем пофигу, работодатели не выстраиваются в очередь, и офферы не начнут приходить рекой.
У меня обратный опыт. И находили меня так, и интервью скипали.
fiftin
16.10.2021 23:50+3На факт контрибьютинга в open source всем пофигу, работодатели не выстраиваются в очередь, и офферы не начнут приходить рекой.
Хе, мне предложение по работе приходят только с GitHub, HR-ы сейчас активно пользуются GitHub-ом для поиска кандидатов и контрибьютинг очень важен.
action52champion Автор
17.10.2021 12:51-3Произошла чудовищная ошибка(выжившего)! А если серьезно - то если всрать такое количество ресурсов в контрибут в проекты, в которых заинтересованы работодатели, то имхо те же усилия приложенные к натаскиванию на собеседования дадут гораздо больший выхлоп. К тому же это будет интересно не только тем работодателям которые используют ваши проекты.
Вы возразите, что вам это в кайф, и карьера просто приятный бонус. И конкретно для сета ваших проектов оно так, потому что в вашем воображении эти проекты интересны. В воображении других интересна какая-то другая тематика, в которую они готовы вкладывать силы на энтузиазме. Возможно даже больше сил, чем вы. Только карьерный выхлоп с них будет околонулевой. И чтобы он был отличным от нуля, таким энтузиастам нужно искать что-то релевантное тому за что платят деньги, и через силу строчить коммиты туда. Что опять возвращает нас к вопросу не рациональнее ли приложить эти силы на подготовку к собеседованиям вообще?
fiftin
17.10.2021 23:15+2Ну если вы это делаете только для поиска работы, то наверное да) Но это такая скука)
action52champion Автор
18.10.2021 12:14Тут подвох в том, что авторы реплик "я делал опенсорс и о это дало мне работу" обычно тактично опускают тот факт, делали опенсорс для довольно узкого круга проектов, которые востребованы у работодателя. И просто благодаря этому многие контрибьюторы пролетают.
И потому я снова настаиваю на том, что в массе есть либо проекты бесполезные для карьеры, либо полезные, но там отбоя от карьеристов нет со всеми вытекающимим в виде конкуренции и тем, что все простые(не затратные по времени) задачи уже решены. И в последнем случае усилия на контрибьют оправданы только если вам это интересно, а интерес у каждого свой.
tyomitch
18.10.2021 15:02+2Очень сомневаюсь, что в проектах, куда контрибутит условный @0xd34df00d, нет отбоя от карьеристов.
Предполагаю, что это работает наоборот: работодатели, чтобы узнать область интересов человека (а интерес у каждого свой) -- смотрят, куда человек контрибутит. Если вы контрибутите в проект, который вам неинтересен, то это вам поможет найти лишь неинтересную вам работу. Ну и зачем?
action52champion Автор
18.10.2021 18:20-4@0xd34df00d это редкое исключние из правил. И по узости специальности и по языку и по способностям. При этом сотни таких как он, вложив душу в чуточку другой стэк, отправились подыхать под забор по причине невостребованности. И у них тоже наверняка были сложные проекты где кроме них да еще пары сверхувлеченных, никто не коммитил.
Ну и зачем?
За пределами мира розовых поней интересной работы на всех не хватает. И даже интересная, обложенная сроками, ограничениями и прочим, недолго остается таковой.
ZhilkinSerg
16.10.2021 11:52+21Делайте вклад в проекты с открытым исходным кодом в первую очередь для себя. Ну а в случае, если ваш вклад будет полезен кому-либо еще, то это просто дополнительный, но необязательный плюс.
tyomitch
16.10.2021 12:23+2Присоединяюсь. Пару раз бывало: "так, эту проблему я уже решал N лет назад в таком-то проекте, где тот мой патч?" При этом в код, написанный на "основной работе", после ухода с неё уже не заглянуть.
"Отпускай хлеб твой по водам, потому что по прошествии многих дней опять найдешь его."
slonopotamus
16.10.2021 12:02+7А если хотите развивать швабодный софт, то будьте готовы что плоды ваших трудов будут никому не нужны. Поэтому постарайтесь, чтобы они были нужны хотя бы вам.
У меня есть подозрение что проблема в этих самых ваших плодах труда, а не в плохих дядьках, не желающих по абсолютно разным причинам их принимать. Ссылок на PRы покажете?
rrrad
16.10.2021 12:58Сам наткнулся на ситуацию, когда сделанный совместно с еще одним человеком патч (патч исходно его, я немного доработал) не принимают более года. Там и другие pr, о которых просили в issues также висят. Сам проект - библиотека для конфигурирования, родоначальник одного из форматов для конфигурации. Майнтейнер - коммерческая компания, выпустившая популярный в определённых кругах фреймворк (и даже не один). Там даже посторонние люди писали, что это немыслимо, что по pool request-у нет даже feedback-а. Не уверен, что изначальный автор библиотеки там еще работает, т.к. в ответ на письмо про помощь с развитием, он ссылался на эту компанию в третьем лице. Подозреваю, что у них тупо нет ресурсов для развития библиотеки, а текущий функционал их устраивает и они не хотят чтото сломать у себя (или у своих клиентов: библиотека используется в целой экосистеме). Подозреваю, что нормальный выход из ситуации - создание форка, но на это у самого тупо нет времени.
Mingun
16.10.2021 13:14Никогда не понимал этой боязни "что-то сломать". Они там про SemVer не слышали что ли?
bm13kk
16.10.2021 14:58+3большинство проектов, начиная с определенного размера, из-за этого подхода начинают харкодить версии зависимостей и на столько боятся обновлений - что пркладывают силы, чтобы не обновлять зависимости
Mingun
16.10.2021 15:01+3Никто не предлагает обновлять зависимости своего проекта. Но выпустить новую версию свой библиотеки для своих пользователей, а самим пользоваться старой версией, раз она их устраивает, им кто запрещает?
bm13kk
16.10.2021 16:40-1Когда мы говорим о зависимостях первого уровня - проблем нет. Выбор стратегии, это хорошо. Но когда мы начинаем смотреть на полное дерево зависимостей - начинают вылазить проблемы. Им даже имен придумали DDL/Dependency-hell.
В языках програмирования есть даже холивары - какими алгоритмами резолвить эти деревья.
И это все ДО того, как пришел отдел безопастности и начал свои хотелки добавлять в эту кашу.
Более того, учитывая очень большую вероятность, что подход софт-в-виртуалке станеет стандартом. У нас будет еще более веселая картинка.Mingun
16.10.2021 17:24+1Это все хорошо, но это никак не мешает никак не трогать свой собственный код и в то же время развивать библиотеку. Какая разница, что там в библиотеке будет сделано, если вы ее не обновляете? Как это сломает ваш работающий код? Он как использовал старую версию, так и будет использовать, хоть есть новая, хоть нет.
bm13kk
16.10.2021 18:11+1Я не говорю про ситуацию "не трогать свой код".
Ты работает в проекте. Он работает, развивается. Возьму пример из пхп, как в статье. В определенный момент ты увидел, что в твиге появилась новая функция и ты хочешь ее использовать. Ты прописываешь последнюю версию у себя и перезапускаешь композер. И он успешно падает с ошибкой. Потому что либа в 3м уровне зависимосте не хочет нового твига. И они у себя прописали что максимум они согласны раобтать с версией, которая поледний раз обновилась 5 лет назад.
Я молчу про случаи, когда в дебиане пытаешься установить пакет (вообще ез версии) - и не можешь потому что его зависимости конфликтуют с существующими.
Итого. Мое право как иженера моего проекта - выбирать что я хочу. Лочить или не лочить. И это хорошо, это правильно. Но эволюционно, это привело к тому, что разработчики пакетов - очень консервативны в отношени своих собственных зависимостей. И теперь тебе надо думать над хаками связанными с чужими решениями залочить пакеты.
kompilainenn2
16.10.2021 13:07+13Опять же в общем случае, там все схвачено тусовочкой, и то что пропустят сильно зависит от того насколько вы близки к этой тусовке.
Не согласен про "тусовочку", но я гляжу на всего один проект конечно, LibreOffice. И там такого точно нет, каждому патчу рады, если он реально делает что-то нужное.
А если хотите развивать швабодный софт, то будьте готовы что плоды ваших трудов будут никому не нужны.
Ну странно конечно и выглядит, как стон обиженного "гения". Я вот сам захотел вкладываться в проект, и вкладываюсь, чем и как могу, уже 7 год. И считаю, что плоды моего труда людям нужны и каждый день я вижу этому подтверждение. Совет дня для тебя - просто измени свое отношение к этому или просто не коммить в опен сорц, потому что это реально для души, когда не за деньги.
F0iL
16.10.2021 13:22+9Так-то в принципе логично, что в опенсорсе вообще никто никому ничего не должен.
Я контрибьючу в открытые проекты в тех случаях, когда я вам натыкаюсь на какую-то недоработку или нехватку чего-то в софте, которым лично пользуюсь, поэтому я делаю исправление для себя, а потом уже отправляю его в апстрим, если считаю, что для других это тоже может быть полезно.
Бывает по-разному, самые приятные процессы бывают в проектах больших компаний, типа Google, Microsoft, и т д. - там вам по вашему PR ответят быстро, вежливо, по делу, и чуть ли не за ручку доведут через весь ревью до мержа.
Бывают проекты медленные, в гитхабе одного известного торрент-клиента мой PR поревьюили, аппрувнули, потом была тишина почти год (!), и только месяц назад главный ментейнер пришел, попросил сделать rebase до актуального master'а и смержил все. Хэппи энд.
Есть проекты "безответные", как с одной Cordova-библиотечкой, которой в мире пользовалось полтора анонимуса из-за того что это Cordova и весьма специфичной задачи, которая решалась, но мне в свое время понадобилось решение именно этой задачи, и она сэкономила немало времени. Кое чего там не хватало, кое что там было сломано, я все пофиксил (в первую очередь для себя), закинул PR, тишина, я написал автору на е-мейл с вопросом жив ли проект вообще, автор извинился за задержку и принял PR.
Есть проекты "безответные наглухо" (да, Telegram, это я про вас). Когда в один момент появляется определенная проблема, решение которой просят сотни пользователей по всему интернету (и ты сам тоже), ты в итоге делаешь патч и засылаешь его в проект, реакции ноль, у твоего PR на гитхабе десятки лайков, пользователи в обсуждениях уже предлагают другу другу вручную применять патч и делать билды самостоятельно, а в официальной репе тишина. Впрочем, там такое не только с моим PRом, там таких десятки висит, а другие закрывают вообще без объяснений.
Ну и к вопросу "помогает ли это при работе". В одной компании в начале процессе найма обнаружили, что я когда-то давно контрибьютил в проект этой самой компаниии, и очень сильно обрадовались. До сих пор там работаю :)
Когда я собеседовался в Redhat, после первого этапа был отзыв, мол, "все неплохо, но нам для конкретно этой позиции нужны ещё весьма специфические скиллы, а у тебя их нет, так что извини. Но мы скинули твою сивишку соседней команде, они увидели у тебя активность в проектах на Go, посмотрели, им понравилось и они как раз ищут гофера, хочешь с ними поговорить?" (у меня тогда уже был офер ииначат релокационный процесс, так что пришлось вежливо отказать).
tyomitch
16.10.2021 13:38пользователи в обсуждениях уже предлагают другу другу вручную применять патч и делать билды самостоятельно
Совершенно нормальное положение вещей, много раз был в такой ситуации, сам накатывал патч, сам билдил, оставался доволен. Опенсорс - это когда каждый сам себе ментейнер.
nick1612
16.10.2021 13:44+9Многих авторов опенсорс проектов вполне можно понять, если встать на их место. Когда человек действительно занимается проектом, обдумывает его развитие и у него сформировано определенное видение развития, а конкретнее - как, и что данный софт должен делать, и самое главное, чего он не должен делать. И когда ему приходится постоянно отбиваться от всяких "контрибьютеров", которые вообще не разобравшись с проектом лезут со своими PR "новой модной фичи", и которым нужно каждый раз объяснять, почему их "улучшение" не будет принято, то после определенного момента, этих авторов это все задалбывает и они без объяснений начинают закрывать подобные PR. А дальше идут обиды, что автор токсичный мудак и вообще не достоин находится в нашем комьюнити (вспоминается автор Actix). Я сам наблюдал такую трансформацию несколько раз.
dmitry_rozhkov
16.10.2021 14:49+8Кто бы что не говорил, а большинство серьёзных опенсорсных проектов ментейнятся людьми на зарплате. И интересы этих людей строго коррелированы с интересами их работодателей.
Если ваш PR не принимают, это может значит одно из многого. Но чаще всего - из-за недостатка времени у ментейнеров. PR же осмыслить надо, убедиться, что вреда от него значительно меньше, чем пользы. А это - время. Его мало. Да и самих ментейнеров мало в сравнении с контрибьютерами. Значительно проще и безопаснее дать вашему PR умереть своей тихой смертью от руки бота. Знаю о чём говорю, потому что сам ментейню проект с 18k звёзд на гитхабе. До этого успел наконтрибьютить где-то в 40 проектов разной степени популярности.
Mingun
16.10.2021 19:18+1Но чаще всего — из-за недостатка времени у ментейнеров.
С другой стороны, зачем нужен мейнтейнер, если у него нет времени на проект? Разве это не его прямая задача — иметь время на проект (просто по самому определению ментеййнерства)? Это значит, что его и нет, но формально он есть и занимает место того человека, у которого время бы нашлось.
dmitry_rozhkov
16.10.2021 20:34+5Вы правда думаете, что места ментейнеров - ограниченный ресурс? Что они могут быть заняты и вакантны? Что ментейнеры кому-то что-то должны, кроме их работодателей?
Mingun
16.10.2021 21:05-1Взялся за гуж — не говори, что не дюж
Никто на этой должности не держит. Уйти можно в любой момент
dmitry_rozhkov
16.10.2021 21:27+3Так ведь и придти может любой, попробуйте. И попробуйте сделать парочку ревью средней степени нетривиальности. Может, оказаться, что выделенное работодателем на поддержку время куда-то незаметно делось, а в очереди на ревью оказалось больше открытых PR, чем было в начале рабочего дня.
Будучи ментейнером, очень приятно разобраться со всеми реквестами. Но контрибьютеров много, а ментейнеров почему-то мало. В Kubernetes - это довольно острая проблема. И Линус о том же говорит.
Mingun
16.10.2021 21:45+1Ну вот я точно знаю, что у меня нет прям такой любви к проекту, что я смогу его ментейнить (== добровольно взять обязательства следить за проектом, отвечать на требования сообщества). Поэтому ничего и не мейтейню. А если бы мейнтейнил, но не справлялся, то так бы об этом и написал на странице проекта — ищу нового человека. А судя по вашим репликам у меня складывается мнение, что вы считаете совершенно нормальным, что у вас не хватает времени на эту работу, но сообщить об этом сообществу и пригласить себе помощника или замену не хотите. Если такие попытки есть, но кандидатов не видно — то мой вам почет и уважение. Если нет — извините, но только порицание.
dmitry_rozhkov
16.10.2021 22:21Я ведь написал, придти может любой, у кого достаточно квалификации. Требования обычно в файле GOVERNANCE.md лежат. Новым ментейнерам всегда рады независимо от того, сколько их уже есть. Наверно, просто мало любви у людей к проекту?
fiftin
17.10.2021 11:05+2Хаха)) Вы думаете там конкурс? В большинстве случаев если майнтейнер уйдет, то проект можно архивировать
Mingun
17.10.2021 13:00Если мейнтейнер не занимается своими обязанностями, то проект, увы, заархивирован уже очень давно.
fiftin
17.10.2021 23:49+2У меня есть реальная история. У проекта был майнтайнер, который раз в 2 месяца принимал PR-ы с фиксами. Это даже был не майнтейнер, а просто чувак с правами принимать PR-ы. Но потом появился инициативный чувак и сказал, а давайте я буду майнтенером! И стал. Мерджил все подряд, сломал все что можно и слился. Тот первый посмотрел на это и свалил с проекта. Так и висел проект 2 года в полуразобранном состоянии.
vlad4kr7
16.10.2021 21:14большинство серьёзных опенсорсных проектов ментейнятся людьми на зарплате.
вот прямо на зарплате компании/организации, которая владеет проектом? или с попустительства/разрешения работодателя? или в свободное от работы время?
это будут совсем разные истории: ментейтер как должностная обязанность, или ментейннер пока не надоело.
dmitry_rozhkov
16.10.2021 21:37Разные истории чего?
vlad4kr7
16.10.2021 22:07Разные истории работы и жизни:
Если ментейтер, как хобби на своем проекте, в свободное от работы время или в рабочее время, с разрешения работодателя, то можно забросить проект, или передать другому, гораздо проще, чем, другой вариант.
Если это компания-работодатель развивает опенсорс и ты на проекте главный, то проще работадателя сменить, чем от PR review. Начальник может и спросить, про PR активность.
Krypt
16.10.2021 19:53+1Есть ещё одна проблема, с которой я не имею ни малейшей идеи как быть, кроме как не принимать реквесты совсем: Двойное лицензирование.
Как автор библиотеки я могу это сделать со своим кодом, но не с кодом, который попадает в OpenSource форк через реквесты. И у меня нет желания мейнтейнить 2 разных форка примерно одного и того же.
К сожалению или к счастью, на данный момент проблема чисто теоретическая.action52champion Автор
16.10.2021 21:19Раскройте пожалуйста тему. Неужели до сих пор такая же муторная процедура приема кода в условный GPL проект на гитхабе без каких-то простых правил и оферт - типа если ты отправляешь код в репу, то автоматически от становится той же лицензии что и сама репа? Оставим сейчас случаи когда могут закоммитить код слитый с коммерческого проекта, просто небольшие багфиксы.
Krypt
16.10.2021 23:09На самом деле вы задали несколько каверзных вопросов, которыми я не задавался. Как контрибьютор, всегда думал, что таки да, я передаю код под лицензиею, что использует репозиторий, куда я отправляю код (напрямую или через реквест). И на самом деле пока я не комичу что-то этакое (что-либо, что я могу переиспользовать в другом проекте, или что либо, потенциально нарушающее авторские права/патент/etc) — это проблемы мейнтейнера.
Как мейнтейнер, я видел всего 1 реквест на всех своих проектах, которые никому, кроме меня, по большому счёту, не нужны.
anmipo
16.10.2021 22:37+4У меня была/есть такая же проблема. iOS приложение, опубликовал под GPL, отдельная лицензия для AppStore. Чтобы не было проблем с Apple, у меня должны быть все права на код. Поначалу единственным решением тоже казалось не принимать пулл-реквесты.
Но есть и немного лучшее решение: Contributor License Agreement (CLA). По сути, контрибьютор передаёт автору проекта все возможные права на внесённый код. Принятие соглашения легко автоматизируется через cla-assistant.
С юридической стороны всё отлично: автор проекта может лицензировать новый код как угодно.
С практической стороны, конечно, это антигуманно. Мало того, что контрибьютор сделал доброе дело, так его/её ещё заставляют читать несколько страниц забористого юридического жаргона и отказываться от своих прав в пользу автора проекта. В общем, CLA отпугивает контрибьюторов даже эффективнее чем "спасибо, но мы не принимаем пулл-реквесты." Но всё таки даёт хотя бы теоретическую возможность принимать пулл-реквесты.
fiftin
16.10.2021 23:43+3Когда создаешь большой PR, нужно понимать что у автора проекта есть свое видение его развития, есть roadmap и ограниченное количество времени на ведение проекта. Автор легко примет небольшой PR, который потребует 10 минут на review, но отклонит большой от неизвестного чувака, потому что изучение кода потребует много времени, а принимать его "на доверии" он не будет.
Поэтому, если вы действительно хотите внести большой вклад в open source, не нужно контрибьютить в 50 разных проектов, выберите 1, станьте частью core team и коммитьте на здоровье.
Mingun
17.10.2021 13:09+3Поэтому я, например, стараюсь, чтобы мои PR не вылезали за 10 коммитов, а каждый коммит собирался и проходил все тесты. И вместо одного большого PR слать десятки. Примут один — сразу открываем следующий, благо, код для них уже написан и только и ждет, когда примут предыдущий. А если PR друг от друга не зависят, или зависят мало, то одновременно можно открывать.
К сожалению, даже в такой ситуации ничего не поделать, если мейнтейнерам плевать на проект. Уже вроде и все расписано, и все зааппрувили, только кнопку в интерфейсе нажать — и все равно висит, как здесь. Причем, периодически там в issues отписываются люди, у которых есть права на нажатие кнопки.
bak
16.10.2021 23:55+1Регулярно контрибьючу мелочь которая нужна самому (а так же принимаю чужие PR в свои). Основная проблема - непонятно - попадутся нормальные адекватные ревьюеры, или ЧСВ-шники с синдромом вахтёра.
Нужен какой-то бейдж в репозиторий, который говорит о том что он contributor-friendly, или что-то вроде того.
А так же список пунктов, которым должен соответствовать проект чтобы зваться contributor-friendly. К примеру, PR принимается во всех случаях при выполнении условий:
Не ломает текущую функциональность
Покрыт юнит-тестами
Удовлетворяет требованиям по code-style
В случае проблем с архитектурой / etc. - ревьюер предлагает как поправить PR чтобы он вписался в архитектуру (и никак - не ответ, либо пиши как переделать - либо принимай)
В случае если новая функциональность не вписывается в идеологию проекта - предлагать переписать в виде стороннего плагина. Нету системы плагинов или через неё сделать нельзя? Принимай PR!
В целом - в мелкие / средние проекты довольно легко контрибьютить, авторы как правило адекваты и рады PR-ам. Хотя есть и исключения.
В крупных - как повезёт (зависит от проекта и от конкретного ревьюера).
Очень часто отговорки по которым заворачивают PR абсолютно смешные, со слабой аргументацией и без каких-либо предложений, самый настоящий синдром вахтёра во всей красе.
lorc
17.10.2021 04:56+8В случае если новая функциональность не вписывается в идеологию проекта — предлагать переписать в виде стороннего плагина. Нету системы плагинов или через неё сделать нельзя? Принимай PR!
Не-не-не, так дело не пойдет. Зачем мне видеоплеер в текстовом редакторе, например?
Если вашу мега-фичу не хотят принимать — всегда можно форкнуть проект. Если фича действительно востребована, то у вас появятся пользователи.
bak
17.10.2021 11:17+1Если вашу мега-фичу не хотят принимать — всегда можно форкнуть проект. Если фича действительно востребована, то у вас появятся пользователи.
Ну оно примерно так и работает сейчас. Но это не удобно с точки зрения пользователя, так как полезные фичи оказываются раскиданы по разным репозиториям и относятся к разным версиям проекта.
fiftin
17.10.2021 09:42+4Т. е. если PR добавляет ненужные возможности, то он будет принят? Через год проект превратится в такого крокодила что им никто не захочет пользоваться и коммитить в него))
Скорее нужен бейдж "Адекватный контрибьютер" ))
bm13kk
17.10.2021 10:57+3Покрыт юнит-тестами
вот больное место. У меня примерно 2 раза в год ситуация, когда зеленые тесты приводят к сломанной функционалу. Написать хорошие тесты (хорошие тесты могут только быть многослойными) - больше работы, чем сам код.
Даже если проет дружествен к тестам, имеет необходимую структуру и хелперы, чтобы быстро писать тесты. Фактически надо рахобраться в самом проете. А потому разобраться в том, как пишут тесты в этом проекте.
JayDi
17.10.2021 00:27+9Скажу как мейнтейнер одного крупного (1.5 млн строк) java-проекта:
Новичку зачастую не знакома история проекта и история различных "багов". В результате появляются исправления вида "я тут посмотрел код и нашел решение". Формально оно исправляет баг, но де-факто лишь прикрывает костылем одну из дырок.
Следствие из предыдущего пункта -- если человек сделал объемный PR и, алилуйа, даже тесты написал (что бывает крайне редко), но при этом не дожал или пошел не по тому пути, то приходится самому разбираться в проблеме и дописывать код. Это иногда раздражает и отнимает лишнее время.
Поэтому, как мейнтейнеру, мне очень не нравятся слишком инициативные разработчики, которые время от времени забегают в проект, накидывают всяких исправлений, а потом ты вынужден сидеть, разбираться и дописывать за них внеплановые фиксы и задачи. Но и правила хорошего тона не позволяют их остановить -- поэтому таких людей стараюсь ставить "на паузу" и "притормаживать" их активность.
А вообще, новый разработчик в проекте -- это всегда радость. Пусть даже и небольшие исправления от него. Собственно, как и любая активность от обычных пользователей вроде баг репортов или предложений.
fiftin
17.10.2021 09:51+2Согласен на 100%, тут большенство комментаторов жалуются что не принимают их очень важные PR-ы, а то что на GitHub-е куча неадекватов и каждый PR нужно досконально проверить, их не волнует. Человек, который веред проект, часто, делает это в свободное время, он не обязан тратить его на чей-то говнокод, поэтому принимает только мелкие и понятные PR-ы, а портянки отклоняет.
mayorovp
17.10.2021 10:23+2Э-э-э, а просто указать автору PR, что вот тут недоисправлено — не вариант?
JayDi
17.10.2021 10:52+4Одно дело, когда исправление неправильное, и можно сразу об этом написать/отклонить, а другое дело -- когда чего-то не хватает или реальная проблема где-то в другом месте находится. Я сам не знаю точного ответа и в этом случае требуется самому провести исследования и собрать материал по тем местам, что требуют проверки/исправления. Т.е. сделать фактически половину работы.
fiftin
17.10.2021 11:10+2Чтобы указать где недоисправлено, нужно изучить код, но в большинстве случаев говнокод видно сразу и проще его отклонить, чем разбираться
StriganovSergey
18.10.2021 14:35+3будьте готовы что плоды ваших трудов будут никому не нужны
Это касается всех программистов, и опенсоурс, и корпоративных.
Даже, если заплатили за работу, никто не гарантирует, что разработанный софт не выкинут в помойку.
(в связи с ликвидацией организации, реорганизацией, корпоративной шизой)
KvanTTT
18.10.2021 14:39+2Я бы обобщил еще больше: это касается всех: программистов, архитекторов, ученых, дворников. Ну и это вообще норма, особенно для ученых, которым постоянно приходится выкидывать неработающие гипотезы.
action52champion Автор
18.10.2021 18:24+1Я бы обощил еще больше. Пусть А - субъект выполняющий действие. Р - результаты труда его действия. П - вероятность выкидывания Р субъекта А на помойку. Тогда для любых А и Р, П > 0.
Moskus
Немного статистики
JayDi
Странная статистика. Например, для России они требуют наличия аж 59 подписчиков на твой аккаунт. А вовсе не количество публичных коммитов. В результате в половине топа какие-то левые аккаунты с всего десятком коммитов.
Elfet
Какая-то странная статистика.
Например я(antonmedv) на 153 месте в Швейцарии. А vladh на 150.
Но сравните наши gh профили?