Question

在研究了 Linus 的做法并得出他为什么成功的理论后，我决定在我的新项目（当然没有 Linux 那么复杂和艰巨）里测试一下这个理论。

但我首先要做的一件事，是大幅度重组和简化 popclient，Carl Harris 的实现很好使，但表现出了一种不必要的复杂性，这在 C 程序员中很常见。他把代码作为最重要部分，而将数据结构置于辅助地位。结果就是，代码很漂亮，但数据结构设计得有点随意和潦草（至少从一个 LISP 老手的标准来看）。

除了提升代码和数据结构的质量之外，我重写的另一个目的是想把它弄成一个我完全理解的东西。如果你对一个程序不能了如指掌，而又要负责他的 bug 修复，那可就不好玩了。

最初一个月左右，我只是继续遵循 Cral Harris 的基本设计。对程序所做的第一个重大改变是添加对 IMAP 的支持，我把协议处理部分重新组织成一个通用的驱动和三个方法表（POP2、POP3 和 IMAP）。这次改动（以及先前的）再次说明了一个程序员应该铭记在心的一般原则（尤其对于 C 这种并不天然支持动态类型的语言）：

9.聪明的数据结构配上愚笨的代码，远比反过来要好得多。

Brooks 在《人月神话》的第 9 章里说：“让我看你的流程图但不让我看表，我会仍然搞不明白。给我看你的表，一般我就不再需要你的流程图了，表能让人一目了然。”历经 30 年的术语/文化变迁，这个道理依旧没变。

这个时候（1996 年 9 月初，即从零开始的六周后），我开始考虑给软件换个名字，毕竟它已不再只是一个 POP 客户端。但我有点犹豫，因为在设计上还没有做出什么真正新的东西，popclient 还需要有点我自己的东西。

当 popclient 学会如何把取来的邮件转发到 SMTP 端口后，软件就有了根本的变化，我们一会儿再谈这个。先说说前面我提到的用这个项目验证我所发现的关于 Linus 成功的理论，（你可能会问）我是如何做的呢？有这么几个办法：

·我尽早发布并频繁发布（几乎从来没有低于 10 天一次的频率，在高强度开发阶段会一天一次）。

·我把每一个因 fetchmail 联系我的人都加到 beta 列表（是指 beta 测试人员邮件列表——译者注）中。

·每次发布新版本时，我都向 beta 列表发送朋友对话般的通知，鼓励他们参与。

·我听取 beta 测试者们的意见，征求他们关于设计决策的看法，当他们发来补丁和反馈时给他们以热情回应。

这些简单措施立刻收到了回报。从项目一开始，我就收到一些质量高到让程序员们垂涎欲滴的那种 bug 报告，而且常常还附带了很不错的修复方法；我还收到经过深思熟虑的批评；收到粉丝来信；收到很有智慧的软件特性建议。这一切都表明：

10.如果你把 beta 测试者当做最珍贵的资源对待，他们就会成为你最珍贵的资源。

衡量 fetchmail 有多成功的一个有趣指标是 beta 列表（fetchmail-friends 列表）的规模，在本文最新一版时（2000 年 11 月），列表成员达到了 287 名之多，并且每周还增加 2 到 3 名。

实际上，列表成员最多时接近 300 名，1997 年 5 月底我修订这篇文章时发现，成员开始流失。一些人要求我把他们从邮件列表中去掉，而原因很有趣：他们觉得 fetchmail 已经足够好了，他们不想再看到关于这个项目的邮件往来！对于一个成熟的集市模式项目，也许这是其正常生命周期的一部分吧。