关于开源和闭源的探讨(下)

我们知道,开源不仅仅颠覆了很多大企业的业务与运营模式，也改变了很多初创高科技公司进入市场的方式与节奏。对于程序员或用户而言，开源的时代既是最好的时代，也是最坏的时代。而开源的盈利模式、开发风险等在业界属于尚无定论的议题。接下来,让我们继续一起探究这些问题的答案。

一 简要分析关于开源vs闭源 商业化解决方案的优劣势

在对开源的业务模式展开讨论之前，笔者想结合自己多年在开源和商业领域的经历与见闻，简要地分析一下关于开源vs.闭源商业化解决方案间的优劣势。
1．成本

· 短期成本：开源上手成本低，使用灵活，可以算作其最大的优势。 ·
中长期成本：开源项目组建的系统最终都需要大量人力和资源来维护，其综合成本通常并不比商业化解决方案更低。

2．稳定性
除非是非常成熟的开源项目，否则其稳定性是未经考验的，这也是使用开源项目在真正进入持续商业化时所遇到的最大挑战。

关于一个项目是否“成熟”，这是个非常主观的问题，如果用Github的star数量来衡量，要充分考虑中国式开源通过运营人头来点赞的模式，即便有1—2万颗星，也并不意味着项目已经成熟了。另外，要看Top100的贡献者，很多所谓的开源项目几乎所有的贡献者都是项目所在公司的内部员工，那么这种开源项目的成熟度能有多少呢？

像MySQL、Redis之类这么稳定的项目并不常见，即便是像MongoDB这么宏大的开源项目，一旦进入大规模部署后对于任何中小公司而言都是巨大的挑战，一旦无法克服，会深陷泥潭难以自拔。

国内市场上一度火爆的TFS(Taobao File System=淘宝文件系统)，曾经受到很多程序员的追捧，但是很少有人仔细的分析过淘宝的应用场景和对该项目的支持力度，现在该项目已经寿终正寝（淘宝团队不再维护该项目），而且淘宝当时设计的目的是支持海量小文件，而有多少的创业项目是一样的业务需求呢？很多人盲目的上马了TFS，到头来发现系统稳定性很差而且有无数的问题，那么，这些是小团队、二次开发能力并不强悍的团队可以承受得了的吗？

3．效率
用性价比（cost—performance）或投入产出比来评估效率是相对合理的方式。笔者以为开源项目会给人造成其效率更高、性价比更高的认知，但是这是有待商榷的。如上文提到的“稳定性”和“成本问题”，开源或许能够实现较高的短期可以见到效果效率，但是随着业务规模的增长，商业化解决方案能更多的让开发者关注于业务本身而不是花无数的精力去研究和保障稳定性、性能、可扩展性等支撑性问题的解决方案。

4．道德绑架
如果拿Neo4J在2018年底宣布其图数据库的社区化版本与企业化版本间的脱钩来看，有太多的开发人员乐衷于像水蛭一样从开源项目攫取，而并没有什么兴趣去回馈开源社区，长此以往，开源社区很难健康、持续性的发展。

但是大多数的程序员都会对每一个不谙技术的团队领导者或者是投资人宣称开源项目是如何的高效可行，其结果是，尤其是在BAT式的互联网行业，很多人觉得开源可以取代一切商业化解决方案，如果一个项目没有采用开源解决方案，则会被道德绑架为没有前途或者没有能力，这些看法和做法显然是失之偏颇，而且这种厚此薄彼、非黑即白、人云亦云的隧道式视觉（tunnel—vision）对于中国IT行业的发展弊大于利。

5．伪开源
何谓伪开源？或许用半开源（Semi-open-source)说更准确一些，就是有很多商业化公司的开源项目中，核心部分的代码采用二进制文件的方式，并没有实质开源，而外围的服务层则以代码可现方式开源。这类的项目甚至占到了整个开源项目的1/3以上，尤其是高性能相关的项目、系统、库都采用这种方式来“开源” 。 例如那些以C、C++、Java这类编程语言为主实现的项目。显然，绝大多数的开发者根本不会有兴趣去探寻底层代码是否开源，能提供个接口来调用，然后项目方也通过开源获得了知名度，最终的结果是，皆大欢喜是真，明修栈道、暗渡陈仓也是真。

二 开源业务模式有哪些?

总结起来，开源的业务模式，特别是按照产品形态、运营与盈利模式来划分有如下几大类:

下面笔者对这六类开源商业模式逐一展开论述:

免费开源版本+付费企业版本模式
这是一种比较常见的开源商业模式。依托开源版本与开源社区来开发最新的功能，并让市场和用户可以尝鲜。同时，通过企业研发资源来维护和打造稳定的、有客户支持的付费企业版本。

最典型的例子有RedHat公司推出的三款Linux操作系统：Fedora、RedHat和CentOS。它们的主要区别在于Fedora是通过开源社区的力量开发的快速迭代，基本上每6个月更新一次主要版本，具有新功能和特性的免费Linux版本；RedHat则是强调稳定性与企业客户需求的付费企业版，可以认为RedHat Linux上面的功能是经过Fedora社区验证过才审慎地引入RedHat中来；CentOS则是在RedHat基础上完全由社区维护的Linux版本，也就是说，没有客户支持，完全依赖开发者或社区的支持。

开源免费+服务付费模式
开源免费+服务付费模式，或开源+咨询、培训模式，或开源+有偿技术支持模式恐怕是最常见的开源商业模式。这一模式的主要特点是用户可以完全免费使用开源项目的所有功能，但是由于很多用户自身缺乏对开源架构、功能的深刻理解，通常需要雇用第三方的商业团队来进行技术支持，包括系统搭建、性能优化等。

最典型的例子是MySQL数据库，MySQL几乎被超过一半的有数据库服务需求的公司所使用，而对数据库的管理、优化是经常困扰这些公司的难题。类似的开源数据库咨询、培训、有偿支持公司应运而生。例如Percona、MariaDB等都是提供相关服务的厂家。

基于开源产品的发行商模式
随着开源项目的复杂度逐年提高，另一种在最近几年逐渐流行的开源商业模式是基于开源产品的发行模式。这一模式的通用特点是通过对开源项目进行二次开发、定制、重新封装来提供具有特色（Differentiation）的功能与服务（例如性能、便捷性的提高等），并以新的开源或闭源的产品方式在市场上发行。

以Open Stack11为例，Open Stack的定位是一款星球级云操作系统（Planet-scale Cloud Operating System）。Open Stack的核心组件（Core Services）有Nova（计算组件）、Neutron（网络组件）、Swift（对象存储组件）、Cinder（块存储组件）、Keystone（验证组件）以及Glance（Image服务组件）六大块，而可选服务有13项之多，例如Manila（共享文件系统）、Murano（应用目录服务）、Sahara（可伸缩MapReduce）、Heat（编排）、Horizon（控制面板）等。以上每一个组件在开源社区都是一个独立的开发项目。面对这样一个庞然大物，它的开发与维护的难度可想而知。也正是基于此，业界涌现了一大批定制化OpenStack发行商：

Ubuntu Open Stack（2015年的一个统计显示全球65%的OpenStack是基于Ubuntu操作系统的12）；
Mirantis（Mirantis Fuel是其旗舰OpenStack增强版，例如图形化安装支持等）；
Cloud Scaling（2014年被EMC公司收购用于推出ECS对象存储产品）；
Piston Cloud（2015年被Cisco收购，相信是为了补充其Metapod产品功能）；
Cisco Metapod（其前身是Cisco OpenStack私有云项目）；
IBM Cloud Manager（对OpenStack的资源调度、自服务门户做了大规模优化）。

以上只是不完全的列表，还有更多的厂家基于Open Stack技术来推出自己的私有云、公有云或混合云解决方案。在开源商务模式中经常会出现多重模式混合的现象，这通常可理解为企业在试图通过不同的渠道来实现盈利。

开源广告（PR）+赞助模式
绝大多数开源项目的存活依赖于企业和个人的经济资助，而开源项目和绝大多数互联网营销（病毒传播）非常类似，靠口碑累积人气。开源软件可以免费下载使用，但作为回馈，需要为该软件免费做广告。这也是为什么几乎所有开源项目的主页的显著位置都会列出它的用户包含了哪些业界知名的公司。

这种免费的背书（PR/endorsement）对于开源项目至关重要。著名开源运动活动家RMS曾经总结了开源项目背后的开发者最主要的诉求是成就感（Sense of Fulfillment）。而让全世界知道有那么多知名企业、产品构建在他们创造的开源项目之上是一种凌驾于物质（金钱）刺激之上的更高层次的心理满足。

另一方面，开源项目也通过各种使用许可（License Agreement）来规范、约束和引导它的使用者们如何正确使用以及如何传播或回馈开源社区。

开源结盟模式
开源项目中的参与者形成联盟（Alliance或Association）也是业界常见的运营模式。通常这种结盟模式都是业界的一些巨头主导的工业联盟。

最典型的例子如PaaS平台上的两大联盟。2014年成立的CFF（Cloud Foundry Foundation）基金会与2015年成立的CNCF（Cloud Native Computing Foundation）基金会。

·CFF基金会是以EMC+VMware+Pivotal（简称EMC联邦的三大公司分别侧重于IT基础设施、软件定义数据中心与大数据）为主体联合业界其他友商来推广Pivotal公司开源的PaaS平台解决方案Cloud
Foundry；
· CNCF基金会则是依托于Google公司从GCP（Google Cloud
Platform）平台上剥离出来的集群与容器管理组件Kubernetes而成立的CaaS（容器即服务）平台。

两大平台都在争夺PaaS/CaaS乃至ITaaS（把整个IT作为整体来服务化）市场。有趣的是这两大联盟里有很多公司都是采用了左右手互搏的策略，例如VMware、Huawei、Intel、IBM等。换句话说，任何一个联盟的成功或失败都不至于让这些参与者一败涂地。因此，对于业界巨头而言这种脚踩两条船的对冲（hedging）策略应该也是一种自我保护。

开源+闭源组合模式
最后，我们来介绍一下开源+闭源组合模式。越来越多公司的产品研发策略已经调整为采用开源项目来构建通用组件，而通过内部闭源开发来实现那些独具特色的功能。这样做的一个最大的优点在于，通过利用开源社区的创造力与开发力量，确切地说是一种众包，可以极大节省企业的资金与资源消耗。而作为回馈这些公司通常会以赞助商、免费广告等方式来资助相关开源项目与社区。

这一模式最典型的案例有IBM的Bluemix与Huawei的FusionSphere。前者是基于OpenStack与Cloud Foundry搭建的混合云管理平台，而IBM在其上集成了超过100种移动、互联网与大数据领域的服务。后者同样也是利用了OpenStack与Cloud Foundry来作为其IaaS与PaaS层的通用组件，但是在底层与上层分别接入了Huawei自己及第三方的硬件与软件产品并进行了高度优化。类似的行业案例还有很多，这种开源+闭源的混搭模式对于企业而言能够带来更高的ROI与资源池配比优化，这也是为什么该模式能够在时下大行其道。

以上数种模式有时也会融为一体以追求最佳的市场切入（Optimal Market Penetration）。例如，大数据软件公司DataStax的产品DataStax Enterprise（DSE）是基于开源NoSQL数据库Apache Cassandra搭建的。DataStax对Cassandra进行了诸多企业级需求强化（安全、图形化管理、结合了Apache Spark的内存计算、搜索等功能、DevOps支持等），并同时支持开源社区版Cassandra与其企业级强化版本，并且还提供Cassandra社区推广与支持服务PlanetCassandra。如此看来以上6种模式，DataStax几乎占全了。

**

三 如何拥抱开源?

关于开源、闭源的讨论,想必大家已经有了深入的了解。我们没有必要硬磕开源和闭源到底孰优孰劣,或者非要一比高下。本话题结束之际,笔者在这里对于那些做开源的公司以及工程师就如何拥抱开源做了三点小建议:

(1)结合业务需求来试错：脱离自身业务需求与规划的任何开源项目都没有太大意义，在引入开源项目的时候不能完全放任研发团队的单方面技术评估，而一定要结合产品、运营及业务部门的需求来综合评估。确切地说CTO/CIO的工作就是确保公司可以选择正确的开源项目来构建相应的基础架构及应用实现。

(2)充分考虑社区活跃度、支持度、架构、文档完善程度：综合考量这些指标是评估一个开源项目可持续性的重要因素。类似的指标还有社区多元化、更新迭代速度、社区文档质量等。

(3)内部人员匹配、团队能力建设：这个因素应该是三条中最重要的，依托开源并不意味着不需要内部开发团队了，恰恰相反，几乎所有的开源项目的成功驾驭都需要更强大的开发队伍，以及与之匹配的产品与业务团队，缺一不可。

【往期回顾】
关于开源和闭源的探讨（上）