Как создать программу с открытым исходным кодом
Здесь обсуждаются основные моменты, касающиеся создания программы с открытым исходным кодом.
Что означает "открытый исходный код?"
Программа с открытым исходным кодом является более общедоступным доступом к базе кода. Это открытие живого проекта к участию для любого желающего. При правильном выполнении для соответствующего проекта программа с открытым исходным кодом может помочь повысить качество продукта.
Одна из основных причин, почему компании создают проекты с открытым исходным кодом, — это их желание привлечь к разработке сообщество. Популярные проекты получают значительное участие сообщества, причем бесплатно.
Это не всегда альтруизм. Люди и организации используют проекты, потому что они видят личную или бизнес-выгоду. Если проект не соответствует их потребностям или ожиданиям, они могут использовать возможность устранения ошибок или добавления функций. Вместо того чтобы держать эти улучшения в частных форках, они вынуждены внести эти изменения в исходный репозиторий, чтобы они стали частью основы проекта. Этот виртуозный цикл улучшения заключается в том, почему многие предприятия производят программное обеспечение с помощью модели с открытым кодом.
Цели проекта с открытым кодом
Итак, есть три уровня участия в программном обеспечении с открытым исходным кодом:
- Потребители, которые изучают или используют репозитории других пользователей.
- Участники, которые активно участвуют в улучшении репозиториев других пользователей.
- Производители, которые создают и поддерживают собственные репозитории, открытые для других.
По мере того как организации задумываются о том, что они хотят получить от каждого уровня, рекомендуется оценить их состояние. В каждом измерении есть пять уровней процессов.
- Нерегламентированное, которое не имеет никакого процесса. Успешное выполнение зависит от индивидуальных усилий.
- Управляемые, которые имеют частично документированные процессы. Успешное выполнение зависит от дисциплины.
- Определены, которые имеют документированные, стандартизированные и интегрированные процессы. Успешное выполнение зависит от автоматизации.
- Измеряемые, которые имеют процесс, управление которым осуществляется количественно. Успешное выполнение зависит от измерения показателей относительно бизнес-целей.
- Оптимизирован, который имеет процесс, который постоянно и надежно улучшается с помощью добавочных и инновационных изменений. Успех зависит от снижения риска изменения.
Чтобы лучше понять, где стоит ваша организация, ознакомьтесь с самооценками с открытым кодом.
Что делать с открытым исходным кодом?
Многие проекты не предназначены для величия с открытым исходным кодом. Хотя ваши критерии могут отличаться в зависимости от целей вашей компании и уровня процессов, ниже приведены некоторые рекомендуемые критерии, которые следует учитывать перед открытием проекта:
Содержит ли ваш проект интеллектуальную собственность, которую вы хотите защитить? Если да, то открытие его кода раскроет ее ценность. Не открывайте исходный код для таких проектов, если вы не чувствуете, что преимущества перевешивают риски.
Находится ли проект в стабильном состоянии с хорошим качеством кода? Проект не должен быть идеальным, но потенциальные участники могут уйти, если проект находится в ужасной форме, чтобы начать с.
Является ли ваш проект полезным для пользователей за пределами вашей компании? Если нет, то вы, вероятно, не получаете никакого участия.
Могут ли люди за пределами вашей компании вносить свой вклад? Им нужен доступ ко всем зависимостям проекта, процессам сборки и любым другим потребностям для запуска проекта. Если они не могут его запустить, они не могут внести свой вклад.
Обладает ли ваша команда пропускной способностью для поддержки программы с открытым исходным кодом? Если нет, подождите, пока не сделаете. Если вы открываете проект с открытым исходным кодом и не поддерживаете его, вы можете потерять возможность создать доверенное сообщество.
Эти вопросы — только часть наиболее общих соображений. У вашей организации могут возникнуть другие проблемы с бизнесом или соответствием требованиям.
Разработка программы с открытым исходным кодом
Запуск программы с открытым исходным кодом аналогичен запуску программы InnerSource, но для общей аудитории. В результате есть несколько дополнительных соображений.
Задание ожиданий сообщества
Файлы, подобные README.md и CONTRIBUTING.md еще более важные, так как они предоставляются пользователям, у которых нет контекста организации. Они должны оцениваться с точки зрения кого-то за пределами компании, чтобы обеспечить ясность.
Кроме того, ваш кодекс поведения является важным документом, который следует выразить. Стандарт — добавить файл в корневой CODE_OF_CONDUCT.md каталог репозитория и использовать его для объяснения поведения, ожидаемого от участников сообщества. Несколько групп в организации должны просматривать этот документ, включая юридическую группу. К счастью, существует множество стандартных правил поведения, с которых можно начать. Многие проекты используют эти кодексы без изменений. Дополнительные сведения см. в руководстве по коду поведения с открытым исходным кодом.
Подготовка сотрудников для обслуживания репозитория
Сотрудники могут не работать с сообществом с открытым кодом. Они могут подготовиться, предоставив своим сотрудникам набор руководств по основным процессам перед началом работы. Эти руководства должны быть размещены во внутреннем репозитории или портале, который регулярно поддерживается и доступен только сотрудникам компании. Ниже приведены некоторые из наиболее важных руководств.
Руководство «Следует ли сделать проект с открытым исходным кодом», которое предоставляет рамки для принятия решения о том, следует ли открывать исходный код проекта-кандидата. Это руководство можно структурировать как блок-схему, набор вопросов или список рекомендаций.
Контрольный список установки, включающий все рабочие элементы, которые команда должна завершить до и после запуска проекта с открытым исходным кодом. Этот список должен включать получение утверждения для публикации проекта с открытым исходным кодом, проверки кода, чтобы гарантировать удаление конфиденциальных данных до публикации проекта, проверку товарного знака или поиск открытого исходного проекта, чтобы убедиться, что нет конфликта названий, и т. д.
Список контактов для ключевых людей в вашей организации, к которым может потребоваться обратиться в случае, если требуется прямая поддержка от обслуживающих лиц. Этот список должен включать сотрудников из отдела безопасности программного обеспечения, безопасности сайта, юридического отдела и отдела по связям с общественностью и т. д.
Ссылка на начальный репозиторий , который можно клонировать в качестве отправной точки. Он должен содержать образец файла README, лицензию, кодекс поведения, руководство по участию, а также любые другие вспомогательные файлы, необходимые для каждого проекта с открытым исходным кодом вашей компании. Он не должен содержать ничего, что вы не хотели бы случайно отправить в публичный доступ.
Руководство хранителя, объясняющее обязанности хранителя в поддержании работоспособности репозитория. Эти обязанности включают поддержание актуальной документации репозитория, обеспечение актуальности проблем и запросов на вытягивание своевременного получения внимания правильных людей и т. д.
Руководство по обмену данными, которое предлагает рекомендации по ответственный за репозиторий для некоторых разделов, которые вы предпочитаете не включать в общедоступные файлы, например
README.md,CONTRIBUTING.mdилиCODE_OF_CONDUCT.md. Эти темы могут быть чувствительными к бизнес-темам, таким как отсутствие обсуждения конкурентов; или более общие темы поведения, например, как соответствующим образом распознать ведущих участников.Внутренние вопросы и ответы, предоставляющие утвержденные ответы на распространенные вопросы. Этот список особенно полезен, если существуют юридические тонкости тем, которые ваша компания может обсудить в ходе поддержания программы с открытым исходным кодом.
Политика лицензий, которая перечисляет, какие лицензии были утверждены или отклонены юридическим отделом для использования или участия в работе с открытым кодом.