夜天之书 #55 如何应对云厂商的“搭便车”行为？
书接上回《开源世界当中到底存不存在“白嫖”？》。
另一个经常被拿出来讨论的“搭便车”行为，是云厂商使用开源软件打包成云服务售卖盈利的例子。
为什么 MongoDB Inc. 要说云厂商伤害了 MongoDB 的社群，Elastic、CockroachLabs 和 Airbyte 也紧随其后呢？
•Why are we changing the license for MongoDB?[1]•Upcoming licensing changes to Elasticsearch and Kibana[2]•Why We're Relicensing CockroachDB[3]•A New License to Future Proof the Commoditization of Data Integration[4]
这四篇公告，我在《免费增值的商业模式》[5]当中也提到过。
我想“云厂商的搭便车行为伤害了制造开源软件的公司”这样的说法，是开源的动机不同所导致的。
这些制造开源软件商业公司一开始开发开源软件，是看到了开源软件在技术圈里的传播潜力。从他们的思考模式出发，其他公司想要复刻同样的商业价值，必然会因为跟不上核心团队的研发能力而被市场淘汰。由于分布式系统的部署和运维足够复杂，只要开源软件能够维持 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 工作。开源的经历可以是你职场生涯的坚实基础，如果你有尤雨溪类似的投入到社群并积极维护资助关系、生产周边或接受广告的话，开源的声誉也可以为你提供额外的收入甚至成为主要收入。
这些例子的存在说明了“开源”和“云厂商”并不是天然的对立关系。实际上，现实情况是某些商业公司通过在云上打包销售基于开源软件的解决方案盈利，云厂商和部分这样盈利的商业公司有竞争关系。开源本身是一个包容的概念，你不必将自己代入到企业主的视角，在重重假设的基础上参与他们在舆论上的攻讦。
References
[1] Why are we changing the license for MongoDB?: https://www.mongodb.com/licensing/server-side-public-license/faq[2] Upcoming licensing changes to Elasticsearch and Kibana: https://www.elastic.co/blog/licensing-change[3] Why We're Relicensing CockroachDB: https://www.cockroachlabs.com/blog/oss-relicensing-cockroachdb/[4] A New License to Future Proof the Commoditization of Data Integration: https://airbyte.com/blog/a-new-license-to-future-proof-the-commoditization-of-data-integration[5] 《免费增值的商业模式》: https://guides.tisonkun.org/freemium-business-model/