【IT168 评论】

　　导读：您需要节省成本，但您不是管理者。您是一名软件开发人员或一个超级用户，或只是需要维持良好的现状。不管是其中的哪种情况，都非常需要向您的环境引入开源软件解决方案。这听上去好像是您需要花上三个星期的时间学习编程或编写 makefile，但事实并非如此。继续阅读本文，了解开源如何成为提高您工作环境效率的一种灵活的可行手段。

　　2010 年的开源

　　请别误会，本文不是对开源的盛赞。本文恰恰是要试图消除对开源的误解。如果有任何事情需要您开始思考，那么就是：开源不再是排他的选择。换言之，本文绝对不是要求您抛弃 Windows®，转而安装 GNU Linux®，或是诅咒 Adobe，又或要将 Apple 愤怒地烧掉。

　　那么本文的目的是什么?很简单：就是让您相信开源软件是可以解决某些问题的，并且您也很可能遇到这些问题。因此，无论您是有 Internet Explorer® 浏览器方面的问题，或是正在寻找一种优良的 Integrated Development Environment (IDE)，又或是厌烦为 PhotoShop 付费，抑或只是想要一种接近实时的支持系统，您的软件栈都将需要增加开源作为一个组成部分。

　　混合的方案几乎总是最好的

　　让我们假设您之所以对开源不怎么热衷，只是出于哲学上的原因。这并不是说您不赞同开源方式;这只是说您在为您所面对的软件问题寻找可替代的解决方案时有一些编程方面的担心。鉴于此，您可能不会转向采用 “全开源” 的方式。所以您会让一些软件 — 甚至是绝大部分软件 — 仍然是“闭源”的。这就意味着该软件是商业的，或是不能让您访问到源代码。这没关系。因为没有东西表明混合开源和非开源软件是一种糟糕的做法。

　　实际上，这种混合方式是最好的一种选择。比如，这种方式采用前，您往往是遇到了当前环境下的一两个问题。比如，您的 Windows 和 Internet Explorer 让您崩溃。如果您换到 Firefox，那么这就是一种混合的方案。(是的。也许您没有意识到，Firefox 是构建在开源软件之上的。)您混合了商业软件(Windows)与开源软件(Firefox)。您获得了两个领域的好处，不必囿于其中的一个领域。

　　开源和非开源软件之间的均衡完全取决于您。您可能除了 Firefox 不会用到其他开源软件，这很好。而另一方面，您也可能会倾向于 Sterling Ball 推崇的 Ernie Ball 方式(CNET 上有指向 Ernie Ball 方式的链接，请参考 参考资料);他们几乎全部使用的是开源软件。在这两种情况下或这两种情况之间的中间状态下，您都可以根据自己的需要进行选择，而这是件非常好的事情。

　　开源并不只意味着开发人员

　　作为一名从事开源项目近十年的开发人员，我清楚地知道很多开源社区实际上都是闭塞的，有时甚至是势利的。如果您的问题八个月之前已经有人问过，那么就有人会这样挖苦您：“菜鸟，查查之前的文档吧!”又比如您提交了对某个特性的请求，那么您有可能会得到 “它是开源的，停止抱怨，自己修复” 的训斥。这都是极端地傲慢和以开发人员为中心的态度。

　　幸好，有这种风气的大多数项目或者已经消失，或者已经显著改变。懂得些许礼数的开发人员大都因为这类行为而撤出或离开项目。现在，在 2010 年，大多数开源项目不仅有由乐于提供帮助的开发人员维护的强大的用户列表，而且还集成了 Facebook、Twitter 和 LinkedIn 作为补充的交流渠道。Bug 跟踪系统在这些项目中很常见，所以您尽可以提交一个特性请求或 bug，而不必担心受到攻击。实际上，最好的项目都欢迎这些报告，因为这可以改进项目。

　　举个例子，XML 处理器和转换器 Xalan-J 具有一个宏大的页面，详细说明了如何处理问题，如图 1 所示。

　　图 1. Xalan-J 提供了一个清晰的页面，详细说明了如何报告问题

　　这里不仅为您提供了指导，还有一个用户列表可以帮到您。虽然这个页面提倡您自己修复 bug，但是值得注意的是 Xerces-J 本身就是一个很低层的代码项目。并且，这里还提供了有关如何使用 JIRA 这个特性全面的 bug 报告 API 提交 bug 的相关信息(参见图 2)。换句话说，您不需要处理只有文本的 UI 以及复杂的指导。Bug 报告和特性请求都已被很好地注解，用户很容易遵循。

　　图 2. JIRA 提供了强壮的 bug 报告功能，而且它对用户是完全开放和可访问的