2.6　何时名不再符实

在研究了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已经足够好了，他们不想再看到关于这个项目的邮件往来！对于一个成熟的集市模式项目，也许这是其正常生命周期的一部分吧。