На днях @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 в этом направлении вроде дообучения открытых моделей? Возможно, вы готовитесь открывать (или уже) свои решения по данной теме?
У нас несколько направлений активности в open source по AI.
Первое — SGR Agent Core, наш флагманский проект. Это полноценный фреймворк для построения агентных систем с Schema-Guided Reasoning архитектурой. Ключевая идея в том, что мы используем явно определенные схемы (Pydantic models) для управления reasoning процессом агента, комбинируя возможности нейросетей с детерминированной логикой. Результаты говорят сами за себя: 86% на SimpleQA бенчмарке, #7 место глобально и #3 среди open source решений, при этом мы используем модели в 10-30 раз меньше и дешевле GPT-4.
Проект активно используется в продакшене у наших клиентов. Например, для Билайна мы построили AI-систему, которая подняла NPS с 7.8 до 9.5 и снизила повторные вопросы на 80%. А для себя создали систему поиска по внутренней документации через интеграцию с Confluence.
Второе направление — инфраструктурные решения. Мы активно контрибьютим в экосистеме vLLM, работаем с оптимизациями XGrammar для structured outputs, где у нас были серьезные performance bottlenecks (падение с 80-100 токенов/с до 4 токенов/с из-за ограничений на длину строки). Разработали платежный шлюз решения для доступа к AI-моделям в российских реалиях с конвертацией рубли-доллары и комплаенсом для регулируемых индустрий.
Третье — специализированные агенты и инструменты. Commerce агент для российского рынка ритейла, агенты с возможностью вечной памяти, Confluence integration агенты для управления корпоративными знаниями. Все эти решения мы открываем в open source, потому что они решают общие проблемы AI-интеграции в энтерпрайзе.
Наша цель — не просто выпустить код, а создать экосистему вокруг промышленного AI для российского рынка, где невозможно просто взять API OpenAI из-за блокировок. SGR Agent Core используется не только нашими клиентами — проект форкнули 160+ раз, его развивает активное комьюнити в Telegram и регулярные контрибьюции от внешних разработчиков. Мы видим, что это становится стандартом для агентских систем в России.
Также я веду публичную активность — телеграм-канал Neural Deep уже набрал 10 тыс. подписчиков. Регулярные выступления на TechWeek и других конференциях, собственные митапы, где мы обсуждаем архитектурные паттерны и делимся продакшен-опытом, помогают формировать базу знаний вокруг AI-систем и привлекать талантливых разработчиков в комьюнити.
Честно говоря, открытость для нас не альтруизм — это стратегия. Мы конкурируем с западными фреймворками типа LangChain/LangGraph, которые доминируют глобально, но не работают в российских реалиях. Открывая SGR, мы создаем экосистему, где разработчики видят, что есть работающая альтернатива, адаптированная под локальные модели, санкционные ограничения и корпоративные требования по конфиденциальности данных. Это наш способ завоевания рынка — через внедрение продукта в сообщество.
Вы в целом много и регулярно взаимодействуете с аудиторией (на Хабре и в других медиа). Расскажите, так ли значимо такое взаимодействие для «обучения» широкой аудитории тому, что вы делаете в плоскости 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 или, по крайней мере, над внутренними библиотеками большинство разработчиков.
В AI-практике другая модель, нежели в мобильной разработке.
Поскольку я возглавляю R&D-лабораторию из шести человек, которая появилась только в апреле 2025, у нас более сконцентрированный фокус на open source как ключевой активности, а не сайд-проекте. Мы целенаправленно строим SGR Agent Core как платформу, которая будет использоваться и внутри компании, и внешними клиентами.
Распределение примерно такое: 60% времени уходит на разработку SGR Core и экосистем вокруг него, 30% на промышленное развёртывание для клиентов типа Билайн, 10% на исследование новых подходов и бенчмаркинг. Open source является основой для всех трех направлений — мы не разделяем внутренний и внешний код — всё, что мы строим, потенциально может стать частью публичного фреймворка.
Каждый в команде работает и с open source проектами, и с client deployments, потому что это дает необходимую петлю обратной связи. Когда видишь, как твой код работает в продакшене у телеком-оператора с миллионами пользователей, понимаешь, какие архитектурные решения правильные, а какие нет. Эти инсайты мы потом выносим в open source через публикации.
Есть ли у вас какой-либо центр координации открытых проектов (или 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-компонентов, которые вскоре будут нужны повсеместно.
