工程师如何对待开源——一个老工程师的肺腑之言
|作者：譚中意
|編輯：李佳陽
|設計：蘇子馨
|責編：王玥敏
?工程師如何對待開源?
本文是筆者作為一個在知名科技企業內從事開源相關工作超過 20?年的工程師，親身經歷或者親眼目睹很多工程師對待開源軟件的優秀實踐，也看到了很多 Bad Cases，所以想把自己的一些心得體會寫在這里，供工程師進行參考，希望能幫助工程師更好的成長。
?概述?
作為一個在科技企業內部進行技術工作的工程師，工作任務就是用技術手段支持和實現公司所關注的商業目標。?實際工作過程中，需要主動或者被動的使用和維護大量的開源軟件。?據統計，每個工程師在企業內部進行研發和運維等工作的時候，每年會接觸到上千款開源軟件，?如果是以 Java 或 JavaSciprt 為主要程序開發語言的工程師，則接觸到的開源軟件數量更多，在萬級別甚至十萬級別。?（數據來源：《2020 State of the Software Supply Chain》由 Sonatype 發布）
那么如何選擇開源軟件？?這么多開源軟件中，如何根據個人需求和業務需要來選擇合適的開源項目來進行投入，是需要綜合考慮的。
選擇了開源軟件之后又如何進行定制和長期維護？?這也是一個很大的問題。因為在企業內部開發軟件，跟個人開發軟件不一樣的是，維護一個計算機軟件系統的成本遠遠大于開發該系統或軟件的成本。選擇開源軟件之后，如何從長期的視角進行定制和修改，后續的長期維護如何進行，才能做到高效和節省成本，業內有很多很好的經驗，也有不少不太成功的案例成為教訓。
最后回到個人，工程師的成長是在不斷的學習和實踐中進行的。如何來利用開源來提升自己能力，擴大自己的眼界，提高自己技術口碑和業內影響力，對于工程師本人也是非常重要的。
本文將從如下三個部分來分別闡述：
1
工程師如何選擇開源軟件
2
工程師如何定制和維護開源軟件
3
工程師個人成長如何利用開源
?1.如何選擇開源軟件?
首先要明確對開源軟件的態度，在現階段是不可能離開對開源軟件的使用的。?使用開源軟件有各種各樣的風險，包括開源合規、安全、效率的問題。?簡化為一句：在企業內部使用開源軟件，需要遵守該企業對開源軟件的內部規定，包括如何引入和如何維護，以便達到高效、安全、合規的使用。
回到具體如何選擇特定的開源軟件的問題上，有如下幾個緯度可以進行參考：
● 根據需求
● 根據技術發展趨勢
● 根據軟件采納周期的不同階段
● 根據開源軟件的成熟度情況
● 根據項目的質量指標
● 根據項目的治理模式
?1.1根據需求來選擇開源軟件?
選擇開源軟件，首先要明確需求，即選擇這個開源軟件的目的究竟是什么。?工程師選擇一個開源軟件，究竟是它用來做什么的，是用來進行個人學習的；?還是用來滿足 ToB 客戶的需求的；還是用來滿足內部服務開發的需求的。?這三個不同的目的下，選擇開源軟件的導向完全不一樣。?（注意：后兩個場景是需要先考慮企業開源合規的需求的，參見第三章）
先說說選擇開源軟件來進行個人學習，那么需要看看個人學習的具體目的究竟是什么。?是想學習一種比較流行的技術來完善個人的技術知識結構擴大個人技術視野；還是想看看相應的開源技術項目的具體實現，來作為內部項目技術開發的參考；還是想為了下一份工作進行有針對性的技術準備。不同的目的會導致不同的選擇。針對前者，顯然是什么技術最流行選什么，自己缺什么選什么；針對第二種目的，一般是對該技術領域的知名開源軟件或者創新性軟件進行有針對性的選擇，即某個特性是我當前需要的，或者是我當前項目實現不好的，我需要看看別人是如何實現的。最后一種，顯然是按照下一份工作的職位需要和技術棧要求進行準備，并根據技術棧要求的門檻高低進行選擇。但是注意，從個人需求出發選擇開源軟件，一般都需要寫個小項目練練手，比如一個 Demo 程序或者一個測試服務，因為不用考慮后續的長期維護，所以盡可以按照個人的想法和個人研發習慣進行各種練習，不用遵循企業內部的開發流程和質量要求，也不用考慮該開源軟件的穩定性和社區成熟度等情況，只需要盡情的學習和參考代碼就好了。
然后看下一個需求，選擇開源軟件進行研發的軟件是需要提供給客戶的，往往可能還是以私有云的方式進行交付。基于此類需求來選擇開源軟件，注意做好平衡，即客戶的需求和企業自身技術規劃或產品的長期規劃需要。以私有云方式進入客戶的 IDC 環境，是需要跟客戶開發和運行環境的上下游項目進行集成的。這時候要看客戶的需要，可能某些客戶對開源軟件有特定的要求，例如要求使用 HDFS 而且是某個特定版本。對這類指定軟件名字和指定版本的要求，有可能是因為客戶當前比較熟悉這個版本，也有可能是因為之前其他軟硬件供應商提供的軟件和版本，指定的目的是方便集成和后續的使用與維護。如果這種需求是符合企業項目或者產品的長期發展需求的，則是可以完全滿足的。如果甲方非常強勢，除了滿足他的要求之外沒有別的辦法，那就選擇客戶所指定的軟件和版本好了。但是如果跟自身項目或產品的長期發展需求不一致，而且具體項目或者版本是可以跟甲方進行協商的，那么需要跟客戶協商出一個雙方都能接受的結果出來，即選擇特定的開源軟件和版本既要做到客戶滿意并買單，又要做到自身的交付成本可控，還要做到符合自身項目或者產品的長期發展需要。
例如客戶使用 Java 的某個老版本，但是企業的 toB 交付的軟件要求使用 Java 的較高版本。那么需要跟客戶協商，要么切換到企業希望的版本上，還需要幫助客戶完成已有系統的升級工作；要么只能降低自身軟件的 Java 版本需求，可能還需要對某些自身代碼進行修改，還可能對軟件中的某些依賴組件進行修改。這個場景下是帶有很多客觀約束條件下的選擇，是需要跟客戶，自身的產品經理和架構師一起協商的。
最后，如果場景是為了滿足內部服務的需求，即選擇開源軟件來搭建的服務是給內部業務或者最終用戶來使用的，常見于國內各大互聯網公司的互聯網服務系統和各種手機上的 App。這時候項目的開發和維護方有較大的自主權，跟 toB 的交付業務完全不一樣。此時選擇開源軟件，就一定要綜合考慮開發和維護成本，還要考慮使用該服務的業務所處的階段。
（1）如果提供的服務是給創新業務使用的，創新業務一般都是試錯業務，隨時需要根據市場情況的變化和當前執行的狀態進行調整，很可能三個月后這個項目沒了，即被取消了。這種情況下?“糙快猛”?的開發方式是比較合適的，不用太多考慮系統的可維護性和可擴展性，就用研發團隊最熟悉的軟件技術棧，然后用底層技術支撐團隊比如基礎架構團隊提供的成熟而且經過驗證后的底層基礎技術平臺就可以，最重要是盡快把系統搭建出來，然后隨著產品進行快速的迭代。這個時候需要盡量降低現有研發運維團隊的學習成本和開發成本，不用太多考慮可維護成本，因為需要糙快猛的把系統堆出來，驗證產品需求和商業模式是最重要的，時間最重要。如果發現有市場機會，就快速跟進，站穩腳跟之后可以采用省時間但是費資源的方式（俗稱?“堆機器”）來進行擴展，或者采用?“邊開飛機邊換引擎”?的模式進行重寫都是比較劃算的。對于處于創業階段的企業或者項目來說，速度勝過一切。
（2）但是如果選擇開源軟件搭建出來的計算機軟件系統或者服務，是需要長期維護的，比如是給公司內成熟業務使用的，或者是針對公司內成熟平臺的缺點進行系統升級并要替代原有產品的，那么在滿足業務需求的前提下，考慮系統的可維護性變成最重要的事情。選擇對應的開源軟件，它是否成熟，是否穩定；二次開發是否友好；運維成本是否比較合算即比較省機器和帶寬；運維操作是否方便，例如常見的擴容和縮容操作是否可以高效、自動、無損地完成；Upstream 到上游開源社區是否容易等等，這些都成為需要重點考慮的事情。這種情況下，開發一個系統的成本，可能只占整個系統生命周期內的成本的 1/10?不到。所以在滿足需求的前提下，重點考慮可維護性。
?1.2根據技術發展趨勢來選擇開源軟件?
如上圖所示，現代計算機軟件或者服務的研發，是一個不斷運行的循環和迭代過程。從市場分析開始，然后進入到創意階段，再到編碼階段，最后到上線階段完成應用的部署和生效，上線之后根據得到的數據反饋，繼續進行分析。這個循環迭代的過程，顯然對于一個身處競爭激烈的行業的企業來說，迭代的速度越快越好，同時也需要具備快速彈性、低成本伸縮的能力，即產品方向對了，那么趕緊進行系統擴容，承接快速增長的流量，做到快速增長；如果產品方向不對，需要趕緊縮容，把相關硬件和人力資源節省出來，投入到新的試錯方向上去。身處同一個行業內的企業，如果企業 A 能以更低的成本，更快的速度地進行各種產品和策略的迭代，顯然它是能比迭代速度慢，成本高的企業 B 是有更好的競爭優勢的。
現在的開源軟件數量非常多，幾乎每一個分類下面都有很多的開源項目。針對某一個具體的需求，如何進行選擇？一個建議是根據技術趨勢進行選擇。即現在的計算機系統迭代的方式是 Agile（敏捷）?+ Scale（擴展）。顯然，能夠支持計算機系統進行快速迭代，并能夠很方便進行低成本彈性伸縮的開源軟件是值得進行長期投入的。而對一個新的開源軟件的學習和使用，學習者是希望該軟件的學習門檻越低越好。一個流行的開源軟件，內部實現可以盡可能的復雜，但是對于用戶來說一定是需要用戶友好的。不然即使創新度再好，易用性不好，只有極客才能學習和掌握，創新的鴻溝是很難跨越的。
例如 Docker 的出現之后，以極快的速度風靡全球，非常多的工程師喜歡上了 Docker。就是因為 Docker 的特性，在傳統的容器系統之上增加了新特性，包括把應用程序和底層依賴庫封裝為一個容器鏡像，容器鏡像有版本，而且可以通過集中的鏡像倉庫進行存儲和大批量分發。Docker 首先解決了長期困擾工程師的開發、測試、上線環境標準化的問題，能夠支持開發者進行快速的迭代。同時使用了統一的鏡像倉庫來進行鏡像的分發，而且底層采用了輕量級虛擬機即容器的技術，可以非常快的被拉起，所以采用 Docker 的系統可以很方便的進行彈性擴展。同時，因為把應用 App 封裝在一個鏡像里面，可以在邏輯上根據 Domain Model 的設計原則進行更好的抽象和復用。顯然，這樣的技術是值得每一個開發計算機系統的工程師學習和掌握的。因為他能帶來極大的方便。相反，在 Docker 產生之前，雖然 Control Group（簡稱 cgroup）?+ Namespace 的技術早就已經出現，并早就集成在 Linux 內核中，Google 的 borg 相關的論文早就已經發表，但是一般的技術研發團隊不是很容易就能駕馭容器并把容器系統在公司內部大規模進行部署的。印象中 borg 論文出現后，國內只有 BAT 級別的互聯網公司，才有一小撮精英研發團隊來研發和使用容器管理系統，例如百度負責 Matrix 系統研發的團隊，阿里負責 Pounch 系統研發的團隊，騰訊也有一個小團隊負責容器系統的研究。但是除了那一小部分團隊，更多的工程師因為相對較難的學習難度而沒有把容器大批的用起來。而 Docker 這種技術，就是非常好的順應了敏捷和彈性擴展的技術趨勢，而且提供了非常好的用戶易用性，然后一出場就被非常多的工程師迅速使用上了，而且成為市場的默認標準。
這些順應潮流的開源軟件是值得選擇和投入的。
另外一個例子是 Spark，Spark 的出現解決了 MapReduce 在分布式計算過程中因為需要頻繁進行 IO 操作導致的性能比較低下的問題，同時在易用性上有較大的提升，所以才取代了 MapReduce 在分布式計算領域內的主流地位。
?1.3根據開源軟件采納周期的不同階段進行選擇?
軟件作為智力活動的產物，他有他的生命周期，一般用軟件的技術采納曲線表示。
開源軟件也是軟件的一種，也都是遵循軟件的技術采納規律的。如下圖所示：
一個開源軟件從創建到衰亡一般會經過 5 個階段。?從創新期（Innovators，占比 2.5%），到早期采納期（Early Adopters，占比 13.5%），然后跨越鴻溝（chasm），進入到早期大眾期（Early Majority，占比 34%），再進入后期大眾期（Late Majority，占比 34%），最后進入衰退期（Laggards，占比 16%）。絕大部分的開源創新項目，沒有能成功的跨域鴻溝，即從早期采納階段進入到早期大眾階段，就消亡掉了。?所以，如果是選擇一個需要長期使用并維護的開源項目，選擇處于早期大眾或者后期大眾狀態的項目是比較理智和科學的。
當然如果只是個人想學習一個新的東西，可以看看處于創新者狀態的開源項目，或者看看處于?“早期采納者”?狀態的項目。
注意不管是從長期研發系統的角度，還是從個人學習的角度，都不要再去看處于衰退期（Laggards）的項目了。?例如現階段即 2022 年，是不用再去選擇 Mesos，Docker Swarm 之類的項目了。自從 Kubernetes 成為容器調度技術分類的默認標準，這兩個項目就已經處于衰退期，他們的母公司都已經放棄了。這個階段如果還投入較多精力來開發和維護，除非真的是非常強勢的甲方要求，把錢砸在工程師面前逼的不得不用才會選擇。
同學們可能會問，從哪里可以看到這些技術采納度曲線？
InfoQ，gartner，thoughtworks 每年都會更新他們各自的技術采納度曲線并公布出來，?大家可以在網上搜索一下，看看他們各自的技術采納圖是什么，然后結合一些業內的經驗，得出自己的判斷。
例如：? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
https://con.infoq.cn/conference/technology-selection?tab=bigdata
從這里能看到 2022 年 InfoQ 對 BigData 領域各種流行技術的判斷。?
從上圖可以看出，Hudi、Clickhouse、Delta Lake 等開源軟件還處于創新者的階段，即在工業界采納還比較少，對于想學習新項目的同學是可以重點關注的。但是現在這些開源軟件還不適合應用在需要長期維護的成熟應用場景里面。
注意這些知名科技媒體的技術采納曲線是每年都在更新的，在進行參考的時候別忘了注意一下發表的時間。
?1.4根據開源軟件的成熟度情況選擇開源軟件?
還有一點，即根據開源軟件本身的成熟度來選擇開源。?即從這個開源軟件是否定期發布，是否處于一個多方維護的狀態（即使一個公司的戰略發生了變化不再繼續維護了，還有其他的公司在長期支持），是否文檔比較齊全等多個維度來進行成熟度的評估。
對于開源軟件的成熟度模型，開源社區有很多度量開源項目的成熟度模型，其中 Apache 開源軟件基金會的項目成熟度模型是比較有名的。
可以參考這里：? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
https://community.apache.org/apache-way/apache-project-maturity-model.html
按照這個 Apache 開源軟件基金會制定的開源項目成熟度模型，他把一個開源項目的評估緯度，分為 7 個維度：
● Code（代碼）
● License and Copyright（軟件許可證和版權）
● Release（發布）
● Quality（質量）
●?Community（社區）
● Consensus Building（共識共建）
● Independence（獨立性）
每個緯度又有幾個考察項。
例如針對 Independence（獨立性），又有兩個考察項，其一是看這個項目是否獨立于任何公司或者組織的影響，其二是看貢獻者在社區內活動是代表他們個人，還是作為公司或者組織的代表出現在社區并進行活動的。
Apache 基金會 Top Level 的項目即頂級項目，在畢業階段都會從這些維度進行綜合的判斷。只有各方面都達標的項目，才會被允許從 Apache 基金會的孵化狀態中畢業而成為成為 Top Level 的項目。這也是逼著個人比較喜歡 Apache 頂級項目的原因。
另外，OpenSSF 項目的 Criticality 評分(參見：https://github.com/ossf/criticality_score)也是一個不錯的參考指標，它會度量一個項目的社區貢獻者數量、提交頻度、發版頻度、被依賴的數量等指標，來判斷一個開源軟件在開源生態中的重要程度。這里就不詳細展開了，有興趣的同學可以參考它的資料，個人認為是一個值得參考的方向，但是這個評分還處于早期階段，距離理想狀態還比較遠。
?1.5根據項目的質量指標來進行選擇?
很明顯，有些開源軟件的代碼質量是比其他開源軟件的質量好。?有的時候需要從項目的質量情況來選擇開源軟件。這個時候，我們需要查看一些被業內廣泛證明比較有效的指標。
其中 MTTU 是被知名開源供應鏈軟件供應商 SonaType 所推薦的指標。它在它著名的供應鏈年度報告里面提到MTTU。?
參見:
https://www.sonatype.com/resources/state-of-the-software-supply-chain-2021
MTTU（Mean Time to Update）：即開源軟件更新它依賴庫的版本的平均時間。舉個例子來說，某開源軟件 A 依賴于開源庫 B，假設 A 的當前版本是 1.0，依賴 B 的版本是 1.1。某天開源庫 B 的版本從 1.1 升級到了 1.2，然后一段時間之后，開源軟件 A 也發布了新版本 1.1，其中把對 B 的依賴版本從 1.1 升級到了 1.2。這個時間間隔，即從開源版本 B 的版本升級到 1.2 的時間點距離開源軟件 A 的新版本 1.1 的發布時間，稱之為 Time to Update，反映出來的是開源軟件 A 的研發團隊，根據依賴庫的更新周期，同步更新它的依賴版本的能力。Mean Time to Update 是指這個軟件的平均升級時間。數值越低表明質量越好，表明該軟件的負責人在很快速的升級各種依賴庫的版本，在及時修復各種依賴庫引起的安全漏洞問題。
據 SonaType 的統計，業內開源軟件的更新升級時間 MTTU 越來越短。?據它的統計，在 Maven 中心倉庫上的 Java 類開源軟件，2011 年平均的 MTTU 為 371 天，2014 年平均的MTTU為302 天，2018 年平均的 MTTU 是 158 天，而 2021年平均的MTTU 時間是 28 天。能看出來，隨著開源軟件庫更新頻率的加快，使用它們的軟件也隨著加快了更新版本的速度，MTTU 相對 10?年前，時間縮短到原來的 10/1 以下。
當然 MTTU 只有項目質量的一個間接緯度。?歷史上是否爆出重要高危安全漏洞，修復響應是否快速及時，等等也是作為開源項目質量評價的重要維度。
某些大廠的安全部門，會不斷評估開源軟件的安全情況，把某些屢屢發生高危安全漏洞，但是修復不及時的開源軟件設定為不安全軟件，列入到內部的開源軟件黑名單中對內公示，并要求各個業務研發團隊不再使用這些軟件，實在因為研發和人力問題不能遷移到新的軟件系統的情況也需要把這些老服務遷移到一個相對封閉的網絡環境中，減少風險可能造成的損失。這個時候，顯然應該需要遵守公司的安全規定，不再使用黑名單上的開源軟件。
1.6從開源軟件所屬于的開源社區治理模式角度來考慮
還有一個維度，即從這個開源項目的社區治理模式來考慮，適用于需要長期進行開發和維護的項目。
社區治理模式（Governance Model）主要是指該項目或者社區是如何做決定的以及由誰來做決定。?具體表現為：?是所有人都可以做貢獻嗎還是少數幾個？?決定是通過投票的方式產生的，還是通過權威？計劃和討論是否可見？
常見的開源社區和開源項目的治理模式有如下三種：
● 單一公司主導：特點是軟件的設計、開發和發布都由一個公司來控制，也不接受外部貢獻。開發計劃和版本計劃不對外公開，相關討論也不對外公開，版本發布時候才對外公開源碼。例如 Google 的 Android 系統。
● 獨裁者主導（有個專有名詞?“Benevolent Dictatorship”，翻譯為?“仁慈的獨裁者”）：特點是由一個人來控制項目的發展，他有強大的影響力和領導力，一般都是該項目的創始人。例如 Linux Kernel 由 Linus Torvalds 來負責，Python 之前由 Guido Van Rossum 來主導。
● 董事會主導：特點是有一撥人構成項目的董事會來決定項目的重大事項。例如 Apache 軟件基金會的項目由該項目的 PMC 決定，CNCF 的基金會的決策是 CNCF 董事會來負責（很多技術決定授權給了 CNCF 董事會下的技術監督委員會）。
個人意見和經驗，根據該開源軟件背后的開源社區的治理方式來進行選擇優先級的排序如下：
● 優先選擇?Apache?畢業項目（因為這些項目的知識產權情況清晰，而且至少有三方在長期維護）
● 次優選擇?Linux?基金會等其他開源基金會的重點項目（因為?Linux?基金會的運營能力很強，每個重點項目后面往往都有一個或者多個大公司在支持）
● 小心選擇一個公司主導的開源項目（因為該企業的開源戰略隨時可能會調整，很有可能不再持續支持該項目，例如?Facebook?就是一個棄坑很多的公司）
● 盡量不選擇個人開源的項目（個人開源更加隨意，風險尤其高，但是不排除某些已經有很高知名度，并且跑出長期維護模式的項目，例如知名開源作者尤雨溪（Evan You）所負責的 Vue.js 開源軟件）。
這是個人推薦的選擇同類開源軟件項目的優先級順序，僅僅代表個人觀點，歡迎討論。
?2.如何定制和維護?
把一個開源軟件引入到企業內部后并用來進行開發和長期維護，就出現了如何定制和維護的問題了。?首先要明確，開源軟件引入到企業內部之后是需要定制的。?因為如下幾個理由：
1、開源軟件往往都是適用于通用場景，考慮的情況比較多，需要支持各種各樣的使用場景。但是引入到企業內部之后，往往只需要針對企業特定的場景。所以針對這些特定場景進行優化，例如對全部功能進行剪裁，去掉跟本場景無關的特性，針對特定場景進行性能調優和參數優化等，往往能取得更好的性能，例如可以抗更多的流量，節省機器成本的效果是驚人的。這也是常見的定制方法。
2、開源軟件進入企業內部要經過開發并長期運營，是需要滿足該企業的各種內部的服務運維規范的。例如業務上線，是需要有完整的日志和監控，比如需要提供服務健康檢查接口，還需要有流量調度等容錯處理。這些都是需要進行定制修改的。
3、開源軟件還需要對接企業內部的上下游系統，例如如果該軟件的正確運行需要依賴底層的分布式存儲和分布式計算系統來完成基本功能，是需要對接企業內部已有的存儲系統或者計算系統的；企業內部的底層虛擬機系統或者容器調度系統，往往有部分修改和優化，對接起來也是需要進行修改的；所以這個時候需要進行定制修改。
4、特殊場景下的需求定制，在企業應用場景下使用該開源軟件往往會遇到特定的問題，可能會碰到 Bug，這些都需要 Bugfix 和新增特性來支持。
?2.1如何對開源軟件進行定制和修改?
對此，筆者建議有幾個基本原則：?不動開源軟件的核心代碼，盡量使用該開源軟件已有的插件機制；或者在外圍改；定期升級到開源社區的穩定版本。
很多開源軟件在設計之初，就留下了不少擴展機制，方便后續開發者進行功能擴展和特性增加。例如幾個最著名的開源軟件 Visual Studio Code，Firefox Browser 就提供了 Extension 機制，很多開發者根據自身需求開發對應的插件，并把插件提交到官方支持的插件市場里面。普通用戶在安裝完成主要程序后，還可以瀏覽插件市場，尋找和選擇自己需要的插件進行安裝。?另外像 Kubernetes，也在多個地方提供了擴展機制，例如核心調度器哪里提供了定制化的 scheduler，可供開發個性化的調度策略；底層的存儲和網絡都提供了很多的插件機制；最值得稱道的是它提供了 CRD（Custom Resource Definition）的機制，允許開發者定義新的資源類型，并復用 Kubernetes 成熟的聲明式 API 和調度機制，進行很方便的操作和運維。?所以，盡量使用該開源項目已有的插件或擴展機制來增加特性。
針對某些開源軟件的修改和定制，并不太適合使用它的擴展機制，或者它本身沒有提供可用的擴展機制。這個時候的修改，盡量在源碼核心的外圍進行修改，而不要去動它的核心代碼。因為開源軟件是隨著開源社區的進展不停的迭代的，開源社區的發展會不斷帶來更多更好的特性。如果對核心代碼進行了修改，而當需要升級到比較新的開源版本的時候，就會非常的痛苦。因為有大量的內部 Patch 需要進行合并，而且需要各種測試，會導致升級成本過高而無法跟社區的主要版本進行同步，最后因為部分核心工程師的離職或者轉崗，那部分的修改沒人能持續維護下去，導致整個系統無法維護和升級，最后導致整個系統被廢棄或者被推倒重來，這會導致大量的人力成本。筆者在多家互聯網大廠工作過很多年，看到了太多這種項目，太多本來針對開源項目的修改，是非常有必要的，但是因為改動了核心代碼，導致想升級到開源社區的較新版本成本太高，最后導致系統無人能維護，只好推倒重來的例子了。
舉個例子吧，筆者在某大廠內部看到有兩個技術團隊在維護 Redis 集群，當時使用的版本都是 Redis 2.x 版本。因為沒有太多集群功能，對大規模的業務支持不好，所以這兩個團隊都對 Redis 的 2.X 版本進行了修改。其中團隊 A 的改法是在外圍改，即在 Redis 之上封裝了一層，用來進行流量調度，Failover 處理等功能；團隊 B 就改的狠一些，直接改 Redis 的核心代碼，把集群功能相關的代碼直接加了進去，甚至在某些局部測試場景下，性能更好一下。短時間內，兩個團隊都能滿足業務線的需求。但是 Redis 開源社區在不停的迭代，不斷加入更多更好的需求，當 Redis 出到 3.x 的時候，兩個團隊都想升級到比較新的版本，因為使用 Redis 的業務方也希望使用 3.x 的版本。但是升級成本明顯不同，團隊 A 很快把相關功能移植到了 3.x 之上，很快把 Redis 版本升級了上去；團隊 B 呢，因為對核心的改動太大，移植成本和測試成本都太高，所以遲遲不能對 2.x 版本的服務進行升級。等到社區 4.x 版本出來，團隊 B 的核心工程師離職之后，該 Redis 集群已經沒有人能夠持續維護并滿足客戶的新版本需求，只好推倒重來，從社區的 4.X 版本直接建集群，自身的系統遷移化了很長時間，也給客戶帶來了很多成本。
所以，對開源軟件源碼的修改，都建議以 Local Patch（本地補丁）的方式存在，一來便于進行維護和升級，二來也方便管理和統計。這種模式下，內部項目的編譯腳本，一般都是把該開源軟件的某個源碼包解開，然后通過 patch 命令把這些 Local Patch 一一打進去，之后再一起進行編譯和測試。而不是把 Patch 直接打到業務源碼里面，雖然在 CI 階段省了幾分鐘，但是后續的維護、升級、管理卻增加了相當的麻煩。
?2.2回饋社會，Upstream（回饋）到上游開源社區，減少維護成本?
工程師在企業內部針對某個開源軟件的某個版本，進行功能特性的增加或者 Bugfix 之后，一般會以 Local Patch（本地補丁）的方式存在在代碼庫中。筆者建議工程師在解決完業務問題之后，盡量把這些 Local Patch 提交到該開源軟件所屬的上游開源社區里面去，完成 Upstream 的過程。
Upstream 有如下幾個好處：
? ? ● 能獲得更好的代碼
在企業內部針對某開源軟件增加特性尤其是 Bugfix 的補丁，往往因為時間緊急，更多采用的是?“Hack”?的方式，即為了快速上線解決問題，補丁修復的地方不一定很合理，代碼補丁的邏輯可能會有漏洞，代碼補丁可能對更多異常條件的處理不夠完善等等。這個時候，如果把這個 Local Patch 提回到該開源項目所屬的開源社區里面，跟該開源社區的資深工程師（Module Reviewer/?模塊負責人）等進行深入的溝通交流之后，往往會根據他們的反饋，對代碼補丁進行更好的完善，從而能得到更好的代碼。
? ? ● 能減輕維護成本
內部保留的 Local Patch，在每次升級到開源軟件較新版本的時候，這些 Patch 都是需要進行評估，部分需要和入并測試的。當然希望這些 Local Patch 的數量越少越少。最好的辦法就是當該開源社區發布新版本的時候就已經包含了這些 Patch。包含的數量越多，企業內部需要評估、需要合并和測試的 Local patch 數量就越少，升級起來成本就越低。記得 Fedora 的發布版本里面，每個版本都保留了不少針對內核和其他組件的 Local Patch，紅帽的工程師也在不斷的把這些 Local Patch 貢獻并和入到上游開源項目社區里面，這樣才能保持 Fedora 內部的 local patch 數量在一個比較低的水平，也保證了升級版本時候的成本是比較可控的。
? ? ?●?建立團隊技術品牌和雇主品牌，方便招聘，并提升工程師自豪感
向上游開源技術社區貢獻代碼，Upstream 這些 Local patch，是可以獲得更好的社區口碑的。向這些技術社區表明該公司不僅只是開源軟件的消費者，同時也是貢獻者。
同時可以建立起較強的團隊技術品牌，表明該公司不僅僅業務比較不錯，技術團隊也是很有實力的，這樣方便對外招聘。
Upstream 到上游開源社區，同時也有利于提升團隊的工程師自豪感和滿意度。
舉個例子，?小米公司在大量使用 Apache HBase 項目的時候，負責的研發工程師堅決執行 Upstream 的策略，不斷的把小米內部驗證過的 Patch 貢獻回到 HBase 社區，并和 Hbase 社區的同學們一起進行某些特性的討論和研發。小米同學在 HBase 社區的影響力越來越大，不斷產生了 Committer 和 PMC，最后小米工程師張鐸成為該項目的 PMC 負責人即項目的 PMC Chair。小米公司在大數據、云計算等領域的技術品牌，很大程度上來源于此項目相關的研發團隊。
?3.個人成長如何利用開源?
工程師的成長，跟他從事的日常工作密切相關，也跟他的日常學習密切相關。?在這個過程中，如何利用開源軟件，來更好的幫助工程師進行成長，幫助工程師實現他們的職業理想或者技術理想，?這里有一些建議。
3.1開放和共享，眼界和心態
站住巨人的肩膀上才能站的更高。?開源世界里面有的是各種各樣的軟件，面向各種場景，解決各種問題。?所以一定要保持一個開放的心態，即在做什么技術相關的事情之前，先看看別人是怎么做的。?要知道世界這么大，工程師遇到的問題 99.99%?以上都是別人已經遇到的問題，別人是如何解決的，有什么經驗可以學習，?尤其是可以看看別人開源出來的項目，看看他們的設計文檔，看看他們是如何思考的；看看他們的源碼，看看他們是如何實現的。?如果感興趣，還可以進一步跟他們直接交流。?一來可以少走很多彎路，避免很多不必要的重復工作，避免重復踩坑。?二來不用重復造輪子，可以把有限的時間放在更有價值的工作上去。?千萬不要坐井觀天，老子天下第一，多看看工業界和開源界，剛畢業去大廠的同學尤其需要注意。
另外還需要共享的心態，學到了最好能共享出來，?讓別人也能參考，吸取經驗和教訓，從而達到共同提高的目的。
?3.2學習開源軟件的推薦步驟和方法
?——費曼學習法?
學習開源軟件有各種學習方法。?針對不同的學習目的，也需要根據自身情況（即對該領域的熟悉程度以及對相關開源項目的了解程度）等采用不同的更適合自身的學習方法。
筆者在這里給大家推薦一個適合工程師學習一門全新的開源技術項目的方法：
● 先盡快入門，把這個開源軟件的 Quick Start（快速入門）和 Tutorial（入門教程）跑起來，先了解它的主要場景和關鍵特性。
●?然后看文檔，注意系統的主要架構圖，了解整個系統的大致架構，建立起一個比較大的整體框架圖出來。
●?最后再結合自身的實際應用場景看相關細節，包括某個細節的文檔和代碼。
比如，如果想學習?Kubernetes，先上它的官網，把它官網上提供的教程快速運行一遍?
(https://kubernetes.io/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive/)
?了解如何創建 pod，如何訪問，如何更新，如何進行流量調度等等。?然后看它的架構圖，了解它的設計原則即聲明式編程，包括幾個核心組件Kube-apiserver,kube-scheduler,kube-controller-manager, kubelet 等的功能以及這些組件都是如何交互的；?最后再根據自身的業務場景需要，看看具體哪部分還需要更深入的了解。?例如需要加入自己的存儲方式，那么看看相關的代碼，參考其他友商的存儲方式的實現。
不建議一上來先捧著源碼看，這么看是沒有頭緒的，而且效率很低。?況且現在不少開源項目都 Too Big 了，而且迭代速度很快，很難有人能了解全部代碼，而且從個人精力來說做不到，更別說也沒有必要。
注意學習一定要和應用結合起來，即要動手。“紙上得來終覺淺，絕知此事要躬行。”?古人云，誠不我欺，對于工程師來說尤其如此。?如果是想比較深入的了解一門新的技術，甚至有打算切換技術路線和職業賽道，那么一定要更多的動手，要把這個開源軟件用起來，或者寫一點程序跑個 Demo 并運行在實驗環境里面，最好解決一些身邊的實際問題。千萬別眼高手低，覺得一切都很簡單，但是真的要跑起來，用起來就千難萬難了。可以嘗試參加技術企業內的一些創新活動，例如 hackthlon（黑客松）活動，把新學的技術用起來；或者寫一點點小工具，讓他跑起來，解決一點點實際問題。例如，如果要練習 Python，寫一個爬蟲，每天去爬天氣預報網站上的數據，然后做一個簡單的查詢，可以獲得當前的天氣預報情況。在用中學，學以致用。
還有一個非常好用的學習方法就是費曼學習法。費曼學習法被認為是最有效、最強大的學習方法之一，親測管用。
步驟也很簡單，我把它簡化為如下三步。
● 先學習一門技術
● 把它講給普通人，讓他聽懂
● 如果聽眾沒有聽懂，回到第一步
通過這種方法，只有自己講解該項技術的用法和架構，并能讓普通工程師聽懂這個技術，才算是真的掌握了。
費曼學習法來源于諾貝爾物理獎獲得者理查德?·?費曼（Richard Feynman）。他是一位知名的理論物理學家，量子電動力學創始人之一，納米科技之父，因其對量子電動物理學的貢獻 1965 年獲得諾貝爾物理學獎。他所提倡的學習方法，被稱之為?“費曼學習法”。步驟雖然非常簡單，但是能把復雜的技術進行簡化，并讓普通工程師能聽懂的方式講出來，這需要對這門技術有深入的理解和掌握，還需要對一些專有名詞和概念進行類比、聯想來進行簡化。一般能做到這樣，就說明對這門技術已經達到了入門的程度，可以繼續進行后續的更深入的學習了。
另外參加業內一些著名課程的考試或者認證也是一種比較好的方式。例如對云原生不熟悉的工程師，當他通過 CKA（Certificated Kubernetes Adminitrator）認證 Kubernetes 管理員考試之后，這個認證可以驗證他具備一定的水平，已經建立起對 Kubernetes 常見操作和系統架構比較全面的了解了。
3.3融入開源社區，終身個人口碑?
最后一點，對于工程師來說，參與和融入到開源社區里面積極貢獻，將會獲得終身的口碑，并能結交到終身的朋友，是十分有利于工程師的長期發展的。?在此，鼓勵工程師，可以選擇自己感興趣的開源項目和社區，并通過交流和貢獻，不斷在社區里面成長。即使以后因為工作關系或者其他種種原因，不繼續在這個開源項目和社區中活躍了，但是他的貢獻將一直被承認。
Apache 開源軟件基金會有一句很有名的座右銘："Merit never expires"
(參見：http://theapacheway.com/merit-never-expires/)
就是說工程師在 Apache 開源軟件基金會項目和社區做貢獻獲得的認可，是永遠不會過時的。曾經是提交者，永遠是提交者。
在開源社區里進行協作，也是工程師進行社交的一種方式。在這里，能認識終身的朋友，能和他們一起工作和交流，對于工程師的成長也是非常有效的。很多開源社區的大牛，在社區里面也是非常友善的，尤其對待新人，對待比較 junior 但是貢獻欲望比較強烈的工程師，更是愿意手把手地教的。在這些大牛工程師的幫助和指引下，新人的成長是非常快的，而且沒有企業?/?部門?/?工作項目等帶來的天花板。即新人可以在自己感興趣的開源項目和社區里面，憑借虛心的態度和貢獻欲望，不斷和社區內的資深工程師進行交流和學習，可以帶來技術能力的飛速發展的。
另外，對于現在的工程師來說，很難有終身雇傭的企業，工程師在企業里面也就是工作一段時間，然后隨著各種主動或者被動的變化，崗位或者就職企業也會發生變化。但是在開源社區貢獻所獲的認可，和建立起來的個人品牌和技術口碑，是永遠隨著個人的，不會因為公司或企業的情況而發生變動。能看到很多一直活躍在開源社區的人，雖然職業發生了很多變動，但是他們在開源社區的認可和品牌一直存在。這也是很多工程師突破職業內卷，突破平臺限制的一種好辦法。
在開源社區長期做貢獻，是利人利己的好事，鼓勵每一位有想法，有行動的工程師，都能找到自己喜歡并投入的開源項目和社區，并且融入進去。
?3.4如何在開源社區貢獻?
在開源社區，尤其是哪些尊重精英治理的社區（例如?Apache?基金會的項目），做貢獻越多，得到的認可越多。?但是很多時候，作為一個新人，要去開源社區做貢獻，并不是抬抬手就能做的，是需要先了解一些社區規則，然后遵守規則才能夠慢慢融入的。
1.貢獻什么？
在做貢獻之前，我們需要了解，對開源社區的貢獻并不是僅僅局限于代碼貢獻，寫代碼增加功能或者 Bugfix 是貢獻，完善文檔和測試用例是貢獻，報告使用問題是貢獻，寫博客介紹項目和推薦項目也都是貢獻，這些都是在開源社區內被廣泛認可的貢獻。
很多社區的技術大牛，進入開源社區做貢獻是從提交測試報告開始的。比如當年 Mozilla 社區最年輕的架構師 Blake Ross（17?歲就成為?Mozilla?社區最高技術決策層之一，并和另外一位架構師創立了?Firefox?項目），他最初進入 Mozilla 社區，是作為實習生，從測試開始的。
“Scratch your own itch!”?這是在開源社區流行很廣的一句話，意思是說在開源社區做貢獻，是需要解決自己的問題的。即在實際工作中遇到了問題，然后嘗試去解決，最后把解決的結果以社區接受的方式貢獻到社區。一般的情況是有個 Bug 或者問題影響用戶的實際應用，或者想增加一個新的功能來滿足企業的自身場景，或者就是想學習一些新的技術。這種解決自身需求的貢獻，是比較長久的。而為了一些蠅頭小利，參與社區運營的一些活動獲取獎勵，對工程師來說只是 for fun，這種貢獻也不是長久的。
所以，對于一個新人，進入到開源社區里面，貢獻可以從一些簡單的問題開始，從解決自身的需要開始。?一個最簡單的例子，先看新手入門文檔，照著文檔描述的步驟一步步走下去，看看能否走通；如果走不通，可以報一個 Bug 出來；或者親身體驗需要增加一些額外的步驟才能走通，可以給這個新手入門文檔提一個 Patch，把這些補充步驟描述出來，這也是社區很歡迎的貢獻。
有些社區把一些簡單的 Bug 設定為?“Good First Issue”，貢獻者可以挑選這些 Issue 來進行貢獻，來熟悉貢獻流程，并融入到社區里面。
2.了解現有社區情況，尊重社區的慣例和習慣
給開源社區做貢獻的第一步是先了解社區。
可以通過社區的網站、郵件列表、Wiki、github 代碼倉庫中的文檔等資料，了解該開源社區的一些基本情況。
通過查看關鍵文檔（Contributing.md)，了解這些項目的貢獻流程和推薦方法。
注意每個開源社區都有自己的慣例，比如他們有自己的?Issue?管理系統（有的可能用?github?的?Issue，有的使用?Bugzilla，有的使用?Jira），然后提交 Patch 的流程和要求也不一樣。
例如歷史非常悠久的 Apache HTTP Server 項目，它對貢獻者的要求如下：
● Patch?需要符合他們的?Code Style
● 對代碼質量也有一些例如線程安全的要求
● Patch?需要針對當前的開發版本?–2.5.X?來做比較
● Patch?的格式使用?diff -u file-old.c file.c?來生成
● 提交?Patch?的入口在?bz.apache.org/bugzilla，建議加上?“PatchAvailable”?關鍵字
● 可以在?mail list?中發郵件來討論，郵件的?title?需要為?[PATCH ]
注意他們采用的方式并不是 github 上流行的 Fork/Pull Request 模式，而是更古老的 Bugzilla+Diff Patch 的模式，?請尊重他們的工作習慣，使用他們要求的模式。（說句老實話，筆者 20?年前在 Mozilla 社區做貢獻的時候，工作方式也是采用 Bugzilla + Diff Patch 的方式。二十多年過去了，Apache 的 HTTP Server 項目的工作模式并沒有發生大的變化。不過工作方式不影響貢獻，熟悉并習慣就好。）
有的開源社區，會提供一種游戲化的貢獻流程，即讓開發者通過一系列簡單的新手任務來熟悉項目和貢獻流程。這種方式是對新人更加友好的，也是經過該社區的社區經理精心設計的。那么對于貢獻者來說，別辜負了他們的良苦用心，走一遍自己覺得必要的任務，熟悉自己希望熟悉的任務和流程就好。
3.態度需要"Be Polite and Respectful"，尊重社區的多樣性
開源社區里面是充滿多樣性的。
開源社區內大部分的資深工程師對新人非常友好的，他們會很有耐心的教導新人，熟悉文檔，熟悉貢獻流程等等（注意一般只有一次，別辜負了）。日常交流中，包括在郵件列表中，在 IRC 或者 Slack 頻道中，在 Issue comments 中，都比較 nice。跟他們的溝通和協作比較容易。
但是注意，也有部分人相對態度不是特別好，如果遇上了，注意不用發生正面沖突。建議可以向社區更資深的一些工程師來求得幫助，而不用正面硬剛。不可能改變任何人，也不可能讓所有人都喜歡，完成必要的工作就好。
4.如何快速找到負責代碼Review的Module Owner,完成貢獻
有的時候，按照社區貢獻流程的文檔走下去，不管是提 Issue 或者報 Bugs，發現模塊負責人反饋很慢的時候，這個時候有一些技巧。
可以加入他們的 IRC 或者 Slack 頻道，找到對應的模塊負責人，然后跟模塊負責人進行禮貌和有建設性的對話。
跟他們建立良好的關系，并通過實際的貢獻，逐步建立起他們的信任。
注意，開源社區的運作是以信任為基礎的。能獲得模塊負責人的信任，是非常有利于之后的工作開展的。
5.提交大Patch需要注意步驟
可能有的工程師反饋，我給某某開源社區提交一個非常好的特性，在我的公司內部工作環境內測試并驗證，效果非常好，性能表現非常出色。但是我把代碼提交到上游開源社區的時候，發現社區并不看重這個特性，反而對我的 Patch 指指點點，挑出各種毛病。太麻煩了，太心累了，干脆不貢獻了。
需要將心比心地想象一下，如果一個陌生人給你的項目提交一個很大的 Patch，代碼 Review 實施起來就很費勁，因為 Patch 比較大。雖然貢獻者說這個 Patch 很有用，實現了一股很厲害的功能，而且經過了他的驗證，但是他是否可靠，他是否能在社區里面長期存在，他是否能夠及時修復他所提交的代碼產生的問題，這些都是問號。所以在沒有建立起基本的信任之前（即提交了幾個小 Patch 并得到了和入），提交大的 Patch 是很費勁的。
另外，提交這個 Patch 的工程師往往并不了解這個開源社區的歷史，也許這個功能很早就在社區被討論過了，也許討論的結論是不需要做或者在別的地方來做。所以，不要盲目自信于自己的 Patch，而是應該先跟社區的工程師先溝通這個場景和問題。
筆者建議貢獻的步驟如下：
● 如果判斷這個?Patch?比較大，那么先在社區內討論問題，讓社區認可這個問題，同時也能獲得社區對這個問題的一些歷史信息（如果有的話）
● 如果社區認可該問題，覺得現在應該要修復了，繼續討論解決思路
● 問題和思路已經被認可之后，并完成一點點設計之后，再討論具體的代碼?Patch
● Patch?需要遵守社區的規范（CodeStyle、組件調用規范、測試規范、文檔規范等）
● 做好心理準備，Patch 可能需要反復修改若干次才能最后被和入，可能需要把一個大的 Patch 拆成若干個小 Patch，分批提交和入。必要的時候需要一定的妥協。
貢獻一個大的 Patch，實現一個重要的功能，步驟雖然多，時間周期雖然長，但是完成之后，能得到社區的高度認可，往往是成為更高層級貢獻者的基礎。而且對于貢獻者個人來說，內心的滿足感和成就感也是非常足的。
6.注意不要做以下的事情
● 提出一個 Idea，希望別人來完成。
尤其是剛剛加入一個社區的時候，就提出社區需要做某些事情，但是自己不做，希望社區里面的其他人來完成，這些意見往往是會被忽略的。“有許多人，‘下車伊始’，就哇喇哇喇地發議論，提意見，這也批評，那也指責，其實這種人十個有十個要失敗。”?這種人更是不受社區歡迎的。
提出一個問題，同時提供一個有建設性的解決辦法，而且自己要參加，可以邀請社區其他人來一起。這是比較推薦的做法。
● 過于急切，缺乏耐心，而忽略了社區的慣例。
寧可速度慢一點，尤其是在社區對新人的信任感建立起來之前，要有耐心。筆者曾經見過一個剛進入開源社區的工程師，技術能力很強，但就是只想快點把他的 Patch 和入進去。跟模塊負責人的溝通的時候，態度雖然禮貌，但是對負責人給出的改進意見反應很敷衍。折騰過幾次之后，該貢獻者在該社區的口碑已經被損失殆盡，他相關的 Bugfix 和新功能開發進展很慢，他后來也黯然離開了該項目。
● 不要碰紅線（即社區的行為規范所禁止的一些惡劣行為）
基本每個成熟的開源社區都有自己的行為規范（Code of Conduct），一般都會在該社區網站或者代碼倉庫的顯著位置展示此文件。
規范內容列舉出若干社區不歡迎的舉動，包括性別、種族、宗教等方面的歧視和冒犯。
注意不要有這些行為，可能有的行為在中國開源社區里面并不被認為是大問題，但是在國際社區不一定是小事。
7.在企業內部對上游社區做貢獻要注意合規問題
在企業內部給上游社區做貢獻，因為是把公司內部研發的結果公開出去，所以需要滿足公司內部的開源貢獻管理辦法。
每個公司對此的規定不太一致。例如谷歌鼓勵工程師貢獻到開源社區，但是要求工程師應該以 google.com 的郵件地址來進行貢獻，100?行以下的貢獻不需要通過內部流程審批，但前提是項目沒有采用 Google 禁止的許可證（例如?AGPL，Public Domain，CC-BY-NC-*）
此外還有一些硬性條件，參見Google OSPO 的官網鏈接：? ? ? ? ? ? ? ? ? ??
https://opensource.google/documentation/reference/patching
?國內百度公司也是鼓勵工程師貢獻到開源社區，無論 Patch 大小都需要經過內部的電子流程，由該部門的技術總監進行審批，并交由百度的開源管理辦公室（OSPO）進行備案，以便后續開源辦公室的數據統計和對工程師的貢獻激勵提供數據支持等。
在企業內部給上游社區做貢獻的時候，往往會碰到該社區要求工程師簽署 CLA（Contribution License Agreement，即貢獻許可協議）或者 DCO（Developer Certificate of Origin，開發者原創申明）的事情。其中 CLA 又分為 ICLA（Individual Contributor License Agreement）和 CCLA（Coperation Contribution License Agreement，即企業級貢獻許可協議），其中 ICLA 是針對個人的，CCLA 是針對整個企業的，即如果該企業簽署了 CCLA 之后，該企業內部的工程師再做貢獻就不用單獨簽署 ICLA 了。不簽署 CLA 的話，則不能提交 Patch。CLA 條款的內容是貢獻者把自己的貢獻授權給社區來進行使用。此時請遵守公司內部的規定，相關的 CLA 條款可能需要經過公司內部的法務來進行 Review。不過好在一些著名項目的 CLA 條款，例如 Apache 開源軟件基金會的項目都使用統一的 CLA 文件，CNCF 基金會的項目也是類似。這些著名項目的 CLA 條款，法務確認之后就沒有問題了。如果不是法務已經確認過的 CLA，需要跟公司負責的法務進行咨詢，避免碰上一些對企業不利的 CLA。
?總結?
本文比較長，凝聚本人的很多心得和體會。
一直認為工程師是非常務實，非常努力的一幫人，是一群深深相信?“我們可以用代碼來改變世界”?的人，是一群認為?“Talk is cheap，Show me the code”、“日拱一卒，功不唐捐”?的人。我一直認為?“開放、協作、務實”?是當代工程師最好的特性之一。
在開源世界里學習、工作、分享，是工程師改變世界最好的途徑之一。
相關閱讀 | Related Reading
行走在開源世界的孤勇者：“只有開源接納了我” | 技術人訪談錄
恭喜 DevLake 加入 Apache 軟件基金會孵化器！
采訪了定義開源的那個人，他說：RMS 有自閉癥，開源不能單一倉庫
開源社簡介
開源社成立于 2014 年，是由志愿貢獻于開源事業的個人成員，依 “貢獻、共識、共治” 原則所組成，始終維持廠商中立、公益、非營利的特點，是最早以 “開源治理、國際接軌、社區發展、開源項目” 為使命的開源社區聯合體。開源社積極與支持開源的社區、企業以及政府相關單位緊密合作，以 “立足中國、貢獻全球” 為愿景，旨在共創健康可持續發展的開源生態，推動中國開源社區成為全球開源體系的積極參與及貢獻者。
2017 年，開源社轉型為完全由個人成員組成，參照 ASF 等國際頂級開源基金會的治理模式運作。近七年來，鏈接了數萬名開源人，集聚了上千名社區成員及志愿者、海內外數百位講師，合作了近百家贊助、媒體、社區伙伴。
總結
以上是生活随笔為你收集整理的工程师如何对待开源——一个老工程师的肺腑之言的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： DIVX、AVC、HEVC格式的区别
- 下一篇： 职业成长-升级打怪