1993 年以来、ぼくはペンシルバニア州ウェストチェスターにある、 Chester County InterLink (CCIL) という小さなフリーアクセス ISP の技術面を担当してた (ぼくは CCIL の共同創設者で、ぼくたちが使ってる ユニークなマルチユーザ BBS ソフトを書いた。興味があれば、 locke.ccil.org に telnet してみてほしい。いまでは 19 回線で 3,000 人弱のユーザをサポートしてる) 。 この仕事のおかげで、CCIL の 56K 回線を通じて 1 日 24 時間ネットに アクセスし続けられるようになった —— というより、仕事柄そうせざるをえなかったというのが実状かな！

　そういうわけで、インターネットの電子メールがすぐに手放せなくなった。 なんかややこしい理由で自宅のマシン (snark.thyrsus.com) と CCIL とで SLIP 接続するのに手間取って、それがうまくいくと、今度はしょっちゅう locke に telnet してメールをチェックするのがえらく面倒に なってきた。メールを snark に配信してもらって、 新しいメールがきたら biff(1) が報せてくれるようにしたかったわけ。

　Sendmail の転送機能は使えない。snark はネットにつないでないときもあって、IP アドレスも固定されてないからね。SLIP 接続経由で手をのばして、 メールをローカルマシンに引っ張ってきてくれるようなソフトがほしかったわけだ。 そういうソフトがあるのは知ってたし、そのほとんどが POP (Post Office Protocol) っていう簡単なアプリケーション・プロトコルを使ってるのも知ってた。 そして、確かに locke の BSD/OS には、ちゃんと POP3 サーバソフトが 含まれているではないの。

　あとは POP3 のクライアントがあればいい。そこでネットで探してみると、3 つか 4 つ見つかった。しばらくは pop-perl を使ってたけれど、 これには当然あるべき（と思われる）機能が欠けていた。 とってきたメールのアドレスをいじくって、返信がうまくいくようにするのが できなかったんだ。

　つまりこういうことだ。locke 上の「joe」という人が、ぼくにメールを出した とする。このメールを snark にとってきて、それに返信したら、メールソフトは snark 上の「joe」にそれを送って悦に入っちゃうわけ。そんな人物はいないのに。 返信アドレスを手でなおして、@ccil.org を最後にくっつけてたんだけれど、これはすぐにえらい手間になってきた。

　こんなのどう見ても、コンピュータがやるべきことだよね (実は RFC1123 のセクション 5.2.18 によれば、これは sendmail が処理しなきゃいけないんだけど）。 でも、既存の POP クライアントはどれ一つとしてこいつがこなせなかった！ というわけで、教訓その1:

1. よいソフトはすべて、開発者の個人的な悩み解決から始まる。

　これは自明のことかもしれない（昔から「必要は発明の母」って言うし）。 でも実際のソフト開発者ってのは、お金で横っ面はられて自分では要りもしないし 好きでもないようなソフトを一日中シコシコ書いてることがあまりに多いんだ。 でも、Linux の世界ではちがう —— Linux 界出身ソフトの質が、 平均してすごく高いのはこのせいかもしれないね。

　そこでぼくは、既存のものとタメを張るようなまっさらの POP3 クライアントを書き上げるべく、即座にコード書きの渦中へ猛然ととびこんだ —— かな？　ご冗談を！ ぼくはまず、手元にある POP ユーティリティを じっくりながめてこう考えた。「ぼくの欲しいものにいちばん近いのはどれかな？」 というのも：

2. 何を書けばいいかわかってるのがよいプログラマ。 なにを書き直せば（そして使い回せば）いいかわかってるのが、 すごいプログラマ。

　—— だからね。すごいプログラマを気取るつもりはないけど、 でもそのまねくらいはしたい。すごいプログラマの大事な特徴の一つが、 建設的な面倒くさがりってヤツなんだ。評価してもらえるのは結果であって、 そのための努力じゃないってのがわかってるってこと。そして白紙から始めるよりは、 よくできた部分解からはじめたほうがほぼ絶対に楽。

　たとえば リーヌス・トーヴァルズ（http://www.tuxedo.org/~esr/faqs/linus）は、 Linux をゼロから書き始めたわけじゃない。386 マシン用の、小さな UNIX っぽい OS だった Minix のコードやアイデアを再利用するところから始めてる。やがて Minix のコードは全部落とされたか、あるいは完全に書き直された —— でも最初のうちは、 やがて Linux となるべき赤ん坊のための簡単な囲いを提供してくれてたんだ。

　同じ精神から、ぼくは既存の POP ユーティリティを探しに出た。 そこそこ上手にコーディングされてて、開発のベースに使えるようなヤツを。

　UNIX 界では、ソース共有の伝統のおかげでコードの再利用が昔からとっても やりやすかった（このせいで GNU プロジェクトは、UNIX という OS そのものについては、かなり不満を持ってたんだけれど、ベース OS には UNIX を選んだ）。Linux 界は、この伝統を技術的な極限にまでつきつめてる。 だれにでも使えるオープンなソースコードが、何テラバイトもある。 だからだれかほかの人の、ほとんど使いものになりそうなコードを探すのは、 Linux の世界ではほかのどこよりもすごくいい結果をうみやすい。

　ぼくの場合もそうだった。もう一度探しに出た結果、最初に見つけたのとあわせて 候補が 9 個あがってきた —— fetchpop、PopTart、get-mail、 gwpop、pimp、 pop-perl、popc、popmail、upop。最初に落ち着いた先は呉承洪（オー・スンホン）の fetchpop だった。ぼくは自前のヘッダ変更機能をそれに加えて、 その他いろいろ改良を入れた。作者はそれを受け入れて、 1.9 リリースに含めてくれた。

　でも数週間たって、Carl Harris の popclient のコードに出くわして、 困ったなと思った。fetchpop はなかなかいい独創的なアイデア （たとえば daemon モードとか）が入ってたんだけれど、POP3 しか扱えないし、コードもいささか素人くさかった（スンホンはプログラマとして 才能はあるけれどまだ駆け出しで、その両方の特徴が fetchpop には出ていた）。 Carl のコードのほうが優れていて、プロ級のしっかりしたものだったけれど、 大事なのに実装が面倒な fetchpop の機能がいくつか欠けていた （ぼくがコーディングした機能も含め）。

　このままいくか、乗り換えるか？　乗り換えたら、開発ベースはよくなるけれど、 かわりにこれまでのコーディングは全部捨てることになる。

　実際問題として、乗り換える理由の一つに複数のプロトコルが扱える点があった。 POP3 は post-office サーバプロトコルで一番普及はしているけれど、 唯一無二ってわけじゃない。Fetchpop をはじめとする競合ソフトは POP2 も RPOP も APOP も扱えなかったし、ぼくのほうでは IMAP <http://www.imap.org/> (Internet Message Access Protocol、一番最近に設計された、最強の post-office プロトコル) のサポートを入れたらいいかもしれないな、 なんてことをすでにおもしろ半分で考え始めていた。

　でも、乗り換えたほうがいいかもしれない理論的な根拠もあった。 これはぼくが、Linux よりずっと前に学んだことでもある。こういうことだ：

3. 捨てることをあらかじめ予定しておけ。 どうせいやでも捨てることになるんだから （フレッド・ブルックス『人月の神話』第11章）

　あるいは言い換えると、1 回とりあえず解決策を実装してみるまでは、 問題を完全には理解しきれないってこと。2 回目くらいになってやっと、 正しい解決法がわかるくらいの理解が得られるかもしれない。 だからちゃんとした問題解決をしたいなら、少なくとも 1 回くらいはやりなおす覚悟はしておくこと。 [JB]

　ま、（と独り言）fetchpop の改良が 1 回目だったわけだ。というわけで、 ぼくは乗り換えた。

　最初の popclient 用パッチを 1996 年 6 月 25 日に Carl Harris に送ったんだけれど、実はかれはしばらくまえに、popclient に興味をなくしている ことがわかった。コードもほこりをかぶってる状態で、ちょっとしたバグも 残ったままだったし。こっちとしては、いろいろ変えたいところもあった。 だから、ぼくがこのプログラムを任されるのがいちばん理にかなってるということで、 両者はすぐに合意した。

　自分でも気がつかないうちに、プロジェクトは拡大したわけだ。もはやぼくは、 既存の POP クライアントにちょっとパッチをあてるような話をしてるわけじゃない。 プログラムをまるごとメンテする作業を引き受けてたんだ。 そして頭の中ではいろいろアイデアも湧いてきていて、これをやったら大幅な変更が 必要になるな、というのもはっきりしてた。

　コード共有を奨励するソフト文化にあって、これはプロジェクト発展の 自然な道筋ではある。ぼくは次の原理を実践していたことになる：

4. まともな行動をとってれば、 おもしろい問題のほうからこっちを見つけだしてくれる。

　でも Carl Harris の行動のほうがもっと大事だ。かれが理解していたこと：

5. あるソフトに興味をなくしたら、 最後の仕事としてそれを有能な後継者に引き渡すこと。

　なにも相談なんかしなくても、カールもぼくも、自分たちがこの世で最高の 問題解決方法を実現するという共通の目標を持っていることがわかっていた。 二人にとって唯一の問題は、ぼくがこれを安心して任せられる人物だってことを 証明できるかということだけだった。それを実証してみせたら、かれはすぐさま優雅な ふるまいを見せて、ソフトをゆだねてくれた。 ぼくの順番がきたときにも、Carl と同じくらいの鷹揚さを示したいなと思う。