阿里作为一家技术公司，一举一动牵动业界的发展。2013年，阿里搞出去ioe的概念，旨在消除对他人的依赖。而现在，它自己却通过变卖开源产品，绑架企业，充当了类似ioe的角色。
相比较一些国际知名的开源软件，阿里的开源软件文档不全、功能阉割、失久未修，很没诚意。它唯一目的就是让你买它的阿里云服务，哦，即使买了服务也有无限的内购。
阿里的开源软件还是不要玩，大多是为了商业宣传。小公司或者个人的软件能通过长期的口碑，逐渐将优势显现；而影响力比较高的阿里之流可能会为了短期利益混淆视听，将坏的唱成好的。
怎么正确使用阿里开源的软件呢，我这里有个建议。
像一些工具包之类的，比如fastjson、druid等，可以放心使用，因为替换容易；像一些低频使用的，工作量堆彻的软件如DataX，也可以酌情使用；而像一些企业级的应用，可能要持续数年的重要技术栈，比如dubbo，就要小心一些，说不定啥时候就撂挑子不干了。
当然也是有分别的。像RocketMQ因为进了apache，就比较照顾自己的面子。即使这样，社区版的和内部的版本之间，也有不少的差别。
通常都是雷声大雨点小，天天开分享会。发布个初始版本以后，就太监了。所以，使用阿里的软件要慎重。为了消除项目长期的技术风险，对此公司开源的东西，要充满戒备。
评估标准
最后更新时间
通常，源码都会放在github。可以看一下代码的最新更新时间。当然这个更新不是随便的，更新一个readme文档不算更新，要看是不是重要功能和bug修复。
当然更新时间还和项目的新旧有关，比较新的项目参考价值小。你要随便用了，需要承担风险。
比如tddl，7年前的代码了。你要用了就上当了。
Star数
star数其实是大家的关注度，并不是判定的唯一标准。2018年，阿里的员工有7.4w。如果有十分之一的员工star了他们公司的项目，就有7千多星。再加上每年离职的流动人口，这个数值就呵呵了。即使这样，大多数项目关注度并不高。
star数量能够看出项目的欢迎程度，但大型公司的项目要打折。
项目来源
有些项目确实是公司内部孵化出来的，比如Canal等。但大多数是拿了别的公司的开源软件，修了一些bug，做了一点改进，然后加个前缀当作自己的作品。
这类开源软件不想着通过正规途径去反馈社区，也不能肩负起后续的维护工作。一般都是为了非常私人的或者团队的目的，要么生命周期很短，要么转向闭源。它通过发展分支的方式，滥用影响力，干扰原开源软件的发展，合法但是不道德的。
典型的如AliSQL、AliRedis、以及最新的spring-cloud-alibaba，搞到最后只能适应自己的云环境，最终为商业化服务。而开发者真正能从中得到的成本和便捷，非常有限。
文档
如果只有简单的几行文档，加上铺天盖地的开发者大会宣传，不用也罢。当然如果你有大把的时间也可以搞一下。
讲原理的文档是最优的；讲用法的文档是有诚意的；啥都没有是正常的；讲成就和吹牛皮的文档是最次的，大家要有分辨力。
点到为止，是大公司的特色。否则教会了徒弟饿死了师父，开源的目的就变了。
pin功能
github的pin功能是将自己觉得好的项目置顶到最上面，我们看下阿里置顶的是啥。
社区口碑
issues的数量和心跳图的比率。还可以在各社区问一下大家的看法。
版权声明
这个就算了吧，阿里不遵守，我们也很少有人遵守。
后端项目替换
推荐
工具类的就不提了，推荐用或者能用的有：canal、fastjson、druid、rocketmq。
其他的，就算了吧。像什么核心中间件比如数据库中间件、文件服务器、缓存等，是不给你用的。
比较有争议的
dubbo
RPC框架。文档和社区不错。
可惜，躺尸后又诈尸的项目，你不确定什么时候又躺尸了。已经透支了很多公司的信任。
替代品：Spring Cloud，功能即丰富又稳定。
AliSQL
内部有用和牛逼的东西，不见得社区会买账。可能用的更多的还是RDS，小公司是可以玩的，上点规模应该想着怎么去掉它。
替代品：MariaDB、MySQL
spring-cloud-alibaba
微服务框架，二次封装。建议使用原生Spring Cloud。
End
最近开源界有点小风波，先是Redis、Neo4j更改了软件协议，然后Kafka紧随其后，最近连Mongodb也忍不住将协议改成了SSPL。佛性程序员可能心理不平衡了，不想再免费付出了。
阿里对开发者的这些伤害，可能是无意的，因为亚马逊也在干同样的事情。但开源阉割版产品，铺天盖地的正向宣传，是有意为之。有了阿里云这个造钱的机器，很多东西都会变味。
不要觉得开源软件是免费的，和商业公司讲情怀，还嫩了点。这么做也无可厚非，但是当了婊子还想立牌坊，未免就太无耻了些。
