Lesson

1. Every good work of software starts by scratching a developer's personal itch.

``Necessity is the mother of invention'') but too often software developers spend their days
grinding away for pay at programs they neither need nor love. But not in the Linux world—
which may explain why the average quality of software originated in the Linux community is so
high.
asking myself ``Which one is closest to what I want?'' Because:

2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
The one I first settled on was `fetchpop' by Seung-Hong Oh. I put my header-rewrite feature in
it, and made various other improvements which the author accepted into his 1.9 release.
I stumbled across the code for popclient by Carl Harris, and found I had a problem. Though
fetchpop had some good original ideas in it (such as its background-daemon mode), it could
only handle POP3 and was rather amateurishly coded (Seung-Hong was at that time a bright
but inexperienced programmer, and both traits showed). Carl's code was better, quite
professional and solid, but his program lacked several important and rather tricky-to-
implement fetchpop features (including those I'd coded myself).
Stay or switch? If I switched, I'd be throwing away the coding I'd already done in exchange for a
better development base.
But I had a more theoretical reason to think switching might be as good an idea as well,
something I learned long before Linux.

3. ``Plan to throw one away; you will, anyhow.'' (Fred Brooks, The Mythical Man-Month,
Chapter 11)
After I sent my first set of popclient patches to Carl Harris on 25 June 1996, I found out that
he had basically lost interest in popclient sometime before. The code was a bit dusty, with
minor bugs hanging out. I had many changes to make, and we quickly agreed that the
logical thing for me to do was take over the program.
4. If you have the right attitude, interesting problems will find you.
But Carl Harris's attitude was even more important. He understood that.
5. When you lose interest in a program, your last duty to it is to hand it off to a competent
successor.
Without ever having to discuss it, Carl and I knew we had a common goal of having the best
solution out there. The only question for either of us was whether I could establish that I was a
safe pair of hands. Once I did that, he acted with grace and dispatch. I hope I will do as well
when it comes my turn.
And so I inherited popclient. Just as importantly, I inherited popclient's user base. Users are
wonderful things to have, and not just because they demonstrate that you're serving a need,
that you've done something right. Properly cultivated, they can become co-developers.
6. Treating your users as co-developers is your least-hassle route to rapid code
improvement and effective debugging.
Having studied Linus's behavior and formed a theory about why it was successful

But the first thing I did was reorganize and simplify popclient a lot. Carl Harris's
implementation was very sound, but exhibited a kind of unnecessary complexity common
to many C programmers. He treated the code as central and the data structures as support
for the code. As a result, the code was beautiful but the data structure design ad-hoc and
rather ugly (at least by the high standards of this veteran LISP hacker).

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.
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.

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.

First, this SMTP-forwarding concept was the biggest single payoff I got from consciously trying
to emulate Linus's methods. A user gave me this terrific idea—all I had to do was understand
the implications.
11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the
latter is better.

well, I had reframed my problem. Clearly, the right thing to do was (1) hack SMTP forwarding
support into the generic driver, (2) make it the default mode, and (3) eventually throw out all
the other delivery modes, especially the deliver-to-file and deliver-to-standard-output options.

The first and overwhelmingly most important feature I wrote after realizing this was multidrop
support—the ability to fetch mail from mailboxes that had accumulated all mail for a group of
users, and then route each piece of mail to its individual recipients.