譯者：魏子杰
（本文翻譯自 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 了嗎？
