Open Source v.s. Open Core

摘要

本文翻譯自 CMSWire 網站的《

Open Source vs. Open Core: What's the Difference?

》，主要介紹 Open Source 和 Open Core 的差別。Open Source 已廣為人知，那麼 Open Core 又是什麼，在開源軟體盛行的今天，二者會怎樣影響這個市場呢？

開篇之前，我們先回到一個 2013 年 CMSWire 向行業内專家提出一個問題：專有軟體（ proprietary software ）和開源軟體 ( open source），哪個更好？當時就這個問題業内人士沒有達成共識，而現在這個問題似乎已經失去其存在價值。

開源無處不在

Constellation Research 副總裁兼首席分析師 Holger Mueller 曾表示——“開源無處不在“，而專有軟體供應商過去的經曆也證明了這一點。開源代碼促進了專有軟體的發展，反觀專有軟體也是開源項目的重要貢獻者。許多大廠，如：思科，谷歌，IBM，微軟，Pivotal，SAP，SUSE 也都是 Cloud Foundry Foundation 的成員，此外， Red Hat 也被歸類到開源公司行列， 擁有 4,550 名員工為開源項目貢獻代碼的微軟也不例外。無獨有偶，除微軟外，亞馬遜，IBM 和 SAP 也位列開源代碼貢獻榜單的前十名。

盡管 Open Source 盛行，大多數軟體供應商并不會給自己貼上“Open Source”的标簽。這是為什麼呢？此外，還有些公司自稱“Open Core” 或附加額外許可證以限制其開源代碼的使用，比如，Confluent 使用 Confluent Community 許可證而 MongoDB 使用 SSPL 許可證，背後的原因又是什麼呢？

Open Source 和“免費開源軟體”（FOSS）的開發者和愛好者對開源以及非開源的讨論充滿熱情，他們讨論關于“free”的不同含義，比如“免費軟體”（

free, as in beer

）和“開源軟體”（

free as in libre

）。但對于大多數開發者而言，尤其是面向 GitHub 程式設計的這類人，他們從 Github 上擷取需要的代碼為他們所用，卻不會關注對應軟體的許可證。正如 Mueller 所說，“PM 隻在意代碼運作結果和開銷并不在意開發是如何實作的，是以造成開發者對許可證的不敏感”。

但開發者、PM，或正在閱讀本文的你，真的應該去關注許可證嗎？來，我們研究下企業在聽到“開源”時，他們在想什麼。

管理者如何看待 Open Source

作為 Host Analytics、Marklogic 的前首席執行官和 Nuxeo 的董事，軟體主管戴夫·凱洛格（Dave Kellogg）說過，人們在面對開源時會混淆兩件事：源代碼和商業模式。在涉及到源代碼時，凱洛格指出需要考慮以下方面：

1. 代碼通路：代碼是否可見，可擷取，可更改等？
2. 代碼作者：它是由誰編寫的？是開源社群中的成千上萬貢獻者共同編寫，還是來自軟體供應商的工程師編寫？

比如 Drupal 有來自社群的 114,702 個貢獻者，而 MongoDB 99％ 的代碼是由其員工編寫。

說到商業模式，大多數情況下開源軟體是“免費的”，假設不是直接從 Apache Software Foundation 或 Eclipse Foundation 這樣機構擷取所使用的代碼，Kellogg 建議我們直接研究開源項目的供應商是如何賺錢的。

開源軟體有如下商業模式：

1. 純服務模式，比如，之前的 Hortonworks （現在的 HDP—— Hortonworks 發行版），使用者隻需為技術支援及咨詢服務買單。
2. Open Core 模式，比如，大家熟悉的 Elastic，部分産品是免費，而進階版本或附加元件則使用商業許可證（參考：社群版和企業版）。正如凱洛格指出的那般，"開源軟體供應商最大的競争對手往往是他們自己的免費社群版"。
3. SaaS 模式，比如，Databricks，供應商将其開源軟體作為服務托管在雲上，通過收取每月/每年的托管和服務費獲利。

Gartner 分析師 Nick Heudecker 是這樣區分 Open Core 與 Open Source 的："Open Core 是以 Open Source 為基礎的商業産品。Open Source 既是一種開發形式，也是一種源代碼的許可方式"。

Heudecker 在部落格中提出：

Open Source 供應商的核心價值在于不再受供應商的限制。畢竟，産品核心部分是開源的，且由全球社群開發。産品核心部分并不屬于某個公司，多數情況是由 Apache Software Foundation（ASF）擁有。在最壞情況下，即使公司倒閉這種最壞的情況發生，核心代碼依然安全存在(于) ASF，被 ASF 所支援。

這聽起來不錯。坦白來講，這不是事實。這是邁出了第一步并在頭一年迅速擴張的好方法。

在 24 或 48 個月的限期後期階段，供應商需要增加收入，有時他們甚至會大幅提高軟體價格。這會導緻我和我的同僚要接很多客戶打來的咨詢電話。他們會詢問他們實際所使用及有價值的功能，如果不用開源元件外的其他功能，他們能正常使用産品嗎？有些時候，這個問題的答案是肯定的 。此外，客戶們還會這些疑問：市面上還有誰家是支援開源元件的？它們更便宜嗎？他們和我之前合作過的軟體供應商用的同一政策嗎？

其他軟體供應商見機，會咨詢我們是否該提供對這些開源元件外的其他元件的簡單支援。因為他們的客戶也會與他們談論其他的内部供應商的政策。

凱洛格對這種銷售政策有其他的看法，他表示，“從供應商的角度來看，免費/社群版本既是潛在客戶的主要來源，也是最大的競争對手——如果企業版沒有提供相較于社群版更棒的功能，那麼人們就不會為之買單或再次購買。”

企業級購買者更傾向于 Open Source 還是 Open Core?

關于企業級購買者更傾向 Open Source 而不是 Open Core，還是 僅僅根據他們業務選擇軟體/服務這個問題，Ovum 分析師 Tony Baer 表示，這是一個複雜的問題。他說：“這是一個難題，答案是‘視情況而定’”。理論上，所有軟體決策取決于商業利益，而商業利益又由一系列選項構成，包括：增加收入，提高盈利，員工保留政策（留用希望在履歷上展現開源項目經曆的開發者），現有 IT 環境的相容性和并購中的機構。

我們咨詢的大多數分析師一緻認為，公司應該關注它們正在使用的開源技術，然而，這說起來容易做起來難。首先，開發者從 GitHub 或其他站點擷取資源時通常不會征求許可。其次，正如凱洛格提及的那樣，在開放源代碼計劃（OSI）準許的清單上有 82 種不同的許可證類型，公司需要了解哪些元件受哪些許可證限制以及使用這些許可證的後果。

OSI總經理兼董事 Patrick Masson 表示，這正是一些大廠，甚至是那些擁護開源的公司針對許可證采取行動的原因。比如，Google 已徹底禁止了至少七種類型的開源許可證。

有人會說因為産品背後的軟體供應商會處理許可證相容性之類的問題，并且内置了企業所需的管理和安全功能，是以 Open Core 軟體可能是一種更安全，更輕松的方法。但是亞馬遜，谷歌和微軟等大型雲提供商可能正在改變遊戲規則。

附錄

Nebula Graph GitHub 位址：

https://github.com/vesoft-inc/nebula

  ，加入 Nebula Graph 交流群，請聯系 Nebula Graph 官方小助手微信号：NebulaGraphbot

Nebula Graph：一個開源的分布式圖資料庫。

GitHub：

官方部落格： https://nebula-graph.io/cn/posts/ 微網誌： https://weibo.com/nebulagraph