Делюсь интересным разговором с Олегом Архангельским@olegarhInTheHabrahabr, руководителем департамента разработки Мессенджеров и ВКС МойОфис и руководителем проекта AntiQ. Олег рассказал об открытом подходе в компании.

• По следам нашей первой беседы хотел бы раскрыть новые, не менее важные аспекты открытого подхода, который вы развиваете в компании. Вы рассказывали о работе с контентом — и сейчас у вас в технологическом блоге выходят и туториалы, и материалы об опыте управления организацией, в т.ч. в контексте открытого подхода. Считаете ли вы это «контентной» или «маркетинговой» частью open source-стратегии?

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

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

История вокруг нашего проекта AntiQ хороший пример. Если смотреть на него поверхностно, можно сказать: «ещё один TypeScript-стек». Но по сути идея другая: изменить модель исполнения TypeScript — отказаться от зависимости JavaScript-runtime и перейти к прямой компиляции в исполняемый код, работающий непосредственно поверх операционной системы.

Классический TypeScript (как и JavaScript) исполняется на движке внутри браузера или окружения, симулирующего браузер, например, Node.js. AntiQ задумывался как способ убрать этот промежуточный слой и запускать приложения напрямую на компьютере — без браузера и других дополнительных сред и языков, с полноценным доступом к ресурсам ОС и, соответственно, без штрафа к скорости. Разбор таких технологических развилок — это и есть та самая «контекстная открытость», продолжающая open source-стратегию.

• Продолжая тему контента, хотел бы спросить, делитесь ли вы планами разработки? Допустим, в roadmap-файлах или в формате досок с задачами.

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

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

Особенно это важно для таких инициатив, как AntiQ: в компилируемом мире у аудитории сразу возникает набор ожидаемых вопросов — про поддержку платформ, зрелость SDK, производительность и экосистему библиотек. Roadmap помогает честно показать: что уже есть, что в работе, а что пока на горизонте.

• Как у вас организована верхнеуровневая информация об участии компании в open source (и способах присоединиться к такой работе)?

Исторически наша работа с open source действительно развивалась волнами. Сначала это были точечные инициативы, например, открытые шрифты или отдельные артефакты под конкретные задачи. Затем появились вспомогательные инструменты и отдельные репозитории, которые возникали вокруг внутренних потребностей команд.

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

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

• В первом интервью мы затронули тему code of conduct. Механизмами управления взаимодействием с сообществом могут быть contributing-гайды и проч. Опять же, у кого-то такие «правила» лежат в репозитории в соответствующих файлах, у других — как-то иначе оформлены. Как у вас?

Пока это как раз та область, где мы честно признаём: нам есть куда расти. Contributing-гайды у нас развиты недостаточно и во многом фрагментарны. Мы понимаем, что для внешнего контрибьютора критически важно с первых шагов видеть понятные «правила игры»: как заводить issue, как оформлять pull request, по каким принципам происходит код-ревью, какие требования к качеству кода, тестам и документации, и как принимаются решения в проекте. Наша задача — привести всё это в структурированный и прозрачный вид. Причём не «для галочки», а так, чтобы правила реально отражали практику.

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

• Есть мнение, что для российских норм и законов стоит адаптировать CLA (contributor license agreement). Делаете ли вы такие адаптации и кастомные CLA или ограничиваетесь традиционной англоязычной версией?

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

• Если говорить о совместном развитии открытых решений, вы говорите, что хотели бы сотрудничать с другими игроками рынка. Есть ли у вас примеры такого сотрудничества, когда вклад в ваши проекты идет централизованно от других организаций, а не от отдельных сотрудников внешних структур?

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

Проект AntiQ — это амбициозная идея: создать компилируемый стек, который сочетает удобство скриптовых языков и при этом остаётся “ближе к железу” — на уровне возможностей относительно низкоуровневого C++. Сделать это без промежуточных языков и в рамках одного цельного артефакта крайне сложно. В мире есть примеры, которые решают похожие задачи (часто вспоминают Qt/QML как большой технологический фундамент), но для нас важно иметь собственное ядро, которое можно развивать совместно.

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

• Есть ли у вас программы поддержки open source-разработчиков?

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

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

• Можно ли говорить о том, что позиция и вклад основателей компании и её руководства в развитие open source — и своего рода open source-евангелизм с их стороны — помогает вам развивать свои открытые проекты?

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

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

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

• Могли бы вы дать какой-то call to action для аудитории — в каких ваших открытых проектах сейчас больше задач, с которыми она могла бы помочь, как присоединиться к такой работе? С чего начать?

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

Кроме того, в проекте есть баги и функциональные пробелы. Но важно правильно понимать, где именно находятся «инженерные точки приложения усилий». Сам по себе TypeScript-компилятор — это инструмент, с помощью которого можно собирать приложения. А большая часть практических задач возникает уровнем выше — во фреймворке и библиотеках, которые позволяют эти приложения реально писать: UI, файловая система, ресурсная система, примитивы для сложных и быстрых интерфейсов, в том числе отображающих большие объёмы данных. Этим как раз занималась команда, которая работала с AntiQ как с платформой для приложений.

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

Telegram-канал для нас — первый и самый быстрый шаг: способ собрать первых заинтересованных людей, начать диалог и получить живую обратную связь на раннем этапе. У нас уже есть первый опыт публичного рассказа о проекте. Недавно наш бывший коллега выступал с докладом на HolyJS, где рассказал о том, зачем мы создавали этот проект и какие задачи он решает. Кроме того, мы обсуждали проект в нашем YouTube-шоу «АйТир Лист», а также выпустили статью на Хабре по следам этого выпуска.