如果你在還糾結該選擇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、在過去幾年裡推動了整個社群、為社群做出貢獻和改革的那幫人。”
說了那麼多，那麼你會怎麼選擇呢？！