Cделать продукт из внутреннего фреймворка: как прошло онлайн-мероприятие для Java и React разработчиков от Haulmont

В апреле мы в Haulmont провели первое в этом году онлайн-мероприятие — день открытых дверей open source фреймворка Jmix. Сделали текстовую выжимку из некоторых докладов (полную видеозапись также прилагаем).

Из материала вы узнаете:

Об этом и не только рассказали Андрей Глащенко, руководитель направления Jmix, Алексей Стукалов, руководитель направлений Developer Advocacy и R&D, и Константин Кривопустов, руководитель команды разработки.

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

Jmix — это новая версия open source фреймворка CUBA, которая помогает быстро создавать корпоративные приложения на Java. Его основная задача: ускорить разработку и снизить порог вхождения для Junior developers и тех специалистов, кто мигрирует в Java из более устаревших технологий, например, Success, Switch и т.д.

Jmix состоит из трех компонентов:

С одной стороны, это — совсем новый продукт: финальный релиз выйдет лишь в июле 2021 года. В то же время Jmix — наследник CUBA Platform, которую мы разрабатываем, меняем и улучшаем вот уже 12 лет. И чтобы понять, как мы попали туда, куда попали, вернемся в самое начало.

Наверняка, вы уже посчитали, но мы все же скажем: CUBA Platform появилась в 2008 году (кстати, в год основания самой компании Haulmont). И как у многих молодых IT-компаний, у нас быстро появились проектные наработки. А когда разработчикам надоедает делать одно и то же из проекта в проект, они создают первые внутренние фреймворки. Так появилась CUBA, но с существенным отличием: у наших разработчиков уже был успешный опыт создания фреймворков.

Нас часто спрашивали, что означает CUBA. И, если честно, это было просто удобное короткое название, которое мы дали одному из первых пакетов. Если посмотреть исходники ядра старой версии фреймворка, можно найти и пакеты «chile» и «bali». Кстати, одной из причин смены названия платформы в будущем стала ассоциация фреймворка со страной — некоторые банки блокировали платежи нам как подозрительные.

Многие помнят, что IT-рынок переживал кризис 2008 года ничуть не легче всего остального мира. Но уже тогда было понятно: будущее — за web-технологиями. Мы выбрали довольно удачный стек на тот момент: Spring + Vaadin. У Spring уже несколько лет выходили стабильные и проверенные версии, а Vaadin казался «серебряной пулей», которая позволит Java-разработчикам создавать богатые web-приложения. Мы даже подумывали в сторону Desktop, но не стали делать на него ставку (и хорошо).

Конечно, в первое время были проблемы с производительностью: когда мы запускали первый проект на CUBA Platform, экраны могли открываться по 40 секунд и даже по минуте. Неожиданное спасение пришло от Google Chrome, который каждый месяц выпускал новые версии, в разы повышающие производительность Javascript. Буквально за полгода проблема решилась, и за несколько лет CUBA состоялась как внутренний фреймворк. Мы запустили на нем два крупнейших продукта компании: ECM-систему ТЕЗИС и систему автоматизации служб такси Sherlock. Более того, дали некоторым дружественным IT-компаниям попробовать CUBA Platform, и у них, как и у нас, тоже получилось создать готовые web-приложения. И тогда…

Наш вывод был таким: если CUBA полезна нам, она будет полезна и другим Java-разработчикам. В 2012 году мы не вдавались в анализ рынка и не изучали его потребности — все это ждало нас в будущем. Но что мы увидели сразу, так это пропасть между внутренним фреймворком и внешним продуктом.

Нам понадобилась техдокументация, причем подробная и качественная. Это была наша маленькая «Война и мир» на тысячу страниц, которую мы писали целый год, а затем переводили на английский язык. Но даже такого подвига было недостаточно. Посудите сами: что сделает разработчик, если на знакомство с платформой и изучение документации ему нужно потратить несколько дней? На 99% уверены, что ничего. Именно поэтому нужны инструменты, которые генерируют код, имеют удобные визуальные редакторы, подсказки и навигацию. Это побудило нас разработать первую версию Studio.

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

Все наши маркетинговые силы были направлены на Java-разработчиков. Мы считали их целевой аудиторией и амбициозно шагнули в международное developer-комьюнити (настолько, что стали серебряными спонсорами на JavaOne в Сан-Франциско). Начали писать статьи и узнали, что такое Хабр-эффект: сайт ежедневно стали посещать тысячи разработчиков. А еще у платформы появились положительные отзывы. И все было хорошо, кроме одного: у нас не было продаж. К концу 2015 года стало ясно, что проблема именно в лицензионной модели.

С замиранием сердца перевели фреймворк под Apache 2.0, выложили код на GitHub и перешли к freemium-модели. Сам фреймворк стал доступен бесплатно, а некоторые инструменты для разработчиков остались платными по подписке. Сейчас эта модель немного изменилась, но принцип остался таким же.

И — о, чудо! — за 2 недели продали в два раза больше, чем за весь предыдущий год. В абсолютных цифрах, конечно, получилось около 10 продаж, но все равно это был взрывной рост. За последующие два года у нас получился зрелый продукт с понятной моделью монетизации, а вокруг CUBA Platform сформировалось комьюнити из тысяч разработчиков. Мы запустили форум, увеличили команду, нашли партнеров в Китае, Италии, Германии и неожиданно для себя начали монетизацию продукта через заказную разработку (сейчас это отдельное и самое быстрорастущее направление Haulmont).

Но чудо таяло, и в 2018 году рост сообщества снизился с 300% до 30%. CUBA все еще была молодым продуктом, и такая динамика нас не устраивала. Мы вновь стали искать слабые стороны. И если с первой все было понятно, то вторая стала для нас настоящим откровением.

Напомним, CUBA появилась в далеком 2008 году. Монолитная архитектура ядра, ограниченность API, собственная архитектура вместо Boot (которого просто не существовало в 2008-ом) не мешали жизни платформы как внутреннего фреймворка, но заметно сдерживали ее рост как публичного продукта.

Созрели проблемы и в инструментах для разработчиков. Был момент, когда все верили: разработка переедет в web. Существовал даже такой проект Eclipse Che — облачная среда разработки. По этой причине CUBA Studio тоже была web-приложением. Однако теория не подтвердилась, и нашему пользователю приходилось постоянно переключаться между IntelliJ и Studio. Это был плохой developer experience, который, к тому же, создавал ощущение «игрушечности» нашей IDE.

И, конечно, проблемой стал Vaadin, который так помог нам в начале пути. По ряду причин он стал нишевой технологией, проиграв битву таким фреймворкам, как React и Angular.

Мы уже говорили, что видели в разработчиках нашу единственную целевую аудиторию. Но что-то не сходилось. И после долгого изучения профиля пользователей нас осенило. Наши главные ценности — ускорение разработки, снижение порога входа, как следствие, экономия денег и времени — интересуют не столько разработчиков, сколько бизнес. В подтверждение мы увидели, что практически все наше сообщество находится на узком пересечении профессиональных и бизнес-интересов. Это люди, которым интересны технологии (иначе они бы не узнали о нас), но которые сопричастны и к бизнес-результату (иначе их не цепляли наши ценности): консультанты, сотрудники небольших IT-компаний, практикующие IT-директора. Поразительно, как мы умудрились набрать более 25 000 разработчиков в глобальном сообществе при такой узкой нише.

Началась работа над преодолением технических ограничений. Мы запустили Marketplace аддонов и вынесли в них часть ранее монолитной функциональности из ядра. Следующим шагом переписали Studio: она стала расширением к популярной среде разработки IntelliJ IDEA. Это обеспечило новый уровень комфорта разработчикам. В 2021 полностью переписали Backend платформы, переведя его на Spring Boot. Заодно завершили разделение монолита на подключаемые модули с продуманным API и решили еще ряд архитектурных проблем.

Изменений накопилось так много, что они коснулись и названия платформы: CUBA стала Jmix. Такое название легко объяснить: «J» означает «Java», а «mix» — технологии и фреймворки, собранные в одном приложении. И никаких ассоциаций с известным островом или коктейлем.

Если говорить о маркетинге, то мы поняли, что наш рынок — это стремительно набирающий популярность Low Code. Философия Low Code платформ (или LCAP) полностью совпадает с нашей: демократизация и ускорение разработки. Целевая аудитория — в первую очередь менеджмент. Однако есть существенное отличие. Изначально (и довольно долго) создатели Low Code Application Platforms продвигали идею, что не нужно быть разработчиком, чтобы создавать корпоративное ПО.

И нельзя сказать, что им это не удалось. Сегодня обычный пользователь, не имеющий навыков программирования, может создать удобную и красивую систему (если это достаточно типовая system of record). Однако шаг влево — шаг вправо, и нужен код. Но разработчики совсем не горят желанием его писать из-за недружелюбных инструментов и ограничений, вытекающих из высокого уровня абстракции LCAP. Добавьте к этому закрытый код и дорогие лицензии, и становится понятно, почему Low Code продукты все еще имеют ограниченную популярность. С новой версией платформы мы хотим предложить альтернативу. Jmix изначально ориентирован на гибкость и удобство разработчика, а «демократизация» в нашем случае — это возможность вовлекать начинающих или «мигрирующих» разработчиков за счет понятных визуальных инструментов. Кроме того, в основе экосистемы Jmix по-прежнему лежит фреймворк с открытым кодом, а значит, создаваемые приложения свободны от лицензионных ограничений.

Для успешной конкуренции на рынке Low Code потребовалось дальнейшее расширение возможностей продукта. И, как следствие, ресурсы для роста команды. Здесь помогли ряд крупных контрактов в том числе со Сбером, а также грант Российского фонда развития информационных технологий — тот счастливый случай, когда наши планы полностью совпали с государственными направлениями поддержки IT.

Сейчас в подразделении Jmix работает уже 60 человек. К концу 2021 ожидаем рост до 75 сотрудников (если вы из IT-сферы, возможно, вам будут интересны наши вакансии).

Таким образом, 10 лет спустя, в жизни продукта начинается новый этап. Мы уверены, что новые возможности Jmix позволят еще быстрее создавать современные, удобные и функциональные приложения.

P. S. В записи вы найдете еще много интересных моментов про open source, профессию DevRel и особенности работы в команде Jmix — советуем посмотреть.