由 TODO Group 出品
原文鏈接：
https://github.com/todogroup/ospology/tree/main/ospo-model/en
本文由 vivo 互聯網 OSPO 成員整理翻譯， 目前已提交貢獻至上游。
vivo 作爲 TODO Group會員，推動了 TODO Group官網中文版的發佈，並基於全球同行共識，翻譯發佈了 OSPO 定義2.0、OSPO 思維導圖。
OSPO（Open Source Program Office）：開源項目辦公室，被視爲開源治理的最佳實踐。
組織 OSPO 模型分類標準
我們希望這是一份動態文件，旨在建立 OSPO 模型的分類標準並確定有助於不同組織學習和實施的關鍵組件（模式）。
社區可以對五階段 OSPO 成熟度模型進行顛覆式貢獻，以更好地滿足特定垂直行業和/或地區的需求。
OSPO 模型 1 —— 五階段 OSPO 成熟度模型
隨着 OSPO 的激增和普及，這些專項也日趨成熟。通過把 OSPO 領導者和專家的對話與 OSPO 調研結果相結合，我們建立了一個 OSPO 成熟度模型，以描述 OSPO 的典型演進過程。
請注意，一刀切並不適合所有情況。
事實證明，該模型在那些最初沒有傳統上在其日常運營中實施開源的環境中效果更好。
此外，組織的規模和類型也會影響 OSPO 的成熟程度。在規模較大的組織中，多個業務部門可能會制定不同的開源策略，每個部門都有不同的技術文化；而純數字化的技術公司更有可能在早期消費 OSS 併爲其做出貢獻，也更有可能接觸到開源技術和理念。
揭祕 OSPO 模型
此外，每個階段都是累積性的。這意味着，在跨級推進時，OSPO 也要承擔上一級的任務和責任。
例如，一旦 OSPO 涵蓋了與開源合規和安全（級別 1）相關的所有必需任務，該 OSPO 可能已準備好遷移到級別 2。現在，該 OSPO 應該負責第一級的開源法律責任以及與傳播 OSS 文化和生態系統參與（第二級）相關的法律責任。
0
階段 0：臨時採納開源
如今，幾乎所有的組織都在使用 OSS。他們採納和開始使用 OSS 的方式各不相同。他們可能將 OSS 作爲產品或工具中的模塊或類庫，或者作爲供應商產品棧的關鍵部分，或者支持供應商提供的服務。開發人員可能將 OSS 用於快速原型開發或微服務和小型應用程序。開發人員還經常採用 OSS 開發工具，如集成開發環境（IDE），或構建在 GitHub 和 GitLab 等開源平臺之上的工具。現代雲原生應用幾乎默認使用開源系統進行容器編排、可觀測性、數據存儲、消息通信等。對於前端應用程序，開發人員非常依賴開源庫和框架。RedHat 報告稱，“90% 的 IT 領導者都在使用企業級開源”。Synopsys 等軟件成分分析供應商表示，超過 75% 的代碼庫包含開源組件。
換句話說，幾乎每個組織都在使用開源。然而，最早的採用形式是臨時性的，由開發人員使用現成的工具和技術解決問題。這種“臨時採用”通常意味着很少考慮默認情況之外的許可證合規，也很少考慮使用開源和分發使用開源組件構建的產品的長期影響。在大多數情況下，少數工程師會積極尋求開源，而工程團隊的其他人員可能會偶然使用開源，但不會將其活動視爲依賴開源。因此，企業既沒有一個專注於開源的集中式團隊，也沒有爲企業制定最高級別的開源戰略。這些都是至關重要的，因爲一旦採用，這些開源組件就會默認成爲組織軟件供應鏈的一部分，這就更有必要採取戰略措施。
1
階段 1：提供 OSS 合規、清單和開發者教育
一般來說，當一個組織意識到其員工正在使用開源產品和代碼，幾乎涉及所有工程和開發部門及職能部門時，就會組建一個 OSPO。這種使用通常是內部使用，而不是作爲向客戶或用戶提供的產品或服務的一部分。實際上，任何擁有大量 IT 服務能力和先進的在線系統或應用程序爲中心的組織都會使用開源，因爲開源在整個技術棧中無處不在，從 Linux 服務器和 MySQL 數據庫到 NodeJS 和 Python 等編程語言以及 React 和 Vue.js 等前端框架。
在這一早期階段，各組織通常爲 OSPO 使用許多不同的名稱。例如，IBM 公司最初將其計劃性開源工作稱爲 "開源指導委員會"。不過，在所有情況下，處於第一階段的組織都認識到 OSS 是其業務和技術戰略的重要組成部分。他們知道 OSS 項目的安全實踐與專有軟件公司的不同。例如，OSS 項目的披露規則往往比專有項目的披露規則更嚴格。因此，他們必須明確自己的法律和安全風險。降低風險的策略包括謹慎許可、開發人員教育和嚴格盤點。
管理法律風險和許可
一個組織的法律團隊或技術領導往往會啓動 OSPO 的第一階段的推進工作，以確保其員工（以及承包商、供應商等）都按照許可條款使用 OSS ，並確保該組織的 OSS 消費不會使其面臨法律風險。目前使用中的 OSS 許可證有幾十種。在 2020 年的調查中，受訪者將合規性列爲大型企業 OSPO 的最大收益，而合規在中型企業仍然是第二大收益。公司一開始通常會有很多困惑。
儘管 OSS 用戶一直在考慮法律合規性，但一些 OSS 貢獻者還是設計了新的許可證，以阻止大型雲提供商基於開源項目創建專有服務。其中最著名的是 Affero 通用公共許可證 (AGPL)。公司可以使用根據該許可證條款發佈的 OSS 向客戶提供專有軟件即服務（SaaS），但如果 AGPL 條款沒有明確區分內部和外部交付，OSS 的創建者可能有理由起訴公司違反許可證規定。許多企業還在業務單元之間建立了內部財務結算系統，進一步模糊了付費服務和內部服務之間的界限。
教育開發者
爲保持合規性，處於 OSPO 成熟度第一階段的組織應制定教育計劃，幫助其開發人員在創建新產品或服務時決定何時使用開源軟件。“許多沒有接受過開源教育的開發人員認爲，因爲他們沒有購買軟件，所以不涉及許可證，因爲他們沒有簽署合同。” VMware 公司開源營銷和戰略總監 Suzanne Ambiel 說，“開源軟件可能是免費的，也可能是無價的，但如果以不合規的方式使用，成本也可能很高。[OSS] 始終附帶許可證。任何 OSPO 最重要的職責之一就是確保開發人員瞭解選擇不同許可證的影響。”
通過開發人員教育，高層管理者往往會承認開源軟件的價值和重要性。在這些項目中，開發人員可以學到：
不同許可證類型的細微差別
引入新的開源軟件產品的正式審批程序
消費不合規開源軟件的實際風險，包括使用來自項目的開源軟件產品或沒有正式許可證的代碼
-
使用貢獻者許可協議 (CLA) 來覆蓋爲開源做出貢獻的組織開發人員
有時，組織會在這一階段引入正式的 CLA 政策。作爲決定在組織的技術棧或基礎設施中使用哪些開源軟件的標準的一部分，它還可能爲判斷開源軟件項目的健康狀況提供指導。
盤點軟件清單
開發人員可能會臨時部署開源軟件，而不對該工作進行系統地歸類。法律團隊和技術領導層傾向於推動編制組織內在使用的所有開源軟件清單。這種清單將組織代碼庫（如 GitHub、GitLab）和系統中的開源軟件逐項列出。階段1的組織建立了特定的軟件清單流程，以創建全組織範圍的軟件物料清單（SBOM）。有了這份清單，法律團隊（通常與 OSPO 團隊合作）就可以持續監控開源軟件的使用情況，並提示法律、安全或其他項目風險。有了詳細的 SBOM，首席技術官（CTO）或首席信息官（CIO）等技術領導層就可以識別並密切監控最關鍵的業務用途，維護組織安全。
本階段建議參與的 OSS 社區列表
|
橫向技能 |
項目 / 社區 |
|
合規 |
Open Chain |
|
安全 |
OpenSSF |
|
|
SPDX |
2
階段 2：佈道 OSS 應用和生態參與
在組織認識到 OSS 的價值以及合規、教育和 SBOM 的需求後，他們開始意識到 OSS 使用的經濟效益並尋求擴大它。第二階段的 OSPO 創建了相關的內部機制，如推廣使用經批准的 OSS 產品的大使、良好 OSS 健康教育計劃以及 OSS 技能建設和認證的技術培訓或學費報銷等。通過這些舉措，組織可以加強對 OSS 的應用並進一步強化：OSS 不僅重要，而且比專有軟件產品更理想、更可取。
員工教育包括制定與 OSS 項目交互的最佳實踐，例如如何請求功能、提交錯誤報告和貢獻基本代碼。在此階段，組織增強其協作能力並體驗 OSS 項目和社區的社交生活。此時，OSPO 向員工和管理人員傳達貢獻而不僅僅是消費 OSS 的重要性。這種外聯活動包括倡導和推動活動贊助、預約項目領導和維護人員作爲公共編程論壇的發言人或小組成員，以及確保組織資源（如人才、資金）用於關鍵任務的 OSS 項目。
對於組織來說，積極和看得見的參與會產生多種好處：更好的知名度、更好的聲譽、更具吸引力的僱主品牌。爲此，許多非科技組織購買展位，參加重要的 OSS 活動，與這些社區進行更多互動，並招募喜歡在 OSS 生態系統中工作的開發人員。活躍於開源領域的技術公司可以將教育計劃擴展到想要與 OSS 社區和供應商互動的客戶。
隨着進入第二階段，組織開始激勵開發人員參與對其運營至關重要的 OSS 項目，從而使開發人員成爲高度活躍的貢獻者或主要維護者。對於技術組織而言，僱用一個著名的 OSS 項目的貢獻者是一項有價值的投資：他們中的大多數貢獻者，比如 Linux 內核—— Linux 操作系統的核心組件以及計算機硬件和軟件之間的關鍵接口——的貢獻者都是全職員工 (FTE)，其工作是爲 Linux 編寫代碼。
在技術領域之外，很少有組織能夠分配全職員工從事開源工作，但他們正在這樣做。例如，康卡斯特和彭博社都有員工全職從事 OSS 項目。在生命週期的這個階段，OSPO 開始探索如何簡化開發人員使用 OSS 的流程。這種開發人員效率可能包括簡化 CLA、將具有可接受許可證類型的 OSS 添加到工單系統以實現快速審批、促進 OSS 架構和軟件的就地重用（內部採購的變體）以及標準化庫選擇和開源開發工具，從而混合 OSPO 和平臺運營職責。
通常在 OSPO 成熟度週期的第二階段（或者有時在第一階段，如果是一家軟件或技術爲核心的公司的話），OSPO 開始爲其開發人員簡化和優化對外開源的貢獻流程。對外參與的請求和獲得批准的過程在早期通常是臨時的且痛苦的。
本階段建議參與的 OSS 社區列表
|
橫向技能 |
項目 / 社區 |
|
社區健康與指標 |
CHAOSS |
|
內部開源文化 |
InnerSource Commons |
3
階段 3：發起開源項目和發展社區
在第三階段，組織發起並主導 OSS 項目或充當其主要發起人。他們將爲一個項目投入一名或多名全職員工（FTE），並承擔培育項目社區並確保其健康發展的責任。他們不會將這種級別的組織承諾與決定開源其項目的員工個人混淆。在第三階段，組織領導者支持在公共領域孵化和啓動開源項目，因爲他們瞭解這些項目如何使他們的組織受益。此類項目往往會在關鍵能力方面提供更好的業績和經濟效益，這些能力可能不是組織價值主張的核心，但對其技術基礎設施至關重要。
此外，創建和啓動開源項目的組織在開源社區中建立了廣泛的信譽；從事開源技術的可能性對許多開發人員來說很有吸引力。我們採訪的大多數 OSPO 都將招聘新的工程人才和保留現有人才視爲開源工作的關鍵動機。
用 FTE 和資金支持項目是開源遊戲中真面目。跨越這一門檻併成功啓動多個開源項目的組織會開發內部資源和流程，以孵化並確保這些項目啓動後的成功。OSPO 不僅僅是項目形成和啓動的守門人和導師；他們向項目創建者提供教育培訓，幫助其瞭解健康的開源生態系統的要求，並指導項目負責人爲他們擔任 OSS 項目所需的更公開的領導角色做好準備。
隨着 OSS 組織的成熟，其 OSPO 會開發內部流程、行動手冊、清單、工具和其他機制來審查、組織和運營開源項目，並培養和指導其領導者。一些 OSPO 更願意在主要開源基金會或 TODO Group 等協作機構的協助下啓動項目，以增強能力或提供基礎設施、戰術援助和其他資源。這種選擇需要的資源較少，但會將項目的控制權讓渡給更廣泛的社區。
本階段建議參與的 OSS 社區列表
|
橫向技能 |
項目 / 社區 |
|
社區健康和指標 |
CHAOSS |
|
特定項目與傘式基金會 |
Linux 基金會 |
|
|
CNCF |
|
|
Eclipse 基金會 |
|
|
Apache 基金會 |
4
階段 4：成爲戰略決策合作伙伴
在這一成熟階段，OSPO 成爲技術決策的戰略合作伙伴，幫助指導選擇並形成對項目的長期承諾。在第四階段，CTO 和其他技術領導者會向 OSPO 及其領導層諮詢應依賴哪些開源技術以及在判斷開源項目時使用哪些決策標準。由於主要的開源技術選擇往往會產生大量的二級和三級成本，並影響上下游技術以及招聘計劃，因此開源項目的選擇成爲一項重大的業務決策。
從廣義上講，OSPO 在第 4 階段提供三種類型的戰略指導。
首先，OSPO 就應採用或從組織的技術棧中刪除哪些開源技術向 CTO 和技術領導層提供建議。鑑於當今 OSS 選項衆多（大多數主要軟件類別都有數十種選擇，如圖 2 所示），OSPO 可以提供對 OSS 趨勢的洞察，例如不同語言的流行程度、API 設計或不同 NoSQL 數據庫的功能。在此角色中，OSPO 成爲 CTO 的內部技術顧問和 OSS 的內部專家。
在第二種類型的戰略指導中，OSPO 率先對可接受的 OSS 項目的構成進行基準測試。OSPO 經常評估項目的行爲和表現，特別是限制使用的許可證類型的變化，或項目路線圖的突然變化，以確定項目管理者是否考慮到社區的最大利益。大多數 OSPO 依賴於粗略的信息評估項目行爲的指標，比如：
它使用哪種類型的許可證？
它的行爲準則是什麼？違反它的後果是什麼？
其治理結構是什麼？該結構能否確保獨立性？
響應 PR 或錯誤報告需要多長時間？
該項目發佈新版本的頻率如何？
項目是由一方（公司或組織）還是整個社區控制的？
-
該項目有多少貢獻者？隨着時間的推移，這個數字的變化趨勢如何？
第三類指導是幫助組織理解和駕馭項目政治，例如當多個有影響力的參與者試圖引導項目時保持中立立場，或者闡明社區成員潛在的政治考慮。在更高層面上，OSPO 可以幫助公司在技術民族主義問題上保持中立姿態，並通過培養超越國界和政治領域的個人和工作關係來彌合政治分歧。這種價值越來越多地延伸到基金會和非營利組織的工作中，因爲這些領域成爲開源中非常重要的中立空間。
本階段建議參與的 OSS 社區列表
|
橫向技能 |
項目 / 社區 |
|
社區健康和指標 |
CHAOSS |
|
特定項目與傘式基金會 |
Linux 基金會 |
|
|
CNCF |
|
|
Eclipse 基金會 |
|
|
Apache 基金會 |
OSPO 檢查清單
根據 OSPO 五階段成熟度模型，本清單可幫助從早期階段到經驗豐富的 OSPO 指引每個 OSPO 階段及其任務。OSPO 檢查清單可在"OSPO 研究的演變" 中找到。
階段 1
定義項目品牌（如 OSPO、開源倡議、開源運營負責人）。
管理法律風險和許可證，創建新的流程和文檔，以確保員工根據其許可證條款使用 OSS，並且組織消費 OSS 不會使其面臨法律風險。
創建教育計劃，幫助開發人員決定何時使用 OSS 來創建新產品或服務。
建立特定的軟件庫存流程，以創建全組織範圍的軟件物料清單 (SBOM)。
總之，要認識到 OSS 的價值以及合規、教育和 SBOM 的必要性。
階段 2
列出與 OSS 項目交互的最佳實踐，例如如何請求功能、提交錯誤報告和貢獻基本代碼。
向員工和管理者傳達貢獻 OSS 而不只是消費 OSS 的重要性（包括倡導和推動活動贊助、在公共技術論壇上預約項目負責人和維護者作爲演講者或小組成員，以及確保組織資源用於關鍵任務 OSS 項目）。
激勵開發人員參與對其運營至關重要的 OSS 項目，使其成爲高度活躍的貢獻者或主要維護者。
階段 3
發起和領導 OSS 項目，或者作爲其主要贊助者。
創建並啓動開源項目，在開源社區建立廣泛的信譽。
爲項目配備一名或多名全職員工，並承擔起培育項目社區和確保其健康發展的責任。
開發內部流程、操作手冊、檢查清單、工具及其他機制，以審覈、組織和運營開源項目，並培養和指導其領導者。
階段 4
成爲技術決策的戰略合作伙伴，幫助指導選擇並形成對項目的長期承諾。
向 CTO 和技術領導層提供建議，說明應採用哪些開源技術，或從組織的現有技術棧中刪除哪些開源技術。
牽頭制定可接受的 OSS 項目的基準。
幫助組織理解和駕馭項目政治。
更多內容：
vivo 正式加入 Linux 基金會旗下 TODO Group
本文分享自微信公衆號 - vivo互聯網技術（vivoVMIC）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。