开源框架的采用最好计算好成本

在java社区（包括javascript社区），几乎每过一段时间就有一些开源的新东西冒出来。新的开源的项目大家直觉上会认为总是会带来免费的价值，而且新的应该更新。的确，开源的精神非常有意义，甚至是IT行业新的驱动力。但具体到一个开源产品应该怎么采用，个人认为还是应该斟酌一下。开源可以有各种原因，某种标准或者体系的参考方案，某些产品的替代品，或者是只是开源者解决了特定的问题以后愿意贡献给社区。假如使用者在开源项目中恰好找到自己面临的痛点问题的解决方案，那是最好不过的。因为你知道开源者要干什么，而且关键是可以评判它的方案。但是对于其他人来说，这个开源方案可能距离痛点还有距离，或者说还没有看到明确的投入产出比，直接大规模使用的好处是让人怀疑的。也许找一两个小项目尝试下，加以评判是最好的方式。要不然就最好等待开源稳定，最佳应用方案浮出水面。大的项目起码得一两年。

比如最新的一个时髦是项目编译中使用的gradle，起码在android的项目中是标配。貌似gradle解决了maven配置中没有脚本的灵活性，可以认为结合了ant的某些特点。但是实际上问题是在maven应用的场景里80%的情况根本就不需要扩展脚本。为了少部分需求搞一个全新的框架好处有多少呢？关键的问题是gradle也有不少开源产品的缺点。一方面引入了特有的convention和一系列配置技术，因此带来了转移成本。另一方面，引入了使用中新的错误。当一些错误信息非常简单甚至误导使用者的时候，使用者完全无从得知如何解决，这实际上有很大的使用代价。jsf 和struts早期版本就是典型例子，信息的不完备就是非常突出的问题。对于一个开源产品来说，底线应该是把出错信息搞得怎么完备都不为过，否则最好还是对其敬而远之先。不等其成熟就上手是有风险的。

对于一个新的方案，最激进的方式是重新来一套。好一些的选择则是提供向前兼容的弹性，比如gradle兼容maven。最不济也应该提供非常完备的提示信息。但是无论怎样，综合成本都要重新计算。软件的目的是解决问题，但条条大路通罗马。解决问题的方案实际上和成本有关，也许新的框架通常提供了一些好处，但是他带来的成本可能仍然大于“旧”的方案，那么旧的方案完全可以继续使用。实际上个人以为在一个比较长的时期内，所谓新旧都是相对的。开源的一些新的方案扣除学习成本以及开发成本，新的方案的好处在相当时期内并不明显。