開源經驗：社區是如何管理HBase項目的？

3月10日，豌豆莢的張鐸成為中國第5位HBase Committer。現在越來越多的公司和開發者都開始關注開源，開源正在經歷前所未有的繁榮時期，但這只是開始。從整體比例來看，國內參與開源項目的人并不多，很多人都不知道如何參與開源項目。在這個背景下，InfoQ采訪了張鐸，希望能深入挖掘HBase項目組織架構、運營、流程等方面的細節。

演講嘉賓

張鐸，豌豆莢基礎技術負責人，目前主要關注存儲相關的技術。2010年研究生畢業，來豌豆莢之前一直在網易有道工作，從事的也是基礎技術相關的工作。2014年底帶領團隊開發了名為Codis 的分布式存儲解決方案，并于2014年11月7在GitHub上開源。

第一次提交代碼

作為一個歷史悠久的開源項目，HBase非常復雜，據統計，HBase差不多有34萬行代碼，主要使用Java語言編寫，部分模塊可能會使用C 語言。我在2008年底的時候就開始接觸HBase，但是提交第一個Patch是在去年的9月份，當時在工作過程中發現，HBase有時候會丟失數據，確認自己的代碼沒問題后，我開始懷疑是HBase的bug，定位問題后就立即對該問題進行了修復。而小米的馮宏華已經是HBase的Committer，也正好是我的學長，在馮的鼓勵下，我把自己發現的問題提交給了官方。

提交后不到10分鐘的時間，就有一位committer聯系我讓改代碼的說明格式（有些地方不符合規范），簡單修改后，這位committer立即@了負責這塊代碼的其他committer。整個提交過程非常快，HBase方的反饋也很好，和我之前想的根本不一樣。

如果要總結下第一次貢獻代碼的經驗，我覺得應該膽子大點，不要害怕。不要懷疑自己的能力，發現問題就提交。不要擔心自己的英文不好，只要發現問題就往上提，這對自己的成長也有好處。很多國外的程序員寫的代碼很爛，但是他們卻敢于提交。而提交后又有很多牛人來幫你修改，這相當于免費請大牛當私人教練。

如何成為HBase的Committer？

并不是第一次提交代碼后就能成為Committer，只要提交過代碼的都是Contributor的角色。Contributor要成為 Committer，需要持續不斷的貢獻代碼，并且開發過新的feature（猜測）。當代碼貢獻到一定程度時，項目管理者會主動與你溝通是否愿意成為 Committer，并不需要自己申請。

成為Committer之前，我一共提交過30次左右的代碼，從官方的邀請信中可以看到，PMC（項目管理者）比較看重我為HBase 1.1提交的幾個大的feature，以及對HBase整個項目的單元測試流程的改進貢獻。

目前HBase共有41個Committer，但真正活躍的不到一半，目前也沒有相應的退出機制。Committer之間主要是通過郵件溝通，也沒有固定的在線溝通時間。

代碼提交后的流程

Contributor不能直接push代碼到倉庫，他的代碼需要經過Committer審核。如果是一個簡單的改動，那一個 Committer就可以直接做主。如果是一個比較大的改動，那就需要多個Committer一起討論才能決定。如果是可能影響兼容性的改動，那需要與該版本的負責人討論后才能確定。

HBase的代碼并沒有使用GitHub進行管理， GitHub上的代碼 只是一個鏡像。Apache基金會中一些比較老的項目使用的都是官方自建的Git倉庫，缺陷管理工具用的是JIRA，提交代碼后，JIRA中相關 issue的狀態會變為Patch Available。同時，項目機器人會定時掃描是否有Patch Available狀態的issue，如果有，它會下載相應的附件，并通過腳本檢查格式是否正確、單元測試能否通過，并把結果發回到JIRA。當 Patch要合并到某個版本之前，該版本的負責人會重點進行測試，包括功能和性能上的。

HBase的項目架構

HBase的項目直接負責人稱為VP，VP全職負責這個項目。VP下面是幾個PMC，每個版本的release manager一般是某個 PMC。PMC下面就是Committer了。一般情況下，一個Committer會對HBase的固定負責某個版本的某幾個塊功能模塊特別熟悉，所以當 Contributor提交代碼時，HBase項目組會優先讓對該模塊比較熟悉的Committer來審核，這個Committer的意見也是最重要的項目組是有審核該代碼的第一負責人。

HBase主要的代碼貢獻者都是 Cloudera 和 Hortonworks 的員工，他們都是全職負責HBase，甚至HBase中寫文檔的人都是Cloudera的員工。Cloudera和Hortonworks都是基于HBase的商業公司，他們同時維護開源的HBase，但同時也都有自己的商業版本。

社區分歧

每個開源項目都會遇到技術方案分歧的情況，同樣HBase也有。HBase在這方面沒有好的解決方案，每次討論這樣的問題時都會分為兩派，大家都在說自己的解決方案以及優勢，但是永遠也沒有結論。目前也沒有相關的投票機制，比如誰的得票多就聽誰的，因為投票很容易導致產生更大的分歧。

其它開源項目也沒有好的解決方案。如果社區比較融合，大家都抱著解決問題的心態來看待這樣的分歧，那還好辦。但如果大家都比較偏執，一派人堅持要這樣做，另外一派人堅持要那樣做，那這樣下去稍有不慎社區就可能分裂，這已經有先例了。再或者就像HBase一樣先掛起這問題，但也不是長久之計。其實分歧問題和社區文化直接掛鉤。

開源談

如果只靠個人無私奉獻，開源項目很難發展起來，更不用說建立生態圈。如同公司一樣，開源社區需要有人來推動、管理和運營，開源不僅僅是代碼本身。比如前面提到的開源文化，這完全是需要有人來引導的。

豌豆莢一直比較崇尚互聯網「開放」「平等」的價值觀，也很支持重視開源技術。，公司決策層領導層也非常重視員工在技術方面的長期積累，所以也允許我也有一些比較自由的時間來研究HBase，做一些貢獻，也不要求這個研究馬上得在多少天內就貢獻多少代碼或者做出多少新feature。我覺得豌豆莢對于基礎技術的長期積累還是很看重的，而且很有耐心。縱觀一些好的公司，一定會多給員工一些屬于自己的時間探索新的東西。如果每天都很忙，不停的在加班，那什么時候去進步了？員工的成長甚至跟不上公司的成長，長期來看反而會拖累公司。