2. The Mail Must Get Through
Since 1993 I'd been running the technical side of a small free-access
ISP called Chester County InterLink (CCIL) in West Chester,
Pennsylvania (I co-founded CCIL and wrote our unique multiuser bulletin-board
software -- you can check it out by telnetting to
locke.ccil.org. Today it supports almost
three thousand users on thirty lines.) The job allowed me
24-hour-a-day access to the net through CCIL's 56K line -- in fact, it
practically demanded it!
Accordingly, I had gotten quite used to instant Internet email. For
complicated reasons, it was hard to get SLIP to work between my home
machine (snark.thyrsus.com) and CCIL. When I finally succeeded, I
found having to periodically telnet over to locke to check my mail
annoying. What I wanted was for my mail to be delivered on snark so
that I would be notified when it arrived and could handle it using
all my local tools.
Simple sendmail forwarding wouldn't work, because my personal machine
isn't always on the net and doesn't have a static IP address. What I
needed was a program that would reach out over my SLIP connection
and pull across my mail to be delivered locally. I knew such things
existed, and that most of them used a simple application protocol
called POP (Post Office Protocol). And sure enough, there was already
a POP3 server included with locke's BSD/OS operating system.
I needed a POP3 client. So I went out on the net and found one.
Actually, I found three or four. I used pop-perl for a while, but it
was missing what seemed an obvious feature, the ability to hack the
addresses on fetched mail so replies would work properly.
The problem was this: suppose someone named `joe' on locke sent me
mail. If I fetched the mail to snark and then tried to reply to it,
my mailer would cheerfully try to ship it to a nonexistent `joe' on
snark. Hand-editing reply addresses to tack on `@ccil.org' quickly
got to be a serious pain.
This was clearly something the computer ought to be doing for me. But
none of the existing POP clients knew how! And this brings us to the
first lesson:
1. Every good work of software starts by scratching a developer's
personal itch.
Perhaps this should have been obvious (it's long been proverbial that
``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.
So, did I immediately launch into a furious whirl of coding up a
brand-new POP3 client to compete with the existing ones? Not on your
life! I looked carefully at the POP utilities I had in hand, asking
myself ``which one is closest to what I want?
2. Because good programmers know what to write. Great ones know what to rewrite (and reuse).
While I don't claim to be a great programmer, I try to imitate one.
An important trait of the great ones is constructive laziness. They
know that you get an A not for effort but for results, and that it's
almost always easier to start from a good partial solution than from
nothing at all.
Linus Torvalds,
for example, didn't actually try to write Linux from
scratch. Instead, he started by reusing code and ideas from Minix, a
tiny Unix-like OS for 386 machines. Eventually all the Minix code
went away or was completely rewritten -- but while it was there, it
provided scaffolding for the infant that would eventually become
Linux.
In the same spirit, I went looking for an existing POP utility that
was reasonably well coded, to use as a development base.
The source-sharing tradition of the Unix world has always been
friendly to code reuse (this is why the GNU project chose Unix as a
base OS, in spite of serious reservations about the OS itself).
The Linux world has taken this tradition nearly to its technological
limit; it has terabytes of open sources generally available. So
spending time looking for some else's almost-good-enough is more
likely to give you good results in the Linux world than anywhere else.
And it did for me. With those I'd found earlier, my second search made
up a total of nine candidates -- fetchpop, PopTart, get-mail,
gwpop, pimp, pop-perl, popc, popmail and upop.
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.
A few weeks later, though, 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 daemon mode), it could only handle
POP3 and was rather amateurishly coded (Seung-Hong was 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.
A practical motive to switch was the presence of multiple-protocol
support. POP3 is the most commonly used of the post-office server
protocols, but not the only one. Fetchpop and the other competition
didn't do POP2, RPOP, or APOP, and I was already having vague thoughts
of perhaps adding
IMAP (Internet Message Access Protocol, the most recently designed and most
powerful post-office protocol) just for fun.
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)
Or, to put it another way, you often don't really understand the
problem until after the first time you implement a solution. The
second time, maybe you know enough to do it right. So if you want to
get it right, be ready to start over at least once.
Well (I told myself) the changes to fetchpop had been my first try.
So I switched.
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 some time 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.
Without my actually noticing, the project had escalated. No longer
was I just contemplating minor patches to an existing POP client.
I took on maintaining an entire one, and there were ideas bubbling in
my head that I knew would probably lead to major changes.
In a software culture that encourages code-sharing, this is a natural
way for a project to evolve. I was acting out this:
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 act as well when it comes my turn.