开源：从“复兴”走向“商业化”

出品丨自主可控新鲜事

内容转载自我思锅我在

正文共5094字，建议阅读时间15分钟

---

前 言

最近在美国版“知乎”Quora上搜“Open Source（开源）”，出来第一条问题是：

“Linux的失败真的是因为开源吗？”。其中一个回答给我很多启发：

“有些人把安卓和Chrome OS的成功归结于Linux开源，但我认为两者根本不相关。安卓和Chrome OS的成功并非得益于Linux/GNU/FOSS，而是因为他们有一个‘聪明的、高利润的、闭源且专属的商业模式’（smart, highly profitable, closed source, proprietary business model）”。

从IBM鲸吞RedHat、微软收购GitHub到Elastic、MongoDB等初创公司相继上市，这一系列事件早就不再是对开源本身的认可，而是标志着开源业务作为一种商业行为（business），其价值和模式逐渐复兴，终于获得了资本市场的广泛承认。

同时，初创团队和科技巨头在各自开源商业化过程中的不同策略与相互间的竞合关系，让我获得了更深层的理解。

---

正 文 

毋庸置疑，IP（Intellectual Property，知识产权）造就了两代伟大的科技公司和高壁垒的商业模式：

• 以芯片销售和基带授权构建垄断地位的英特尔和高通；

• 以软件授权PC厂商的微软以及直接将原生操作系统和硬件捆绑销售的苹果。

后面两家公司所缔造的以开发者为中心的软件及App生态，外加软件本身的网络效应，直接推动了互联网、云计算、大数据和如今AI等技术的发展。在这个过程中，用户和开发者对平台的依赖再一次加固了生态的壁垒。

壁垒带来垄断，垄断产生高利润。

在所有技术的背后还能看到另外一家巨头的影子——谷歌，其策略似乎跟上面所有公司的做法完全相反。从开源Chrome浏览器、安卓系统、到深度学习框架Tensorflow等技术，在A16Z去年喊出“开源正在吞噬软件”之前，我已经坚定地认为谷歌是近十年来软件技术发展的最大贡献者和获利者，开源是其最重要的商业策略之一。

但经过这段时间的研究，当我再看到Quora上的那个回答时，逐渐明白了一个基本逻辑：

选择开源本质上是个技术方向性问题，不是商业问题，更不能成为一种商业模式。

“旷视开源是想让更多人用我们的框架，找到更多能在产业落地的算法和部署的方案。”，旷视副总裁谢忆楠向我说道，这是深度学习框架“天元”Alpha版开源的主要目的。

而技术难度在于首先要让公司内部超过1400位研发人员基于统一技术标准真正在日常工作中用起来，其次需要将产业中落地的算法和模型内化后进一步反哺框架背后的算法。最后才是将接口封装及标准化，并让用惯Tensorflow、PyTorch的老手和研究员能借助技术文档，快速上手。

回到安卓系统的例子，当年谷歌开源的只是AOSP部分（Android Open Source Project，安卓开源项目），收费的是GMS（Google Mobile Service，谷歌移动服务），GMS就是谷歌旗下各种应用及API，包括我们熟知的地图、邮箱、Youtube和应用商店等。

由于安卓的内核本身基于Linux，后者要求安卓的核心代码必须免费公开。而GMS才是谷歌的“印钞机”，通过软件的网络效应和巨大用户基数，手机厂商最终不得不把它作为出厂标配，才让谷歌延续了来自IP世界的“高利润、闭源且专属”的商业模式，奠定了其在移动操作系统的霸主地位。

所以，从技术角度，涉及操作系统底层架构、操作性能、用户界面等部分，任何开发者或硬件厂商都可以根据开源代码进行二次开发。在遵守相关开源许可证的基础上，二次开发者有权自由选择是否开源，这取决于他们是否希望直接从中获利。

此外，谷歌在开源Tensorflow后一年，旗下更多产品的性能得到快速提升，而自己的AI公司Deepmind也随后宣布采用新一代Tensorflow作为底层算法框架。可见开源与否对大多数公司来说更是一个公开检验其核心技术领先性及可用性的机会。

HashiCorp是一家开发支持多云部署开源工具的公司，这个月刚宣布完成1.75亿美金的E轮融资。CTO Armon在一次关于开源的讨论会上说道：当面对开源或闭源的选择时，团队会先辨别问题是来自“技术复杂性（technical complexity）”还是涉及“组织架构（organizational）”。如果影响的是工具或产品的基本使用效果，这就是个技术问题，解决后必须开源；如果来自公司内部的孤岛或效率问题，则不需要公开。

其次，如果想把一个开源项目（project）做成一款成功的开源产品（product），这才是商业问题。

有个开源项目在上线初没少在用户面前吃闭门羹，团队由UC Berkeley的几位博士生组成，被拒绝的主要因为是用户担心团队毕业后可能解散。于是在2013年，大家决定全职投入并成立了一家公司，叫Databricks，如今已经完成了F轮融资，估值超过60亿美金。前三年团队只做一件事情，推广并行计算框架Spark项目并积极维护开发者社区。直到2015年，需求突然喷发，代码贡献量激增，才让他们开始思考如何商业化。

这是大多数团队都会经历的一个过程，更有意思的是，Databricks的CEO Ali和HashiCorp的Armon都认为：成功的开源项目背后能持续提供核心支持的往往只是一个精简的团队或一家公司，最多两家。

“当想清楚为什么要开源后，接下来要搞明白怎样开源，包括版本迭代和场景落地。”，这是谢忆楠给创业者的首要建议。旷视对开源的产品路线做了清晰的规划，从支持的CPU类型到对多种嵌入式设备的覆盖。

（来源：旷视开源发布会）

并且，商业化对于初创团队（或处于成长期的公司）与大公司相比，主要有以下几点不同，仅供参考：

出发点不同：大公司可能在一个项目的早期便开源，凭借其号召力希望更多人一起“贡献”迭代，初创团队则会在产品相对成熟的时候再开放，希望尽快吸引用户深度“使用”，注重完善产品在工业环境下的综合表现。

“开源不是我的一时冲动，而是深思熟虑、谋划已久”，物联网开源大数据平台涛思数据的CEO陶建辉曾在自己的公号上写道。三年时间写代码，不到十人的研发团队，项目在GitHub上线仅三个月就获得超过一万个star，这对初创公司来说非常不易；

战略意义不同：无论产品还是生态可能仅是大公司商业战略的一环，而对于初创公司产品和用户就是全部。

开源数据库上市公司MongoDB非常重视自助式开源产品“Community Server”，认为它是公司最重要的销售漏斗。当开源社区中的用户想在数据库上搭建应用时，就可以免费试用托管式的DbaaS（Database as a Service，数据库即服务）产品Atlas，当使用量进一步增加的时候便需要付费。随后公司销售将会在付费用户群中继续筛选具有更高阶需求和付费能力的销售目标，为他们提供企业级产品Enterprise Advanced，包括专属服务器、运维工具等增值服务；

运营策略不同：因此大公司建立“联盟”（partnership），包括传统软件巨头、咨询公司、ISV（独立软件开发商）、集成商、SaaS服务商等伙伴，而初创团队更注重维护“开发者社区”（community）。

尤其对于中国团队，从一开始就应该注意国际化问题，“从英文文档、教程、案例到辅导课程（tutorial）准备，建立严格的代码审核流程，重视每一位用户的贡献”，一流科技的CEO袁进辉对我说道，他公司旗下的深度学习框架OneFlow也将在几个月后开源。

所以，当做好了充足的思考和准备，决定要全身心投入到商业化运作的时候，“东风”在哪里？

第三、找到企业级客户，“SaaS”的重点不是“Software”，而是“Service”，正如“云服务”的重点不是云，而是服务。

尽管初创团队和大公司在开源初期的出发点和策略有所不同，但当前者发展到后期或被大公司并购后，这些行为的边界将会逐渐模糊，新的差异会很快出现：

1.以前用户大多是“开发者”，现在开发者不能完全代表他的“企业”，必须重新调研企业级客户的真实且完整的需求；

2.以前用户发现了代码错误提交的是“pull request”，然后等待你的回复，现在客户会在半夜给你的客服致电，要求立刻处理问题；

3.以前客户习惯独立下载软件并私有部署，希望你在必要时提供在场支持和维护，现在他们习惯把更多应用和数据放在云端，并希望你也能提供类似的“服务”和收费方式。

你会发现，这些新特点的出现基本跟开源与否无关。

以RedHat为首的开源1.0时代随着RedHat在2018年被IBM以340亿美金收购而落下帷幕，2.0时代的“东风”便是面对新特点之下全新的商业模式、产品路线和应用架构——

SaaS、“Developer-led（开发者导向）”以及云原生。

首先在开源初期，获得社区里的开发者支持（advocacy）至关重要，原因不再赘述；

产品化后，需要进一步为开发者提供额外服务，让他们能专注在应用级开发上。随着开发者在公司采购决策的影响力增加，产品将很有可能形成面向企业级客户的销售转化。这类似Zoom之所以能改变公司自上而下的采购模式，正是因为员工在企业IT采购中的影响力逐年上升；

最后，深入企业级客户的研发甚至业务流程，构建全栈方案。这对于在底层基础设施层（infrastructure）从事相关开源项目的公司来说可能更重要，原因在后面会解释。

陶建辉也分享过，“从一开始设计，就决定要打造一个全栈的时序数据处理工具，不仅只是一个时序数据库，还提供缓存、流式计算、消息队列、订阅等系列功能”，才能最大程度减少产品对系统资源的消耗和维护的复杂度。

只有做到以开发者为导向，才能最终做到以客户为中心。

最后，面对绕不开的“如果BAT（国外是FAANG)做了，你怎么办？”这个问题，谨慎选择开源许可证，保护IP。

对开源许可证的类型，给大家做个快速归纳：

（来源：https://www.cnblogs.com/newcaoguo/p/7103249.html）

促使我思考这个问题来自以下几个事件：

原有的GPL协议，由于网络服务（Web service）公司的兴起（如Google）产生了一定漏洞，比如使用GPL协议下的开源软件，它并不发布于网络之中而只是通过云提供服务，则公司可以自由的使用GPL协议却不开源自己私有的解决方案。所以，AGPL的出现就是为了弥补这个漏洞；

2018年10月，MongoDB宣布其开源许可证从AGPL v3切换到自己定义的SSPL（Server Side Public License，服务器端公共许可证）。SSPL会明确要求托管MongoDB实例的云服务商（尤其在亚洲的公司，你们细品）要么从MongoDB获取商业许可证，要么向社区开源其服务代码，意在打击逃避AGPL监督的行为；

2019年1月，亚马逊AWS推出托管文档数据库服务DocumentDB，与MongoDB完全兼容。官网宣称可以“提供大规模运行关键任务型 MongoDB 工作负载时所需的性能、可扩展性和可用性”，同时提出能帮助用户“轻松地将本地或在亚马逊云上的MongoDB数据库迁移到DocumentDB，并且几乎不会出现停机”。产品推出后立即在开源社区引起巨大争议，而MongoDB股价在当天下跌13%。

AGPL虽然试图在规则上弥补上述“Web service loophole（网络服务漏洞）”的问题，但从MongoDB推出SSPL便知道效果不佳。更让我担心的是DocumentDB的出现把一个技术方向性问题直接推到了商业可行性层面，让“云服务”在众多以SaaS模式进行开源商业化的初创公司面前成为了一把双刃剑：

客户把数据和计算交给开源公司，而开源公司的服务质量（包括性能、可扩展性和可用性）又取决于云服务商（AWS、阿里或微软等）同时其代码还暴露在公开环境中。那么无论从规模经济还是服务质量来看，后者在基础设施层上天然具有一定优势。

当然，如同上面所说，随着对全栈服务、混合云部署以及在物联网设备和边缘上区别处理等特殊需求的出现，一开始就在云上设计、开发并维护相关产品的初创公司会逐渐形成自己的护城河。

所以，当公司选择了SaaS作为商业运作的基本模式后，判断护城河坚固与否和其商业价值，最终还是会回到SaaS最核心的几个指标：例如增长、流失率（Churn rate）和收入留存率（NDR）等。

AI三要素算法、算力和数据中，谷歌对后两者拥有足够强的优势，在开源安卓上尝到甜头后，2015年开源深度学习框架Tensorflow便成了顺理成章的事情。百度也在2016年开源了其深度学习框架“飞桨”，上周清华大学正式对外开放自研的深度学习框架“计图”，而这周轮到旷视的“天元”。有传闻称华为也计划在今年开放早已上线的深度学习平台MindSpore，仔细看各家都有自己的技术特点和商业小算盘。

未来在AI、基础设施以及IoT等前沿领域和相关技术上，我们一定会看到更多国内开源项目及科技巨头的行动。

但需要非常谨慎的是，这与所谓的“国产替代”不可相提并论。原因如下：

1.开源社区是全球开发者同场竞技和知识共享的地方，仅得到国内的“开发者支持”既没有说服力也不够有影响力；

2.从“开发者导向”到“以客户需求为中心”，除了个别敏感领域外，开源公司的客户群体理应不分国别。何况如果连企业级客户的安全及隐私性都无法保证，如何确保那些高危领域的安全呢？

3.以SaaS为主要模式的开源产品，由于自助服务（Self-service）而形成的网络效应，自然会为公司带来全球性口碑。这将直接影响SaaS的核心指标，任何保护性政策都对公司长期商业价值没有任何好处。

哪怕对于一切“国产替代”的项目，我非常认同松禾资本的董事总经理郭琤琤在《国产替代：沸腾的十年大潮 | 松禾研究》中的观点：

“我们要的是真实的替代，不要伟大的备胎。”

那么，在这个“开源正吞噬着软件”的时代，我们将会看到什么样的项目和公司呢？

一个在前端经久不衰的开源服务，背后必然有一个具备高度凝聚力和全球化视野的开发团队，以及围绕这个团队而组建的高度商业化运作的公司，这与国别无关。