原标题：开源是免费的，维护也是免费的。
一个资源库的供养需要一个村子的努力
我认为，把开源软件做为礼物献给世界的某个人，不会觉得负有为你维护软件的责任。一些项目的确声明了责任，但是不能仅仅因为有人在GitHub上发布了项目就说明责任被自动授予了。我想，更多的责任应该在于使用该项目的人。将要使用它的是你的代码，你的代码需要更新、你的代码将要崩溃。在你开始使用一个资源库或框架之前，你应该考虑以下问题：
· 这个软件取决于谁？它的依赖的依赖项是什么？它们更新合理吗？资源库在用类加载器、字节码做着奇怪的操作、搞乱了运行时吗？这些情况更有可能出现在你的语言或运行时的新版本里。
· 除了使用另一个或自己写，我使用这个资源库或框架能得到多少好处？
· 这个资源库写得不错吗？有对代码做全面测试吗？通过测试了吗？
· 作者建议你用在生产环境中了吗，或者它只是概念验证(proof of concept)或探索型想法？
· 作者有过维护开源软件的经历吗？他们自己使用吗？如果我想增加一个特性或修复bug，作者乐于接受，或者它是“没有开启pull request的开源”？顺便说一句，这是不错的，意味着当你的需求偏离时，你需要维护自己的fork。
· 我和老板的风险容忍度怎么样？
· 我有时间、且征得了老板的许可、有能力来自己维护或优化这个资源库吗？
· 如果有必要，这个资源库通过安全审查了吗？
· 作者有谈到API的稳定性吗？
· 项目的issure tracker执行情况怎么样？作者有响应，或者他们不再参与了？
· license和软件的其它部分兼容吗？
· 最近一次的重要提交是在什么时候？整个项目存活了多长时间？
· 有相应的用户社区吗？有邮件列表吗？
· 我正在编写的代码的预计使用周期和危险程度怎么样？
一旦你考虑清楚了这些问题，你将对所使用的资源库继承下来的风险有更好的理解，还有项目的极有可能的未来方向。如果你决定采用了，那么我建议你加入邮件列表，在GitHub上关注它，以随时关注更新变化。
可替代的依赖项的选择
拉取一个依赖项应该是经过深思熟虑的，可以先看看其它选择：
· 如果你仅仅需要非常少量的、相对简单的代码，在license允许的前提下，只把代码拷贝到你的项目就可以了。
· 确保标准资源库没有提供类似的功能。如果它只是另一种依赖项的包装库，那么你可以直接使用那种依赖项吗？
· 如果为了某种数据结构而在拉取另一种依赖项，那么是否存在一种可替代的算法，你可以使用不需要这种数据结构的算法吗？
· 存在一些应该你自己编写的代码吗？虽然这不总是最好的选择，有时候为了满足你的质量标准，也没有其它选择了，你需要自己来构建。
· 有一个商业化的选择吗？开源是免费的【注1】，维护它也是免费的。给维护软件的其他人员支付费用，将增加他们继续为你维护的动力，这可能是很多公司最好的选择。