系列：開源是一種開發模式、商業模式還是其他什麼？（一）

“開源”一詞是在1998年由開放原始碼組織(OSI)舉行的戰略會議上提出的。OSI維護著開源定義(OSD)，它對任何聲稱是開源軟體的發行條款做出了規定。OSI還制定了一個符合這些準則的官方開放原始碼許可列表。

OSD給出了開源軟體的明確定義，但沒有提供太多關於開源軟體如何影響公司構建和人們需要的產品或服務能力的見解。換句話說，關於在開源基礎上建立企業的最佳方式，仍然存在巨大的爭議。

在這個由多個部分組成的系列的第一篇中，我將為理解什麼是產品，產品經理做什麼，以及如何將開源視為一個供應鏈奠定基礎。在以後的文章中，我將深入探討這些主題，但我將從剖析一些常見的、但從根本上說令人困惑的詞彙開始。

開發模式還是商業模式?

開源的採用在產品和解決方案中很常見，但這對產品團隊真正意味著什麼，還沒有定論。開源是一種軟體開發模式還是一種商業模式?即使在今天，在開源圈子裡也有巨大的爭論。

認為開源是一種開發模式的人強調協作、編寫程式碼的去中心化性質，以及釋出程式碼的許可。那些認為開源是一種商業模式的人討論了透過支援、服務、軟體即服務、付費功能，甚至是廉價的營銷或廣告來實現貨幣化。

雖然雙方肯定都有合理的論點，但這些模式都沒有讓所有人滿意。也許是因為在軟體產品及其實際構建的歷史背景下，我們從未充分考慮過開源。

與其把開源看作是一種開發模式或一種商業模式，也許公司應該從供應鏈的角度來考慮，從中來購買技術。

供應鏈包括建立任何產品或服務所需的組織、人員、活動、資訊和資源。這包括像羊毛大衣一樣簡單的產品，或者像一個有成千上萬個依賴關係的開源軟體專案一樣複雜的產品。經濟學之父Adam Smith在《國富論》中，描述了一件羊毛大衣的供應鏈：

“牧羊人、羊毛的分揀者、羊毛加工者或梳理者、染色者、塗鴉者、紡紗者、織布者、填充者、穿衣者，以及其他許多人，都必須加入他們不同的技藝流程中，以完成這種普通的生產。”

我們大多數人可能沒有聽說過一件羊毛大衣的供應鏈所涉及的角色，但有一點是顯而易見的：勞動分工和協作是健康供應鏈的關鍵，特別是在開源方面。

產品還是專案?

如果你接受開源是一個構建解決方案的供應鏈，這就導致了圍繞專案和產品的另一個誤解。紅帽公司的執行長Paul Cormier對開源專案和開源產品進行了務實的區分。

雖然我同意Paul的觀點，但我不得不承認，世界上大多數人並沒有認識到這種明顯的區別。在與客戶、合作伙伴、使用者、分析師、記者，甚至我自己的家人的談話中，大多數人都在交替使用專案和產品這兩個詞。

我將試圖透過提出一個簡單的定義來澄清：產品是人們用貨幣購買的東西，而專案是人們參與、貢獻或使用的東西。這就為更好的定義提供了部分途徑，但要真正理解，你需要定義什麼是產品，以便清楚地看到什麼不是專案。

軟體產品，像任何其他產品或服務一樣，有一系列的活動需要把它們推向市場。它們有商業計劃、定價和包裝、定位和資訊傳遞、分銷策略、銷售支援、組合調整、構建/購買/合作伙伴決策和路線圖。

管理這些產品的團隊進行焦點小組，分析潛在市場，向記者和分析師介紹他們的產品如何融入市場，帶領客戶瞭解路線圖。最重要的是，根據付費客戶的需求來定義這些路線圖。產品團隊花費了大量的時間和金錢來了解客戶的問題，但這很少是社群成員的工作成果。

產品團隊對他們在產品中使用哪些供應商有一個基本的選擇。這可能意味著在一個產品中使用兩個、三個、四個、甚至十個不同的上游專案。也可能意味著當上遊專案不再滿足購買產品的客戶需求時，就會切換到上游專案。

最後，它也可能意味著定位合作伙伴的解決方案或產品組合的不同部分，以填補客戶需求的空白。產品團隊也可以決定將開源作為供應鏈的一部分，將專有軟體作為另一部分，從而將產品與專案區分開來。他們甚至可以使他們的產品只作為一種服務提供;這就是定價和包裝的力量。

幾乎所有的產品都是透過向一組由供應商提供的商品元件新增一層差異化的價值而建立的。無論它們是建立在開放原始碼還是專有元件上。換句話說，上游供應商不能提供與下游產品相同的解決方案。

當上遊專案和下游產品處理完全相同的商業問題時，就會出現差異化程度很低的現象。這類似於上游供應商和下游產品公司都在銷售輪胎--上游供應商需要銷售輪胎，而下游產品公司則需要銷售汽車。

供應鏈元件和下游產品之間缺乏差異化，是開源公司遇到問題的地方。

每天，產品團隊都必須在付費客戶的驅動下做出定價、包裝、構建、購買、合作伙伴和路線圖的決策。這就是產品的差異化，也是它與社群驅動的開源專案的根本區別所在。

從開源供應鏈中購買

“Free”是言論自由的自由，而不是免費啤酒的免費。任何人都可以下載和使用開源軟體，但只要你出售使用開源的產品，你就必須對客戶負責。這種責任包括檢查軟體是否打過補丁，是否安全，是否執行良好。一個產品團隊對客戶有承諾，並對供應鏈中選擇的每個部分負責。

換句話說，在開源軟體上構建一個產品並不是免費的。它需要花費時間或金錢。因此，用 "購買 "這個詞來描述產品團隊和為這些產品提供技術的上游開源專案之間的關係，是正確的。

從產品團隊的角度來看，每個上游專案都可以被認為是一個供應商。產品團隊可以透過貢獻工程師、文件編寫者、測試人員等的時間和精力來向開源供應商“購買”。由於時間就是金錢，花在上游工作上的每一個小時都可以用美元來衡量。

無論你的企業是銷售基於開源的產品，還是構建供內部使用的解決方案，都存在從開放原始碼供應鏈消費的成本。在開源基礎上構建任何東西，都隱含著對所選擇和使用的元件的責任。但是，與傳統供應鏈不同的是，1美元可能不是1美元。

在開源供應鏈上投資的每1美元可能會換回2美元、3美元，甚至10美元的價值回報。投資回報可能更高，因為其他人和公司也在貢獻價值，以及多樣化的想法。從開源供應鏈上消費的每個人都繼承了總價值。如果社群是健康的，那麼所獲得的價值就會遠遠超過所做的貢獻。

從開源供應商那裡採購還有一個隱藏的好處。與傳統供應商不同的是，社群驅動的開源專案不是利潤驅動的實體，沒有銷售、營銷和進入市場的成本。這類似於從非盈利實體購買，但再次強調，它不是“像免費啤酒一樣的免費”。從開源供應鏈採購，並向你的客戶提供產品，肯定是有成本的。

一個更好的產品比喻

也許從來沒有人認為開源是以產品為中心的，因為它是與網際網路和網路公司的繁榮一起成長起來的。這是一個在沒有太多商業計劃的情況下，就把資金扔給想法的時代。試圖應用傳統的業務理解，導致了對開源與開放核心的定義，以及產品團隊的角色和責任的爭論。

眾所周知，軟體行業，尤其是開源行業，在產品管理和上游工程的配合上一直感到困惑。專案和產品之間的模糊界限甚至導致了對上游專案應具備的功能上的誤解。

作為推動世界上最大的開源產品Red Hat Enterprise Linux路線圖的產品團隊的一員，我想謙虛地提出一個新的正規化來思考開源軟體:開源是一種供應鏈模式。

這不是一個巨大的智力飛躍，但這對思考利用開源產品的討論、辯論和認知負荷有深遠影響。

利用開源獲取價值

近年來，有人提出了這樣的論點，斷言永遠只能有一個紅帽公司。這種說法意味著只有一家公司可以透過銷售支援而發展成為數十億美元的企業。這種說法是有問題的，因為紅帽並不靠支援賺錢，甚至可以說，紅帽網路是開源的第一個SaaS。

其次，其他公司，如SUSE、Cloudera和Chef，已經獲得了相當大的價值。最後，許多企業從SaaS模式開始，延伸到鄰近的企業內部業務，如CloudBees。

所有這些企業都能夠成功地將開源作為供應鏈來創造價值，同時透過滿足上游專案無法單獨解決的複雜業務問題來獲取價值。從根本上說，SaaS和硬體/軟體的組合沒有什麼不同，儘管可以說它們更容易實現貨幣化。

各位產品經理，我建議你們開始考慮將開源專案作為你們產品的供應鏈。它將使你在做出產品驅動的決策時有新的明確性，並關注業務需求而不是技術。在所有的供應鏈中，產品經理必須公平地對待他們的供應商。

例如，下游的產品團隊不能告訴上游的供應商該怎麼做。下游產品團隊還必須向供應商支付足夠的費用，以保持他們的業務並繼續提供技術。這只是兩個例子，說明把上游的開源專案當作供應商來對待，可以使雙方的關係更加健康。

音樂界有一句話：關鍵不在於你演奏的音符，而在於你不演奏的音符。約束力孕育著創造力。如果你知道你不能根據上游供應商的程式碼來區分你的產品，你的產品團隊就必須要有創造力。你必須找出其他值得購買的價值。我將在本系列文章的後面挖掘這個問題;在下一篇文章中，我將對什麼是開源產品以及如何用它創造價值的範圍進行補充說明。