起源
jBPM3是一个完整的工作流系统实现，面向开发人员，目的在于简化对组织核心流程进行支撑的软件创建，不支持标准。
发展
jBPM4引入PVM，使其拥有更强大的扩展性，同时增加BPMS特性，这些特性包括了对BPMN的支持、面向业务人员的Web建模器和简单统计分析功能的加入。
分裂
- JBPM的主创人员Tom Baeyens与合作伙伴在JBPM的未来架构上产生了重大分歧，于是Tom离开了Jboss并加入了Alfresco公司，沿用jBPM4代码，创立了Activiti5。
Activiti5基于jBPM4的开源工作流系统，与Alfresco的集成增加了其流程可视化与管理能力，同时通过创新的Activiti Cycle协作组件支持流程相关人员之间的协调，最后，它加强了集成能力。 - Jboss公司完全抛弃了JBPM4的架构，基于Drools Flow进行彻底重构，推出了JBPM5。支持BPMN，通过与Drools的合并支持BAM，通过内容仓库增加对流程可视化的支持。由于放弃了jBPM4的PVM，引擎的可扩展性受到损害，并且不再支持jPDL。
尽管JBPM5和Acitiviti5都支持BPMN2.0规范，但是由于JBPM5完全推翻了JBPM4的架构，这无异于将已经在使用JBPM4和之前版本的用户推向了Activiti5。因此几年下来，Acitiviti大有取代JBPM之势。当然，JBoss旗下有众多优秀的产品，JBPM5作为Jboss的亲生子，自然与这些产品进行整合具有先天的优势，因此选择Activiti5或JBPM5还需要认真权衡利弊。
裂变
- 除Alfresco以外，Activiti最大的贡献者之一的公司Camunda表示Activiti可能太拘束于Alfresco对以文档为中心的工作流的需求(这个也是BPMN约束使然)，而忽视了Activiti起步时的更为普遍的BPM平台。camunda宣布他们正从Activiti 分裂出一个新的开源工程，那就是camunda BPM.
- 当年JBMP的主创Tom已经离开Alfresco多年，后辈们也开始步前人后尘。Tijs Rademakers、Joram Barrez等Activiti的原班核心人马，由于与Alfresco公司在项目的未来发展方向上出现分歧，于是选择集体出走，创建了Flowable，并且将第一个版本定义为5.22，而且在两周前发布了6.0版本。
- activiti自身发展缓慢，Activiti这几年止步不前，开始吃老本。而这几年又出了CMMN/DMN两个新规范以及BPMN更多的规范，Camunda框架已经率先响应并支持了，而Activiti5还是不能支持这些规范的，导致流失很多用户，很多用户转向了Camunda阵营，activiti也开始着急忙慌的想去实现CMMN以及DMN规范，但是在实现DMN规范的过程中，还在重构代码，那就是在用户层面增加了更多的引擎，包括内容引擎、应用引擎等，在内核方面因为还是使用的PVM技术，导致在支持流程动态化方面有些吃力，bug层出不穷，前段框架选型失败，后端重构错误等原因。activiti6以及activiti5的代码官方已经宣称暂停维护了。activiti7就是噱头 内核使用的还是activiti6，并没有为引擎注入更多的新特性，只是在activiti之外的上层封装了一些应用，往云方向发展。6.0版本据说留了大量框架级bug，而在flowable中进行了修复。
从各方面收集的资料来看
activiti优于jbpm，jbpm首先出局
flowable优于activiti，即activiti也不再考虑
flowable与camunda之间，能查到资料是camunda更好一些，但缺乏多资料交叉印证。
资料1：
从多个维度对比，camunda优于flowable
https://blog.csdn.net/qq_30739519/article/details/86682931
资料2：
flowable以6.4.1版本为分水岭，大力发展其商业版产品。开源版本维护不及时。部分功能已经不再开源版发布，比如表单生成器（表单引擎）、历史数据同步至其他数据源、es等等。dmn目前是个半成品，没有camunda稳定和好用，对于dmn规范支持薄弱。部分商业版的组件被商业化，因此开源版不再维护。Mongdb目前也放到商业产品中了，开源版的几乎不能用。（来源：https://blog.csdn.net/qq_30739519/article/details/82493456）