Как за месяц открыть 116 PR и получить 13 мерджей: опыт open source

116 пулл-реквестов, 177 найденных багов, 13 мерджей, из них пять — в чужие репозитории. За один месяц. Это не фантастика, а реальные цифры из отчета разработчика Анируддхи Адака, который решил проверить, что будет, если относиться к open source как к ежедневной практике.

Сразу оговорка: эти цифры не должны пугать. Они показывают не недостижимый рекорд, а механику. Большинство из 177 issues — это мелкие баги, найденные при чтении кода. Пять мерджей в чужие проекты — результат аккуратной работы с существующей архитектурой. И каждый такой PR — это кусок портфолио, который работает на вас даже после закрытия вкладки GitHub.

Почему open source стоит времени

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

Анируддха за месяц просматривал чужие репозитории с «лупой»: читал код, искал места, где поведение расходится с ожиданиями. Так и родились 177 issues. Из них 7 публичных security-репортов и 2 приватных — то есть часть найденного была достаточно серьезной, чтобы сообщать о ней непублично.

Цифры, которые стоит разобрать

Распределение issues по проектам показывает, что не нужно пытаться охватить все сразу. Десять проектов, на которые пришлись основные находки, и вот как они распределились:

Шестьдесят issues в одном проекте — это не значит, что проект ужасен. Это значит, что вы глубоко в него погрузились. Гораздо полезнее изучить один репозиторий досконально, чем поверхностно посмотреть десять.

Кейс: как починить Ctrl+F в больших таблицах

Самый яркий результат месяца — два мерджа в genspark-ai/genoffice, офисный пакет с открытым кодом. Первый фикс касался поиска по таблице: при ленивой загрузке данных Ctrl+F искал только среди уже загруженных строк. Если в вашей таблице 50 тысяч строк, а нужное значение на 40-й тысяче, поиск выдавал честное «ничего не найдено». Значение, конечно, было.

Вместо того чтобы писать собственный поиск с нуля, Анируддха использовал примитивы, которые уже были в кодовой базе для AI-поиска: те же функции чтения данных, те же лимиты. Получился минимальный, аккуратный патч, который не ломает остальное. Мейнтейнер проекта отметил именно это: «спасибо за аккуратность и за то, что переиспользовали существующие механизмы, а не построили параллельный велосипед».

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

Второй кейс: фича, которая обернулась уроком

Второй мердж добавил в GenOffice подсветку строки и столбца активной ячейки — как в Excel, только аккуратно и опционально. Фича полезная, но не она запомнилась. А запомнилась ошибка, которую автор допустил в первом пуше: при добавлении новых строк интерфейса он сдвинул значения i18n-ключей во всех девятнадцати локалях. Кнопка на вкладке View в зависимости от языка показывала «en» или «zh» вместо нормального текста.

Мейнтейнер заметил это сразу и объяснил, что именно сдвинулось. Анируддха поправил и встроил в свой процесс простое правило: после любых массовых изменений локализации сравнивать каждую локаль со списком ключей до пуша. Девятнадцать локалей не прощают копипаст-расхождений.

Как повторить этот результат

Если вы хотите не просто разово пофиксить баг, а погрузиться в open source системно, вот что стоит делать:

• Выберите один-два проекта, которыми реально пользуетесь. Так вы будете знать, как они должны работать, и быстрее найдете несоответствия.
• Читайте код без задачи. Просто открывайте файлы и смотрите, что происходит. Баги начнут находиться сами.
• Оформляйте PR так, чтобы мейнтейнеру было легко. Описывайте, как воспроизвести проблему, что меняете и почему, какие тесты прогнать.
• Не расстраивайтесь, если PR не приняли с первого раза. Из 116 PR восемь автор отозвал сам — это нормально, когда видишь, что решение неудачное и лучше переделать.
• Используйте готовые примитивы, даже если они кажутся неочевидными. Чужой код — это библиотека, а не препятствие.

Но главное — регулярность. Разовые контрибьюты дают мало. А вот ежедневная практика — чтение, поиск, мелкие фиксы — со временем превращает вас в человека, которому мейнтейнеры доверяют.

Типичные ошибки новичка

По опыту этого месяца можно составить небольшую таблицу ошибок:

Что в итоге

Цифры августа — не цель, а побочный эффект регулярной работы. 116 PR, 177 issues — это не про «выпить море кода», а про системное погружение. Каждый принятый мердж — строчка в резюме, каждый issue — доказательство того, что вы умеете находить проблемы. И каждый отклоненный PR — повод стать лучше.

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