По случаю перезапуска сайта хочется привести без сокращений статью, которую написал Aleksander Alekseev. Удивительно, но нас до сих пор спрашивают некоторые начинающие OSS-энтузиасты, с чего бы им начать общение с OSS-сообществом? Как раз на этот вопрос и пытается ответить Aleksander в этой статье:

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

Между прочим, интересный вопрос — а зачем это вообще кому-то может быть нужно? Для большинства людей работа над открытыми проектами — это в первую очередь возможность получить колоссальный опыт разработки, а также сделать нечто, чем будут пользоваться миллионы людей по всему миру (возможно, даже не зная об этом) ну как минимум еще ближайшие лет 10. Не стоит также списывать со счетов желание понять, как внутри устроены, скажем, операционные системы или компиляторы. Я пишу здесь об этом по той причине, что без достаточно сильной мотивации вы вряд ли найдете лишнее время для работы над каким-то там опенсорсом. Поэтому первым делом поймите для себя, что именно привлекает вас в данном конкретном проекте.

Примечание: Также вас может заинтересовать статья Как я прокачиваю владение английским языком. В мире open source, как правило, все разработчики общаются между собой на английском языке.

Далее предполагается, что вы определились с проектом, а также разобрались, как он компилируется, как прогоняются тесты, как происходит установка, а также нашли описание процесса разработки и место, куда нужно посылать патчи. Это не сложно. Примеры см в заметках Сборка LLVM-стека из исходников и чем она так интересна, PostgreSQL: сборка из исходников и настройка под Linux и Памятка по сборке ядра Linux из исходного кода. Также не повредит разобраться, как отлаживать проект. Тут все сильно зависит, помимо прочего, от используемого в проекте языка программирования, а также используемой вами ОС. Если проект написан на C или C++, то обратите внимание на мои заметки, посвященные GDB, LLDB и WinDbg. В любой непонятной ситуации не стесняйтесь обратиться за помощью в мейлинг лист или IRC-канал проекта.

Итак, с чего же можно начать:

• Опечатки. Начните с малого. В любом достаточно крупном проекте полно опечаток, как в документации, так и в комментариях к коду. Патчу, который их исправляет, гарантированно все будут очень рады, а шансы сломать что-то таким патчем равны нулю. А значит его почти наверняка быстро примут. В процессе у вас сложится хорошее понимание, как в данном конкретном проекте нужно оформлять патчи, куда их нужно слать, и так далее.
• Code review. Большинство программистов обожают писать код, но не очень любят читать или тестировать его. Поэтому многие проекты испытывают нехватку в ревьюверах. Будучи новичком в проекте, вы совершенно бесценны, как ревьювер! Ведь вещи, которые другим разработчикам могут казаться «очевидными», для вас таковыми не являются. При этом делать code review сравнительно просто. Как минимум, нужно проверить, что код действительно делает то, что нужно, ничего не ломает, проходит все тесты и сам покрыт тестами, не сыпет ворнингами при компиляции, хорошо документирован, оформлен в соответствии с принятым в проекте code style, не ломает обратную совместимость, и не содержит явных ошибок (например, утечки ресурсов). Что интересно, читая чужой код, вы быстро разберетесь во внутреннем устройстве проекта. Не бойтесь пропустить какие-то ошибки. Коммиттер, а также другие ревьюверы, прекрасно понимают, что вы работаете над проектом недавно, и в любом случае перепроверят за вами.
• Исправление багов. На какие-то баги вы можете налететь сами. Особенно, если проект, над которым вы работаете — это библиотека. Но куда большие багов обычно репортят другие пользователи проекта. Проверьте багтрекер. Найдите первый понравившийся баг и попытайтесь его воспроизвести. Если не получается, постарайтесь выяснить у багрепортера детали. Может оказаться, что баг не воспроизводится или даже уже был исправлен. Закрыв тикет без какого-либо исправления, вы тоже окажете помощь проекту. Еще в поиске багов вам могут помочь санитайзеры и статические анализаторы кода.
• Оптимизация. Обычно это халява, так как в сущности от вас требуется переписать код, чтобы он делал то же самое, только быстрее. Правда, чтобы найти настоящее «бутылочное горлышко», нужно не просто придумать синтетический бенчмарк, а иметь какую-то реальную и достаточно большую нагрузку. Само собой разумеется, выполнение оптимизации потребует от вас хорошего владения средствами профилирования кода.
• Тесты. Печально, но факт — тесты программисты писать тоже не любят. Определите степень покрытия кода тестами, найдите непокрытые участки кода, напишите для них тесты. Удивительно, но многие программисты не понимают разницу между модульными и интеграционными тестами и никогда не слышали про property-based тесты. Если в проекте нет одного из этих видов тестов, предложите патч, который его добавляет.
• Документация. А еще программисты часто не любят писать документацию. Проверьте, нет ли белых пятен в официальной документации или man-страницах проекта. Бывает еще так, что в документации есть несостыковки, устаревшая информация, или просто битые ссылки. Возможно, документацию можно улучшить, добавив в нее наглядных примеров.
• Рефакторинг. В любом достаточно старом проекте есть места, которые можно переписать чуть лучше, чем они написаны сейчас. Большой файл с исходным кодом можно разбить на несколько, десяток параметров, передаваемых процедуре, можно объединить в одну структуру, и так далее. Важно, чтобы код не только решал стоящую перед ним задачу, но и был при этом читаемым!

Если позволите, хотелось бы дать еще пару советов. (1) Чем меньше ваш патч, чем больше шансов, что его примут. В частности, «заодно» подправлять отступы в не связанных с вашим патчем местах — очень плохая идея. (2) На первых порах любая прихоть коммиттера для вас — закон. Если коммиттер просит вас что-то исправить в патче, просто сделайте это, даже если ваши предпочтения не совпадают с предпочтениями коммиттера. Спор с ним попросту ни к чему не приведет. (3) Будьте предельно вежливы, используйте как можно больше слов please, thank you, и так далее. Любая грубость, троллинг, сарказм и так далее совершенно недопустимы!

Также не забывайте, что контрибьютить можно не только в виде патчей. Отвечать на вопросы в IRC и пользовательском списке рассылки, дополнять и исправлять wiki-сайт проекта, освещать новости проекта в своем блоге (можно создать рассылку ProjectName Weekly, если ее еще нет), писать обучающие статьи или, возможно, даже книги, посвященные проекту, организовать локальные юзергруппы, и так далее — все это тоже очень важные вклады в развитие проекта!

А контрибьютите ли вы в open source проекты и если да, то в какие, и каким образом?