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

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

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

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