譯者:魏子杰
(本文翻譯自 A guide to setting up your Open Source Program Office (OSPO) for success by J. Manrique Lopez de la Fuente, CC BY-SA 4.0)
學習如何拓展、維繫你的開源社群與盟友。
![]() |
圖片來源:CC BY 3.0 US Mapbox Uncharted ERG |
許多公司創設開源計畫辦公室(Open Source Program Offices, OSPO),用來維繫自身與其仰賴之開源生態系的友好關係。在充分理解公司之開源生態系的情況下, OSPO 能最大化公司的投資利潤,並降低購買、參與開發、推出開源軟體等的風險。而且,因為公司非常依賴自身的開源生態系,確保生態系健全與永續就等於確保公司命脈、永續成長與發展。
開源辦公室為何對各公司及開源生態系如此重要?
馬克.安德里森曾說「軟體正在吃掉全世界」,而最近這句話可以修正成「開源軟體正在吃掉全世界」。但為何會變成這樣?
各公司以多種方式參與開源專案,而這些專案構成公司的開源生態系統。想一窺專案與生態系之間的交互關係與影響,可以先著眼開源軟體(OSS)的導入與釋出流程。
從 OSS 導入的角度來看,各公司利用 OSS 建構自有的解決方案與基礎設備維護架構。會運用到 OSS 的原因是技術提供者也在使用 OSS ,或是公司開發者們也將開源元件引入公司的 IT 基礎架構。
從 OSS 釋出的角度來看,許多公司也為 OSS 專案做出貢獻。比方說,若上游專案需要特定修復方案,公司提供支援的同時就是在對 OSS 專案做出貢獻。例如,三星(Samsung)確保自家硬體在上市後能受軟體支援,就等同於對特定繪圖領域專案做出貢獻。還有些案例,對 OSS 做出貢獻是種機制,因為人才們可跳脫日常生活、為專案盡一份心力,公司也能網羅那些人才。
有些公司推出自家的開源專案,也算是種 OSS 釋出的方式,像紅帽(Red Hat)或 GitLab 這樣的公司大概就是這樣;不過也有越來越多像來福車(Lyft)這樣的非軟體公司推出多項 OSS 。
![]() |
OSS 導入及釋出示意圖 |
最終,所有涵蓋於 OSS 導入及釋出流程的專案共同形成公司的 OSS 生態系。跟任何生物一樣,公司的 OSS 生態系決定公司是否健全、永續。
OSPO 的職責
沿用物種和生態系的比喻, OSPO 所屬人員可說是公司 OSS 生態系的防護員。他們照料生態系、維護公司與生態系的關係,確保公司健全與永續。
若公司採購 OSS 專案,他們必須注意授權與合規管理、確認專案是否一切正常、保證沒有安全疑慮。有時候他們更得兼職「星探」,挖掘社群內的人才,以備未來不時的聘僱需求。
若公司對 OSS 專案做出貢獻,他們必須確認沒有智慧財產權(IP)疑慮、確保公司確實做出貢獻並居於專案的領導地位。有時他們也需要盡量將人才留在公司勢力範圍、持續讓人才為公司盡心力。
若公司推出、維護開源專案,他們有責確保社群參與及成長、確認沒有 IP 疑慮、保證公司確實做出貢獻,也許還要持續引進新人才。
讀到這裡,大家了解 OSPO 團隊成員必須具備的綜合技能了嗎?我問過一些在 OSPO 工作的人他們的團隊規模如何,答案是公司內每 1,000 位開發者就有 1 到 5 位是 OSPO 團隊成員。與他們所管控之人員數量及潛在 OSS 相關活動相比,這樣的人數實在不多。
如何管理 OSPO
大家了解 OSPO 團隊成員所關心的事務與責任後,要如何管理 OSPO 呢?
這裡列出幾個能查找到豐富相關知識與資源的開源社群:
- TODO Group 是個「歡迎所有人與自身以技術、工具等方式交流」的團體,以期成功並有效地運營開源專案和方案。例如他們有推出完整的一套指南,將幾個最成功的 OSPOS 運營案例分享給各公司。
- CHAOSS (Community Health Analytics for Open Source Software) 社群發展出一整套評量開源專案經營之健全度與永續性的指標、方法與軟體。(關於 CHAOSS 相關社群與工作小組,詳見下文。)
OSPO 經理需要向公司其他部門會報 OSS 導入及釋出相關的許多事宜,例如:正在使用哪些專案?其健全度如何?管理者是誰?正在釋出哪些專案?如何處理社群的貢獻?、主要貢獻者是誰?
資料導向的 OSPO
戴明(William Edwards Deming)曾說:「沒有資料輔佐的人,提出來的想法都是片面的。」
有想法不是壞事,但如果想法是以資料為基礎的話,肯定更容易理解、討論,進而決定最適合公司和其目標的做法。 若想尋求評量指標和工具協助的話, CHAOSS 是不二選擇。
CHAOSS 社群近期推出了一套新的評量指標定義,不過只是以下各個工作小組(WG)處理事項當中的一小部分:
- 一般 WG:負責定義 (1) 多個 WG 所共同使用的 或 (2) 對社群健全度很重要,但並不適合其餘任一 WG的評量指標。關注組織關係、應對能力、地理涵蓋範圍等面向。
- 多樣性與包容性 WG:吸收與 OSS 多樣性和包容性相關的過往經驗,旨在從質、量兩方面了解如何量測多樣性和包容性。
- 發展進化 WG:負責改善與軟體實行之發展進化與行政事務相關的評量指標。
- 風險 WG:負責改善與軟體實行之風險與行政事務相關的平量指標。
- 經濟價值 WG:注重與開源業界之經濟價值標準相關的評量指標,旨在推出可信並符合業界標準的經濟價值評量指標。該指標會有點類似軟體開發界的標準普爾指數(S&P),也可說是指標重要性和業界準則的重要參照對象。
像 Augur 、 Cregit 和 GrimoireLab 這類的專案不只可以產出評量報表,還可以展示 OSPO 相關活動成果。這些專案也是 OSS 社群提供之工具和解決方案的基礎,例如 Cauldron.io 這種簡化 OSS 生態分析的軟體即服務 (SaaS)開源解決方案。
![]() |
CHAOSS 評量之 Unity OSS 15 年活動成果(來源:cauldron.io) |
缺乏良好評量策略的話,空有指標和資料也沒用。大家通常評量時會盡可能展開量測,而後產出多到數不清的報表和儀錶板,它們又被圖表和數據塞滿。這樣到底有什麼價值?
過往經驗顯示最有效的評量方式是「目標→問題→指標(GQM)」策略,但我們可以如何將其應用於 OSPO ?
首先,我們必須明瞭公司為何要使用、採購、推出、維護、貢獻於 OSS 專案。通常公司的目標都跟市場定位、所需之上游開發、吸引及留住人才等方面相關。基於上述目標,我們應該要寫下可用資料回答的一些相關問題,如下所示:
誰是我的 OSS 生態專案的主要維護人員?有幾位?
![]() |
Uber OSS 程式碼之核心、一般、偶然貢獻者的數量變化。圖源:uber.biterg.io |
人們以各種不同形式或工具(如程式碼、測試、提出問題或建議等)做出貢獻。分析出核心貢獻者(佔總貢獻的 80 %)、一般貢獻者(佔總貢獻的 15 %)和偶然貢獻者(佔總貢獻的 5 %)之後,不僅可以回答出這些貢獻者數量隨時間如何變化,也能得知貢獻者如何在這三種身分之間變化。結合組織關係相關資訊,則能進一步發現外部核心貢獻者。
貢獻在哪裡發生?
![]() |
Uber OSS 活動,依地點與時區分布呈現。圖源:uber.biterg.io |
OSS 生態系的成長也跟 OSS 專案遍及全球有關。懂得這件事之後, OSPO 和公司就能採取行動加以加強對不同國家和地區人民的支援。
自家公司的 OSS 網絡為何?
![]() |
Uber OSS 網絡。圖源:uber.biterg.io |
一家公司的 OSS 生態系也包括公司員工有為其做出貢獻的所有專案。了解員工們為哪些專案做出貢獻,就能更清楚哪些科技或 OSS 元件是他們感興趣的,以及自家公司正與哪些公司或組織協作。
自家公司如何處理貢獻?
![]() |
Github 的拉取請求待辦清單管理指數和運作存在時長分析。圖源:uber.biterg.io |
推出 OSS 專案的其中一個目標就是幫助相關社群成長茁壯。檢測自家公司如何處理專案相關的外部貢獻,可了解公司「受歡迎」的程度,也能發掘出講師(或瓶頸),降低可參與貢獻之門檻。
採購者 vs. 維護者
過去幾個月來我們一直耳聞,許多公司利用 OSS 卻並沒有做出相應回饋。常見的狀況是,這些公司靠著免費軟體賺得盆滿缽滿,但同時 OSS 專案的維護者卻因用戶不斷抱怨、要求免費支援而過勞。
整個系統嚴重失衡:一般情況下,使用者會比維護者多,但這到底是好是壞?軟體有人使用(理應)是好事,但我們必須兼顧使用者和維護者的期望。
從公司角度而言,採購 OSS 但不做出貢獻將帶來非常非常大的風險。
OSPO 的重要性在於,他們能提醒公司即將面臨哪些風險、以及如何透過回饋 OSS 生態系來降低風險。要記得,生態系能永續,公司才有機會永續。
一個不錯的策略是開始將公司從純 OSS 採購者轉變成貢獻者,為 OSS 導入專案做出貢獻。與其只是提出問題、回答問題、傳送修補程式,做出貢獻更能幫助專案成長與維護,同時也回饋社群。此過程並非一蹴可幾,但漸漸地,公司會受認可為 OSS 生態系公民的一員。最終,公司內某些人也可能會成為那些專案的維護者。
那麼資金呢?有很多金援 OSS 生態系的方式,以下列舉幾種:
- 公司自發活動,如 Tidelift 或 OpenCollective
- 基金與相關機制,如 Software Freedom Conservancy 或 Linux 基金會的 CommunityBridge
- 自籌基金專案(參考 Indeed 和 Salesforce 等案例)
- 募集散戶資金,如 Github Sponsors 或 Patreon
還有,各公司必須避免「非我所創」症候群。有些 OSS 專案可能有幾家公司提供諮詢、客製化、維護與(或)支援服務。與其只是使用 OSS ,投入大量時間和資源自行管控與客製化、或是將相關服務搬到內部執行,不如請上述公司代為執行思考工作,可以提高效率。
最後我想強調, OSPO 對公司於現存市場中成功並茁壯非常重要。 OSPO 就像是他們公司 OSS 生態系的牧羊人,對生態系的任務和發展最清楚,因此他們更該手握更高的管理、監測、推薦與決定權,公司才能成長、永續。
你的公司設立 OSPO 了嗎?