CSDN|基础软件，未来只有开源一条路？

本文插图
作者 | Ed Huang 责编 | 郭芮作为一个在中国的数据库软件从业者，最近被不少朋友在微信上询问业内某厂商「团队整合」的新闻，我其实并不想对这个事情发表什么评论。我始终坚信：基础软件，未来只有开源一条路。如果不开源，或者说内核不开源的话，产品的生命力是有限的。所以，在这里想分享一些我个人有关开源与闭源的看法，希望大家看完这篇文章后能够有些自己的思考 :）作为从事开源的创业者，这几年的实践让我们对于 ESR 的这本书的理解更加的深入，我会试着在这篇文章总结一些我们经常被问到的问题，最后一部分我斗胆给 ESR 的理论在当今云时代的背景下做一些修订，另外我们讨论的软件范围仅限于基础软件（数据库，编译器，操作系统等）。
代码是核心竞争力吗？我和一些闭源软件项目的作者聊过，大多数选择闭源的原因不外乎以下几种：

觉得自己的核心算法非常厉害，不希望竞争对手模仿；
担心用户拿到代码，就不给钱了；
没有找到或者建立自己的护城河；
代码太丑，不好意思开源；
怕被人找到 Bug 。

其中以前三种答案居多，我非常能理解，这些回答也都是非常正当的理由，只是这篇文章我们好好的就事论事的挨个分析一下，对于第四第五个理由，其实我不想过多展开，未来有机会再聊聊，我们聊聊前两种，先看第一种，我在后边会聊聊第二种。
对于第一种原因，我们再深入思考一下，一般可能有下面两种情况：

我的核心代码很短，可能是一个很巧妙的算法，或者一套很巧妙的参数；
我的工程上的设计和实现得很优秀，系统架构是领先的。

对于第一种情况，我一直以来的观点是：如果在同一个行业里面，除非你达到了彻彻底底的人才垄断，那么在一个充分竞争的环境，如果这个问题是一个高价值问题，那么你能想到的短短的「核心算法」，别人也同样能想得到。天下没有银弹，计算机科学就是在无数种妥协和不完美中寻找平衡的艺术（当然，图灵奖级别的 idea 或者量子计算机这种现象级的东西另说，但是这种机会是很少见的），即使通过闭源创造出短期的垄断优势，但是这个平衡一定会被另一个竞争对手打破，最终也一定会出现一个优质的开源替代品全部吞掉（这个开源事实标准短期看甚至不一定是更好的）。
其实多数的产品优势是体现在工程实现上，也就是上面的第二种，一群优秀的工程师，在正确的设计下，构建出优质的软件。对于这种情况，无论开源还是不开源，竞争对手都没有办法很好的模仿，就像一个学霸，考了一个100分的答卷，把这个答卷给一个学渣看，学渣朋友肯定也没法马上变成学霸，因为代码只是结果，是什么样的思考和选择得到了这个结果，这个过程是没法开放的，所谓知其然不知其所以然，当然，就算你也很厉害，也有一批优秀工程师，短时间也做出了一个不错的产品，但是没关系，结局和前面提到那种情况也是一样的：只要你是闭源的，这个问题又足够普遍且高价值，那么长远来看一定会有一个开源的解决方案吞掉一切。这背后的原因其实和代码没有什么关系，因为代码在这里其实并不是核心竞争力。关于前面提到的第三种理由，我认为是和第一种类似，作者可能认识到代码并不一定是核心竞争力，但是没有构建好护城河的情况下，只能选择将代码作为护城河。
代码不是核心竞争力，那什么才是？在聊真正的核心竞争力之前，我们来聊聊闭源软件的局限性。我们看看一个闭源的软件的一生：立项的动机可能是某个公司或者个人对于一个市场机会的洞见找到了一个高价值的场景，通过开发一个软件能够很好的提高效率或创造价值，甚至可能就是一张来自甲方的合同，总之这个公司招募了一伙程序员，设计师，产品经理，开始项目的开发。一切顺利的情况，顺利的满足了甲方的需求，甲方也很开心的付钱了，然后这个公司发现，好像这个软件改一改（甚至不用改）也就能够在同行业另一个客户那边卖出去，这就太好了，感觉找到了一条致富路。可是好境不长，客户这边的场景和需求在变化，原来的软件可能不一定能够满足新的需求了，但是开发团队就这几杆枪，稍有不慎一个方向判断错误，可能时间和机会窗口就错过了。这就意味着，对于项目领头人的要求就很高，要求持续能够引领行业的方向。还有一种方式是挑选一个相对狭窄或迭代不快的领域，存活时间能够延长一些。对于甲方也很难受，总是感觉需求的满足慢半拍，甚至对于有些有着研发能力的甲方，因为受限于没有源码，就算知道如何改进，也只能干瞪眼。其实这个问题的本质在于：闭源软件开发商虽然可能是技术的专家，但是并不一定是业务或者场景的专家，软件进化的速度受限于开发团队和产品经理自己的认知和见识的进化速度，除非开发商强大到能够持续引领整个行业的进化方向，否则无解。其实这个问题，教员早就给出了答案：「…凡属正确的领导，必须是从群众中来，到群众中去。这就是说，将群众的意见（分散的无系统的意见）集中起来（经过研究，化为集中的系统的意见），又到群众中去作宣传解释，化为群众的意见，使群众坚持下去，见之于行动，并在群众行动中考验这些意见是否正确。然后再从群众中集中起来，再到群众中坚持下去，如此无限循环，一次比一次地更正确、更生动、更丰富…」 — 《关于领导方法的若干问题 32》, 1943 要我说教员放在当代，就算是当个程序员，也能是一个大师级别的。教员的这段话，包含两个关键的点，完美的解释了开源软件的生命力的来源，我下面的详细讲讲。第一点，开源软件的生命力来自于场景的垄断，而背后更本质的垄断是人才垄断。为什么强调从群众中来？回顾刚才我们闭源软件的那段，其实一个关键的点是，软件的初始动机虽然来自于少数人的洞见，但是持续保持洞见并不是一件容易的事情，这就是为什么很多技术团队或者产品团队容易「自嗨」，一旦脱离用户，极易出现这样的问题。闭源软件厂商触及用户的手段不外乎于传统的商业宣传和销售，用户从感兴趣到使用起来的门槛很高，实施的周期也很长，另外通常销售会站在产品团队和客户中间，通过一些信息不对称来获取超额的利润，其中最大的信息不对称就是封闭的源代码本身或者定制化。这导致的问题是，相比流行的开源软件，闭源软件没有办法高效的获取，吸收和理解更多的场景，这对于一个通用的基础软件产品来说通常是一个致命的问题，如果见过的场景不够多，更没有办法判断产品那些需求该做是普遍需求，哪些是伪需求坚决不做，我认为这就是做产品的「触感」。对于一个流行的开源软件，本身不会有上面提到的问题：因为有足够多的用户，那么一定能看到足够多的场景，也能看到足够多的稀奇古怪的用法，这一个个用户的反馈，修过的一个个 bug ，提出的一个个建议，会持续的产生类似「复利」的效果，你的软件越强壮，见过的场景越广，会进一步让你接触到更大的用户群，帮助软件变得更强大，如此循环。实际上开源软件本质上是通过放弃一部分通过信息不对称产生的潜在利润，换取了极其高效的传播和场景触及效率，但是有意思的是，实际上牺牲掉的这些潜在利润大概率也不一定真的牺牲掉，一来可能本身付费能力有限，二来可能实际上这些用户通过宣传站台二次传播或者代码贡献等方式回馈了项目本身。在上面那个过程中还会产生一个更加厉害的效应：人才的垄断。正所谓「事在人为」，上面提到的场景垄断中种种的技术决策和实践都是人来操作的。一个流行的开源软件在变成事实标准的过程中，一定会培养出大量熟悉这个产品的工程师，用户，摇旗呐喊的粉丝，代码贡献者，甚至挑刺吐槽的人。传统意义上，大家理解的开源社区只是狭义上的开发者社区，只有贡献代码才算参与，但是我认为只要和这个产品发生关联的人，都算是社区的一部分，「人尽其材」才是构建开源社区的终极目标。这个优势是会随着时间的流逝不断累积，这个很好理解，举个例子：A 公司的工程师在 A 公司的工作中学习使用了 TiDB 也很好的解决了问题，然后这个工程师作为数据库专家跳槽到了 B 公司，遇到同样的问题时，你猜他会选什么？第二点，迭代，迭代，迭代，只有高速迭代才能立于不败之地。上面教员的话里面有个关键的点，关于正向循环，也就是迭代。这个道理同样也适用于软件开发，软件从来都不是静止的，随着市场和竞争环境的变化，你今天的竞争优势，很可能明天就不是了。很多人都喜欢用静态的眼光看待问题，热衷于各种方案的横向对比，而忽略了进化速度，在这点上，我可能更看重的是同一个产品的纵向对比，举个例子：目前有 A, B, C三个方案，可能当下看这三个方案差距不大，也许在百分之五十之内。但是如果其中一个开源方案每次和自己半年前比都是在翻倍的提升（背后开源社区推动），但是闭源的方案的进步受限于团队规模和资源。这时候的选择除非是那种火烧眉毛的情况，否则一定应该选择一个迭代速度更快，增长率更好，更代表未来的方案，这个也很好理解。这是人的思维的一个惯性，人总是倾向用线性思维去看待问题，于是对非线性增长的事物往往会习惯性的低估。说一个更加震撼的例子，我粗略统计了一下，从 2018 到现在，也就短短一年多时间，整个 TiDB 的 SQL 层这么一个项目发生了 30000 多次提交（https://github.com/pingcap/tidb），有接近 60% 的源码被修改。也就是说，每一年的 TiDB 都和上一年是不一样的，是一个更适应当下的，更加进步的一个 TiDB ，而且随着社区的不断壮大，迭代的速度会越来越快。我完全不能想象，如果 TiDB 是一个闭源软件，从第一行代码开始写，到现在短短的 5 年时间，如何能够到达现在这个成熟度，这一切都是得益于开源社区的带来的加速度和反复迭代。