一直以来，资本市场常以药品研发来类比软件研发：两者都需要在前期投入巨大的不确定成本研发新品，一旦研发成功，通过专利授权和垄断销售带来的利润，不仅可以覆盖之前投入的研发成本，甚至还有巨大的盈利空间。
其中，新品药物盈利的关键就在于专利保护和垄断生产。一旦配方公开并且允许仿制药流通，药品的价格就会显著下降。由于药品的公益特性，一般而言药品专利会有时间上限，超过时间上限后即成为公共知识可以仿制生产销售。在专利期内，药品研发公司通过前述手段收回成本保持盈利。
商业软件的研发类比大抵相同。企业雇佣开发者做出专有软件之后推向市场，通过收取垄断的授权费和维护费用收回成本实现盈利。目前，没有专门的法律规定软件发布后一定时间内必须公开源码，允许任何人使用。然而，软件开源即扮演了这样的角色：向所有人公开软件源码，允许任何人出于任何目的使用、修改和发布修改后的版本。
药品专利的盈利模式会受到仿制药的直接挑战，同样地，软件专利的盈利模式也会受到开源决策的直接影响。
其中最明显的是，如果软件用户直接使用开源版本或开源替代即可完成需求，他有什么动机为开发软件的创新厂商付费呢？
我在供职某家商业开源企业期间，就遇到过跟着客户一起做概念验证（POC），到验收签约阶段，客户发现此前支持他们完成整个项目的所有软件都可以公开获得，因此提出质疑式感谢：既然你们已经开源了所有的软件，并且我们已经知道如何基于这些开源软件构建解决方案，后续我们自己实施就行，不会再继续付费了。当然，POC 阶段的辛苦费还是可以结一下的。
这与创新企业预期的商业模式显然格格不入，POC 的收入也无法覆盖软件研发的费用。自那之后，这家企业就把所有公司发布的制品全部附上 All Rights Reserved 字样，确保用户不再产生误解。
在这个模式下，不仅是创新企业的具体商业实践会存在挑战，更致命的是，它在逻辑上就存在不可调和的问题：如果你为客户提供的价值来源于开源软件不够好用，而你能提供专家服务和软件维保，那么迭代改进开源软件，就是在跟自己的营收模式做对。
换一句简单的话说：用户的付费点是开源软件不够好，一旦你把开源软件做好了，用户就不用付费了。
这种模式在 Java 大数据生态上体现的非常明显。叠床架屋的解决方案体系，一个组件进来一大家子就进来的风格，没人能搞懂的运维和配置属性，都是确保营收的"护城河"。没了我，你还真就用不了了。
最近刚被 IBM 以 110 亿美元收购的 Confluent 显然深谙此道。几位创始人在 LinkedIn 公司开发了 Kafka 项目，捐赠给 Apache 软件基金会保证项目的供应商中立性后，出来创办 Confluent 公司，并在完善已有的功能以后，所有新功能均只在上游提供接口，而实现由 Confluent 公司提供。甚至就连不同软件的客户端，即使开源，也是放在 Confluent 公司的名下，而不再捐赠到 Apache 软件基金会。其他供应商 10 倍 100 倍的碾压开源 Apache Kafka 的时候，Confluent 就像典故中的刘邦一样，大喊"分我一杯羹"跟着拿出自己的商业版本，一起碾压一起爽。
这个挑战，在 Akka 修改软件协议，从 Apache 2.0 转向 BuSL 1.1 的文章[1]中写得非常明白：太多人直接拿着 Akka 就用起来了，既然开源开箱就用得那么好，那自然是感谢加再见，付钱免谈。Akka 的著作权人 Lightbend 公司选择 BuSL 1.1 协议，类似前述药品专利限期的做法，在版本发布 3 年后，对应代码即可以 Apache 2.0 协议被使用，即超过限期之后允许自由仿制。可以阅读我此前写的《商业源码协议为何得到 HashiCorp 等企业的垂青？》了解关于 BuSL 1.1 协议的更多信息。
其次的一个问题就是，即使你能够接受有能力自己用起来的用户不付费，只要是符合开源标准定义的开源协议，都允许你的同行（竞争对手）直接复用你的软件，同样向潜在客户提供服务。
运用药品研发的类比，即厂商可能管不到也不想管，你作为个人自己真的对着配方把药物合成出来自己服用，毕竟个例寥寥无几，不影响整体盈利局面。然而，如果你是同行药企，拿着配方大喇喇地仿制，不仅价格更低，还声称自己做了改良，比原厂更好，而新的配方是秘密，并不公开。这种情况下，创新厂商（原厂）受到的挑战就是直接且剧烈的。
软件开源同样面临这个问题。想必各位并不陌生某些从来不在开源社群当中出现的供应商，到客户面前一面大谈自己的软件如何兼容开源标准，一面又对开源实现极尽贬损之能事，说得开源软件一无是处漏洞百出，而自己的 fork 版本上全部做了修复，还提升了性能，还有维保。真是不买不行。
在这种竞争下，创新厂商同样面临上面的窘境。如果在开源版本上修复了对应问题，竞争对手拿去就用，反正你修等于我修，你不修我修了以后也不贡献回去，反而到客户面前说你没能力修。如果创新厂商也不再修复，而是推出商业版本，只在商业版本上提供修复，这就跟前面提到的 Confluent 一样，分我一杯羹大家一起踩开源软件了。
ELv2 和某些厂商运用 BuSL 1.1 协议的做法，就是出于类似的考虑：禁止竞争对手基于开源版本提供商业服务。其中 ELv2 是为这类需求量身定制的，要求不得提供"与原始软件具有相同功能的产品"，并且禁止破解被授权密钥保护的功能。关于 ELv2 协议，可以阅读我此前写的《Elastic License 2.0 与开源协议的发展》以及文中提到的相关链接了解更多信息。
那么，我不支持软件开源吗？
答案是否定的。我认为在可能的情况下，开源自己创造的软件依然是推动技术进步和创新的重要力量。
在《开源孪生：商业开源的模式实践》一文里，我提到商业软件无需开源、回馈商业软件中的开源依赖，以及公共库应当开源等几个核心观点。今天，我与合伙人一同开发的 ScopeDB 没有开源，我们选择了与药品研发类似的商业模式：通过专有软件授权，提供云上专有服务、维保支持等收回成本并实现盈利。
然而，我们在开发 ScopeDB 的过程中，衍生出了多个公共库，这些库均以 Apache 2.0 协议开源发布在 GitHub 上，供所有人使用和参与。在更广泛的开源社群，我们还从 ScopeDB 的用例出发，为 Rust 标准库提交了多个补丁，共同发起 Apache DataSketches 项目 Rust 版本并全力投入其实现。
只要确定好自己的盈利模式核心，所有生态合作的部分，反而越是开源协同，越是能以最小的成本撬动起最大的杠杆，同时也让自己的标准和理论通过开源社群传递到方方面面。其中最重要的，或许是避免走上"诱导转向"的错误路径，即先用开源骗到合作，再因为前面提到的核心冲突仓促闭源，消耗公众信任浪费公共资源。
ScopeDB 开发过程中重度使用并积极维护的 fastrace 库，开源出来的 logforth 库和服务于异步编程的 mea 库等等，我都想不到它们需要闭源的理由。公共库本身没有销售价值。相反，它们需要被广泛使用和认可，才能跟着庞大的用户群体一起存续下去，保证公共库本身不会因为缺乏维护而腐化，进而成为商业软件的潜在风险。
这其实才对应了 Eric Raymond 在《大教堂与集市》的《魔法锅》一文里下的论断：
如果你希望闭源，唯一合理的原因是你想把这个软件卖给别人，或者防止竞争者使用它。答案很明显，你在保护销售价值。但 95% 的软件写出来是供内部使用的，在没有销售价值的可言的情形下，从闭源中还能得到什么好处？
参考资料
1
文章: https://akka.io/blog/why-we-are-changing-the-license-for-akka