Open Source v.s. Open Core

简介: 本文主要介绍 Open Source 和 Open Core 的区别。Open Source 已广为人知,那么 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://github.com/vesoft-inc/nebula

官方博客:https://nebula-graph.io/cn/posts/

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

目录
相关文章
|
5月前
Open3D OCtree 八叉树
Open3D OCtree 八叉树
|
5月前
|
编解码
Open3D Voxelization 体素化
Open3D Voxelization 体素化
106 1
Keil报错:cannot open source input file "core_cmInstr.h" 解决办法
Keil报错:cannot open source input file "core_cmInstr.h" 解决办法
703 0
Keil报错:cannot open source input file "core_cmInstr.h" 解决办法
|
缓存 Python
Python - with open()、os.open()、open()的详细使用
Python - with open()、os.open()、open()的详细使用
524 0
|
Java Linux
too many open files
If you encounter the file descriptor leaks problem, it might be helpful to you.
2529 0