Делюсь разговором с Тамарой Щепалкиной, техническим директором МойОфис. В интервью — подробный разбор открытого подхода, реализуемого компанией.

Ваш проактивный выход в open source — яркий и заметный шаг, но почему вы выбрали именно данный момент? Это — определенная стратегия, в том числе с учетом того, что вы анонсировали и дальнейшие шаги в этом направлении?
Это действительно часть стратегии. Компания пришла к этому моменту тогда, когда была готова выйти на новый уровень — уровень полноценного опенсорсного развития.
Развитие проекта в закрытом формате ограничивает его потенциал. Открытый подход даёт больше гибкости: он позволяет подключать сообщество, собирать обратную связь на самых ранних этапах и двигаться быстрее, чем в режиме «внутренней лаборатории». Кроме того, мы видим ценность в том, чтобы продукт мог эволюционировать не только силами одной компании, но и в партнёрстве с другими игроками рынка.
Задач у этого шага несколько. Во-первых, это медийность: мы хотим развивать продукт открыто, вместе с сообществом, а в перспективе — возможно, и с другими компаниями. Во-вторых, это ценность развития собственных отечественных компиляторов.
Если сообщество проявит интерес, мы также готовы в будущем выложить UI-фреймворк.
За счет открытого подхода вы планируете добиться совершенно иной динамики развития компании? С учетом изменений в составе топ-менеджмента?
Компания стабильно развивается, и поэтому мы приняли решение в том числе развивать и опенсорс-направление. Этот шаг связан не только с текущими изменениями в управлении: подобные стратегии обсуждались и при предыдущем, и даже при предпредыдущем составе топ-менеджмента.
Нынешнее руководство также видит в нём ценность. Мы стараемся сохранять преемственность: многие сотрудники, которые стояли у истоков разработки, продолжают работать в компании. А те, кто ушёл, как, например, Владимир Цышнатий, поддерживают с нами активный контакт и вовлечены в развитие продукта. В частности, Владимир расскажет о создании проекта и какие задачи он помогает решать на грядущей флагманской фронтенд-конференции HolyJS.
Какие цели для вас являются ключевыми на данном этапе (допустим, если назвать их «краткосрочными»)? Какие «долгосрочные» цели вы для себя наметили? Что может дать компании, такой как ваша, открытый подход?
Ключевое для нас сейчас — подключить опенсорсное сообщество к развитию наших продуктов. Мы видим в этом не просто обмен кодом, а полноценное партнёрство: разработчики получают доступ к инструментам, которые можно использовать и дорабатывать под собственные задачи, а мы — обратную связь и новые идеи, которые помогают делать продукт лучше.
По сути, это win–win: компании могут быстрее адаптировать решения под свои сценарии, а наша команда — расширять продуктовую линейку, опираясь на реальные запросы рынка. Это выгодно не только нам, но и всему профессиональному сообществу: снижается зависимость от закрытых решений, появляется больше свободы для экспериментов и совместной работы.
Важный фокус на будущее — развитие целой линейки опенсорсных решений. Мы не ограничиваемся одним проектом: наша цель — сформировать устойчивую экосистему, в которой будут и компиляторы, и инструменты для разработки, и, возможно, UI-фреймворки. Всё это позволит российским и зарубежным компаниям работать на более независимой и открытой технологической базе.
Вывод тех или иных решений в open source — выбор конкретных разработок — во многом уникальная история для каждой компании. Как вы определились с тем, что именно открывать и в какой последовательности? Что учитывали?
Вывод тех или иных решений в open source — это действительно уникальная история для каждой компании. Здесь нет универсальной формулы: всё зависит от бизнес-задач, зрелости продукта и того, какую ценность мы хотим донести до сообщества.
Для нас основными стали два фактора. Во-первых, мы понимаем, что открытый релиз даёт продукту совсем другой масштаб внимания и обратной связи. Во-вторых, это инвестиционные перспективы: мы рассматриваем опенсорс как долгосрочное направление, в которое стоит вкладываться, потому что оно усиливает наш бренд, привлекает экспертов и повышает технологическую независимость.
Что касается последовательности — она была для нас достаточно очевидной. Мы решили начать выход проекта с компилятора: это базовый элемент, на котором строится всё остальное. Он формирует фундамент экосистемы и задаёт уровень технологического качества. Следующим шагом мы рассматриваем UI-фреймворк — это уже надстройка, которая раскрывает возможности базовой технологии для прикладных сценариев.
Таким образом, мы идём от «фундамента» к более прикладным инструментам, чтобы шаг за шагом формировать полноценную линейку опенсорсных решений.

Одно из ваших открытых решений — компилятор tsnative, преобразующий TypeScript в нативный машинный код. Расскажите, пожалуйста, он построен на основе сторонних проектов или был разработан в компании с нуля?
Компилятор tsnative действительно был разработан в компании с нуля. Мы изначально не шли по пути форка существующих решений, потому что перед нами стояла задача сделать инструмент под наши конкретные требования к производительности и интеграции с экосистемой продуктов. Поэтому архитектура проектировалась внутри компании, с акцентом на то, чтобы он был максимально адаптивным и удобным для практического использования.
При этом, конечно, как и любой современный проект, tsnative не существует в вакууме. Мы активно использовали открытые библиотеки и наработки сообщества — это нормальная практика: не изобретать колесо заново там, где уже есть отлаженные и хорошо работающие решения. Но ключевые компоненты — от логики трансляции до оптимизаций и интеграции — разрабатывались нашей командой.
И для нас важно подчеркнуть: tsnative — это не «форк с косметическими изменениями», а продукт, в основе которого лежит оригинальная инженерная работа. Именно поэтому мы и приняли решение вывести его в open source: у проекта есть собственная ценность и потенциал для развития, который может быть интересен и полезен гораздо шире, чем внутри одной компании.
Как вы готовили данный проект к выходу в open source? Что считаете важным учитывать на этапе подготовки? На какую аудиторию ориентируетесь с точки зрения развития сообщества вокруг tsnative и как планируете работать с ней?
Для нас ключевым было выпустить проект в таком виде, чтобы он был максимально готов к использованию и безопасен для сообщества. Поэтому на подготовительном этапе мы уделили большое внимание нескольким направлениям.
Во-первых, безопасность. Мы не хотели, чтобы в открытый релиз попал код с уязвимостями. Для этого мы подключили санитайзеры (UndefinedBehaviorSanitizer и AddressSanitizer), прогнали проект через статический анализатор Svace, а также через динамическое сканирование (A-Scan, Y-Scan). На этом этапе мы нашли и устранили ряд потенциальных проблем, чтобы пользователи могли быть уверены в качестве и надёжности проекта.
Во-вторых, юридическая чистота. Мы проработали лицензии используемых библиотек и подготовили полный пакет документов, чтобы у разработчиков не возникало вопросов по правам на использование и распространение.
Третье направление — удобство использования. Мы подготовили Docker-образ, чтобы любой разработчик мог быстро поднять и попробовать компилятор у себя, без долгих манипуляций с окружением. Кроме того, мы обеспечили воспроизводимость сборки и подготовили документацию: короткую, понятную и с рабочими примерами. Мы также сделали демо, чтобы новый пользователь мог увидеть работу инструмента на практике буквально в первые минуты знакомства.
Что касается аудитории, здесь у нас два ключевых фокуса.
Для веб-разработчиков мы хотим дать инструмент, который позволит выйти за рамки привычной браузерной среды и писать код, который компилируется в нативный машинный код. Это расширяет горизонты и снимает ограничения, о которых наши разработчики говорили ещё на самых ранних стадиях проекта.
Для C++-разработчиков мы предлагаем способ ускорить работу над теми частями систем, где критична скорость разработки, но не требуется максимальная оптимизация по производительности. По сути, это даёт возможность экономить время и силы, а потом при необходимости комбинировать быстрые прототипы с более «тяжёлым» кодом.
Таким образом, мы готовили tsnative не просто как «выкладку исходников», а как полноценный проект, с которым можно работать, тестировать, развивать и который сразу же приносит практическую пользу.
В другом вашем открытым проекте — MemLimiter — используется лицензия MIT, но для tsnative вы выбрали Apache 2.0. Можно ли говорить о том, что и последующие открытые проекты компании будут распространяться под Apache 2.0? Считаете ли вы, что выбор лицензий существенно влияет на развитие открытых проектов и сообществ вокруг них?
Выбор лицензии для нас всегда зависит от конкретного проекта и стратегических целей, которые мы перед ним ставим. В случае с MemLimiter мы использовали MIT, потому что это лёгкая, минималистичная лицензия, которая прекрасно подходит для небольших и узконаправленных инструментов.
С tsnative ситуация иная. Мы понимаем, что это более крупный проект с долгосрочной перспективой и, самое главное, с фокусом на развитие сообщества и вовлечение внешних контрибьюторов. Поэтому мы выбрали Apache 2.0. Эта лицензия считается одной из самых открытых и «дружественных» к сообществу. В отличие от MIT, она подробно регулирует вопросы, связанные с авторством и правами контрибьюторов, что очень важно, когда речь идёт о масштабном и живом опенсорс-проекте.
Если сравнивать, то с точки зрения функционала обе лицензии довольно близки: они позволяют свободно использовать, модифицировать и распространять код. Но Apache 2.0 даёт больше гарантий и прозрачности для тех, кто решит вносить вклад, и тем самым снижает возможные барьеры для участия.
Поэтому, отвечая на вопрос о будущих проектах: мы не ограничиваем себя исключительно Apache 2.0 — выбор всегда будет зависеть от характера продукта. Но в случаях, где критично развитие полноценного сообщества и участие сторонних разработчиков, скорее всего, мы будем продолжать использовать именно эту лицензию.
-
Вы много делаете для взаимодействия с технологической аудиторией, в том числе достаточно широким кругом потенциальных сотрудников и энтузиастов. Например, в августе вы выпустили «трёхтомник» по Lua, используемому у вас.
Считаете ли вы, что бесплатный и открыто распространяемый контент, а также семинары и прочие форматы «обучения» аудитории важны и даже критичны для компании, которая развивает открытые технологические проекты?
Если говорить про «трёхтомник» по Lua, то нужно уточнить: это коммерческое издание, но при этом у нас действительно много других образовательных инициатив, которые мы распространяем бесплатно и открыто. Для нас это важная часть стратегии: мы понимаем, что развитие открытых технологий невозможно без подготовки аудитории — как разработчиков, так и студентов, которые только входят в профессию.
Мы уделяем большое внимание взаимодействию с университетами и школами: проводим семинары, курсы, совместные лаборатории. Для студентов и молодых специалистов это шанс получить доступ к современным технологиям и реальным кейсам, а для нас — возможность вовлечь в сообщество новых людей, которые будут в дальнейшем развивать экосистему.
Бесплатный образовательный контент и открытые мероприятия позволяют не развиваться только опенсорс-направлениям, но и стимулируют развитие инноваций и знакомство с лучшими российскими технологиями. Это своего рода «точка входа», которая снимает барьеры и помогает сформировать заинтересованное сообщество вокруг продукта. Ведь мало просто выложить код в открытый доступ — важно, чтобы у людей было понимание, как им пользоваться, зачем он нужен и какие перспективы открывает.
Поэтому мы сделали отдельный продукт, который доступен вузам бесплатно, и ожидаем интерес от молодых специалистов, которые могут дать предложения по улучшению и развитию наших технологий. В частности, начать разрабатывать надстройки и автоматизации для экосистемы МойОфис на языке Lua, который широко используется в наших редакторах.
Что касается будущих активностей — здесь мы пока без спойлеров. По мере готовности будем делать анонсы, но могу сказать точно: образовательное направление для нас останется приоритетным. Мы планируем и дальше развивать контент, практику взаимодействия с университетами и форматы, которые делают технологии более доступными и понятными.
Как вы подходите к работе с code of conduct в плоскости open source?
Мы считаем, что code of conduct — это важный элемент любой серьёзной опенсорс-инициативы. Когда компания выходит в open source, она автоматически становится частью большого сообщества со своими устоявшимися нормами и практиками. Игнорировать это было бы неправильно, поэтому мы изначально ориентируемся на принятые в индустрии правила взаимодействия.
При подготовке проектов мы учитываем и уважаем сложившиеся традиции сообщества: от прозрачности обсуждений до уважительного общения между участниками. По сути, это вопрос не только культуры, но и устойчивости самого проекта. Если внутри сообщества нет правил игры, то рано или поздно это приведёт к конфликтам, снижению вовлечённости и потере интереса со стороны контрибьюторов.
Мы планируем идти по пути, который уже хорошо зарекомендовал себя у крупных проектов: использовать стандартные практики и шаблоны code of conduct, адаптируя их под наши конкретные задачи. При этом мы хотим, чтобы это были не «формальные документы ради галочки», а реально работающий инструмент, задающий атмосферу сотрудничества и взаимного уважения.
В целом для нас важно, чтобы open source развивался не только как код, но и как сообщество, где комфортно и новичкам, и опытным контрибьюторам. Именно поэтому мы смотрим на code of conduct не как на дополнительное требование, а как на естественную часть процесса.

МойОфис бесплатно отдает и оригинальные шрифты ХО_Fonts. Можем ли мы отнести такого рода проекты к вашей общей open source-стратегии? Как вы в целом оцениваете эффект от такого рода активностей?
Да, это тоже часть нашей долгосрочной стратегии, хотя и с несколько иным акцентом. Проект ХО_Fonts также начался ещё во времена Дмитрия Комиссарова и изначально задумывался как вклад в развитие локальной дизайн- и айдентика-среды. Бесплатное распространение шрифтов — это не только про удобство для пользователей наших продуктов, но и про создание дополнительной ценности для профессионального сообщества: дизайнеров, разработчиков интерфейсов, компаний, которые используют кириллицу и другие локальные алфавиты.
Мы действительно относим такие проекты к общей линии «открытости»: это не классический open source в инженерном смысле, но по духу очень близко. Мы делаем доступным ресурс, который обычно бывает закрытым и коммерческим, а значит — снижаем барьеры для тех, кто работает с визуальной частью цифровых продуктов.
Обратную связь мы получаем регулярно — от дизайнерских студий, от разработчиков, от компаний, которые внедряют шрифты в свои проекты. Она нас, честно говоря, более чем устраивает: мы видим реальное использование, благодарности и новые сценарии, которые мы даже не предусматривали. Для нас это показатель, что подобные инициативы нужны и ценятся.
В целом мы оцениваем эффект таких активностей как стратегически позитивный: они формируют вокруг компании имидж игрока, который думает не только о своём бизнесе, но и о развитии всей экосистемы.
Как вы подходите к управлению развивающимся портфелем открытых проектов? У вас организован своего рода open source program-офис или на данном этапе этим занимаются отдельные продуктовые команды, уделяя какую-то часть своего времени открытым проектам?
На данном этапе у нас нет отдельного open source program office как выделенного подразделения. Мы идём более естественным путём: открытые проекты развиваются внутри продуктовых команд, и разработчики уделяют им часть своего времени параллельно с основной работой. Такой подход позволяет быстрее проверять гипотезы и не перегружать структуру лишней бюрократией.
При этом у нас уже выстраивается собственное сообщество вокруг проектов. Мы открыли Telegram-чат поддержки AntiQ и используем его как точку контакта с внешними разработчиками. Там можно, будет следить за новостями, делиться обратной связью, задавать вопросы и обсуждать идеи. Для нас это важный элемент: open source — это не только код, но и люди, которые его развивают, и мы стараемся максимально рано выстраивать живую коммуникацию.
Если активность вокруг проектов будет расти — а мы на это рассчитываем, особенно в случае с tsnative, — мы сможем создать отдельную команду, которая займётся именно open source-направлением. Это позволит системнее работать с контрибьюторами, поддерживать инфраструктуру и координировать развитие портфеля.
По сути, мы идём по пути «от сообщества к структуре»: сначала запускаем проект и формируем аудиторию, а когда видим достаточную вовлечённость — создаём под это отдельную организацию внутри компании.
P.S. Дополнительное чтение — неклассическая литература для руководителей по открытым стратегиям — разбираем свежие научные статьи 2025 года.
Комментарии (2)

Vedomir
06.11.2025 14:55Хорошее и правильно дело. У нас очень многие используют открытые проекты, гораздо меньше людей и организаций участвует в их развитии и еще меньше создают свои новые.
Litemanager_remoteadmin
Не боитесь ли Вы что кто то скопирует Ваш код? для своей разработки, конкуренты например