Open Source Politics

Cloudera主要開發open source軟體。今天在公司裡聽幾個資深的developer討論open source的文化,覺得相當有意思,在此分享個人心得。

Open Source Business Model

Cloudera的business model是hybrid open source:藉由銷售open source軟體的license賺錢,並透過proprietary軟體產品的部分做出differentiation,很少公司像Cloudera一樣採用這種銷售模式。而在這公司工作有時就會遇到conflict of interests: 一方面developer希望自己參與的open source project成功,但一方面也希望公司的產品跟競爭對手有differentiation。

為什麼要做open source的生意?當然原因之一是Hadoop一開始就已經是open source project了,另一方面是Cloudera的founder Mike Olson七、八零年代是UC Berkeley的學生,所以非常、非常左派。

從Cloudera的角度來說,雖然公司是用proprietary的部分做出differentiation來賺錢,但其實公司大部份的engineering資源是花在open source的部分,而且公司也一直不斷開發新的open source project,並不會因此就把open source的部份當成免費的午餐,或者不重視。

Conflict of Interest

作為一個software engineer來說,參與open source project其實是對個人的履歷很大的加分,因為要成為一個project的contributor不能只靠嘴砲,一定是有實力、並且透過長時間在計畫裡面投入的累積才行、還要獲得整個社群不同背景的人認可、而且最終的結果全世界都看得到。除此之外也有個人實現的部份,畢竟大家都想參與世界一流的計畫吧!

可是從公司角度來說,為了要養活developer就得賣錢,就必須跟其他競爭對手有differentiation。 Cloudera是用proprietary 的部分做出differentiation,把一些很酷的功能藏起來。有時候就必須做出取捨,把open source的部分做得太好反而對公司不利XD

但其實這個界線很模糊,Cloudera這間公司到目前還是比較像個startup,很多東西都沒有明確的policy,基本上都是相信個人的判斷。作為Apache Software Foundation的一員,developer其實都很希望能維護open source project的成功,但同時每個人都是公司的雇員,而且都有領股票,所以每個人也都希望公司成功,要如何取捨是個很有趣的問題。

Proprietary Open Source Project

open source project也有好幾種。
有一種open source project模式是像MongoDB這種,雖然是open source,但只有一個commercial support provider(MongoDB),而這間公司主導了整個計畫。在Cloudera這種project我們稱為”proprietary open source project”,因為即使source code開源,使用這項專案的客戶仍然會遇到vendor lock-in的問題,因為沒有其他vendor能提供commercial support。

Collaborative Open Source Project

Apache Software Foundation裡的open source project則不一樣。一個project從被ASF接受提案,成為incubating project一開始,就規定計畫裡面一定要有多個不同單位的contributor參與,一定要有不同單位的committer能維護project codebase。這一年的經驗讓我了解培養一個社群,讓世界各地的人都能貢獻doc/patch/bug report,比單純只有把code公開放在github上更加重要。我不知道有什麼好名稱來形容這種開發模式,暫且就稱為collaborative open source project吧。

就商業角度來說,這種開發模式的好處是:更多的人貢獻documentation/patch/commit,等於一個公司只需要用相對少的代價便能維持一個project。舉例來說整個Hadoop codebase超過250萬行,但Cloudera只需要十來個Hadoop developer而已。從使用者的角度來說,不必擔心如果有一天Cloudera倒了(應該不至於….)或者Cloudera放棄開發這個project。

但另一方面,因為社群的參與者來自四面八方,就會有不同的conflict of interest。例如在一個project X有人提交了一個新feature,假設Cloudera提供project X, Y, Z的技術支援,但Hortonworks提供project X, W, V的技術支援,自然而然Cloudera的developer就只會考慮到這個新feature 對project Y, Z的影響,但Hortonworks的developer或許並不以為然。一般來說,在假設每個人都是出自善意的前提下,最後都能得到一個比較好的解決辦法,例如將feature設計成configurable,要用的人就自己enable它,擔心有bug的人就disable它。不過這也讓Hadoop變成非常非常複雜。

我也曾看過patch reviewer隸屬於競爭對手公司,結果code review很刁難,甚至不論如何就是不願接受patch;我也曾經看過有人爭執到最後在Jira上吵架打筆仗,不過這真的很罕見,畢竟大家做事都是存了個volunteer的心態。

在collaborative-open source的公司還有個很大的特色:因為大部份的開發都透過社群間的互動完成,product manager的角色很少,而且他也無法直接影響產品的開發,連design doc都是由開發者寫的。事實上Cloudera所有storage相關component — HDFS, HBase, Accumulo, Kudu總共三十人上下,只有一個PM。考慮到各個component又各自有數十乃至上百外部非Cloudera的contributor,等於一個PM對應了幾百個developer,以軟體開發公司來說,這應該是非常極端的case。

我覺得Apache Software Foundation是個很好的open source project governance model。它對於projects有一定的要求,並不是隨隨便便丟到github上的project都能成為ASF project,但它也有彈性,讓眾多異質的project可以共享同樣的資源(license, legal, infrastructure, community)。題外話,雖然ASF的project一開始大部份都只是Java相關的網路service, library的project,但現在幾乎所有新的ASF project都是big data 相關的了(或者反過來說,幾乎所有big data的project都屬於ASF了)

Open Source Innovation, Enterprise-grade quality

有時候覺得這份工作相當具挑戰性:我們必須接受open source的innovation,但同時必須確保軟體的品質達到enterprise-grade。舉例來說,有時候會有些人提交了patch修一個bug,卻沒有unit test;或者做了一個新功能,卻沒有design doc,沒有user documentation等等,所以我們必須要把關,確保每個被接受的change都至少符合一定的品質門檻。換句話來說,我們的付費客戶信任我們的技術能力,但我們卻必須信任這項專案某些貢獻來自我們從來不認識的志願者。

Conclusion

Cloudera是間開發open source軟體的公司,而這裡的文化也非常開放。我當初會選擇這間公司,很大的原因就是這裏的文化,還有在這裡做open source開發。每天,我都想著在跟全世界最棒的developer交流,做全世界最有挑戰的工作,每天都很興奮。

Leave a Reply 請留下你的回應