Как стать участником опенсорс-проекта, даже если не умеешь писать код?

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

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

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

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

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

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

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

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

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

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

Всякий раз, когда переписываешь код, не забывай, что ты работаешь в команде, поэтому делай все возможное, чтобы твой стиль совпадал со стилем, принятым в проекте. В противном случае это то же самое, что сказать: «Мне не нравится ваш стиль, вы должны делать так же, как я».

Приоритизируй баги

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

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

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

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

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

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

Пиши тесты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Делай дизайн

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

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

Чтобы подкрепить все наши слова фактами, мы собрали отзывы трех людей, которые получили профессиональный опыт в открытых проектах.

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

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

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

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

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

Попал в OpenVZ достаточно случайно. По работе занимался в основном прикладным программированием, практически не имеющим точек пересечения с системным. В какой-то момент приобрел свой первый 64-битный ноутбук (Acer с AMD Turion 64), ну и поскольку Windows 64-битной под руками не было, поставил Gentoo. С Linux до того момента знакомства практически не имел, так, поиграться ставил какой-то древний Red Hat, но он меня особо не впечатлил, да и для решения текущих рабочих задач эта операционка не подходила. Под Gentoo ноут более-менее работал, но некоторых драйверов не было в стандартной поставке ядра, так что пришлось собирать свое ядро из исходников.

Тут я и словил первый баг, правда, не в самом ядре, а в программе формирования конфигурации ядра. Порыскал по Сети — решения проблемы нет, ну и рискнул сам попробовать исправить. Оказалось, пришлось разбираться со множеством смежных задач (как собирается ядро, какие инструменты используются и прочее). Сделал патч, выслал в рассылку. К моему удивлению, мейнтейнеры ядра отнеслись очень благосклонно даже к такому «кривому» патчу (забегая вперед, скажу, что его пришлось переделать, так как патч был отвратительный, просто не стали сразу давать «от ворот поворот»), не было ни одного смешка в сторону новичка: объяснили, что и как, и показали, как делать правильно.

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

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

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

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

Я думаю, в моей истории ничего оригинального нет. Как это происходит обычно — начинаешь использовать какой-то софт, и внезапно оказывается, что хотелось бы, чтобы что-то в нем работало не совсем так, или чего-то не хватает, или есть противные косяки. В случае опенсорса есть возможность исправить это самому. Так было с оконным менеджером dwm, в котором меня раздражала конфигурация через config.h c перекомпиляцией: сначала я добавил конфиг через xrdb, потом click to focus и так далее. Такие изменения не соответствовали минималистичным гайдлайнам проекта, поэтому пришлось делать форк.

C DragonFly BSD примерно то же самое: завлекательные тексты на сайте звучали интересно, FreeBSD надоела, но внезапно оказалось, что там плохая поддержка языков, отличных от английского, и управления энергопотреблением (ACPI). Пришлось заняться портированием необходимых участков кода из более свежей версии FreeBSD. Сильно помогли другие разработчики c IRC-канала, объясняли, что к чему, и помогали разбираться с проблемами. Там я получил кое-какой опыт разработки ядра и системных библиотек. Еще удалось на этом заработать немного денег — нашелся человек из Москвы, который использовал DragonFly BSD в продакшене и тоже что-то там хотел подкрутить в ACPI. Нашел меня через git log, связался по почте.

В OpenBSD я только по мелочи какие-то патчи кидал — в cwm что-то допиливал для удобства (в wm’ах-то я уже был спец), в ksh поправил пару косяков и улучшил vi mode. В этом проекте отношение к новым контрибьюторам не самое лучшее — предполагается, что ты самостоятельно во всем разберешься и только после этого будешь писать в рассылку. Порог вхождения высокий, выживают только самые стойкие, зато код получается хороший.

Еще я участвовал в 9front: доработал драйвер для Wi-Fi и уже знакомый мне ACPI. У них, наверное, самая маленькая работающая реализация интерпретатора AML. Да и само ядро довольно компактное (в сравнении с «нормальными» ОС), поэтому разбираться проще. Хвастался этим на собеседовании, насколько помогло (или наоборот) — не знаю.

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