Я сеньор-разработчик с 10-летним стажем в энтерпрайз-программировании.

Все эти 10 лет я пользовался теми или иными решениями из open source: заходил в проекты, читал исходные коды и документацию, писал свои pet-проекты на GitHub. Но до сих пор ни разу не контрибьютил в open source.

А мечта такая была всегда. Ведь какой я программист, если не участвую в open source-сообществе?

Почему я долго не начинал

Попытки исправить этот пробел у меня уже были.

У меня были коллеги, которым удавалось находить баги в популярных проектах и приносить туда исправления. На своей практике я тоже иногда сталкивался с проблемами в чужом коде, но почти всегда думал:

Скорее всего, об этом уже знают умные люди.
Скорее всего, это уже поправили.
Скорее всего, нет смысла идти и предлагать своё исправление.

Ещё я читал статьи в духе «топ open source-проектов для первого вклада», открывал репозитории, смотрел issues с пометкой ideal for first contribution и пытался в них разобраться.

Но обычно быстро понимал, что ничего не понимаю.

Как запускать проект?
Где править?
Что вообще от меня хотят?
Можно ли задавать вопросы?
А если вопрос глупый?

Писать уточняющие вопросы мейнтейнеру было страшно. Вдруг я спрошу какую-то очевидную вещь и сразу станет понятно, что я тут случайный человек?

Но в голове всё равно жила мысль:

Open source — это не только «писать код бесплатно». Это способ выйти за пределы своей песочницы и посмотреть, как живут реальные проекты, которыми пользуются другие люди. И, может быть, самому немного в этом поучаствовать.

Воля случая

И вот я как-то попал на митап, где ребята из индустрии презентовали новый open source-инструмент для сообщества — Axelix.

Проект был про боли, связанные с сопровождением Spring Boot-приложений. То есть не что-то далёкое и абстрактное, а вполне понятная мне область: Java, Spring Boot, эксплуатация сервисов, диагностика и всё то, с чем backend-разработчик сталкивается в реальной жизни.

И в этот момент я понял:

Кажется, это оно.

Стек привычный.
Идея проекта понятная.
Мейнтейнеры прямо говорят, что ждут вклада от сообщества.

Казалось, всё сошлось.

Как оно было

После митапа я приехал домой воодушевлённый.

Открываю GitHub, нахожу проект, вижу документацию, правила для контрибьюторов, описание и много кода. Из митапа я уже знал, что проект пишут около года и скоро должен быть первый релиз.

Открываю issues — и там много открытых задач.

Часть уже назначена на кого-то.
Часть вообще непонятно про что.
Часть выглядит так, будто без контекста проекта туда лучше не лезть.

И меня снова начинает пробирать знакомый страх:

Ну всё, опять ничего не понятно.

Но в этот раз я всё-таки не закрыл вкладку.

Привыкший в корпоративной культуре к Jira и её аналогам, я начал смотреть на лейблы. Нашёл нужный для меня ideal for first contribution, отфильтровал задачи — и стало уже не так страшно.

Количество issues уменьшилось.
Страх тоже немного уменьшился.

Начал читать заголовки и нашёл задачу, описание которой было мне понятно. Проваливаюсь глубже — а там аккуратно подготовленное описание: что нужно сделать, зачем это нужно и какой минимальный контекст нужен для старта.

И тут я впервые подумал:

Похоже, это можно взять.

А что делать дальше?

Дальше, как у неопытного в open source человека, возник вопрос:

А что теперь делать?

В корпоративной разработке всё понятно: есть задача, есть команда, есть процесс, есть договорённости. А тут чужой репозиторий, чужой проект и публичное пространство.

Благо в современном мире нейронок можно задать этот глупый вопрос AI-помощнику.

Ответ оказался простым: оставить комментарий в issue и попросить назначить задачу на себя.

Так я и сделал.

После этого клонировал проект и начал разбираться. Где-то помогал опыт, где-то документация, где-то AI-помощник под моим чутким руководством.

Первый PR

Сама задача, к счастью, оказалась не из серии “переписать половину проекта за вечер”.

Нужно было добавить кеширующую обёртку над AxelixVersionDiscoverer — компонентом, который определяет версию Axelix. Смысл был простой: первый раз версию вычисляем, сохраняем, а при следующих вызовах уже отдаём из кеша.

Для первого PR это оказалось почти идеальным вариантом: задача небольшая, результат понятный, польза тоже понятная. И главное — не нужно было сразу погружаться во все внутренности проекта.

Следующий вопрос был уже технический:

А у меня же, наверное, нет прав коммитить в feature-ветку open source-проекта?

И я оказался прав.

Тут уже помог обычный GitHub-процесс:

  1. форкнуть проект;

  2. создать ветку в своём форке;

  3. закоммитить туда изменения;

  4. открыть pull request в основной репозиторий.

И вот настал тот самый страшный момент — создать свой первый PR в open source.

Было реально страшно.

Что его не примут.
Что я что-то сделал не так.
Что всё было зря.
Что это будет видно всему миру, и я могу опозориться.

Собравшись с духом, я нажал Create pull request и написал описание к своим изменениям.

Ожидание

Дальше было ожидание.

Я несколько раз заходил посмотреть исходник своих изменений. Проверял, ничего ли не забыл. Раз в час открывал PR и смотрел, не поменялось ли что-то, не задеклайнили ли его.

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

И в этот момент меня начали переполнять чувства.

С одной стороны:

И всё? Это было так просто?

С другой:

Я теперь контрибьютор в open source-проект, который хоть кому-то интересен?

Я был реально рад.

Казалось, я стал маленькой частью того, что раньше казалось доступным только для «крутых программистов».

Да, вклад был небольшой. Но для меня это был важный момент.

Что было дальше

А дальше всё стало проще.

Цели сделать вклад просто ради галочки у меня не было, поэтому я продолжил. Уже не так стеснялся писать комментарии в issues, задавать вопросы по задачам, писать напрямую мейнтейнеру, если были какие-то концептуальные вопросы.

Потом были ещё PR, замечания от мейнтейнера, правки, обсуждения.

И оказалось, что весь этот процесс очень похож на мои обычные рабочие будни:

  • разобраться в задаче;

  • понять контекст;

  • внести изменения;

  • открыть PR;

  • получить review;

  • поправить замечания;

  • довести до merge.

Только с небольшой ноткой большей ответственности: этот PR увидят не только твои коллеги, но потенциально и весь мир.

И оказалось, что не так всё страшно.

Что я понял

Наверное, главный вывод для меня такой:

Первый вклад в open source — это не обязательно большой и сложный PR. Иногда достаточно маленькой понятной задачи, нормальной коммуникации и готовности довести дело до конца.

Мне долго казалось, что open source — это территория каких-то очень крутых программистов, которые знают всё лучше меня.

А на практике оказалось, что начать можно довольно просто:

  • найти понятный проект;

  • выбрать небольшую задачу;

  • прочитать правила контрибьюта;

  • задать вопрос, если что-то непонятно;

  • сделать первый PR;

  • спокойно пройти review.

Open source не начинается с большого архитектурного вклада. Иногда он начинается с маленькой правки, issue, документации или аккуратного вопроса.

Главное — не приходить «спасать проект», а попробовать быть полезным.

Вместо вывода

Я 10 лет пользовался open source и думал, что когда-нибудь тоже начну участвовать.

Оказалось, что «когда-нибудь» наступает не тогда, когда ты становишься достаточно умным, опытным или уверенным. Оно наступает, когда ты выбираешь маленькую понятную задачу и делаешь первый шаг.

Для меня этим шагом стал первый PR в Axelix.

И да, я ничего не сломал.

В итоге open source оказался не закрытым клубом для избранных, а обычной инженерной работой в публичном пространстве.

Да, страшнее нажимать кнопку.
Да, больше ответственности.
Но процесс тот же: понять задачу, сделать маленькое изменение, пройти review и довести до результата.

P.S. Через какое-то время после моего первого вклада было очень приятно увидеть на крупной конференции, в докладе про этот open source-проект, своё имя в списке благодарностей.

Мелочь, конечно.

Но для человека, который 10 лет собирался «когда-нибудь начать контрибьютить», очень приятная.