今天下午要参加一个开源方面的研讨会，所以这两天考虑开源的事情比较多。在国产数据库领域，被诟病得比较深的就是开源和套壳。在不少数据库产业从业者和用户眼里，开源和套壳是一码事，是受到大家排斥的。似乎只有完全自主研发的数据库产品才能算是真正的国产数据库。
我的观点可能无法代表这些人，因为我的看法是截然不同的。昨天我也说过，数据库产品研发是要奉行长期主义的，没有十年二十年的沉淀是无法开发出一款成熟的数据库产品的。如果你准备今天开始，花上五年时间从0开始做一个数据库产品的研发，再用五年时间在市场上推广与打磨，二十年后你的企业可能可以开始盈利。我想很难让资本能够青睐你，而你自己掏腰包拿出几个亿甚至十几个亿来打造这样一个产品，有没有可能呢？有没有用户可能为你当第一个用户，品尝一把数据库小白鼠的味道呢？可以想见，完全自研的道路肯定是十分艰辛的。国内也真的有这样的老牌数据库企业，二十多年磨练出了一个自主研发的数据库产品，正好借着信创的东风，开始起飞了。不过如果你从现在开始重复这个故事，那注定是更加艰辛的。
开源社区以丰富的用户资源，大量的贡献者，可以大大缩短数据库产品的研发周期，如果完全依靠自主研发，自行营销，一款产品可能需要十多年的打磨，那么现在在广大的开源社区用户的帮助下，打造一款成熟的开源数据库产品可能只需要3-5年时间。如果你利用开源生态来开发数据库产品，那么产品的成熟周期至少会缩短一半。只不过开源数据库产品想要实现盈利也是十分有挑战性的事情，在国外的开源数据库产品的生存空间相对舒适一些，主要是国外存在大量的有着长期主义的资本加持，另外客户的知识产权保护和付费服务意识比较强，因此还存在大量的商业变现机会。而国内的开源生态环境对于开发者更不友好，想完全依托开源数据库产品盈利，难度更大。即使是国外的开源数据库厂商想要纯粹通过开源生态盈利，而不是通过一些商业化运作来收割用户，也是很难做到真正盈利的。因此国产数据库的开源之路走得并不平坦。
拥抱开源，并不是一定就要自己做开源数据库，还可以当开源数据库社区的下游厂商，利用开源数据库产品封装或者发展自己的商用版本。这就是被大家诟病得最多的“开源套壳”。实际上我也是赞同国产数据库厂商利用开源代码“套壳”国产数据库的，因为这一条较为快速的发展国产数据库产品的路子。如果一个数据库产品完全自研需要10年时间，起码开源社区帮我们缩短了五六年时间，让数据库产品的研发周期缩短，成熟度也有了极大的提升。比如我们要利用Postgresql社区版去封装自己的企业版，那么只要做好自研代码的管理，自研代码部分能够随着社区版代码的升级而持续升级。一些实力较强的企业也可以基于某个版本的社区版开发自己的数据库产品，不断地迭代代码，完全脱离开源社区。
只要你的产品能够遵守开源协议的要求，比如GPL协议的数据库，你修改了数据库之后，也能够继续开源代码，如果你用了BSD协议的数据库的代码，你能够根据开源协议要求保留BSD的版权声明，那么你的商用版就是完全合法的。如果让我选择两款国产数据库，一款是自研了三五年的，一款是基于开源数据库封装了两三年的商用版，我可能会首选后者。
但是鼓励国产数据库厂商使用开源代码并不是支持“完全套壳”，而是希望我们的数据库厂商在产品中拥有大量的自主价值。比如高可用架构的集群计算框架、強一致性读写分离、数据库兼容性提升、性能优化、解决开源代码中存在已久的顽疾等。总之你不能完全白嫖，也要有自己的原创，并且能够反哺开源社区，对开源社区有所贡献。哪怕能力有限，贡献不了关键代码，发现几个BUG，优化优化文档也是应该的。
在基于开源社区版的企业版的功能上，你必须有自己独到的地方，必须让用户有掏钱购买的动力。如果你的收费的商用版功能和社区版差不多，你还想收钱，那么你必须拥有强大的服务能力，能够让用户能够为你的服务能力付费，否则你的商用版的收费就失去依据了。
总结一下今天所说的观点，赞同拥抱开源，使用开源代码来加快国产数据库产品的研发与发展。但是你要利用开源代码挣钱，那么就要体现出你的价值了，让人能够为你买单。不必要纠结数据库产品是否使用了开源代码，也并不是使用开源代码就比完全自研低人一等。只要好用、安全、可靠，那么出身并不重要。
