DevOps｜亂談開源社區、開源項目與企業內部開源

• 2022 年 11 月 7 日
• 筆記

之前的一篇文章《從特拉斯辭職風波到研發效能中的荒唐事》中關於企業內源的內容在研發效能群內引起了大家的熱烈討論。有的小夥伴不同意，有的小夥伴非常不同意，我覺得這都是非常正常的回饋，話不說不透，理不辯不明，我還是特別希望能和大家一起把這個問題弄明白。這篇文章就是那篇文章的後續，本文主要討論開源社區、開源項目以及企業內源。

企業內部開源

內部開源（Inner Source）簡稱內源，指把開發開源軟體中學到的經驗教訓應用到公司或組織內部開發軟體的實踐。公司和組織可以在內部開源的同時開發專有軟體。

開源社區概念

開源社區又稱開放源程式碼社區，一般由擁有共同興趣愛好的人所組成，根據相應的開源軟體許可證協議公布軟體源程式碼的網路平台，同時也為網路成員提供一個自由學習交流的空間。由於開放源碼軟體主要被散布在全世界的編程者所開發，開源社區就成了他們溝通交流的必要途徑，因此開源社區在推動開源軟體發展的過程中起著巨大的作用。

開源社區的特點

1）共同興趣愛好

你對這個東西感興趣就可以參與進去，小到更新文檔，回答用戶問題，大到貢獻程式碼、優化架構、加入方向討論。只要你有能力且得到了別人的認可，那麼社區就是歡迎的。願意加入就加入，覺得不合適了就退出。你不對任何一個人有義務，任何一個人也沒有理由約束你。

2）開放式交流空間

基於PR的程式碼協作，基於 wiki 的文檔協作，基於slack/telegram 或者郵件組的討論溝通。大家「大部分」的工作都是透明的。

開源項目所有的物料、製品每個人都可以訪問。正式發布的版本還是會受到核心團隊的審查、驗證、把關等。

當然某些開源項目也有核心成員，他們的一些討論會限制在一定範圍。大體來看，這還是一個非常開放式的交流空間。

3）開放式協作：平等、自組織、精英領導

因為大家是基於興趣愛好而來，那麼來去自由。想關注 Watch/Star 項目即可；想貢獻內容 Fork/PR 過來，會有人查閱你的 PR；自己已經很熟悉項目了，在 Issue 討論區幫助回答用戶問題也可。總之想對一個項目進行貢獻，是沒人限制你的。

雖然加入的門檻很低，但是開源協作是有「運行規則」的。每個項目都有一些核心成員，這些成員主要是把控項目前進的方向，推動項目前進，接受其他人的 PR，同時對項目投入更多的精力產出更多的內容。

開源社區是一個以共同興趣愛好為基礎的、鬆散的組織。

企業的概念

現代的企業是依法設立的,以營利為目的,運用各種生產要素(土地、勞動力、資本和技術等),向市場提供商品或服務,實行自主經營、自負盈虧、獨立核算的法人或其他社會經濟組織。最本質的企業是一個以盈利為目的的經濟組織。

如果一定非要說企業都由什麼興趣愛好的人組成，那就是都擁有「共同賺錢的愛好」。 

企業的特點

企業是一個由組織機構、規章制度組成的的社會組織，需與員工簽訂勞動合約，而形成的一種開放式的社會組織。企業給員工各種福利待遇，員工按照公司要求盡職盡責，不存在自組織的因素。

企業不需要依靠血緣、親緣等其他關係，更不依賴於興趣愛好；公司里也會有各種公司組織的社團，提供一些經費場地等，但根本目的還是服務好員工，讓員工有更好的產出。

企業作為一種社會組織，他的目的就是盈利，不斷提高經濟效益。如果說做開源社區可以給公司帶來經濟效益，那麼公司也可以選擇做；但做開源社區只是一種手段，而不是目的。

企業並不是一個完全開放式的空間，通常來說員工的薪資待遇股票期權等在公司都是禁止公開討論的。公司的發展策略等也是高層領導確定後把結論周知大家，至於決策等過程、用到的數據、利弊的考慮等都會受限於特定的人群，一般也不會在公開場合討論。

曾經有一家公司，企業內網有一個完全匿名的 BBS。匿名 BBS 的出發點是好的，給大家一個自由討論的空間。我覺得這是一個非常好的「討論實質內容」的地方。只要你把事情的原委說明白，基本上都能得到妥善解決。公司的人力、行政、食堂、財務、法務等都願意在上面回答大家的問題。但是後來部分同學開始不斷在上面質疑公司的業務目標、公司的經營策略，公司的打法運營手段等。。。。這已經超出了「實際問題」的層次，甚至已經到了「價值觀」。最後發展的結果就是取消了匿名，從此 BBS一潭死水，而很多原本能在內網解決的問題，卻都變成了脈脈上的各種牢騷。

企業是一個自上而下的組織架構，有很多的層級，上對下有考核、管理、領導的權利；這一點和開源社區區別很大。雖然開源社區也有精英式領導，但頂多接受或者拒絕你的 PR，談不上管理，更沒有考核。

開源社區+企業

企業和開源社區也可以結合。比如 Redhat。 Redhat 曾經是一個納斯達克上市公司(2018年被 IBM收購)，它是一家開源解決方案供應商，為諸多重要IT技術如作業系統、存儲、中間件、虛擬化和雲計算提供關鍵任務的軟體與服務。Redhat 是很多重大開源項目的主要貢獻者。僱傭專職的員工為開源社區貢獻程式碼，然後將開源社區項目產品化，達到盈利。

企業內部開源的目的是啥？

企業為啥要做內部開源(inner source)? 從內源的維基百科上，我們可以看到主要動機就是 1）想在內部建立類似開源的文化 2）在企業內部開發專有軟體。

• 1）共同興趣愛好：如果某些人對項目感興趣可以自願去學習、去加入

• 2）開放式交流空間：某些項目的文檔、程式碼、製品都開放

• 3）開放式協作：平等、自組織、精英領導

做到以上三點不難。如果僅僅是把repo 許可權打開、文檔放開、開放討論，那後面怎麼讓項目進展下去呢？這是我們要考慮的問題。

企業內部項目和開源社區項目異同

企業內部的項目都有團隊歸屬的屬性。開源社區的項目雖然也有核心成員，但是你完全可以 fork 一個自己的倉庫，自己維護，不用在乎核心成員和原項目。

企業內部項目做不好，有追責的機制，投訴的機制：開源社區的項目沒有這個機制，你覺得項目做的不好你來貢獻。

企業內部的項目都有明確的時間節點，都有交付日期的規劃。到什麼時間點交付什麼製品都是有清楚定義；雖然開源社區有的項目也有日期規劃，但也只是規劃，延期交付，大家也覺得沒啥，畢竟大多數人是白吃人家飯，還要嫌棄人家飯晚么？

企業內部項目都有品質要求，這個團隊做這個項目，那麼就要對這個項目品質負責，出了問題，你要修復；雖然優秀的開源社區項目出現了問題，尤其是嚴重問題，負責任的團隊也會及時修復，但這不是義務，更多還是一種自我追求。大多數項目都是「你行你上，不行別BB」

企業內部項目都有產品方向，策略、路徑、目標計劃，你可以「諫言」，提出好的建議，但是最終還是負責團隊「決策」。

所以開源項目是一個成員人數不定、自組織、精英式隊員領導的沒有盈虧核算的鬆散項目。對於何時能滿足用戶需求具有很強的不確定性。而企業內部項目是團隊組織架構清晰，有明確負責人負責的在一定時間內達到某種目的的自負盈虧的項目。對於企業內部項目，時間、範圍、品質、成本都有明確的要求。

企業內源怎麼才能做起來？

那我就想在企業內部搞企業內源，我怎樣才能搞起來呢？什麼樣的項目適合呢？

• 已經具備一定功能，仍需添加小需求的維護性項目

• 對時限沒有嚴格要求的小項目

• 公司氛圍是寬鬆的，員工有「閑」

• 公司的程式碼評審做得很好

• 支撐的基礎設施相對完善，不需要更多其它角色介入（比如設計師、QA等）

通過上面就可以看到只有人閑，且需求沒有deadline，這樣的內源項目也許才能跑起來。

中國企業內源現狀

線下和一些華為騰訊百度的小夥伴細緻了解了下企業內源的情況，總的來說，企業內源是可以做的一件事，但是效果和前景並不像網上說的那麼光鮮亮麗。花了很大力氣去搞，效果其實一般。對於一個大公司，如果大家覺得自己很閑，想豎起大旗做個專項，弄個企業內源，當成個事向上彙報還是可以的，但別太當回事。都冷靜下來想一想，華為騰訊百度這種自身工作都卷到10點多回不了家的公司，怎麼可能很閑，怎麼可能靠「共同興趣」去搞企業內源？除非做企業內源也是我工作的一部分，是我的「職責範圍」。那和實際的項目制本質區別又在哪裡？

文章總結

開源項目和企業內部項目差別很大，形相似義不同。對於「盈利」有很高要求的企業，項目的目的性非常強，對時限有明確的要求。項目的時間、範圍、品質、成本都會納入考量的因素，通過在不同因素間進行衡量，做出最佳的決策。如果企業內源不能在時限上給出明確的時間點，對範圍、品質、成本也不能明確出來，大部分企業內部項目都不可能以這種形式展開。

以上討論的範圍限制在中小企業（研發小於3000人），有專職團隊負責基礎工具，中台工程類建設的情況。

更多內容

從特拉斯辭職風波到研發效能中的荒唐事

內源的維基百科 //en.wikipedia.org/wiki/Inner_source

Tim O’Reilly //en.wikipedia.org/wiki/Tim_O%27Reilly

感謝點贊、轉載關注我，了解研發效能發展動向歡迎進入「DevOps研發效能」一起探討