02.11.2026

В этой заметке разберем наиболее значимые зарубежные проекты, команды которых независимо друг от друга развивают архитектурную модель реализации BPM-движка Camunda 7. Родительский проект прекратил свое развитие год назад, в октябре 2025 года, и в настоящее время находится в “замороженном” состоянии. Патчи обещаны вендором, но только для подписчиков на Enterprise поддержке.

Всё, что было хорошего в Camunda 7 CE, в большей или меньшей степени, переехало в новые проекты:

• Лицензия Apache 2.0
• Универсальный BPM-движок с long-running процессами и job-исполнителем
• Портативность и толерантность к ядрам СУБД
• Тесная интеграция со Spring и Spring Boot
• Развитый REST API и механизмы External Tasks
• Web-приложения для общего администрирования и исполнения задач

Различия проектов проявляются в обвязке вокруг bpm-движка: ребрендинг, дополнительные платные модули, различные уровни поддержки, разная скорость выпуска патчей и новых версий.

Cогласно общепринятой истории, переломный момент и появление большого числа форков произошел после того, как вендор Camunda изменил условия лицензирования и переключил все свои ресурсы на развитие коммерческой линейки Camunda 8 (SaaS-ориентированная платформа на Zeebe), а линейку Camunda 7 фактически перевёл в режим “заморозки”. При этом сообщество и ряд независимых компаний начали собственное развитие форков Camunda 7. В результате появилось несколько параллельных проектов с +/- одинаковым ядром, но разной governance-моделью. У трёх рассматриваемых систем разный подход к управлению, к формированию команд разработки, к коммерческой модели развития (но вокруг одной общей идеи про открытое ядро с монетизацией через поддержку и enterprise-доработки).

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

• Безопасность. CVE по зависимостям команды форков должны будут отслеживать и патчить самостоятельно. А это возможно осуществлять на хорошей скорости только имея зрелый состав команды и технически развитый сборочный комплекс.
• Преемственность и совместимость. Чем дальше форк по своей кодовой базе уходит от изначального проекта (новые модули, правки ядра), тем выше получается стоимость поддержки и тем сложнее будет осуществить обратную миграцию или переход на другой форк.
• Устойчивость. Что будет, если компания или команда единомышленников, развивающая конкретный форк, сменит стратегию или вовсе исчезнет? Кто платит за стабильность производственного процесса, как обеспечивается его непрерывность, каков горизонт планирования?
• Экосистемность. Коннекторы/расширения, ранее созданные сообществом под Camunda 7, в теории переносимы, но на практике их работоспособность придется проверять отдельно по каждому форку.

Для Operaton ядро команды формируют несколько экспертов BPM из Германии:

• Karsten Thoms, Principal Software Engineer, Itemis AG
• Tim Zöller, Founder, Lambdaschmiede GmbH
• Julian Haupt, Founder, Hauptmedia
• Andreas Zill, Head of Technik, Uubato

Вместе с ними в проекте почти 100 контрибьюторов.

Для CIBSeven ядро команды разработки формируют сотрудники CIB software GmbH, но при этом активно привлекаются и внешние контрибьюторы. Среди тех, кого часто упоминают в контексте проекта:

• Christian Wicke (Solution Architect, ATRUVIA AG);
• Peter Sommerhoff (Team Lead, A12 Workflows, mgm technology partners GmbH);
• Alexey Nesterenko (Lead Software Architect, Allianz Technology).

Для FluxNova следует отметить, что это не классическая общественная команда или внутренняя команда одной компании, а сообщество контрибьюторов от разных отраслевых организаций. Участники из разных банков и компаний делятся экспертизой, предлагают фичи, исправляют баги и формируют дорожную карту проекта. То есть фонд FINOS сам не производит ПО, он лишь обеспечивает нейтральную среду развития и управление проектом, чтобы тот оставался открытым и не зависел от какого-то одного конкретного вендора. В качестве основных участников проекта можно выделить:

• Fidelity Investments
• NatWest Group
• Deutsche Bank
• Capital One
• BMO
• TD Bank

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

По данным Maven Repository картина уязвимостей примерно такая (почему примерно, потому что для новых релизов ситуация достаточно быстро меняется):

Как не трудно заметить - только Operaton целенаправленно устраняет уязвимости, а у двух других форков ситуация плюс/минус схожая и часть уязвимостей тянется еще с кодовой базы Camunda 7.

Наша независимая проверка публичной кодовой базы на GitHub (через анализ SBOM в Dependency-Track) подтвердила, что Operaton 2.2.0 выглядит чище остальных: 835 maven-компонентов и ноль известных уязвимостей. CIB seven 2.2.0 и FluxNova 3.1.1 показывают соответственно 118 и 161 уникальных уязвимостей, из них 15 и 17 критических. Контрольный прогон сделали по кодовой базе Camunda 7.24.0 CE, для которой получили 297 уникальных уязвимостей и 49 критических. Получается, что все три форка за последний год сократили унаследованный технический долг, но в разной степени.

Однако, эту разницу нельзя читать как «в одном форке дыры, в другом нет». Все четыре SBOM были собраны одним инструментом (cyclonedx-maven-plugin), как агрегат по всему репозиторию, и в них попало всё, что тянут модули проекта, включая тестовые матрицы совместимости и варианты поставки под разные платформы.

Отсюда возникает несколько версий одной библиотеки в одном файле для анализа: у Operaton таких артефактов 27, у FluxNova 90, у Camunda 244, у CIB seven 324. Если посмотреть граф зависимостей по SBOM, то картина у проектов будет разная: у Camunda старые Spring, Jackson, Netty и async-http-client приходят только из тестовых модулей. А у CIB seven старые Spring 5.3, Tomcat 10.1 и Undertow 2.3 тянут боевые модули: стартер для Spring Boot 3, дистрибутив Run на Spring Boot 3, подсистема для WildFly 28. Получается, что это сознательная поддержка старых платформ, которая и обусловила наличие в проекте уже давно известных CVE. В свою очередь для FluxNova SBOM графа модулей не содержит, поэтому для этого проекта отделить тестовое от боевого не получается.

Ручное сравнение показало, что Operaton честно держит стек на последних версиях без “хвостов” из старых библиотек, а у CIB seven и FluxNova в составе есть компоненты с известными критическими уязвимостями (Undertow 2.3.6, Tomcat Embed 10.1.54 и 11.0.20, Netty 4.1.92, async-http-client 2.12.3), и перед выбором нужно выяснить, попадут ли эти компоненты в вашу итоговую сборку. Характерная деталь: Netty 4.1.92, async-http-client 2.12.3, Guava 31.1, HttpClient 4.5.9, PostgreSQL JDBC 42.5.5 и FreeMarker 2.3.31 у FluxNova это ровно те же версии, что в Camunda 7.24.0, то есть унаследованные и не обновлённые за прошедший год. Но при этом они могут использоваться только в интеграционных тестах и коннекторах, которые не обязательно попадут в ваш итоговый прикладной проект.

Числовые показатели находок:

Важно отметить, что количество уязвимостей по агрегатам годится как мера гигиены репозитория, но не как мера риска для конечных прикладных проектов. Для более точной оценки SBOM нужно собирать по каждому дистрибутиву (а лучше по каждому прикладному проекту) отдельно, без тестовых модулей, и уже потом предметно анализировать. При этом основное внимание стоит обратить на то, какие версии ключевых библиотек каждый из форков содержит в своем составе, и есть ли среди них такие, за которыми числятся критические CVE.

Сориентироваться по свежести ключевых библиотек позволяет следующая таблица:

Operaton стоит на самых свежих линейках: Spring Boot 4.1, Spring 7.0.10, Tomcat 11.0.27, WildFly 41, Netty 4.2, Logback 1.6, и у каждого артефакта одна версия (две у Jackson 2, потому что часть модулей ещё на 2.21). Это результат ежедневных обновлений через Dependabot с автомержем, который виден в истории коммитов upstream.

CIB seven 2.2.0 собран на тех же свежих версиях Spring 7 и Tomcat 11, но в выгрузке рядом с ними лежат Spring 5.3 и 6.2 и Tomcat 10.1: это модули совместимости со Spring Boot 3, которые проект сознательно держит для клиентов, не переехавших на Spring Boot 4. Для таких клиентов это плюс, но в SBOM дистрибутива такие версии появляться не должны. То же с Undertow: 2.3.6.Final тянет подсистема для WildFly 28, рядом есть 2.4.0.Final для текущего WildFly. Для клиента это значит, что выбор варианта поставки CIB seven определяет и набор известных CVE: сборки для Spring Boot 4 и WildFly 40 чистые, сборки для Spring Boot 3 и WildFly 28 несут находки Tomcat 10.1 и Undertow 2.3.

FluxNova 3.1.1 по основному стеку близка к Operaton (Spring Boot 4.0, Spring 7, Jackson 3, Tomcat 11), но тянет за собой старый хвост: Netty 4.1.92 и async-http-client 2.12.3 (оба 2023 года), Guava 31.1, Commons IO 2.11, HttpClient 4.5.9, PostgreSQL JDBC 42.5.5, Logback 1.2.11. Каждый из них даёт находки в Dependency-Track.

Состояние зависимостей отражает модель развития каждого форка. Все три начались от Camunda 7 CE после объявления о прекращении её развития, все три под Apache 2.0, все три перешли на Spring Boot 4 и Jakarta EE 11. Но дальше пути расходятся:

Любой из рассмотренных форков может выступать как оркестратор, который синхронизирует микросервисы или вызывает агентов (через HTTP/gRPC или external tasks), передаёт им контекст из процесса, ждёт результат и дальше маршрутизирует поток по BPMN‑логике. То есть стать надежным помощником там, где процессы проектируются в BPMN и должны быть исполняемыми без написания большого количества прикладного программного кода.

Если главный критерий выбора это состояние цепочки поставки и скорость закрытия уязвимостей в зависимостях, то Operaton сегодня впереди: одна свежая версия каждой библиотеки, SBOM внутри каждого архива, ноль известных CVE на момент проверки. Однако, за это платим коротким сроком поддержки версии и отсутствием вендорской поддержки.

Если нужен вендор с договором, LTS на 18 месяцев и совместимость со Spring Boot 3, это CIB seven; перед выбором стоит запросить у вендора SBOM именно дистрибутива и план по Undertow. Если важна нейтральная фондовая модель и крупные финансовые участники, это FluxNova, но с пониманием, что проект уходит от совместимости с Camunda 7 и что в составе есть библиотеки 2023 года с критическими CVE.

Как и с любым open-source проектом, успех зависит от активности сообщества и/или наличия сильной корпоративной поддержки. Перед масштабным внедрением рекомендую провести пилотный проект: проверить совместимость с вашими конкретными сценариями, оценить удобство интерфейса и то, как платформа впишется в ваш существующий ИТ-ландшафт.
Если уровень поддержки нотации BPMN 2.0 у всех рассматриваемых форков примерно равный, то вот с нотациями DMN и, тем более, c CMMN дела обстоят иначе. И на практике может оказаться, что часть из старых схем придется не мигрировать, а переписывать. Оценить степень соответствия на основании открытых описаний и документации довольно трудно, поэтому тут тоже не обойтись будет без пилотных проектов. Еще более сложная ситуация с вариантами подключения AI-агентов, как в качестве маршрутизаторов, так и в качестве исполнителей задач или ассистентов по управлению средой исполнения процессов. Единых мировых правил и стандартов нет, поэтому реализации у каждой из команд существенно отличаются.