关于开源和闭源的探讨(上)_开源 闭源生态的区别

01|溯源

无论媒介的形式是软件还是硬件，开源与闭源指的都是信息（特别是科技信息）被共享的方式。

·开源通常被等同于免费（尽管不准确，但大体上是没错的）;
·闭源则通常以携带copyright（版权）的方式呈现，需要付费购买。

以史为鉴，笔者把人类开源的发展史划分为7个阶段，如下图所示:

最早的开源可追溯到互联网出现之前的汽车工业时代。1911年，福特汽车之父Henry Ford打赢了一场美国司法历史上著名的历时八年之久的专利官司，导致从1895年开始就垄断汽车发动机两冲程引擎专利技术的律师George B· Seldon再也无法以独享（闭源）专利的方式从汽车企业那里征收专利费用了。随之形成的机动车厂商联盟在其后的数十年间免费（开源）共享了数以百计的专利技术。
图：美国汽车工程师、企业家 亨利·福特

时间推进到20世纪70年代，ARPANET(美国高级研究计划署的简称)等机构在美国政府的推动下联合企业与高校催生了互联网的核心网络技术堆栈——如TCP/IP技术。而ARPANET成员间制定和分享技术标准的媒介为RFC（Request-for-Comments），即IETF（Internet Engineering Task Force，互联网工程任务组）组织发布的RFC文档。从1969年最早的RFC到目前为止有超过7,000个RFC1。其中最著名的有如RFC 791（IP协议）、RFC 793（TCP协议）、RFC 768（UDP协议）等。

20世纪80年代见证了免费软件（Free Software）运动的诞生，开路先锋是当时尚在MIT的Richard Stallman（RMS）。他最早于1983年在USENET上面宣布开始编写一款完全免费的操作系统GNU（GNU’s Not UNIX——时代背景为当时流行的操作系统UNIX 100%被商业企业闭源控制）。为了确保GNU项目代码保持免费并可被公众获取，RMS还编写了GNU GPL（GNU General Public License，通用大众版权）。
GNU的创立为Linux的诞生铺平了道路。据Linus本人回忆，1991年，时在芬兰读本科的他听到了RMS的演讲，深受鼓舞，于是在同年，Linus Torvalds编写的Linux内核问世，其采用GPLv2许可，此后，GPL逐渐成为开源最主要的版权许可方式。

RMS的另一大贡献是以组织、机构的方式系统化地推动了免费软件深入人心。他于1985年成立了FSF（Free Software Foundation，免费软件基金会），业界为此有了个充满政治含义的新名词——FSM（Free Software Movement，免费软件运动）。从最早的GNU项目到后来的LAMP，到近年来经互联网公司大肆鼓吹的共享经济形态，究其根本：如果有免费的“午餐”（来替代需付费的产品或服务方式），绝大多数人会趋之若鹜，此人性也。免费理念与实践之集大成者非RMS莫属。

真正的开源（Open-Source）软件要到1998年1月，Netscape（网景）公司宣布把Navigator（1994年问世的第一款互联网浏览器，Mozilla Firefox的前身）浏览器的代码开源。RMS在第一时间意识到开源的潜在价值，同年二月即成立了OSI（Open-Source Initiative，开放源码促进会）。如果说FSM为颠覆20世纪60—70年代UNIX系统的商业垄断而生，而OSI则是预见性地用开源去引领互联网时代的科技进步，开创了一条与商业+闭源不同的道路。

1998年1月，网景与微软IE浏览器竞争失利以后，为了挽回市场，网景通信公司公布旗下所有软件以后的版本皆为免费，并开放网景通信家（Netscape Communicator）4.0的源代码，成立了非正式组织Mozilla（谋智）。

另一个因素要归功于黑客文化（Hacker Culture）。RMS、Linus Torvalds……都是不折不扣的黑客出身。“黑客”一词在西语语境中趋于中性甚至偏褒义，但在中文语境中是一个略偏贬义的词汇，不过，在云与大数据时代，随着越来越多的中国青年一代接触和融入到更多的开源项目与社区中，相信中国的“黑客”必将绽放异彩。

GNU免费软件项目出现的时候其目标是构建一个完整的、可以取代UNIX操作系统的集编程、编译、调试、集成与运行环境于一体的生态系统。显然这个宏大的目标在头十年内 （1983—1993年）并没有实现，而最完整的实现是LAMP开源技术栈（见下图）。

广义的LAMP可延展至包含一切接入互联网的软件、固件、硬件乃至内容与服务的使能型开源科技。LAMP的出现极大地推动了局域网向互联网跨越，继而奠定了云计算与大数据的技术基础，并经一路攻城略地成为主流技术。此外，广义的LAMP覆盖面非常广，在操作系统层面可包含BSD等系统，如Yahoo!公司偏好的FreeBSD，WWW服务器包含Nginx等，数据库还包含PostgreSQL等，编程语言则可以泛指新兴的开源语言如Ruby/RoR等。
LAMP所代表的四大典型开源技术，Linux、Apache、MySQL、PHP/Python分别在服务器操作系统、WWW服务器、数据库及编程语言市场占有率接近或超过50%，并有继续上升的趋势。

02| 黑客文化驱动开源技术

开源技术在最早期并非纯粹以商业目的为驱动，确切地说是一种黑客文化（Hacker Culture）。以RMS为首的开源推动者们认为开源+共享+众筹是更高层次的精神享受，其成就感也继而带来更高的劳动生产率和工作效率。这一点和当下的互联网思维如出一辙。不过商业界不会错过任何提高ROI（Return-on-Investment，投入产出比）的机遇，以IBM、惠普、华为、甲骨文还有无数的互联网公司为代表，无一不是或转型来积极拥抱开源或从第一天开张即是开源驱动，即便是以偏执于闭源科技而著称的微软，也不得不在近些年开始拥抱开源软件技术（如容器计算兼容Docker）以获得更广泛的市场认知度。开源如此强势，恐怕是很多人始料不及的。

毋庸置疑，开源对传统的商业模式是一种颠覆，它以一种免费+开放的姿态赢得了黑客（Hacker）群体的心，鼓动了一批又一批的程序员投身开源社区，孜孜不倦地为开源项目贡献代码、编写文档、四处宣讲。例如近来流行的各种meet-up，就是开源项目积聚人气的一种新宣讲方式。

对于长期以来只有商业+闭源一条独木桥可走的需求侧企业与机构而言，开源显然提供了另一条路。不过这可能是康庄大道也可能是荆棘小路——简单来说，开源看起来很美，用好却很难，基于开源构建的产品与解决方案对于系统设计、开发、维护、升级、定制等一系列的需求通常远超想象。

对于供给侧而言，拥抱开源则是冰火两重天。一方面是积极拥抱开源可能会创造新的业务模式与现金流，另一方面是老的业务模式几乎一定会面临缩减、枯萎。这种现象我们称之为cannibalization，即业务间的“自相残杀”。

此外，对于工程师，特别是软件工程师而言，开源提供了新的就业机会，不过，同时也意味着那些曾经在微软、甲骨文这些主流商业、闭源体系架构上求生的成千上万的工程师会逐渐失去工作……

值得一提的是，虽然开源项目看起来似乎风光无限，但现实情况是，闭源项目仍是主流。无论是在商业领域还是在商业软件市场，开源项目所承载的体量仍旧指数级小于商业化项目。

03| 软件在吃我们所有人的午餐

业界的另一大趋势是随着底层硬件的同构化（通用化、商品化），系统主要的差异性都通过软件来体现。例如，虚拟化，容器化，软件定义的计算、网络、存储等。

软件，无论开源与否，以其远超硬件的灵活性、可定制性、可编程性、可二次开发性，顺应并引领了信息时代需求多变的特点而越来越受到青睐。其结果是硬件研发厂商几乎都是赔钱赚吆喝，而软件开发商则在金字塔的顶端拿走了整个产业链最大头的利润。

以手机行业为例，那些手机代工厂，如鸿海（富士康），组装生产一部手机获利不超过4美元，而苹果公司通过控制手机操作系统和其上的软件商店，每部利润超过200美元。另外，整个智能手机产业的利润的94%都属于苹果公司——软件的力量让人惊诧。软件是否在吃我们所有人的午餐（Software is eating our lunch）？也许，我们要用更久的时间来回答这个问题。

另一方面，时下成为了似乎软件可以定义一切的时代。软件的能力被极大的神化了！一个最典型的例子就是，软件所提供的算力是不可能超越底层硬件的物理极限的，而实际上，很多软件根本就无法充分利用底层硬件的高并发、低延时能力。这里面或许我们不应该点名批评任何一家公司，但是，务实地说，Hadoop生态中的解决方案，甚至包括Spark，动辄就会用成百上千台机器，实际上每台机器的利用率都甚为低下。32台机器的集群，如果每台机器只有1个线程在奔跑，这个集群的算力低于一台机器上面32个线程以高密度并发的方式在奔跑的算力。当然，这个问题复杂的地方在于，32台机器的硬盘并发的吞吐率一定会高于1台机器的硬盘吞吐率，不过，我们如果强调的是CPU的算力的话，那么事实就是如上所述。

这个问题还触及到另外一个话题——什么样的分布式系统是更高性能的呢？大家可以通过类比得到答案。

更小规模的分布式的集群、更密集的并发，往往会达到比那些更大规模的集群，但是却只有低密度并发更好的效果 。这也意味着：更低的延迟、更高的并发，在单位时间内更高的吞吐率，高ROI、低TCO。或许大家应该思考下，为什么有的人在前2年就说过：“Hadoop已死！”

笔者曾亲历了Hadoop肇始阶段。从2004年开始到2006年，Hadoop由Yahoo！的工程师Doug Cutting捐赠给Apache开源社区，笔者时任Yahoo! SDS战略数据部架构师。

2004年时，Yahoo!每天要处理全球超过30000台Apache Web服务器上面超过27TB的数据，这个数值在当年比Google要庞大，是世界上最大规模的数仓。值此机缘，笔者亲历了在Yahoo!内部彼时的分布式数仓系统建设中，Hadoop的性能、吞吐率、延时等很难与内部其它更实时化的数仓系统竞争，内部无法消化，进而转为捐献给了开源社区 。

笔者记得当时还开玩笑：Doug, it’s not gonna work （道哥，Hadoop肯定搞不定啊……）。 我为什么这么说？很简单，即便在今天，X86服务器的性能已经数倍高于十几年前了，但是一个普通的Hive查询，Hadoop随便一个Map-Reduce操作返回就要40秒，它实在是太慢了！几乎所有的Hadoop系统，都占用了无数的硬件资源，但是绝对不是以一种Fast Data的方式来执行任务的。这些是Big Data最令人难以启齿的问题 ，即便是到了Spark的架构模式上，也依然远远没有达到可以实时处理海量数据的水平。从投入与产出比来看，Hadoop/Spark最成功之处是构建了一整套生态，但是，生态不是一切，笔者始终认为，在数据库、数仓系统，性能才是第一生产力，也始终是第一生产力！