そういうわけで、きれいで革新的なデザインを手に入れ、 毎日自分で使ってるから確実に動くのもわかってるコードもできたし、 さらにベータリストは拡大する一方。だんだんわかってきたのは、 自分がやっているのが、ほんの数人にたまたま便利に使えるような、 自分だけのちょっとしたハッキングなんかではなくなってきた、 ということだった。ぼくがいじっているのは、UNIX マシンと SLIP/PPP メール接続を持ってるハッカーみんなが本当に必要としている プログラムだったんだ。

　SMTP 転送機能のおかげで、このソフトは競合ソフトからぬきんでて、 「カテゴリーキラー」になる可能性まで出てきた。カテゴリーキラーというのは、 ニッチをあまりに見事に満たしているので、それ以外の選択肢は単に 放棄されるどころか、ほとんど忘れ去られてしまうようなソフトのことだ。

　こういう結果は、狙ってできるものではないし、 計画して得られるものでもないと思う。ものすごく強力なデザイン上のアイデア、 あとから考えると、その結果が当然きわまりなく、自然で、 事前に約束されていたようにさえ思えるようなアイデアによって、 そういう結果に引き込まれなくてはならないんだと思う。そんなアイデアを狙うには、 たくさんアイデアを思いつくしかない —— または、ほかのひとのいいアイデアをもらって、 それをもとの発案者が思ってもみなかったところまでつきつめるという エンジニアリング上の判断を持つという方法か。

　Andrew Tanenbaum は、386 用に簡単なネイティブの UNIX をつくるというアイデアを最初におもいついた。これは教育用ツールとしてだった。 リーヌス・トーヴァルズは Minix のコンセプトを、Andrew が予想もしなかったくらいはるか遠くにまで拡張した —— そしてそれが、すばらしいものへと成長した。 同じように（もっともスケールは小さいけれど）ぼくは Carl Harris と Harry Hochheiser のアイデアをもとにして、それをつきつめた。 ぼくらのいずれも、みんなが天才というものを考えるロマンチックな意味では 「独創的」じゃなかった。でも、科学も工学もソフト開発も、 ほとんどは独創的な天才の手になるものではないんだ。 ハッカー神話がなんと言おうとも。

　でも結果はそれでもなかなか大した代物だった —— それどころか、 あらゆるハッカーが死んでもいいと思うような大成功！　 そしてこれはつまり、ぼくは自分のねらいをさらに高く設定しなきゃいけない ということを意味する。fetchmail を、いまの自分に見える可能性くらいにまで 優れたものにするためには、自分のニーズのためだけにコードを書くのではなく、 自分の守備範囲ははずれていても他人が必要としているような機能を加え、 サポートしなくてはならなくなった。そして同時に、プログラムをシンプルで 堅牢にしておく必要もあった。

　これを認識してから書いた初の、そして圧倒的にいちばん重要な機能は、 マルチドロップのサポートだった。これはつまり、複数ユーザ宛のメールが 全部たまっているメールボックスからメールをとってきて、 それぞれのメールを個別受信者に選り分ける機能だ。

　マルチドロップのサポートを足すことにしたのは、一つには一部のユーザが しつこくせがんだこともある。でも最大の理由は、アドレッシングを最大限に 一般化して対応せざるを得なくなることで、シングルドロップのコードのバグを 全部ひねりつぶせるだろうと思ったからだ。そしてそれは立派に実証された。 RFC 822 http://info.internet.isi.edu:80/in-notes/rfc/files/rfc822.txt を解析してきちんと実装するには、えらく長い時間がかかった。これは 個別部分が特にむずかしかったからではなく、相互に依存しあった面倒な細部を 山ほど片づけなきゃならなかったからだ。

　でもマルチドロップアドレッシングは、ふたをあけてみたらこれまた すばらしい設計上の決定だった。なぜそう思ったかというと：

14. ツールはすべて期待通りの役にたたなきゃダメだが、 すごいツールはまったく予想もしなかったような役にも たってしまう。

　—— からだ。マルチドロップ fetchmail の予想もしない利用法は、 メーリングリストを運用する際に、リストの管理や alias の展開を、SLIP/PPP 接続のクライアント側でできちゃえることだった。 これはつまり、ISP のアカウント経由で個人マシンを走らせてる人でも、 ISP の alias ファイルに絶えずアクセスすることなしにメーリングリストを 運用できるってことだ。

　もう一つ、ベータテスタたちが要求してきた重要な変更は、8 ビット MIME の サポートだった。これはすごく楽だった。ぼくは自分のコードを 8 ビットクリーンにするように心がけてきたからだ。これは、こういう機能への 要望を予想してたからではない。こんな別のルールに従ったまでのことだった：

15. ゲートウェイソフトを書くときはいかなる場合でも、 データストリームへの干渉は最低限におさえるように必死で努力すること。 そして受け手がわがどうしてもと言わない限り、絶対に情報を 捨てないこと！

　この規則を守っていなかったら、8 ビット MIME サポートはむずかしくて バグだらけになっただろう。でも、ぼくは守っていたので、 RFC 1652 http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1652.txt を読んで、ほんのちょっとしたヘッダ生成のロジックを加えるだけですんだ。

　ヨーロッパのユーザの一部は、セッションあたりにとってこられるメッセージ数を 制限するオプションをつけるようにしつこくせがんだ（電話代が高いので、 それを抑えるためだ）。ぼくは長いことこれを拒否してきたし、 いまでも完全に満足しているとはいいがたい。でも、世界のために書いているんなら、 顧客には耳を傾けなきゃ —— かれらがお金で支払ってるんじゃなくても、 これは変わらない。