Никогда не забывай об этом, когда делаешь open-source проект
Если составлять топ самых крутых изобретений человечества, то второе место сразу после кофеварки наверняка займёт open-source — разработка проектов с открытым исходным кодом, которая помогла родиться поистине огромному числу полезных и гениальных продуктов. Причём опенсорс важен не только для сообщества программистов в целом, но и для каждого конкретного разработчика: участвуя в создании программ с открытым кодом, они могут неплохо развить свои скиллы, обрести новых друзей со сходными интересами и, конечно же, потешить своё самолюбие. Признайтесь, вам хотелось бы, чтобы вашей библиотекой пользовался весь мир?
Число участников open-source сообщества растёт ежедневно, а количество созданных ими проектов — ежеминутно. Каждый разработчик может столкнуться с необходимостью создании открытого кода, поэтому важно заранее понять ключевые аспекты и особенности успешного развития open-source проекта. В данной статье я постарался собрать ответы на наиболее важные на мой взгляд вопросы, которые могут возникнуть у тех, кто давно хотел узнать про опенсорс, но боялся спросить.
Первый шаг — выбираем лицензию!
Невероятно, но факт: ключевым вопросом при создании продукта с исходным кодом является выбор лицензии. Почему? Всё просто: этот документ позволит чётко определить юридические рамки распространения и внесения изменений в проект. Что не только поможет защитить ваши права как автора, но и сразу обозначит ваши условия сотрудничества с другими разработчиками.
Если у написанного вами кода нет лицензии, его использование несёт за собой большие юридические риски: такой код по-умолчанию защищён авторским правом, и использовать, изменять или распространять его без вашего личного согласия не может никто. Даже если он лежит в открытом виде где-нибудь на GitHub.
При выборе лицензии для вашего проекта важно знать, какие доступные варианты у вас имеются. Основные типы лицензий можно разделить на две большие категории: «copyleft» и «permissive».
Copyleft лицензии требуют, чтобы любой производный код от оригинального open-source кода наследовал его условия лицензирования. Наиболее известными copyleft лицензиями являются:
GNU General Public License (GPL)
Affero GPL (AGPL)
Lesser General Public License (LGPL)
Eclipse Public License (EPL)
Mozilla Public License (MPL)
Сразу замечу, что далеко не каждая из этих лицензий может понравиться разработчикам, которые потенциально могли бы использовать вашу разработку: так, например, GPL требует, чтобы все выпущенные улучшенные версии кода, покрытого этой лицензией, также были открытыми. Любопытно, что GPL содержит небольшую, но не самую приятную лазейку: если ПО доступно только через Интернет (например, в виде веб-приложения), то данная лицензия не требует предоставления исходного кода пользователям. Лицензия AGPL закрывает эту лазейку, являясь более строгой.
Permissive лицензии предоставляют больше свободы для повторного использования, модификации и распространения. К ним относятся:
Эти лицензии обычно короче и накладывают куда меньше условий. Например, MIT License разрешает использовать оригинальный код как угодно (при условии включения оригинального уведомления о copyright и лицензии).
Выбор между этими типами лицензий зависит от намерений разработчика или лицензиара по использованию ПО. Подведем небольшой итог: если вашей целью является максимальное распространение и свободное использование кода, предпочтительнее выбрать разрешающую лицензию. Если же вы хотите сохранить код в открытом доступе, но обеспечить распространение модификаций исключительно на тех же условиях, что и у оригинальной разработки, следует отдать предпочтение copyleft.
Как вы уже успели заметить, данный вопрос не так прост, как кажется, поэтому я настоятельно рекомендую заранее ознакомиться с требованиями различных типов лицензий. Сделать это вы можете на таких общедоступных ресурсах, как:
Open Source Initiative — содержит список подходящих для open-source проекта лицензий и объяснения их особенностей;
Choose a License — предлагает полезные руководства для выбора подходящей лицензии для вашего проекта;
Можно воспользоваться даже Википедией (https://en.wikipedia.org/wiki/Open-source_license), которая тоже предоставляет обзор open-source лицензий, включая исторический контекст и описание их различных типов.
Шаг второй: обеспечиваем качество исходного кода
То, что код должен быть качественным, очевидно всегда. Но для опенсорса это важно особенно, ведь если код будет плохим, разработчики могут попросту отказаться от участия в проекте. Низкое качество кода затрудняет его понимание, а это не только снижает скорость работы над проектом, но и усложняет внесение новых изменений и исправление ошибок, что в итоге приводит к появлению новых багов и уязвимостей. Плохой код станет причиной оттока заинтересованных программистов и существенно замедлит разработку: кому захочется над ним работать, когда на свете и без того много интересных опенсорс-проектов? Сообщество играет ключевую роль в open source, а потому привлекательность и доступность кода для новых участников должна быть в приоритете.
Что сделать, чтобы улучшить качество своего проекта?
Писать больше тестов. Тесты — это основа качества любого проекта. Хорошие тесты помогают находить ошибки почти любой сложности. А ещё они помогают разработчику дополнительно задуматься о том, зачем, как и для кого он создаёт проект, ведь в процессе их написания можно лучше осмыслить созданный код. Добавлю, что тесты могут быть использованы как своего рода документация с примерами, ведь хороший и чистый тест наглядно показывает, как работает та или иная часть программы.
Добавить статический анализ кода. Использование инструментов статического анализа кода (таких как ESLint для JavaScript, Pylint для Python или PHPStan для PHP) помогает обнаруживать потенциальные ошибки, проблемы с безопасностью и несоответствия стилю кодирования на самом раннем этапе. Откровенно говоря, современную разработку без этих инструментов сегодня вообще уже сложно представить: все «взрослые» опенсорс проекты пользуются ими в обязательном порядке. В рамках работы с открытым кодом это важно ещё и по той причине, что по мере роста проекта и числа работающих над ним незнакомых вам программистов дополнительные инструменты проверки качества их изменений существенно облегчат и обезопасят ваш проект.
Автоматизировать проверку качества кода. Для повышения качества и безопасности проекта настоятельно рекомендуется использовать инструменты непрерывной интеграции (CI), автоматизирующие запуски тестов и статический анализ кода. Данная практика позволяет эффективно выявлять уязвимости и ошибки на ранней стадии, существенно улучшая качество вашей разработки. А использование Git-хуков для предварительной проверки изменений перед созданием коммитов и их пушем в репозиторий будет дополнительным барьером от некачественных или потенциально опасных изменений. Правильно настроив автоматизации проверок нового кода, вы не только сэкономите время, но ещё и сократите число возможных ошибок в проекте.
Без документации никуда и тут
Разработчик, помни: документация — основа основ, без которой сторонним специалистам придётся тратить (не)лишнее время. Если её нет, им даже не сразу будет ясно, зачем вообще нужен ваш продукт и на что он способен. Многочисленные исследования подтвердили важность наличия качественной документации, и, если вы планируете создать продукт с исходным кодом, будьте готовы к тому, что придётся расписывать каждый свой шаг, ведь отсутствие документации может убить даже самый крутой проект.
К счастью, для ленивых придумали специальные инструменты и ресурсы, способные частично автоматизировать процесс: Sphinx, ReadTheDocs, Jekyll и многие другие в этом вам очень помогут. Но даже просто понятно написанный README файл уже лучше, чем ничего. Друзья, пожалуйста, думайте о ваших коллегах — пишите документацию, хотя бы самую простую!
Работаем над развитием сообщества вокруг своего проекта
Как правильно организовать процесс работы над вашим проектом? Как решить проблему bus-фактора? Как разрешать конфликты заранее? Без паники: не вы первый, не вы — последний, и большинство сложных вопросов уже решили до вас. Главное — с самого начала иметь какую-то тактику, и её придерживаться.
В первую очередь определитесь с миссией и целью проекта, от которой целиком и полностью будет зависеть вектор его развития. Если у проекта не будет цели, не будет и людей, которые захотят над ним работать;
Сделайте работу над проектом максимально прозрачной для каждого потенциального его участника, описав правила внесения изменений в проект (CONTRIBUTING) и кодекс поведения (CODE_OF_CONDUCT). Проекты без этой информации могут попросту игнорироваться разработчиками. Указав, какая конкретно помощь вам требуется от сообщества, и подробно расписав текущие задачи, вы сможете привлечь участников гораздо быстрее;
Старайтесь максимально быстро реагировать на возможные вопросы пользователей и на создаваемые ими баг-репорты. Очень важно, чтобы они не чувствовали себя брошенными один на один с ошибками и проблемами, которые содержатся в коде продвигаемого вами инструмента;
Выделяйте наиболее активных участников вашего проекта и не стесняйтесь давать им больше полномочий. Opensource — это командный путь, поэтому вам необходимо ценить и поощрять вклад людей, которые сотрудничают с вами. Позвольте им участвовать в решении важных вопросов и учитывайте их мнение: они это оценят.
Маркетинг
Проект сам себя не раскрутит, поэтому для достижения популярности вам придётся попотеть. К счастью, возможностей для маркетинга предостаточно, и уже сегодня вы можете:
Рассказать о своём проекте в социальных сетях, на хабре и на других ресурсах, где про него смогут узнать;
Подготовить небольшой веб-сайт о своём продукте с описанием его цели и функциональных возможностей. Кстати, средства автоматической генерации статических html страниц из md документации могут вам помочь в этом, а разместить результат можно, например, на Github Pages или Read the Docs. Со временем этот сайт начнет привлекать новых участников и пользователей;
Принимать участие в знаковых событиях, например Hacktoberfest — это идеальный способ привлечения новых разработчиков в проект. Достаточно просто осуществить небольшую подготовку согласно правилам данных мероприятий и вы можете наслаждаться ростом популярности своего детища;
Самопиариться. Если вы сделали действительно классную библиотеку, которая пригодится другим разработчикам, грех её не разрекламировать. Не стесняйтесь писать разработчикам других популярных решений (в рамках которых можно применить вашу разработку), о своём продукте, доказывая его ценность не только на словах, но и на примерах. За спрос денег не берут, а за спам не банят. Хотя это не точно;
Ещё самопиариться — например, на митапах или тематических конференциях, что может стать дополнительным способом привлечения новой аудитории в проект.
Советов никогда не бывает много, а полезных — тем более. Наверняка в сети вы сможете узнать что-то ещё. Например, есть полезная статья о продвижении проекта на GitHub Blog: «Marketing for maintainers: Promote your project to users and contributors», не менее ценная информация о привлечении новых контрибьютеров в проект на ресурсе opensource.com:
«Attract contributors to your open source project with authenticity», статья о том, как найти пользователей для проекта в Open Source Guides: «Finding Users for Your Project»… и это лишь малая часть публикаций по теме.
В заключение
Всё, что я написал выше — только ключевые рекомендации. На самом деле нюансов гораздо больше, и лишь с учётом каждого из них можно разработать действительно выдающийся и популярный опенсорс-продукт. Это непросто, но очень увлекательно — особенно если усилия в конце концов увенчаются успехом, и ваше детище найдёт свою аудиторию.
Однако, имейте в виду: важно не только создавать что-то своё, но и поддерживать чужие инициативы. Не забывайте отмечать проекты звездочками, вносить свой вклад в их улучшение, искать/править баги, совместными усилиями улучшая продукт. Помните: текущий уровень развития во многом обусловлен существованием сообщества открытого исходного кода. Помогая другим, вы в конечном счёте помогаете и себе!
