封面故事：Apache ECharts團隊：ASF頂級項目是怎麼煉成的？
作者：凌敏
優秀的產品背後，必定有優秀的團隊做支撐。《頂尖技術團隊訪談錄》系列採訪以國內知名公司的 IT 技術團隊爲線索，展示他們的文化、思想與經驗。本期，InfoQ 走進 Apache ECharts 核心團隊，瞭解 ASF 頂級項目背後的故事和團隊沉澱下來的開源經驗。
Apache ECharts 是一個基於 Web 前端技術實現的數據可視化產品，它誕生於 2013 年，由百度 EFE 團隊創建並開源，並於 2018 年 1 月捐贈給 Apache 軟件基金會。2020 年年底，團隊發佈了全新重量級的 Apache ECharts 5。2021 年 1 月 26 日，Apache 基金會官方宣佈 ECharts 項目正式畢業，成爲 Apache 頂級項目。
目前，在 npm 上，Apache ECharts 的每週下載量約爲 25 萬，在 GitHub 的關注數也達到了 4.6 萬。
ECharts 的三次蛻變
從 2012 年正式在百度內部立項到現在，ECharts 主要經歷了三個發展階段。
在早期階段，ECharts 的核心代碼主要由作者林峯貢獻。2013 年 6 月和 2014 年 6 月，團隊分別發佈了 ECharts 1.0 和 2.0 兩個大版本。彼時，ECharts 基於 html5 Canvas，是一個純 JavaScript 圖表庫，並支持折線圖、柱狀圖、散點圖等多類圖表展現，同時支持任意維度的堆積和多圖表混合展現。
2015 年年初，隨着原作者林峯離開項目，ECharts 的主要維護工作交給了沈毅、宿爽。這之後，ECharts 的核心團隊也逐步趨於穩定，除沈毅、宿爽外，還有包括羨轍、俊婷、德清在內的多位技術人蔘與其中。至此，ECharts 正式邁入第二個發展階段。
在進行了半年左右的小版本維護工作之後，團隊成員意識到 ECharts 是時候做出改變了—— 3.0 版本要重構整個架構。之所以做下這個決定，一方面是因爲彼時的 ECharts 存在很多難以修復的 Bug，另一方面，ECharts 當時的架構設計對於功能的組合和擴展並不是很靈活，經常引來開發者抱怨。
在覈心團隊再三權衡下，ECharts 開始進入 3.0 版本的研發中。最終歷時半年，於 2016 年 1 月發佈了 ECharts 3.0。此後，ECharts 團隊收到了很多 issue，在高頻率地迭代了幾個小版本後，最終整個項目在 3.2 版本逐漸穩定了下來，而新的架構也在擴展發麪發揮了不少作用，保證了 ECharts 的持續發展。
2018 年年初，ECharts 正式發佈 4.0 版本，同時由百度捐贈給 Apache 軟件基金會，並進入第三個發展階段。
2020 年年底，團隊發佈了 Apache ECharts 5，完成五大模塊、十五項特性的全面升級，圍繞圖表的敘事能力，在動態敘事、視覺設計、交互能力、開發體驗以及可訪問性等方面做了專項優化升級，讓用戶獲得更好的數據可視化的展現效果。
在 Apache 孵化的那些日子
從加入 Apache 軟件基金會孵化到正式畢業，ECharts 團隊成員在協作模式、思維方式上發生了翻天覆地的變化，如何才能更好地應對這些變化？如何讓項目順利畢業？
InfoQ：會什麼爲選擇加入 Apache 軟件基金會？
A：在加入 Apache 軟件基金會之前，ECharts 項目 95% 的開發者都來自百度內部，協作模式也依託於內部溝通。從項目本身的發展角度來講，這種方式存在一系列不穩定因素。一方面，項目很容易受到其他因素影響，比如當團隊其他業務比較忙的時候，很難再抽出時間來做 ECharts 項目相關工作，最終導致項目的發版很受影響。另一方面，加入 Apache 也能幫助 ECharts 吸引更多來自不同公司的開發者加入進來，從而讓整個開源的生態變得更加健康。此外從開發者角度來講，ECharts 項目加入 Apache 之後，開發者在選擇產品的時候也能更有信任感，在版權方面也不會有太多顧慮。
InfoQ：加入 Apache 軟件基金會後，團隊在協作模式上發生了哪些變化？
A：在加入 Apache 之前，團隊溝通主要是在公司內部，採用面對面討論或是在即時通訊軟件裏討論的方式。加入 Apache 之後，我們需要經常用郵件去做異步溝通，剛開始我們對這種協作模式是不太適應的。一方面，郵件溝通效率比較低，發出郵件之後，可能要等待幾個小時才能收到對方的回覆，有時討論一個非常簡單的問題，一來一回也需要一週的時間。另一方面，我們團隊的大部分開發者都是中國人，在郵件列表裏用英文進行溝通存在一定難度。
後來我們在跟 Apache 的導師以及其他有開源項目經驗的人溝通後意識到，對於開源項目來說，效率並不是唯一的追求目標，怎麼能吸引更多的開發者加入到我們貢獻者的行列中去，纔是現階段更重要的事情。郵件列表的協作模式能讓更多人知道我們的討論內容，知道這個項目有哪些重要的事情正在發生，同時，這種協作模式也能讓外界看到我們的友好姿態，更願意參與進來。
InfoQ：除了協作模式，還發生了哪些變化？
A：最大的變化可能來自於思想上的轉變。一個很明顯的例子就是，我們在做 PR Review 的時候，會願意花更多的時間去 Review 別人的代碼。在過去，面對別人提交的有問題的 PR，我們會覺得與其和對方溝通具體應該怎麼做，不如直接把這個 PR 關掉，自己重新提交一份正確的 PR，這樣也能節省我們很多時間和精力。
但加入 Apache 後，我們也意識到如果每次都關掉別人的 PR，很可能最後維護這個項目的永遠都是那麼幾個人，外部開發者很難參與進來。所以現在，如果別人的代碼有問題，我們也會花很多時間去和對方解釋，一步一步指導他怎麼做，同時也有越來越多的開放文檔，幫助開發者更好地加入參與進來。
InfoQ：如何才能順利從 Apache 軟件基金會畢業？需要注意什麼嗎？
A：從孵化到正式畢業，這個過程中有幾件比較重要的事情需要維護者注意。
第一，要學會用 Apache 的方式進行發版；第二，要保證發版固定的週期；第三，要發展一些外部的貢獻者，比如來自不同公司的開發者等等。以上這三點都是可評估的維度，除此之外，還要解決一些其他方面的問題，比如品牌是否被其他項目佔用等等。
其實要想從 Apache 軟件基金會畢業，並沒有明確的指標要求，像我剛提到的發版週期，也不是一個絕對的數字上的評判。最重要的是要向 Apache 基金會證明，這個項目在沒有導師幫助的情況下，也能由項目的管理委員會正常獨立的運營下去。
維護開源技術項目的挑戰
開源技術項目的維護離不開所有人的共同努力，如何讓項目、社區發展得越來越好，是每個項目參與者必須要面對的難題。
InfoQ：您是如何理解開源的？
A：從名字上來講，開源指的是開放源代碼，把你的源代碼開放在網絡上，但其實這僅僅是開源的第一步。接下來，你需要讓更多的人使用你的開源項目，比如，你要建立使用文檔，告訴別人怎樣用這個項目。如果沒有這一步，沒有人用你的開源項目，那麼開源和不開源是沒有什麼區別的。
下一步，你要考慮的是，怎樣才能讓這個開源項目持續有活力，怎樣才能吸引更多有意願的開發者參與進來，貢獻他們的想法。因爲不管是個人項目還是團隊項目，開發者都是有限的，項目很容易受到不穩定因素干擾，影響到發版或日常維護。通過吸引更多的開發者參與進來，項目也會更加健康，具備更長久的生命力。
其實很多開發者對於開源項目都存在一種誤解，會覺得這樣一個免費的項目就應該服務於他，應該無條件地第一時間響應他提出的問題，並立馬解決。這樣錯誤的預期必然會帶來一定的心理落差。所以對於開發者而言，不要對項目有太多苛責，不要一味地去索取，而是要想想自己能爲自己喜愛的開源項目做些什麼，這對於雙方都是有益的。
InfoQ：在維護開源技術項目的過程中，您遇到過哪些讓您印象深刻的挑戰？
A：其實挑戰還是比較多的，最大的挑戰可能就是如何降低開發者參與的門檻，如何減少開發者參與過程中產生的挫折感。作爲開源項目的維護者，我們要做的就是在項目的開發流程中，儘量地不消磨掉開發者的熱情。我們要通過一些代碼架構的優化，以及項目流程的優化，來引導開發者積極貢獻，提高大家參與的熱情。
當然，其他方面的挑戰也比較多。比如曾經有段時間，我們很頭疼 issue 的維護工作，因爲這是一個非常消磨意志的事情。一方面，我們每天要面對大量的 issue，我們需要充當客服角色，來回答開發者們提出的各種問題。另一方面，有些開發者提的 issue 描述得比較混亂，讓人有點摸不着頭腦，也不知道該怎麼回答。最後，我們參考了其他非常成功的開源產品的做法，通過提供一個 H5 創建的幫助頁面，給開發者一個固定的格式來填寫他們遇到問題，或是他們想要的新需求。另外，我們還寫了一些機器人腳本，來第一時間回覆開發者提的 issue。這些工作在一定程度上也幫我們節省了非常多的精力。
InfoQ：在您看來，維護這樣一個大型的開源技術項目，需要具備哪些關鍵素質?
A：第一，要有同理心，要多站在開發者角度去思考問題。如果我是開發者，自己在使用一些開源項目時，問題得不到解答，我的內心也會很焦急。作爲開源項目維護者，應該理解開發者的這種心理，通過一些工具或方法，提高開發者的使用體驗。比如，我們就會通過提供 H5 表單的方式，幫助開發者更好地提交 issue，我們也能快速解決問題，從而進一步完善用戶體驗。
第二，要有服務的心態，多給予開發者幫助。對於開源項目來說，如何吸引更多的開發者加入進來，是我們一直要思考的問題。一名開發者從開源項目的用戶變成貢獻者，是存在一個轉換關係和轉換比例的。要想提高轉換比例，一方面，需要項目維護者先做出一個有價值的產品，當你的產品本身足夠有吸引力，才能讓更多的人來使用它。另一方面，維護者可以通過做一些事情來提高轉換比例，比如在開發者使用產品的過程中，給他足夠的幫助，讓他感受到社區的溫暖。受到過社區幫助的開發者，在未來的某天，也許也會去幫助社區裏的其他人，把這種幫助傳遞下去。
第三，要有責任感，對作品和開發者負責。對一個大型的開源項目來說，任何一個很細微的改動都可能會帶來正面或負面的影響，因此維護者需要具備足夠的責任感，不能把問題丟給產品的使用者自己解決。
第四，要有自驅力，要有足夠的熱情。維護一個用戶量比較大的開源項目，需要投入大量的時間和精力，自己日常的一些工作和生活也可能會被打斷。因此，維護者需要具備很強的自驅力，並對項目保持熱情，有時甚至還要主動、默默地承擔一些事情。比如，很多時候維護者做的工作很可能會被忽略，優化升級後的一些小細節，如果不對比，使用者可能一直不會發現，也不會知道原來一個小小的細節的改動背後，維護者需要做很多次的試驗和嘗試，才能保證改動的正確性。
InfoQ：如何打造一個持續活躍、健康發展的社區？
A：我覺得沒有一個公式能告訴你怎樣把社區打造好，因爲不同的項目有不同的風格，大家情況也不相同。對於 ECharts 而言，我們也一直在探索這個問題，通過這幾年的建設，我們也積累了一些經驗。
第一點，作爲開源項目的維護者，你要對社區建設有足夠的重視，而不是把它當做可有可無的事情。第二點，通過產品持續爲你的用戶提供價值，這樣用戶才願意反哺社區，願意與你建立信任感。第三點，通過一些具體的方法或策略，降低用戶貢獻的門檻。比如，你可以給用戶提供更多完善的文檔，做 PR Review 時對他們進行更詳細的指導。最後，不管他的 PR 有沒有被合入進來，都要表達對他的感謝，讓他意識到他的貢獻是有意義的。
最後，像 ECharts 這樣由公司牽頭髮起的項目，能獲得公司認可和持續的支持在項目發展階段是非常重要的。我們非常感謝百度多年以來全力支持 ECharts 項目，如果不是出於對開源精神真心的認可與遠見，是很難堅持做這樣沒有商業收益的事的。通過捐獻給 Apache 軟件基金會，公司希望項目能夠發展出更健康的社區，最終實現不依賴於少部分核心開發者也能健康持續發展的目標。而在項目真正能實現自主可持續發展之前，公司的持續支持則是項目健康成長非常重要的因素。通過在 Apache 基金會孵化期間的磨合與學習，ECharts 項目可以說已經在一定程度上實現了自主可持續發展的目標。而百度也將繼續爲項目提供支持——作爲公司員工和 ECharts 核心開發者，這一點對我們來說是非常鼓舞人心的。
對 Apache ECharts 的期待
從 2013 到 2021， ECharts 已走過 8 載。下一步，將走向何方？
InfoQ：如果讓您給現在的 Apache ECharts 打分的話，您會打多少分？爲什麼？（滿分 100 分）
A：可能會從功能性和開源社區兩個維度來進行打分。功能性方面，我會打 80 分。雖然現在的 Apache ECharts 功能很豐富，但由於精力或其他方面的限制，我們還沒有做到想象中的最好的樣子。開源社區方面，我會打 65 分。雖然我們通過了 Apache 的畢業要求，但與其他像 Vue、React 或者 ThreeJS 這樣成功的前端開源項目還是存在一定差距，未來我們也會繼續努力。
InfoQ：接下來 Apache ECharts 會朝着哪個方向演進？目前有什麼計劃？
A：從總體上來說，我希望 Apache ECharts 是一個可以持續帶給人驚喜感的項目。具體功能方面，接下來我們會專注在兩個比較大的方向上。第一個就是持續增強我們的拓展能力，除了優化接口，帶來一些更靈活的定製化之外，還要在文檔和示例的引導上多下功夫。第二個就是提高應用程度，讓大部分開發者能夠做到開箱即用，讓我們的默認設計在一些領域方向能夠滿足他們相應的專業性需求，當然這也需要我們在相應領域具備一定經驗，這也是一個需要慢慢積累的過程。
社區方面，我們下一步會通過優化各種周邊工具，以及整體的開發流程，來提升開發者的開發體驗，降低開發者貢獻代碼的門檻。
嘉賓介紹：
羨轍 Apache ECharts VP
沈毅（pissang） Apache ECharts PMC
宿爽（爽爺） Apache ECharts PMC
王俊婷（叮叮） Apache ECharts PMC
目錄
封面故事
Apache ECharts團隊：ASF頂級項目是怎麼煉成的？
重磅訪談
爲什麼我說低代碼是“行業毒瘤”？
技術實踐
順豐科技架構升級之路
十年三次重大架構升級，微博應對“極端熱點”的進階之路
貝殼一站式大數據開發平臺實踐
技術管理
聲網高澤華：關於技術領導力的成長點
創新研究
騰訊 AI Lab 圖神經網絡研究結果已經被 ICLR-2021 收錄