The Cathedral and the Bazaar | Page 8

to be responsible for fixing bugs in a program you don't understand.
For the first month or so, then, I was simply following out the implications of Carl's basic
design. The first serious change I made was to add IMAP support. I did this by
reorganizing the protocol machines into a generic driver and three method tables (for
POP2, POP3, and IMAP). This and the previous changes illustrate a general principle
that's good for programmers to keep in mind, especially in languages like C that don't
naturally do dynamic typing:
9. Smart data structures and dumb code works a lot better than the other way around.
Brooks,







Chapter 9

: ``Show me your flowchart and conceal your tables, and I shall continue to be mystified.
Show me your tables, and I won't usually need your flowchart; it'll be obvious.'' Allowing
for thirty years of terminological/cultural shift, it's the same point.
At this point (early September 1996, about six weeks from zero) I started thinking that a
name change might be in order-after all, it wasn't just a POP client any more. But I
hesitated, because there was as yet nothing genuinely new in the design. My version of
popclient had yet to develop an identity of its own.
That changed, radically, when popclient learned how to forward fetched mail to the
SMTP port. I'll get to that in a moment. But first: I said earlier that I'd decided to use this
project to test my theory about what Linus Torvalds had done right. How (you may well
ask) did I do that? In these ways: I released early and often (almost never less often than
every ten days; during periods of intense development, once a day).
I grew my beta list by adding to it everyone who contacted me about fetchmail. I sent
chatty announcements to the beta list whenever I released, encouraging people to
participate. And I listened to my beta-testers, polling them about design decisions and
stroking them whenever they sent in patches and feedback.
The payoff from these simple measures was immediate. From the beginning of the
project, I got bug reports of a quality most developers would kill for, often with good
fixes attached. I got thoughtful criticism, I got fan mail, I got intelligent feature
suggestions. Which leads to:
10. If you treat your beta-testers as if they're your most valuable resource, they will
respond by becoming your most valuable resource.
One interesting measure of fetchmail's success is the sheer size of the project beta list,
fetchmail-friends. At the time of latest revision of this paper (November 2000) it has 287
members and is adding two or three a week.
Actually, when I revised in late May 1997 I found the list was beginning to lose members
from its high of close to 300 for an interesting reason. Several people have asked me to
unsubscribe them because fetchmail is working so well for them that they no longer need
to see the list traffic! Perhaps this is part of the normal life-cycle of a mature bazaar-style
project.
Popclient becomes Fetchmail
The real turning point in the project was when Harry Hochheiser sent me his scratch code
for forwarding mail to the client machine's SMTP port. I realized almost immediately that
a reliable implementation of this feature would make all the other mail delivery modes
next to obsolete.
For many weeks I had been tweaking fetchmail rather incrementally while feeling like
the interface design was serviceable but grubby-inelegant and with too many exiguous
options hanging out all over. The options to dump fetched mail to a mailbox file or
standard output particularly bothered me, but I couldn't figure out why.
(If you don't care about the technicalia of Internet mail, the next two paragraphs can be
safely skipped.)
What I saw when I thought about SMTP forwarding was that popclient had been trying to
do too many things. It had been designed to be both a mail transport agent (MTA) and a
local delivery agent (MDA). With SMTP forwarding, it could get out of the MDA
business and be a pure MTA, handing off mail to other programs for local delivery just as
sendmail does.

Why mess with all the complexity of configuring a mail delivery agent or setting up
lock-and-append on a mailbox when port 25 is almost guaranteed to be there on any
platform with TCP/IP support in the first place? Especially when this means retrieved
mail is guaranteed to look like normal sender-initiated SMTP mail, which is really what
we want anyway.
(Back to a higher level....)
Even if you didn't follow the preceding technical jargon, there are several important
lessons here. First, this SMTP-forwarding concept was the biggest single payoff I got
from consciously trying to emulate