Делюсь разговором с @poxvuibr — Ильей Сазоновым, директором по продуктам Axiom JDK, направления Axiom Spring и OpenIDE. Мы обсудили особенности открытого подхода компании.
Илья, поделитесь, пожалуйста, небольшим рассказом о своей экспертизе. Будет полезно для аудитории — в т.ч. узнать об опыте работы над открытыми проектами.
Моя экспертиза — это бэкенд. Не всегда Java, но в основном. Я этим занимаюсь около 20 лет, поэтому работа с открытыми технологиями — это норма, конечно. Еще до Axiom JDK мы делали проект, где была библиотека, с помощью которой мы генерировали PDF-документы. Тогда мы столкнулись с проблемой — документы с кириллицей превращались в птичий язык. После долгих поисков и копания в коде выяснилось, что там был хардкод в духе «encoding = Latin-1», поэтому мне пришлось пересобрать проект с изменением на «encoding = UTF-8». Мы далее работали с этой версией, приходилось делать пересборки, и в какой-то момент все развалилось, потому что пересобрать библиотеку забыли. Тогда я понял, что мог бы, конечно, немного больше поработать и залить изменения в апстрим, тогда было бы меньше сложностей.
Моя контрибьютерская активность как раз связана с тем, что встречаются небольшие проблемы, которые не так сложно исправить, но авторы того или иного решения не добрались до них. Например, несколько лет назад я поправил плагин под IntelliJ IDEA, который делал Vim-режим. Вспомнил про эту историю, потому что недавно я увидел, как исправленный тогда баг вновь вернулся. Придется поправить еще раз. Еще есть среда Msys, где мне была нужна утилита Pipe Viewer, которая помогает рисовать прогресс-бар для консольных утилит, где это не предусмотрено. Я собрал пакет, его добавили. Было и такое, что под Msys не собирался Silver Searcher (команда ag, заменитель grep), там нужно было поправить один символ. Подобные примеры — это также ценный опыт.
У Axiom JDK широкий спектр разработок, какую роль в линейке продуктов играют их open source-версии? Как исторически развивался открытый подход в компании?
В целом смысл существования Axiom JDK в том, чтобы развивать Java в России. Поэтому все то, что у нас есть так или иначе связано с Java. Каждому нашему продукту соответствует открытая версия, но есть ряд особенностей. Допустим, есть мнение, что open source позволяет легко адаптировать все под свои потребности, делать исправления и закрывать баги. Однако с большими открытыми проектами это далеко не всегда так — внести изменения самостоятельно, или собрать такой проект бывает достаточно сложно. Поэтому сегодня открытость технологических продуктов скорее означает, что найдется такая организация или человек, которые помогут вам сделать необходимые улучшения, чтобы все работало. Если в этом разрезе посмотреть, становится понятнее, чем занимается Axiom JDK. Есть и другие моменты — например, вопросы безопасности, особенно критичные в последнее время.
Если крупными мазками, для меня Java — это синоним JDK. Этот движок нужен, чтобы код на Java запускать. И для этого у нас есть Axiom JDK Pro. Далее необходимы инструменты для создания сервисов на Java. В первую очередь, если по времени появления смотреть, это — Java EE, сменившая название на Jakarta EE. Имею ввиду сервер приложений: и он у нас есть: Libercat, основанный на открытом Tomcat, а также энтерпрайз версия Libercat, основанная на открытом TomEE Plus (Tommy Plus). Если спросить Java-разработчика, что еще ему нужно для создания сервисов, то он скорее всего скажет про Spring. И у нас есть Axiom Spring, в основе которого тоже лежит проект с открытым кодом.
Еще совместно с коллегами мы развиваем проект OpenIDE. Его репозиторий размещен на GitFlic, где можно заводить issues и проч. Если говорить о том, как люди делают вклад в этом контексте — это в основном плагины. Мы сделали с нуля свой маркетплейс плагинов и принимаем там заявки на добавление сторонних. Конечно же, если их лицензия позволяет, а также приветствуем открытый код.
Могли бы мы подробнее остановиться на совместном проекте OpenIDE? Было бы интересно узнать о вашем вкладе в его развитие и узнать больше о маркетплейсе.
Мы развиваем OpenIDE силами трех компаний — Группы Астра, Haulmont и Axiom JDK. Каждая обладает существенной экспертизой и делает равноценный вклад. Мы в Axiom JDK специализируемся на сборке OpenIDE. Платформа, на которой построен проект, общедоступна, как и пайплайн для сборки, поэтому вроде бы данного вопроса быть не должно. Однако он есть, а мы — собираем OpenIDE целиком. Дело в том, что там есть код не только на Java и Kotlin, но и на других языках: Go, Rust, C, C++. Мы делаем так, чтобы в России и на российских операционных системах OpenIDE можно было использовать. Здесь используется версия glibc достаточно старая, с учетом чего нам и нужно все собирать. Это можно сделать, если собрать новый компилятор с помощью старого, а затем собрать все нативные составляющие. Мы на своей стороне это делаем, включая dll-ки, которые последний раз собирались в открытом мире наверное пару лет назад.
Если говорить шире, сейчас мы в Axiom JDK также разрабатываем плагин для легкого мониторинга. Это как профилирование, но для того, чтобы следить за кодом, который запущен из OpenIDE — смотреть расход памяти, потоки. Это есть в IntelliJ IDEA Ultimate, но нет в Community Edition. Сделали мы и плагин для того, чтобы у нас были подготовлены индексы для Axiom JDK. За счет того, что мы хорошо понимаем, что находится под капотом JDK, плагин позволяет ускорить индексирование новых проектов. В целом наш маркетплейс достаточно наполнен, и мы принимаем новые плагины. Один из примечательных — предназначен для того, чтобы делать новые проекты на Spring. Я даже сделал туда несколько коммитов.
Считаете ли вы, что нерекламный технологический контент необходим и значим для развития open source-проектов и решений на основе открытых разработок? Например, у вас есть технологический блог на Хабре, где вы делитесь опытом.
Да, мы ведем блог, а также тг-канал. Еще мы проводим Java Rock Star Meetup, куда мы приглашаем ведущих экспертов в нашей области. Например, в одном из недавних мероприятий участвовал Роман Елизаров, который внес существенный вклад в создание языка Kotlin, а также Алексей Рагозин, один из наиболее крутых специалистов по перфомансу в мире Java. Мы уделяем много внимания поддержке Java-комьюнити в России. Это — одно из крупнейших Java-сообществ в мире. Для обучения аудитории по нашим продуктам мы также регулярно проводим вебинары, выступаем на крупных мероприятиях, проводимых JUG Ru Group и HighLoad, а также, например, на Podlodka. Из ближайших будет SnowOne в Новосибирске.
Ну и наконец Аксиом поддерживает Spring АйО — русскоязычное сообщество разработчиков создано с целью развития и популяризации Spring. Spring это, ещё раз напомню, один из самых популярных Java фреймворков. В целом тема маркетинга в нашей области достаточно неожиданная. Есть open source, о котором мало кто знает, но в мире Java и в нашей деятельности решения исключительно известные, которые не требуют рекламы. Однако объяснять и работать с аудиторией все-таки необходимо.
Я люблю приводить примеры вроде мифа о том, что Java «медленная». И с такими заблуждениями вполне можно работать — объяснять, что это не так. Также есть специальные продукты, как у нас, где Java ускоренная. Однако я встречал людей, которые сравнивали производительность даже с Python, аргументируя это скоростью запуска той или иной утилиты по сравнению с условным решением на Python. В таком контексте нужно понимать, что у Python, конечно же, нет Java машины, которая долго запускается, а потом быстро работает, но и сделать так, чтобы она быстро запускалась тоже можно. Есть такая штука Graal, которая делает native image и позволяет получить моментальный запуск.
Такого много в open source, когда нужно объяснять и «обучать аудиторию».
Какую роль такой контент играет в работе с внутренней аудиторией сотрудников?
Контент по теме открытых технологий важен как для внешней аудитории, так и для наших сотрудников. Этот момент для всех одинаковый. В нашей области что-то постоянно происходит, и мы стараемся «делать новости» по своим направлениям. Поэтому в целом, конечно же, хорошо бы быть в курсе хотя бы общих моментов, иначе можно попасть в ситуацию, когда будешь всем рассказывать, что Python быстрый, а Java медленная. Я всем рекомендую смотреть выступления на конференциях, где всегда можно найти что-то полезное и подкрепленное личным опытом в определенной узкой сфере. На днях я смотрел доклад о том, как инициализировать спринговые бины. Тема понятная, но мне встретился нюанс, который заинтересовал, в том числе с точки зрения опыта коллег.
Если говорить о внутренней и внешней коммуникации, то у меня совмещаются обе стороны в силу участия как раз в конференциях с докладами, а также интервью и других активностях. Если сравнивать с другими сотрудниками, то это — возможно более выраженная направленность на внешнюю аудиторию и развитие сообщества, экосистемы вокруг наших продуктов, в том числе развития возможностей на стороне заказчиков.
Также я хотел бы спросить про работу над «правилами игры» в сообществе вокруг открытых проектов. Как у вас обстоят дела с этим?
Если говорить в контексте, например, OpenIDE, то у нас нет отдельного, нестандартного code of conduct. Но хочется отметить, что основной вклад сообщества состоит в том, чтобы делать плагины. И в этом разрезе у нас есть определенный порядок участия: как подать заявку, какая может быть лицензия, какое будет тестирование на нашей стороне и так далее. В остальном — дополнительные вопросы и рекомендации всегда можно получить в чате.
Есть ли у вас определенные структуры и роли, которые поддерживают открытые проекты? В контексте OpenIDE это — выделенная организация, возможно есть дополнительные виртуальные команды по части работы над open source.
Сейчас в целом увеличивается потребность в экспертизе при работе над открытыми решениями, и далеко не всегда хватает тех, кто способен внести нужные доработки и сделать это корректно. Кроме того, в сфере open source, построенной изначально на всеобщем доверии друг другу, появляются и другие нюансы. В идеале ты должен доверять всем, кто open source-решения разработал, а также тем, кто разработал решения в их основе. Поэтому появляется потребность в доверенных источниках open source. В этом смысле мы в Axiom JDK — команда, которая занимается Java — не просто ускоряем что-то, а даем гарантии, что эта Java безопасна, не имеет недокументированных возможностей.
Это очень важная роль, и на эти активности собираются как раз виртуальные команды наших экспертов. У нас есть доверенный репозиторий Java-библиотек. Это — гарантия того, что не будет такой ситуации, когда исходники не соответствуют тому, что есть в артефактах. Не будет такого, что у вас появятся закладки. Многие знают, что такое Log4j. Хотя некоторые узнали как раз о Java из-за того, что там в одной из библиотек была уязвимость. Были проблемы и с MongoDB и прочими известными решениями. Поэтому мы в первую очередь заботимся о том, чтобы уязвимости были известны, даже если они появляются, а в случае с Axiom Spring, Libercat и Axiom JDK Pro — мы их активно исправляем. В этом так или иначе участвуют все сотрудники.
Как вы могли бы охарактеризовать общие цели участия компании в открытых проектах вроде OpenIDE? Зачем это нужно и что это дает Axiom JDK?
Конкретно с OpenIDE всё просто и понятно. Как я уже говорил, Axiom JDK занимается развитием Java в России, а IDE, так же как сервер приложений или Spring Boot, — это части экосистемы для разработки Java приложений. И конечно, раз уж сложилась такая ситуация, что российская JDK есть, а российской IDE нет, то кому как не Axiom JDK быть среди тех, кто приложит усилия к исправлению этого несоответствия. Но это — OpenIDE, а вообще. конечно, каждый случай и каждый проект надо рассматривать отдельно.
Какие новые направления вы начали развивать в контексте OpenIDE и Spring?
У нас в работе OpenIDE Pro с возможностями, которые очень нужны организациям. Мы развиваем там поддержку Go и JavaScript. Ранее я отмечал Axiom Spring, где мы предоставляем поддержку для Spring по аналогии с тем, что делаем для Java. У нас есть плагин для того, чтобы делать новые проекты для Spring, будет и поддержка Axiom Spring. Этот плагин не может делать проекты для Spring Boot 2.7, потому что эту возможность убрали на Spring Initializer, с помощью которого работает плагин. Мы вернем эту возможность.
Стоит сказать, что для Spring Boot 3.5.x поддержка заканчивается в июне 2026 года, после этого обновления будут появляться только для четвёртой версии. И уязвимости, обнаруженные в 3.5.x закрываться не будут. А по результатам опроса в Jugru, 3.5.x это самая распространённая версия. Компании ещё не осознали, что развивать ветку 2.x как раньше годами теперь больше не будут. Но Axiom Spring уже сейчас предлагает поддержку и закрытие уязвимостей даже когда публичные исправления заканчиваются.
Могли бы вы поделиться с аудиторией задачами, где была бы полезна помощь?
У нас в чате OpenIDE многие пишут о том, что было бы хорошо, если бы OpenIDE поддерживал PHP. У нас фокусировка несколько иная, поэтому здесь помощь участников сообщества с нужной экспертизой была бы крайне полезной.
