如何評價小米團隊擁有4個hbase committer?

01-01

在小米幹了快一年並剛被HBase社區邀請成為HBase Committer，所以想把對這個話題之前想說但沒好意思說的想法說一下。然後再寫篇博客更系統的說說完整想法：）

目前國內一共10個committer。4個在小米，4個在阿里，一個是小米前員工離職創業去了，一個在英特爾。

小米歷史上的5個committer，四個是在小米當選的，一個是在豌豆莢當committer後過來的 @張鐸並且今年還成為國內第一個HBase PMC member。

阿里的話有國內第一個committer，有一個今年年初當選的，一個從猿題庫跳過去的，一個在我之前一周剛當選的。所以實際上阿里在HBase這塊做的也是不錯的，大家不要太黑阿里。畢竟阿里的規模比小米還是大不少，不同部門用不同的技術很常見，用哪個也不完全是技術問題也沒啥對錯之分。這四個committer分別屬於三個大部門。阿里內部用的HBase也有各種不同的版本，各自維護各自的。

所以可以看出，國內絕大多數committer都是在大公司做事情從而被社區認可，極少在小公司做的變成committer後也跳到大公司了。畢竟大公司對資料庫的要求更高，需要改進的地方多，撞到bug的「機會」多，可以做的事情也更多。像阿里和小米都是有自己的HBase內部分支的，很多feature都是在自己的分支開發上線跑穩定了才提交給社區，這樣提交給社區的patch無論數量還是質量都更高，也就更容易當上committer。

反過來大公司也需要有committer來進一步提升資料庫的質量以及在社區的話語權，因而committer在大公司會更被認可，換句話說是給的錢更多。而且就算不是資料庫，在整個碼農領域，如果想拿到比較高的級別和工資又不太想做管理依然想把主要精力放在技術上的話，其實基本上也只能去大公司。這個和公司本身是否支持開源關係倒也不是那麼大（應該也沒有哪個公司會在用某個開源資料庫的同時還禁止自己員工給社區提patch吧），其實很多國內committer在社區上的工作都是北京時間的晚上也就是下班後在家搞的，一方面白天可能有公司的工作沒時間搞，一方面晚上和美帝那邊的人交流也更方便。

開源社區和公司的商業利益之間的關係，是一個很有意思的話題。我現在是Cloudera的工程師，Hadoop的brach committer，根據我自己的經驗談一下。

首先，公司為什麼會付出資源貢獻到開源社區？主要的好處就是可以「讓全世界的開發者支持我想要的feature」。舉個具體的，有個公司需要HDFS支持文件截短/truncate（參見HDFS-3107下面熱鬧的討論），因為有committer，他們就可以把這個feature推上去。然後一個關鍵的好處就是之後HDFS的所有代碼都需要支持（最少要考慮支持）truncate。比如我正在開發的Erasure Coding（HDFS-7285）。試想如果阿里巴巴有2-3個Hadoop committer，也許就不會放棄雲梯項目。

其次，committer的份量。先簡單說一下Hadoop的committer系統結構。Apache每個項目有個委員會（PMC），然後有若干committer。除了可以直接提交代碼，committer還可以一票否決任何一個patch。還有一些branch committer只能提交到特定的branch里的。任何一個公司不能有超過半數的committer。全職做的話，如果代碼質量好，大部分patch能通過的話，大約1.5-3年可以成為committer。我覺得門檻就在於Hadoop作為「數據中心的操作系統」，對代碼質量要求比較高。而且涉及到不少分散式計算裡面相對複雜的概念，完全理解現有設計和代碼就不是一件容易的事。HBase我沒有太多涉及，但是應該比較相似。

最後，小米有3個HBase committer我覺得是一件值得驕傲的事情。中國公司里還沒有先例。我在一個評論里也提到，華為曾經有兩個Hadoop committer，但是馬上被Intel挖走了。另：中國公司看上去在Spark社區有很好的勢頭。

1、小米管理上更喜歡輕型團隊，從一開始就更願意使用開源項目

2、小米存儲的數據達到那個量級的時候，也剛好遇到合適的雞架團隊，調研後選擇了hbase，可以快速上手，同時技術上完全hold得住

3、hbase的完成度遠沒有mysql的高，很多坑需要雞架去填

4、做了很多事情，成為committer也是必然的事情

5、也是小米趕上了這個時代，這個時代的技術環境跟BAT成長時的又不同，所以技術上的選擇也不同，有了開源項目，可以更平滑地支撐業務的大數據量

Apache社區的committer是完全對等的，committer可以revert任何一個commit，可以在mail list發表支持或者反對意見。當然這也有risk，比如社區相互revert，但是committer除了項目申請的時候其他時候是被投票產生的，所以也對在社區的activity和reputation有一定的保證。因為在投票的時候並不只看commit個數，還綜合評價貢獻者在mail list的討論、review的評論、社區的人脈等等。

非常高興小米擁有4個hbase的committer。apache社區以hadoop和大數據平台為中心，國內大部分互聯網公司從使用開始，針對業務逐步深入，貢獻feature+討論，進而從contributor成為committer。Apache社區的任何一個patch或feature，需要足夠多的討論和修改，這些也都是完全公開的，這填補了互聯網短平快隨時上線的短板，也是提高軟體質量、社區軟體商用的必經之路。也正因為如此，Apache社區的contributor或committer在系統設計、技術view甚至修bug上也有保證。

由於大家本來就來自不同的公司，所以committer是分散的。這樣的另一個好處是大家都因為一個項目在一個圈子和領域裡，有利於相互認識，彼此交流。同時，Apache社區也有極個別由國人主導的項目，如Kylin和Hawq，它們在初期就是國人主要參與開發的。同時在TLP如Spark里也有越來越多的國人Committer和Contributor，值得驕傲！

現在不是四個了嗎

有老闆支持就是不一樣。

如果你的公司可以允許你的工作內容就是往社區發issue和提交代碼，而不是以KPI為尺度要求佔多少業務服務多少用戶。我想出committer只要堅持就是可以辦到的，你想下，一天本來是往公司倉庫的幾十個commit現在都變成往社區提交。混個臉熟堅持個一兩年應該就是可以被提名成committer。

反觀來說，Hadoop/HBase/Hive其實都是被壟斷在Cloudera和Hortonworks手裡，交雜著很多商業利益和很多人是拿著公司的錢為出KPI的目的在提issue和提交代碼。當然不是說這個不好，只是感覺和Hacker的精神距離有點遠。

另外吐槽某公司，明明HBase業務量/機器數是小米的xx倍，但是因為有「牛逼」的「XXS」，所以只能呵呵了。

=== Update ===

&> 試想如果阿里巴巴有2-3個Hadoop committer，也許就不會放棄雲梯項目。

呵呵，即使達到接近半數的commiter和有PMC，某司會照樣放棄。因為不論本身從一開始使用Hadoop的目的，以及到推行東西時不分青紅皂白使用的行政手段/政治手段。來往就是個例子，搞文化大革命一套一套的。而某些所謂自主研發的xx平台，某些人揣測上意，粉飾太平，搞個大新聞，大肆宣傳一翻，自身KPI有了，但實際產生的坑然後背後需要多少苦逼民工加班加點來插屁股。還有很多內部的優秀犧牲品在路上，後續且看Oxs/OxxBase所謂的自助研發資料庫如何「牛X」。

現在還有3個嗎?

我現在就在HBase Committer的slack群組裡面

30號人並沒有看到國內committer面孔... (有的話還想認識下, 畢業回國求個內推!)

我也算是經常逛JIRA的人, 沒怎麼看到國內committer活躍.(除了Spark, 超級無敵多中國人!)

HBase JIRA裡面確實有些issue是***.at http://xiaomi.com Report的, 但還是很少很少... 而且感覺不怎麼受重視, 沒什麼人評論和提patch.

國內committer應該都是在忙公司事和kpi, 沒空閑看社區了吧

不過Cloudera和FB還有Hortonwork真是一把一把的工程師往裡面扔... 壟斷程度太高

最後, 可能國內開源最厲害的是華為, 最近新提了個項目Carbondata已經Apache Incubator. 還有國內企業通過Apache基金會投票的項目嗎? 暫時只知道這個... 還有有段時間了的Kylin(基於Hadoop的OLAP, 百度有在用), 其實也是國人主導開發, 雖然公司是eBay(好像是上海eBay).

其實想表達的, 3個committer真的沒什麼... (如果國內公司想的話, 肯定可以更多)

強答一發，我覺得能體現小米雲存儲組的技術實力，9月在PingCAP的meetup上聽過楊肉的分享，感覺他對分散式系統的理解很深刻，我本身不是很懂分散式，也覺得受益匪淺，他當選committer也算實至名歸吧。

不過我覺得還要理性看待，雖然我們的互聯網很發達，但是我們在基礎軟體領域還差的很遠，美國，歐洲每年都有無數的資料庫項目，大學的研究項目，商業項目，開源項目都有很多，多讀讀論文就知道他們做的東西有多高級了。

我們的目標不能僅僅是成為一些知名開源項目的committer，需要更大的野心，比如阿里的OceanBase，PingCAP的TiDB，還有華為準備做的新資料庫，都是以替換Oracle為目標。姑且不說能否成功，我覺得這是很重要的一步，說明我們已經有信心涉足這些我們以前很少涉足的領域了。現在的情況是，本來做這些事情的人就不多，很多人還要總對他們冷嘲熱諷，小米有幾個committer，有些人也能強行噴，碼農何苦為難碼農呢。我們要多些支持和鼓勵，互相學習，也要有更大的野心，一起來推動國內基礎軟體的發展。如果有一天，美國的碼農以成為我們國人發起的開源項目，比如TiDB的committer而驕傲時候，那才是值得我們自豪的。

喝水吃飯一樣平常的事，無需過度解讀。並且需要指出，open source contribution 分很多，改client修bug與改架構加核心功能天差地別，改代碼和負責做release又是天差地別。

公司角度看，用開源並填坑，這並不是嚴格意義公司參與開源，這和個人參與沒區別啊。不談公司核心產品開源這個爭議，就看公司玩開源的態度，可以看看：

公開了多少最核心常用演算法？

公開了多少基礎構建的實現？比如內核的。

公開的演算法，軟體，多少別的公司真的大膽在用。

公司是否有獨立的法律團隊處理開源相關法律問題。

公司是否有各部門聯合辦公統一審批軟體或演算法開源的常設Committee

一年全公司規模開源培訓多少次？

是否有完整專職的工程團隊跟進上述事項。

國內公司普遍差距很大的。

踩坑填坑，程序員做自己份內的事情，不必過度解讀。

想了一下大概流程這樣：

1. 公司要做一個項目，技術選型選到某開源工具

2. demo方案驗證-&>測試-&>上線-&>運營重構改bug 翻源碼

3. 我靠這裡怎麼有個坑，這種情況下會掛啊！

4. 我靠這個參數為什不能靈活一下配合我司的另一個輪子！

5. 我靠這個為什麼不能暴露出來，監控不方便啊！

6. 我靠這個新特性怎麼不做，我司急需啊！

7. 開branch修修補補增加新功能，重新編譯

8. 官方新版出了，改了不少bug，有了這個特性，可是branch改了那麼多怎麼辦，這麼多衝突，這麼測試怎麼搞，和官方發展方向有分歧了以後怎麼辦

9. 有沒有辦法做committer，大方向影響官方版，小修小補能提交提交不能提交和公司內部的branch差異也比較小

10. oh yeah 真的可以耶~

這有用嗎誰都能幹啊

偶還是網易pomelo前10 commiter呢

不管怎樣，還是挺令人欣慰的。

這個世界上各種各樣的組織多了去了，小米有3個是這個組織裡面的人，可能只是他們由於技術需要等原因加入這個裡面，這也要拿來炫耀？

個人揣測一下，也許華為技術大牛加入的社區小米還沒資格進呢。他們要是也把這些列出來，就算看似高大上，不過對於消費者來說，這也是一件既無聊又傻逼的事。

奧氏體304都要包裝一下，可想。

小米不是要做hadoop的封裝嗎，重金聘幾個committer也是情由可緣，其實阿里另一方面想的話，也算是提高了自己的自主研發吧……facebook做什麼呢，都要自己研發