5. When Is A Rose Not A Rose?
Having studied Linus's behavior and formed a theory about why it was
successful, I made a conscious decision to test this theory on my
new (admittedly much less complex and ambitious) project.
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 old LISP hacker).
I had another purpose for rewriting besides improving the code and the
data structure design, however. That was to evolve it into something
I understood completely. It's no fun 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 [code] and conceal your [data
structures], and I shall continue to be mystified. Show me your [data
structures], and I won't usually need your [code]; it'll be obvious.''
Actually, he said ``flowcharts'' and ``tables''. But allowing for thirty
years of terminological/cultural shift, it's almost 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 fetchmail learned how to forward fetched
mail to the SMTP port. I'll get to that in a moment. But first: I
said above 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 periodsof 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 time of writing it has
249 members and is adding two or three a week.
Actually, as I revise in late May 1997 the list is 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.