В 2020 году сообществом InnerSource Commons были представлены
паттерны InnerSource, которые описывают лучшие практики применения InnerSource в едином формате, упрощающем их понимание, оценку и повторное использование.
Сообщество InnerSource Commons основано в 2015 году и в настоящее время объединяет более 3000 участников из 800 компаний. Паттерны собирались сообществом на протяжении многих лет и на текущий момент собрано и описано 79 паттернов. Наиболее зрелые паттерны были опубликованы в
книге InnerSource Patterns и в
репозитории на GitHub. Под зрелостью авторы понимают, что каждый паттерн прошел рецензирование участниками сообщества и имеет подтвержденный пример применения на практике.
Сообщество определяет InnerSource как
использование принципов и практик Open Source для разработки программного обеспечения внутри организации. Практики и паттерны InnerSource могут стать эффективным инструментом для разрушения организационных барьеров, стимулирования и масштабирования внутреннего сотрудничества, ускорения адаптации новых инженеров (On-boarding), а также выявления возможностей для вклада в экосистему Open Source.
Паттерны (
Patterns) — это способ описания повторяемых, проверенных решений проблем в рамках определенного контекста. Паттерны предоставляют участникам сообщества InnerSource Commons способ кратко и ясно обмениваться знаниями, способствуя развитию практик InnerSource. Паттерны разделены на основные разделы: название (
Title), формулировка проблемы (
Problem Statement), контекст (
Context), силы (
Forces) и решения (
Solutions).
Список паттернов InnerSource:
1.
30-дневная гарантия (30 Day Warranty) — при принятии вкладов от команд, не входящих в состав вашей команды, естественным образом возникает нежелание брать ответственность за код, написанный не собственной командой. В рамках паттерна 30 Day Warranty команда-контрибьютор соглашается в течение 30 дней предоставлять исправления дефектов для принимающей команды. Это повышает уровень доверия между командами и увеличивает вероятность принятия вкладов.
2.
Общие требования (Common Requirements) — общий код в совместно используемом репозитории не удовлетворяет потребностям всех проектных команд, которые хотят его использовать. Проблема решается за счет согласования требований и рефакторинга.
3.
Контрибьютор по контракту (Contracted Contributor) — сотрудники, желающие вносить вклад в InnerSource, сталкиваются с сопротивлением со стороны линейного руководства. Решение заключается в использовании формальных контрактов и соглашений, которые снимают эти ограничения.
4.
Выделенный лидер сообщества (Dedicated Community Leader) — необходимо выбрать людей, обладающих как коммуникативными, так и техническими навыками, для руководства сообществами с целью обеспечить успешный запуск инициативы InnerSource.
5.
Рынок краткосрочных задач (Gig Marketplace) — создается внутренний маркетплейс в виде внутреннего сервиса, на котором конкретные потребности проектов InnerSource публикуются в виде Gigs с явными требованиями к времени и навыкам. Это позволяет руководителям лучше понимать временные затраты сотрудников и профессиональные выгоды, тем самым повышая вероятность одобрения участия в InnerSource вкладах.
6.
Модель зрелости (Maturity Model) — команды начинают внедрять InnerSource, и практика распространяется на несколько подразделений. При этом понимание того, что именно считается проектом InnerSource, становится широко распространенным, но не всегда единообразным. Решение заключается в предоставлении модели зрелости, которая позволяет командам провести самопроверку и выявить паттерны и практики, о существовании которых они ранее не знали.
7.
Лицензия InnerSource (InnerSource License) — два юридических лица, входящих в состав одной организации, хотят обмениваться исходным кодом программного обеспечения, но обеспокоены юридическими последствиями, связанными с ответственностью или межкорпоративным учетом. Лицензия InnerSource предоставляет повторно используемую правовую рамку для обмена исходным кодом внутри организации. Это открывает новые возможности для сотрудничества и явно фиксирует права и обязанности вовлеченных юридических лиц.
8.
Портал InnerSource (InnerSource Portal) — потенциальные контрибьюторы не могут легко находить проекты InnerSource, которые им интересны. Создание интранет-сайта, индексирующего всю доступную информацию о проектах InnerSource, позволяет контрибьюторам узнавать о проектах, которые могут их заинтересовать, а владельцам проектов InnerSource — привлекать внешнюю аудиторию внутри организации.
9.
Поощрение участников (Praise Participants) — эффективное выражение благодарности контрибьюторам с целью стимулировать их дальнейшую вовлеченность и побудить других сотрудников вносить вклад.
10.
Индекс активности репозитория (Repository Activity Score) — индекс активности репозитория представляет собой числовое значение, отражающее активность проекта InnerSource в репозитории.
11.
Экспертный комитет (Review Committee) — модель работы InnerSource является радикальным отходом от более традиционных подходов как для разработчиков, так и для руководителей. Создание экспертного комитета в качестве интерфейса между инициативой InnerSource и всеми руководителями бизнес-подразделений, участвующих в ней, повышает вероятность того, что последние ознакомятся с инициативой и будут ее поддерживать, поскольку такой формат обеспечивает определенный уровень прозрачности и контроля, не поощряя микроменеджмент.
12.
Сервис или библиотека (Service vs. Library) — команды могут неохотно работать с общими кодовыми базами за пределами границ своих команд из-за неопределенности в вопросе того, кто будет нести ответственность за реагирование на простои сервиса. Решение заключается в осознании того, что во многих случаях возможно либо развертывать один и тот же сервис в независимых окружениях с отдельными цепочками эскалации на случай простоя сервиса, либо вынести значительную часть общего кода в одну библиотеку и совместно работать над ней.
13.
Доверенный коммиттер (Trusted Committer) — многие проекты InnerSource оказываются в ситуации, когда они на регулярной основе получают обратную связь, новые функциональные возможности и исправления дефектов от контрибьюторов. В таких ситуациях мейнтейнеры проекта ищут способы признать и вознаградить вклад контрибьютора, выходящий за рамки отдельных разовых вкладов.
14.
Базовая стандартная документация (Standard Base Documentation) — новым контрибьюторам проекта InnerSource сложно понять, кто поддерживает проект, над чем можно работать и каким образом вносить вклад. Предоставление документации в стандартных файлах, таких как README.md и CONTRIBUTING.md, обеспечивает процесс самообслуживания для новых контрибьюторов, позволяя им самостоятельно находить ответы на наиболее распространенные вопросы.
15.
Сценарии использования трекера задач (Issue Tracker Use Cases) — команда-хост проекта InnerSource не обеспечивает прозрачность не только планов и прогресса, но и контекста изменений. Проблема решается за счет расширения сценариев использования трекера задач проекта, включая мозговые штурмы, обсуждение реализации и проектирование функциональности.
16.
Инструменты коммуникации (Communication Tooling) — пользователи проекта InnerSource испытывают сложности с получением помощи и установлением контакта с командой-хостом. Последовательное использование асинхронных инструментов коммуникации делает обсуждения видимыми, архивируемыми и доступными для поиска, что приводит к повышению уровня поддержки пользователей.
17.
Оценка ценности межкомандных проектов (Cross-Team Project Valuation) — ценность межкомандных проектов InnerSource, которые не оказывают прямого влияния на выручку компании, сложно обосновать. Данный паттерн предлагает основанный на данных способ представления проекта, который позволяет как сформулировать его ценность, так и усилить ее восприятие.
18.
Прозрачное межкомандное принятие решений с использованием RFC (Transparent Cross-Team Decision Making using RFCs) — проекты InnerSource, стремящиеся к высокому уровню участия и принятию наилучших решений для всех вовлеченных сторон, нуждаются в создании специальных систем на протяжении всего жизненного цикла программного обеспечения. Публикация внутренних документов Requests for Comments (RFCs) позволяет начинать обсуждения на ранних этапах проектирования и повышает вероятность создания решений с высоким уровнем вовлеченности и ответственности всех участников.
19.
Начинать как эксперимент (Start as an Experiment) — запуск инициативы InnerSource в формате ограниченного по времени эксперимента упрощает ее одобрение и поддержку со стороны руководителей, не знакомых с InnerSource.
20.
Основная команда (Core Team) — даже в случаях, когда проект InnerSource широко востребован, вклад и использование могут быть затруднены из-за сложности работы с проектом. Создание Core команды, которая целенаправленно занимается базовыми элементами проекта, позволяет упростить участие и использование. Работа такой команды дает возможность контрибьюторам добавлять и использовать функциональность, создающую ценность для их сценариев.
21.
Документируйте направляющие принципы (Document your Guiding Principles) — объяснение InnerSource как применения лучших практик Open Source внутри организации плохо работает для людей без опыта работы с Open Source. В качестве решения ключевые принципы InnerSource документируются и широко публикуются.
22.
Расширения для устойчивого роста (Extensions for Sustainable Growth) — проект InnerSource получает слишком большое количество вкладов, что усложняет его сопровождение. Предоставляя механизм расширений за пределами ядра проекта, мейнтейнеры обеспечивают масштабирование возможностей проекта с минимальными затратами и накладными расходами на сопровождение.
23.
Стандартный процесс релизов (Standard Release Process) — команды могут не решаться использовать проект InnerSource, если не уверены в уровне его зрелости. Для решения этой проблемы критически важны единообразные примечания к релизам и публикация артефактов. Эти практики демонстрируют устойчивую приверженность проекту, формируют доверие и подтверждают долгосрочное обязательство по развитию управляемого и устойчивого программного обеспечения.
24.
Групповая поддержка (Group Support) — что происходит, если команда или отдельный участник перестает поддерживать проект InnerSource? Проект можно сохранить, сформировав группу заинтересованных участников.
25.
Явно определенные уровни управления (Explicit Governance Levels) — разные команды внутри организации используют практики InnerSource по-разному, что приводит к путанице и неэффективности из-за несогласованных ожиданий в отношении взаимодействия и прав на внесение вкладов. Создание централизованно задокументированных уровней управления, определяющих степень влияния команд-контрибьюторов на проект, повышает прозрачность и ясность как для контрибьюторов, так и для команд-хостов.
26.
Модульный код (Modular Code) — отсутствие модульности в архитектуре программного обеспечения препятствует повторному использованию и, как следствие, не позволяет в полной мере получить преимущества InnerSource. Помогая командам понять ценность модульности и выделяя время для движения к этой цели, можно увеличить уровень сотрудничества в рамках InnerSource и в целом улучшить архитектуру программного обеспечения.
27.
Улучшение обнаруживаемости (Improve Findability) — сотрудники не могут находить необходимые им внутренние решения из-за неудачных соглашений об именовании. Это приводит к фрустрации при поиске решений InnerSource и снижению повторного использования кода.
28.
Преодоление временного давления со стороны управления проектами (Overcoming Project Management Time Pressures) — управление проектами исходит из предположения, что давление сроков и обязательства по функциональному наполнению не позволяют разработчикам выделять время, необходимое для создания кода, пригодного для совместного использования, и оказания поддержки.
29.
Введение метрик в InnerSource (Introducing Metrics in InnerSource) — вовлечение всех заинтересованных сторон в проектирование и интерпретацию метрик для измерения текущего состояния инициативы InnerSource с точки зрения ее здоровья и производительности.
30.
Отдельный репозиторий общего кода, отличный от репозитория сборки (Shared Code Repo Different from Build Repo) — работа с накладными расходами, возникающими при хранении общего кода в отдельном репозитории, который не совпадает с проектным репозиторием, используемым для production-сборок.
31.
Портал InnerSource — гигиена (InnerSource Portal – Hygiene) — предоставление возможности генерации официального бейджа для проектов, которые намерены быть признанными проектами InnerSource внутри компании.
32.
Нежелание принимать вклады (Reluctance to Receive Contributions) — владелец общего актива неохотно принимает вклады из-за дополнительных затрат на сопровождение, которые они за собой влекут. Обобщающий паттерн, который описывает четыре дочерних паттерна, три из которых еще предстоит определить.
33.
Вовлечение владельцев продукта (Include Product Owners) — вовлечение и обучение владельцев продукта (Product Owners) принципам InnerSource помогает им корректировать свои действия, например в области KPI, чтобы сотрудничество в рамках InnerSource работало более эффективно.
34.
Поддержка соответствия требованиям (Assisted Compliance) — помощь владельцам репозиториев в обеспечении соответствия требованиям путем подготовки файла CONTRIBUTING.md за них и предоставления его в виде pull request.
35.
Open Source важнее InnerSource (Open Source Trumps InnerSource) — разработчики игнорируют проекты InnerSource, поскольку считают проекты Open Source более предпочтительными. Введение обязательной оценки проектов InnerSource перед выбором open source проекта повышает вероятность того, что проекты InnerSource будут приняты и использованы.
36.
Настройка проекта с учетом уровня управления (Governance Level Guided Project Setup) — перед публикацией своего первого проекта InnerSource команда хочет выбрать подходящий уровень управления (Governance Level), но не уверена в том, как различные уровни повлияют на ее повседневную работу. Специальный перечень ресурсов, включающий лучшие практики, рекомендуемые паттерны и целевые уровни зрелости, предоставляет команде конкретные ориентиры и помогает принять обоснованное решение.
37.
Ограниченный InnerSource (Contained InnerSource) — применение методов InnerSource для облегчения сотрудничества в межподразделенческом проекте без инвестиций в привлечение вкладов со стороны команд и участников, не входящих в рамки данного проекта.
38.
Хороший первый проект (Good First Project) — в организации запущена программа InnerSource, и для успешного старта ей необходимы подходящие первые проекты, которые хорошо соответствуют стилю разработки InnerSource. Оценка готовности проектов к InnerSource (InnerSource readiness, fitness functions) помогает выбрать проекты, обладающие потенциалом продемонстрировать ценность и эффективность InnerSource.
39.
Группа методического сопровождения InnerSource (InnerSource Guidance Group) — сильно различающиеся стандарты разработки в разных командах могут замедлять взаимодействие между ними. Создание группы методического сопровождения InnerSource, которая определяет общие управленческие и поведенческие ориентиры, помогает снизить эти трения.
40.
Единый реестр исходного кода (Unified Source Code Inventory) — в крупной организации с несколькими юридическими лицами часто сложно получить полную видимость всех программных активов, в частности всего исходного кода. Такая ситуация снижает возможности увеличения бизнес-ценности и усложняет контроль затрат и обязательств, например расходов на сопровождение программного обеспечения, в масштабе всей организации. Реестр исходного кода на уровне организации решает эти проблемы и одновременно позволяет выявлять и поддерживать ценные активы InnerSource.
41.
Явно разделенная ответственность за владение (Explicit Shared Ownership) — программный компонент, от которого зависят несколько команд, со временем развивается до состояния, при котором отдельные владельцы больше не способны нести полную ответственность. Возникает неопределенность в том, кого привлекать для внесения изменений. Явное закрепление совместного владения и прозрачное описание ожидаемого поведения устраняют эту неоднозначность. Подготовка документа для контрибьюторов создает естественный механизм эволюции модели владения.
42.
Преодоление мышления Not Invented Here (Overcoming the Not-Invented-Here Mindset) — качественные решения отклоняются из-за синдрома Not Invented Here (NIH). Инженеры и их руководители предпочитают сначала реализовывать функциональность самостоятельно, даже если уже существует альтернативное решение. Сдвиг в сторону культуры Proudly Found Elsewhere помогает снизить негативное влияние NIH.
43.
Баланс между открытостью и безопасностью (Balancing Openness and Security) — несмотря на то, что InnerSource наиболее эффективно работает в средах с высоким уровнем совместного использования кода, функции безопасности и юридического сопровождения (Security/Legal) предпочитают ограничивать доступ к исходному коду только необходимым кругом лиц. Включение представителей Security/Legal в команду, введение явных уровней совместного использования и политик безопасности для общих репозиториев, а также определение того, какая информация считается чувствительной, позволяет упростить совместное использование кода при минимизации сопутствующих рисков.
44.
Преодоление пропасти InnerSource (Crossing the InnerSource Chasm) — ранние эксперименты с InnerSource оказались успешными, однако методы, эффективно убеждавшие первые команды, перестают работать при масштабировании инициативы. Преодоление этой пропасти возможно за счет применения различных подходов для работы с людьми, находящимися на разных этапах кривой принятия инноваций.
45.
Переход к модели InnerSource для кода подрядчиков (Transitioning Contractor Code to InnerSource Model) — контрактные разработчики часто не мотивированы участвовать в активностях InnerSource, которые могут выходить за рамки их контрактных обязательств. Данный паттерн описывает, как сфокусироваться на последующем переводе проекта подрядчика в формат InnerSource за счет явного задания ожиданий по конкретным артефактам и результатам, связанным с InnerSource, в составе общей поставки проекта.
46.
Инкубационный конвейер (Incubator Pipeline) — команда, сопровождающая широко используемую библиотеку общего кода, хочет принимать вклады от других команд, не снижая общий уровень качества библиотеки. Для этого команда использует инкубационный конвейер, который устанавливает более низкий порог для входа вкладов и более высокий порог для выхода и перехода в статус верхнеуровневого компонента библиотеки.
47.
Интервью с внутренними заказчиками InnerSource (InnerSource Customer Interview Questions) — организация приняла решение создать программу InnerSource, но не уверена, какие проблемы следует решать в первую очередь. Использование интервью с внутренними заказчиками помогает выявить болевые точки в масштабе всей организации и расставить приоритеты в тех областях, где InnerSource может дать наибольший положительный эффект.
48.
Формирование стратегии InnerSource (Creating an InnerSource Strategy) — в ряде случаев бывает сложно убедить сотрудников в релевантности InnerSource для организации и получить поддержку со стороны руководства. Создание стратегии InnerSource, которая связывает подход и активности InnerSource с целями и общей стратегией организации, помогает решить эту задачу.
49.
Кодекс поведения (Code of Conduct) — коммуникации и взаимодействия между участниками носят грубый, неинклюзивный или оскорбительный характер, что вредит сообществу и приводит к росту бесполезных обсуждений без добавленной ценности. Кодекс поведения задает правила и ожидания в отношении поведения и взаимодействия внутри сообщества и способствует формированию более высокого уровня сотрудничества.
50.
Ретроспективы доверенных коммиттеров и контрибьюторов (Trusted Committer and Contributor Retrospectives) — команда-хост, работающая с контрибьюторами вне своей линии управленческого подчинения, регулярно сталкивается с недопониманием. В результате взаимодействие становится хрупким и фрустрирующим. Выделение времени для регулярных ретроспектив InnerSource-команды, состоящей из доверенных коммиттеров и контрибьюторов, помогает сделать коммуникацию более устойчивой и прозрачной.
51.
Хакатон InnerSource (InnerSource Hackathon) — на ранних этапах внедрения InnerSource в компании интерес к нему и его практическое применение проявляют в основном энтузиасты, тогда как не все инженерные команды готовы или имеют достаточно времени и ресурсов для его внедрения. В такой ситуации полезно предоставить безопасное пространство для экспериментов и освоения InnerSource в формате внутреннего хакатона InnerSource.
52.
Управление емкостью для ревью вкладов (Managing Capacity for Reviewing Contributions) — проверка вкладов InnerSource требует значительных временных и трудовых затрат. Это должно учитываться при планировании емкости, особенно для крупных вкладов. Ожидания и доступная емкость должны быть прозрачными, чтобы контрибьюторы понимали, когда их вклад будет рассмотрен и, в случае принятия, выпущен.
53.
Амбассадоры InnerSource (InnerSource Ambassadors) — при продвижении InnerSource в крупной децентрализованной организации сложно своевременно понимать и устранять локальные проблемы, возникающие в различных подразделениях и регионах. Локальные волонтеры, называемые амбассадорами InnerSource, обеспечивают поддержку на местах, продвигая принципы InnerSource и выступая коммуникационным мостом между своими командами и ISPO (InnerSource Program Office).
54.
Круговые сообщества (Circle Communities) — внедрение InnerSource в организациях продвигается медленно из-за ограниченного понимания, низкой вовлеченности и недостаточной контекстной релевантности. Паттерн Circle Communities решает эту проблему за счет организации синхронных обсуждений, которые выстраивают связи, закрывают пробелы в знаниях и формируют культуру сотрудничества и непрерывного обучения.
55.
Внутренняя платформа для разработчиков (Internal Developer Platform) — по мере роста внедрения InnerSource в организации проектные команды нередко сталкиваются с неэффективностью масштабирования из-за фрагментированных инструментов, окружений и рабочих процессов. Внутренняя платформа для разработчиков (Internal Developer Platform, IDP) предоставляет способ решения этих проблем за счет централизованной self-service системы, которая стандартизирует окружения разработки и интегрирует инструменты для повышения согласованности, уровня сотрудничества и продуктивности разработчиков.
56.
Документирование архитектурных решений (Document Architecture Decisions) — контрибьюторы InnerSource часто испытывают сложности с пониманием архитектурных решений и логики проектирования системы, что может приводить к рассогласованию между мейнтейнерами, контрибьюторами и стейкхолдерами и, как следствие, снижать готовность к участию. Для повышения прозрачности и качества принимаемых решений рекомендуется фиксировать архитектурные решения и их последствия в легковесном и доступном формате, что упрощает онбординг, проясняет принятые решения и поддерживает долгосрочную устойчивость проекта.
57.
Стимулы и антистимулы InnerSource (InnerSource Incentives and Disincentives) — недостаточная осведомленность о стимулах и антистимулах для участия в InnerSource снижает вероятность получения вкладов в проекты InnerSource. Проблема решается путем публикации и распространения полного перечня возможных стимулов и антистимулов.
58.
Следовать принципам InnerSource на практике (Walk the InnerSource talk) — команды по всей организации поощряются к применению принципов InnerSource, таких как открытая работа, совместное использование кода и прозрачное сотрудничество. Однако если команда, отвечающая за инициативу InnerSource, сама не следует этим практикам, это подрывает доверие и замедляет внедрение. Поэтому такая команда должна подавать пример: документировать решения в виде кода, работать открыто и относиться к своей работе как к проекту InnerSource, чтобы сформировать доверие и показать другим, как это делается на практике.
59.
Обязательный InnerSource перед Open Source (Require InnerSource before Open Source) — сопровождение и управление open source проектами может быть сложным для организаций из-за отсутствия внутренней инфраструктуры и специалистов, обладающих знаниями необходимых практик сотрудничества. Требование прохождения стадии InnerSource перед публикацией проекта в open source дает командам время выстроить внутреннюю поддержку, управление и навыки совместной работы, необходимые для успешного взаимодействия с внешним сообществом.
60.
Контекст для генерации кода с помощью AI (AI Code Generation Context) — AI-инструменты генерируют код, который может не соответствовать стандартам проекта и архитектурным паттернам. Предоставление контекста для генерации кода с помощью AI внутри репозиториев позволяет направлять AI-инструменты на создание вкладов, соответствующих существующим соглашениям проекта, снижая трения при ревью и сохраняя целостность кодовой базы.
61.
InnerSource как усилитель карьеры (InnerSource as a Career Booster) — многие сотрудники задаются вопросом, какую пользу участие в проектах InnerSource приносит их карьере за пределами задач непосредственной команды. Участие в InnerSource позволяет расширять навыки, развивать профессиональные связи, повышать видимость внутри организации и открывать новые карьерные возможности.
62.
Переход от InnerSource к Open Source (Migrating from InnerSource to Open Source) — когда проект InnerSource успешно развивается внутри организации и соответствует критериям внешней публикации, у организаций часто отсутствует структурированный подход к такому переходу. Формирование процесса, охватывающего юридические, безопасностные, управленческие и сообществные аспекты готовности, позволяет перевести проект в open source, сохранив его внутреннюю ценность.
Дополнительно следующие 17 паттернов сейчас находятся в разработке:
1.
Overcome Acquisition Based Silos - Developers2.
Overcome Acquisition Based Silos - Managers3.
Discover Your InnerSource4.
Junkyard Styled Inner Sourcing5.
Incentive Alignment6.
Change the Developers Mindset7.
Change the Middle-Management Mindset8.
Share Your Code to Get More Done - Likely Contributors Variant9.
Code Consumers10.
Explaining InnerSource to Management by anchoring it to Agile / DevOps / Lean11.
Culture Change through Hiring12.
How to Defeat the Hierarchical Constraints13.
Organizational Mindset Change14.
Bad Weather For Liftoff15.
Incentive mechanisms to foster voluntary contribution16.
Duplicated Projects17.
Sustainable InnerSource ProgramАвторы дают рекомендации по применению паттернов. Каждая организация имеет свою собственную историю (контекст, Context), культуру (один из источников сил, Forces), а также цели. Поэтому использование паттернов для решения проблем, как правило, требует их адаптации. Постарайтесь выявить особенности вашей ситуации и соотнести их с контекстом и силами, описанными в паттерне. Проверьте, не требуют ли эти дополнительные ограничения изменений в разделе решения (Solution), чтобы обеспечить работоспособность паттерна в вашем случае.
Авторы также представили паттерны в виде диаграммы связей (
Mind map), чтобы упростить их поиск и применение. Диаграмма классифицирует паттерны в зависимости от различных стадий программы InnerSource в организации (
Begin,
Adopt,
Grow,
Scale), а также от вызовов, которые могут возникать на соответствующих этапах: