此时(1996年9月初，在从零开始六个月后)，我开始想接下来修改名字——毕竟，它已不仅仅是一个pop客户，但我犹豫了，因为还没有什么新的漂亮设计呢，我的popclient版本需要有自己的特色。

当fetehmail学会怎样把取到的邮件转送到smtp端口时，事情就完全改变了，但是首先：上面我说过我决定使用这个工程来测试我关于linustorualds所做的行为的理论，(你可能会问)我怎样做到这点呢?以下面的方式：

我尽早尽量频繁的发布(几乎从未少于每十天发布一次；在密集开发的时候是每天一次)。

我把每一个和我讨论fetchmail的人加入一个beta表中。

每当我发布我都向beta表中的人发出通告，鼓励人们参与。

我听取beta测试员的意见，向他们询问设计决策，对他们寄来的补丁和反馈表示感谢。

这些简单的手段立即收到的回报，在工程的开始，我收到了一些错误报告，其质量足以使开发者因此被杀掉，而且经常还附有补丁、我得到了理智的批评，有趣的邮件，和聪明的特征建议，这导致了：

如果你象对待最宝贵的资源一样对待你的beta测试员，他们就会成为你最宝贵的资源。

六.popclient变成了fetchmail

这个工程的真正转折点是harryhochleiser寄给我他写的代码草稿，他把邮件转发到客户端机器的smtp端口，我立即意识到这个特征的可靠实现将淘汰所有其他的递送模式。

几个星期以来我一直在修改而不是改进fetchmail，因为我觉得界面设计虽然有用但是太笨拙琐碎了，到处充满了太多的粗陋的细小选项。

当我思考smtp转发时我发现popclient试图做的事太多了，它被设计成既是一个邮件传输代理(mta)也是一个本地递送代理(mda)。使用smtp转发，它就可以从mda的事务中解脱出来而成为一个纯mta，而象sendmail一样把邮件交给本地递送程序来处理。

既然端口25在所有支撑tcp／ip的平台上早已被预留，为什么还要为一个邮件传输代理的配置或为一个邮箱设置加锁的附加功能而操心呢?尤其是当这意味着抽取的邮件就象一个正常的发送者发出的smtp邮件一样，而这就是我们需要的。

这里有几个教益：第一，smtp转发的想法是我有意识地模拟linus的方法以来的最大的单个回报，一个用户告诉我这个非同寻常的想法——我所需做的只是理解它的含义。

想出好主意是好事，从你的用户那里发现好主意也是好事，有时候后者更好。

很有趣的是，你很快将发现，如果你完全承认你从其他人那里得到多少教益的话，整个世界将会认为所有的发明都是你做出的，而你会对你的天才变得谦虚。我们可以看到这在linus身上体现得多明显!(当我在1997年8月的perl会议上发表这个论文时，larrywall坐在前排，当我讲到上面的观点时，他激动的叫了出来：“对了!说对了!哥们!”所有的听众都哄堂大笑起来，因为他们知道同样的事情也发生在perl的发明者身上)。

于是在同样精神指导下工程进行了几个星期，我开始不光从我的用户那儿也从听说我的系统的人那儿得到类似的赞扬，我把一些这种邮件收藏起来，我将在我开始怀疑自己的生命是否有价值时重新读读这些信。:)

但是有两个更基本的，非政治性的对所有设计都有普遍意义的教益。

最重要和最有创新的解决方案常常来自于你认识到你对问题的概念是错误的。

一个衡量fetchmail成功的有趣方式是工程的beta测试人员表(fegtchmail的朋友们)的长度，在创立它的时候已经有249个成员了，而且每个星期增加两到三个。

实际上，当我在1997年5月校订它时，这张表开始因为一个有趣的原因而缩短了，有几个人请求我把他们从表中去掉，因为fetchmail已经工作的如此之好，他们不需要看到这些邮件了!也许这是一个成熟的市集风格工程的生命周期的一部分。

我以前一直在解决错误的问题，把popclient当作mta和具有许多本地递送模式的mda的结合物，fetchmail的设计需要从头考虑为一个纯的mta，做为一个普通internet邮件路径的一部分。

当你在开发中碰了壁时(当你发现自己很难想通下一步时)，那通常不是要问自己是否找到正确答案，而是要问是否问了正确问题，也许需要重新构造问题。

于是，我重新构造了我的问题，很清楚，要做的正确的事是(1)把smtp转发支持放在通用驱动程序中，(2)把它做为缺省模式，(3)最终分离所有其他的递送模式，尤其是递送到文件和标准输出的选项。

我在第三步上犹豫了一下，担心会让popdiant的长期用户对新的递送方法感到烦心，在理论上，他们可以立即转而转发文件或者他们的非sendmail等价物来得到同样的效果，在实际中这种转换可能会很麻烦。

但是当我这么做之后，证明好处是巨大的，驱动程序代码的冗余的部分消失了，配置完全变得简单了——不用屈从于系统mda和用户的邮箱，也不用为下层os是否支持文件锁定而担心了。

而且，丢失邮件的唯一漏洞也被堵死了，如果你选择了递送到一个文件而磁盘已满，你的邮件就会丢失，这在smtp转发中不会发生，因为smtp侦听器不会返回ok的，除非邮件可以递送成功或至少被缓冲留待以后递送。

还有，性能也改善了(虽然在单次执行中你不会注意到)，这个修改的另一个不可忽视的好处是手册变得大大简单了。

后来，为了允许处理一些罕见的情况，包括动态slip，我必须回到让用户定义本地mda递送上来，但是我发现了一个更加简单的方法。

所有这些给了我们什么启发呢?如果可以不损失效率，就要毫不犹豫抛弃陈旧的特性，antoninedesaintexupery(在他成为经典儿童书籍作家之前是一个飞行员和飞机设计师)曾说过：

“最好的设计不是再也没有什么东西可以添加了，而是再也没有什么东西可以去掉。”

当你的代码变得更好和更简单时，这就是你知道它是正确的时候了，而且在这个过程中，fetehmail的设计具有了自己的特点，而区别于其前身popclient。

现在是改名的时候了，这个新的设计看起来比老popclient更象一个sendmail的复制品，它们都是mta，但是senmail是推然后递送，而新的popclient是拉然后递送。于是，在两个月之后，我把它重新命名为fetehmail。

七.fetchmail成长起来

现在我有了一个简洁和富有创意的设计，工作得很好的代码，因为我每天都用它，和一直在增长的beta表，它让我渐渐明白我已经不是在从事只能对少数其他人有用的工作中，我写了一个所有有一个unix邮箱和slip／ppp邮件连接的人都真正需要的程序。

通过smtp转发功能，它成为一个潜在的“目录杀手”，远远领先于它的竞争者，这个程序如此能干以至于其他的程序不但被放弃简直被忘记了。

我知道你不可以真得瞄准或计划出这样的结果，你只能努力去设计这些强大的思想，以后这些结果就好象是不可避免的、自然的、注定了的，得到这种思想的唯一办法是获取许多思想，或者用工程化的思考其他人的好主意而超过原来想到它的人的设想。

andrewtanenbanm原来设想建造一个适合386的简单的unix用做教学，linustorvalels把andrew的可能想到的minix可以做什么的概念推进了一步，成长为一个极好的东西，同样的(虽然规模较小)，我接受了cardharris和harryhochheiser的想法，把它们变得更强大，我们都不是人们所浪漫幻想的天才的创始人，但是大多数科学和工程和软件开发不是被天才的创始人完成的，这和流传的神话恰恰相反。