274    这时（1996年9月初，开工后大约六周），我开始考虑要给软件换个名字了。

275    因为毕竟它已经不仅仅是个POP客户端了。

276    但是我在犹豫，因为设计上没有什么新突破，我的popclient需要独具一格。

277    当popclient学会如何将收取到的邮件再通过本机SMTP端转发的时候，这一切迅速改变了。

278    这个容后再表。

279    首先，我之前说过要在开发过程中验证李纳斯成功的理论，那么（你也会问）我是怎么做到的呢？

280    * 我早发布，常发布（从未低于十天一次，在高强度的开发周期则每天一次）。

281    * 我把每个曾和我讨论fetchmail的人都列入公测名单。

282    * 每当新版本发布，我都会不厌其烦的给公测名单里的每个人寄送一份，并鼓励其参与。

283    * 我听取公测人员的意见，在设计上征求他们的看法。

284    并且当他们寄回补丁和反馈的时候，给予鼓励。

285    这些简单的方法立竿见影。

286    在项目一开始，我就收到了很多能让大多数程序员垂涎三尺的高质量错误报告，而且经常还附带不错的修补方法。

287    我还收到过深刻的评论、支持者的来信，高明的功能建议。

288    这一切都证明：