【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 报告功能，而且它对用户是完全开放和可访问的

　　社区是一个好东西

　　这里所描述的这种交互最后就形成了所谓的社区。虽然您可以简单地发出一个寻求帮助的请求或保存一个 bug 报告，然后再返回到用户列表，但是这不是常规做法。订阅了软件项目邮寄列表的大多数用户最终都四处游荡。他们找到了忙着解决相同领域内的问题或是遇到了不 同领域内的类似问题的其他用户。

　　虽然看上去简单，甚至有些超理想化，但社区的确是在这些电子邮件列表和支持站点的基础上形成的。在这里，就您的软件问题，您能够找到在别处不 可能碰到的可以为您提供建议的人，或是您能够为之提供建议的人。返回到之前提及的有关 Ernie Ball 的文章：Sterling Ball 的开源体验不只改善了其业务：它还让他有了一种想让遇到相同问题的人知道该如何处理这样的实际问题并战胜该问题的强烈愿望。结果，很多其他的公司都以不同 的方式尝试过 Sterling 和 Ernie Ball 的解决方案。

　　开源软件吸收了这类社会性创意。不管是得益于开放电子邮件列表的特性还是因为软件在开放的状态下发展迅速，交互性得到了长足的发展。当然，没 有人会因为自身的原因而强烈反对交互，即便是商业公司也不会。但是对于开源软件，这种交互性又能特别好地培育更进一步的交互性以及用户与用户间的交互性。 这是开源的一个不可小觑的益处。

　　开源软件是开放的

　　我尝试着避免在标题上卖弄聪明 — 书籍、文章中的章节，凡是您想得到的 — 但是这里，我必须要说明：开源中的 “开放” 并不是可有可无、无关紧要的。假设您有管理层和公司利益需要顾及;本文的第一节本应精心为他们设计。

　　但是您不时地光顾 IBM® developerWorks，我于是做另一个假设：您已经至少具有了开发人员的思维方式。也许您还不能随心所欲地编写代码，但是您已经可以像开发人员那 样思考。这是件好事。而且说实话，这也是开源的亮点所在。在掌握了混合方式和社区之后，您的担忧就更多地是技术上的;并且开源可以极好地消除这些担忧。

　　自制文档虽然过时，但很有用

　　首先，坏消息是：开发人员均不善于为其编写的代码制作文档。这意味着如果想要深入钻研 Xalan-J、Firefox 或 Sourceforge.net 上您感兴趣的项目，您总是会发现找不到真正好的文档。在一个名为 initParser() 的方法名旁边附上一些诸如 “初始化解析器” 这类极无益的说明并不鲜见。那用处不大。

　　不过，一个项目及其基础代码越成熟，那么文档也就越好。以 JDOM 项目为例，它已经存在多年了。JDOM 是一种开源的解析用 API，较 SAX 或 DOM 更为用户友好。实际上，很多人 — 来自 NASA，甚至是 Sun Microsystems(现在的 Oracle) — 都在使用 JDOM。之所以有这样的使用得益于其归档良好的 API。比如，清单 1 所示的是 Element 接口内的一个方法的代码。

　　清单 1. JDOM 内部文档的例子

　　/** * This protected constructor is provided in order to support an Element * subclass that wants full control over variable initialization. It * intentionally leaves all instance variables null, allowing a lightweight * subclass implementation. The subclass is responsible for ensuring all the * get and set methods on Element behave as documented. *

　　* When implementing an Element subclass which doesn't require full control * over variable initialization, be aware that simply calling super() (or * letting the compiler add the implicit super() call) will not initialize * the instance variables which will cause many of the methods to throw a * NullPointerException. Therefore, the constructor for these subclasses * should call one of the public constructors so variable initialization is * handled automatically. */

　　protected Element() { }

　　对于一名开发人员，这非常有帮助。清晰的文档消除了混淆，并且让使用这个类变得简单了很多。当然，很多语言 — 包括 Java™ 语言 — 均允许这类代码级的文档被转变成更为有用的东西。图 3 所示的是 Element 接口的 JavaDoc，它是从上述代码文档直接生成的。

　　图 3. JavaDoc 是代码级文档的可视表示

　　大型社区意味着大量的支持人员

　　就代码级别的文档理念展开。首先，开发人员编写一些文档。然后，项目上的其他人与代码交互并会自己优化其文档或是让原始的开发人员优化其文 档。这样一来，文档就改进了。

　　然后，用户开始与代码交互。其中有些用户还会发现问题、报告问题甚至是帮助修复问题。文档不断完善。

　　随着用户群的增长，发生了这样的事：有几个用户是 A 类型的，即非常细心型的(我之所以这么说是因为我就是这样的人)。这些人将会深入研究基础代码并相应改进文档。他们会禁不住这么做;这是他们的性格所致。 所以即便这些用户永远都不更改代码的功能，他们还是会改进代码的文档。

　　这个过程下来，用户社区成为了支持社区。热心的一组人会现场提供问题的答案 — 他们中很多是义务的，没有报酬，甚至与原始的基础源代码没有任何关系。比如，您可以查看一下面向新手的 Eclipse 项目的论坛。这是一个 开源的开发环境。浏览其中各式各样的帖子后，您不免会感概有如此多的问题得到了解答 — 并且还解答得很详细 — 而提供问题答案的人连 Eclipse.org 电子邮件都没有。它们绝对不是 IBM 有意安排的人。相反，您看到了一个开源社区是如何快速成为一个支持社区的。这不是商业软件，对么?

　　您真能直接发邮件给微软么?

　　没错，这多少有点刺耳，但却相当真实：公司越大，越难获得高质量的支持。最近一次您感觉好像能够收到就您对 Excel® 或 Mac OS X 的问题给出解答的电子邮件是什么时候?虽然这偶尔发生 — 并且通常看上去更像是一种公关的姿态而非真正的支持 — 但绝不是惯例。您当然可以购买支持合同，但是在您拨打电话时能否获得满意的答复，还得靠运气。

　　不过，需要澄清的是：当然，我和您一样，也享受过很棒的支持体验。我遇到过工作人员忽视了我已经超出了注册期仍为我提供帮助;我曾在挂了电话 几分钟后就收到了措辞谨慎的解释;我也曾接到过电话只是为了了解我的近况。所以，绝不是说商业公司不能提供很好的支持。

　　并且，很多开源软件项目会让一些成熟的公司帮助为这些项目提供支持服务。有些使用这类公司，其他则不用。所以支持服务在一个开源环境中可以如 同闭源环境中的那般 “商业化”。墨守成规无益，并会使您和那些与您有相同境遇的人看上去很迂腐。

　　不过，有一点值得考虑：支持已经不再局限于屈指可数的几个工作人员了。代码文档提供了支持。通过阅读这些文档，您的知识得到扩充，并且在很多 情况下，还能自己解决问题。用户组形成了更大的支持社区。我于是更愿意依赖于一些整晚都在追踪 bug 的人为我提供很好的建议，而不是那些从 FAQ 里阅读问题答案的工作人员 — 不管该 FAQ 有多棒和多详细。

　　开源软件更新频繁

　　迭代是被大量使用的一个术语。在软件开发界更是频繁出现。对于开源 软件，迭代 往往指的是软件趋向于频繁发布。实际上，这也是开源软件的核心：早发布，常发布。所以您可以在主要的发布之间有 15 到 20 个发布(2.0、2.1、2.1.1、2.1.2、2.2 等，直到最后的 3.0)。

　　这并不是说商业软件没有迭代。只不过商业软件的迭代常常对典型的普通用户是隐蔽的。即便是像 Windows 和 Mac OS X — 虽然经常更新 — 这样的软件，大都用在屏幕底部的一些不起眼的淡入和淡出或是极小的窗口尽量遮盖这些更新。为什么?因为对于大多数商业软件而言，修订常被看作是纠正错误。 修订越多，要纠正的错误就越多。

　　对于开源软件，正好相反。代码是开放的，所以如果有错误的话，每个人 都会知道。只需订阅 JDOM 或 Xalan-J 或 Eclipse 或 Firefox 的一个用户列表。bug 不是什么秘密。登录到 JIRA 以获得您喜欢的任何项目。结果如何?常有一些发布和修订来修复这些错误。有什么要隐藏的，对么?并且有了这些频繁的发布，您 — 用户 — 才能享受其中的好处。

　　特性请求由您控制

　　如果软件发布频繁且其中没有隐藏任何真正的 bug，那么就有了一个不断进化的基础代码。其好处就是特性的更新变得很容易。如果您已经是一个月发布一次或更频繁，那么有什么可以阻止软件添加更多的特 性，而不只是修复 bug 呢?

　　现在，仔细思考一下这个问题。用户社区就是支持社区，发现并修复 bug。开发人员一方面要服务于受众，另一方面他们自身也是受众。那么由谁控制特性请求呢?管理者?股东?亦或是项目经理?都不是(尽管他们可能会或多或 少地参与其中)。您是控制者，又是受众，还是决策者。

　　最后，频繁的发布意味着不断地改进。bug 修复是一种改进，但功能上的升级也是一种改进。并且由于开发是开放的，因此您是一个很有影响力的人。在 JDOM 上(我是其上的一个共同创建者和长期的活跃分子)，我们主要的软件更改都源起于用户的请求。比如，向具有更多界面驱动支持的新版本的转移就是受一个用户的 启发，而这个用户与项目并没有“正式”关系，他只是参与者。Eclipse 就是受聪明的程序员和用户驱动的。

　　开源软件为您做调整(差不多如此)

　　开源软件的长期用户是根据其需求调整软件的主力军。您也可以很低调，从不加入邮寄列表，并且只有一个要求就是好的质量。这也是 Ernie Ball　的目标所在。而另一方面，您越投入，您对软件就有更多控制。您的特性请求会被流通，您甚至可以拥有添加自己的功能的权利。

　　与此同时，您也在为这个软件调整您自己。这不是坏事。经常的使用以及对开源所提供的基础代码的了解让您能够调整自己的工作方式以发挥软件的最 佳性能。您会发现随着您对软件内部工作机制知识的增长 — 您在用户列表上的投入，甚至对代码的帮助 — 您就能够做出优化软件的使用的决策。您知道 hook，您知道它的性能好在哪里，您也知道哪里是问题的所在。这样，您最终会从该知识中受益并有更好的表现。

　　结束语

　　如今，您读过的很多有关开源的文章一般都洋洋洒洒，或至多有一些实际的感受，但是也不乏对开源的热情。很多年来，开源的倡导者一直使用哲学论 据来支撑他们的观点。倡导者似乎比用户更愿意盲目皈依。这太煞风景 — 不只是对于非开发人员，对没时间在其工位旁树一面开源大旗的程序员也是如此。

　　这类近似布道的论调遮盖了开源软件的真正好处。若能明智而审慎地使用(这是 “在大多数情况下不要到处都用开源!”的一种隐晦的说法)，开源软件可以减少成本，并且在很多情况下，能改善功能。正如之前提到的， Firefox 是大多数普通用户最为常见的例子：很少有人是因为开源而选择安装 Firefox。它实在是一款很有用的浏览器，其插件比所有其他浏览器加起来还要多。为什么?因为此软件背后有一个充满生气的活跃社区的支持。

　　也许，在一个混合的环境中选择开源软件最好的解释仍在于 IBM 本身。(没错，本文是要在 IBM 网站上发布。但是，这句话是成立的。)IBM 除了商业软件外，还有一系列的开源软件，从对 Apache 的贡献到 Eclipse 等等。这种方式 — 在需要的时候 使用开源 — 才是值得您借鉴的方式。

　　也许您不喜欢 Gimp，那么不妨选择 PhotoShop。也许通过 Safari 跨桌面和 iPhone 同步书签实在是一个不错的解决方案。那很好。只是不要因为认识不深而将 开源软件拒之门外。(这句话听起来与它描绘的动作一样很有戏剧性。)如果您需要快速的升级周期和补加特性，请考虑开源的替代选择。如果您需要支持，而又不 想一年支出很多费用，那么就请看看在某个特定的领域开源能否效力。并且不管您做什么，都必须要有足够的信息。基于好的信息做出好的选择。这样一来，皆大欢喜。欢迎您告诉我您选择 — 和拒绝 — 哪些特定的开源软件以及为什么。网上见。