2018年末，GitHub發布了年終總結報告，報告中指出：2018年，Github 注冊的新用戶數量是前六年的總和，且目前Github上的代碼倉庫已有1億個。這樣的結果，相信Linus Torvalds在1991年寫下第一份Linux開源郵件的時候怎么也不會想到，現在我們可以毫不夸張的說，“開源軟件正在吞噬世界”。

1998 年，Bruce Perens 和 Eric S. Raymand 聯手創建了開放源代碼促進會，“開源軟件”正式有了自己的定義。現在，開源軟件已經二十多歲了，其內涵和外延也在不斷深化和拓展之中，“開源”二字代表的不僅僅是一個項目，更是代表了整個社區，代表了隱藏在背后的開發者和工程師們。

站在開源背后的工程師們之間是如何進行協作與交流？基于開源軟件的商業公司如何更好的發展？開源團隊如何更好的管理和研發一個項目？… Cloudera計算平臺研發負責人譚望達詳細的為我們進行了一一解答。

1. 寫在前面的話

It’s actually open source software that’s eating the world John Vrionis, Venturebeat, 博客

隨著這幾十年開源的熱潮，開源軟件逐漸的占領了整個軟件的生態。1991年Linus Torvalds在發出第一封宣布Linux開源的郵件時候可能沒有想到會對軟件市場造成如此大的影響。隨著1999年Apache軟件基金會的成立，這幾年開源軟件更是繼續飛速發展：

從大數據領域來說，有Hortonworks（2014年）和Cloudera（2017年）的IPO（基于Apache Hadoop以及各種Apache基金會的產品），2017年的Mongo IPO（基于MongoDB），2018年的Elastic IPO（基于Elastic Search, Logstash, Kibana），到近幾年取得大量融資的Databricks (基于Apache Spark)，Confluent（基于Apache Kafka）。

從云原生領域來說，CNCF基金會在2015年的建立讓整個生態也飛速的發展，其中孵化了Kubernetes、Prometheus等等項目，后面有Google、Redhat等巨頭參與。

別的領域的開源軟件發展也不甘落后，比如說機器學習領域影響重要的軟件幾乎以開源為主：Tensorflow (來自Google)，Pytorch（來自Facebook），Apache MXNet。

從國內來說，各個公司也在擁抱開源、或者以開源作為產品的基本形式，比如說PingCAP （基于TiDB），Kyligence (基于Apache Kylin)，還有最近炒得火熱的阿里巴巴收購Data Artisans（Apache Flink背后的公司）。

從開源領域來說，現在是糧草兼備，也有東風的狀態：好的開源項目很容易在相關的領域得到更多的反饋，也會逐漸變得更加的好用和穩定；開源項目成長到一定級別后，能夠吸引獨立的公司在后面支持，能夠得到穩定的資金和人力的投入；參與開源軟件的核心工程師們也容易得到更多的名譽、影響力。長期的反饋會讓開源軟件發展得越來越好，對于公司來說也會越來越重要，參與開源的工程師越來越多。

因為開源軟件對于各個領域來說的影響越來越大，公司或多或少都會參與開源。所以怎么能夠更好的管理基于開源技術的團隊會是一個非常值得思考的話題。這方面討論的文章相對較少，所以也希望能夠分享一下我這幾年在管理基于開源技術的團隊中的經驗。

2. 開源團隊管理

在展開之前，什么叫做是開源團隊呢？從我看來，開源團隊主要的特征是，團隊的產出主要是基于一個或者幾個開源軟件，并且團隊有能力投入部分的時間到開源社區之中，參與開源軟件的開發與計劃的制定等等。

相對來說，如果一個團隊堅持“拿來主義”，直接用開源軟件而很少幫助反饋開源社區。或者是在公司內部的分支上進行修改而不將改進回饋到開源社區中。那么這樣的團隊則不是我這里想要討論的“開源團隊”。這樣做有若干的缺點，我在下面會展開討論。

下面的文章中，(2.1 從工程師的角度出發), 首先作為團隊最重要的一部分，我會談談開源對于團隊內的工程師來說，到底有哪些好處和挑戰。（2.2 從公司的角度出發）其次從資源的提供方 - 公司來說，開源到底有哪些好處和挑戰，怎樣選擇開源與否，怎樣選擇不同的開源方式。(3 談談細節), 我會談談從細節出發，開源的一些具體的問題如何解決，比如說怎樣制定基于開源的開發計劃和發布計劃等等。

2.1. 從工程師的角度出發

2.1.1 工程師參與開源的目的和方式

首先我們來了解一下，工程師參與開源有哪些目的呢？在我看來，主要是有下面的一些目的:

• 更好的技能，對于工程師而言，一個重要的目的是如何讓自己的技能樹跟隨者時代的發展。由于良好的開源生態系統，現在的公司越來越少會捆綁在閉源的商業軟件中，這導致優秀的開源項目一般來說生命力很長。工程師如果熟悉精通開源項目的話，一般會很容易在市場中找到一個有競爭力的位置。
• 更好的認可度、知名度，在熟悉使用開源技術的目的之外，一部分活躍的工程師會花上不少的時間來去參與開源項目的技術討論，反饋開源軟件的缺陷，以及將改進貢獻回開源項目中去。在這個過程中，這些工程師可以得到更多人的認可，并且也會讓自己在市場中的競爭力得到提高。比如說一個職位需要精通Apache Hadoop的工程師，工程師甲只是熟悉在生產壞境的使用，乙在甲基礎之上貢獻了若干不錯的改進并且合并回了主干，如果兩者的背景類似，公司容易青睞乙。
• 在圈子內建立更多的人脈，由于開源社區的開放性，很多開源社區的參與者也是抱著一個很開放的心態來與人溝通。多參與開源社區可以讓工程師與來自不同的公司、文化背景、語言與國際的人進行溝通。在過程中可以更多的積累人脈與了解到別人的思維方式。不容易固化在自己的小圈子里面。

那么工程師參與開源主要有哪些方式呢？（從易到難排序）

• 熟悉使用開源項目，這個比較顯而易見，在工作中如果對某些開源項目用得比較多，那么自然會更好的熟悉開源項目。
• 參與貢獻開源項目，參與貢獻也有很多的方式。主要有代碼貢獻和非代碼貢獻。非代碼貢獻主要是有，反饋缺陷；幫助社區其他用戶回答相關的問題；（在技術會議、博客等等）分享自己使用某些開源項目的經驗和教訓；幫助開源社區推廣項目(布道師，Evangelist)
• 參與主導開源項目的方向，當對于開源項目的貢獻累積到一定程度的時候，工程師就可以更多的參與開源的開發方向，把開源項目計劃往自己更希望的方向推進。

2.1.2. 對工程師的挑戰

第一個挑戰：如何把個人的目標和團隊的目標結合在一起。

參與開源當然可以是興趣驅動，不過對于個人與團隊來說更高效的方式是，能夠讓個人的目標和團隊的目標結合在一起。不然對于團隊而言，工程師花費的努力并不能讓團隊得到提升；對于工程師而言，也未必能幫助當前的工作（不過可能可以幫助下一份工作）。純粹從個人興趣出發的開源活動在短期內可以幫助自己思考未來的方向，但是如果長期來說，可能會難以讓個人集中精力，也難以爭取公司從資源、時間上的支持。

第二個挑戰：廣度 vs. 深度

參與開源、并且代碼被接納并且合并到某個開源項目主干會給工程師帶來成就感，但是我也見過一些工程師，每天樂此不疲的在不同的開源社區中找尋各種瑣碎的問題，比如說有問題的單元測試代碼，一些代碼的拼寫或者格式上的建議，不夠精準的日志信息等等。結果就是過了一年可能可以有幾百個PR (pull request)被合并到主干中，Github主頁上的格子每個都是綠色的。

不過從個人目標和開源項目的發展來說，這個是最好的方式嗎？毋庸置疑的是，對于開源項目而言，這些改進都是正面的，相對也很容易被合并進去，因為這樣的改進一般很安全，不會帶來什么錯誤。但是從另一方面來說，努力去做5個重要的、會改進生產環境中的性能的改進比做100個代碼拼寫錯誤的改進得到的提高更大，對開源社區來說也更重要。（因為代碼拼寫錯誤對于項目的用戶和可維護性來說的影響一般不算很大）。

2.1.3. 團隊管理者應該做些什么

首先團隊管理者應該鼓勵工程師多參與開源: 參與開源可以很好的讓工程師得到鍛煉。從溝通能力，設計能力，代碼質量方面都能夠得到很多的提升。現在很多公司特別是互聯網公司的工作方式比較糙快猛，要求出活快，一個人寫代碼就行了，代碼審核只是走一下流程，代碼過幾年就得重寫一遍。而開源項目的需求和實現往往是經過很多的討論得到的，雖然初始的時候進展和企業內部的軟件相比很難相比，但是長期來說，往往可以一步一步的超過企業內部實現的質量。從這個方面而言，多參與開源的工程師溝通能力、設計能力往往會更強一些。

其次團隊管理者應該盡量的把工程師的個人方向和團隊的方向給結合在一起: 以大數據領域為例子，一個公司如果對Apache Hadoop、Apache Spark等等項目用得比較多，那么很容易發現一些不滿足需求的地方。如果能夠把這些需求提回社區能夠幫助讓社區更好的考慮未來的方向。大部分的開源社區還是非常希望來自其他公司的貢獻者能夠參與進來，幫助一起把社區建設好。

那么如果有工程師對與工作內容不直接相關的開源項目感興趣怎么辦呢？比如說一個非機器學習團隊的工程師對Tensorflow感興趣，從我的經驗來說，給這些工程師一部分的時間和自由度讓他們去參與是非常有好處的，就算是日常工作內容比較忙，也不要阻止工程師去參與自己感興趣的項目。原因是，第一你不知道什么時候這些知識儲備會有作用，我經歷過的好一些重要的項目都是從20%時間來的。第二如果打擊了工程師的積極性，對長期的個人發展和團隊管理都不利，也不容易建立起一個有黑客精神的團隊。我通常的做法是，除非是產品發布等等非常忙的時間，我會鼓勵工程師可以用20%的工作時間來做感興趣的項目。堅持幾年下來會發現團隊積累了很多的知識來去處理更復雜的問題和需求。

2.2 從公司的角度出發

說完了個人，這里再說說公司。團隊管理人作為連接公司和個人需求的橋梁，也需要認真考慮一下開源對于公司的目的和意義是什么，需要怎樣做才能更好的得到公司的支持。

2.2.1 公司參與開源的目的是什么

首先談一談公司參與開源項目的目的是什么，這里分為兩種開源項目：企業用來賣錢的項目；企業內部使用的項目。

2.2.1.1 企業用來賣錢的項目：
現在越來越多的企業把核心開源，然后在周邊通過部署、監控、分析的軟件；或者技術支持服務；或者云上的服務來實現盈利。

對于Cloudera、 Elastic、 Confluent、Databricks這類公司而言，理想狀態下，開源核心軟件的目的可以更好的接觸到客戶，當客戶使用之后發現問題，對于大部分沒有非常強大的開發團隊的客戶而言，他們會有很強的動力來購買云服務、收費軟件或者是技術支持。這個當然是從理想狀態上來說的，如果說公司提供的收費軟件如果并不好用，或者是公司提供的免費開源軟件沒有流行開來，開源的意義就變得相對不大了。在這個話題上，我后面會稍微展開一下哪些項目適合開源、哪些項目不適合開源的討論。

2.2.1.2 企業內部使用的項目：
每個企業或多或少地使用開源項目。那么參與這些開源項目有下面的意義:

• 提升工程師的水平和積極性：這里在工程師角度的一節中已經提到過，這里就不重復說了。
• 建立更好的公司工程品牌：對于軟件、互聯網公司而言，招聘到好的人才是非常難的事情。深度參與開源的團隊，或者是主導了某些重要的開源軟件可以建立更好的公司的工程品牌。因為參與開源往往意味著公司開放包容的文化和黑客精神，這些也是優秀的工程師所喜歡的。
• 同步開源社區的進展：做開源這些年接觸到了很多公司在線上部署了一個開源版本之后就不再主動的升級，而是根據自己的需求在上面進行數以千計的改動。造成本地和上游的版本區別太大，幾年之內因為核心工程師離職、或者是有大的改進已經在現有的版本上無法再改，不得不推翻重來。如果說公司更多的和開源社區同步，可以讓長期的維護成本降低。下面的 “如何管理本地和上游版本”的章節會詳細的討論一些常見的策略。
• 得到開源社區的幫助：參與開源雖然說由于開源社區的代碼審核、設計討論等等問題上會花費比自己開發更多的時間，但是當建立好了與開源社區的關系之后，可以得到很多別人的幫助。最后可以達到自己投入N個工程師做某一個項目，然后得到K（可以小于N可以大于N）來自社區的工程師的幫助，比公司完全自己投入來講可以節省部分的資源。

2.2.2 哪些東西合適開源、哪些東西不合適開源

了解到了公司參與開源的目的和好處之后，這里再談談哪些適合開源、哪些不適合開源。

2.2.2.1 哪些不適合開源
非通用性的項目

首先開源的軟件需要有通用性，比如說只能夠跑在公司內部比較獨特的環境中的軟件，或者是很少有別的公司有類似的需求。對于這樣的軟件來說，開源不容易造成廣泛的影響，公司投入開源的時間和資源（比如說為了開源而做的文檔，需要做一些代碼清理等等）未必能得到足夠的回報。

跟競爭對手拉開差距的部分

其次對于公司用來賣錢的軟件來說，對于與競爭產品拉開差距的功能部分（Differentiator），最好謹慎開源。因為開源之后競爭對手也可以免費的拿到這部分功能的實現。在這方面的開源，最好參考一下最近MongoDB、Confluent（參考 Confluent 官宣）等等公司對軟件許可證的修改以防止競爭對手（比如說云廠商）插管吸血。

不必要的重復造輪子

如果已經有一個好的的開源項目實現，背后有一個健康的開源社區的前提下，謹慎造輪子。比如說公司想要一個需求相對獨特的分布式文件系統，在已經有HDFS、Ceph等等大的開源項目的前提下，開源的意義就變得很小，因為如果要和成熟的開源社區競爭是一個很難的過程。因為至少你要投入類似或者更多的資源來建設這個開源社區。

2.2.2.2 哪些適合開源
通用的模塊、項目

跟上面提到的原因類似，如果說一個項目或者模塊比較通用，比如說某種通用數據結構的Go實現，或者是在公有云上能夠方便部署的圖數據庫。開源這種項目往往可以很快的吸引用戶。

競爭性的開源

如果行業老二想把老大拉下馬的話，開源和免費老大賴以生存的技術是常見的策略。比如說Google開源Android以對抗蘋果。新的數據庫公司以開源來對抗老的數據庫公司等等。

參與一個良好生態的開源社區

跟重復造輪子相比，參與一個有著良好生態的開源社區可能是對公司長期來說更有好處的事情。

3 細節討論

3.1 如果更好幫助團隊的和開源社區溝通

開源社區的溝通和公司內部的跨團隊溝通區別其實區別很大。首先公司內部的溝通常常是自上而下的：公司有一個大的目標，然后分下來到每個團隊，大家扯皮劃清工作界限、制定計劃。然后再由技術負責人、工程師來做執行。溝通的前提往往是公司或者團隊的利益所驅動的。而且除了外企有跨國界的合作以外，溝通都是在本地或者國內，鮮有語言的問題。從項目設計、代碼設計來說，常常就是走兩個極端：部分公司基本上口頭能夠解釋清楚的就未必需要寫下來。還有一些公司內部有非常嚴格的文檔、溝通上的規范。

而開源社區的溝通需要更多的自下而上：參與開源社區的工程師當然會帶著一些公司的目標去，但是更多的想法應該是由個人驅動。在怎樣參與開源社區的過程中也會帶著一些個人的印記。

在我看來，開源的溝通有下面的挑戰和解決辦法：

1） 分布式異步：開源團隊往往遍布世界各地，跨洲、跨時區是常見的時區。對于一些社區的合作，可能同時有來自歐洲、亞洲、美洲的參與者。來自中國的工程師可能早上對某個討論發出了評論，到晚上十一二點才收到來自美國的工程師的回復。如果某個公司重點的項目卡在了溝通上，會很讓人著急的。

解決辦法：

• 主動一點：有些人喜歡早上起來第一件事就是回復別人的評論，有些人喜歡下班的時候再把前一天的評論都回復掉。由于開源社區松散，來自別的公司的參與者未必會把你的一些疑問和PR放在最高優先級上。在這一點上需要每個參與者更加主動一點去發起討論，也可以禮貌地催一下社區別的參與者看一下你的回復。
• 團隊線下溝通：開源社區很喜歡知名的、大的公司來使用自己發布的軟件并且做出反饋，尤其是比較新的，需要“踩坑” 的新功能、新版本。如果你的團隊準備投入一定的資源來上新的版本或者功能，不妨可以問問社區相關領域的負責人可否定期不定期地進行線下溝通，來解決一些疑問，并且討論一些功能的需求等等。從我的經驗上來說，這樣的溝通方式其實非常的有效。而且也能夠更好的建立線下的人脈。

2） 文檔、注釋：由于分布式異步的溝通方式，最好能夠鼓勵團隊把文檔和注釋盡量寫得清楚一點。不然在溝通之中會來來回回的確認你想要表達的內容。多搞幾次之后雙方都容易失去耐心。

3.2 如何把對的人放在對的地方去

因為開源的參與會落實到每一個參與者，不是說每個人都適合做每一樣事情。我下面會略談一下怎樣把不同的工程師放在開源社區的不同的角色之中以更好的讓每個人發揮自己的長處。

我主要把工程師分為了下面四類，并且談談每一類的特點、適合做的事情和需要來自團隊怎樣的幫助。

類型特點適合做的事情需要怎樣的幫助

技術好，愛溝通 (A)	這一類的工程師不管在開源里還是開源外都是項目最重要的部分。	有潛力主導社區的方向，可以參與社區重要功能的開發，討論。可以幫助團隊里面別的同學參與開源。	來自團隊的支持、信任。
技術好，不愛溝通 (B)	這一類工程師是: 如果有一些功能需要很多的討論，未必很合適做。但是如果當技術需求清晰之后，他們可以很好的完成任務。	在技術需求討論清晰后，進行比較深的、比較復雜的功能開發。	多鼓勵進行溝通，以成為A型；否則的話應該幫助這類工程師進行溝通，明確需求和目標，以便工程師更好的完成功能。
愛溝通大于技術 ?	這一類的工程師未必是技術不好，而是相對技術而言，更希望與人溝通。從技術上的特征來說往往是廣度大于深度。	能夠幫助解決一些繁瑣的（當然也是重要的）功能。 通過寫博客、設計新的例子、tutorial，等等。幫助社區的宣傳。(類似于布道師的角色)	其實這一類的工程師對于社區來講至關重要。一個又說又做的社區比只做不說的社區要好的太多。如果讓A型工程師來做C的事情往往結果不好。 所以從團隊的角度來說，應該多鼓勵這一類的工程師來幫助社區。對于新的社區而言，有專職的布道師是一個很好的選擇。
技術溝通都不好 (D)	他們未必就是不喜歡技術或者溝通，只是從技能儲備來說不夠。	可以幫助一些繁瑣的任務和功能。	他們需要團隊很多的幫助。 這幾年下來接觸過一些原本技術溝通都不太好的工程師。在幫助下他們有些能成為B、有些能成為C。

3.3 如何管理本地和上游分支

這個是基于開源的項目開發最常見的問題，開源軟件不同于傳統軟件，開源社區的發展方向未必是團隊希望的方向。那么如何管理本地（公司內部的）分支和上游（開源社區擁有的）分支呢？這里說的開源項目是基于社區的開源項目（由多個公司共同主導的項目），如果是開源項目完全被自己的公司所主導的話，工作的方式其實和內部的項目差不多的。（也適用于3.4）

其實簡單說來，大概就是兩種方式：

1） 第一種方式，開發的代碼全部進入上游分支

一般這種方式需要對團隊對開源社區有一定的控制權， 因為需要將代碼合并進上游分支需要得到相應模塊負責人的審核、反饋和提交。如果對社區控制權相對比較弱的話，這種方式會造成時間拖得太長。這樣做的好處是，本地的代碼和上游的代碼是非常類似的。不太會出現同一個功能，社區版本和本地版本不一致的情況。

如果是對于比較大的功能或者是需要若干個commit的改進，建議在上游社區建立一個單獨的分支，把新的改進都合并到上游的分支中，等到功能開發、測試完成之后，再合并入上游的主干分支和發布分支。

2）第二種方式，開發的代碼先進入本地分支

相對于1），這種方式其實是不得已而為之，不過在很多時候公司需要的功能必須在某個時間之前上線，如果社區討論的時間太久、或者代碼審核的意見太多，或者社區根本就不同意提出的方案，那么這種情況下代碼會進入本地分支。

如果這種情況發生了，建議在工作任務相對不那么忙的時候，把對應的功能還是推進到上游分支中，不然時間長了之后，本地的代碼實現跟上游的代碼完全不一樣，這樣會導致內部的版本會很難升級到社區新的發布中去。

3.4 如何管理本地和上游的版本

說完了本地和上游的分支，這里說說怎么管理 本地的版本和上游的版本。

首先這里舉一個最常見的一種管理方式：

上面藍色的圖標是上游（社區）版本的發布，每個版本的發布包括了若干的改進。綠色的圖標是內部的版本，初始的時候內部1.0’版本和社區的1.0版是一樣的。

由于上游社區的開發進度太快，在1.1里面加入了很多激動人心的新功能，但是潛在會帶來代碼的不穩定性。因為內部的版本需要在公司內部里面做完測試，上線等等流程才能上線，所以內部的版本的迭代會相對保守，所以內部的下一個發布可能不是直接緊跟社區版的1.1作為基礎，而是從社區1.1版本里面選擇一些重要并且相對安全的改進放入內部開發分支，作為內部1.0.1版本的一部分。

同樣等到社區1.2版本發布之后，內部可以把對應的一些改進放入內部1.0.2版本的發布中去。

那么這樣長期做也不是辦法，所以需要不定期的把內部的版本和社區的版本做一些同步，等到社區發布了1.3版本之后，因為功能被別的社區公司在不同的場景下進行了驗證，所以公司內部也可以將內部的版本重置到1.3版本中去，并且加以驗證、將改進回饋到社區。這樣的過程一般來說比較痛苦，但是從長遠來看對公司和社區是雙贏的一個選擇。

3.5 如何管理分布式的團隊

說一下分布式團隊管理的挑戰和解決方法。

挑戰主要是在時區和有效溝通上面，我們這邊的做法（不同的daily sync up time，每周的planning），和定期的project sync up。另外就是對工程師的要求，從招聘的時候就放在重要的位置的。

因為社區的開發者本來就分散在不同的公司、國家之中，在開源社區中發生人才流動的時候，很有可能選擇去別的公司做之前的開源項目。不夸張的說，我見過的絕大部分基于開源的團隊都是非常分散的，這個給團隊的管理帶來了很大的挑戰。我們團隊近20個同學分散在
7個不同的時區（歐洲、印度、中國、澳大利亞、美國西部、中部、東部），我們這個超分散的團隊還能夠一起很好的工作、推進公司和開源社區項目的發展，我想分享一下自己的一些經驗：

1）從招聘開始

第一步也是最重要的一步是選擇對開源有濃厚興趣的人，如果人對自己的工作有興趣和激情，相應的抱怨也會少很多。從性格上來說，比較開朗（不一定是在口頭交流中的）、性格比較開放的工程師比較適合開源跨時區、異步的溝通方式。

2）同步會議

對于像我們這樣的分布式團隊，沒有辦法找到一個時間是所有人都醒著的。這樣對于團隊的溝通和狀態同步造成了很多的挑戰。

我的解決辦法是將項目需要合作的模塊分配給時區比較接近的同學以盡量避免太晚或者太早影響生活。取消每天大家都參加的狀態同步會議、取而代之的是每周每個模塊1-2次的開發同步會議。因為一般的工程師都不太會同時工作超過3個模塊，所以從同步會議造成的時間開銷來講應該還是在可控的范圍之內的。

3）開源社區的工作方式

從工作方式來說，我也盡量的鼓勵大家跟開源社區的工作方式一致。以代碼審核為例，開源社區一般是需要審核者 (Reviewer/Committer) 把意見評論到對應的JIRA或者PR中，在合并代碼前會至少等幾個小時到幾天看看有沒有別人的意見。我們內部的工作方式也是類似的。如果是對組內同事的代碼、設計有建議的話，線下的會議或者在線會議是可以的，但是最終的建議需要總結下來并且放到對應的JIRA或者PR中去，這樣可以讓團隊、社區里面的其他人知道最新的狀態。這樣做雖然比面對面討論、當成提交代碼略慢，但是從代碼質量的角度來說，這樣的結果可以更好的保證代碼質量，從長期來看是值得的。

當分布式的團隊適應了這種開源社區的工作方式之后，我甚至發現很多時候就算完全沒有面對面的交流（包括在線會議），大家也能夠很好的一起合作。

4. 總結

本文講了一下關于基于開源軟件的團隊的管理的經驗。雖然說開源社區的合作方式跟大家熟知的團隊內部或者跨團隊的方式有諸多不同，不過當摸清楚了開源社區的溝通習慣之后，其實管理一個基于開源技術團隊也沒有非常多特別的東西。簡單來說就是尊重個人，尊重社區還有和把團隊的目標和公司的目標匹配在一起就是了。希望本文分享的經驗能夠對讀者有幫助。

作者介紹：

譚望達，Cloudera計算平臺研發負責人，高級經理，管理Kubernetes、Hadoop YARN、深度學習平臺相關的全球研發團隊。在開源領域，是Apache Hadoop committer以及項目管理委員會委員，Hadoop社區負責人之一。主導了GPU調度和隔離、資源搶占、全局調度器等等功能的設計和開發。創立了Submarine項目（在Kubernetes、YARN上運行深度學習任務），并將Submarine推進成為Hadoop的頂級項目。在加入Cloudera之前，曾在Pivotal (EMC) Hadoop團隊，負責在Hadoop之上的高性能計算（HPC)、機器學習相關的產品研發。在此之前，曾在阿里云算法平臺參與分布式機器學習平臺的研發。

總結

以上是生活随笔為你收集整理的开源是项“全民工程”，揭秘开源团队的管理运作的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。