Open Source v.s. Open Core

摘要

本文翻譯自 CMSWire 網站的《Open Source vs. Open Core: What's the Difference?》,主要介紹 Open Source 和 Open Core 的區別。Open Source 已廣爲人知,那麼 Open Core 又是什麼,在開源軟件盛行的今天,兩者會怎樣影響這個市場呢?git

開篇以前,咱們先回到一個 2013 年 CMSWire 向行業內專家提出一個問題:專有軟件( proprietary software )和開源軟件 ( open source),哪一個更好?當時就這個問題業內人士沒有達成共識,而如今這個問題彷佛已經失去其存在價值。github

開源無處不在

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% 的代碼是由其員工編寫。post

說到商業模式,大多數狀況下開源軟件是「免費的」,假設不是直接從 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://github.com/vesoft-inc/nebula

知乎:https://www.zhihu.com/org/nebulagraph/posts

微博:https://weibo.com/nebulagraph

相關文章
相關標籤/搜索