Как red_mad_robot развивает свою опенсорс-экосистему — от Android и iOS инструментов до AI-систем и агентных фреймворков

На днях @sW1ft — Сергей Иванов, Head of Android red_mad_robot — поделился со мной подробностями об открытых проектах и open source-стратегии компании, её целеполагании и результатах в данной сфере. Получилось развернутое интервью с примечательными инсайтами, а также примерами и комментариями по теме.

• Вы работаете на рынке уже 17 лет — в какой момент вы решили: «Теперь мы идём в open source?». Что стало ключевым фактором? Какие цели у вас есть?

Мы начали делать первые шаги в open source уже в ранние годы существования компании. Для нас было важно напрямую взаимодействовать с сообществом разработчиков, чтобы укрепить технологический бренд и показать экспертизу. Open source, как и публикация статей, и выступления — идеально подходят для этого. Мы демонстрируем индустрии и партнёрам, как решаем сложные технологические задачи, а также качаем HR-бренд для привлечения талантливых инженеров.

• Если говорить на конкретном примере, у вас есть открытый проект Konfeature для оптимизации работы с Feature Flags. Рассматривали ли вы другие модели его развития? Почему в итоге решили отдать его в open source?

Библиотека Konfeature разработана для удобной стандартизированной работы с Remote Config, в частности, с Feature Flags. Существующие на рынке решения, включая предшественника Konfeature — библиотеку Flipper, не удовлетворяли нашим новым потребностям. Мы сочли Konfeature удачной и полезной для сообщества, поэтому решили поделиться библиотекой в open source.

• В контексте Konfeature: вы рассчитываете на вклад сообщества в его развитие или же также есть и другие цели? Возможно, это некий экспериментальный выход в open source и планируется продолжать эту историю?

Konfeature — наша первая экспериментальная библиотека на Kotlin Multiplatform. Пока что она поддерживает только Android, но в ближайшее время мы добавим полноценную поддержку iOS. Планируем развивать библиотеку, в первую очередь, собственными силами, так как сами используем её в работе, но всегда приветствуем вклад внешних контрибьюторов.

• В вашем репозитории есть несколько других инструментов, таких как input-mask-android или FigmaExport, которые решают узкие, но важные задачи. Как рождаются такие проекты — возможно, это ответ на внутренние потребности команды или это — творческие инициативы разработчиков, которые потом интегрируются в рабочий процесс — как, например, Smarty, выросший из пет-проекта? К слову, есть ли в планах передать компоненты Smarty в open source?

Наши решения рождаются и как ответ на внутренние потребности компании или команд, например, Gears, и как творческие инициативы разработчиков, к примеру, Gradle Infrastructure. Нередко эти факторы совпадают — это наиболее благоприятная ситуация. Творческие инициативы разработчиков часто раскручиваются на базе внутренних потребностей команд, возникающих в ходе работы над задачами бизнеса. Тот же Smarty вырос из пет-проекта и стал коммерческим продуктом — у нас нет цели выкладывать его в open source. В будущем планируем публиковать в open source другие AI-проекты.

• У вас на Хабре множество материалов, посвященных проектам и трендам в сфере ИИ — вы в том числе разбираете клиентские кейсы. Ведется ли какая-то работа с open source в этом направлении вроде дообучения открытых моделей? Возможно, вы готовитесь открывать (или уже) свои решения по данной теме?

Валерий Ковальский

Head of AI red_mad_robot, @kekslop

• Вы в целом много и регулярно взаимодействуете с аудиторией (на Хабре и в других медиа). Расскажите, так ли значимо такое взаимодействие для «обучения» широкой аудитории тому, что вы делаете в плоскости open source? Как такая проактивная работа с аудиторией влияет на развитие компании?

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

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

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

• Ваши стайл-гайды по Kotlin, Markdown и именованию ресурсов опубликованы под открытой лицензией. Что стояло за этим решением?

И упростить онбординг, и привлечь внимание коммьюнити к нашим стандартам качества, и получить развивающую обратную связь. К примеру, Kotlin Style Guide мы составили в 2017 году, еще до появления Kotlin Style Guide от Google, поскольку Kotlin Coding Conventions от Jetbrains покрывали слишком мало кейсов — в исчерпывающем стайл гайде была потребность как у нас, так и у комьюнити, и мы решили её закрыть. В последствии наш стайл-гайд претерпевал изменения и по сей день служит расширением официальных гайдов. Поскольку правила в стайл-гайдах могут варьироваться из-за субъективных предпочтений, мы сразу допустили, что некоторые команды в комьюнити захотят внести локальные корректировки для себя, при этом придерживаясь наших основных правил.

• Как вы принимаете решение о выводе того или иного инструмента в open source? В качестве основного репозитория вы используете GitHub, или уже размещаете проекты и на других площадках?

Мы выносим решение из проекта, когда его уместно распространить на множество проектов в виде внешней зависимости — часто это становится ясно ещё на этапе проектирования решения проблемы. Далее есть три пути: в зависимости от сложности решения, его потенциальной пользы для внешнего комьюнити, а также коммерческих перспектив — мы либо сразу выносим решение в open source, как, например, некоторые мини-библиотеки из репозитория Gears для Android, либо проводим инкубацию с возможной последующей публикацией в open source, как с изначально внутренней библиотекой Debug Panel для Android, либо делаем коммерческий продукт, например, Daisy. Вся работа R&D-лаборатории AI-направления, не касающаяся коммерческих проектов, выкладывается в open source, согласно стратегии направления.

Сейчас наш open source публикуется только на GitHub: общий аккаунт, RnD, AI-проекты.

• Ранее вы рассказывали, что не только разработали свою открытую библиотеку Android Gallery, но и внесли правки в проект PhotoView — ваш Pull Request был принят. Систематизируете ли вы подобную контрибьютерскую активность компании? Как вы могли бы оценить регулярность подобных активностей? Если возможно, расскажите, пожалуйста, и о других примерах контрибьютерства?

Контрибьюторство в чужие open source проекты ситуативно: в основном когда сталкиваемся с проблемой во внешнем инструменте, либо когда можно расширить функционал и оптимизировать его реализацию. Если время не ждёт, делаем локальный воркэраунд или улучшение для получения желаемого здесь и сейчас, а параллельно проводим контрибьют. Мы приветствуем такую активность, но не систематизируем её.

Из того, что вспомнилось: были контрибьюты в androidx.navigation, Detekt, Kotest с исправлениями и расширениями их API. Если не готовы предложить целевой код с решением проблемы, заводим issue или добавляем информацию в существующие issue.

В AI-направлении основная контрибьюторская активность связана с экосистемой vLLM и смежными инструментами. Когда у нас производительность в продакшене на Qwen3-30B упала до 4 токенов/с, мы не просто нашли воркэраунд, а подробно задокументировали проблему и предложили архитектурные улучшения в подходе к валидации ограничений.

Также контрибьютим в обсуждения вокруг MCP (Model Context Protocol) — протокола для интеграции AI-агентов с внешними системами. Мы используем MCP в реальных проектах для интеграции Confluence и е-commerce систем, поэтому активно участвуем в дискуссиях про точки расширения и лучшие практики.

Регулярно делимся находками через GitHub issues и pull requests в проектах Atomic Agents, Guidance и других фреймворков, которые используем в продакшене. Недавно помогли с диагностикой проблем со стримингом в одной из библиотек, где отправлялись полные снапшоты вместо дельта-чанков, что давало пятидесятикратный оверхед на сеть.

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

Так исторически сложилось, что основной вклад в open source со стороны нашей компании был сделан практиками Android и iOS. Недавно активно подключилось направление AI. Распределение ресурсов в каждой практике зависит от того, какой приоритет open source отдаёт руководитель практики, наличия подходящих кейсов, инициативности и загруженности сотрудников основными задачами. Если говорить о практике Android, то мы стараемся привлекать к работе над open source или, по крайней мере, над внутренними библиотеками большинство разработчиков.

Валерий Ковальский

Head of AI red_mad_robot, @kekslop

• Есть ли у вас какой-либо центр координации открытых проектов (или open source program-офис)? Возможно, этим занимается кто-то один из сотрудников или небольшая команда?

У нас нет централизованного управления всем open source компании и фиксированной команды для этого. Управление лежит на руководителях практик. Сейчас активнее всего работу с open source организую я в практике Android и немного за её пределами, и Валерий Ковальский в практике AI. Стать участником open source движухи может каждый сотрудник без какой-либо бюрократии.

При необходимости кросс-коммуникации руководители практик сами связываются между собой или привлекают сотрудников своих команд. Например, Konfeature является проектом практики Android, но мы хотим сделать инструмент универсальным, добавив поддержку iOS, а это требует синхронизации с практикой iOS — Android-разработчик, занимающийся адаптацией, связывается с iOS-разработчиками, чтобы учесть пожелания и услышать рекомендации, затем реализация валидируется обеими практиками. Во время создания Figma-Export iOS консультировался с Android. Для кросс-координации практик проводятся технические встречи и доклады, распространяется документация. Скажем, когда мобильные практики интегрируют AI-функции или инструменты в свои проекты, они обращаются к AI-практике, чтобы вместе определить, как лучше решить задачу.

В рамках AI-направления существует R&D-лаборатория, созданная специально для развития AI-продуктов. Руководитель AI одновременно является и мейнтейнером основных open source проектов. У AI-направления есть публичный роадмап в GitHub для SGR Agent Core и активное комьюнити в телеграм-канале, где обсуждаются feature requests и архитектурные решения, а на регулярных трансляциях руководитель AI показывает процесс разработки. Это создает прозрачность и вовлекает сообщество в принятие решений.

• Расскажите, пожалуйста, о своем подходе к выбору лицензий для открытых проектов. Что в этом плане для вас является приоритетом?

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

• Что уже дает опенсорс-подход red_mad_robot?

Мы видим, что вклад в open source в течение многих лет положительно влияет на привлечение талантов в компанию, лояльность кандидатов и развитие наших сотрудников.

Есть явное влияние и на уверенность партнёров и клиентов в нашей экспертизе, которое особенно ярко в последнее время проявляется в AI-направлении. Когда мы предлагаем корпоративному клиенту развёртывание локальной AI-системы за миллионы рублей, возможность посмотреть код на GitHub и увидеть 900+ звёзд, активное сообщество и мощные показатели производительности — это серьезный фактор в принятии решений. Клиенты видят, что это не чёрный ящик с зависимостью от поставщика, а проверенное сообществом решение.

Также open source критичен для AI-сообщества в России из-за санкционной действительности. Западные фреймворки типа LangChain завязаны на заблокированный API OpenAI. Наш SGR работает с локальными моделями, что востребовано в российском корпоративном сегменте, где есть и опасение санкций, и требование конфиденциальности данных. Через open source мы показываем, что есть жизнеспособная альтернатива без зависимости от западных API.

Конкретный пример: после выступления на TechWeek к нам обратилось три банка и два телеком оператора, в первую очередь, потому что они увидели SGR Agent Core на GitHub и его показатели производительности, где маленькие модели обгоняют GPT-4. Для них это было доказательством, что технология работает и ее можно распространять внутри без риска блокировки API.

• По вашим ощущениям, насколько важно потенциальным сотрудникам, заказчикам и партнерам видеть, что компания вкладывается в open source?

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

Упомянутый пример с обращением к нам нескольких компаний после выступления на TechWeek хорошо демонстрирует важность вклада в open source — он придаёт уверенности потенциальным клиентам и партнёрам в качестве наших решений и экспертизе.

• В качестве завершения предложил бы порассуждать о будущем open source в России. Какие практические шаги нужны, на ваш взгляд, для дальнейшего развития? Как вы сами планируете участвовать в развитии open source?

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

Мы продолжим планомерно развивать решения для мобильных разработчиков и хотим выходить в open source по направлению backend.

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

Конкретные шаги, которые планируем в open source по AI:

Во-первых, продолжать развитие SGR Agent Core как полноценной платформы. Мы движемся к тому, чтобы любой разработчик мог за день собрать промышленного агента под свой сценарий, используя наш фреймворк. Это включает инструменты для мониторинга, отладки, оптимизации стоимости локальных развёртываний.

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

В-третьих, работа с государством для создания благоприятных условий развития open source в сфере AI. Это включает поддержку вычислительной инфраструктуры для обучения и инференса, налоговые льготы для компаний, которые контрибьютят в open source, может быть, даже государственные гранты на развитие критичных AI-компонентов, которые вскоре будут нужны повсеместно.