Pull to refresh

Невыносимая легкость контрибьюта в Open Source

Reading time5 min
Views21K

Мы дожили до момента, когда для отправки своего коммита в популярный проект, не нужно подписывать бумажный отказ от прав на код, как это бывало в случае с 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 на больших кластерах, буквально живете этим, ловите редчайший проблемы для редких ситуаций, то это другой разговор. Люди строчащие коммиты в серьезный проект по КД обычно имеют для этого подходящую работу и ресурсную базу. Или социальную базу.

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

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

Tags:
Hubs:
Total votes 109: ↑93 and ↓16+101
Comments93

Articles