Анестезиолог Кон Коливас разработал собственную версию планировщика задач для Linux ядра, потому что существующая реализация была адаптирована под серверные задачи, но неудовлетворительно справлялась с пользовательскими задачами.

Алексей Кузнецов, который по воле случая «превратился» в Linux хакера, сменил свою профессию с физика-теоретика на системного программиста.

ИТ-журналист Пётр Семилетов помимо своей основной работы уже десять лет разрабатывает свой текстовый редактор Tea с открытым исходным кодом.

Леся Новасельская, получившая специальность паталогоанатома, участвует в тестировании проекта c открытым исходным кодом.

Подобных примеров множество. Всех этих людей объединяет одно — они реализовали свои интересы в проектах с открытым исходным кодом и участвовали в них и для удовольствия, и для получения опыта. Сложился некий миф о том, что открытый проект – это только для программистов, причем тех, у кого уже есть большой опыт в разработке. Но это не так. Открытый проект — это не только разработка исходного кода, но и тестирование, техническая поддержка, написание документации, маркетинг и т.д. А ещё — отличный шанс приобрести опыт и получить удовольствие от общения с такими же единомышленниками, как вы. Согласно результатам голосования основным препятствием для участия в открытом проекте является отсутствие понимания того, как присоединиться к проекту. Поэтому в статье мы разберёмся как и в качестве кого можно присоединиться к такому проекту.

Пишите новый код

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

Для каждого проекта характерны свои внутренние технические процессы, поэтому узнайте о них побольше, прежде чем предложить свой вариант. Например, на проекте PostgreSQL жёстко регламентированы все процессы: изменения в коде отправляются в виде патча в рассылке всем основных разработчикам, которые тщательно изучают все изменения. С другой стороны, есть и другие типы проектов, как, например, Parrot, где программисты могут «коммитить» основной репозиторий. Если на проекте используется GitHub, возможно, процессы поставлены через pull request’ы, т.е. через запросы на включение сделанных изменений. Помните: нет двух одинаковых проектов. Всякий раз, когда вы переписываете код, не забывайте, что вы работаете в команде, поэтому делайте всё возможное, чтобы ваш стиль совпадал со стилем, принятым в проекте. Часть кода, которую вы добавляете или меняете, не должна выбиваться из общего кода. У вас могут быть свои предпочтения в оформлении кода, но ваш код должен соответствовать общим стандартам, принятым в проекте. В противном случае это то же самое, что сказать: «Мне не нравится ваш стиль, и я думаю, что мой лучше, поэтому вы должны делать так, как я».

Приоритезируйте дефекты

Безусловно, код – это основа любого открытого проекта, но его написание – не единственный способ участия в нём. Технической поддержке зачастую уделяют недостаточно внимания в погоне за созданием новых функциональных возможностей и исправлением ошибок. А ведь именно это и есть те области, которые позволяют даже новичкам войти в проект.

Например, у проекта OpenVZ есть полностью открытая система работы с дефектами — bugs.openvz.org, где собраные все известные (исправленные и неисправленные) проблемы за всё время существования проекта (без малого десять лет). Багтрекер – один из механизмов коммуникации между разработчиками и пользователями. Постоянная работа с текущими запросами даёт отличную возможность внести свой вклад в проект. Для работы с системой вам могут понадобиться специальные права доступа, которые вам предоставит менеджер проекта, следуя принципам меритократии.

Тестируйте промежуточные версии

Опрос в сообществе тестировщиков ПО показал, что интерес к тестированию ПО с открытым исходным кодом со стороны профессиональных тестировщиков есть. Многие хотели бы поучаствовать в таких проектах, но не знают с чего начать. В свою очередь в любом проекте (даже в коммерческом) всегда есть недостаток тестировщиков. Обнаружение и сортировка багов может значительно сэкономить время разработчикам на поиск проблемы. Если пользователь пишет: «Программа не работает, когда я делаю такие-то шаги», — не поленитесь разобраться в том, чем вызвана эта проблема. Проблема повторяется? Вы можете продемонстрировать её, повторив ряд конкретных шагов? Сузить круг проблемы до конкретного браузера или дистрибутива? Даже если вы не знаете истинную причину проблемы, попытки сузить круг возможных причин во многом помогут разработчикам справиться с ней. Независимо от того, что вам удалось выяснить, добавьте свои комментарии к багу, чтобы все могли с ними ознакомиться.

По своему опыту могу сказать, что у открытых проектов не хватает ресурсов хорошо протестировать новую функциональность. Поэтому перед тем как добавлять серьёзные изменения в основную ветку репозитория исходного кода проект старается привлечь как можно больше людей для тестирования. Такая практика так и называется — призыв к тестированию (call for testing). Ни один проект не обладает тем количеством аппаратных и программных конфигураций, которые имеет сообщество этого проекта. Разработчики проекта OpenBSD анонсируют появление новой функциональности в новостях, чтобы привлечь внимание тестировщиков и пользователей к ней. То же самое мы делаем и в проекте OpenVZ — публикуем список новой функциональности, доступной для тестирования.

Вы можете принять участие в тестировании и убедиться, что продукт работает на той или иной платформе. Как правило, вам необходимо собрать и установить новый «билд» и протестировать продукт, но особенно значимо для проекта, если вы используете нестандартные аппаратные средства. Если вы подтвердите, что сборка работает и при таких условиях, это существенно облегчит задачу руководителей проекта в определении текущего статуса релиза.

Пишите тесты

В большинстве проектов используются программные комплексы, предназначенные для тестирования кода, но сложно представить себе такой комплекс, который бы не предусматривал возможности добавления в него новых тестов. Используйте такие тестовые инструменты, как gcov для C, чтобы установить те области исходного кода, которые нельзя протестировать имеющимися тестами. Затем добавьте соответствующий тест, чтобы иметь возможность протестировать необходимую функциональность.

Исправляйте баги и добавляйте новую функциональность

Патч с исправлением проблемы или добавляющий необходимую вам функциональность — это своего рода классический способ вовлечения в открытый проект (если помните, с этого началось вообще всё движение за свободное ПО). Этот способ рекомендует и Джеймс Боттомли, CTO Virtuozzo, тем, кто хочет принять участие в Linux-проекте, но не знает, как. Обычно он приводит в пример случай, когда у него возникла необходимость в изменении функциональности SIP клиента в Android. Он обнаружил отсутствие необходимой функциональности, сделал патч и отправил в проект SIPdroid.

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

Помогайте поддерживать инфраструктуру проекта

Вам интересна область DevOps? Это направление сейчас очень популярно. Хороших инженеров DevOps очень трудно найти, мы это знаем на собственном опыте. Получить опыт можно в проектах, в которых ведётся открытая разработка инфраструктуры. Это такие проекты как Wikipedia, проект Fedora Linux. OpenVZ только делает первые шаги в этом направлении.

Настройка процесса непрерывной интеграции для компонентов проекта, пакетирование компонентов для Linux дистрибутивов, автоматическая настройка окружения разработчика, — всё это тоже задачи DevOps.

Пишите и переводите документацию

Ведение документации – рутинная составляющая любого проекта, которой зачастую пренебрегают. Кроме того, проблемы с документацией часто могут быть вызваны тем, что она написана с точки зрения людей, хорошо знакомых с проектом, а не тех, кто только знакомится с ним. Если при чтении документации по проекту вас когда-нибудь посещала мысль: «Такое ощущение, что её написали так, как будто я уже знаю, как пользоваться программой», то вы понимаете, о чем речь. Очень часто новый взгляд со стороны позволяет выявить недостатки в текущей документации, которые могут не заметить непосредственные участники проекта. К тому же в динамично развивающихся проектах документация быстро устаревает и её требуется поддерживать в актуальном состоянии.

Если вы по какой-то причине думаете, что заниматься этим «несерьёзно», то вы ошибаетесь. Нет «серьёзного» или «несерьёзного» вклада в открытый проект. К примеру, разработчик OpenBSD (в то же время и сотрудник CERN) Инго Шварц (Ingo Schwarze) написал утилиту mandoc, которая теперь используется для форматирования страниц документации не только в OpenBSD, но и в FreeBSD, NetBSD, DragonFlyBSD и попутно привёл в порядок форматирование существующих страниц документации в проекте. Об этом он рассказывал на BSDCan 2015. Так что все зависит от того, что интересно вам. Если интересно — беритесь и делайте!

Помогайте другим пользователям с их проблемами

Лучший способ сплотить команду – это помогать другим. Для дальнейшего успеха проекта особенно важно отвечать на вопросы, в частности, на вопросы новичков. Это время не будет потрачено зря, даже если он задает вопрос, на который можно найти ответ, перечитав необходимую документацию. Кроме того, вы получите нового благодарного и активного участника своей команды. Все с чего-то начинают, а любому проекту необходим постоянный приток кадров, чтобы он продолжал развиваться.

Рекламируйте любимый проект

Если у вас есть блог, делитесь своим опытом, который вы получили в проекте. Расскажите о проблемах, с которыми вы столкнулись при использовании ПО, и как вам удалось их решить. Таким образом, вы сможете убить двух зайцев сразу: поддержать внимание к проекту своих коллег и создать полезную базу информации для тех, кто присоединится к нему в будущем и будет искать в сети ответы на уже описанные вами вопросы. Блог, рассказывающий о ваших технических достижениях и изысканиях – это также отличный способ поделиться реальным опытом разработки и решения технических проблем, который может вам пригодиться при поиске новой работы. Во многих проектах есть агрегаторы записей из блогов участников проекта, традиционно их называют «планетами»: планеты OpenVZ, Linux kernel, Perl, Freedesktop, Gnome, Debian и т.д. Записи увлечённых своим делом людей могут быть интересны даже если вы никак не связаны с проектом.

Делайте дизайн

Дизайн — это бич большинства открытых проектов. Скучные сайты, невзрачные логотипы сопровождают проекты просто потому что технические люди в основном зациклены на реализации, а не на том, как это должно выглядеть. Поэтому участие дизайнеров крайне приветствуется. Пользователи сайта StackExchange попробовали ответить на вопросы «как графический дизайнер может внести вклад в открытый проект», «чем должен мотивироваться дизайнер для участия в открытом проекте», но мнения их разошлись. Дизайнеры из компании RedHat также осознали необходимость более активного участия дизайнеров в открытых проектах и попробовали создать сайт, который поможет открытым проектам и дизайнерам найти друг друга, но о фактах успешного применения проекта я пока не слышал.

Ищите задачи, которые интересны вам и полезны проекту и пытайтесь их решить. Способы участия в проекте могут отличаться от проекта к проекту, поэтому отличным стартом могут быть страницы с описанием вариантов участия в проекте: OpenStack, OpenVZ, FreeBSD и т.д. Сам факт того, что у проекта есть такая страница говорит о том, что он открыт для участия других людей.
Чтобы подкрепить все наши слова фактами мы собрали отзывы трёх людей, которые получили профессиональный опыт в открытых проектах:

Александр Юрченко, разработчик в компании Яндекс:

На свою первую серьезную работу за деньги (разработчик встраиваемых систем) я пришел уже будучи больше года официальным разработчиком ядра бесплатной операционной системы OpenBSD. Официальным – в смысле у меня был доступ на запись в репозиторий. А до этого еще с год я был «зрителем», присылающим патчи разработчикам.

Должен сказать, что участие в подобном проекте дает колоссальный опыт. В хорошем крупном opensource проекте есть все, что обычно требуют от разработчика на собеседовании: и грамотное проектирование, и хорошее кодирование, и навык работы с системой контроля версий и баг-трекером, а так же peer review, работа в команде и т.д. и т.п. Таким образом, «поварившись» год-другой в такой атмосфере, можно запросто вырасти до уровня, который соответствует позиции Senior developer.

Собственно, со мной так и было. Я не имел никакого формального опыта работы (по трудовой), но меня сразу взяли старшим разработчиком. А после первой недели испытательный срок был уменьшен с трех месяцев до нуля :)

Кирилл Горкунов, разработчик проектов OpenVZ и CRIU:

Попал в OpenVZ достаточно случайно. По работе занимался в основном прикладным программированием, практически не имеющим точек пересечения с системным. В какой-то момент приобрел свой первый 64-х битный ноутбук (Acer с AMD Turion 64), ну и поскольку Windows 64 битной под руками не было, поставил Gentoo. С Linux до того момента знакомства практически не имел, так, поиграться ставил какой-то древний RedHat, но особо не впечатлил, да и для решения текущих рабочих задач эта операционка не подходила. Под Gentoo ноут более-менее работал, но некоторых драйверов не было в стандартной поставке ядра, так что пришлось собирать свое ядро из исходников. Тут я и словил первый баг, правда, не в самом ядре, а в программе формирования конфигурации ядра. Порыскал по сети — решения проблемы нет, ну и решил сам попробовать исправить. Оказалось, пришлось разбираться с множеством смежных задач (как собирается ядро, какие инструменты используются и т.п.). Сделал патч, выслал в рассылку. К моему удивлению, мэйнтейнеры ядра отнеслись очень благосклонно даже к такому «кривому» патчу (забегая вперед, скажу, что пришлось переделать, так как патч был таки отвратительный, просто не стали сразу давать “от ворот поворот”), но не было ни одного смешка в сторону новичка: объяснили что и как, и показали как делать правильно.

Дальше заинтересовало само ядро — как работает, какие алгоритмы используются. В этом отношении “открытость” проекта оказывает неоценимую услугу: можно посмотреть как решаются те или иные задачи (не какие-то теоретические, а реальные). Нередко возникал вопрос “а почему так, а не эдак”, и вот тут крайне полезно иметь обратную связь с автором кода. Открытые списки рассылки не только позволяют спросить у разработчиков “что и как”, но, что более важно, служат чем-то вроде базы знаний — всегда можно поискать в архивах обсуждения проблем и методы их решений.

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

Примерно так было и со мной: несколько лет правил что-то в коде, высылал патчи, получал по рукам за кривой код, ну и одобрения, если патч был правильным и красивым. Такой опыт фактически бесценен. И можно быть уверенным, если у тебя начинает что-то получаться, то тут же появятся предложения о работе. Я так и пересекся с разработчиками Linux ядра из OpenVZ. Ну а дальше решили работать вместе над OpenVZ ядром и смежными программами, не забывая конечно и о ванильном ядре.

Открытость проекта — чрезвычайно важное подспорье при обучении практическому программированию, но надо понимать, что проект проекту рознь, и открытость сама по себе абсолютно не гарантирует качества кода (если закачать свой код на гитхаб, он не становится от этого хорошим кодом). Равно как и обратное — закрытый код не является априори хорошим или безопасным.

Александр Поляков, разработчик

Я думаю в моей истории ничего оригинального нет. Как это происходит обычно — начинаешь использовать какой-то софт и внезапно оказывается, что хотелось бы чтобы что-то в нем работало не совсем так или чего-то не хватает, или есть противные косяки.
В случае опенсорса есть возможность исправить это самому. Так было с оконным менеджером dwm, в котором меня раздражала конфигурация через config.h c перекомпиляцией: сначала я добавил конфиг через xrdb, потом click to focus и т.д. Такие изменения не соответствовали минималистичным гайдлайнам проекта, поэтому пришлось делать форк. C DragonFlyBSD примерно то же самое: завлекательные тексты на сайте звучали интересно, FreeBSD надоела, но внезапно оказалось, что там плохая поддержка языков, отличных от английского, и управления энергопотреблением (ACPI). Пришлось заняться портированием необходимых участков кода из более свежей версии FreeBSD. Сильно помогли другие разработчики c IRC-канала, объясняли что к чему и помогали разбираться с проблемами. Там я получил кое-какой опыт разработки ядра и системных библиотек. Ещё удалось на этом заработать немного денег — нашёлся человек из Москвы, который использовал DragonFlyBSD в продакшене, и тоже что-то там хотел подкрутить в ACPI и драйвер какого-то рейда (вроде). Нашел меня через git log, связался по почте.
В OpenBSD я только по мелочи какие-то патчи кидал — в cwm что-то допиливал для удобства (в wm'ах то я уже был спец), в ksh поправил пару косяков и улучшил vi mode. В этом проекте отношение к новым контрибьюторам не самое лучшее — предполагается что ты самостоятельно во всем разберёшься, и только после этого будешь писать в рассылку. Порог вхождения получается высокий, выживают только самые стойкие, зато код получается хороший.
Ещё я в 9front участвовал: доработал драйвер для WiFi и, уже знакомый мне, ACPI. У них наверное самая маленькая работающая реализация интерпретатора AML. Да и само ядро довольно компактное (в сравнению с «нормальными» ОС), поэтому разбираться проще. Хвастался этим на собеседовании, насколько помогло (или наоборот) — не знаю.

Ну вот так вот можно получить опыт в открытых проектах. Главное не бояться присылать кривой код (бывает у всех), сохранять спокойствие (когда его обругают) и выбирать проекты, которые тебе действительно интересны. И опыт получишь и удовольствие. Ещё есть шанс, что работодатель сам тебя найдет по коммитам или профилю в гитхабе (Привет, Гугл!).