大廠爭先成立的“開源辦公室”有啥門道？

最近，有訊息稱位元組跳動在內部郵件中正式官宣了“開源委員會”的成立。其實，這在國內大廠裡並不少見，華為騰訊百度等都早已成立了自己的“開源辦公室”，位元組跳動的動作更像是一種“順勢而為”。

“軟體吞噬世界，開源吞噬軟體”這句話都已經被說爛了，因為事實就擺在那裡，現代應用程式已經被開源元件所佔領，企業既繞不開也躲不掉。況且，開源軟體還能為組織帶來節省成本、提高程式碼質量等諸多好處。

因此，企業內部針對開源成立專門的組織機構幾乎是命中註定。Open Source Program Office（簡稱 OSPO），也就是我們所說的“開源辦公室”，就是這樣的背景下誕生的。

事實上，國外企業在 OSPO 上的腳步，要比國內走得更快更遠。早在 2004 年，谷歌就已經成立了自己的 OSPO，這也是最早成立的一批 OSPO。隨後，微軟、Adobe、Netflix、英特爾等知名科技公司紛紛跟進，普及速度迅速。

在 Linux 基金會名下，有一個專門致力於普及 OSPO 的工作組，叫做 TODO。TODO 最近的一項調查發現，雖然 OSPO 在科技行業的普及率仍然是最高的，但是在教育和公共部門等也正在興起。OSPO 開始滲透到國外的大學、政府和民間機構當中。

 

可以預見的是，OSPO 的實踐也會漸漸地在我國普及開來。但是，我們對 OSPO 的認識卻又少之又少。在觀察了各家企業的 OSPO 實踐之後，小編總結了 OSPO 在設定上的以下幾個特徵：

 

1、企業不搞，員工也會“暗搓搓地”搞 

現實情況中，就算企業不搞開源，也不能避免員工會遇見開原始碼。很多人在討論，一些企業對於開源持有抵制態度，會限制對開源軟體的使用，其實不然。在十多年前，這種情況是有可能的，比如說微軟在堅決反對開源的時候，的確有聽聞他們會禁止員工參與和閱讀開原始碼。但隨著對開源態度的轉變，微軟現在的開源參與情況大家都有目共睹。

因此，一個企業對於開源的態度重點其實不在於反不反對，而在於重不重視。企業很少會阻止自家員工去接觸開源，但是如果這個企業足夠重視的話，它不會放任這些內部的開源力量是散漫無組織的狀態。

這一路徑基本符合大多數公司 OSPO 的建立過程。比如雅虎、優步等，都在官方的陳述中表示自家的開源之旅是由小部分熱情的工程師“非正式”地開始的。

然而，僅憑工程師的興趣和熱情是不夠的，不加以規範和約束往往會造成問題。就拿剛剛成立 OSPO 的位元組跳動為例，它在開源合規性上吃了不少虧。2021 年 10 月，抖音前端團隊宣佈開源其設計系統和 UI 庫 Semi Design，卻涉嫌抄襲；2021 年 12 月，抖音海外版還因為違規使用 OBS 等原始碼，被推上了輿論的風口浪尖。一系列的事件這讓位元組意識到了問題的所在，於是今年他們開始成立 OSPO，引入公司級的開源策略、規範和流程機制，也就不奇怪了。

無獨有偶。從 2010 年開始，Twitter 的開發人員開始發現回饋開源專案是一件很難的事情，因為公司的法律部門對程式碼許可和相關問題非常擔憂。針對這一問題，Twitter 最後找到的解決方案是 —— 建立 OSPO，把合規流程抓起來。

基本上，對公司和員工來說，成立 OSPO 是一個雙贏局面。規範流程讓工程師們在一定支援的情況下，安全地參與到開源中去；而公司也可以藉此防範風險、留住人才。

 

2、OSPO 團隊普遍“人少”

OSPO 作為一個不產出收益的辦公室，自然是編制越精簡越好。一些說法認為，每 1000 名開發人員中大約需要 1-5 人負責監視 OSS 相關活動。因此，絕大多數企業的 OSPO 其實是一個很小的團隊。

當然，這個比例並不是定死的，更多情況下要視企業自身而定。例如，傾向於在集團層面進行統一管理的 Bloomberg 在 6500+ 開發人員的規模下，其 OSPO 僅有兩名全職；而對細節管理比較注重的 Comcast 儘管才 1000+ 開發人員，它的 OSPO 團隊也達到了 5—10 人。

谷歌 OSPO 辦公室經理 Will Norris 曾透露，他們辦公室只有大約 15 名團隊成員，其中包括了一個合規團隊、兩名律師、一個負責活動參與的外展團隊和一個技術團隊。這 15 人要服務的是谷歌 72000 多名員工。

當然，全職團隊雖小，但一些企業會採取“虛擬職位”的形式。所謂“虛擬職位”是說：這些職位是虛的，員工是在兼職幹這件事，他們有自己的本職工作和實際部門。這取決於 OSPO 必須與公司內多個不同部門合作的特性。

其中的經典例子就是 SAP，SAP 在 2018 年初成立了自己的 OSPO，將其開源專案辦公室組建為一個虛擬團隊，由來自不同領域的多個團隊組成董事會。

位元組跳動此次成立的開源委員會，也採用來虛實結合的運作方式。也就是說，全職同學 + 不同研發團隊的兼職同學，以最大程度地複用各個團隊已經做過的工作。

還有一個非常特殊的例子就是 Netflix。實際上，Netflix 並沒有正兒八經地成立開源辦公室，而是通過一個小型的跨職能工作組來管理開源事宜。該工作組在內部郵件列表進行討論，每月舉行一次非正式會議。當然，也有觀點認為 Netflix 之所以能這麼做，是因為它更多是一家流媒體公司，而不是一家軟體公司。

 

3、但職能一點也不少

OSPO 到底需要乾點什麼？在 Linux 基金會 TODO 小組的定義中，OSPO 的職能包括設定程式碼使用、分發、選擇、審計相關政策、培訓開發人員、確保法律合規以及促進和建立有利於組織戰略的社群參與。

總的來說，OSPO 最核心的功能大致是以下幾個：

首先，OSPO 經常要關注和監督公司開源合規性的各個方面。也就是說，當公司使用開源軟體專案時，他們需要了解許可證和合規性，檢查專案的執行狀況，確保不存在安全漏洞；當公司為開源軟體專案做出貢獻時，他們需要確保沒有智慧財產權問題，以確保公司的貢獻能在專案中處於領導地位。

其次，OSPO 常常是公司與外部開源社群之間的“中間人”。公司是需要與一些關鍵的開源專案社群保持聯絡的，比如蘋果一直和 K8S 社群聯絡緊密。但是，一些公司如果把開源專案社群視為免費勞動力的話，很可能就會在溝通上出現問題，而 OSPO 則需要站在二者之間，尋找到“平衡點”。

激怒我們開源社群朋友的後果將是毀滅性的。這不是我們想做的事情，因為我們關心這個社群，我們是其中的一部分。對於剛接觸開源的公司，我認為他們經常沒有認識到開源的重要性。”

—— Google 開源辦公室經理 Will Norris

最後，OSPO 還肩負培養公司開源文化的重任。具體來說，OSPO 可以通過政策等手段來改進工程師們的開源實踐。TODO 小組的新調查中，近 69% 的參與者表示，在組織內培養開源文化是 OSPO 的主要責任。

這是一項文化變革的努力。程式碼顯然是其中的重要組成部分，但社群和參與是人與人之間的事情。如果你要建立一個開源專案辦公室，並且嘗試使它成為一個真實的東西，則必須瞭解文化和推廣文化。開源負責人是一個真正的變革推動者。

—— 微軟開源專案辦公室主任 Jeff McAffer

 

4、高層重視的前提下，OSPO 可以特色化

其實，OSPO 並不是要千篇一律。正如 Jeff McAffer 所言，沒有什麼一刀切的模型，微軟的經驗也不能被拿過來完全複製到另一家公司。

但有一點原則卻是通用的：OSPO 的建立需要得到高層的支援和重視，否則很難實行到底。因為領導層的支援，往往會起到平息爭議、加大資源和資金投入等作用。然而，高管卻又是常常被忽視的重要參與者，一些高管認為開源僅僅是技術實現中的一些細節。但如果高層有足夠的意識，他們一定會參與到開源管理政策制定中的關鍵決策中去。

大多數 OSPO 都是直接向公司的 CTO/COO/CEO 這個級別彙報的。例如，位元組跳動開源委員會就是由 CEO 梁汝波和兩位技術最高負責人楊震原、洪定坤擔任 Sponsor。在位元組看來，大的開源專案往往需要長期投入，同時又需要協調公司內外很多資源。

但這並不意味著公司必須只能建立一箇中央的 OSPO 來負責整個公司的開源運作。相反，如果公司更傾向於各部分獨立行動，那麼在各個單位中建立分散的 OSPO 也不是不可以。Comcast 就曾在這個方面探索過，該公司最終建立了兩個開源專案辦公室，一個用於 NBC 業務，另一個用於有線電視業務。

 

5、可以從“內源”開始，但別讓“程式碼被砸到牆上”

內源（Inner Source）一詞最初是 Tim O'Reilly 在 2000 年創造的，是指在組織內建立類似開源的文化。也就是說，公司可能仍然在開發閉源軟體，但在內部開放開發，建立透明文化。

內源其實是一個很好的企業開源過渡步驟。在百度開源辦公室的自我介紹中，一開始百度僅是開源專案的使用者，然而該公司在 2013 年開始提出平臺化思維戰略，開始實踐“內部開源”，之後百度逐漸進階形成了今天的開源格局。

此外，騰訊也是一樣。2019 年 6 月，宣佈成立開源管理辦公室的同時，騰訊也公佈了自己的開源戰略路線圖，騰訊的開源將分“三步走”，而內部開源協同則是第一步。

但對於有點追求的企業來說，內源絕不是終點。雲原生計算基金會營運長和 Twitter 前開源專案負責人 Chris Aniszczyk 曾說過：“你絕不希望是自己開源專案的唯一貢獻者。你是期望讓公司以外的人為你的開源專案做出貢獻的。歸根結底，你永遠沒辦法僱傭世界上的所有頂尖人才。”畢竟，與外界人才的溝通才是開源的精髓所在。

而且，一個好的 OSPO 往往能夠將開源專案發揮到最大限度。紅帽公司將那些僅僅將程式碼公開到一個公共倉庫的開源方式戲稱為“把程式碼砸到牆上（throwing code over the wall）”。這種不作為導致的結果可想而知。這時，OSPO 必須發揮自身統籌的作用，通過協調各部門來使開源取得成功。

2022 年 2 月，TODO 工作組釋出的 OSPO 報告裡提出了 “OSPO 成熟的 5 個階段”：

階段 0：使用開源

階段 1：提供開源合規性和庫存的支援，並教育開發者

階段 2：佈道開源軟體的使用方式，培養參與氛圍和開源生態

階段 3：主導開源專案，並發展社群

階段 4：成為開源社群的戰略決策的合作伙伴