Как найти open source проект - Исправление недочетов и поиск решений вместе с Examum.ru

Как поучаствовать в разработке Open Source проектов, какова их роль и что они могут дать вам как разработчику?

Начнём с того, что гордое название «Open Source» носят проекты с открытым исходным кодом, которые чаще всего разрабатываются и поддерживаются силами сообщества. Это значит, что устройство и принцип работы таких проектов прозрачны, а в разработке может принять участие любой желающий.

Участие в Open Source проектах — это возможность усовершенствовать свои навыки, создавая при этом что-то новое или улучшая уже существующее. При этом не имеет значения, изучаете вы основы PHP или являетесь продвинутым C++ разработчиком — открытых проектов уйма, на любой вкус и цвет. Начинающие программисты могут не только пополнить багаж знаний, научиться работать с чужим кодом и получать фидбек от опытных программистов, но также пополнить портфолио первой серьёзной работой.

Разбираемся, как поучаствовать в Open Source проекте и не ударить в грязь лицом.

Тут всё зависит от ваших целей и задач. Кто-то начинает работать с Open Source, чтобы глубже изучить определённый технологический стек, кто-то — потому что сам использует тот или иной инструмент в работе и считает, что может его улучшить. Кто-то, как мы в ABBYY в случае с нашей библиотекой NeoML, сначала создаёт инструмент для решения внутренних задач, а потом понимает, что от его выхода в Open Source выиграет и компания, и сообщество. Есть разные пути — решите, какой из них больше подходит именно вам.

Работа в Open Source может дать много, если подойти к ней с умом. Навык чтения чужого кода здорово выпрямляет руки, работа с кураторами подтянет английский. А чувство, что вы приложили руку к крупному проекту (которых в Open Source достаточно), может неплохо смотивировать вас в карьерном плане.

Антон Немкин, председатель совета фонда Цифровая долина Сочи

Как найти Open Source проект?

Для участия в Open Source проекте самое главное — определиться со сферой собственных интересов. Это крайне важно, так как вам предстоит выбрать проект, максимально подходящий под ваши интересы и компетенции. Делается это просто. Крупнейший сайт с проектами — это Github. Там вы делаете поисковый запрос по ключевым словам, соответствующим интересам, например «javascript gamification framework». В ответ получаете список проектов, в каждом из которых вы можете поучаствовать.

Никита Буйда, основатель и ведущий разработчик Datebox.app

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

Новичку я бы посоветовал обратить внимание на GitHub Trending, где постят небольшие проекты.

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

Антон Немкин, председатель совета фонда Цифровая долина Сочи

На что обращать внимание при выборе проекта?

Обратите внимание на ПО, которым пользуетесь сами: во-первых, вы уже знакомы с проектом как пользователь и хорошо понимаете, что стоит улучшить или изменить; во-вторых, вы будете вносить вклад в то, что важно для вас.

Описание проекта — интересен ли он вам? Решает ли важную (интересную) проблему? Актуальна ли тема?

Популярность проекта. На Github это можно оценить по количеству звёзд — местному аналогу лайка.

Посмотрите на раздел с проблемами (issues): много ли там открытых и особенно закрытых проблем? Это поможет оценить простор для творчества.

Изучите часть описания проекта, относящуюся к сторонним разработчикам (contributing). Там, как правило, описывается простой способ, как настроить среду разработки под этот конкретный проект и прислать свои изменения. Иногда просто пишут «pull requests are welcome», то есть «ждём не дождёмся ваших исправлений и предложений».

Насколько давно были сделаны последние изменения в проекте, активно ли идёт разработка? Если да, то ваши изменения быстро рассмотрят и, возможно, примут. Если не активно — быть может, вы захотите взять продвижение проекта в свои руки?

Есть ли активное комьюнити? Часто у проекта может быть чат, форум или группа в соцсети, где разработчики активно обсуждают проект. Кроме того, активность можно посмотреть в комментариях к проблемам и предлагаемым изменениям.
Никита Буйда, основатель и ведущий разработчик Datebox.app

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

Илья Башилов, руководитель Frontend-направления SimbirSoft

Каковы особенности Open Source разработки?

В каждом Open Source проекте есть свои правила и ограничения для организации кода, построения архитектуры. Обычно всё это описывается в разделе contributing в README.md или в файле CONTRIBUTING.md (чаще всего находится в корне репозитория проекта).

Среди требований нередко встречается определённый код-стиль проекта, которого надо придерживаться.

Во многих проектах для каждого изменения требуется написание юнит-тестов. Без них изменения не принимаются.

Естественно, всё общение между участниками проекта ведётся на английском языке через систему pull-request, в специальных чатах или даже через email рассылки. Это также чаще всего описывается в разделе contributing.
Дмитрий Зайцев, эксперт по разработке ПО компании «Рексофт»

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

Каких Open Source проектов стоит избегать?

У проектов с открытым кодом есть и свои неприятные особенности:

Разработчик проекта может вести его в никуда. И такое бывает весьма часто! Если проект всё равно хорош, то вы можете сделать ответвление (fork) и разрабатывать его в правильном, по-вашему мнению, направлении.

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

Разработчик проекта может потерять интерес и забросить код. Это можно понять по количеству нерешённых проблем в репозитории и давним обновлениям кода.
Никита Буйда, основатель и ведущий разработчик Datebox.app

Что стоит сделать перед тем, как принять участие в Open Source проекте?

Основной инструмент для участия в Open Source проектах — это, конечно, система контроля версий Git. Поэтому в первую очередь стоит ознакомиться с ним. Также можете испытать возможности GitHub Copilot — инструмента, который помогает разработчикам писать код.

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

Илья Башилов, руководитель Frontend-направления SimbirSoft

А как быть с внесением изменений в проект?

Pull request — запрос на изменение кода в репозитории. Перед началом работы обязательно создайте свою ветку, в которую вы будете вносить изменения. Если речь идёт о master-ветке, любые изменения стоит вносить только после согласования с куратором проекта.

Отличной практикой будет предварительный показ вашей работы кому-нибудь, ведь вы могли что-то упустить или просто свернуть не туда. В этом случае вас могут попросить изменить что-либо в вашем PR.

Как начать свой Open Source проект?

Это ещё один ответ на вопрос, как поучаствовать в Open Source проекте: создайте его сами. Но для начала определитесь с целью, взвесьте все «за» и «против», убедитесь, что готовы взять на себя ответственность за труд других людей и уверенно двигаться к релизу.

Если начинать свой Open Source проект, то необходимо привлечь к нему внимание через англоязычные порталы. Самый простой вариант — публиковать ссылки на портале Reddit в нужных подразделах с тематикой «программирование». Это обеспечивает больший отклик, чем публикация на любом русскоязычном сайте. Естественно, стоит рассказать о проекте и на таких ресурсах, как Хабр, DTF и в тематических группах ВК.

Дмитрий Зайцев, эксперт по разработке ПО компании «Рексофт»

Источник

Как новичку поучаствовать в опенсорс разработке?

Время на прочтение
4 мин

Количество просмотров 38K

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

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

В наиболее общем виде ответ звучит так:

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

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

Какие открытые библиотеки, фреймворки или инструменты вы применяете чаще всего? Может, вы работаете с Grunt, Gulp, Webpack или Browserify, и вам кажется, что они могли бы быть улучшены или задокументированы точнее. Или, вероятно, вы применяете библиотеку React или модуль Angular – их тоже можно немного отполировать. Вы наверняка используете какое-либо опенсорс ПО — и его улучшение может вам в чем-то помочь.

Первые шаги

Как только вы определились с проектом, в котором будете участвовать, возникает второй вопрос: «А с какой стороны за него браться»? У многих проектов есть файл CONTRIBUTING. Заглянув в него, вы обнаружите инструкции по участию в проекте. Если отдельного файла нет, то соответствующие инструкции могут быть в README (обычно расположен на домашней странице проекта). А если нет ни того ни другого, то можно отправить пулл реквест на добавление хотя бы скелетного файла CONTRIBUTING.md, чтобы начать переговоры о добавлении полноценных инструкций.

Познакомьтесь с проектом ближе. Чтение документации это хорошо, но мне больше нравится узнавать проект по коду. Мой любимый способ – влезть в обращения к функциям через дебаггер. К примеру, что случиться, если обратиться angular.module?

Посмотрев код, вы поймёте многое о принципах работы библиотеки или фреймворка. То же самое вы можете делать и с локальными инструментами, используя ваш любимый отладчик узлов (или просто добавив console.logs). Не переживайте, если с ходу что-то останется непонятным. Не сдавайтесь — вам это под силу!

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

Если у вас есть собственные соображения об исправлении бага или фичи, которую вам хотелось бы претворить в жизнь, я настоятельно рекомендую сначала обсудить её с куратором(ами) на GitHub issue. Может они скажут, что она лежит вне сферы интересов проекта или уже находится в разработке, а может, подскажут, какого рода изменения они хотели бы видеть в программном коде. Вы потратите гораздо меньше времени, убедившись, что ваш пулл реквест будет принят, прежде чем браться за его оформление (точно также прежде чем сделать предложение своей жене, я сначала сделал все для того, чтобы ответ был “да”)

Ваш первый пулл реквест

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

Также вам может быть интересна серия постов о том, как участвовать в опенсорс проектах на GitHub: https://blog.kentcdodds.com/introducing-how-to-contribute-to-open-source-be67917eb704.

Дополнительные материалы

Загляните на GitHub’s issues в поисках тикетов, отмеченных first-timers-only, good for beginners, good first bug (или good-first-bug), или help wanted. Есть и другие ресурсы для поиска простых путей участия в проектах:

twitter.com/yourfirstpr
twitter.com/first_tmrs_only
24pullrequests.com
up-for-grabs.net/#
github.com/MunGell/awesome-for-beginners

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

Заключение

Мне очень нравится участвовать в опенсорс проектах, и я всячески советую испытать на себе этот опыт. Да, начать непросто, но после того как вы сделаете первый шаг все последующие будут даваться значительно легче. Конечно, не всегда всё идёт как по маслу. У опенсорс сообщества есть свои причуды. Не обращайте на них внимания, просто продолжайте работать. Всё обязательно получится! Удачи!

Пара слов от переводчика:

Хотел бы посоветовать ещё одну полезную статью Кента «Introducing: How to Contribute to Open Source». В ней упоминается его небольшой курс «How to Contribute to an Open Source Project on GitHub».

Источник

Как поучаствовать в разработке Open Source проектов, какова их роль и что они могут дать вам как разработчику?

Участие в Open Source проектах — это возможность усовершенствовать свои навыки, создавая при этом что-то новое или улучшая уже существующее. Начинающие программисты могут не только пополнить багаж знаний, научиться работать с чужим кодом и получать фидбек от опытных программистов, но также пополнить портфолио первой серьёзной работой.

Разбираемся, как поучаствовать в Open Source проекте и не ударить в грязь лицом.

Чем может быть полезен Open Source?

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

«Работа в Open Source может дать много, если подойти к ней с умом. Навык чтения чужого кода здорово выпрямляет руки, работа с кураторами подтянет английский. А чувство, что вы приложили руку к крупному проекту (которых в Open Source достаточно), может неплохо смотивировать вас в карьерном плане.»

Антон Немкин, председатель совета фонда Цифровая долина Сочи

Как найти Open Source проект?

«Для участия в Open Source проекте самое главное — определиться со сферой собственных интересов. Это крайне важно, так как вам предстоит выбрать проект, максимально подходящий под ваши интересы и компетенции. Делается это просто. Крупнейший сайт с проектами — это Github. Там вы делаете поисковый запрос по ключевым словам, соответствующим интересам, например «javascript gamification framework». В ответ получаете список проектов, в каждом из которых вы можете поучаствовать.»

Никита Буйда, основатель и ведущий разработчик Datebox.app

«Очевидный ответ, который напрашивается, — зайти на GitHub. Уже на месте стоит определиться с тематикой, хотя бы с точностью до крупной области. Затем погуглить, что есть на сайте на этот счёт. Новичку я бы посоветовал обратить внимание на GitHub Trending, где постят небольшие проекты. Начать просто: найдите проект, который вам по зубам, и предложите свои доработки. Вообще, нередко кураторы идут навстречу новичкам и охотно разъясняют, что упрощает процесс работы.»

Антон Немкин, председатель совета фонда Цифровая долина Сочи

На что обращать внимание при выборе проекта?

Описание проекта — интересен ли он вам? Решает ли важную (интересную) проблему? Актуальна ли тема?

Популярность проекта. На Github это можно оценить по количеству звёзд — местному аналогу лайка.
Посмотрите на раздел с проблемами (issues): много ли там открытых и особенно закрытых проблем? Это поможет оценить простор для творчества.
Изучите часть описания проекта, относящуюся к сторонним разработчикам (contributing). Там, как правило, описывается простой способ, как настроить среду разработки под этот конкретный проект и прислать свои изменения. Иногда просто пишут «pull requests are welcome», то есть «ждём не дождёмся ваших исправлений и предложений».
Насколько давно были сделаны последние изменения в проекте, активно ли идёт разработка? Если да, то ваши изменения быстро рассмотрят и, возможно, примут. Если не активно — быть может, вы захотите взять продвижение проекта в свои руки?
Есть ли активное комьюнити? Часто у проекта может быть чат, форум или группа в соцсети, где разработчики активно обсуждают проект. Кроме того, активность можно посмотреть в комментариях к проблемам и предлагаемым изменениям.

Никита Буйда, основатель и ведущий разработчик Datebox.app

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

Илья Башилов, руководитель Frontend-направления SimbirSoft

Каковы особенности Open Source разработки?

В каждом Open Source проекте есть свои правила и ограничения для организации кода, построения архитектуры. Обычно всё это описывается в разделе contributing в README.md или в файле CONTRIBUTING.md (чаще всего находится в корне репозитория проекта).
Среди требований нередко встречается определённый код-стиль проекта, которого надо придерживаться.
Во многих проектах для каждого изменения требуется написание юнит-тестов. Без них изменения не принимаются.
Естественно, всё общение между участниками проекта ведётся на английском языке через систему pull-request, в специальных чатах или даже через email рассылки. Это также чаще всего описывается в разделе contributing.

Дмитрий Зайцев, эксперт по разработке ПО компании «Рексофт»

Каких Open Source проектов стоит избегать?

У проектов с открытым кодом есть и свои неприятные особенности:

Разработчик проекта может вести его в никуда. И такое бывает весьма часто! Если проект всё равно хорош, то вы можете сделать ответвление (fork) и разрабатывать его в правильном, по-вашему мнению, направлении.
Разработчик проекта может медленно отвечать. Вы видите, что обновления кода идут, но коммуникации с разработчиком никакой. Это плохой признак и знак того, что ловить здесь нечего.
Разработчик проекта может потерять интерес и забросить код. Это можно понять по количеству нерешённых проблем в репозитории и давним обновлениям кода.

Никита Буйда, основатель и ведущий разработчик Datebox.app

Что стоит сделать перед тем, как принять участие в Open Source проекте?

Основной инструмент для участия в Open Source проектах — это, конечно, система контроля версий Git. Поэтому в первую очередь стоит ознакомиться с ним.

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

Илья Башилов, руководитель Frontend-направления SimbirSoft

А как быть с внесением изменений в проект?

Как начать свой Open Source проект?

«Это ещё один ответ на вопрос, как поучаствовать в Open Source проекте: создайте его сами. Но для начала определитесь с целью, взвесьте все «за» и «против», убедитесь, что готовы взять на себя ответственность за труд других людей и уверенно двигаться к релизу.

Если начинать свой Open Source проект, то необходимо привлечь к нему внимание через англоязычные порталы. Самый простой вариант — публиковать ссылки на портале Reddit в нужных подразделах с тематикой «программирование». Это обеспечивает больший отклик, чем публикация на любом русскоязычном сайте. Естественно, стоит рассказать о проекте и на таких ресурсах, как Хабр, DTF и в тематических группах ВК.»

Дмитрий Зайцев, эксперт по разработке ПО компании «Рексофт»

Источник: новость на Tproger

Источник

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

Избегаем «Уловки-22»

Поиск опен-сорс проекта с API

Практика: Поиск проекта с необходимостью документирования API

Понимание типа API, используемого в проекте

Содействие потребует навыков работы с Git

Не недооценивайте свои писательские навыки

Дополнительное чтение

Следующие шаги

Избегаем «Уловки-22»

Предположим, у нас нет опыта работы с API документацией, но мы пытаемся получить работу техписателя API документации. Работодатели будут готовы не обращать внимания на опыт, если мы сможем продемонстрировать примеры написания документации API. Но как мы получим примеры описания API без API-документации? И без примеров API документации как мы можем получить желаемую работу? Это может показаться невозможной ситуацией.

Обойти эту «Уловку-22» очень просто: создаем примеры документации API с помощью проектов с открытым исходным кодом, в которые мы внесли свой вклад. Вот где пригодится данное практическое занятие.

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

Поиск опен-сорс проекта с API

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

Поиск подходящего проекта может быть сложной задачей, но он важен для вашего портфолио и вашего успеха в проникновении в мир документации API. К счастью, почти все проекты с открытым исходным кодом используют GitHub, и GitHub предоставляет различные теги для документации и «help wanted» для привлечения добровольцев. (Задача настолько распространена, GitHub предоставляет советы по поиску проектов с открытым исходным кодом.)

Идеальный опен-сорс проект должен отвечать следующим критериям:

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

👨‍💻 Практика: Поиск проекта с необходимостью документирования API

Для поиска нужного проекта:

Открываем расширенный поиск GitHub
Скроллим экран и ищем раздел Issues Options. В поле With the labels вписываем help wanted. Это стандартный тег, который команды используют для привлечения добровольцев в свой проект (но некоторые команды, которым нужна помощь, могут его и не использовать). Скроллим вверх и замечаем, что надпись: «Требуется помощь» автоматически заполняется в поле Advanced Search.
В поле Advanced Search добавляем ключевые слова documentation и api перед тегом help wanted

Нажимаем кнопку Search и видим результат.

В полученном списке можно поискать проект REST API (а не API нативной библиотеки, такой как Java API). Есть ли проекты, которые выглядят интересными или перспективными? Если так, отлично. Если нет, добавляем ключевые слова и продолжаем искать.

Если поиск на GitHub не дал подходящих проектов, можно поискать на следующих ресурсах:

Trending GitHub projects
Crowdforge
Up for Grabs
Bus Factor
Code Triage
Changelog
24-hour Pull Requests
Programmableweb.com API directory

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

После выбора проекта пометим следующее:

Задействован ли REST API в проекте?
Как в проекте помечены проблемы, связанные с документацией? Например, используется ли в нем ярлык «документация»?
Определяем текущее состояние документации проекта: является ли она надежной, скудной, обширной, есть она вообще?
Насколько активен проект? (Какова частота коммитов?)
Сколько участников в проекте?

Примечание: Пока не нужно связываться или взаимодействовать с командой. Мы просто собираем информацию и анализируем потребности в документации здесь.

Понимание типа API, используемого в проекте

Во время поиска проекта API, нужно понять, что существует множество различных типов API. Многие из API-интерфейсов, с которыми мы работаем, могут быть исходными библиотеками API, которые не используют веб-протоколы для выполнения запросов и ответов (как это делают API-интерфейсы REST), а скорее подключают к проекту библиотеки для конкретного языка. Если кажется, что API фокусируется на определенном языке, а документация API выглядит автоматически, скорее всего это исходная библиотека API.

С другой стороны, если документация проекта содержит основные разделы конечных точек — это API REST.

Содействие потребует навыков работы с Git

Прежде чем вносить свой вклад в опен-сорс проект, нужно понять основной процесс Git Pull request. Для понимания рабочего процесса Git возможно придется освоить инструкции Git или вот Git на русском. Но лучший способа изучения Git, это активная практика в реальном проекте.

Не стоит переживать о Git сейчас. Можно изучить его позже, когда будет рабочий контент. Пока же просто ищем проект.

Не недооценивайте свои писательские навыки

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

В обзоре GitHub Survey: Open Source Is Popular, Plagued by Poor Docs and Rude People, Дэвид Рамел резюмирует результаты опроса GitHub 2017 года:

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

Также посмотрим Open source documentation is bad, but proprietary software is worse Мэтта Асаи. Мэтт выделяет результаты документации того же опроса GitHub:

93% респондентов скрежетали зубами от некачественной документации, но также признались, что практически ничего не сделали для улучшения ситуации. … Если вы считаете, что глубокая потребность в документации побудит большее количество разработчиков внести свою лепту и помочь, вы ошибаетесь: 60% разработчиков не могут потрудиться представить документацию.

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

Автору курса хорошо знакомо значение роли документации из его личного опыта написания документации для опен-сорс проектов. В какой-то момент, прежде чем сосредоточить свою энергию на этом курсе по API, он написал несколько руководств для документации по Jekyll. Том Джонсон добавил инструкции, которые включали много нового контента, и даже добавил раздел Tutorials.

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

Поэтому нужно быть уверенным в ценности, которую мы можем внести в опен-сорс проект. Мы создаем необходимую документацию для проекта.

Дополнительное чтение

Дополнительные материалы к изучению:

How to choose (and contribute to) your first open source project;
Contribute to open-source projects through documentation

Справочник по GitHub Pull Request доступен в разделе Процесс Pull request на GitHub

Следующие шаги

Приступаем к следующему практическому занятию: Оценка ключевых элементов API документации

🔙

Go next ➡

Источник

В этой статье собрано все, что необходимо знать для участия в Open Source проектах: типичные ошибки и приобретаемые навыки.

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

Молодые программисты ищут в Open Source проектах необходимый опыт, а искушенные разработчики реализуют свои «проекты выходного дня» и улучшают качество используемых ими программ. При этом многих профессиональных разработчиков останавливает незнание «кухни» Open Source движения и боязнь раздражать сообщество очевидными для его членов вопросами и другими ошибками.

В этой статье мы рассмотрим, с чего начать вхождение в мир Open Source как студентам, так и разработчикам со стажем, а также возможности заработка в рамках программ поддержки открытого программного обеспечения и в собственных Open Source проектах.

Известно множество примеров, когда люди, даже далекие от профессиональной разработки, вносят вклад в открытое программное обеспечение, получая удовольствие от общения с близкими по духу людьми. Но для новичков, как показывает опрос, проведенный на сайте opensource.com, основным барьером для вхождения в мир открытой разработки программного обеспечения является банальное отсутствие знаний о том, с чего начать.

А начать довольно просто – с поиска проекта, который вам симпатичен.

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

Программы для поддержки студентов

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

В течение 3-4 месяцев вы удаленно занимаетесь написанием и тестированием кода, составлением отчета. В ходе программы вы получаете стипендию, разделенную обычно на несколько платежей. Большинство спонсируемых программ проходят в летние месяцы, чтобы студенты не отвлекались от основной учебной деятельности. Однако регистрация заявок начинается раньше, обычно весной. Редакция proglib.io специально подготовила эту статью именно сейчас, так как большинство конкурсов принимает заявки студентов во второй половине марта.

Google Summer of Code

Google Summer of Code – самая известная глобальная программа, сфокусированная на привлечении молодых программистов в Open Source разработку. В 2018 году студенты могут выбрать один из проектов и подать свои заявки на участие в программе с 12 по 27 марта.

К 23 апреля студентов и менторов связывают в пары для начала планирования проекта. С середины мая до начала августа студенты работают над своим проектом, а в конце августа подводятся результаты. Стипендия зависит от страны проживания и разбита на три платежа: 30%, 30% и 40%. Например, для России сумма сейчас составляет $3600.

С общим планом вы можете ознакомиться на странице расписания. Правила участия в программе приведены на соответствующей странице. Прочитать подробности от участника Google Summer of Code на русском языке можно в серии статей awRabbit.

Другие стипендиальные программы

Кроме Google Summer of Code существует ряд не менее достойных программ поддержки студентов:

European Space Agency: Summer of Code in Space (SOCIS) – разработка систем для космоса, анализ данных, обработка изображений, визуализация и т.д. После утверждения проекта студент получает стипендию 1000€, после успешного завершения – еще 3000€. На написание кода дается три летних месяца.
OpenDaylight Summer Internship Program – в дополнение к стипендии программа оплачивают перелет в Кремниевую долину на OpenDaylight Event по завершении программы для презентации отчета.
The X.Org Endless Vacation of Code (EVoC) – программа, у которой нет дедлайна: вы выбираете проект и описываете что именно готовы делать в течение 3-4 месяцев. Стипендия в $5000 разбита на начальный ($500) и два последующих платежа по $2250, начисляемых после успешного прохождения ключевых точек.
Tor Summer of Privacy – очередной виток программы был объявлен в блоге Tor 2 марта. Программа связана с различными идеями относительно развития Tor. У студентов преимущество, но могут участвовать и не студенты. Суммы стипендий аналогичны Google Summer of Code. Подача заявок проходит с 12 по 26 марта, объявление победителей 20 апреля.
OWASP Summer Code Sprint – программа, посвященная системам безопасности, более скромная по стипендии (суммарно $1500), но интересная самими проектами.
Outreachy Program – программа, нацеленная на привлечение в Open Source людей из социальных групп, слабо представленных в разработке: женщин, трансгендеров и национальных меньшинств без ограничения по возрасту. Размер стипендии $5500 плюс дополнительные $500 в качестве трэвел-гранта. Проекты включают не только программирование, но и User Experience, документирование, иллюстрацию, графический дизайн и Data Science. Дедлайн подачи заявок 22 марта. Для оповещения о датах конкурса подпишитесь на лист рассылки.
Rails Girls Summer of Code: еще одна программа, нацеленная на привлечение девушек в IT. Здесь также нет ограничений по возрасту и не обязательно быть студенткой. В этом году прием заявок уже закончился, но продолжается краудфандинговая компания.

Программы менторства проектов

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

Mozilla Winter Of Security – программа проводилась последний раз в 2016 году.
Season of KDE – в этот раз проходит с 10 декабря 2017 по 21 марта 2018, дедлайн подачи был 26 декабря 2017 года.
Free Software Foundation Interships – ближайший дедлайн для подачи заявки 27 апреля 2018. Программа проводится три раза в году: весной, летом и осенью и требует отдачи по 20 часов в неделю.

Обратите внимание, что в этих же сообществах вы можете найти проект и наставника вне обозначенных дедлайнов.

Программа для школьников Google Code-In

Из-за сложностей с перечислением денежных средств несовершеннолетним в стипендиальных программах обычно указывается возрастное ограничение: не младше 18 лет. Для подростков 13-17 лет проводится соревнование по открытому программному обеспечению Google Code-In. В результате конкурсов участники получают различные подарки, футболки и сертификаты. Отчеты русскоязычных школьников по этому конкурсу в 2012, 2013 и 2014 годах сподвигли и некоторых взрослых людей заняться Open Source

Другие варианты поиска ментора

Еще один из возможных способов найти ментора это ACM MentorNet – специальная сеть для создания пар наставник-ученик. Заметим, что для этого требуется наличие почты на edu-домене.

Более общий сервис – сайт инициативы развития открытого программного обеспечения Open Source Initiative, содержащий множество различной актуальной информации об Open Source движении.

Наконец, вы можете просто писать администратору/менеджерам интересного Open Source проекта, например, владельцам соответствующего репозитория на GitHub.

Где еще можно найти проект или просто задачу

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

Множество проектов собраны на специальных сайтах сообществ. Например относительно Gnome работает программа GnomeLove, для новичков в Linux Kernel есть сообщество Linux Kernel Newbies, у Mozilla Foundation What Can I do For Mozilla и т.д.

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

issuehub.io
Up for Grabs
OpenHatch
24 Pull Requests

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

С чего начать

Проекты бывают очень большими, а начать можно с малого. Люди, участвующие в Open Source проектах это в первую очередь сообщество единомышленников. Присоединитесь к e-mail рассылке, IRC-каналу или групповому чату. Выясните как общаются между собой участники проекта. В крупных проектах обычно для каждой составляющей делается отдельная рассылка.

Бывает, что создаются специализированные planet-порталы, аккумулирующие новости из разных каналов. Читайте документацию и комментарии в самом коде. Читайте блоги и twitter, чтобы быть в курсе новостей сообщества. Следите за обновлениями репозитория и баг-трекера.

Как в общих чертах выглядит процесс разработки

Рассмотрим на примере GitHub наиболее популярную модель совместной разработки fork & pull.

Представим, что какое-то сообщество создало нравящийся вам репозиторий. Вы клонируете (fork) его и вносите изменения в своей личной версии репозитория. Если вы думаете, что текущие изменения могут быть полезны для исходного проекта, вы отправляете pull request – запрос на включение изменений кода в репозитории. Контрибьюторы репозитория решают, будут ли предложенные изменения включены в оригинальный репозиторий или отклонены. Подробнее на русском языке вы можете прочитать об этом здесь.

На GitHub пулл-реквест в публичный репозиторий может осуществить любой зарегистрированный участник. Главное, чтобы этот запрос был хорошо оформлен и содержал исчерпывающее описание. Далее рассмотрим основные примеры содержаний пулл-реквестов.

Что делать в Open Source проектах

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

В любых, даже коммерческих проектах, развитие функционала программ превалирует над его тестированием. По этой причине часто, перед тем как добавлять изменения в основную ветку репозитория, объявляется call for testing – привлечение людей, готовых протестировать предварительную версию.

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

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

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

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

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

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

3. Ищите и исправляйте ошибки

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

Если вы обнаружили еще не оформленный баг, пишите issue. Если вы сами сумели его исправить, оформляйте pull request и указывайте, что он исправляет определенный issue. Или найдите чужой issue, в котором описывается баг и устраните его в коде. Некоторые проекты требуют, чтобы баг-фиксы сопровождались тестами.

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

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

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

4. Пишите тесты

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

5. Пишите примеры и демо-приложения

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

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

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

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

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

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

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

Разработчики в основном думают о реализации какого-то технического замысла, но часто в Open Source проектах материализованной идее не достает красивой обертки. Броское качественное оформление привлечет к проекту и новых пользователей, и участников сообщества.

Найти дизайнера или предложить свои услуги можно при помощи сайта Open Source Design.

8. Ведите блог/YouTube-канал и помогайте другим пользователям

Делитесь опытом, полученным при работе в Open Source проектах. Рассказывайте о проблемах, с которыми вы столкнулись и как вы их решили. Так вы одновременно поддержите внимание к любимому проекту и создадите базу информации для тех, кто присоединится к нему впоследствии.

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

Все это зарекомендует вас как специалиста и поможет собрать благожелательную аудиторию.

Типичные проблемы новичков

Проблемы, с которыми сталкиваются новички в open source проектах, можно объединить в следующие категории:

Неуверенность в собственных силах. Код в Open Source проектах пишут в большинстве своем не гении разработки, а такие же программисты, как вы. И даже у них есть ошибки и просто опечатки. Нужно понимать, что крупным проектам требуются разработчики разного уровня подготовки, навыков и опыта. Открытость никак не гарантирует качества кода и часто даже неопытный новичок лучше, чем отсутствие специалиста.
Пугающая величина проекта. Да, проекты могут состоять из сотен и тысяч файлов, миллионов строк кода. Но никто не читает все эти файлы подряд. Чаще всего есть какая-то проблема, которая становится для вас точкой входа в проект – вы постепенно «разматываете» код от этого отправного пункта.
Боязнь задавать вопросы и раздражить сообщество своим непониманием. Если вы будете кого-то раздражать, вам скорее всего на это мягко намекнут, в этом нет ничего страшного. Такое происходит крайне редко, так что нужно постараться – многие проекты живут исключительно за счет энтузиазма создателей, и хорошие пулл-реквесты подстегивают их к продолжению работы.
Попытки решить множество проблем ондим пулл-реквестом. Обычное правило: один баг – один pull request, одна фича – один pull request. Так тем, кто получает ваши исправления гораздо проще их принимать или отклонять и аргументировать решение.
Вопросы сразу лично авторам проекта. Получить ответ гораздо быстрее из чата или мейлинг-листа, так как его одновременно читает множество людей.
Вы безоговорочно соглашаетесь с тем, что вам говорят ревьюеры. Ревьюер может быть тоже не прав. Старайтесь аргументировать свою позицию, если вы считаете ее правильной. Это очень полезный навык для того, чтобы работать в команде. Обратная сторона – умейте принять позицию, если вы действительно не првы.
Вы сдаетесь. Спокойствие, только спокойствие. Даже об этом вы можете написать в сообщество. Что где-то застряли и не знаете как дальше продвинуться. С этой ситуацией сталкивался любой, и кто-то обязательно даст совет по вашей проблеме.

Чему вы научитесь

Кроме удовольствия от участия в любимых Open Source проектах, начинающие программисты также учатся большинству вещей, характерных для работы в сильной команде:

Разбираться в чужом коде.
Пользоваться системами контроля версий.
Понимать весь процесс разработки продукта.
Проводить ревью кода (читать и понимать код вне IDE).
Проводить тестирование.
Пользоваться инструментами: IDE, сиcтемы сборки, утилиты проверки стиля и логики кода (checkstyle/PMD) и т.д.
Работать в очень большой и очень распределенной команде, обсуждая идеи и принимая решения.

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

Как это поможет в работе/карьере

Разработка открытого программного обеспечения повлияла на карьеру многих разработчиков. Мы объединили отзывы разработчиков о работе в Open Source проектах относительно основной работы в следующие пункты:

Весомая строчка в резюме и опыт. В хорошем крупном проекте есть все, что обычно требуется от разработчика на собеседовании: грамотное проектирование, хорошее кодирование, навыки работы с системой контроля версий и баг-трекером, peer review, работа в команде и т.д. За два-три года непрерывной работы в такой атмосфере можно вырасти до уровня, соответствующего позиции Senior Developer. Такой опыт может оказаться эквивалентен соответствующей строчке в трудовой книжке.
Портфолио и набор программных решений. Вашу компетенцию становится легко оценить по профилю на GitHub. Всегда есть что показать и легко пройти первый этап собеседования при приеме на работу. Кроме того, есть шанс, что работодатель найдет вас по коммитам или профилю на Github. Зарубежом это становится все более распространенной практикой.
Репутация и востребованность. Если компания использует развиваемый вами открытый продукт в своем технологическом стеке, вы становитесь идеальным кандидатом на место соответствующего разработки. Кроме того в Open Source проектах вы можете пересечься с другими специалистами, которые предложат вам место в своей компании.
Самостоятельность. Можно не ждать выхода новой версии библиотеки, а исправить баг самостоятельно.
Стажировки в мировых компаниях.

Как это поможет в учебе

Вернемся к студенческому вопросу. Что дают занятия открытым программным обеспечением студенты?

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

Если вы студент, это также позволит вам претендовать на различные стипендии.

Стипендия по постановлению Правительства РФ #945.
Стипендия Президента РФ.
Стипендия Правительства Москвы.
Стипендия фонда Владимира Потанина.
Стипендия Аниты Борг.
Другие конкурсы гранты.

Собственный проект

Наконец, нужно понимать, что участие в Open Source проектах не ограничивается работой в составе команды – вы всегда можете создать свой собственный, авторский проект. Опыт, накопленный на других площадках, вам в этом только поможет.

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

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

Варианты развития

В дополнение к спонсорству возможны следующие варианты заработка для дальнейшей работы в Open Source:

Собственный бизнес. Сделайте проект, на основе технологии которого можно построить бизнес. Например, вы создаете бинарники для конечных пользователей. К технологии будет испытываться большее доверие в силу свободности кода –можно проверить проект на отсутствие закладок. Кроме того, вы можете создать более крупный программный продукт, который может применяться многими, и на собственном примере вы можете показать другим как работает проект и привлечь контрибьюторов.
Платная поддержка. Одна из самых популярных моделей: вы разрабатываете открытый код, но предоставляете клиентам платную поддержку своего решения. Таким образом, например, поступает Linux Red Hat.
Разработка на заказ. Фактически аутсорсинг для других фирм и платные доработки под нужды заказчика. Пример: компания Chronicle Software кроме свободных проектов Crhonicle выполняет заказы по разработке систем с использованием этих проектов.
Обучение клиентов. Проводите обучающие платные тренинги, на которых вы учите клиентов как использовать ваш продукт. Таким образом, вы одновременно продвигаете проект и зарабатываете деньги.
Двойное лицензирование. Лицензируйте свой проект двумя лицензиями. Например, бесплатной лицензией для одиночных пользователей и образовательных учреждений и платной лицензией для коммерческого применения. Примером является система виртуальной роботехники V-REP.
Платные вспомогательные сервисы. Стратегия, близкая к предыдущей, но более гибкая: зарабатывайте не на самом проекте, а на предоставлении платных вспомогательных сервисов, таких как хостинг, сервис резервного копирования или мониторинга.
Сбор пожертвований. Не самый популярный подход в Open Source проектах, примером может служить Linux Mint и ReactOS.
Краудфандинговые компании. Последний подход, совмещающий первый и предпоследний пункты данного списка заключается в целенаправленном сборе средств на создание продукта в ограниченные сроки. Такие компании регулярно объявляются на Kickstarter и c переменным успехом набирают необходимую сумму. Один из успешных примеров – клиент для MySQL mycli.

О чем нужно помнить

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

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

Как раскрутить свой Open Source проект

Для того, чтобы представить свой проект общественности, нужно начать с довольно простых вещей:

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

Когда вы посчитаете, что проект уже выглядит достойно, проведите рекламную кампанию: добавьте ссылки на проект в Reddit (в ветку reddit.com/r/{язык вашего проекта}), Hacker News, в профильных группах и форумах. Если ожидается, что проект станет достаточно крупным, заведите для него свой твиттер-аккаунт, в который будете выкладывать новости по работе над проектом и попробуйте его разрекламировать, попросив кого-то из близких по духу известных разработчиков.

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

Другие материалы по теме

Open Source проекты в резюме: 5 причин писать открытый код
8 книг об open source для обучения программированию
6 open-source проектов для практики новичка

Источник