Question

“切斯特互联”（Chester County InterLink，CCIL）位于美国宾夕法尼亚州（Pennsylvania）的西切斯特郡（West Chester），是一家小型的免费互联网服务提供商。1993 年以来，作为联合创始人，我曾一直负责 CCIL 的技术部分，并编写了我们独创的多用户论坛程序——你可以通过 telnet 连到 locke.ccil.org 来试试看。时至今日，这个程序通过三十多条线路支持近三千名用户访问。这份工作使我能够使用 CCIL 的 56K 线路保持每天 24 小时连在网络上，当然，这是工作需要！

我已经习惯了使用电子邮件，但每过一会儿就 telnet 到 locke 上查一下邮件，是一件比较烦人的事。我很希望邮件能够自动地递送到 snark（我家里的机器）上，这样，邮件来的时候就会通知我，然后我就能用本地工具来处理它。

互联网原生的邮件转发协议 SMTP（Simple Mail Transfer Protocol，简单邮件传输协议）并不适用，因为它最适用于机器一直在线的情况，而我家里的机器并不总是在线，而且也没有一个静态 IP 地址。我需要这样一个程序，它可以在我时断时续的拨号上网期间，把我的邮件取到本地。我知道有这种软件，它们大多使用了应用层协议 POP（Post Office Protocol，邮局协议）。现在绝大多数常见邮件客户端都支持 POP，但在那个年代，我所用的邮件阅读器并不支持。

看来我需要一个 POP3 客户端。于是我便到网上找了一个（事实上我找到了三四个），使用了一段时间后，我发现它有个明显的缺陷：它不能正确地解析取回邮件的邮箱地址，导致我不能正确回复。

问题是这样的：比如 locke 上有个叫 joe 的人给我写信，我把信取到 snark 上并试图回复时，邮件程序会傻乎乎地想把它发给 snark 上并不存在的 joe。所以我不得不每次把回复邮件地址修改为 @ccil.org 的样子，这实在有点痛苦。

很明显这种事应该由计算机搞定，但没有任何一个现成的 POP 客户端能做到这点！这给我们上了第一课：

1.好的软件作品，往往源自于开发者的个人需要。

按说这是显而易见的（正如老话说“需要是发明之母”），但太多的软件开发人员并不需要也不热爱他们正在开发的软件，他们把编程当差事，为的只是拿薪酬。Linux 世界里可不是这样——也许这可以解释为什么 Linux 社区里原创软件的平均质量是如此之高。

那么，我是不是应该立即投入到疯狂的编程中，做出一个全新的 POP3 客户端和其他程序一较高下？千万不要！我把手头的 POP 程序看来看去，认真思索“哪个最接近我想要的”，因为：

2.优秀的程序员知道写什么，卓越的程序员知道改写（和重用）什么。

我不敢说自己是卓越的程序员，我只是模仿他们。卓越程序员们有个很重要的特征是“建设性懒惰”，他们知道人们要的是结果而不是勤奋，而从一个部分可行的方案开始，明显要比从零开始容易得多。

以 Linus Torvalds 为例，他并没有尝试从零开始写 Linux，而是以重用 Minix（一个用于 PC 机的迷你型 UNIX 类操作系统）的代码和理念作为开始，虽然 Linux 中所有 Minix 代码最终都被移除或重写，但它在 Linux 成长初期确实起到了类似脚手架的作用。

基于同样的理念，我试图找到一些代码写得还不错的 POP 程序，作为我开发的基础。

UNIX 世界共享源代码的传统使得代码重用变得很便利（这正是 GNU 选择 UNIX 作为基础 OS 的原因，且不论它对 UNIX 本身的保留意见），Linux 世界则把这个传统发挥到了技术上的极限。相比其他地方，从 Linux 世界多达数 T 字节的开放源码中，找到一些他人写的“足够好”的代码要可行得多。

不出意外，连同上次找到的，我一共找到九个备选程序：fetchpop、PopTart、get-mail、gwpop、pimp、pop-perl、popc、popmail 和 upop。我首先选择了 Seung-Hong Oh 写的 fetchpop。我给程序加上了“邮件头重写”功能，并做了一些其他改进，这些改进被作者接受并在 1.9 版本中发布。

几周以后，我偶然发现了 Carl Harris 写的 popclient 代码，同时带来的是一个难题：尽管 fetchpop 有一些很好的创意（比如使用后台进程模式），但只能处理 POP3 协议，代码也略显业余（Seung-Hong Oh 在那时是个聪明但缺乏经验的程序员，这两点都看得出来）。Carl Harris 的代码要好一些，专业而稳健，但缺乏 fetchpop 中一些重要而精巧的特性（包括我写的那部分）。

继续完善 fecthpop 还是转换到 popclient？如果转换，我写的那些代码就可惜了，但同时能换来一个更好的开发基础。

一个更实际的转换动机是 popclient 对多协议的支持。POP3 是最常用的邮件服务器协议，但并不是唯一的。fetchpop 以及其他备选程序并不支持诸如 POP2、RPOP 或 AROP 这些协议，而我还有点想加上对 IMAP（Internet Message Access Protocol，互联网消息访问协议，这是最新设计的、功能最强大的邮局协议，http://www.imap.org）的支持，仅仅是为了好玩。

另外，还有一个理论上的原因让我决定转换，这可是早在 Linux 之前我就学到的：

3.“计划好扔掉一个吧，迟早你会这么做的。”（Fred Brooks，《人月神话》第 11 章）

或者可以这么说：在你第一次把问题解决的时候，你往往并不了解这个问题，第二次你才可能知道怎么把事情做好。所以，如果你想做对事情，至少要再做一次。 ¹

好吧，我对自己说，改写 fetchpop 是我的第一次尝试，现在我可以换了。

1996 年 6 月 25 日，我把自己对 popclient 所做的第一批补丁发给 Carl Harris，发现他基本已经失去了对 popclient 的兴趣。由于 popclient 代码有点陈旧，还有些小 bug 没有解决，很多地方都值得改进，我和 Carl Harris 很快达成一致：由我来接手这个程序。

项目在不经意间升级了，我不再是对现有 POP 客户端做一些小打小闹的补丁工作，而是开始维护整个程序。新的想法不时冒出来，我意识到自己也许可以对程序做些大改动了。

在一个鼓励代码共享的软件文化中，这是一种很自然的项目演化方式。我见证了下面这条：

4.如果你有正确的态度，有趣的事情自然会找到你。

当然，Carl Harris 的态度更重要，因为他明白：

5.当你对一个程序不再感兴趣时，你最后的责任就是把它交给一个可以胜任的接棒者。

尽管并没有明确提及，但 Carl Harris 和我都知道，我们的共同目标是做出最好的解决方案。唯一的问题是我能否证明自己是可靠的，一旦我做到这点，Carl Harris 就优雅而利落地把程序交接给我。如果有一天轮到我时，希望我也能交接得这么棒。