Как сделать проект с открытым исходным кодом

Что нужно учитывать при создании открытого исходного кода

• Убедитесь, что у ваших ресурсов есть возможность поддерживать код.
• Убедитесь, что у вас есть процесс ответа на отзывы от сообщества открытого исходного кода.
• Решите, где вы будете размещать свой код.

Основные принципы Open Source Initiative представлены ЗДЕСЬ.

Рекомендуемые решения Open Source:

Полезные линки:

• OpenAPI Specification v3.1.0 | Introduction, Definitions and More
• OpenAPI Specification — Version 3.1.0 | Swagger
• REST API Documentation Tool | Swagger UI

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

1) Выберите лицензию с открытым исходным кодом

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

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

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

Следующая подборка является примером популярных лицензий с открытым исходным кодом с устойчивыми сообществами:

• Apache License 2.0
• MIT license
• BSD 3-Clause «New» or «Revised» license
• BSD 2-Clause «Simplified» or «FreeBSD» license
• GNU General Public License (GPL)
• GNU Library or «Lesser» General Public License (LGPL)
• Mozilla Public License 2.0
• Common Development and Distribution License
• Eclipse Public License version 2.0
• Creative Commons v4.0

Более подробная информация о типах лицензий доступна на веб-странице.

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

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

2) Подготовьте свой код к выпуску

1. Поместите свой код в систему контроля версий.
2. Если ваш проект уже находится в системе управления версиями, рассмотрите возможность создания новой версии для общедоступного выпуска.
3. Совершайте обновления заблаговременно и часто. Это важный шаблон рабочего процесса, который следует использовать при разработке проекта. Он способствует открытости, прозрачности и предоставляет возможность для регулярной обратной связи и обзора.
4. Очистите свой код от любой конфиденциальной информации.
   Перед тем, как сделать репозиторий общедоступным, убедитесь, что код рецензируется и проверяется на наличие конфиденциальной информации. Важно гарантировать, что токены личного доступа и другие личные данные не станут непреднамеренно общедоступными.
   При анализе кода следует учитывать следующее:
   • Вклады связаны с учетной записью пользователя, настроенной системой контроля версий. Учитывайте личность учетной записи, делающей коммиты, потому что их может просматривать любой, у кого есть доступ к репозиторию.
   • Удалите все пароли, ключи API, секретные ключи и учетные данные из источника (и истории репозитория).
   • Удалите все внутренние URL-адреса, которые не должны быть обнаружены внешним миром. Они должны находиться в файлах свойств и не возвращаться в репозиторий исходного кода.
   • Код следует сканировать с помощью автоматизированных инструментов аудита (например, NodeJS предоставляет аудит npm). Они находят уязвимости безопасности в ваших пакетах, обновляют и исправляют их там, где могут.
   • Следует использовать последние версии зависимых библиотек. По возможности включайте автоматические обновления в конвейер непрерывной интеграции.
   • Любые сторонние приложения, встроенные в код (Google Analytics или аналогичные), должны быть объявлены. Сюда входят любые учетные записи, необходимые для использования технологии.
   • Следует проконсультироваться с Essential 8 и OWASP Top 10, чтобы убедиться, что соответствующие меры безопасности обновлены.
   • Вы также можете проверить, что ваши зависимости обновлены и не имеют дополнительных уязвимостей, которые вы собираетесь передать другим.
5. Убедитесь, что ваш проект содержит файл readme со следующей информацией:
   • предыстория и цель проекта
   • с чего начать (с примерами)
   • любые известные проблемы или ошибки
   • лицензия
   • атрибуция
   • контактная информация
   • руководство по взносам

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

3) Разработайте план обслуживания, постоянного улучшения и поддержки

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

• техническое обслуживание (исправления, patches)
• постоянное улучшение
• поддержка

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

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

4) Выпустите (опубликуйте) свой проект

Выполнив описанные выше шаги, вы сможете сделать проект доступным на выбранной вами платформе.

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

• Node.JS -> NPM
• Java -> Maven Central
• .Net -> NuGet
• Python -> PIP
• PHP -> Composer
• Perl -> PPM
• Ruby -> Gems

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

Если вы хотите опубликовать свой код в учетной записи opencode.md, свяжитесь с нами по почте opencode.md@gmail.com, чтобы выразить свою заинтересованность.