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的生态系统贡献自己的力量。