14 способов сделать первый шаг в open source

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

• «Я не очень хороший программист».
• «У меня недостаточно времени, чтобы этим заниматься».
• «Я не знаю, каким проектом заняться».

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

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

Наиболее распространенное заблуждение у новичков в том, что они считают, что для участия в open source-проектах необходимо быть настоящим «гением программирования». Но это совсем не так. Безусловно, в мире open source-разработки есть свои гуру, однако далеко не все. Большинство из них – обыкновенные разработчики, которые всего-навсего хорошо делают свою работу, независимо от того, насколько малый или большой вклад они вносят в проект. И далеко не всегда эта работа связана с программированием. Работа над open source-проектами в основном заключается в рутинном исполнении текущих задач. Большая часть задач, которые получают разработчики, не требует гениального видения проблемы, как у Ларри Уола, создателя Perl, или Дэвида Хейнемейера Ханссона, основателя Rails. Создание нового языка программирования или фреймворка, конечно, требует вдохновения, но остальная часть работы, которая и делает такие проекты, как Perl или Rails, успешными, требует постоянных рутинных усилий. Эти усилия едва ли могут принести вам славу, но они, безусловно, нужны и важны, и рано или поздно ваш вклад будет замечен.

Внимательно слушайте

Все стадии работы в open source-проектах так или иначе связаны с людьми, которые в них задействованы. Вы присоединяетесь к команде, а это значит, что необходимо понимать, как устроены процессы и взаимодействие между всеми ее участниками. Прийти в команду со своим видением ситуации и навязывать всем свою точку зрения - не самый удачный вариант. Для некоторых проектов такой подход может быть приемлемым, но если над продуктом работают уже не один месяц, шансы на то, что ваши идеи воспримут с энтузиазмом, очень невелики. Прислушиваться к мнению и точке зрения коллег – это, пожалуй, лучший способ понять, что необходимо проекту на текущей стадии. 1. Присоединяйтесь к рассылке. На многих проектах e-mail-рассылка является основным способом коммуникации. На крупных проектах обычно есть несколько списков рассылки. Например, на проекте PostgreSQL используют не менее 12 рассылок, касающихся обсуждения вопросов пользовательского интерфейса, а также 6 рассылок для разработчиков. Оптимальный вариант – следить за основными рассылками в каждой из групп, чтобы начать вникать в основные текущие вопросы. 2. Следите за блогом. Блоги, которые ведут ведущие разработчики, могут быть весьма полезны, поскольку будут информировать вас об изменениях и улучшениях в грядущем релизе. Существуют специализированные порталы со словом “planet” в названии, которые аккумулируют новости и посты из блогов с различных ресурсов, связанных с проектом. Найти такой ресурс можно, отправив поисковой запрос типа “planet ”в Google. 3. Добавляйтесь в чат. Во многих open source-проектах для обсуждения текущих вопросов используются групповые чаты. Поэтому не забудьте выяснить, как общаются между собой участники вашего проекта.

Работайте с “тикетами”

Безусловно, код – это основа любого open source-проекта, но не стоит полагать, что написание кода – это единственный способ участия в проекте. Технической поддержке зачастую уделяют недостаточно внимания в погоне за созданием новых функциональных возможностей и исправлением ошибок. А ведь именно это и есть те области, которые позволяют новичкам войти в проект. Большинство проектов имеют общую открытую систему работы с “тикетами”, которая связана с веб-сайтом проекта и включена в документацию. Подобная система – это основной источник коммуникации между разработчиками и пользователями. Постоянная работа с текущими запросами – это отличная возможность внести свой вклад в проект. Для работы с системой могут понадобиться специальные права доступа, которые вам предоставит тим лид, как только вы решите заняться текущими запросами от пользователей. 4. Находите баги. В проектах с открытым исходным кодом баги часто проходят незамеченными. Обнаружение и сортировка багов может значительно сэкономить время разработчикам на поиск проблемы. Если пользователь пишет: «Программа не работает, когда я делаю такие-то шаги», - не поленитесь разобраться в том, чем вызвана эта проблема. Проблема повторяется? Вы можете вызвать эту проблему, повторив ряд конкретных шагов? Вы можете сузить круг проблемы до конкретного браузера или дистра? Даже если вы не знаете истинную причину проблемы, попытки сузить круг возможных причин во многом помогут разработчикам справиться с ней. Независимо от того, что вам удалось выяснить, добавьте свои комментарии к багу, чтобы все могли с ними ознакомиться. 5. Закрывайте старые баги. Нередко случается, что баги «пофиксили», но «тикет» не закрыли. Таким образом, система «засоряется» старыми багами, которые мешают работать с актуальными проблемами. «Очистка» системы трекинга от старых багов – это скучная и длительная процедура, но она очень важна для всего проекта. Для начала отфильтруйте «тикеты» по дате, например, старше, чем один год, и посмотрите, существуют ли такие баги. Просмотрите логи по релизам и убедитесь, что эти баги устранили и их можно закрыть. Если баг исправили, необходимо добавить комментарий с упоминанием версии, в которой баг был устранен, и закрыть его. Постарайтесь воссоздать баг в последней версии продукта. Если его невозможно воспроизвести, сделайте соответствующую запись и закрывайте «тикет». Если баг продолжает повторяться, укажите это в «тикете» и оставьте его открытым.

Работайте с кодом

Все программисты, работающие на проекте, независимо от опыта и квалификации, могут помочь вам с кодом. Не думайте, что вам необходимо быть гением, чтобы начать работать над проектом. Если ваша работа связана с изменением кода, изучите методы изменения кода, которые используются на проекте. Для каждого проекта характерны свои внутренние технические процессы, поэтому узнайте о них побольше, прежде чем предложить ваш вариант кода. Например, на проекте PostgreSQL жестко регламентированы все процессы: изменения в коде отправляются в виде патча в рассылке всем основных разработчикам, которые тщательно изучают все изменения. С другой стороны, есть и другие типы проектов, как, например, Parrot, где программисты могут «коммитить» все изменения непосредственно в базу. Если на проекте используется GitHub, возможно, процессы поставлены через pull request’ы, т.е. запросы на включение сделанных изменений. Помните: нет двух одинаковых проектов. Всякий раз, когда вы переписываете код, не забывайте, что вы работаете в команде и поэтому делайте все возможное, чтобы ваш стиль совпадал с общей базой, используемой в проекте. Часть кода, которую вы добавляете или меняете, не должна выбиваться из общего кода. У вас могут быть свои предпочтения в оформлении кода, но ваш код должен соответствовать общим стандартам, принятым на проекте. В противном случае это то же самое, что сказать: «Мне не нравится ваш стиль, и я думаю, что мой лучше, поэтому вы должны делать так, как я». 6. Тестируйте бета-версии. В любом проекте, который создается для работы на нескольких платформах, могут возникать проблемы, связанные с переходом на другую платформу. Накануне нового релиза, когда выходит новая бета-версия, руководители проектов ожидают, что они будут протестированы на различных платформах. Вы можете принять участие в тестировании и убедиться, что продукт работает на той или иной платформе. Как правило, вам необходимо собрать и установить новый «билд» и протестировать продукт, но особенно значимо для проекта, если вы используете нестандартные аппаратные средства. Если вы подтвердите, что «билд» работает и при таких условиях, это существенно облегчит задачу руководителей проекта в определении текущего статуса релиза. 7. Исправляйте баги. Обычно с этого начинается работа новичков с кодом. Здесь всё просто: найдите «тикет», в котором описывается какой-нибудь баг и попробуйте устранить его в коде. Подтвердите изменение в документации (если необходимо). Неплохо также добавить тест для тестирования той части кода, которую вы исправили; некоторые проекты требуют, чтобы все баг-фиксы сопровождались соответствующими тестами. Ведите записи, по мере того как вы осваиваете незнакомый код. Даже если вы не можете справиться с багом, опишите в тикете, что вам удалось о нем выяснить. Это поможет тем участникам команды, кто будет работать с багами после вас. 8. Пишите тесты. В большинстве проектов используются тестовые комплексы, предназначенные для тестирования кода, но сложно представить себе такой комплекс, который бы не предусматривал возможности добавления в него новых тестов. Используйте такие тестовые инструменты, как gcov для C или Devel::Cover для Perl, чтобы установить те области исходного кода, которые нельзя протестировать готовым тестовым комплексом. Затем добавьте соответствующий тест, чтобы иметь возможность протестировать необходимый функционал. 9. Отключайте оповещения компилятора. Часто «билд» проектов на С сопровождается многочисленными оповещениями компилятора. Такое сообщение не всегда говорит об ошибке, но заставляет отвлекаться. Проверьте, возможно, в коде скрыт какой-то баг. Если же багов нет, отключайте ложные оповещения. 10. Добавляйте комментарии. Когда вы просматриваете код, вам могут встретиться отдельные запутанные участки. Если какой-то кусок кода привел вас в недоумение, то велика вероятность того, что и у других он вызовет такую же реакцию. Опишите эту проблему в документации и отправьте патч.

Работайте с документами

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

Работайте в команде

Работа в open source-проектах только отчасти связана с кодом. Настоящий успех проекту приносит команда. И вы можете помочь созданию сплоченной команды. 12. Отвечайте на вопросы. Лучший способ сплотить команду – это помогать другим. Для дальнейшего успеха проекта особенно важно отвечать на вопросы, в частности, на вопросы новичков. Это время не будет потрачено зря, даже если новичок задает вопрос, на который можно найти ответ, перечитав необходимую документацию. Кроме того, вы получите нового благодарного и активного участника своей команды. Все с чего-то начинают, а любому проекту необходим постоянный приток кадров, чтобы он продолжал развиваться. 13. Ведите блог. Если у вас есть блог, делитесь своим опытом, который вы получили на проекте. Расскажите о проблемах, с которыми вы столкнулись при использовании софта, и как вам удалось их решить. Таким образом, вы сможете убить двух зайцев сразу: поддержать внимание к проекту своих коллег и создать полезную базу информации для тех, кто присоединится к проекту в будущем и будет искать в сети ответы на уже описанные вами вопросы. (Блог, рассказывающий о ваших технических достижениях и изысканиях – это также отличный способ поделиться реальным опытом разработки и решения технических проблем, который может вам пригодиться при поиске новой работы). 14. Уделяйте внимание вебсайту. Большинство программистов, к сожалению, не самые лучшие дизайнеры, поэтому едва ли найдется проект, при разработке которого не прибегали дополнительно к помощи дизайнеров. Если вы талантливый веб-дизайнер и можете помочь улучшить вебсайт, а, следовательно, и представление проекта для пользователей, именно на это вам и следует направить свои усилия. Возможно, сайту необходим редизайн или собственный логотип. Именно эти умения могут требоваться в вашей команде. Многим руководителям команды на проектах не хватает именно таких креативных дизайнеров. И самое главное: прислушивайтесь к словам ваших коллег. Возможно, вам удастся помочь им в решении насущной проблемы. Так, например, недавно разработчики Parrot в процессе обсуждения в рассылке решили использовать GitHub в качестве системы работы с «тикетами» вместо прежней системы Trac. Некоторые были против этого перехода, поскольку не было возможности перенести существующие «тикеты» в новую систему. После дня обсуждения всех «за» и «против» один из разработчиков предложил написать программу-конвертер, чем и привлек к себе внимание. Через некоторое время программа была готова, и всю историю из более 450 «тикетов» удалось сохранить. В любом проекте всегда есть возможность найти для себя работу, и на open source-проектах таких возможностей множество. Нужно только суметь найти правильное применение своим способностям. Источник: 14 Ways to Contribute to Open Source without Being a Programming Genius or a Rock Star by Andy Lester

16 лет dev.by — «дефолтный» источник информации о беларусском ИТ

Вы можете...