Всем привет, меня зовут Юрий Пузыня, я занимаюсь развитием платформы документации Diplodoc в Yandex Infrastructure, которую мы пару лет назад выложили в опенсорс. И сегодня я расскажу лёгкую историю невероятного везения в опенсорсе.
Мой первый коммит как контрибьютора в опенсорс‑проект был смёржен спустя два с половиной года мной же в качестве мейнтейнера этого проекта. И в чём тут история успеха — спросите вы. Но давайте я расскажу всё по порядку.
Глава 1, в которой герой знакомится с опенсорсом и учится всё делать правильно
Эта история началась, когда я работал в маленькой компании, в которой продажников было больше, чем программистов, и времени на изучение и внедрение новых технологий не было совсем. Мы деплоились в продакшн через Rsync, важный код хранили в SVN, неважный — просто на локальных компьютерах. А во время обедов обсуждали, что неплохо было бы внедрить Jira или Redmine в качестве таск‑трекера. И тестировались мы часто прямо на проде, руками откатывались, снова выкатывались. Всё это было крайне неэффективно, но мы разрабатывались как могли.
Но однажды настал тот день, когда пришло время воспользоваться новой технологией на работе, и я долго пытался разобраться, почему она не работает так, как написано в документации, а в некоторых случаях — не работает вообще. Потратил много времени на поиск в интернете и понял, что технология выложена в опенсорс и готова к улучшениям от любого желающего. «Пришло моё время», — подумал я.
Воодушевившись и вооружившись энергетиками, коль здоровье ещё позволяло, я за пару дней или даже, скорее, ночей разобрался с необходимой мне проблемой, попутно починил ещё парочку. Разобрался, как оформить свой первый пул‑реквест на Github — это для меня был первый опыт, я только начинал разрабатывать. И нажал заветную кнопку Create pull request и, прямо скажем, ворвался в опенсорс с ноги.
Так моя история могла бы закончиться, но мне повезло, и на проекте меня ждал очень опытный и терпеливый мейнтейнер, который помог мне сделать первые шаги в опенсорсе.
Через два дня в моём пул‑реквесте появился первый комментарий, смысл его был таким: «Здравствуйте, спасибо за ваш вклад в проект. К сожалению, сложно понять, что в точности здесь происходит. Возможно ли разбить пул‑реквест на несколько частей?» Меня этот комментарий удивил своей вежливостью и заставил подумать, как сделать пул‑реквест лучше. И придумал я небольшой багфикс, который можно оформить отдельно.
Оформил 47 строчек кода, дождался следующего фидбека, в котором меня просили всё описать. Мне это показалось странным. Мол, 47 строчек кода, казалось бы, прочитай 47 строчек — всё пойми. Но спустя много лет я понял, что описание нужно не только мейнтейнеру и контрибьютору, оно нужно будет ещё и всем, кто это будет когда‑нибудь читать ради истории, чтобы понять, что там происходило.
Добавил описание, снова залил изменения на сервер, и теперь меня попросили написать тесты. Сейчас это не кажется удивительным, но тогда мне, человеку, который вообще не писал ни разу тесты, было, конечно, волнительно. К счастью, мейнтейнер мне оставил подробные инструкции о том, как пишутся в этом проекте тесты, куда их лучше написать. Я справился достаточно быстро, залил и эти изменения на сервер, и тут практически моментально получил заветный бейдж Merged.
Я пытался лениться, но мне не дали: на пятом пул‑реквесте я понял, что всегда будут описания, тесты и хорошие названия коммитов. Мы перестали тратить время на ожидание обратной связи, и дело пошло быстрее.
На этом этапе я сделал для себя несколько выводов:
Не торопитесь. Опенсорс — это про взаимовыгодный обмен временем. Это действительно должно быть выгодно и вам, и мейнтейнеру. Да, вам может быть не очень приятно постоянно писать тесты, но вы на этом можете развиваться и учиться.
Изучите требования. Старайтесь выполнять те требования, которые на проекте уже есть, чтобы сэкономить время своего старта. Это максимально сокращает бесполезную коммуникацию.
Начните с малого. Если вам кажется, что первое изменение невозможно разделить на части, то лучше начать с другого исправления, может быть, с чего‑то поменьше, чтобы вы почувствовали проект.
Поймите, устраивают ли вас процессы. Действительно ли вам выгодно работать с этим проектом? Потому что вы ни в коем случае не должны чувствовать дискомфорт в опенсорсе. Иногда это повод сменить проект, иногда — поговорить с контрибьютором, иногда — прочитать документацию проекта, чтоб понять, чего от вас ждут.
Глава 2, в которой герой что-то теряет, расстраивается, но потом находит и снова становится счастливым
Шли месяцы на опенсорс‑проекте, и я понял, что мне уже не хочется идти на основную работу, так как на ней нет того, к чему я привык: хорошо настроенного CI/CD‑цикла, таск‑трекера, автоматического тестирования и, главное, не было Git. Чтобы вернуть мотивацию, я решил менять реальность вокруг себя и внедрять в работу технологии, которые попробовал на опенсорсе. И тогда опенсорс перестал быть для меня бесплатным — на основной работе меня стали больше ценить и повышать мне зарплату.
Глава 3, в которой герои учатся работать вместе
К концу первого года участия в опенсорс‑проекте я пришёл к своему следующему кризису. Я достаточно хорошо знал проект, у меня уже появилась собственная стратегия. Я открывал от двух до пяти пул‑реквестов в день, но всё чаще они отклонялись, или обсуждения с мейнтейнером затягивались так, что уже ничего не хотелось. Я стал хуже спать, потому что не понимал, что происходит и как это всё поправить. Назревала буря. Думал либо отказаться полностью от проекта, над которым я работаю, либо, что ещё хуже, форкнуть его.
И тут мне снова повезло — мейнтейнер проявил инициативу и предложил всё обсудить. Впервые за год я общался с человеком не в пул‑реквестах, а в другом канале — тогда ещё было модно вести основательные дискуссии в почте.
Буквально за одну сессию переписки в почте мы с мейнтейнером решили все проблемы. Договорённости были довольно банальными: проект был уже большой, и на нём нужно разделять области ответственности и проработать API для расширяемости проектов.
Также все дальнейшие большие изменения мы будем заранее обсуждать в Issue, до того как будет написан какой‑либо код, чтобы потом никто не обижался, что эти изменения не нужны. Нам очень помог Extension API — можно было части своего проекта выносить в отдельные репозитории, развивать по своим правилам и говорить сообществу — пользуйтесь на свой страх и риск. Это ускоряет разработку.
Я описал решение конкретной проблемы, которых может быть много на проекте, но самое важное — помнить, что мейнтейнер не робот, это человек, с которым можно поговорить и договориться.
В этой истории помогли новые каналы коммуникации, но здесь я бы хотел вас предостеречь. Если вы только пришли на проект, будет плохим тоном искать альтернативные каналы коммуникации. Представьте, мейнтейнер вас не знает, а вы стучитесь ночью к нему в личку и рассказываете свою гениальную идею, как сделать его проект лучше. Я после такого, скорее всего, добавлю человека в чёрный список и продолжу жить спокойно.
Глава 4, в которой все начинают говорить на одном языке
Шёл второй год работы над проектом, и я был уже не контрибьютором, а мейнтейнером, что накладывало на меня дополнительные задачи, активности, которые мне в большинстве своём нравились.
И мне нравилось общаться: мы общались на английском, и это была отдельная интересная задача — коммуницировать с тем, кто далеко от тебя, но вас объединяет одно общее дело. Были сложные архитектурные обсуждения, и мне тоже это очень нравилось, потому что я не чувствовал себя каким‑то суперопытным разработчиком и смотрел, с кем я участвую в дискуссиях, наблюдал за их умными мыслями. В какой‑то момент осознавал, что я уже могу генерировать свои мысли, пожалуй, тоже умные. И, безусловно, было приятно.
Потом начались локальные митапы для популяризации технологии, и это был мой первый, незабываемый опыт публичных выступлений. Всё это было бонусами к тому, что я стал мейнтейнером, но были и нюансы.
Я начал замечать, что я абсолютно не справляюсь с локальной коммуникацией на проекте. То, что давалось предыдущему мейнтейнеру так легко — он с таким терпением помогал мне пройти мои первые шаги, — я этого совершенно не умел. И когда я смотрел, например, на какой‑нибудь issue с названием Something went wrong…, я даже иногда впадал в панику, уходил пить чай и не возвращался. Ну не хочется заходить в такой issue. Хочется что‑нибудь типа: конкретное название ошибки в таком‑то компоненте. Желательно, чтобы первой же строчкой внутри issue было «я готов сам починить».
Другая проблема, когда не просто неинформативное название ошибки, а настоящая паника: всё сломано, срочно сюда ваше внимание нужно! Ещё меньше хочется таким заниматься. А чего хотелось бы? Хотелось бы, опять же, конструктива: «Фатальная ошибка в самом начале работы с приложением». И тогда я как мейнтейнер, конечно, поставлю на такой issue бейджик крайней важности и, скорее всего, сам пойду чинить: если моё приложение полностью не работает, я не могу бесконечно долго ждать, когда кто‑то за меня это починит.
Проблемно было и если какой‑нибудь пользователь писал две страницы текста, пытаясь задать вопрос где‑то в середине, но когда ты уже дочитал до конца — ты не понимаешь, в чём именно вопрос, о чём вообще речь. И уходишь думать — наверно, там было что‑то важное, и думаешь: «Сейчас попью чайку и ему отвечу». И тоже не возвращаешься.
Я понял, что это проблема не только моих пользователей, но и моя собственная. И чтобы снизить эту нагрузку на себя и на проект, я сделал contribution‑гайды, issue template, pull request template. И стало попроще. Бóльшая часть issue и пул‑реквестов стали открываться в правильном виде, стало поприятнее в них заходить.
Отдельная проблема — когда разработчики создают пул‑реквесты без оглядки на проект в целом. Перед тем как предложить правки, стоит потратить чуть больше времени и понять, там ли вы видите проблему. Может быть, 10 коммитов назад всё так и было задумано, а если это проблема — докажите, пожалуйста, что это действительно так. Вернитесь в историю на 10 коммитов назад и покажите, с чего всё началось, чтобы я мог дать конструктивный фидбек. Без этого мне приходилось самому заходить в такие пул‑реквесты и думать: «Как мы такое вообще допустили?», и идти самому по этой истории. Мейнтейнеров часто меньше, чем контрибьюторов, и важно уважать их время и максимально им помогать.
Итак, советы для мейнтейнеров:
Рефлексируйте над тем, что происходит на вашем проекте и почему он, возможно, доставляет вам дискомфорт.
Структурируйте места, которые помогают вам оптимизировать процессы, — в моём случае contribution‑гайды, issue template, pull request template и так далее.
И неоднозначный, но за годы практики всё‑таки очень важный совет: если вы считаете, что на вашем проекте всё хорошо, и этому уже есть много подтверждений — игнорируйте плохие описания issue и пул‑реквестов. Если люди не справляются с десятой попытки, уже после того как вы выдали им личные инструкции, я вам советую не тратить на них время, потому что они не тратят его в должной степени на вас. Напоминаю, опенсорс — это взаимовыгодный обмен временем.
Глава 5, в которой герой наконец решает свою задачу спустя два с половиной года
В качестве мейнтейнера у меня появилось больше возможностей по внесению изменений в проект. Во‑первых, уже было срезано очень много углов по тому, как проводить коммиты до прода. Это уже были не те процессы, с которыми я встретился вначале. Я не стал писать меньше тестов, их осталось столько же, просто мне не обязательно было теперь ждать апрува от соседнего мейнтейнера на каждое изменение. Мы ревьюили исключительно самые большие, важные, а в остальное время я развивал проект почти самостоятельно.
Из того пул‑реквеста, который был у меня изначально, на 5000 строк кода, к этому моменту осталось всего 36. Всё остальное я за это время каким‑то образом вынес оттуда. И на самом деле смёржить этот пул‑реквест было уже делом принципа, потому что в нём не было ничего полезного, скорее всего, там были только строчки какой‑нибудь документации. Проект за это время сильно разросся: то есть мои 5000 строк превратились, скорее всего, где‑то тысяч в 40 и были написаны уже не только мной, но и всем комьюнити. Да и на самом деле то, что я принёс вначале, было неправильным, недостаточным, и мне помогли с этим разобраться. В этом и есть суть опенсорса.
Эпилог
Когда я только попал в опенсорс, повезло с мейнтейнером. Это был потрясающий человек, кажется, из Чехии, с невероятным терпением. Он на долгие годы стал моим ментором. То есть я, вообще, заходил в опенсорс, чтобы решить свою задачу, не знал, что есть другие причины, чтобы этим заниматься. Но как только я пришёл в опенсорс, оказалось, что на самом деле основная моя потребность — это обучение и развитие. Я как‑то это прочувствовал сразу на проекте и начал черпать из общения со своим ментором кучу информации.
Мне повезло и с самим проектом, потому что он рос вместе со мной. Мои потребности на проекте менялись. То есть сначала это было обучение и развитие, потом мне стало больше интересно именно взаимодействие с комьюнити. Участие в митапах давало мне какое‑то чувство собственной важности, и проект мне всё это позволял.
Мне повезло с этим проектом в последний раз, когда необходимо было от него отказаться. Так бывает, что ваши дороги с конкретным опенсорсом расходятся, потому что вы его переросли. В моём случае я устроился в IT‑компанию и появились другие приоритеты. И в этот момент так получилось, что мою технологию заменили на рынке на более интегрированную в основные продукты, и я смог достаточно легко повесить бейджик «Заархивирован» на свой проект, сказать коммьюнити спасибо, и мы пошли приносить в пользу дальше в опенсорсе, в других проектах.
Очень сложно сделать выводы из истории, где постоянно везло. Но главный вывод будет в том, что, несмотря на везение, полагаться на него не нужно, а нужно постоянно рефлексировать. Если в какой‑то момент вам почему‑то опенсорс не нравится, на это точно есть очевидная причина, и она может быть очень легко исправлена, потому что в опенсорсе самые классные люди, здесь всегда можно договориться. Самые классные, самые умные, самые безвозмездные. И, договорившись с этими людьми, вы можете помочь им улучшить какие‑то процессы, документации, чтобы стало понятнее, как с этим всем работать.
Но если это всё не помогает — это очень спорный пункт, мы долго думали, добавлять его или нет, — игнорируйте. Бывает, что проект действительно вам не подходит. Бывает, что проект не подходит никому, и такие проекты закрываются. В опенсорсе тоже есть конкуренция, но она выражается не в деньгах, а в качестве проектов.
Проектов в опенсорсе достаточно для того, чтобы выбрать себе хороший, и недостаточно для того, чтобы мы все тут сидели поодиночке. Нам приходится на хороших проектах собираться в группы, что прекрасно.
Кстати, у нас в Diplodoc есть целая небольшая программа для контрибьюторов с призами и славой.
Спасибо, что прочитали. Приятного вам опенсорса!
