樑飛在 2011 年開源 Dubbo 這個項目的時候，完全沒有想過，Dubbo 這個名字，最後會變成一個 Apache 的商標，會成爲一個在 GitHub 上有 2 萬多人關注、一百多人蔘與貢獻的超級項目。在自己退出這個項目多年後，Dubbo 仍在野蠻生長，並煥發新機。
從商業公司開源出去的產品會變成什麼樣？開源是否一定要按照某種既定的方式去生長？還是說開源的世界有足夠的包容性、開放性，能夠允許各種各樣的創作在其中成長？且看本次二叉樹——Dubbo 項目的故事。
嘉賓簡介
樑飛（虛極），2009 年加入阿里巴巴，負責中間件的開發，Dubbo 開源分佈式服務框架作者，HTTL 開源模板引擎作者，QCon 優秀出品人。 2012 年加入天貓，負責手機天貓 APP 的技術團隊，見證了天貓雙 11 無線化全過程。熱衷參與開源社區建設，傳播服務化，SOA，框架設計，移動應用等架構設計理念。
Dubbo 項目誕生於 2008 年。樑飛最早進入阿里的時候，Dubbo 項目還沒有 Dubbo 這個名字，那時的 Dubbo 還是一個阿里內部的系統。2010 年，Dubbo 項目進行了重構。
“2009 年下半年主要在修 bug，到了 2010 年初的時候覺得這個架構實在是不堪重負，覺得改起來太痛苦了，於是就重寫了。”
從 1.0 進入 2.0，樑飛推動了大量的工作，同時繼續在 JavaEye 寫着他的博客。
“寫博客對你有什麼影響？”
“在社區裏面看別人的博客，他們也在寫一些開源軟件，大家互相看博客，然後就認識了。推薦我來阿里的朋友就是當時圈子裏認識的。”
2011 年的阿里，憋了一股勁兒要成爲一家技術人嚮往的企業。那個時候，開發者剛剛成爲國內各大廠商爭相奪取的寶貴資產。靠什麼吸引最頂尖的開發者？黑客文化。工程師文化。開源文化。
“那時候公司覺得要做一些開源的事情，一個是反哺開源界，同時也希望通過開源來提升公司的影響力。”
當時在淘寶、在阿里 B2B，都有團隊在推動開源。阿里 B2B 這邊決定先拿 Dubbo 項目開源出去。
“大概在 2011 年初做了很多剝離的工作，也把文檔做了梳理。我們並沒有做很強的推廣，我們自己在技術羣裏發了一些文章，就有人開始在用了。”
“那個時候的團隊多少人？我看到你們有一張六個人團隊的照片。”
“人員的變化還是挺多的，六個人是頂峯時期，是我們知名度上來之後加入我們的。我們平時開發基本上就是一到兩個爲主。”
“有外面的人來貢獻代碼嗎？”
“有很多人給我們貢獻代碼。還有很多公司請我們來跟他們講。”
“還有公司問說能不能我們付一點錢，這樣的話他們覺得出了問題可以找我們。”
“但是我們當時沒有這種機制。”
一年時間很快過去了，Dubbo 的用戶越來越多，有知名汽車廠商、證券廠商、水泥廠商、電器廠商、電商廠商。
“當時來這麼多公司，在你的預期之內嗎？”
“超出我的預期。”
就在這個時候，發生了一件大事：阿里巴巴集團要強化 One Company，開始進行架構調整。技術層面，整個公司大統一，就希望不要重複建設，但凡相同的項目都要合併。
當時的淘寶有一個項目叫做 HSF，也是一箇中間件服務框架，跟 Dubbo 做的事情高度重合。
“一開始說可以讓 HSF 合併到 Dubbo 裏面來，給了我們三個月時間要把它們整合起來。”
HSF 項目的作者林昊（畢玄），也是當時國內 Java 領域的知名技術領袖。在 OSGi 非常流行的時候，畢玄可能是國內能夠把 OSGi 解釋的最清楚的人之一。
HSF 和 Dubbo，雖然做的事情高度重合，但是設計理念不怎麼一樣，雖然有些碰撞，但最終目的還是爲了“強強聯合”。
“合併的時候，整個淘系都在用 HSF，而阿里金融、集團、B2B 都在用 Dubbo。”
“時間沒有達到預期，還是沒合併起來。但其實我們把兩邊的協議都兼容好了。”
“後來就決定反向合併，把 Dubbo 合併到 HSF 裏面去。”
“你當時覺得應該合併嗎？”
“我覺得協議能互通是有好處的，並不是壞事。我覺得他們做的挺好，把兩邊的設計理念全部整合在一起了。”
不久之後，Dubbo 團隊調整，去到了各個地方。從外面看來，Dubbo 項目從 2014 年之後就再也沒有更新過。倒是噹噹網開發的擴展版本 Dubbox 後來持續發展，被圈內人評價爲“牆內開花牆外香”。
“你會不會覺得建立共識是一個特別困難的事情？”
“我覺得任何東西必須要有一個主導，但這個東西其實沒有對錯。一個設計是沒有對錯的，有些人可能就是不會認同你這個共識，但你總是能找到認同你共識的人。”
“我就是認爲越簡單越好，我的設計原則就是一定要實用。增加的複雜度越小，能帶來更大的收益，我覺得就值得。”
“那麼，你要怎麼吸引那些能夠認同你的人到你的身邊來？在他們還不知道你的時候。”
“我會去其他團隊認識人，或者在圈子裏面認識人，我會跟他去聊我的理念，我會去分享。有人特別認同的話，他就會來。”
就在所有人都以爲 Dubbo 項目已經沒有未來的時候，事情又出現了變化。
2017 年 9 月，就在項目已經將近 3 年沒動靜的時候，Dubbo 連續發佈了好幾個新版本，並且開始在內部招募對 Dubbo 感興趣的同事。新版本背後的主力開發團隊是阿里巴巴中間件團隊，其中一個重要的人名叫北緯，他從 2017 年 7 月開始接手 Dubbo。在一次對外公開的採訪中，北緯說到：
“我對 Dubbo 的瞭解主要來自樑飛在 JavaEye 的系列文章，再通過自己閱讀源碼，以及在內部 RPC 框架對 Dubbo 兼容的工作中學習所得。”
樑飛曾經在 2015 年寫過一個繼續推動 Dubbo 的規劃，找了很多人聊過：找過開源委員會，找過內部的朋友，找過外面的朋友，希望能共同把這個事情繼續推起來。但是，樑飛已經沒有那麼多時間可以投入到 Dubbo 上。他當時在做天貓客戶端。
“不管是誰，靠一腔熱血都很容易涼掉。”
有的開源項目，通過志願者們投入各自的業餘時間活下去。但我們應該要求所有的開源項目都能做到這一點嗎？事實上，用戶也不會願意將自己重要的東西跑在單純靠志願者們的業餘時間堆砌起來的項目上——尤其是企業用戶。
Dubbo 是中間件項目，用戶一定是企業。企業用戶寧願花錢，有人給他提供服務，而不是搞來一堆免費而沒有保障的東西，自己爲所有的問題負責。
Dubbo 的轉機，在於阿里雲的流行。
2017 年的阿里雲，發現有一批客戶上雲之後，想要用 Dubbo。因爲他們 Dubbo 已經用的很熟了，不想因爲上雲而被迫改變自己的使用習慣。
於是，阿里雲就把 Dubbo 服務作爲自己的一個產品，賣給了這些客戶。
但是，客戶們又提出了一個問題：
“你看你們 Dubbo 都不怎麼更新代碼了是吧？你們自己都不維護了，我們用你的框架就覺得特別不放心。”
這下好了，真正的客戶提出要求了。提升客戶對 Dubbo 的信心，成爲了一件在公司層面有價值的事情。
“怎樣提升客戶對 Dubbo 的信心？”
“讓它進一步升級。”
“最好的辦法是什麼？”
“捐給 Apache。”
北緯帶動着他的團隊，將 Dubbo 項目捐給了 Apache。2018 年初，Dubbo 項目正式進入了 Apache 的孵化器。
一邊是 Apache Dubbo 重啓後的第一個里程碑版本 2.7.0 進入社區投票階段，並將作爲社區的畢業版本；另一邊，Dubbo 正在從一個微服務領域的高性能 Java RPC 框架，演進到微服務框架 Dubbo Ecosystem，打造出一個完整的微服務生態。而此時，距離去年 Dubbo 重啓僅過一年有餘。
我們去找到北緯，希望他聊聊 Dubbo 的未來。北緯說，還是讓樑飛跟我們多講講。
“你覺得什麼是開源的精神？”
“開源的精神，就是大家的智慧能共同成長。”
“你覺得中國的開源現在有哪些做得好的地方和不足的地方？”
“我覺得中國的開源最缺對社區的重視，很多都只是把代碼 push 出來，有些甚至連文檔都不完善，好像人家愛用不用，出了問題也不是我的事。但這可能是一個初級階段，慢慢會成熟起來。但我覺得好的地方就是，大家都相信開源的力量。”
“您會不會覺得中國企業做開源，功利心特別重，光去看這個東西是不是有用？”
“輸出技術影響力是吧？我覺得一個開源社區要能夠一直運作下去，而且能跟上時代的潮流，其實是要與時俱進的。我覺得做開源，就是期望這個東西一直有生命力，這個作品能夠活多久應該作爲它的核心目標。”
“那您覺得 Dubbo 還能活多久？”
“我覺得技術的革新其實挺快的，不革新的話，就有淘汰的危險。但是在這個節點上進行一次革新的話，我覺得它還有很長的生命力。”
“那是什麼樣的革新？”
“任何技術一定是沒有終點的。沒有任何架構能解決現實中所有的問題，而任何一個架構去解決前面的問題的時候，一定會帶來副作用，然後就需要下一個架構去治理。這個探索的方向是沒有止境的，但只有你到達了一個階段，你才能夠去想下一個階段的很多事情。”
“回到原點，十年前的選擇一定是最正確的嗎？就算當時是最正確的，現在也不一定正確對吧？因爲時代在變化。如果我們今天從零開始，我們有沒有更好的選擇？有時候我們背了十年的包袱，反而不敢行動了。但我希望我們下一代演化的時候，我們能夠提出一些顛覆式的理念，真正革新的解決我們現在面臨的問題背後的那些問題，而不是頭痛醫頭腳痛醫腳。這是我們期望做的事情。”
如常，早上 9 點多，樑飛打開郵箱，關於 Apache Dubbo 重啓後的第一個里程碑版本 2.7.0 的討論郵件還在 mailing list 裏熱烈進行着；另一邊，Dubbo 正在從一個微服務領域的高性能 Java RPC 框架，演進到微服務框架 Dubbo Ecosystem，打造出完整微服務生態。而此時，距離去年 Dubbo 重啓僅過一年有餘。