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

　　說了那麼多，那麼你會怎麼選擇呢？！