Camunda 7, почему «форк» – это правильно. 

Статья посвящена неоднозначной ситуации, вызванной действиями крупного иностранного вендора – компании Camunda Services GmbH, который объявил об изменениях в своей продуктовой и лицензионной политике, повлекших за собой полное прекращение развития open-source версии BPM-движка Camunda 7 CE.  

Проблема 

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

Что есть форк 

«Форк» — это конкурирующий проект, основанный на версии исходного кода ранее существовавшего проекта. Все проекты свободного ПО могут быть «форкнуты», такая возможность является основополагающей и лежит в основе понятия «свободного ПО»: 

Свобода распространять копии своих изменённых версий среди других. Делая это, вы предоставляете всему сообществу возможность воспользоваться вашими изменениями. Доступ к исходному коду является обязательным условием.

При этом отличительной чертой форка является «намерение», когда авторы намереваются заменить им исходный проект, создать с ним конкуренцию. Простое создание или выпуск варианта кода проекта обычно не приводит к форку. Более того, выпуск вариантов для экспериментов считается нормой в процессе разработки свободного ПО (FLOSS). Многие проекты FLOSS (например, проект разработки ядра Linux) намеренно проводят «отборочные испытания» (также называемые «конкурсами»), в ходе которых разные разработчики реализуют разные конкурирующие подходы; результаты сравниваются, и подход, дающий наилучшие результаты («победитель»), принимается проектом. Эти «отборочные испытания» часто обсуждаются в эволюционных терминах, например, «победная мутация» принимается в проект, а альтернативы отвергаются как «эволюционные тупики». Поскольку все стороны стремятся к тому, чтобы «лучший» подход был принят проектом, а все остальные подходы были отвергнуты, и это не форки. 

Большинство попыток создания форков игнорируются сообществом, поскольку у разработчиков должны быть очень веские причины рассматривать возможность перехода на конкурирующий программный продукт. В мире свободного ПО разработчики обычно сопротивляются поддержке форков: бытует мнение, что форки распыляют усилия, которые были бы эффективнее при объединении, затрудняют поддержку и дальнейшую разработку, вынуждают разработчиков обсуждать управление проектом, а не улучшать продукт. Поэтому создателям форка приходится обосновать, почему другие разработчики должны будут поддержать их форк; распространённые причины включают в себя убеждение, что изменения принимаются очень медленно или наоборот, что изменения происходят слишком быстро, что управление проектом слишком закрыто для посторонних, что система лицензирования препятствует разработке или что техническое направление развития базового проекта в корне неверно и зашло в тупик.  

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

При этом наиболее частым вариантом развития ситуации является:  

• Смерть форка. Объявить форк легко, но требуются значительные усилия для результативной модификации его кодовой базы, поддержки сборочных комплексов, демо-стендов, подготовки документации и инструментов для миграции проектов. 

Далее идут промежуточные случаи: 

• Либо возникает устойчивая дифференциация (например jBPM, Activity, Camunda), либо, спустя какое-то время, происходит повторное слияние с оригиналом. Также становится больше проектов с двойным лицензированием, когда пользователи могут использовать продукт бесплатно в рамках условий open-source лицензии, но компании или пользователи, которые хотят использовать продукт в условиях, не совместимых с open-source лицензией (например, в закрытых системах), могут приобрести коммерческую лицензию. 

И, наконец, наиболее редкий, но кардинальный вариант: 

• Смерть оригинала. Когда базовый проект окончательно перестает развиваться и закрывается. 

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

Какие требуются доработки 

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

Но по мере того, как исходный код все больше модифицируется, полученное программное обеспечение все больше отличается от оригинала. Применительно к ядру BPM-движка Camunda мы считаем важным учесть и доработать следующие ключевые моменты: 

• Избавиться от CVE в сборках Camunda, которые тянутся уже больше 10 лет и вызваны, на наш взгляд, невозможностью со стороны вендора отказаться от поддержки морально устаревших технологий, которые до сих пор «крутятся» на инфраструктуре у крупных коммерческих заказчиков. 

• Сделать работу движка стабильнее, избавить его от необходимости поддерживать морально устаревшие технологии (такие как старые версии серверов приложений, JavaEE и Spring Framework 5). 

• Очистить программный код движка от компонентов, не используемых в open-source версии (то есть от встроенных систем телеметрии и управления лицензиями, доставшимися в наследство от кодовой базы Camunda Enterprise). 

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

• Реализовать собственный подход к построению тепловых карт и обеспечить возможность сборки BPM-движка с расширенными средствами мониторинга на базе Spring Boot Actuator. 

• Обеспечить совместимость с актуальными сборками JDK (17, 21+) и совместимость с российскими сборками операционных систем и баз данных. 

В чем сила, брат? 

Форк Camunda 7 для конечного пользователя — это в первую очередь способ сохранить стабильность и снизить риски, связанные с переходом на новую технологию. При таком выборе нет необходимости переписывать проекты и заново реализовывать интеграции: ваши старые BPMN и DMN модели автоматически подхватываются новым движком и продолжают работать, все API методы остаются знакомыми и предсказуемыми, а значит вероятность ошибок в продакшене минимальна. Кроме того, Camunda — это не только набор ПО, но и целая методология работы, объединяющая разработчиков и бизнес-аналитиков. При её замене на стороннее решение есть риск, что придется менять не только программный код проектов, но и сам подход к взаимодействию команд, что может повлечь колоссальные организационные издержки. Форк, в свою очередь, позволяет сохранить привычный рабочий процесс, накопленные best practices и совместимость с локальной инфраструктурой. 

Дополнительным преимуществом является то, что форк развивается полностью на территории РФ. Это обеспечивает соответствие локальным требованиям и стандартам, а также открывает новые возможности для глубокой интеграции в национальную ИТ-инфраструктуру — чего ранее было сложно достичь при использовании оригинального решения. 

Важно подчеркнуть, что форк — это не только про "реанимацию ". Этот подход открывает пространство для инженерных улучшений, особенно в тех местах, где основной вендор был ограничен необходимостью сохранять обратную совместимость или ориентировался на глобальный рынок. Новый вендор может сфокусироваться на конкретных потребностях пользователей и приоритетно внедрять те функции и best practices, которые давно востребованы, но не поддерживались из коробки. Таким образом, форк становится не только инструментом снижения затрат и рисков, но и технологической платформой, способной эволюционировать в сторону современных требований. 

Один в поле не воин 

Поднять такой объем доработок одной командой, пусть и достаточно квалифицированной, объективно сложно. Но хорошая новость заключается в том, что продукты для разработчиков от компании Хоулмонт имеют глобальное распространение, поэтому нам легко удается договариваться о коллаборациях команд и проектов. Наши идеи про универсальные инструменты для процессной разработки, про единый центр управления средой исполнения бизнес-процессов, про поддержку различных сред IDE и поддержку различных вариантов BPM-движков находят живой отклик в сообществе, благодаря чему нам удается объединить усилия по развитию форка с наиболее активными международными командами. Мы коммитим в их проекты, они делятся с нами результатами своих изысканий и экспертизой. Таким образом, форк выполняет не разобщающую, а наоборот объединяющую разные команды функцию. И это здорово. 

OpenBPM — это не просто техническая замена Camunda 7, а стратегическое решение для компаний, которые ценят стабильность и предсказуемость. Наш форк сохраняет все преимущества оригинальной платформы, одновременно предлагая современные улучшения и полное соответствие российским требованиям. 

Готовность к промышленной эксплуатации в октябре 2025 года, сразу после EOL Camunda, подтверждена не только тестами, но и официальной сертификацией в реестре Минцифры. Мы предлагаем не просто форк, а эволюционное развитие проверенной технологии. 

Официальные документы для РФ: 

Роспатент – Свидетельство №2025615638 от 06.03.2025.  

Реестр Российского ПО - Реестровая запись №29290 от 20.08.2025.  

Сертификаты совместимости:  

• REDOS 8 от 09.06.2025  

• AltLinux 11 от 19.06.2025  

• AstraLinux SE 1.7 & 1.8 от 21.07.2025  

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