如果你在还纠结该选择JPMB还是Acitiviti的时候，或者还在纠结于是否该从JPMB迁移到Activiti的阵营中的时候，很不幸地告诉你，Flowable6.0已经发布了。

是不是变得更纠结啦？！又多了一种选择。

1、什么是Flowable？

如果你对工作流引擎有所了解，那么一定知道Java领域当前主流的工作流引擎无非就是Jboss旗下的JBPM和Alfresco旗下的Activiti。

Flowable是Activiti原班主创人员从Activiti分离出来的一套工作流引擎，是一个业务流程管理(BPM)和工作流系统，适用于开发人员和系统管理员。其核心是超快速、稳定的BPMN2流程引擎，易于与 Spring集成使用。

2、Flowable6.0的由来？

故事还得从头说起。

依然是江湖流传已久的版本，大约在7年前，在JBPM4发布以后，JBPM的主创人员Tom Baeyens与合作伙伴在JBPM的未来架构上产生了重大分歧，于是Tom离开了Jboss并加入了Alfresco公司。紧接着，Alfresco公司就发布了Activiti5.0这款开源产品。Activiti团队直接将第一个版本定义为5.0，也是明示大家Acitiviti就是JBPM4的延续。而Tom的老东家Jboss则完全抛弃了JBPM4的架构，基于Drools Flow进行彻底重构，推出了JBPM5。

尽管JBPM5和Acitiviti5都支持BPMN2.0规范，但是由于JBPM5完全推翻了JBPM4的架构，这无异于将已经在使用JBPM4和之前版本的用户推向了Activiti5。因此几年下来，Acitiviti大有取代JBPM之势。当然，JBoss旗下有众多优秀的产品，JBPM5作为Jboss的亲生子，自然与这些产品进行整合具有先天的优势，因此选择Activiti5或JBPM5还需要认真权衡利弊。

说完Activiti的由来，不得不先感叹老祖宗的智慧：“话说天下大势，分久必合，合久必分”。

因为笔者在推特上关注了Tijs Rademarkers（原Activiti的Project Lead），前段时间当看到他两条连续的更新，9月份还在Activiti改bug，10月份居然发布Flowable上线声明，笔者浑身一颤，这明显是要搞事啊！

果不其然，打开Activiti官网发现已经改版了，团队成员的介绍也被替换了！

而新建的Flowable官网，成员介绍果然是那些熟悉的面孔，之前Activiti里的大咖们。

Flowable的诞生简直和Acitiviti的诞生如出一辙！当年JBMP的主创Tom已经离开Alfresco多年，后辈们也开始步前人后尘。Tijs Rademakers、Joram Barrez等Activiti的原班核心人马，由于与Alfresco公司在项目的未来发展方向上出现分歧，于是选择集体出走，创建了Flowable，并且将第一个版本定义为5.22，而且在两周前发布了6.0版本！要知道，Activiti当前版本依然还是5.22，6.0处于Beta阶段。

这下又给众多开发者布下了个不小的难题，是该紧跟Flowable的步伐，还是蹲守着Activiti？更不用说那些还在纠结于JBPM和Activiti之间的开发者了，这下又多了一个选择。

3、Flowable6.1醒目的新特性

Flowable 5.22和6.0版本众多让人惊艳的新特性已经在官网详细地罗列，笔者在此就不再复述。Flowable项目组核心成员在Twitter上透露6.1版本的新特性至少包括以下几点，结合点融网自动审批系统底层工作流引擎的实践，这些新特性依然让人眼前一亮。

异步处理历史数据。当前版本处理历史数据与运行时数据处在同一个线程，大量使用案例表明，处理历史数据占用较长时间而用户不得不等待该线程事务的结束。改为异步处理后性能明显得到改善。

回退功能，运行通过API方式，让工作流当前状态回滚到之前的状态。

增加和拓展对事件子流程的支持

提高对事件监听器事务生命周期的支持

新增全局Counter功能

4、那么Flowable能走多远？

越来越多的公司都意识到：创建一个软件项目最好的方式就是“开源”。

开源使得公司能够大大缩短开发时间，尤其能减轻打造一套通用系统底层架构上的压力，并且采取的是一套兼容性更强的技术标准。不少全球知名IT企业，都在将自己一些已经相当成熟的项目不断地开源出来。

可以说每一套软件系统的背后或多或少都有着开源的影子。

因为开源，任何人都可以参与进来，无论供职哪家公司，或者是自由职业者。然而开源也存在这样一个问题，开源能让每个人都自由地发挥聪明才智，但是它也并非想象中那样美好。毕竟我们处于一个商业的世界，那些背后支持着开源项目的大公司，在决定技术和项目的走向上总是拥有更大的话语权。

当一个开源项目的核心主创人员与开源项目背后的大公司发生技术和项目的走向分歧时，主创人员不得不另立山头，想要将自己的想法实现出来。但是同样危险的是，假如一个开源项目背后没有一个实力雄厚的公司支持下去，那么也许就会是一个有头无尾的开源项目。

而Flowable作为Activiti的一个分支，能走多远？或许也将受此因素影响。从Tijs Rademakers的LinkedIn上更新的简历来看，现在Flowable项目背后的靠山有可能是这家叫KIS Consultancy的公司。这家公司的主页简单到实在不能再简单了，Flowable的命运一时半会儿还真不好判断。

5、开源分支的利弊？

在开源的世界里开辟分支是常见的。例如这篇文章May the Fork Be with You（http://thenewstack.io/may-fork-short-history-open-source-forks/）提到的一样，前段时间在Docker开源社区热议的一个话题：开辟Docker分支。

一些Docker生态系统的厂商和最终用户进行了一场从Docker分割出去的讨论。在表达各种对Docker公司在Docker Engine上管理的失望背后，这些技术专家和公司实际上是在探索如何解决在支持企业级的Dokcer部署中遇到的各种烦心问题。在诸多正在考虑的选项之中，包括可能会将整个开源的Docker Engine一起另起炉灶( fork )。

开辟分支有时是利于项目发展的。例如这篇文章Why you should fork your next open-source project（http://www.techrepublic.com/article/why-you-should-fork-your-next-open-source-project/），该文指出开辟分支往往是利于改革和创新的。

当然，不一定所有的开源分支最后都能成功。例如这篇文章Open Source Software and Forking: The Good, The Great and The Ugly（http://www.makeuseof.com/tag/forking-good-great-ugly/），通过对LibreOffice与MariaDB的比较、Node.js And与Forward的比较，以及对SystemD的案例分析，有较为详细的阐述，有兴趣的读者值得一看。

6、Flowable团队是如何打消用户顾虑的

Flowable团队对用户说道，“如果你还在犹豫是否加入我们，请看看Activiti源码里的作者们，再看看Flowable项目的成员们。我们是最懂Activiti、在过去几年里推动了整个社区、为社区做出贡献和改革的那帮人。”

说了那么多，那么你会怎么选择呢？！

本文作者：黄斐（点融黑帮），任职于点融工程部Loan Business团队，致力于点融自动审批系统的底层流程引擎和监控服务系统的建设工作