The Cathedral and the Bazaar | Page 3

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
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.
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 [JB].
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 principle:
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.
The Importance of Having Users
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.
Another strength of the Unix tradition, one that Linux pushes to a happy extreme, is that a
lot of users are hackers too. Because source code is available, they can be effective
hackers. This can be tremendously useful for shortening debugging time. Given a bit of
encouragement, your users will diagnose problems, suggest fixes, and help improve the
code far more quickly than you could unaided.
6. Treating your users as co-developers is your least-hassle route to rapid code
improvement and effective debugging.
The power of this effect