AliSQL · 社区动态 · 关于开源之后评论的评论
Author: 丁奇
背景
AliSQL在云栖大会宣布开源，并有幸请到MySQL之父、MariaDB创始人Monty一起见证。
我们在将消息公布到社区之后，也同时关注社区的反馈。以下是对于评论的评论。
handshake protocol
声音：以阿里的个性就是大多数开源了 push 到 github 后面就不怎么管了
其实这么说的人并没有真正全面的去看阿里开源的趋势，大家会看到这几年的分支维护的是越来越健康的。“后面就不怎么管“，这里的“后面”说得很有艺术性，除了天地之外没有什么东西是保证天长地久的。活跃三天和活跃三十年，只要停下来，你说的“后面”就都是对的。如果以这个为标准，那么不只是中国的开源分支，全世界的开源产品都是到“后面”就不维护的。
因此我们眼中的健康的开源会是什么样呢？我觉得最重要的是态度，然后是天时地利。 态度是：我们把开源分支和维护作为我们的一个小理想在保护。只要条件还允许，我们会持续维护。天时地利是：那些条件。
以 AliSQL 的开源策略来说，我们希望节奏上是RDS线上经过验证的、稳定使用的patch才发布到开源分支。所以我们可以保证的是，只要阿里云RDS的业务在，这个分支的维护就会持续。 大家会看到我们接下来会每个季度至少发布两个Release Notes，把我们认为稳定的和有足够应用场景的patch发布到开源分支。 本次发布开源代码同时我们发布了新的Release Note，增加了TokuDB和秒杀场景功能 支持。
声音：Release Notes 里两个版本号竟然是一样的
其实版本号不同，你需要把发布日期也一起带进去看。AliSQL的版本策略是这样的，我们会持续 rebase 到官方最新或次新的GA版本，但是AliSQL要保持自己的更新节奏，因此我们的版本号格式是官方base版本+（发布日期）。
这样的好处是大家从版本号可以得到足够的信息，包括与自用 MySQL 的版本对比和分支活跃情况。
声音：issue#2 ~ issue#7 是什么鬼👻？也是 KPI 的一部分？
并不是所有事情都要跟 KPI 挂钩，尤其issue里的“赞”，没有意义。 作为分支管理者，对于外部参与者的称赞，我们只能表示感谢，然后关闭。难道还可以删除吗？话说好像 GitHub 也没有删除发言的功能，只能修改，总不能修改别人的评论。
至于内部的同学，在 issue 发“赞”我们是批评的。因为在github上最直接的赞，是Star；最有直接价值的赞，是提问题和改进建议；最有长远价值的赞，是提需求或者pull request。 比如上周末 @DarkiT 同学提的建议“建议官方帖个标准的my.cnf的配置” 就非常好，感谢。我们已经在 wiki 上更新了三个不同规格的推荐配置。
声音：就不能把优化合并到官方 MariaDB 或 MySQL 么？
如果所有的patch都能合并到MariaDB，我们又何必这么麻烦再单独维护一个分支呢。如果可以而没有这么做，MariaDB的创始人Monty肯定是第一个提出反对意见的。
实际上的情况是：
- 我们会把能够合并到MariaDB或MySQL的patch提交上去。这篇文章 里面提到的patch，其实就都是提交到MySQL，并已经被5.7合并入主干的patch；
- 有一些patch是不够general，但是我们觉得对某个垂直场景有效果的。
这里举个例子，AliSQL里面有 COMMIT_ON_SUCCESS 这个hint，作用是，如果带此hint的语句执行成功，事务就默认提交。这个有什么好处呢？正常的使用方法是更新、等待成功、发commit。加这个hit可以减少事务提交的最后一次交互，在系统压力大或者网络较长的场景下，这是可以减少事务持续时间，提升整体吞吐量的。
这样的 patch 其他分支未必会接受，但对我们自己和我们的用户来说，在一些场景下是有效的，我们就去维护。
展望：从公司力量到社区力量
“事实上很多成熟的开源项目都是商业公司主导或贡献的”（from @incompatible)，此句为真相。 同时，我们也看到，一个成熟项目一定是社区力量一起来完成的。因此我们真诚希望在GitHub上能够看到pull request、功能需求、IDEA、测试结论。
相信每个公司的DBA都偶尔有这么一个想法：要是MySQL支持xxx这个功能，我就爽了。但是没有开发和维护能力？没有关系，提到issue中，如果这是一个在某个方向足够通用的需求，我们或者社区其他开发者，会去实现的。
阿里云RDS团队有没有做这件事情的驱动力呢？ 有的，以现在RDS的用户量和覆盖场景，你的需求，也一定是一部分RDS用户的需求。