You deserve to be able to cooperate openly and freely with other people who use software.You deserve to be able to learn how the software works, and to teach your students with it.You deserve to be able to hire your favorite programmer to fix it when it breaks.
You deserve free software.
你可以公開、自由地與其他軟件使用者合作，你有權瞭解軟件的工作原理，並將其傳授給你的學生，當軟件發生問題時你完全可以僱用你所喜愛的程序員對它進行完善。
你理應得到自由的軟件。
——Richard Matthew Stallman（理查·馬修·斯托曼，自由軟件運動的精神領袖）
很難想像一個項目不使用開源產品的情形，所有的框架都自己寫，所有的工具類都自己堆砌，所有的運行容器都自己建立——這不是一個健康的項目，這個世界是分工合作的世界，有分享也有貢獻，有索取也有回報，這才是Java人的理想世界，而且我們也正朝著這個方向前進。
不，我不想回到那個沒有Struts、Spring、Hibernate、Tomcat的年代，絕對不想。
建議139：大膽採用開源工具
我們經常會看到一個項目的lib中包含了大量的工具、框架包，要想看懂項目代碼還應該對這些工具包有一個大致的瞭解，開源工具包確實會對我們的項目有非常大的幫助，比如提升代碼質量，減少Bug產生，降低工作量等，但一旦項目中的工具雜亂無章時就會產生依賴的無序性，這會導致代碼中隱藏著炸彈，不知何時就會突然引爆了。
而且，在Java世界中從來就不缺乏重複發明輪子的例子，MVC框架有Struts，也有Spring MVC、WebWorker；IoC容器有Spring，也有Google Guice；ORM既有Hibernate，也有MyBatis；日誌記錄有經典的log4j，也有嶄新的logback。可是選擇多了，也會導致我們無從選擇。因此，在選擇開源工具和框架時要遵循一定的原則：
普適性原則
選擇一個工具或框架就必須考慮項目成員的整體技術水平，不能有太大的跨度或跳躍性，要確保大部分項目成員對工具都比較熟悉，若一個項目中的成員大部分是新員工，那麼在持久層框架的選擇上，使用MyBatis就比Hibernate要合適，因為MyBatis相對簡單、方便；再比如在一個熟悉SSH開發的團隊中，就不應該無故選擇Guice作為IoC容器，除非是行政命令或為了嘗鮮。
唯一性原則
相同的工具只選擇一個或一種，不要讓多種相同或相似職能的工具共存。例如集合工具可以使用Apache Commons的collections包，當然也可以使用Google Guava的Collections工具包，但是在項目開發前就應該確認下來，不能讓兩者共存。
「大樹納涼」原則
在沒有空調、電風扇的年代，最好的納涼方式就是找一棵大樹，躲在樹蔭下享受著習習涼風，愜意自在。我們在選擇工具包時也應如此，得尋找比較有名的開源組織，比如Apache、Spring、opensymphony（雖然已經關閉，但它曾經是那麼耀眼、輝煌）、Google等，這些開源組織一則具有固定的開發和運作風格，二則具有廣闊的使用人群（很多情況下，我們不會是第一個發現Bug的人），在這樣的大樹下，我們才有時間和精力納涼，而不會把大好的時間消耗在排查Bug上。
精而專原則
在武術上，對一個頂級高手的描述是「精通十八般武器」，但對工具包來說這就不適合了，我們選擇的工具包應該是精而專的，而不是廣而多的，比如雖然Spring框架提供了Utils工具包，但在一般情況下不要使用它，因為它不專，Utils工具包只是Spring框架中的一個附加功能而已，要用就用Apache Commons的BeanUtils、Lang等工具包。
高熱度原則
一個開源項目的熱度越高，更新得就越頻繁，使用的人群就越廣，Bug的曝光率就越快，修復效率也就越高，這對我們項目的穩定性來說是非常重要的。有很多開源項目可能已經很長時間沒有更新了，或者是已經非常成熟了，或者是瀕於關閉了，這我們不能要求太高，畢竟開源項目已經共享出了他人的精力和智力，我們在享受他人提供的成果的同時，也應該珍惜他人的勞動，最低的標準是不要詆毀開源項目。
對於開源工具，我們應該大膽採用，仔細篩選，如果確實所有的開源工具都無法滿足我們的需求，那就自己開發一個開源項目，為千千萬萬的Java人服務，也為Java的生態系統貢獻自己的力量。