开源的缘起、传承与商业未来
原文链接 https://tisonkun.org/2021/12/14/the-cathedral-and-the-bazaar/
历时五天，我总算把《大教堂与集市》这本经典的开源文化著作认真读了一遍，真是酣畅淋漓。
本书是作者 Eric S. Raymond 的文集，其中最著名的一篇就是《大教堂与集市》，其他几篇分别是《黑客圈简史》《开垦心智层》《魔法锅》和《黑客的反击》。最有价值的是《大教堂与集市》和《开垦心智层》两章，系统解释了开源软件是如何生产的，开源开发的优势在哪，开源软件的传承是如何做到的。《魔法锅》解答了一些常见的关于开源软件使用价值和销售价值的问题，但是受限于时代背景，对商业化的讨论局限在夸大使用价值的部分，不能很好的指导基于开源软件提供软件服务的商业模式。
在进入具体的内容讨论之前，必须着重提到译者卫剑钒对中译本创造的价值。翻译是对原内容的二次创作，软件开发领域外文著作众多，大部分译本都让原文表意有明显的损失。卫剑钒翻译的《大教堂与集市》，阮一峰翻译的《黑客与画家》，以及云风翻译的《程序员修炼之道（第二版）》是我近一年来读过的本领域最佳译作。
开源协同的优势
《大教堂与集市》一章主要讲的就是开源协同的优势。集市模式就是开源协同的模式，本章的要点在于论证这种模式能够生产出高水平的软件，以至于超过任何商业公司闭门造车的软件。原文的论述重点在同行评审的价值，辅以拥有用户的重要性，落点在如何以集市模式领导开源项目。出于讨论流畅性的考虑，我把前两点的顺序调换然后展开。
拥有用户
对于任何软件来说，获取用户都是一个艰难的生存挑战，持续的用户反馈能够帮助软件不断修正前进方向，没有用户也即意味着软件的死亡。开源软件能够在早期发展阶段吸引到足够的注意力和用户。
一种形式是如原文作者继承 popclient 项目，从而直接继承其用户群。这在商业公司开发的软件当中是不容易做到的，因为涉及到专有软件的所有权转移，总是非常的繁琐且挫败的。大部分商业公司开发的软件，一旦因为种种原因不再维护，往往无法为人所继承而是彻底死亡。
因此，如今的用户对全新的专有软件往往抱有很强的怀疑态度。例如，最近一段时间迸发出来的新兴数据库软件，如果我无法获得它的源码，那么我如何能够自由地探索它呢？成熟的闭源商业软件辅以用户手册或许没有这个烦恼，但是软件的更替是不可避免的，新兴软件刚出世时，往往欠缺文档，功能不全，只有阅读源码甚至加以修改才堪堪能用。这种情况下，开源软件不是比闭源软件更好的问题，而是只有开源软件才能生存下来的问题。
此外，围绕开源软件或软件群形成的开源共同体有内部共通的价值观。如果你制作了一个新的开源软件，在潜在的用户群组里发帖介绍自己是不会被排斥的，如果软件质量不错，还会得到用户的自发传播。例如，我在 GitHub DCO App 异常期间，顺手开发了一个基于 GitHub Actions 的方案并在原 issue 下评论介绍自己的解决方案。没有回复会认为这是恶意竞争，而是出于解决问题的群策群力。又例如，Engula 项目开发过程中，向 Rust Community 和其他相关主题的资深开源开发者均寻求过意见和建议，其中认可 Engula 项目价值的人，就会自发的传播它。这对于商业软件来说是不可想象的，如果上面的行为替换成一个闭源商业软件，则参与者会认为你是一个销售人员而不是黑客同行，并且对一个完全黑盒的全新解决方案兴趣寥寥。
最后，开源软件不会将自己的用户局限在销售关系以内，这往往能保证软件开发者有更强的主导能力，按照符合软件工程的方式开发高质量软件，而不是在需求爆发的压力下将软件绑定在单一用户的需求上。
同行评审
同行评审是原文论述的重点，实际上，集市模式的核心价值就在于跨越组织边界的独立的同行评审验证设计和保证正确性。原文将其称为“Linus 定律”，即
如果有足够多的 beta 测试者和合作开发者，几乎所有问题都会很快显现，然后自然有人会把它解决。
不过针对这个定律有两点需要解释。
第一点是它所强调的是独立的同行评审实施的简单性和有效性，而不是单纯的“人多力量大”。
开源开发的价值之一就是源代码公开使得任何人都可以分析代码逻辑以定位问题。时至今日，传统的研发组织仍然把开发人员和测试人员区分成两个竖井，测试人员几乎只能完成黑盒测试。可想而知，缺乏分析的现象型 bug 报告往往需要耗费开发人员相当多的时间重新验证、复现和定位。如果让对源代码一无所知的测试人员为 bug 定级，则两类人员之间的冲突会更加尖锐。
开源开发打破了这种困境。由于大家都有真实的源码，开发者和测试者很容易发展出一个共享的表达模式并进行有效的交流。一个现象型 bug 报告和一个直接关联到源码的分析型bug报告，对开发者解决问题的帮助简直是天壤之别。Linus 定律建立在开源开发的基础上，强调的是拥有源码以后加入新的眼睛的成本不在包含商业公司管控带来的限制和摩擦，从而能够从基数足够大的同行评审当中获取高价值的报告。
原文引用《人月神话》的 Brook 定律，提到随着开发人员数目的增长，项目复杂度和沟通成本按人数的平方增加，而工作成果只会呈线性增长。对于这个论点，原文作者是认同的。但是，开源项目所采用的沟通方式，区分成少部分核心开发人员与由 beta 测试者和潜在的贡献者组成的外围人员。外围开发者实际工作在分散而并行的子任务上，他们之间几乎不交流；代码修改和bug报告都会流向核心团队，只有在那个小的核心团队里才会有 Brooks 开销。
这揭示了开源开发的精英领导制内核，也解释了 Linus 定律虽然常被简化成“只要眼睛多，bug 容易捉”，但是却不是简单的“人多力量大”。
第二点是开源软件当中出现 bug 是正常的。这一点过于天经地义以至于当我发现我需要强调它的时候有些震惊。近年来出现的“心脏滴血”和前几天的 Log4Shell 漏洞，导致部分声音认为开源项目的使用是有风险的。
对此，我只能说，这当然啊！软件有 bug 不是正常的事儿么？开源开发不是银弹，任何复杂的软件都会有 bug 存在。Linus 定律成立的案例 Linux 是在高速发展的过程中保持了相对稳定的质量，而不是从来没有 bug 出现。如果你认为开源软件有不可承受的风险，最佳做法是参与其中对它做出改良。
此外，开源软件的许可证往往附带了免责声明，也即这个软件的源代码就这样（AS IS）给你了，没有任何保证（WITHOUT WARRANTIES）。在应用当中整合开源软件之后，保证应用的正确运行与安全性是应用开发者的责任。开源软件会因为安全问题损失声誉，因此作者会尽力提高安全性和正确性，并辅以相应的测试验证，但是这些都是尽力而为，没有保证。
集市模式
《大教堂与集市》一章的落点在如何以集市模式领导开源项目，这种模式相较传统的管理架构有何不同。
其中很多原则和技巧不是开源特有的，并通过敏捷等理念渗透到商业公司的软件开发当中。例如，“好的软件作品，往往源自开发者的个人需要”，“早发布，常发布，倾听用户的反馈”，以及“想出好主意是好事，从你的用户那里发现好主意也是好事”等等。
其中最重要的一点是关于发布的。开发者在需求列表不能调整和最后期限不能拖延的双重要求下，会完全顾不上质量，整个工作很可能会变成一团乱麻。Linux 通过发布两种不同类型的版本，各自宽松其中一个要求来保证软件质量和进度的协调。
一种办法是保持最后期限不变而让需求列表灵活一些，允许某些到最后期限时仍未完成的需求被舍弃，这基本上就是“稳定版”核心采取的策略。 Alan Cox（稳定版核心的维护人）以相当规律的时间间隔将核心发布，但并不保证某个特定bug何时被修复，也不保证实验版中的某个特性何时会搬到稳定版中。 另一个办法是设定好想要的需求列表，并在其完成时发布，这基本上是“实验版”核心的策略。 De Marco 和 Lister 引用研究结果，指出这个进度策略即是“好了告诉我”，这不仅能够保证最高质量，而且就平均而言，与“保守”或“激进”的进度安排相比，它的交付时间更短。
对于与传统的管理架构比较的部分，其理论基础可以参考《开放式组织》与《企业的人性面》相关的论述。概括地说，开源的方式给予开发者足够的自由，以吸引高水平的黑客自发地创造价值。这种超越了对安全需要乃至生理需要的追求的模式，激发的是参与者对社会需要和自我实现需要的热忱。
在这里，没有预设的团队和资源，不需要在办公室环境下吞并其他团队的资源或者对其他团队的进攻做出防守。开源开发者是志愿者，是因为兴趣和能力自主选择的，他们会把自己的资源带到工作中，而不需要关心团队之间的领土争端和倾轧。
在这里，参与者凭借其创造的价值赢得权威。也就是说，最有才华的人能够对项目的发展做出最合适的决定。这不同于雇佣关系下被强制调配的人与项目之间的关系，而是对于特定的人，自由选择适合自己的项目，对于特定的项目，自然筛选出最合适的人。
原文还提到一种观点，即传统开发管理能保证艰苦和乏味的工作总能落实。我想这点毫无疑问是错误的。Linux 和 Kubernetes 的文档充足到令人难以置信，反过来只为了领工资才上班的人往往消极对抗撰写文档和测试或调试问题等工作。
开源共同体的目的是制造高质量的软件，在这个共同目标的引领下，不同方面的人才聚拢起来发挥自己的价值，反而是能够找到对传统开发管理认为艰苦和乏味的工作甘之如饴的人才。对于项目维护者来说，认识到这些所谓“无聊”部分的价值，协同参与者完成它们，是项目能够脱颖而出的必要条件。经过二十年来的经验积累，这逐渐成为最有才华的黑客当中的共识。
最后，对于想要实行集市模式的人，这里转述原文提到的“集市模式的必要条件”。
集市从成立伊始，就需要一个可以运行和测试的东西。当开始建设开源共同体的时候，你需要拿出一个像样的承诺。程序此时并不需要特别好，它可以简陋、有错、不完整，文档可以少得可怜。但它至少要做到能运行，且让潜在的合作开发者相信，这个软件在可预见的未来，能演变成一个非常棒的东西。
项目领导人需要能识别出别人的优秀创意，掌握一定水准的设计和编码能力，并且必须具备很好的人际交往和沟通能力。最后一点应该是显而易见的，为了建立一个开源开发共同体，你需要吸引人们，让他们对你做的事感兴趣，让他们乐于看到自己的贡献。一些技巧可能有助于实现这些，但远远不是全部，你的人格特征也很重要。
开源软件的传承
《开垦心智层》一章讨论开源共同体的发展，以及发展过程中开源软件的所有权及转让的问题。
所有权
原文提到，开源软件的所有权获取有三种形式。
第一种也是最显然的，就是去创建这个项目，当这个项目在开始时就只有一个维护者而且这个维护者仍然起作用的时候，所有权问题是连提都不该提的。 第二种方式是获取前任对所有权的移交（有点像“接力棒传递”）。这在社区中很容易理解，当项目“所有者”不愿意或者不能在开发和维护中投入必要的时间时，他（她）有义务将项目移交给一个有能力的继任者。 第三种方式是一个项目需要维护但项目所有者已经消失或失去兴趣了。如果你想维护该项目，你的责任是努力找到这个“所有者”，如果找不到，你可以在相关场所（比如 Usenet上专注于该应用领域的新闻组）声明该项目似乎是一个“孤儿”，而你想为之负责。
我在协助处理 TiDB 里两个合并子项目的工作的时候，实质上就遵循了这里的原则。原来的项目由多名 contributor 参与完成，在当时的 CLA 设置下，要求每位 contributor 都必须和 TiDB 项目签 CLA 才能合并。比起强硬的改变 commit author 绕过 CLA 检查，我建议尝试联系未签署 CLA 的参与者补上。这些参与者被 at 以后很快响应并且解决了问题。
其实参与开源开发的人不是坏人，在项目没有发展出多样性之前，不要擅自以“内部”“外部”这种二元视角界定参与者的属性，也不要假设“外部”是邪恶的。
分化
原文将分化行为列为开源文化当中的禁忌。分化指的是派生出一个随后不能交换代码的竞争项目，并导致开发者群体的分裂。
黑客厌恶项目分化的另一个原因是，他们惋惜那些被浪费的重复工作分化后的两个子项目总是有着或多或少平行的演化路线。他们也会注意到分支倾向于分裂合作开发者社区，使得两个子项目的人手都比父项目的人手更少。
近年来雨后春笋般冒出来的开源项目，在分支和合作问题上起码有两点值得关注。
第一点是对合作的漠视。相当部分项目，号称开源，实则核心成员还是都来自同一个公司团队，规模往往超不出十几人。他们有很强的领地意识，拒绝其他人的参与，或者将其他人的贡献打包进项目整体说成都是该公司的贡献。这样做，使得不同组织的参与者失去动力甚至有种被驱逐出去的意味，实质上只是源码可得的传统项目开发模式。
当然，也有好的案例，且大多来自公司背景不强的项目。例如 SeaTunnel 还叫 WaterDrop 的时候，就吸引了不同组织成员的关注和参与，现在又被 Apache 成员关注到，合作进入 Apache 孵化器孵化。
第二点是对分支的痴迷。也就是公司喜欢 fork 出来搞个魔改版本，从不考虑 contributing back 还以为自己占了便宜。且不说这种行为禁锢了原本可以参与共同体的成员，代码分化带来的兼容性问题魔改版本从来不能解决。回过头来把魔改版本抛头换面又煞有介事的“开源”，应该被整个黑客社会所唾弃。
如果说还有一点，那就是那些所谓的“开源技术公司”，如果试图对开源共同体实施某种形式的管控，让商业公司凌驾于志愿者之上，那么这样的项目实际上更容易分化。Elastic 和 OpenSearch 就是一个典型的例子。
对于相对开放的民主制度而言，它的一个主要优势在于，绝大多数潜在的革命者发现通过在系统中工作比攻击该系统更容易让自己向目标前进。但如果既有政党联合起来“提高门槛”，导致那些较小的不满意团体觉得更难实现自己目标的话，这种优势就很容易被侵蚀破坏。 准入门槛不高的开放过程鼓励参与而非分裂，因为参与者能从中获得成果，而不用付出分裂所需的高昂成本。尽管这种成果可能不像分裂所得成果那样令人印象深刻，但其成本较低，且大多数人都能接受这种折衷。
冲突与解决
原文提到，项目当中的冲突与解决主要围绕三个问题展开
- 谁来负责做设计决策？
- 如何决定哪个贡献者应该被授予荣誉，如何授予？
- 如何保持项目团队和产品不被分裂为多个分支？
第一个问题由上述所有权问题回答。关于分支的问题在上一节已经讨论过了。现在看第二个问题。
无论采用独裁者模型还是委员会模型，黑客的荣誉都跟他创造的价值相关。也就是说，黑客的声誉在礼物文化的大背景下，由他的贡献即赠与开源共同体的礼物的价值所决定。对于独裁者模型来说，独裁者本人需要能够践行这样的规则，否则高水平的参与者就会选择离开。对于委员会模型来说，还有一个额外的问题是委员会自身应该避免冲突。原文质疑委员会模型难以避免冲突
在这种形式中，我们很难看到内部边界，并因此很难避免冲突，除非委员会内部享有极高水平的和谐与信任。
但是，今天的软件复杂度越来越不支持独裁者模式。如果独裁者本人已经把部分决策权交给参与者，那么他在运行上就类似于委员会的模式。即使独裁者名义上拥有最终决定权，他与维护某一模块的核心成员仍然需要保持高水平的信任以减少项目当中的摩擦。
结合如今一部分商业公司创建或大规模参与开源项目的背景，如果项目建立的是同侪共同体（community of peers），也就是说成员的角色与个体相关，而不是与他在某个组织的职位相关，在这种情况下依然把委员会的人员增加与企业员工入离职挂钩，这种组织形式就是非常危险的。
具体地说，部分项目照猫画虎地搬来了 Apache 软件基金会式的同侪共同体设计，在决定项目 PMC 成员和 committer 人选时，却变成了公司同事入职，“理应”有 commit 权限，就稀里糊涂的成了什么 committer 或 PMC 成员。一旦离职，则完全不理会项目的发展，甚至出于不愉快恶意捣乱项目的日常事务。这就是没有基于项目的需要和个体对项目的认可和贡献选择委员会成员的弊病。
这是说缺乏多样性的项目中，单一公司的员工需要避嫌吗？当然不是。实际上，成为大力投资该项目的公司的雇员，能够尽可能多的时间投入到项目发展上，公司的员工确实有更大的可能性成为核心成员。但是必须注意的是他的推举应该是客观的，基于项目的需要和个体对项目的认可和贡献来选择。只有这样，才能努力做到委员会内部有极高水平的和谐与信任，这才是这种组织形式下项目长久发展的根基。
开源与商业模式
《魔法锅》一章的主题是开源与商业模式，着重讨论了反公地模型，软件的使用价值和销售价值，以及当时存在的开源相关的商业模式。
反公地模型
我曾多次听到有人拿“公地悲剧”来类比开源协同的开发模式，认为后者也会如前者一样失败。
所谓的公地悲剧，指的是假设一个村庄里的所有人都可以不受限制地在一片公共的草地上放牧，如果没有一个共识来抑制过度放牧，出于自身利益的考虑，每个人都会尽可能多的放牧，以期在公地资源耗尽之前从中获取最大价值。
但是，Linux 项目持续三十年，长寿的开源项目比比皆是，这种类比显然是有谬误的。原文从公地悲剧两个必要条件来反驳，一是过度使用，二是供应不足。
公地悲剧的一个必要条件是所有人都放牧会使得草地退化，但是开源软件一旦制造出来，不会因为被过度使用而损失价值。反过来，广泛的使用会提升开源软件带来的价值。这一点很好理解。
公地悲剧的另一个必要条件是没有人会修缮草地，因为公地奖励“搭便车”行为，即你修缮了草地别人就可以无偿分享你的成果，而你的付出别人并不承担，结果是付出比不上被分摊后的收益，于是所有人都不付出。
在开源开发中不会遇到这种情况。这是因为参与者不仅需要解决方案，他们还需要问题被及时解决。因此解决这个问题本身带来的收益就足够偿还成本，而等待别人解决问题则完全无法预期它会在何时被解决。
这部分解释了解决方案必然会被生产出来的问题，但是其创造者为何会无偿发布这个补丁，还需要进一步的讨论。
一方面，很多情况下开发者无法为其确定一个公允的市场价格。另一方面，坐等在补丁上不会有任何收益，反而会带来额外的成本，因为你现在要在上游发布新版本时重复合并这个补丁。由于上游对该补丁的存在并不知晓，这种重复合并甚至有可能是多次重做。毫无疑问，这是非常挫败的。由此看来，只要你需要上游的更新，无偿发布补丁就是最优策略。
但是，这里还有一个问题，如果补丁有足够的差异性，补丁作者为什么不将其闭源以获取其销售价值？对于 GPL 许可的项目来说，项目本身的演化需要与其他各方分享，这不是个问题。但是软件结合的形式有很多，GPL 对软件即服务等方式难以产生约束，还有以其他宽容开源协议如 APL 等许可的项目，这些情形正是当下开源与商业的讨论焦点。
软件的使用价值和销售价值
在讨论这个焦点之前，我们先看看软件的使用价值和销售价值。
软件的使用价值是它作为一个工具的经济价值，软件的销售价值是它作为一个可买卖商品的价值。大部分软件是作为内部系统被生产出来的，原文认为，这个比例达到九成以上。开发者的薪资实际是出于维护软件的使用价值的目的支付的。
如果你创造的软件主要用于内部系统，而你的薪资也来自于维护它的使用价值，那么通过闭源来保护销售价值是没有意义的，因为你不会将它用于销售。这种情况下，通过开源协同来提高软件本身的开发效率和质量，就是有收益的。
值得注意的是，只要软件的开发在隶属于不同组织的参与者之间共享工作流，采用开源协同的开发方式就没有额外的成本，因为公司为了用上这个软件，总是要付出开发成本的。这个共享工作流的前提条件也是《魔法锅》一文成书时未曾想到的，居然还有人为了形式开源而给同一套代码区分出两套工作流。
原文提到两个常见的反论意见。一个是通过闭源代码保护商业机密。这是无稽之谈，主要是代码设计糟糕。通常来说，你应该将机制开源，编写通用的逻辑，而将商业知识相关的策略单独实现。当然，后者并没有什么开源的必要。
另一个是说闭源能够保护软件安全。这也是谬论。除了上面商业机密泄露的场景，对于纯粹的骇客攻击行为，二进制照样能被破解，开放源码只是多了一种破解的手段。
类似近几天的 Log4Shell 漏洞，难道黑客不读代码就找不到这个问题了吗？如果公司内重新实现日志框架，且不说要达到 log4j2 的水平要付出多大成本，以及生态兼容性的种种问题，难道重新实现的软件就没有其他安全问题吗？
即使不说分析源码的破解手段并不比破解二进制的手段轻松多少，可靠的安全性也依赖于算法及其事先经过彻底的同行评审。这么看来，开源软件反而更容易修复安全问题。Log4Shell 通过同行评审发现后通过必要的 private 邮件列表上报，在上游修复后进行披露，正是这种安全同盟的一般做法。
直接收费的问题
当然，上面这些讨论仍然没有覆盖当前这波开源浪潮下新出现的商业公司群体，这些公司创造开源软件，并希望基于它们创造的开源软件获利。
原文对直接收费类型的许可证做出了批驳，指出希望在源代码可得的前提下添加某种收费或变相收费的条款，会遭到黑客的反感，从而失去开源共同体的支持。这是因为这类许可证违背了三个开源共同体的共识。
第一个与对等性有关。大多数开源开发者并不反对别人利用他们的礼物获利，只是不能要求有任何人站在一个特权地位上牟利。MongoDB 的 SSPL 在理念上或许沿袭了 GPL 的一些理念，只是它对形成派生作品的描述“形成服务”太过笼统，得不到广泛的支持。但是 MongoDB Inc. 自己并没有按照 SSPL 的要求开放它的整个服务栈的源代码，这种对等性的破坏遭到了黑客的唾弃。实际上，MongoDB 的核心代码几乎只由其公司雇佣的员工开发和评审。
第二个与非有意后果有关。原文提到，对商业使用或销售进行限制并收费的许可证有着令人扫兴的效果。特别是这条规定给某些分发行为笼上了一层法律阴影，而这些活动正是黑客非常愿意鼓励的事。还是 SSPL 的例子，由于“形成服务”太过笼统，几乎所有黑客都倾向于不分发该软件以避免潜在的法律风险。原文认为，黑客很少在这一点上让步。实际上，这也是 OSI 拒绝承认 SSPL 是开源许可证的主要原因。
第三个与保持礼物文化相关，这也是最关键的一个原因。如果许可证在法律上就禁止产生分支，那么黑客们绝对不会认同这样的条款。原文解释到，虽然黑客们不赞成分支，但是分支是“最后一招”。如果维护者不能胜任或者背叛开源文化，可以通过分支来保护礼物的传递。Elastic 与 OpenSearch 就是活生生的例子，以 AWS 的工程师为首的开发者在 Elastic 转向更加封闭的时候基于开源版本分支并独立发展，保持新分支的开源属性。
开源的商业未来
《魔法锅》随后介绍了当时作者所看到的的若干种基于开源软件的商业模式。这里不需要展开，因为它们都统一在同一个模型下。这个模型就是基础架构和中间件开放，应用和服务收费的模型。
开源基础架构，并利用同行评审的价值，协同跨越组织的参与者创造出类别杀手，做到这点的收益实在太大了。类别杀手指的是即好到没人再想使用其他备选的高质量开源原创项目，例如 Linux 和 Kubernetes 等。
Google 愿意开放 Kubernetes 的源代码，很大一部分原因就是为了联合其他商业公司以及整个开源共同体形成事实标准的垄断，而要做到这一点，开源协同的方式是最高效的。Kubernetes 形成垄断后，越是早期参与项目的组织，越是投入资源大的组织，越能够获得某种程度上的原厂品牌效应，并积累足以应付软件在使用上的种种问题的开发者团队。这些组织通过提供应用级别的定制和维护服务收取报酬。
原文认为应用非常倾向于继续封闭，这种封闭尤其可能出现在自成一体的垂直市场当中，其网络效应也较弱。这其实就是针对特定场景开发的插件或者是针对具体业务接入基础架构的实施。时过境迁，如今的软件复杂度已经不是当年一个全栈工程师从购买服务器到整个网站都能负责开发的年代，雇佣业务实施团队将越来越常见。
这些插件某种意义上也可以算作中间件。实际上，应用和中间件之间的差别会随着时代的发展而变化。原文认为数据库是中间件，但是如今却更被认为是某种基础软件。中间件走向闭源还是开源，取决于软件失效的代价，代价越高，走向开放的市场的压力就越大。
举个例子，AWS 的不少服务是闭源的，但是它们的客户端是开源的。这些客户端就是中间件，如果它们的维护更封闭，那么失效的可能性就会越高。广泛的用户会倾向于使用开源的替代品。一个案例是 AWS S3 的 Rust 客户端 rusoto 和官方后来提供开源版本。
Confluent 依靠提供 Apache Kafka 的服务盈利，整个商业模型包括三个部分。
第一部分是实施，也就是帮助客户业务与 Apache Kafka 对接，乃至于设计整个业务消息平台。这是传统上所说的“外包”工作，由于软件复杂度日益升高，这类工作所需的软件开发技能也越来越丰富，相应的雇佣薪资也就水涨船高。这种模式也被称为订阅，在一个订阅周期内，客户能够获得实施工程师的支持，商业公司在提供工单响应的保障。实施包括支持私有化部署，也包括帮助客户对接云服务。
第二部分是提供基于开源软件的云服务，也就是云上的 Apache Kafka 资源，客户按照使用的节点数或访问量交费，这种模式实际上是商业公司通过出租商业地产盈利。一方面，CPU 和内存等资源本身是成本，用户无论如何也要为这些成本付费。另一方面，商业公司在资源之上提供了消息平台的抽象，屏蔽了部署和运维软件的复杂度，并以此来赚取差价。对于无力自行维护的企业来说，购买云服务就是最优选择。
值得一提的是，这种部署的附加值是工程师水平和硬件成本的函数，云厂商往往能够获取更廉价的硬件成本，因此独立服务提供商最好追求部署和运维本身的开销下降，这种运维和部署的策略是商业机密和盈利的基础。另一方面，可以通过维持云中立，避免供应商锁定等优势，利用云厂商之间的竞争激发用户的优先选择意愿。
第三部分是专有软件，例如 ksqlDB 等。只不过 ksqlDB 的位置更像是接近基础架构的中间件，被 Apache Flink 和 Materialize 等项目挤压了不少生存空间。反观 Apache Pulsar 和 Apache RocketMQ 就没有将类似功能做成专有软件以期销售，避免被其他项目分化用户。
对于哪些软件不适合通过闭源获取商业价值，《魔法锅》一文介绍了应该考虑开放源码的软件，时至今日仍然是正确的
- 可靠性、稳定性、可扩展性非常重要。
- 除了独立的同行评审，没有其他便捷易行的方法验证设计和实现的正确性。
- 该软件对客户的业务非常关键，因此客户期望避免供应商锁定。
- 该类软件受网络效应主导，即你无法实现压倒性的市场控制力。
- 关键方法属于公共知识。
开源与闭源在几乎所有层面上都是并存的，并且呈现出一种动态发展的趋势。
起初，Windows 垄断了操作系统的市场。当 Linux 出现以后，服务端操作系统的份额开始逆转，并且出现 RedHat 等商业公司。原文称为中间件的数据库，起初被 Oracle 主宰，如今它也承受着 PostgreSQL 的冲击，海量提供 PostgreSQL 服务的商业公司也能生存下来。今天，云原生技术和软件即服务的概念改变了软件生产和使用的格局，越来越多的商业公司创造开源软件或参与到其开发当中，目的就是推出下一个类别杀手，并取得之后的软件服务战争的优势。
实际上，最好的商业价值获取方式仍然依赖创造性的垄断，这也是知名商业著作《从 0 到 1》的观点。只不过，软件的复杂度以及开源开发应对这种复杂度在生产力上的显著优势，使得你无法在一个很大的范围内实现垄断。但是你仍然可以找到合适的垂直领域，或者就是为客户做实施——这也许是最垂直的一种方式了。
如今，想要创造局部垄断的一种新方式，是通过开源协同的集市模式创造出一个类别杀手，在此过程中获得某种程度上的原厂品牌效应，并积累足以应付软件在使用上的种种问题的开发者团队。进一步的，将原本的市场格局改变，在不改变固有需求的情况下改变产生商业价值的位置。以操作系统为例，原本商业公司以创造出商业操作系统为竞争优势，Linux 出现后，如何基于 Linux 提供更好的服务，或者看到 RedHat 如今的上云策略，提供海量 Linux 服务器资源的运维和应用的部署服务。
改变不利于自己的商业格局，并在环境有利于自己的时候做好下一次颠覆的准备，才是开源时代的商业未来。我也相信这种形式，能够促使企业家真正成为创新的先锋，而不是被长时间垄断所麻痹，不思进取乃至阻止社会生产力的进步。
