序言
今年的双十一对阿里巴巴中间件消息团队来说，注定是个不平凡的日子。在这一天，稳定性小组重点攻克的低延迟存储解决方案成功地经受住了大考。整个大促期间，99.996%的延迟落在了10ms以内，极个别由于GC引发的停顿在50ms以内，对于读写比例几乎均衡的分布式消息引擎来说，这一结果无不令人兴奋。甚至可以毫不夸张地讲，即便拿到明年的Java one大会上，也必定是场非常吸睛的技术干货分享。接下来，团队同学会把相关的经验提炼总结出来，期待能在接下来全球Qcon大会上为小伙伴们带去尽可能多的干货分享。
除此之外，更让大家倍感欣慰是我们终于为赢得世界的尊重，拥抱世界走出了第一步，这一步走的着实不易，每走一步，回头看看，都是记忆满满。正所谓，桥曾坚固，但已坍塌；路虽沧桑，但已破旧；街曾繁华，但已被拆；巷虽深远，但已变旧。唯一不变的，是那生命里留下的深深脚印。
初衷
捐赠最好的项目给Apache~ 这个想法，最早是14年中旬，在开发maven dependency mediator这个开源组件的时候冒出来的。当时，为了解决中间件组件依赖问题，我研究分析了业界最主流的开源方案，有Maven官方的，也有民间的，甚至研究了Gradle的解决方案，很可惜，不知道是不是我们写代码相比老外比较随意，还是说我们的规模达到了让组件依赖熵混乱不堪的境界，必须自己着手撸这么个*（平心而论，这些年为各类国际开源社区没少贡献ISSUE或者PR。但即便如此，心中那种撸*的”恶念”时不时会浮现）。于是乎，着手写了这么一个组件。接下来问题来了，怎么去维护，怎么做能够持久的去演进这款组件？相信喜欢撸*的童鞋都有这样的经历，产品从0到1容易，再从1再到0可就难了去了。放眼望去，这方面做的最棒的无非就是FastJson了，这么些年的坚持，为大家带来了极尽优化的性能（不仅性能，功能方面也不落后于同类产品）体验。能够持久专注，不断演进才应是我辈应该追求的开源情怀啊。
回过头来，我们再来看这个maven组件项目，为了能够吸引更多的外籍朋友反馈，专门写了一个长篇E文，系统化介绍怎么做二进制兼容依赖，从最初的设计编码，到运维部署都有一套相对体系化的方案探索出来，为此还曾想过发表专利来保护下这块，不过后来因为事情多也就搁浅了。到此，我们发现，上面提出的让人纠结的问题还是没有解决，这个项目怎么发展？因为之前的调研过程中，从maven的Codehaus，也就是maven最大“非法”（非官方）插件集散地得到了一些灵感 - 捐赠给它。Okay，接下来，结果大家也看到了。这个小项目发展到1.0.2版本的时候，被我搁浅了（说实话，这个项目的代码质量在当时那种情况，算是不错了。但我要吐槽一下Maven自身的单测框架和集成测试框架，问题还是挺多的。不管如何，如果有童鞋希望展这个项目，可以联系我，截止目前，放眼望去，业界还是缺少这么一个好用的兼容检测组件，这里面还是有一些非常好玩的想法我没有精力落地掉：-））。为什么搁浅？因为当时自己的工作重心主要在分布式消息引擎、消息推送这块，并且也是公司这块几个中间件的贡献者以及负责人。能不能聚焦一下，那些工具撸起来固然爽快，但后续的发展着实让人操心。俗话说，众人拾材火焰高。能不能找几个技术好手把分布式领域的精髓都体现在某个产品中，和当时消息团队的负责人誓嘉（非常低调的厉害家伙:)）闲暇时间聊起来，聊到这块，聊到开源，聊到分布式技术，聊到业界分布式消息引擎，聊到它们未来的发展。随后，再随后，方向渐渐明晰了，于是便有了捐赠Apache这个现在看来最最基础的一步。
我个人是比较喜欢聆听批评，尤其是足球和开源这块，等等，姑且先抛开中国男足，今天只谈开源。有很多人讲，国内的开源氛围不好，很多都是只谈绩效，沽名钓誉，尤其是几个大厂甚至把风气都带歪了。即便开源了，设计、源码、文档、社区也是很难持续跟进。不可否认，这样的事实也许存在。但今天，我们把RocketMQ放出来，就是想给大家一个证明，一起来看看由内而外，然后再由外而内这种模式到底能不能行得通。我们彼此心里非常清楚，开源与商业化相辅相成，水可以载舟，也可以覆舟。产品、技术、商业如何能够打好配合，激发出1+1+1大于3的价值来，这也是我们今年思考最多的问题。
MQ简介
RocketMQ是阿里巴巴在2012年开源的第三代分布式消息中间件，不仅在传统高频交易链路有着低延迟的出色表现，在实时计算等大数据领域也有着不错的吞吐。开源至今，社区参与度非常高，国内拥有超大规模的活跃交流群，ISSUE上更是收录了来自全球数百个高质量的话题交流以及问题沉淀。除此之外，在产权保护、知识输出这块，有着接近20篇专利的沉淀。去年，RocketMQ获得了中日韩开源论坛CJK OSS大奖，今年早些时候又进入欧美主流开源门户网站Awesome-java视野，意味着RocketMQ正式走出国门。也正是基于如此卓越的表现，为后续Bruce，Brian等欧美大拿引路Apache奠定了良好的群众基础。
在它之上，我们构建了自己的内部版本MetaQ，还有云产品MQ。经历了几年线上近乎苛刻的场景验证，在双十一当天消息容量达到万亿级的体量。这中间，有不少小伙伴默默地付出着（这里面还有一个小插曲，社区的朋友为感谢RMQ项目，捐赠了近500 RMB，不过我们把这些钱一次性捐赠给公司的公益事业啦:) ）。而今天，我们将这些毫无保留的开源出来，就是为了让更多人受益。阿里巴巴是个很讲究感恩的公司，我们取之于开源不在少数，是时候体系化地反哺社区了。什么样的社区能让Alibaba的产品走上更健康的道路呢，思考来思考去，还真只有Apache。相信在Apache这个平台上，没有人会去偷懒，没有会想着走捷径。今天也只是一个孵化项目，想不想毕业，能不能毕业，完全取决于我们对于开源精神的理解和诠释。我想，应该没有人会拿名族大义开玩笑吧（呸呸呸，扯到这上面来了。其实就是要给公司以及国内的同行们带个好头，做个表率，争口气:) ）。毕竟，我们代表中国，代表中国最先进，最执着的那批技术探路者。
捐赠历程
接下来，进入重点。一起看看Apache的整个捐赠历程吧。整个历程始于2014年，终于2016年（这里用终于不是很妥当，我们只是刚开始走上正路而已）。想法可能天天有，但怎么落地，尤其是这个想法的落地，非常具有挑战。在研究Apache官网关于捐赠流程的文章后，我们甄选了几位MQ方面非常有经验的老美，和他们聊聊吧。在很诚恳的给他们讲述了我们希望捐赠给Apache的诉求，Brian（ActiveMQ PMC member，Groupon CTO）率先答应了会帮助我们。接下来，开始准备Proposal呗。很快，初稿就出来了。经过和Brian反反复复几次沟通，不断修改，算是有点模样了。这时，问题来了，我们失去了和Brian的联系。虽然说老外非常喜欢度假式放松，但这次回来可真联系不上了。就像断线的风筝那样，我们无所是从。接下来，大家也看到了，这件事情基本上被搁浅了。在John（JCP专家组成员）的邮件里，他也用folded out这个词来问我，到底是什么原因让你们中途搁浅了呢。Okay，搁浅的原因讲清楚了。接下来，时间来到了2015年。通过朋友的引荐，结识了Kylin的总架构师蒋旭（技术上任何牛逼的词都可以往上贴，非常低调的榜样）以及在Apache上的主推手Luke（非常Nice的一位GG，Kyligence联合创始人）。又在Apache 亚洲路演北京站和他以及后来也是我们的Mentor之一的姜宁（Apache多个项目的PMC member,committer）进行了交流，请教了一些禁忌事项。至此，我们捐赠进程又活跃了起来。再后来呢，Luke和姜宁也成为阿里巴巴RocketMQ IPMC国内的两位mentor。不仅如此，他们也欣然接受了阿里巴巴weex团队的邀请（具体牵线人应该是我们可敬的JStorm负责人纪君祥:)），继续在Apache进程中为我们“保驾护航”。说到这里，最最重量的小伙伴要等登场了。除了mentor，我们还需要征集最最重要的champion候选人。Brian这条线断了，需要我们再挖掘一位贵人相助。这个时候“大拿“Bruce（ActiveMQ in Action的作者，这里我不想过多描述他在开源领域的杰出贡献，感兴趣的童鞋可自行google）出现了。给我印象最深的是Bruce一上来就问了我5个“究极”的问题：
是否了解Apache 孵化进程，是否知晓ASF 项目的一些基本要求
是否联系过其他Champion
是否联系过其他Mentor
是否联系过Apache ASF Membe
进入Apache后，RocketMQ会怎么发展
当然，回答这些问题应该不成问题。但从这几问题看得出来，Bruce非常有经验，也非常有心的在尝试帮助我们。此后的岁月里，我们保持着高频度的邮件来往，前前后后大概接近100封吧。考虑到时差，这一来一去，也就2个月过去了。期间又恰逢Bruce金婚19年（由衷的祝福），中间出去旅行了一阵子。很快，一个重要的日子来了。一天，Burce问我”准备好了吗，我们即将开启Apache之旅“。我的回答也毫无犹豫，”Let’s Go~“一切都在平稳的向前推进着。双十一当天，迎来了投票。预料之中的是，社区非常活跃的John对我们提出了几个犀利的问题，对我们的社区数据提出了疑问。本着实事求是的原则，我公开邮件加私信的方式将事情的原委和他一一道来，疑虑担心算是打消了。这里面还有一个小插曲，在大家”交涉“期间，来自Apache董事会的President和Vice chirman也来帮我们说话，用文化差异，包容性等帮我们解困。真的要非常非常感谢他们。
现在回想起来，John为什么会问那几个犀利的问题，主要原因来自他也是ActiveMQ PMC成员，要知道我们网罗了3位ActiveMQ的VP来帮助我们。而且按照Bruce的建议，Proposal里加入了和Apache ActiveMQ和Kafka的客观对比。我的妈妈呀，这一举，为我们带来了这么多不必要的麻烦。在咨询了Bruce之后，我们的Proposal并没有删除这个对比，但是稍微聚焦了一下我们的优势。就这样，看似平稳的投票朝着非常好的方向发展了。
这还没完。接下来，更有意思的事情出现了，Apache Trafodion项目的Release Manager开了一个专题，题目为 - China Contribution. (was: RocketMQ Incubation Proposal)。我的妈妈呀，这跟RocketMQ有毛线关系，实在看不下去了，适时地发表了我的见解。在这个讨论里，大家主要聚焦的问题是Trafodion项目里，来自中国的contributors喜欢用QQ，而不是邮件进行沟通，这让他们很是头疼。说到这，大家想必也看到了，国内其实还是有很多非常乐于开源的同学活跃在Apache社区的。另外，由于标题太过于刺眼，好玩的事情出现了。中国人嘛，看到有人扯到跟中国开源相关的事情，大家不乐意了。Luke，姜宁，陈亮（华为Apache Carbondata孵化项目负责人），包括Databricks那个华人GG，都发表了防御性“声明”。由于各种原因，中国人无法邮件，无法google，所以才。。。最后的结果大家想必也猜到了，不可能有结果，没有结果可能就是最好的结果。所以这里给大家的建议就是，如果希望让国外的小伙伴参与进来，就试着把自己的英语拾起来吧，注释，讨论以及一些必要的文档尝试用英语，本地化社区可以有非英语支持频道！
经过了这么多折腾，投票结果总算出来了，还不算坏 - 10票带binding的+1，无反对票，正式进入孵化期。孵化成功后有望成为国内首个互联网中间件在Apache上的*项目，成为全球继ActiveMQ，Kafka之后，分布式消息引擎家族中的重要成员。此次捐赠，也意味着以MQ为代表的互联网中间件在新兴物联网，大数据领域会发挥着越来越大的作用。另外，我必须提一下，虽然目前大数据技术”横行当道“，尤其以Spark和Hadoop为阵营的各大开源平台层出不穷（看看近些年那些最活跃的那些Apache产品）。小伙伴要当心，大数据背后的那些分布式技术都是相通的，看问题学技术要掌握本源，只有掌握了最根本的，在技术广袤的海洋里，你才不会迷失。另外，也正是通过这次Apache之旅，让我深刻意识到在社区里面，有着大量的MQ 爱好者，如果能激起这些久经沙场的国外大拿的共鸣，那么这势必将是一个充满竞争力的社区。
从这些经历中，大家可以清晰地看到，捐赠从想法酝酿到成型，再到落地，前前后后接近一年半。中间也经历了各种曲折。回过头来看，这些都是宝贵的财富，团队也在不断反思和总结。整个投票过程，团队核心Committer全程参与，很好的近距离体验了Apache Way，为后续其它产品的输出奠定了坚实基础。
MQ未来
再接下来，也是我最想分享的。Apache RocketMQ接下来如何发展。大家知道，我们在云上围绕着RMQ做了云端版本的消息引擎MQ，像发送者事务，消息轨迹这些功能都是集成在MQ中的。一个初具规模的软件产品，一般都会有社区版和商业版两种授权。RocketMQ和MQ两者之间，也是这样的关系。所以也请大家理解我们在开源版本和商业版本之间的不同发展路线。这两者如何能够相互配合，互相补充，共同繁荣，在全球都是一个不易解的问题。不过，我们可以承诺，只要是团队开源出来的，一定是在阿里久经考验的臻品，而且质量会越来越好，越来越趋向标准化。除此之外，为了更透彻的响应Apache社区关于多元社区文化的理念，在新的contributor和committer这块，我们会加大力度扶持、甄选具有开源情怀的童鞋，无论国籍，靠谱即可:) 能在大数据技术林良满目的今日，国内自主研发的互联网中间件从中杀出一条血路，向着拥抱全球规范的道路前行。这条路不容易走，但方向对了，就不怕远~
心动不如行动
到这里，希望那些有志于打造世界*互联网中间件的同学加入我们，帮助我们，监督我们，让我们一起打造全球最棒的消息引擎（不仅如此，我们还有更好玩的产品在后面），携手拥抱分布式领域最值得期待的规范体系。
路才刚刚开始，如果还有梦想，那就带着灵魂出发吧~
方向，节奏，专注，激情~
Alibaba 冯嘉
写在RocketMQ Apache捐赠投票后的第三天，终稿于11.22晚