InnerSource мне, как инженеру, очень симпатизирует, потому что позволяет сделать цепочку поставки бизнес-ценности децентрализованной. При всей красоте этого подхода у него есть трудности в реализации. Эти сложности можно разделить на технические и организационные. И те и другие «лечатся», если знать о правильных подходах.

В статье я описал, какие преимущества даёт InnerSource, какие есть проблемы с его внедрением и как микросервисная архитектура помогает решить часть этих проблем автоматически. Статья состоит из следующих разделов:

1. Зачем вам InnerSource.

2. Пять шагов при работе по InnerSource.

3. Помощь микросервисов в преодолении технических барьеров.

4. Организационные проблемы InnerSource и их решения.

5. Модель зрелости и метрики.

6. Рекомендации к использованию.

Для тех, кто любит смотреть, а не читать, слайды и видео с конференции ArchDays.

1. Зачем вам InnerSource

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

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

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

Мириться с этой ситуацией не нужно, а необходимо использовать InnerSource. Это поможет «протолкнуть» вашу задачу в релиз соседней команды.

Характеристики InnerSource

Вот основные требования для организации InnerSource у вас в компании:

1. Исходный код всех проектов доступен для чтения всем сотрудникам компании.

2. Любой может стать контрибьютором в репозиторий с помощью pull request.

3. Core Team принимает изменения извне и следит за целостностью IT-продукта.

Сценарий работы по InnerSource

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

1. Управление приоритетами в бэклоге для того, чтобы понять, можно ли взять в работу внешнюю задачу.

2. Выяснение требований по новой фиче.

3. Согласование плана работ между своей и внешней командой.

4. Разработка фичи силами своих разработчиков, аналитиков, QA, DevOps, дизайнеров.

5. Сбор обратной связи от внешней команды на тему «а то ли мы сделали?». Если выяснится, что сделали не совсем то, что требовалось, то идём по кругу.

Ну а если у вас уже настроена работа через InnerSource, какие шаги вы проходите:

1. Анализ pull request от внешней команды.

2. Добавление кода pull request в свой код либо отказ и написание рекомендации для исправления.

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

2. Пять шагов при работ по InnerSource

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

Давайте подробно рассмотрим пять шагов, которые разработчик пройдёт с InnerSource:

Нужно отдавать себе отчёт в том, что ступор разработчика на любом из этих этапов приводит к тому, что InnerSource в компании «не взлетает». Обратите внимание на каждый барьер и способы этот барьер убрать, чтобы у вас получилось обеспечить для разработчика приятный опыт работы по InnerSource.

2.1. Поиск нужного репозитория

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

Для облегчения этой задачи вам понадобится, чтобы у каждого репозитория было:

1. Структурированное описание в самом репозитории. Обычно для этого используют файл README.md. Важно, чтобы это описание было однообразным на всех проектах внутри компании, тогда в нём будет легче разобраться и найти нужное.

2. Актуальная высокоуровневая IT-архитектура на весь ландшафт. Это поможет разработчику быстрее найти точки приложения сил.

3. Удобный инструмент коллаборации и обмена репозиториями, например github. Другими словами, нужна платформа, где будут видны все репозитории и есть возможность делать поиск.

2.2. Запуск проекта локально

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

Поэтому Core Team должна сделать следующее:

1. Всю инфраструктуру описывать в коде (IaC) и хранить её вместе с кодом проекта.

2. Использовать docker-контейнеры или аналог, чтобы внешний разработчик не зависел от окружения конкретного компьютера с его настройками ОС.

3. Дать доступ ко всем нужным инструментам разработки своего проекта.

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

2.3. Внесение изменений

Если вы хоть раз брали исходный код чужого проекта, то вы понимаете, что чувствует разработчик, решивший отправить pull request в неизвестный ему репозиторий. Разбираться в чужом коде обычно довольно сложно. Поэтому вам нужно позаботиться о его времени и силах разработчика, которые он потратит на разбор исходников.

Для этого у проекта должно быть следующее:

1. Актуальная документация, по которой понятна структура проекта и основные идеи, на которых он выстроен.

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

3. Модульные и другие тесты, благодаря которым получается быстро разобраться со сценариями работы кода.

4. Доступны инструменты разработки.

5. Доступна и понятна актуальная IT-архитектура проекта.

6. Если у сервиса, который меняют, есть API, то необходим доступ к его описанию и возможность попробовать API в действии. В идеале надо использовать такие инструменты, как Swagger.

2.4. Проверить, нет ли поломок

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

Чтобы снизить неопределённость в этом вопросе, нужно:

1. Качественное автоматизированное тестирование на уровне кода и желательно e2e-тесты.

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

2.5. Сделать pull request и релиз

Наконец, когда нужный репозиторий найден, система развёрнута, внесены изменения и прошла проверка на ошибки, настаёт момент сделать pull request в этот репозиторий.

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

Чтобы этот этап прошёл гладко, позаботьтесь о следующем:

1. Для внешнего разработчика и Core Team нужен удобный инструмент коллаборации. За эталон можно взять работу с пул реквестами на github.

2. Чтобы Core Team не мучилась с выпуском релиза, а он проходил без проблем и быстро, нужна тотальная автоматизация CI/CD.

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

3. Помощь микросервисов в преодолении технических барьеров

Возможно, вам повезло, и у вас в компании уже есть настоящие микросервисы. Обратите внимание, что речь не о микросервисном монолите.

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

1. CI/CD, тотальная автоматизация инфраструктуры. Контрибьютору не надо читать сложные инструкции и делать что-то вручную.

2. Контейнеры, IaC.. Контрибьютор может быстро развернуть сервис на своём компьютере.

3. Мониторинг, трассировка запросов, логирование, автоматизация тестирования. Core Team не страшно принимать и апрувить pull request.

4. Чистый API, компилируемые контракты (proto), swagger. Контрибьютор и Core Team легко понимают, как и где будет меняться API сервиса и на кого эти изменения повлияют.

5. Паттерны проектирования кода и взаимодействия сервисов: CircuitBreaker, TolerantReader, GracefulDegradation и так далее. Чтобы было легче разобраться, какой сервис за что отвечает, и не бояться поломать всё вокруг.

Таким образом мы снимаем часть барьеров:

Остались ещё области для работы, но, согласитесь, вы начнёте внедрение InnerSource не с нуля. Поэтому, если у вас есть правильные микросервисы, используйте это как трамплин для перехода на InnerSource.

4. Организационные проблемы InnerSource и их решения

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

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

4.1. Бонусы за фичи

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

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

4.2. Ответственность контрибьютора

Представьте себе ситуацию, что пару месяцев назад вам прислали пул реквесты, вы их приняли и сделали релиз. Но здесь выяснилось, что в изменениях были ошибки. Кто в этом случае должен заниматься исправлением?

Проблема в том, что контрибьютор может быть занят и не иметь в этот момент желания уделять время вашему проекту. Раньше он сделал это добровольно. Он когда-то пришёл решить свою задачу, отправил пул реквест, свой вопрос закрыл и теперь занимается совсем другим.

Если исправление подобных проблем возложить целиком на Core Team, то в какой-то момент она может захлебнуться от потока багов, которые были вызваны многочисленными пул реквестами.

Я рекомендую заранее договориться внутри компании об ответственности за создание pull request и его принятии. Все должны согласиться с правилами игры, чтобы у вас были законные основания вернуть контрибьютора в проект или, наоборот, выделить больше времени для Core Team на исправление ошибок.

4.3. Высокий порог вхождения

Мы наблюдали такой эффект, что начинающим и слабым разработчикам оказывается закрыта возможность делать пул реквесты. Им сложно разобраться в разных проектах и понять, куда и как вносить изменения. Даже если они всё-таки сделали пул реквест, то Core Team может возвращать его десятки раз, что тоже негативно влияет на контрибьютора.

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

С такими разработчиками нужно отдельно работать: выявлять их и помогать им повышать инженерный уровень. Кроме этого, можно включать автоматический сбор метрик кода и покрытия тестами в CI. Это даст возможность разработчику, который отправил свои изменения в ветку репозитория, получить быструю обратную связь о качестве своего кода. Согласитесь, что получать негативный фидбек от CI психологически гораздо легче, чем получать его от сеньор-разработчика.

4.4. Планирование релизов

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

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

4.5. Вместо жалоб — пул реквест

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

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

4.6. Нет исходного кода

Для нас самих это было неожиданностью, но не у всех систем, в которые хочется контрибьютить, есть исходный код. Например, исходного кода нет во многих BPM-движках и CRM-системах.

Тем не менее, как я писал недавно, в low-code решениях тоже можно использовать InnerSource. Само понятие pull request будет иным, но суть останется такой же. Вы будете вносить изменения не в код, а в визуальную схему бизнес-процесса. При этом вам придётся чуть плотнее повзаимодействовать с командой сервиса, в который вы контрибьютите, потому что зачастую в low-code платформах очень плохо реализована система контроля версий.

4.7. Слишком много технологий

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

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

4.8. Проблемы с доступом для внешних подрядчиков

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

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

5. Модель зрелости и метрики

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

1. Transparency

   • Plans and Products

   • Development Process and Tools

   • Decisions

   • Helpful Resources

   • Stories

2. Collaboration

   • Channels for Providing Feedback

   • Leadership

   • Organizational and Functional Structure

   • Contribution

3. Community

   • Sharing Policies

   • Feel part of the Organization

4. Governance

   • Rewards

   • Monitoring Policies

   • Support and Maintenance

   • Culture

   • InnerSource Roles

Желательно организовать оценку зрелости InnerSource для каждой команды, чтобы вы периодически получали отчёт о том, как идёт внедрение понимания этого метода в компании в целом.

Отдельно хочется сказать про Governance Monitoring Policies. По себе знаю, что сложно самому придумать метрики оценки InnerSource, а цифры всё-таки полезны для отслеживания динамики. Поэтому предлагаю вам подсказку в виде списка Some Examples of Interest. Возьмите из него метрики, актуальные для вашего бизнеса, сделайте из них дашборд и периодически обновляйте, чтобы понимать, как продвигается активность по использованию InnerSource.

6. Рекомендации к использованию

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

Учтите, что если у конкурентов получилось внедрить InnerSource, то они окажутся впереди. Поэтому не откладывайте внедрение этой практики, используйте уже сейчас лучшее, что придумало IT-сообщество.

Ссылки

1. A comparative study of challenges in integrating Open Source Software and Inner Source Software

2. Книга Getting Started with InnerSource

3. Collaborate through social coding

4. Паттерны InnerSource

5. Сообщество, статьи, learning path и многое другое