五金店
最近Zach Tellman和Factual开源了一些资源库，他们想处理根本不存在的具体需求。在Reddit的评论里，有人发牢骚，因为这个软件可能在1-2年内被抛弃，如果他们依赖这个软件，他们将陷入困境。我认为这种想法源于对开源软件的误导和自私的视角。
做为软件工程师，应对开软资源库、应用程序和框架，就像在一家五金店，这是非常有吸引力的。如果你有问题，而标准资源库无法解决，就拉取一个依赖项。需要工具集函数？在GitHub搜索一下，并增加一个依赖项。想发挥最近疯狂流行的单页应用程序？那就拉取另一个依赖项。需要用Ruby处理XML？只需瞬间安装Nokogiri，你可以笑到最后。
或许这可以应付一段时间，但是漏掉了软件工程中最关键的地方：软件随着时间而衰落，也叫熵。软件不是以独立系统的形式存在的，它与其它随着时间而变化的软件交互，包括你的操作系统、内存、其它外部服务、数据库、CPU、网络、IO设备（打印机、显示器）和最重要的因素—用户。这些系统被新的系统取代或更新。有时候变化是向后兼容的，有时候却不是。因此，代码被一次写完、而终身维护。使用某人的开源代码对你是个巨大帮助，因为你不必去写了。然而，随着时间的流逝，状况有所改变，熵就起了作用，代码需要维护和更新了。
一个资源库的供养需要一个村子的努力
除了把开源软件看做五金店，我认为更好的比喻应该是，加入一个村子去供养一个孩子。你拉取的每个依赖项需要随着时间一直维护，还有它所依赖的依赖项，如此往复。这里的问题不是关于维护是否需要去做，而是谁来做。较大的社区有更多的资源和时间来做，成熟的项目已经经过了优化、良好的测试以及具有稳定的API。如果你正忙于新生的、模糊的或快速变化的语言中，那么更多的维护将要压到你的身上。
我认为，把开源软件做为礼物献给世界的某个人，不会觉得负有为你维护软件的责任。一些项目的确声明了责任，但是不能仅仅因为有人在GitHub上发布了项目就说明责任被自动授予了。我想，更多的责任应该在于使用该项目的人。将要使用它的是你的代码，你的代码需要更新、你的代码将要崩溃。在你开始使用一个资源库或框架之前，你应该考虑以下问题：
一旦你考虑清楚了这些问题，你将对所使用的资源库继承下来的风险有更好的理解，，还有项目的极有可能的未来方向。如果你决定采用了，那么我建议你加入邮件列表，在GitHub上关注它，以随时关注更新变化。
可替代的依赖项的选择
拉取一个依赖项应该是经过深思熟虑的，可以先看看其它选择：
最后
开源软件对于程序员的生产力是一种巨大的恩惠，节约了人类数个世纪的努力。但是请记住，正如你拥有自己的可用性，你还拥有你的软件和与此相关的一切。
注1：一切都在发展变化，不断地向昨天告别，满怀信心地投入每一个崭新的今天。
