Flowable vs jBPM

The Flowable open-source engines for BPMN, CMMN and DMN are licensed under Apache-2.0, according to the Flowable open source page. That license lets your team use, modify and redistribute the engine code without a license fee to Flowable for the engines themselves. The engines run embedded in a Java application or as a service, and they expose both Java and REST APIs. What the license does not provide is support, hosted operation or the commercial tooling, so those costs and responsibilities must be planned separately.

• Engine code: The BPMN, CMMN, DMN and event registry engines are Apache-2.0 licensed, so the code can be reviewed, forked and patched inside your own change control.
• Community support: Open-source users get access to a community forum. That is a discussion channel, so confirm whether any response expectations apply before you depend on it for production incidents.
• Professional services: Flowable offers these separately from the license, so you buy implementation, customization or training as scoped work.
• Upgrade effort: Flowable 8.0.0, released on February 27, 2026, moved to Spring Boot 4 and dropped Spring Boot 3 support, so upgrade labor is a real cost even with no license fee.
• Tooling gaps: The facts attribute low-code modeling and visual debugging to the commercial products, so confirm what your open-source build includes before you plan to hand models to business analysts.

Check the license file in the exact release you deploy, and ask Flowable in writing what the community forum covers.

Flowable sells a separate commercial platform, including Flowable Work, Engage, Orchestrate and Design, and these products are built on the same engines as the open-source distribution. The commercial layers add low-code modeling, visual debugging, security controls, monitoring and governance, according to the Flowable open source page. Buyers pay for these layers on top of the engine they already run, so the decision depends on how much of that functionality your teams would otherwise build and maintain themselves.

• Product family: Flowable Work, Engage, Orchestrate and Design each target different parts of the workflow lifecycle, so map your use cases to a specific product before you size anything.
• Low-code modeling: This lets analysts draw and change processes with less developer involvement. Confirm which roles the subscription permits to edit live models.
• Visual debugging: Operators can inspect running process instances visually. Test it against the audit trail and evidence requirements that your compliance team sets.
• Security controls and governance: These cover access and change control over process assets. Ask how they integrate with your existing identity provider and approval workflow.
• Monitoring: The open-source Spring Boot starters expose an actuator endpoint at /actuator/flowable for running processes. Compare that baseline with the commercial monitoring before you decide what to license.

Ask Flowable for a feature matrix that separates open-source capabilities from each commercial product, and get it in writing before you size a subscription.

jBPM is part of Apache KIE, the home of Drools, OptaPlanner, jBPM and Kogito, and the project is licensed under the Apache License 2.0, as described on the Apache KIE site. That license matches the Flowable engines, so licensing alone does not separate the two options. The practical differences lie in what the project ships, how it is packaged and how it is governed. Because jBPM comes with a broader family of tools, your build and dependency footprint will be larger than a standalone BPMN engine.

• License: Apache KIE is Apache 2.0 licensed, so redistribution and modification terms are comparable with Flowable's engines.
• Project scope: Apache KIE covers rules, planning, process and cloud-native business automation, so you may install components your use case does not need.
• Editor change: Apache KIE 10.2.0 introduced a new BPMN editor, replaced the legacy GWT-based tooling and removed the classic BPMN and DMN editors. Plan migration for any models authored in the removed editors.
• Kogito repositories: The Kogito Runtimes and Kogito Apps repositories are archived, with their code moved into the apache/incubator-kie-drools repository, so update build references and source links.
• Standards support: Release 10.2.0 added DMN 1.6 and Java 21 support, and it moved to Quarkus 3.27.2 and Spring Boot 3.5.10.

Confirm which KIE artifacts your build pulls and map each one to the release notes before you commit to a version line.

Apache KIE remains in incubation at the Apache Software Foundation. The KIE site notes that incubation does not necessarily reflect the completeness or stability of the code. It only means the ASF has not yet fully endorsed the project. The code can still be Apache-2.0 licensed and widely used while the project's governance stage is open, and regulated buyers need to weigh that governance question explicitly in their risk register.

• What the note means: Incubation tells you about ASF endorsement status. It does not measure code quality, test coverage or security posture, so evaluate those directly.
• Release cadence: Apache KIE 10.0.0 was tagged on December 11, 2024, 10.1.0 on July 8, 2025 and 10.2.0 on April 28, 2026. Gaps between releases are a planning input for patch and upgrade windows.
• First ASF major release: Apache KIE 10.0.0 came 15 months after the previous release on September 5, 2023, and it upgraded the stack to Java 17, Jakarta 10, Quarkus and Spring Boot.
• Evidence to gather: Review open issues, recent commit activity and the results of your own pilot, not the incubation label alone.
• Graduation or retirement: Either outcome changes project governance, so record how you would respond to each one.

Ask the Apache KIE community which milestones remain before the status changes and how security fixes are handled for the release line you plan to run.

Confirm before you assume that any vendor stands behind jBPM in production. For Flowable, the commercial platform and professional services are documented as separate offerings, so procurement has a clear counterparty. For jBPM, your support options depend on what third parties offer for the Apache KIE release line you choose, and you should verify that in writing. Either way, paid support should be defined by a written scope, not by a general reputation for responsiveness.

• Flowable subscription: The commercial platform is a separate purchase from the Apache-2.0 engines. Ask what the subscription covers, how long the term runs and which products are included.
• Flowable professional services: These are offered separately and are scoped per engagement. Ask for named deliverables, acceptance criteria and the people who will do the work.
• Flowable community forum: Confirm whether any response commitment applies to open-source use before you rely on it for incidents.
• jBPM external support: Ask any candidate provider whether it supports jBPM within Apache KIE, which versions it covers and how it handles the 10.2.0 editor change.
• Contract terms: Request written security patch windows, upgrade assistance and exit terms that cover data and models.

DeployOpen plans, implements and supports open-source platforms inside your own infrastructure under fixed-scope agreements, so ask any provider for a written scope that names the engine, version and support window.