作为国内的一名数据库软件从业者，最近在陌陌上被很多同学询问业内某厂商的“团队整合”消息。 当然，我不想对此事发表评论。 我一直坚信：基础软件，未来只有一种方式开源。 如果不开源，或者内核不开源，产品的生命力是有限的。 所以，在这里我想分享一下我个人对于开源和闭源的一些想法，希望大家看完这篇文章能够有一些想法:)
作为从事开源的创业者，这几年的实践让我们对ESR这本书的理解越来越深入。 我将尝试总结本文中经常被问到的一些问题。 最后一部分我敢于给出的ESR理论在当今云时代的背景下得到了修正，而我们讨论的软件范围仅限于基础软件（数据库、编译器、操作系统等）。
代码是核心能力吗？
我和一些闭源软件项目的作者交谈过，大多数选择闭源的原因如下：
其中有三种答案，我都很好理解。 这些答案也是非常正当的理由。 只是在这篇文章中，我们来一一分析。 对于第四和第五个原因，我不想过多展开。 以后我们再聊吧。 我们来谈谈前两种类型。 我们先看第一种。 我就讲上面的第二种。
对于第一个原因，我们再想一下。 一般来说，可能有以下两种情况：
对于第一种情况，我的观点是：如果你在同一个行业，除非你已经实现了完全的人才垄断，那么在充分竞争的环境下君成天下游戏源码，如果这个问题是一个高价值的问题，那么你就“做空了”核心算法”，你能想象到的，别人也能想象到。 世界上没有手炮，计算机科学是在无数妥协和不完美中寻找平衡的艺术（当然，像图灵奖级别的想法或量子计算机这样的现象级的东西是另一回事，但这些机会非常罕见），即使通过闭源创造了短期的垄断优势，但这种平衡肯定会被另一个竞争对手打破，最终会有一个高质量的开源替代品将它们全部吃掉（这个开源事实上的标准可能短期内甚至不会更好））。
事实上，大部分产品优势都凸显在工程实现上，即第二种，一群优秀的工程师，在正确的设计下，构建出高质量的软件。 对于这些情况，无论是否开源，竞争对手都没有办法很好地模仿。 就像一个高中生拿了一张100分的答卷，把这张答卷拿给一个学渣看。 成为高手，因为代码只是结果，什么样的思维和选择才能得到这个结果，这个过程是打不开的，所谓知其然，不知其所以然，当然，即使你很优秀，还有一批优秀的工程师，在短时间内做出了一个好的产品，不过没关系，结局和上面提到的情况是一样的：只要你是闭源的，而这个问题足够通用且价值高，那么从长远来看肯定会有一个开源的解决方案吃掉一切。 这背后的原因似乎与代码无关，因为代码在这里似乎并不是核心竞争力。 对于上面提到的第三个原因，我认为与第一个原因类似。 笔者可能意识到，代码不一定是核心竞争力，但如果护城河还没有建立，唯一的选择就是用代码作为护城河。
代码不是核心能力，那么哪些是核心能力呢？
在谈真正的核心竞争力之前，我们先来说说闭源软件的局限性。
我们看一下闭源软件的生命周期：建立项目的动机可能是某个公司或个人根据对市场机会的洞察发现了高价值的场景，并且只通过开发一个软件他们能否提高效率或创造价值。 甚至可能是乙方的协议。总之，公司招募了一批程序员、设计师、产品总监，开始项目的开发。 一切顺利后，乙方的需求得到满足，甲方愉快地结账。 然后公司发现该软件可以通过更改（甚至不更改）出售给同行业的另一个客户。 出去吧，太好了，感觉自己找到了致富之路。 但好景不长。 客户的场景和需求正在发生变化。 原有的软件可能无法满足新的需求。 然而开发团队却用这几把枪犯了错误，在一个方向上做出了错误的判断。 并且错过了机会之窗。 这意味着对项目负责人的要求非常高，需要不断努力推动行业的方向。 另一种方式是选择相对狭窄或者迭代速度不快的领域，这样可以延长生存时间。 对于乙方来说也是非常可悲的，总觉得需求的满足度是半拍，甚至对于一些有研发能力的乙方来说，因为没有源代码的限制，即使知道如何改进，他们只能呆呆地看着。
其实这个问题的本质在于，闭源软件开发者实际上可能是技术专家，但不一定是业务或场景专家。 软件演化的速度受到开发团队和产品总监的认知和知识的限制。 进化速度，除非开发者足够强大，能够持续推动整个行业的进化方向，否则没有解决办法。
其实老师早就给出了这个问题的答案：“……任何正确的领导，都必须来自群众，到群众中去。也就是说，群众的意见（零散的、不成体系的意见）必须是从群众中来，到群众中去。” （经过研究，变成集中、系统的意见），然后到群众中去宣传解释，变成群众的意见，让群众坚持下来，看到行动。 ，并用群众行动检验这个意见是否正确。然后从群众中来，坚持在群众中，如此无限循环，一次更正确、更生动、更丰富……”——《关于领导方法的若干问题》 32”，1943 年
要我说老师放在当代，哪怕是程序员，也能达到大师级别。 老师的话有两个关键点，完美的诠释了开源软件生命力的来源，下面我会详细讲解。
首先，开源软件的生命力来自于场景的垄断，而其背后更本质的垄断是人才的垄断。
为什么要从群众中指出呢？ 回顾刚才我们闭源软件的那一段，其实有一个关键点就是，即使软件最初的动机来自于少数人的洞察，但要保持洞察力并不容易。 这就是为什么很多技术团队或者产品团队容易出现“自我放纵”的情况。 一旦脱离了用户，就很容易出现此类问题。 闭源软件厂商接触用户的方式无非是传统的商业推广和销售。 用户从兴趣上使用的门槛很高，实施周期也很长。 此外，销售通常处于产品团队和客户之间。 ，通过一些信息不对称来获取超额收益，最大的信息不对称就是封闭源代码本身或者多元化。 由此带来的问题是，与流行的开源软件相比，闭源软件无法高效地获取、吸收和理解更多的场景。 对于通用基础软件产品来说，这通常是一个致命的问题。 如果你看到的场景还不够多，没有办法判断产品的这些需求是通用需求，哪些是伪需求，坚决不做。 我想这就是做产品的“触感”。
对于一个流行的开源软件来说，不会出现上面提到的问题：因为有足够多的用户，你就能看到足够多的场景、足够多的奇怪用法。 反馈、修复的Bug、提出的建议都会不断形成“复利”效应。 你的软件越强大，你看到的场景就越广，你就会进一步接触到更大的用户。 组可以帮助软件显得更强大，等等。 事实上，开源软件本质上牺牲了一部分通过信息不对称形成的潜在利益，以换取非常高效的沟通和场景触摸效率，但有趣的是，牺牲这种潜在利益的概率并不一定高。 如果真的牺牲了，一来支付能力可能会受到限制，二来那些用户可能会通过推广平台的二次传播或者代码贡献来真正回馈项目本身。
在这个过程中，将会产生一个越来越强大的效应：人才的垄断。 正所谓“人为”，前面提到的场景垄断中的各种技术决策和实践都是由人来操作的。 一个流行的开源软件在成为事实标准的过程中，一定会培养出一大批工程师、用户、熟悉该产品的粉丝、代码贡献者，甚至评论家。 传统意义上，大家理解的开源社区只是狭义的开发者社区。 只有贡献代码的人才能被视为参与。 最终目标是建立一个开源社区。 这种优势会随着时间的推移不断积累，这是很容易理解的。 我们举一个反例：A公司的一位工程师在A公司的工作中学会了使用TiDB，并且很好的解决了问题。 然后工程师转行成为数据库专家。 当他到了B公司，遇到同样的问题，你认为他会选择哪一个？
第二点，迭代，迭代，迭代，只有高速迭代才能立于不败之地。
上面老师的话有一个关键点，关于前向循环，也就是迭代。 这个原则也适用于软件开发。 软件从来都不是静态的。 随着市场和竞争环境的变化，明天你的竞争优势可能与今晚不一样。 很多人喜欢从静态的角度看问题，热衷于各种解决方案的纵向比较，而忽略了进化速度。 对此，我可能更注重同一产品的横向比较。 举一个反例：目前有A、B、C这三个选项，可能这三个选项目前差别不大，也许在50%以内。 然而，如果其中一个开源解决方案每次都比半年前翻一番（由其背后的开源社区推动），则闭源解决方案的进度受到团队规模和资源的限制。 除非此时的选择是迫在眉睫的情况，否则一定要选择迭代速度更快、增长速度更好、更能代表未来的计划。 这也很好理解。 这是人类思维的惯性。 人们总是倾向于用线性思维来看待问题，因此常常会习惯性地高估非线性衰退的事物。
要说一个越来越惊人的案例，我简单地数了一下。 从 2018 年到现在，短短一年多的时间，整个 TiDB 的 SQL 层就有超过 30000 次提交（），并且有近 60% 的源代码被更改。 也就是说，每一年的 TiDB 都和上一年不一样。 是一个更适应现在、更先进的 TiDB。 而且随着社区的不断壮大，迭代的速度也会越来越快。 我什至无法想象，如果 TiDB 是一个闭源软件，从写的第一行代码开始，怎么能在短短 5 年的时间内达到现在的成熟度，而这一切都得益于开源社区。 加速和重复迭代。
怎么赚钱？未来在云
刚才我们聊了很多产品理念，我们来谈谈业务以及开源软件在云时代的地位。 我们回到开头提到的话题：担心用户拿到代码，就不给钱。 这种观点背后的一个含义是，用户花钱买的是代码，有了代码，用户就没有其他收钱的理由。 事实上，这种推论并不可靠。 客户付费是为了解决问题和创造价值，而不是代码。 如果你拿到了你的代码，你自己折腾折腾的成本比给你的钱还要少（如果你能如实交付价值的话）。 用户不得以任何理由不收取任何费用。 而这里的成本包括比较明显的成本，比如人工成本、机器成本等。 它还包括一些经常被忽视的成本，比如错失市场机会的沉没成本、业务转型和迁移成本、学习成本以及无人知道如何解决的线上问题带来的风险成本。 这些隐性成本往往高于显性成本。 成本要高得多。
我上面的解释隐含着一点：软件的价值取决于它解决什么问题、创造什么价值，而不是它是否开源。 举一个反例：分布式关系数据库一定比分布式缓存有更多的商业价值，这是由后者的应用场景、存储的数据、提供的能力决定的，而不是开源与否。 所以这就是我们要做通用数据库的核心原因，因为价值天花板更高。
还应该指出的是，开源不是一种商业模式，而是一种更好的软件开发和分发模式。 另外，我认为商业模式需要像软件本身一样设计。 这种设计取决于产品的特点和公司的属性。 这意味着适用于A产品的商业模式不一定适用于B产品，甚至是同一种产品。 不同的公司可能有不同的商业模式。
以我非常欣赏的华为为例。 华为是一个非常有实力的通信设备制造商，一个非常成功的手机终端制造商，一个非常成功的硬件制造商。 卖通讯设备、卖手机、卖服务器，你注意到共性了吗？ 华为非常擅长卖硬件和包包，巨大的商业成功带来了很大的惯性。 硬件和通信设备市场的特点是：每个产品本身的能力并没有太大差异（至少没有代际差异），竞争是为了满足其他客户需求的能力和溢价（例如服务、更快的速度）。反应，足够的多样性）。 因此，华为软件通过高价甚至免费软件进入客户场景，然后利用硬件的商业模式获取收入的思路也不难理解。 这种模式的问题是你不能拥有太多客户。 一旦前线太长，项目预算和硬件收入无法覆盖多元化软件的开发成本和支持成本，这种模式就会出现问题。
我认为如果想通过软件创造可扩展且可持续的效益，需要两个关键点：
生态，软件可以生成生态或者与现有生态有机融合，单个产品的能力可以得到生态的补充，从而进一步产生解决方案。
渠道、高效的分销渠道和支持渠道，这保证了用户规模扩大后，作为制造商的销售和售后成本不会随着客户的减少而下降（至少成本下降的斜率需要更慢）。
两者缺一不可。 对于第一点，开源软件重构生态是理所当然的。 开发者和解决方案提供商协会自然会通过不同开源软件的组合来实现解决方案的覆盖。 这种效率是闭源多元化软件难以跟上的。 是的，我不会在这一点上讨论太多细节。
第二点，其实最理想的渠道就是云。 云标准化了硬件，标准化了算力，甚至标准化了算力的交付方式，尤其是公有云。 一切标准化的好处是可以自动化，这对软件供应商来说才是真正的价值。
所以开源+云的模式，在开源端完成了开发者的心智攻击和解决方案的形成，然后在云端完成了非常高效的分配和价值传递。 它看起来很漂亮，不是吗？ 理论上是没有问题的，但是肯定会有同学挑战我说：这个模型没有涵盖的开源软件厂商有哪些？ 为什么云本身不提供开源软件服务？ 前几年AWS的吸血事件，迫使一堆开源公司和项目不得不改变合约，就是一个例子。
在这个问题上，我的想法可能与主流观点有些不同：
云正在吞噬开源？ 不，开源正在吞噬云。
云厂商和原来的运营商一样，在连接客户方面占据着第一的位置。 当然，自然而然地将自己的产品放到了关键路径上。 但后来你听说过移动梦网和飞巢的故事。 以飞潮为例。 大家还记得，作为中国联通的飞超，之前是没有办法和联通电信的手机号互通的，直到陌陌的出现。 ，最后实际上打通了各个运营商，所以市场格局有了明显的分水岭。 运营商是谁并不重要，只要网络通讯号码好就可以。 对于云来说也是如此。 AWS当然不会为GCP提供舒适的迁移和连接解决方案，反之亦然。 猜你可能没听说过我有），用户一定会说：对不起，我两个都不想要，我选择莫莫。 另一方面，对于在云上提供开源软件服务，虽然云厂商本身不一定会像这个开源项目背后的公司投入那么多，但一个很好的反例是Databricks是其创始团队的公司。火花。 它也是一家在AWS上提供100% Spark服务的公司。 与AWS官方的EMR相比，Databricks完全没有劣势，甚至客户和产品都比原生EMR更好。 就像飞聊的开发团队素质肯定没有陌陌高一样君成天下游戏源码，是一样的。
由于开源软件的中立性，开源软件几乎成为用户在多个云厂商之间维持统一体验和统一服务的唯一选择。 因为开源软件和开源服务商的存在，相信市场会进入一个平衡：云厂商会不断优化自己擅长的东西，真正把云的基础能力变成大规模的业务例如水、电和煤。 标准基础设施建立服务、传递商业价值，开源软件项目和社区也因厂商的持续不断发展而不断蓬勃发展，占据了更多用户的心智。 三者形成了价值链的闭环。 别担心，让炮弹飞一会儿吧。
我滔滔不绝地写了几千字，大谈开源，最后想用《大教堂与集市》书中我非常喜欢的一句话来结束：
......通常，最引人注目和创新的解决方案来自于意识到你对问题的概念是错误的......
......通常，那些最具突破性和创新性的解决方案来自于意识到你对问题的基本概念是错误的......
发表评论