嘉賓 | 譚中意

整理 | 涂承燁

策劃 | 徐杰承

“開源”是近幾年是非常火的一個詞，但目前很多企業對于開源是什么，怎么用開源，如何參與開源，企業在開源方面如何做決策，如何進行開源治理，如何利用開源強化競爭力等方面的問題，仍存在著一些難點。

在日前由51CTO主辦的??WOT全球技術創新大會??中，第四范式公司架構師、開放原子基金會TOC副主席譚中意老師為廣大參會者帶來了主題演講——《大中型科技企業如何制定和落地開源戰略》。重點介紹了什么是企業開源戰略；企業為什么需要開源戰略；企業開源戰略包含的內容，以及企業開源戰略制定和落地的實踐經驗。現將演講內容整理如下，希望對諸君有所啟發。

本文分為兩部分：

第一部分為企業開源戰略是什么，為什么需要，都包含哪些內容。

第二部分為企業開源戰略如何制定和落地。

1. 企業開源戰略定義

企業開源戰略是企業技術戰略的一部分。

它主要與開源軟件和協作相關，包括如何使用、如何管理、如何與外部開源社區合作、是否創建自己的開源項目來獲取利益，還包括學習開源社區的協作模式來提升內部的效率和質量等。

關鍵是要與企業的商業戰略對齊。

空談開源對于企而言沒有任何意義，企業是一個盈利性組織，做任何事情都要考慮ROI（投資回報率）。因此，開源的技術戰略一定要與企業的商業戰略對齊。

開源戰略主要解決哪些問題

• 海量開源組件如何使用才能安全、合規、高效？
• 每個企業都會用到大量開源項目，重點投入的項目是哪些？為什么？怎么投？如何衡量？
• 如何利用開源建設內部的研發文化？

2.為什么需要企業開源戰略

企業已經離不開開源軟件，所以需要一個整體、一致、長期、清晰的策略。

• 一個連貫的開源戰略有助于明確企業內的優先級
• 指導開源運營，并向員工提供清晰一致的指導
• 開源管理的流程和政策需要更高層的上位法

在展開闡述企業開源戰略之前，我們先看看開源的一些基本知識和底層邏輯。

開源究竟是什么

“開源”一詞現在已經有很多種解釋，開源軟件、開源商業、開源協作、開源社區等等，開源的核心理念是以公開的方式產生知識產權。開源軟件= 源碼公開+OSI認證的License。而開源的商業模式則是建立在開源軟件之上的商業模式。

現在認為，開源是一種開放式協作模式，產出物符合開源許可證的要求。

企業使用開源軟件不等于免費

企業使用開源軟件不是免費的，是有各種成本的，例如引入的成本、學習的成本、維護的成本等，而在這其中，維護的成本一般是最高的。開源軟件的License都有一個免責條款，用戶使用該開源軟件做任何事情，出現問題與原作者無關，原作者沒有任何義務修復企業在生產環境中碰到的問題。因此，企業在使用開源軟件碰到問題時，要么需要商業公司的支持，要么自行招聘工程師負責這方面的工作。

常見的開源商業模式

符合OSI定義的開源許可證的軟件，軟件本身是沒有銷售價值的，任何人都可以對其進行免費下載、修改、分發，軟件本身不會收取任何費用。而關于開源的商業模式，則主要有如下2種：

（1）羊毛出在豬身上

這是互聯網從業人員非常熟悉的模式，A產品免費、B產品收費。例如Google的安卓手機系統是免費的，但安裝在上面的Google GMS是收費的，這就是一類典型的商業模式。

（2）基于開源軟件進行企業服務

這方面總結起來主要有以下四個模式：

• 雙License（代表：MySQL、X264）
• Open—Core（代表：Kafka，Elastic）
• Service（代表：RedHat，IBM）
• SaaS（代表：AWS、騰訊、阿里）

企業開源的底層邏輯

• 利他+利己

首先，企業將軟件免費開放，將自己的知識產權暴露出去，這本身就是一種利他的行為。但企業又要從開源上獲取收益，這又是利己的。因此，利己和利他必須要很好地結合，既吸取開源帶來的便利，同時避免過度商業化給開源社區及企業長期利益帶來損害。所以需要很好的設計商業模式，把握這個度。

• 競爭+合作

開源界有一個詞是Coopetition，是Competition和Cooperation兩個詞的混合體，開源世界既有競爭也有合作。兩個廠商有可能在開源項目A方面是競爭關系，而在開源項目B方面又是合作關系。開源不是一個零和游戲，更多是做大蛋糕，大家分享利益的過程。例如，同一個商業賽道上的兩家開源軟件企業，可能只有在面對同一個客戶時才是刺刀見紅的競爭，而在其他方面，例如面對投資者、媒體、上下游或用戶時，他們其實是一榮俱榮的合作關系。

• 開放+透明+協作的價值觀

開源的運作建立在“開放+透明+協作”的價值觀上，這也是Apache項目所推崇的Apache開源軟件基金會最基本的理念。開源中的協作是要建立信任的，社區的運作也是以信任為基礎的，而信任的建立必須要遵守這種價值觀。

• 驅動力3.0

對于從事軟件研發的知識工作者而言，參與開源社區做貢獻，更多的是源于他們的自驅力，他們希望自己的軟件能夠被更多人所使用并獲得更好的價值。傳統的“胡蘿卜+大棒”的方式，做了多少事就拿多少錢的這種傳統的激勵方式是非常短期和低級的，對于開源相關的長期健康運作是不適合的。開源需要利用驅動力3.0的激勵模型。

3.如何管理企業內部的開源軟件供應鏈

企業開源戰略之一：開源軟件供應鏈管理

開源軟件的供給非常多，企業要確保開源軟件供應鏈的可信。企業引入開源并在內部進行編譯、再開發、再部署，這是一個鏈條的過程，在這個過程中，最重要的是要保證鏈條是安全的、合規的、高效的。否則會給企業帶來直接的商業損失。以下是幾個實際案例，因為企業不正確使用開源軟件導致的商業損失。

衡量軟件企業供應鏈管理能力?

開源軟件社區的安全漏洞修復是非常快的，一般來說今天爆出漏洞，三天內就會出對應的patch，最遲一周也會出一個新版本。對于引入開源的企業而言，關鍵問題首先是漏洞的定位，其次是修復所帶來的影響，這是企業需要考慮的一個典型問題。而對于向外輸出開源的企業來說，一些比較嚴格的供應商會要求提供合規的軟件組件清單，這對于企業而言會是一個考驗。引入與輸出都能夠做的很好才會被認為是靠譜的、高效的供應鏈管理。

構建供應鏈需要政策、流程、工具、法務、安全團隊的共同支撐，這是一個公司級別的行為。以國內外開源軟件治理的案例來說，一定要將這個流程變成公司級的行為才能夠節省成本。

實際操作案例：?

• 組建跨部門多功能小團隊，包括法務、安全、工具團隊
• 使用工具盡可能自動化
• 需要大規模多層次的培訓和宣導

對于同樣fastjson的一個高危的CVE bug。在構建軟件供應鏈管理能力前，其處理方式為：安全管理部向全員發郵件聲明某個軟件的版本有高危漏洞需要盡快修復，但是半年后這個bug影響多少業務，這些業務是否已經修復都無從知曉。而在具備開源軟件供應鏈管理能力后，企業能夠在30分鐘內定位漏洞所影響的業務線并精確發送安全工單到直接負責人來告知情況和修復辦法，三天內可以做到全部修復。

我們接下來看企業開源戰略中內部開源相關的內容。

企業開源戰略之二：內部開源

當企業規模較大時，很容易出現各部門間壁壘嚴重的問題，俗稱silos“部門墻”。 也很容易在多個部門內出現重復造輪子的情況。筆者曾在某大廠中發現機器學習平臺有15個，某大廠中Kubernetes云部署平臺超過10個，而其中大部分的輪子是低水平、重復、比較low的輪子。在集團范圍內存在這些情況是對人力資源巨大的浪費。此外，工程師對技術的追求比較低，只想著快點把產品做出來、快點上線、快點拿收益、快點去升職，最后好跳槽。這會使得企業的技術升級速度放緩，留下大量技術債與極差的基礎設施，部署環境、監控等都比較差。線上經常出問題，經常處于救火中。

對于以上問題，內部開源是一個有效的解決方案。內部開源（InnerSource）是從開源社區的軟件研發中吸取經驗，并將其應用在公司內部的一種軟件開發模式，其主要擁有以下優點：

• 提升代碼質量
• 提升人員的能力
• 提高員工的滿意度
• 打破部門墻
• 減少重復造輪子
• 激勵創新

由于在實行企業內部開源后，參與其中的項目的代碼會在內部公開，工程師在工作過程中自然而然會考慮代碼的可讀性，而且開源社區的運作方式是代碼提交一定要經過代碼review，擁有嚴格的代碼review過程，代碼質量自然會得到提升。

InnerSource和最近十年企業內推行的DevOps有非常深的聯系。二者都以提升效率為目標。而提升效率最重要的兩個方法，一個是重用，一個是自動化。InnerSource更關注重復用，DevOps則更關注自動化。其兩者是互相促進的，一個DevOps做得好的項目，采用內部開源的方式來運作是更有利的。而InnerSource的基礎設施做得好，也能夠幫助DevOps的工具更快地落地。

只有基于開放、透明、協作的價值觀，建立起內部信任的文化，才可以將DevOps正向推動。對DevOps而言，并不是企業上了CI/CD平臺，流程跑起來就算是做好了。下圖是InnerSource和DevOps的關系圖。

目前采用內部開源的國際大廠包括微軟、谷歌、Bosch，國內大廠包括華為、騰訊、百度等，都在進行相關的內源建設。

企業開源戰略之三：對外開源

Linux基金會曾提出，企業對外開源包括四個階段：消費者階段、參與者階段、貢獻者階段、領導者階段。企業對外開源的兩種形態，一種是Upstream，對已有項目做貢獻，另一種則是自主創建開源項目。自主創建開源項目一定是帶有強烈的商業目的，是Business Driven的問題。

企業對外開源的目標或者說收益主要有以下三點：首先，降低內部版本的維護成本。如果內部用到的開源軟件需要與外部開源軟件的版本長期保持同步，則需要減少本地的補丁數量，做法是將一部分補丁貢獻回去，本地的補丁數量自然而然就會下降，從而減少持續版本升級維護的成本

其次，希望復用開源社區成熟的分發渠道。例如微軟在Linux內核的貢獻是不小的，但其貢獻只聚焦于內核跟微軟Hypervisor相關部分。使用這些補丁才能讓微軟的操作系統上安裝Linux發行版的虛機運行狀態良好。因此，微軟將這些補丁直接貢獻到上游社區即Linux內核，這樣各個發行版出新版本的時候就會直接包含這些補丁。不貢獻在上游Linux內核社區的話，微軟需要跟各個Linux商業發行版本廠商一個個溝通技術合作，這將花費巨大的成本

最后，希望對一些關鍵軟件保持控制力。一些大廠選擇在對其業務非常關鍵的項目上投入人力，就是希望能保證這個項目的迭代符合它的利益目標。

近幾年很多企業尤其大廠都在不斷對外開源自己內部的技術。但是在對外開源之前先需要回答三個靈魂拷問：首先是為什么要做；其次是如何證明是否成功；最后是如何進行衡量。如果這幾個問題都沒有答案，那對外開源只能被認為是工程師自發的行為，對外開源的項目也大概率會成為一個爛尾的項目。

為什么對外開源，有一些比較好的理由如下：

• 構建事實標準，提供開源實現能更快推進標準
• 打擊競爭對手，例如企業與某廠商是競爭對手，業務側重點不同，將對手企業的側重點實現并開源，就是對競爭對手的打擊
• 競爭差異性，例如Mozilla與IE的競爭，IE選擇預裝，而Mozilla則直接選擇開源，實現競爭的差異性
• 建立生態系統推廣，例如Android
• 雇主品牌和技術口碑，例如LinkedIn開源Kafka
• 降低支持成本，客戶自行維護，例如各種云廠商的云SDK

當然也有一些不好的理由如下：

• 甩包袱，不想維護的項目交給社區
• 內部不想增加人員，想找免費勞動力
• 內部工程師或部門的KPI
• 純PR無后續支持計劃

在對外開源之前，需要對該項目進行很好的評估。?

要評估一個項目的潛力，需要明確其所處的賽道、分類、市場潛力、與競爭對手的差異性，以及上下游都有哪些項目，這些更多的其實是產品設計、產品戰略的問題。此外，企業在做對外開源時一定要做如下幾個review：

• 法務review：項目采用什么樣的License、采用什么樣的條款、是否存在法律風險
• 技術review：項目有沒有安全漏洞，有沒有合錄一些不需要的代碼
• 市場review：項目使用什么branding，市場競爭的策略是什么
• 治理模式review：采用獨立發展模式還是托管到基金會，亦或是成為基金會的孵化項目

4.企業開源戰略如何制定和落地

如何制定

企業的開源戰略一定要結合企業的自身情況分階段進行制定。例如擁有海外業務的企業，海外業務可以先從合規做起；內部重復造輪子現象嚴重的企業，可以先進行企業內部開源；而對于主營云，希望拓展智能云toB業務的企業，對外開源會是一個很好的手段。

制定過程可以參考使用BLM（Business Leadership Model）方法來進行規劃和制定

開源戰略如何落地

關于開源戰略的落地有一個簡單的方法，就是組建開源管理辦公室（OSPO）。其作用是幫助企業創建和執行開源項目的戰略，保障開源領導者、開發者、營銷人員和其他員工成功運營開源項目。而OSPO的主要職責則涉及以下幾個方面：

• 清晰向內外溝通公司的開源策略
• 貫徹并監督開源戰略執行
• 促進企業內有效和安全的使用開源軟件
• 維護開源許可合規的審查和監督
• 確保代碼向開源社區的高質高頻發布
• 與開發者社區合作，促進公司對其他項目的有效貢獻
• 在組織內部形成開源文化

業內第一家創建OSPO的公司是Sun Microsystems，Sun公司于1999年成立首個開源辦公室，其所做的第一件事就是推動Java的開源，也是由于開源所帶來的正向影響，Java一直活到現在并且非常有生命力。

設立OSPO的常見模式

業內設計OSPO的常見模式包含三種。第一種，將OSPO設立在在法務部門之下，側重解決知識產權問題，例如硬件的公司都會把OSPO掛在法務部門。第二種則是將OSPO設立在研發部門，主要支持工程師使用開源軟件，適合軟件公司。第三種，將OSPO設立在市場/開發者關系團隊，偏重PR去影響銷售。

目前國內各大企業中，也有不少OSPO落地的案例，華為在其集團標準與產業發展部集團戰略研究院；騰訊在其研發管理部；阿里的OSPO隸屬于CTO office；百度則設立于技術管理部等等。

嘉賓介紹：

譚中意，第四范式架構師、企業智能化轉型開源社區—-星策社區發起人、中國開源推進聯盟副秘書長、開放原子基金會TOC副主席。在Sun、Baidu、騰訊工作超過20年，曾任百度開源技術委員會負責人。在企業開源治理方面有大量規劃與落地經驗。也是多個開源基金會包括Apache、Mozilla、Gnome、InnerSourceCommons、OpenChain的Committer/Member。