阿里作為一家技術公司，一舉一動牽動業界的發展。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
End
最近開源界有點小風波，先是Redis、Neo4j更改了軟體協議，然後Kafka緊隨其後，最近連Mongodb也忍不住將協議改成了SSPL。佛性程式設計師可能心理不平衡了，不想再免費付出了。
阿里對開發者的這些傷害，可能是無意的，因為亞馬遜也在幹同樣的事情。但開源閹割版產品，鋪天蓋地的正向宣傳，是有意為之。有了阿里雲這個造錢的機器，很多東西都會變味。
不要覺得開源軟體是免費的，和商業公司講情懷，還嫩了點。這麼做也無可厚非，但是當了婊子還想立牌坊，未免就太無恥了些。
