Привет! Я Владимир Потехин, разработчик в Т-Банке в ИТ-хабе Нижнего Новгорода. Моя статья — первая в спецпроекте «20 в 20» к 20-летию Т-Банка. Двадцать специалистов из двадцати городов расскажут свои истории в серии статей, чтобы показать, как выглядит наша распределенная ИТ-карта. За эти годы Т-Банк сильно вырос, вместе с ним выросла и инженерная среда: команды работают в разных городах, но остаются частью одного большого процесса.

Я много времени уделяю работе с опенсорсом и искренне за него радею. Люблю опенсорс за ощущение общего дела: когда код не просто пишешь, а вместе с другими улучшаешь, обсуждаешь, докручиваешь и делаешь полезнее.

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

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

Немного истории

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

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

У нас сильный HR Tech: команда выросла из внутренних автоматизаций найма в полноценный продукт, который покрывает весь жизненный цикл сотрудника — от привлечения до развития. Еще есть Marketing Technologies — решения для автоматизации маркетинга, шопинга и рекламы, причем сразу под B2B и B2C, с упором на масштаб и эффективность.

Отдельный стратегический трек — кибербезопасность: делают инструменты защиты инфраструктуры и параллельно развивают AI-ассистента, который помогает с безопасностью и реагированием на инциденты.

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

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

Этот шаг стал первой предпосылкой к тому, что мы начали строить дальше.

Проблема, которую мы хотели решить

Роман Седов, лидер профессии JS

Во время работы с инструментами я регулярно натыкаюсь на что-то, что хочется улучшить: иногда мелкая неконсистентность, иногда фундаментальная проблема, которая замедляет работу в разы. Бывало понятно, к кому идти и как помочь. Но бывало и наоборот: идея внести merge request наталкивалась на стену: проект сложно запустить локально, нужно давать права, менторить с нуля. В итоге разработчики делали локальные костыли или писали свое с нуля — и в обоих случаях идеи и код не переиспользовались.

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

Мне частенько приходилось делать этот выбор — будь то проект для автоматизации рутины, общий линтер или библиотека для работы с AST-деревьями. В девяти случаях из десяти сделать костыли проще. Но проще не значит лучше: я стараюсь сначала смотреть, как можно законтрибьютить. Это принесет пользу и для меня, и для всех, кто использует проект, и для тех, кто придет после. 

Как мы начали

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

Такой шаг нашелся в библиотеках UI-компонентов. У нас есть дизайн-система и четыре ее реализации: React, Angular, iOS, Android. Почти идеальный полигон для иннерсорса: компоненты достаточно изолированы, контрибьют часто закрывает конкретную нужду твоего проекта прямо сейчас, а одно улучшение работает сразу на сотни downstream-проектов.

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

Где иннерсорс приживается лучше всего

Опыт показывает: не все проекты одинаково хорошо подходят для открытого контрибьюта. Лучше всего работает на общих библиотеках и core-инструментах. Там, где ценность контрибьюта очевидна, а компоненты достаточно изолированы, чтобы PR не ронял что-то соседнее. Еще большой интерес вызывают внутренние проекты, которыми пользуются разработчики внутри компании.

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

Как иннерсорс работает у нас

Команда мейнтейнер заводит небольшой конфиг в специальном репозитории с указанием стека, описанием проекта, контактами и ссылками на полезную для контрибьютора информацию. Этот конфиг помогает выстраивать различные автоматизации для аналитики и дополнительной мотивации. Центральный инструмент — доска Иннерсорс. Проекты, открытые для контрибьюта, выкладывают туда задачи с описанием, стеком и контактами. Можно отфильтровать по стеку или проекту, взять интересующую задачу и получить все инструкции.

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

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

Зачем разработчтки контрибьютят

Мотивации у специалистов разные, и хороший процесс должен работать для всех:

• Команда ждет правок в общем проекте вне спринта — контрибьют позволяет не ждать.

• Нужны задачи для перформанс-ревью или заявки на повышение — иннерсорс дает доступ к задачам другого уровня или стека.

• Между проектами появился временной резерв — есть куда его направить с реальной пользой.

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

Влияние на инженерную культуру

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

Со временем это рушит барьеры между командами. Разработчики начинают знать людей за пределами своего непосредственного окружения, и чужой код перестает быть черным ящиком. Если возникает проблема с каким-то инструментом, вместо поиска виноватых и перекладывания ответственности первой реакцией становится вопрос «А могу ли я сам исправить это?».

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

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

Что нужно понимать заранее

Прежде чем открывать проект, стоит честно ответить на несколько вопросов — они сэкономят много нервов потом.

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

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

Иннерсорс плохо закрывает острую нехватку ресурсов — не стоит использовать его с этой целью.

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

Отдельно про мейнтейнеров

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

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

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

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

Что дальше

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

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