當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

文末有彩蛋 | 第四周课程回顾与总结

發布時間：2023/12/4 编程问答 37 豆豆

生活随笔收集整理的這篇文章主要介紹了文末有彩蛋 | 第四周课程回顾与总结小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

我們在前三周的課程上（第一周、第二周、第三周），系統講授了 FOSS 和 COSS 的課程內容，第四周，我們開始進入 OSPO（開源項目辦公室）的部分。

本導學班在調研全球開源教育與課程的基礎上，通過收集、整理、理解、拓展國際最新的前沿開源課程，采取眾創的模式，由 X-lab 核心開源研究的成員共同進行協作學習，以最大效率的吸收國際前沿開源知識，共創、共享、共進。本導學班，以開源 FOSS 和開源 COSS 課程內容為基礎，結合自己的理解，并進行適當拓展。

第四周的系列課程圍繞以下七塊內容進行：

開源介紹

開源商業戰略

有效的開源項目辦公室 (OSPO) 管理

開源開發實踐

開源許可與合規

了解上游開源項目

創建開源項目

一、開源介紹

開源軟件的誕生源生于自由軟件運動，實用主義和理想主義是現代開源在公司業務和戰略的關鍵組成部分。開源社區的構建可以追溯到計算機的早期，植根于學術/企業/共享/黑客心態。幾乎所有社區都具有以下幾個主要特征：去中心化、透明度和任人唯賢。社區往往表現出緊密的垂直層次結構和松散的水平結構，如下圖所示。雖然公司內部也可以運用這些“敏捷”原則，但和企業不同的是，開源項目呈現不同的組織結構模式 —— 不以職位論英雄，異步溝通和決策透明。

企業使用開源可以提高速度、降低成本、提高可定制性、加速創新并形成差異化壁壘。因此本系列課程將重點介紹企業通過 OSPO （開源項目辦公室）更好的涉及開源。

二、開源商業戰略

有兩種主流的圍繞開源的商業模式——使用開源的公司（大多數），和主要生產開源的公司。也就是對開源的消費和生產。

先看消費。Gartner的研究表明，一流的軟件和技術組織使用的80%的軟件來自開源，基于這些開源組件構建剩余 20% 的附加組成構成產品。因為這樣可以使企業把有限的精力和資源集中在差異化業務上，同時與開源生態系統的其余部分分擔通用代碼的開發成本。

再看生產。對開源的生產通常分為以下幾種類型：

許可??這種模式依賴于商業許可和開源許可下的雙重許可軟件，通常會產生產品的“社區版”和“企業版”，客戶根據需要的功能來選擇對應的產品。

托管??公司在云托管的SaaS（軟件即服務）中提供開源產品，如 AWS 和 Google Cloud。

支持??企業希望利用開源提供的技術創新，但更關心在開源產品上運行業務。如 RedHat 和 IBM 等公司會提供支持、技術指導、專業服務和培訓，來幫助企業在開源平臺上運行業務應用程序。

OpenCore???一個功能強大的核心產品是免費和開源的。圍繞這個核心，商業實體提供閉源軟件以增加或拓展其功能。也可以與支持模型結合來提供培訓和技術支持。

作為一個公司，制定實用的開源戰略時，要先想清楚三個問題：

公司希望在哪里使用開源？
使用開源實現了哪些業務目標？
公司如何確保誰先開源業務目標？

典型的開源之旅有幾個落腳點：消費，參與，貢獻，領導。公司在開源中扮演不同角色時，需要制定的戰略也不相同，如下圖所闡述的，如果某個開源項目是你公司的產品或技術需要用到的核心元素，這時候對應的就需要去考慮成為積極參與者，甚至去引領這個項目。另外需要注意的是，公司在某一個開源組件中的參與程度會隨著時間而改變，需要定期（典型周期為半年到一年）審查開源策略，根據業務或經濟狀況調整參與度。

三、有效的開源項目辦公室 (OSPO) 管理

開源項目辦公室（OSPO）是一個是企業明確制定和執行開源戰略的地方。它旨在成為公司開源運營和結構的中心，支持、培育、貢獻、解釋和發展開源，這可以包括設置代碼使用、分發、選擇、審計等，以及培訓開發人員、確保法律合規性和促進和建立社區參與。

OSPO的主要職責包括：

清楚地傳達公司內外的開源戰略
監督戰略的執行
促進開源在商業產品和服務中的使用
確保向開源社區高質量和頻繁地貢獻代碼
與開發者社區互動并有效地回饋項目
在組織內培養開源文化
維護開源許可證合規性審查和監督

當然也不是所有 OSPO 都需要具備以上全部功能，這更多取決于公司的業務需求。從下圖可以看出，在與開發者協作以外，OSPO 還需要支持非常多的非開發活動，像公共關系協作，開源法務合規，制定策略，與社區的交互和參與等。

建立一個有效的 OSPO，需要先考慮從哪里開始，可以是自上而下，得到高層管理者的支持；也可以是自下而上，由一小部分開發人員和開源愛好者發起。無論如何開始，一個合適的領導者至關重要，這個角色需要對公司的業務了解深刻，擁有商業敏銳度和管理技能，并需要能夠談論深層技術。

下一步，就是建立結構化的政策和流程，同時保持一定的靈活性。

OSPO 的結構??OSPO應該在工程部門，還是在法律部門、CTO 辦公室或其他特定業務部門？這同樣取決于公司的主要業務和開源戰略。這里有一些常見的位置供參考：

對于擁有大量知識產權組合的公司，前期會選擇在法律部門設置 OSPO 來解決合規問題
工程驅動的公司通常選擇在工程部門建立 OSPO，report to CTO 或 CIO
有些公司選擇營銷組，作為開發者關系/營銷的一部分

OSPO 的人員??對應的，OSPO 的角色由開源項目經理，法律團隊，合規團隊（核心團隊為開源審查委員會 - OSRB），開發者關系、宣傳和布道者組成，還有一些其他工作角色，如工具管理員，培訓經理，工具和系統集成開發人員，部署支持人員和實施項目負責人。

OSPO 的流程? 配備了角色之后，下一步就是明確政策和流程。政策應該列出公司范圍內使用開源的要求和規則，并記錄可執行的流程，來確保規則得到了遵守。流程需要確保最少的開銷，并不斷質疑和更新規則以簡化程序。公司要準備好隨著時間的推移，業務的變化以及開源項目的成熟和發展，修改規則和程序。

四、開源開發實踐

開源軟件開發和傳統軟件開發中的 “Waterfall” 模型有很大不同。拿需求收集來舉例，開源開發中需求通常是來自用戶或開發者的“功能請求”，并且由于開發的迭代/敏捷性更強，不存在長期的需求階段。這種方法需要應對不斷變化的需求并對項目運營所在的技術和業務環境做出快速響應。

成功的開源開發工作的一個標志就是能夠根據可用的參與量有效地擴展項目（可擴展的開發模型），隨著小型項目發展成中型到大型項目，它們會執行更嚴格的發布周期，增加維護者，并對子系統進行進一步劃分。可以參考世界上最成功的開源項目之一——Linux Kernel，它有一個嚴格執行的發布級別，和專門的維護集（LTE分支）。這種開發模型的一個關鍵要素是，通過將不同項目子系統的責任委托給“維護者”來發揮作用，“維護者”對子系統中的代碼負有最終責任。這允許一定程度的專業化和監督，使整個項目維護者能夠專注于項目的更大戰略和架構圖。

公司參與開源時，其實是要去和大型分布式開發團隊進行協作，而這種協作方式和公司內部嚴格的開發活動略有不用。沒有兩個社區是完全相同的，社區也不適用于個別公司。所以一定要了解社區，了解它是如何治理和溝通的，然后去溝通、參與、回饋，并計劃好適當的退出策略。（如果需要的話）

內源? ?內源是指“使用開源軟件開發最佳實踐，并在組織內建立類似開源的文化。該組織可能仍然開發閉源軟件，但在內部開放開發”。內源實施非常強調開源的文化部分，除了簡單采用開源開發實踐以外，在組織內部建立更開放和透明的文化才能發揮內源的全部好處。

五、開源許可與合規

許可證是開源分發的關鍵概念。公司在使用開源項目時，許可證合規是一個非常關鍵的避免風險的策略。開源許可證如下圖展示的，主要分為寬松許可證，如 MIT、BSD ，和互惠許可證，如GPL、AGPL。公司必須了解自己使用到的開源組件涉及到哪些許可證，并且在發布產品時履行許可證義務，所以開源合規計劃整體分為兩塊：了解義務，履行義務。

可能會觸發許可證義務的場景是對一個開源組件的修改和分發。

下圖是公司進行合規管理時的典型實踐，對于入站的開源組件（可能是自己開發的軟件，第三方軟件或專有軟件）：

首先需要識別他們
識別之后，對源代碼進行審計，得到審計報告
審查小組對審計報告進行審查，解決報告中的問題
批準使用
一旦某個開源組件被批準在產品中使用后，需要被登記到產品清單中，并在跟蹤系統中注冊
準備一份聲明（Notice）
驗證和分發，提供隨附的（需要開源的）源代碼，對應的版本

這個過程不可避免的需要依賴工具，例如源代碼掃描，許可證掃描，二進制包掃描，集成工具，組件管理工具等。這里有兩個行業優質項目：

SPDX，提供了標準交換數據格式的工具，spdx文檔的內容是標準格式的軟件包、包級別、文件級別和版權信息等內容，這種更加通用的格式可以幫助降低掃描合規性時的復雜度。
OpenChain，提供了一個規范和認證計劃，涉及源代碼、構建腳本、許可證副本、歸屬通知、修改通知、SPDX 數據和其他管理軟件可交付成果的開源許可證可能需要的材料的供應鏈交換。

公司在進行并購交易時通常需要進行審計，對于特別是軟件公司，開源審計流程和傳統審計有一定不同。進行開源審計是為了了解目標公司對開源軟件的使用深度和依賴程度。同樣，輸入是一些可能的開源組件，輸出是一份物料清單（BoM），包含完整的開源組件來源，許可證，以及聲明。

審計可以分為傳統審計和DIY審計，傳統審計是第三方審計公司的人員通過遠程訪問或現場訪問源代碼執行審計，并給出審計報告；DIY審計是收購方或目標公司自己運行掃描工具，這種方式更加靈活，但一般需要企業內部有經驗豐富的員工能夠解釋掃描結果和提出修補建議。

六、了解上游開源項目

上游作為名詞，是指衍生品所基于的原始開源軟件項目；上游作為動詞，是“將更改推送到上游項目”的簡寫方式，即對源代碼所做的更改貢獻回原始項目。

如果在供應鏈的背景下考慮上游，它會是這樣的：

為什么公司要對上游項目做貢獻？只消費而不回饋似乎看起來更容易，但是貢獻回上游可以讓其他人知道所做的變更，并且圍繞變更進行規劃，同時降低自己的代碼意外損壞的風險，減少構建成品的工作量，甚至有機會影響你所使用的開源項目的未來方向。

那么什么時候應該貢獻上游？

當保持代碼與上游項目同步的成本（時間或金錢）超過單獨工作的便利性時
當你希望其他人（包括客戶）使用你的代碼時
當你希望你的代碼成為事實上的標準，或推動主線項目時
如果你預計在即將推出的產品中重復依賴某個代碼庫來補充上游項目

上游開源項目使用的治理模型有多種，因集權程度、組織實體的影響程度以及民主式決策機制和領導力選擇而存在差異。沒有一刀切的模型，不同的項目可能適應于某種特定的模式。我們可以看幾種例子：

公司主導的治理，如Google Android，RHEL
仁慈的獨裁者，最典型為Linux內核
理事會，如FreeBSD，Debian
基金會/財團，如Open Stack，Kubernetes，Academy Software Foundation

與上游進行合作時，我們一般采用“上游優先”的理念，然后制定有效的貢獻政策，這些政策應該更多是幫助人們成功地為開源項目作出貢獻，特別是對于新貢獻者。貢獻政策還應預定義上游項目使用的已批準的開源許可證列表。

上游社區可能還需要其他類型的與代碼無關的支持，這時可以參考上述治理模型，可以選擇以公司會員的形式贊助項目或者負責該項目的基金會。這些資金可以幫助項目取得成功，并且在某些情況下，還能幫助公司本身更多地參與咨詢角色或對項目產生一些影響。

七、創建開源項目

公司要創建開源項目，第一步需要了解這樣做的價值主張是什么——有成千上萬個開源項目，你的代碼是否提供差異化的價值，還是能讓一個成熟且成功的項目變得更好？其次是衡量在開源中的投入，不是簡單的將代碼扔出來，卻不考慮內部財務和工程投資。

下圖列舉了創建開源項目的適當理由和不好的理由：

你需要為你的新項目做好準備，確定相關的執行負責人，適當的給他分配資金。還有很重要的一點是，需要對員工進行培訓，不只局限于對宏觀開源的培訓，還需要讓工程師和產品經理意識到一些可能與他們日常構建產品或評估方式的不同之處。

下一步是對要開源的項目進行審查，包括法律審查，技術審查，這兩塊我們在合規工程中講過；此外還有營銷審查，為項目品牌建立指導方針；然后就是建立合適的治理模式和流程，包括社區架構，領導力，基金會的選擇等等。

項目成功啟動之后需要持續的維護，這就需要借鑒典型的成功的開源項目的運作模式了。你需要建立起一個社區，維護多元化的貢獻者群體，這也意味著企業需要有更多資金投入，以及內部開發者的投入，這些投入可以依靠項目的重要性來決定。

一般來說，可以聘請社區倡導者（有時也稱為社區經理）來幫助新的開源項目取得成功，這是個非常有挑戰性的角色，此外，也不要忽視技術作家、項目經理，甚至社會學、心理學等非傳統研究領域的人。

以上就是第四周課程的總結。自此，我們暑期為期一個月的開源軟件通識基礎課程到此結束，希望能夠和大家繼續保持互動，一起來聊開源。

我們接下來會進行短暫的休整與總結，開始新一輪的迭代。從新學期 9 月份開始，我們將繼續推出新的一期開源通識課程，目的性也會更加明確，我們這里可以簡單劇透一下。

為了保證課程質量與大家的專注度，新一期的課程準備采取定向邀請的形式進行招生（互聯網企業、開源初創公司、開源基金會、高校、開源投資機構等），規模預計 60 人左右。

根據目前的反饋來看，開源運營的視角是大家需求最為迫切的地方，我們也考慮從這個角度來切入，小伙伴們不要錯過，有興趣的可以給我們留言，歡迎加入我們～

本文為 ?X-lab開放實驗室 ?原創文章，遵循CC-BY 4.0協議，轉載請附上原文出處鏈接及本聲明。

文中部分圖片源自：https://nythesis.com

總結

以上是生活随笔為你收集整理的文末有彩蛋 | 第四周课程回顾与总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。