Как управлять успешной программой InnerSource

  • 8 мин

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

Что такое InnerSource?

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

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

Преимущества InnerSource

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

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

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

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

Эти примеры — лишь несколько из преимуществ, которые предлагают программы InnerSource. Дополнительные сведения см. в разделе Введение в InnerSource.

Настройка программы InnerSource на GitHub

Настройка видимости и разрешений репозитория

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

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

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

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

Дополнительные сведения о разрешениях на доступ к репозиторию по уровням.

Создавать обнаруживаемые репозитории.

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

Ниже приведены некоторые рекомендации.

  • Используйте описательное имя репозитория, например warehouse-api или supply-chain-web.
  • Включите краткое описание. Предложения или двух должно быть достаточно для того, чтобы потенциальные пользователи могли понять, соответствует ли проект их потребностям.
  • Лицензировайте репозиторий , чтобы клиенты знали, как они могут использовать, изменять и распространять программное обеспечение.
  • README.md Включите файл в репозиторий. GitHub использует этот файл в качестве целевой страницы при посещении пользователями репозитория.

Добавление файла README

Файл README сообщает ожидания для проекта и помогает управлять вкладом. Файлы README могут:

  • Сформулируйте цель и концепцию проекта, чтобы потенциальные потребители могли понять, насколько он отвечает их потребностям.
  • Предложите визуальные вспомогательные средства, такие как снимки экрана или примеры кода, чтобы продемонстрировать проект в действии.
  • Включите ссылки на рабочую или демонстрационную версию приложения для проверки.
  • Задайте ожидания для необходимых компонентов и процедур развертывания.
  • Включите ссылки на проекты, от которых зависите. Эти ссылки являются хорошим способом продвижения работы других.
  • Используйте Markdown, чтобы помочь читателям правильно отформатировать содержимое.

Если вы помещаете файл README в скрытый github репозитория, документы или в корневом каталоге, GitHub распознает и автоматически отображает файл README для посетителей репозитория. Если репозиторий содержит более одного файла README, показанный файл выбирается из расположений в следующем порядке: каталог github , корневой каталог репозитория и, наконец , каталог документов .

Ознакомьтесь со статьей Прекрасные примеры файлов сведений README.

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

Управление проектами на GitHub

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

Для упреждающего решения этой проблемы GitHub ищет CONTRIBUTING.md файл в корневом (или /docs/.github) репозитории. Используйте этот файл, чтобы объяснить политику участия в проекте. Точные сведения могут отличаться, но рекомендуется сообщить потенциальным участник знать, какие соглашения следует проекту, где команда ищет запросы на вытягивание, какие сведения запрашиваются для отчетов об ошибках и т. д.

Если существует CONTRIBUTING.md , GitHub представляет ссылку на нее при создании проблем или запросах на вытягивание, чтобы поощрять их следовать за ним.

Contributing guidelines links.

Ознакомьтесь со статьей Прекрасные примеры файлов участия CONTRIBUTING.md

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

Создание шаблонов запросов на вытягивание и проблемы

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

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

A new issue using the template.

То же самое касается запросов на вытягивание, за исключением того, что путь — .github/PULL_REQUEST_TEMPLATE.md.

Ознакомьтесь со статьей Прекрасные шаблоны проблем и запросов на вытягивание GitHub.

Определение рабочих процессов

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

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

Измерение успешности программы

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

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

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

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

Узнайте о чужих успехах в этих примерах использования InnerSource.