开源软件不是凭空出现的，开发开源软件是一项艰苦卓绝的工作。每个开源软件的背后少则有原作者一人的投入，多则协同了成千上万人组成的开源社群的共同努力。然而，开源软件的源代码总是免费可得，并且开源软件协议总是不限制用户的使用形式。

基于开源软件完成工作乃至搭建业务盈利的用户，并不总是参与软件开发的人，这种形似经济学中“搭便车”的行为，在国内被提及的时候总会被称为“白嫖”，以至于后者称为圈内的一个热词。那么，开源世界当中到底存不存在“白嫖”，不同角色眼中的“搭便车”行为到底是怎么样的？本文将对此做些讨论。

用户的“搭便车”行为

从经济学的角度上，“搭便车”行为意即不付成本而坐享他人之利。由于开源运动的精神就包括了制造出来的开源软件的源代码免费可得，并且不限制任何人将其用于任何用途，所以我们可以说，开源世界当中“搭便车”的行为是广泛存在的。

实际上，当我们编译一个 C 程序的时候，很可能我们就依赖了自由软件 GCC 或开源软件 Clang 作为实现编译的编译器。大多数程序员都不曾直接参与过这两个编译器的开发，因此做过这样操作的人都可以算是这两个软件的“搭便车”者。

然而，自由软件运动发起的根本，就是 Richard M. Stallman 对软件自由的追求，即他认为软件开发应当像学术研究一样，其成果是公开透明并且允许其他人演绎的。开源运动方面，前面提到的“开源软件的源代码免费可得，并且不限制任何人将其用于任何用途”就是开源定义的一部分，并且 Apache 基金会的元老级成员 Ted Dunning 在纪录片 Trillions and Trillions Served 当中也提到，当他不再纠结于其他人使用软件盈利，而是彻底使用开源软件协议授权自己开发的开源软件的使用以后，软件的生命力和他本人得到的反馈和声誉回报反而增强了。

也就是说，纯粹使用开源软件的用户，并不会挑战一个秉承自由软件精神或开源精神的开发者的认识。这样的“搭便车”行为在开发者选择对应的开源软件协议的时候就被视为做出了对应的承诺，这也意味着开发者应该谨慎选择开源软件协议。

另一方面，Apache SkyWalking 的作者吴晟曾经说过，“真正伤害开源的是开发者本身”。通过原文的描述和我走访若干开源软件的维护者得到的回应，以及自己作为开源软件的开发者的体会来看，当开发者痛斥用户的“搭便车”行为为“白嫖”的时候，往往指的是这样的一种情况：

一个是开发者，特别是中国的开发者认为，软件作者去帮助他人是天经地义的，因为整个软件是你写的，所以我来问你问题，你就应该有问必答。如果你不答，就认为你这个人摆架子。而不是考虑因为软件作者用了自己的时间提供服务，所以应该表示感谢。

简而言之，就是无偿使用了开源软件，却丝毫不尊重投入了巨大精力开发出开源软件的生产者们，反而认为这些生产者理所应当提供各种支持。

关于这个话题，我和吴晟在推特话题 #开源逸闻上抛出了不少例子。

其中我印象最深的是 Vue.js 作者的尤雨溪拉黑挑衅者的案例。这个用户认为 Vue.js 的某个库用 TypeScript 写实在是太难懂的，于是抱怨难道作者不应该照顾纯 JavaScript 用户（言下之意，尤其是“我”）的心情吗？尤雨溪的回复堪称模板，也讲清楚了这种行为在维护者眼里的性质。这里做一个简单的翻译引用：

嘿，没有人强迫你用这个库，你也不需要为使用它付费。作为一个用户，你至少应该以一种互相尊重的态度进行有建设性的交流，但是你没有。源代码当中的复杂类型是为了给日常使用提供更好的提示，这是一个显而易见的折衷取舍。你把你自己在 TypeScript 上的挫败感发泄到库作者身上，而库作者却在免费地生产开源软件并试图为你提供帮助。你是一个典型的开源软件“搭便车”者，请你滚蛋并且再也不要使用这个库。

P.S. 你已经被所有 vuejs 组织下的项目永久拉黑，请不要再试图回复。实际上，我相信你可以停止使用开源软件并且从头开始写所有东西，这会对你更好！

这个模板很快被其他的一些开源软件的维护者复用（笑）。当然，库本身仍然是开源软件，这个被拉黑的人仍然可以免费下载到源代码。但是从这个案例里我们可以看到开源软件作者最反感的“白嫖”行为，就是这种理所应当地索取。

吴晟在多年经营 SkyWalking 项目的过程当中也遇到了很多这类案例，

• 常见的开源用户的错误思路：把公司需求和定制化需求带到社区，期待社区花费人力时间解决。
• 这里提问者，典型的把开源开发和闭源的内部的功能性开发混淆了。他询问了一个开源社区开发者，不会遇到的场景。
• 宁可等待一周，反复的问一个问题，也不愿意把关键词放在官网搜索框中回车一下。

我也在邮件列表上看到过几个典型的案例。

一个是某公司的软件供应链审计人员“要求” ZooKeeper 说明自己软件的定位和不同版本使用风险，这是把 ZooKeeper 开源软件社群当成与自家公司签订了某种合同的软件提供商了。

另一个是 Flink 中文列表上，不止一名用户总会像上面吴晟见到的案例一样，把自己的本职工作的问题抛到邮件列表上，并心急如焚地等待别人的解答，一旦收不到回应，就会颇有些气急败坏地抱怨“这个问题没人解答吗？！”当然，在用户列表上抛出问题，这是软件用户的权利。但是 Apache 开源社群强调了每个社群成员都是志愿者，如果有人出于社群责任感、热心或者解答问题锻炼自己等等动机帮助你，这是值得感谢的。但是你本人才是领薪水做工作的那个员工，其他人没有义务回答你的本职工作带来的问题。或许你的老板很急，你也很急，但是你先别急，才有可能在社群的帮助下解决问题。

最后，我想提倡的一点是如果社群当中其他成员对你提供帮助，我个人希望听到的是感谢而不是“辛苦了”。因为我一不觉得辛苦，二不觉得这是个义务。我没有辛苦地为你做什么，你也不要以为我是在辛苦地为你做什么。至于我是在“非工作时间”或者你当地时间的凌晨回复，你也不要感到惊讶。不要以自己对这件事情的投入程度来揣测别人为什么要在你当地的这个时间做这件事情。很多情况下，他不是为你而做，而是出于前面提到的社群责任感、热心或者解答问题锻炼自己等等动机而采取行动。至于别人希望在什么时间做什么事情，也不需要你做评判，主观地觉得别人“辛苦”了。

行文至此也到一段落，原本准备写的“云厂商的‘搭便车’行为”和“开发者的‘搭便车’行为”两个主题就等日后再有动力的时候再写吧。

云厂商的“搭便车”行为

另一个经常被拿出来讨论的“搭便车”行为，是云厂商使用开源软件打包成云服务售卖盈利的例子。

为什么 MongoDB Inc. 要说云厂商伤害了 MongoDB 的社群，Elastic、CockroachLabs 和 Airbyte 也紧随其后呢？

• Why are we changing the license for MongoDB?
• Upcoming licensing changes to Elasticsearch and Kibana
• Why We’re Relicensing CockroachDB
• A New License to Future Proof the Commoditization of Data Integration

这四篇公告，我在《免费增值的商业模式》当中也提到过。

我想“云厂商的搭便车行为伤害了制造开源软件的公司”这样的说法，是开源的动机不同所导致的。

这些制造开源软件商业公司一开始开发开源软件，是看到了开源软件在技术圈里的传播潜力。从他们的思考模式出发，其他公司想要复刻同样的商业价值，必然会因为跟不上核心团队的研发能力而被市场淘汰。由于分布式系统的部署和运维足够复杂，只要开源软件能够维持 MySQL 时代一家话事的话语权，拿下缺乏维护这些分布式系统的客户是有可能的。换句话说，商业公司的基本诉求是盈利，当 MongoDB Inc、Elastic、CockroachLabs 和 Airbyte 选择开源全栈技术的时候，他们考虑的商业模式是免费增值的市场策略 + 软件复杂度带来的维护成本引发的付费意愿。

然而，云厂商拥有强大的云上软件部署优化能力。云厂商与上面这些商业公司做商业竞争，并不需要研发出具有代差的高水平软件。只要完成云上打包部署的工作，调配厂商内部的网络、存储和机器资源，调动遍布全球的销售团队，在企业服务市场的组合拳足以在直接使用上述开源软件的情况下赚取高出原厂的利润。

这一下子，制造开源软件的公司就不干了。

你没有听过 Kubernetes 的作者指责阿里云销售 Kubernetes 发行版损害了他们的利益，也没有听说诉讼专家 Oracle 打击其他 JDK 的提供商，Linux、Spring 和 Netty 等等众多开源项目的维护者也不在乎其他厂商如何打包销售解决方案。因为这些厂商的经营跟他们的获利途径没有冲突。然而，MongoDB Inc. 流派的公司，就是打着规模化销售软件服务来盈利的算盘，云厂商的行为是实打实的利益冲突。

另一方面，虽然也有部分开源软件作者为自己的付出得不到回报愤愤不平，但是大量高质量的开源软件开发的目的，是为了解决作者自己的问题或者出于 Because I can 这样的理由。这些作者有着不同于开公司销售标准化软件以外的诉求，乐于见到云厂商使用它们的技术构建自己的产品方案。反观制造开源软件的公司是实打实的支付了员工工资开发这个软件的，为了回本和盈利就指望把软件和服务卖出去赚钱，除此以外也没啥别的想法。这样的模式下云厂商赚走的钱，即使还给自己留下了一些盈利空间，也是这些做着有朝一日成为 Microsoft 体量的公司梦想的商业公司所不能接受的。

前文提到，“开源软件的源代码免费可得，并且不限制任何人将其用于任何用途”是开源定义的一部分。这就意味着云厂商对开源软件的打包销售在开源协议许可的范围内。制造开源软件商业公司愤而斥责云厂商“白嫖”、“吸血”，是因为他们把自己制造的开源软件当成了专有软件，不希望其他人能够与他们进行商业竞争。

这一点，从 Elastic 即使能够打赢和 AWS 的商标官司，在开源协议保护知识产权的范围内迫使 AWS 将其 ElasticSearch 服务更名为 Amazon OpenSearch Service 以外，还是要以禁止提供同类服务和破解密钥的 Elastic License 来重新许可自己的产品可以看出来。

从 ELv2 的措辞当中我们可以看出来，这些厂商的主要诉求就是禁止商业竞争。ELv2 并未限制不提供同质服务的情况下的商业使用，对于 Elastic 来说，如果用户具备相应的技能，或者用户公司已经支付给其工程师用于运维 ElasticSearch 的内部使用，那么也就不是自己的目标客户。这也是 Airbyte 和 Starrocks 的选择。CockroachLabs 使用 Business Source License + Cockroach Community License 达成了一样的效果。

这种模式的主要缺点如同 Eric S. Raymond 在《大教堂与集市》中《魔法锅》一文所说：

封闭条款往往限制了同行评审参与。

换个角度看，在组织员工投入精力参与开发的开源软件，有可能被云厂商或其他竞争对手直接使用的情况下，商业公司应该如何理解和投入在开源方向上的资源呢？

我们可以从社群和公司的关系来分类讨论。

如果是公司依附型的关系，也就是上面讨论的 MongoDB Inc. 这样的公司，雇佣员工开发软件，那么只要云厂商或者其他强势的对手参与商业竞争，以 ELv2 或者 BSL 重新许可基本是定局。或许在自己研发的软件尚不突出，竞争对手发现没有直接复制的价值的时候，才能维持开源许可的外表。GPL 和 AGPL 可以提示下游软件作者期望整个社群在一个共同的上下文当中工作，但是无法抵抗一行不改只是增强部署实施和销售团队碾压的来自云厂商的商业竞争。

如果是社群依附型的关系，也就是 RedHat 和 Linux 以及 Kubernetes 这样的关系，开源社群可以独立生存发展，那么商业公司应该不会有其他厂商“白嫖”或“吸血”的体验，因为自己也是社群强大生产力的获利者。这类公司需要理解与自己经营关系紧密的开源社群的运作方式，通过制作发行版或者一揽子解决方案来形成自己的商业价值。形成后者能力的代码是专有代码，因此也就不存在被“搭便车”的问题。例如 Tetrate.io 制作 Istio 发行版和应用网络治理框架，虽然使用了开源的 Istio 和 Apache SkyWalking 等软件，但是也有大量内部代码。阿里和腾讯的 Kubernetes 发行版也是类似的逻辑。

如果是相互依附型的关系，也就是项目并非公司所有，但是社群又需要公司投入支持的情况，这种情况产生的项目往往一开始并不是为了作为商品销售而产生的。例如 Apache DolphinScheduler 目前是白鲸开源公司的技术图谱上的重要基础软件，但是它的启动阶段是在易观公司内部完成的。同样的软件还包括 Apache Pulsar 和 Apache Doris 等等。对于这些例子当中的公司，由于没有那种“这是我的软件”的执念和软件确实几乎 100% 是公司出钱投人开发的背景，在经营上可以参考社群依附型的做法，同时加强原厂品牌，积极营建社群伙伴关系，提高其他竞争对手攻占定位的难度。

公司在技术上选择开源路线的时候，应该遵循开源本身就是跨越组织边界的集体智慧的性质，寻找已经存在的方案。例如白鲸开源公司为了完善自己 DataOps 的流水线，没有选择从头开发一个数据管道，而是联合原 Waterdrop 社群孵化 Apache SeaTunnel 项目。例如最近参与 Apache Ambari 项目复活的成员，有部分人的背景是希望将 Ambari 用在公司大数据套件产品当中。从一开始就加入到开源协同的环境里，也就不会出现抱着盈利的目的付出巨大精力以后没有回报的挫折和矛盾了。

当然，虽然把公司的全部营收赌在一个全开源的技术栈能大卖上不现实，但这并不意味着企业就不能从头开发一个开源软件。上面提到的这些可以拿来就用的软件，本身是在商业公司内部作为基础支持服务开发，由于公司并不需要依靠他们盈利，进而出于开源协同对质量的促进、生态的建设和声誉的积累等优势，将代码开源。这其实也是《大教堂与集市》当中论证为何应该开源的一部分，在这些情况下，开源并不会损害公司的利益。

最后，生产开源软件的参与者们到底还是一个一个具体的工程师。不是每个人都必须要创建公司，不是每家公司都必须要做得像微软那样大。Vue.js 的作者尤雨溪曾经透露他通过 Patreon 接受捐赠和其他途径获得的收入，在 2016 年就已经超过在 Meteor 和 Google 的收入。前端圈子的曝光量和捐助习惯是值得学习的，可以看看其中几位的 Sponsor 情况。

其中，由于重度使用 @squidfunk 的作品 Materials for Mkdocs 作为网站框架，我发现一些关键的功能只在 Insider 版本当中才有，作者实现得很好，而我没有时间精力在开源版本上做出一样好的改动，这就促使我也成为这 407 个赞助者的一员。

最初的 Apache 成员大多有正式工作，Linux 的核心成员乘着 VALinux 和红帽上市的东风分到了相当数额的股票，Netty 的两位核心作者，Trustin Lee 目前在 Databricks 工作，Norman Maurer 目前在 Apple 工作。开源的经历可以是你职场生涯的坚实基础，如果你有尤雨溪类似的投入到社群并积极维护资助关系、生产周边或接受广告的话，开源的声誉也可以为你提供额外的收入甚至成为主要收入。

这些例子的存在说明了“开源”和“云厂商”并不是天然的对立关系。实际上，现实情况是某些商业公司通过在云上打包销售基于开源软件的解决方案盈利，云厂商和部分这样盈利的商业公司有竞争关系。开源本身是一个包容的概念，你不必将自己代入到企业主的视角，在重重假设的基础上参与他们在舆论上的攻讦。