Введение: почему стоит создать open source проект
В основе инициатив с открытым исходным кодом лежит идея, что любой желающий имеет право их изучать, применять, изменять, вне зависимости от своих целей. Эти права обеспечиваются через open source лицензию. Открытый код снижает преграды для сотрудничества, помогая пользователям делиться работающими решениями. Опенсорс дает ИT-специалистам инструменты для контроля и развития своих инициатив. Компании, использующие такой софт, могут нанимать специалистов для его развития, вместо того чтобы зависеть от закрытых коммерческих разработок.
Есть много причин, по которым человек или компания могут решить открыть исходный код:
1. Желание сотрудничать: в open source проекте может участвовать кто угодно. Например, в платформу для уроков программирования Exercism вкладывалось около 350 участников.
2. Улучшения: открытые проекты могут быть использованы в разных целях, и новые пользователи могут адаптировать вашу работу для своих разработок. Популярная CMS WordPress была адаптацией уже существующей разработки b2evolution.
3. Прозрачность: кто угодно имеет право на то, чтобы начать заниматься тестированием проекта с открытым исходным кодом. Иногда прозрачность имеет значение даже для государственных разработок. Например, в американских и болгарских законах прописаны требования прозрачности для некоторых отраслей экономики: государственной безопасности, здравоохранения, банковского дела.
Open source бывает не только программное обеспечение, но и множество других вещей: наборы данных, книги, библиотеки текстов. Разработка проекта с открытым кодом своими силами — лучший способ понять принципы работы опенсорса. Рассмотрим, как это делается.
Определение целей и задач
Определение целей — это ключевой этап, который поможет вам определить, над чем следует работать, что можно отложить на потом и в каких областях вам возможно потребуется помощь. Попробуйте сформулировать, для чего вам вообще необходима разработка с открытым исходным кодом. Универсальных ответов на этот вопрос нет. Возможно, у вас есть несколько целей в рамках одной идеи или несколько идей под разные цели.
Если вы в первую очередь хотите продемонстрировать ваши профессиональные навыки, вероятно, вам не пригодится никакая внешняя помощь. Это лучше сразу отразить в файле README. Если же вам надо привлечь помощников, то стоит уделить время написанию документации и позаботиться о тех, кто только начинает с вами сотрудничать.
С развитием проекта деятельность вашего сообщества не будет ограничена лишь написанием кода. Управление задачами, код-ревью, продвижение — все эти аспекты играют важную роль в жизни любой инициативы open source. Объем времени, затрачиваемый на задачи, не связанные с написанием кода, возрастает с увеличением масштаба деятельности. Готовьтесь решать задачи самостоятельно либо привлекать помощь со стороны.
Если компания, где вы работаете, поддерживает разработку с открытым исходным кодом, убедитесь в наличии возможностей для ее запуска. Необходимо назначить ответственного за его поддержку, развитие, организацию сообщества. Чаще всего для таких задач требуется дополнительный бюджет либо другие ресурсы: обязательно обсудите это с коллегами перед тем, как начать.
Выбор лицензии и создание документации
В любом проекте, независимо от его стадии развития, важно наличие следующей документации:
1. Лицензия на открытый исходный код (оpen source license). Этот документ разрешает пользователям свободно копировать, распространять, изменять составляющие вашего проекта. Лицензия служит защитой от возможных юридических проблем. Ее добавление при запуске обязательно.
2. README. Этот файл объясняет правила пользования проектом, параллельно раскрывая его суть. Он отвечает на вопросы о том, что делает ваша программа, как ее использовать, где получить помощь при необходимости.
3. Руководство для участников (CONTRIBUTING). Этот документ описывает, как стать участником вашего проекта и как внести свой вклад в его развитие. Он может включать инструкции по сообщению об ошибках, предложению новых функций, настройке среды разработки и тестирования. Кроме технических деталей, в нем также могут быть указаны правила участия, планы развития, контактные данные, предложения по улучшению.
4. Нормы поведения (Code of Conduct). Определяют базовые правила взаимодействия внутри проекта, что особенно важно, если вы создаете что-либо для компании или сообщества. Эти нормы способствуют установлению здоровой и конструктивной атмосферы, снижая ваш стресс как менеджера. Они не только описывают приемлемое поведение, но и уточняют, какие последствия могут быть за нарушения. Вы можете использовать уже существующие общепринятые правила, например, Contributor Covenant, который широко применяется в 40 тысячах открытых разработок, включая такие крупные как Rails, Kubernetes или Swift. Важно быть готовым соответствовать этим нормам, применяя санкции в случае необходимости.
Публикация этих файлов в главной директории вашего GitHub-репозитория делает их доступными для посетителей. Это значительно увеличит удобство использования вашего проекта, а также снизит количество повторных вопросов и недопониманий.
Настройка репозитория и инструментов для совместной работы
Когда вы создаете репозиторий, старайтесь уделить дополнительное внимание составлению более удобных и понятных правил. Вот несколько важных шагов, которые следует предпринять:
1. Согласованные соглашения о коде и ясные имена. Используйте единые соглашения о форматировании кода и ясные, понятные имена для функций, методов и переменных. Для этого используются инструменты статического анализа кода, такие как Black, Ktlint и другие.
2. Комментирование кода и документация. Убедитесь, что ваш код достаточно подробно прокомментирован, опишите ваши мысли, укажите на возможные проблемы. Задокументируйте функции, методы, чтобы облегчить понимание для других разработчиков.
3. Конфиденциальность в истории изменений. Проверьте, чтобы в истории изменений, проблемах или запросах на слияние не содержалось конфиденциальной информации, такой как ключи API или пароли.
4. Четкие описания выпусков и журналы изменений для каждого релиза. Так пользователи смогут отслеживать изменения и исправления ошибок.
5. Включение руководящих принципов. В репозиторий также стоит включить руководящие принципы, которые объясняют вашему сообществу, как участвовать в проекте. Это может включать информацию о типах вкладов, которые приветствуются, процессе предложения новых функций или сообщения об ошибках.
Привлечение первых участников и сообщества
После того, как вы создали привлекательный README и сделали ваш проект доступным, настало время задуматься о привлечении внимания к вашей странице на GitHub.
Убедитесь, что в вашем репозитории на GitHub добавлены соответствующие теги. Так сторонние пользователи смогут вас найти.
Подходящие площадки для распространения информации о вашем проекте — Hacker News, X, Reddit, тематические сообщества ВК, Telegram-каналы и чаты. Однако достичь статуса основной новости или лучшего поста на любой из этих платформ может быть непросто. Не увлекайтесь слишком активной рекламой на любой платформе, чтобы избежать маркировки сообщений как спама.
Если нужно, чтобы люди оставляли отзывы, сперва убедитесь, что они действительно использовали ваш продукт и нашли его полезным. Также рассмотрите возможность добавления кнопки «tweet this project» в README. Это позволит людям, которым нравится ваша разработка, естественным образом продвигать ее среди своих подписчиков.
Также помните, что отзывы не всегда влияют на число звезд. Пользователи будут отмечать проект звездой лишь в том случае, если он действительно им понравится.
Это, конечно, не означает, что вы не должны просить людей о помощи, обратной связи или проверке кода. На самом деле, стоит стремиться реагировать на любые отзывы: будь то предложения по улучшению, сообщения об ошибках, или любая другая обратная связь.
Готовьтесь к тому, что отзывы могут быть и отрицательными, и всегда стремитесь понять, какие уроки можно извлечь из них. Возможно, вы обнаружите несколько новых подходов к улучшению своего проекта.
Управление проектом и его развитие
Опенсорс-продукты разрабатываются сообществом, поэтому развитие сообщества крайне важно для любой открытой инициативы. Для масштабных разработок необходимы как специалисты с технической подготовкой, так и те, кто может эффективно коммуницировать с широкой аудиторией. Важно помнить, что участвовать может каждый, главное — проявить желание. Если вы умеете программировать, вы можете работать над задачами (issues), а если у вас художественные способности, то ваша визуализация может оживить различные аспекты.
Помимо этого, развитию способствует составление документации, создание базы знаний, перевод документации на разные иностранные языки, активное взаимодействие с сообществом. Координацию этого процесса обычно осуществляют комьюнити-менеджеры, которые поддерживают общение, озвучивают планы, собирают отклики, строят доверительные отношения между аудиторией и командой.
В мире открытого исходного кода необходима прозрачность: участники сообщества должны понимать направление движения и текущие цели, чтобы избежать неопределенности.
Важно также обдумать стратегию развития в случае выхода кого-либо из участников по любым причинам. Поэтому предпочтительнее, чтобы управление проектом осуществлялось коллективом, а не отдельным лицом. Еще одним рискованным моментом при наличии единственного лидера является возможность развития продукта в направлении, не соответствующем ожиданиям сообщества. Для решения этих проблем используются следующие подходы:
- переход управления в руки команды, а не отдельных людей (децентрализация);
- активное взаимодействие в рамках сообщества, обмен опытом, публичное обсуждение успехов, неудач, планов развития.
Монетизация и поддержка проекта
За основные изменения продуктов с открытым кодом отвечают, как правило, сеньоры и тимлиды. Возможно, часть этих специалистов могла бы потратить свое время на более коммерчески выгодные проекты, тем не менее они выбирают вложения в опенсорс. Эти усилия не приносят людям мгновенной финансовой выгоды, поэтому они не могут посвятить этому полный рабочий день. Нужно разработать стратегию монетизации, и здесь возможны различные подходы:
1. Краудфандинг либо платформы вроде Patreon. Так можно собирать пожертвования от сообщества. Однако суммы, собранные таким образом, нельзя сравнить с заработком разработчика в крупной компании.
2. Сотрудничество с брендами. Можно предложить свое решение крупным компаниям за деньги. Это также вряд ли позволит разработчику полностью обеспечить себя, но станет более стабильным источником дохода, чем пожертвования.
3. Продажа услуг на основе решений с открытым исходным кодом. К примеру, создатели CMS или баз данных могут предоставлять консультации по использованию продукта либо анализировать механизмы его внедрения.
Кроме того, некоторые сервисы предлагают специальные тарифы для опенсорс-разработчиков, предоставляя бесплатный доступ к своим услугам или сниженные цены.
Заключение: что дальше после запуска проекта
Каждое вложение, комментарий, pull request — это еще один шанс личного и профессионального роста, как для вас, так и для других участников. Однако в процессе работы необходимо учитывать еще некоторые детали.
После запуска вам придется создавать множество текстов: от руководств до рассылок. Возможно, надо будет вести сообщества в социальных сетях, отвечать на вопросы пользователей, вести новостную ленту. И для технической документации, и для общения с пользователями стиль текста очень влияет на восприятие со стороны. То же самое относится и к стилю кода.
На начальных этапах развития любого ИT-проекта явно формируется его будущий облик. Каким он будет, зависит от вас. Независимо от итогов, ваша работа на виду у других — это ценный вклад в сообщество и важный опыт для вас самих.