Как ввязаться в большой opensource-проект?

Для начала стоит отлично разобраться во всех возможностях, фичах и «закоулках» проекта на уровне пользователя через документацию и, возможно, исходники. Это необходимая база.

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

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

Привить себе привычку постоянно лезть в исходники проекта на пару уровней глубже, чем stable API.

(Возможно коммент Кэпа. Личное мнение человека, отправившего несколько скромных патчей в Yii.)

Я советую для изучения Chrome/Chromium. Почему? Потому, что у него грамотно организованный код и есть design documents — описание архитектуры и устройства отдельных компонент. вот, смотрите: www.chromium.org/developers/design-documents/. Также, там применяется много технических хитростей.

Если вам, к примеру, интересно узнать, как работает композитинг (и аппаратное ускорение рендеринга), вы просто читаете соответствующий диздок и смотрите упомянутые там классы.

Если вам вообще интересна не какая-то часть продукта, а общее устройство — ищите главный файл приложения и функцию main() и вперед… несколько дней, проведенных в изучении путей вызова функций помогут вам составить представление о работе ПО.

Естественно, по ходу разбирания в коде вам могут понадобиться мануалы, например заглядывать в MSDN для подробностей функий WinAPI, документацию внешних библиотек, возможно, еще что-то. Если речь о С++ (а в Хроме он используется), вам также полезно укрепить знания этого языка, пролистав Страуструпа и почитывая C++ FAQ (я не помню ссылки, найдите сами в Гугле, но любой уважающий себя С++ разработчик должен знать то, что там написано, так как С++ на редкость богат возможностями выстрелить себе в ногу).

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

Ок, допустим Хром вам неинтересен, вы хотите залезть в ядро Линукса. Опять же, гуглите диздоки и все, что на них похоже, например, во многих проектах это называется Hacker's manual/hackers reference — там обычно описывается общая структура проекта и какой модуль за что отвечает.

Говоря кратко, ядро Линукса состоит из отдельных подсистем, каждая из которых управляет набором таблиц и списков (таблица процессов, список открытых файлов, список страниц памяти). Изучать его проще всего, взяв системный вызов, например fopen() или kill() или fork() и посмотрев, какой код вызывается в ходе его выполнения. Обычно это проверки прав пользоателя, проверка состояния процеса, вызов хуков, и, наконец, самое главное — модификация каких-нибудь таблиц, например добавление сигнала в очередь процесса.

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

Но и как в случае с хромом, потратив определенное время на изучение кода и документации, понимание его устройства придет само собой.

Вот, например, сходу нагуглилось: tldp.org/LDP/tlk/tlk.html (старый документ), www.kernel.org/doc/htmldocs/kernel-hacking.html (не очень старый). Также, в дереве исходников ядра есть папка с говорящим названием documentation, также там разбросаны файлы readme.

Ввязываться в такой проект, если это старт, не надо. Потому что там уровень и полиси могут быть наработанные. В таких проектах, во-первых, стоит участвовать, если чувствуется уверенность в себе, как технические скиллы, так и психологические. Лучше выбрать более-менее средний, и начать с него.
В чтении кода проекта особо сложного нет, обычно. Просто повторюсь — большие проекты имеют свои полиси, стили кодирования, стили названия файлов, вплоть до классов и функций. Отчасти чтение «сразбегу» такого кода не то что запутывает — надо знать / изучить стиль проекта. Как пример _большого_ проекта — Samba.

Для примера — сам линукс-кернел. Кода — очень много. И даже примерно понимать все основные принципы, как они реализованы внутри (и как происходит фильтрование в netfilter и как создается файл в fs) — задачка непростая. Но он делится на однообразные куски. Например, драйвера сетевых карт — сотни карт поддерживаются, все драйвера — очень похожи друг на друга. Прочитал (или даже написал) вдумчиво один драйвер и более-менее понял их всех, и получил общее представление о том, что там работает выше в ядре. Есть даже туториалы по написанию LKM и каких-то реальных и псевдо-драйверов — отличный способ начать. Аналогично с таржетами netfilter, с файловыми системами, queue discipline итд. Начинаете как раз с узкого куска, ищете туториалы (если они есть — не всегда), читаете исходники аналогичных модулей. В итоге сможете сделать один маленький кусок, и получите кое-какое смутное представление о тех частях ядра, которые сопряжены с ним.

К слову о ядре Linux — есть книжка Бовета и Чезати «Ядро Linux» (в английском варианте — Understanding The Linux Kernel). ИМХО — неплохое введение в общую архитектуру, основные идеи и «где что лежит».

Но, конечно, в случае ядра linux просто жизненно необходимо просто научиться программировать под linux, разобраться с системными вызовами, механизмами IPC и прочим, прежде чем лезть в само ядро