Da war ich also mit einem eleganten und innovativen Design, Code, von dem ich wußte, daß er gut funktionierte, da ich ihn jeden Tag verwendete, und einer lebhaft wachsenden Beta-Liste. Nach und nach dämmerte mir, daß ich nicht mehr mit einem trivialen persönlichen Hack befaßt war, der einigen Leuten nützlich sein konnte. Ich hatte meine Finger in einem Programm, daß jeder Hacker mit einer Unix-Maschine und einer SLIP/PPP-Mailverbindung wirklich braucht.
Durch das Leistungsmerkmal des SMTP-Forwarding zog fetchmail der Konkurrenz soweit davon, daß es realistisch wurde, in ihm einen baldigen "Kategorienkiller" zu sehen, eines jener klassischen Programme, die eine Nische so kompetent ausfüllen, daß Alternativen nicht einfach nur weggeworfen, sondern fast vergessen werden.
Ich denke, man kann ein solches Ergebnis nicht wirklich planen oder anstreben. Man muß von Designideen hineingezogen werden, die so mächtig sind, daß sie im Rückblick wie offensichtlich, natürlich oder sogar gottgewollt wirken. Die einzige Möglichkeit, so eine Idee zu finden, ist, eine Menge solcher Ideen zu haben -- oder das technische Urteilsvermögen, um die guten Ideen anderer Leute jenseits deren Vorstellungen weiterzuentwickeln.
Andy Tanenbaum hatte die ursprüngliche Idee, ein einfaches Unix für den IBM PC zu schaffen, der eigentlich ein Lehrbehelf war. Linus Torvalds hievte das Minix-Konzept weiter als Andrew es wahrscheinlich für möglich gehalten hätte -- und es wurde etwas ganz wunderbares daraus. In der selben Weise (nur in kleinerem Maßstab) übernahm ich einige Ideen von Carl Harris und Harry Hochheiser und hetzte sie zu Höchstleistungen. Keiner von uns war "originell" in dem romantischen Sinne, in dem sich die Leute ein Genie vorstellen. Es ist aber so, daß die Wissenschaften, Ingenieurskünste und Softwareentwicklungen nicht von Genies weitergebracht werden, was immer anderes die Hackermythologie auch behauptet.
Die Resultate konnten sich trotzdem sehen lassen -- tatsächlich war es genau die Sorte Erfolg, für die jeder Hacker lebt! Und das bedeutete, daß ich meine Latte noch höher legen mußte, um fetchmail so gut zu machen, wie ich nun sah, daß es werden konnte. Ich mußte nicht nur für den eigenen Bedarf schreiben, sondern auch Leistungsmerkmale unterstützen, die für Menschen außerhalb meines Orbits wichtig wären. Und simpel und robust sollte mein Programm auch noch sein.
Das erste und mit Abstand wichtigste Leistungsmerkmal, das ich nach dieser Erkenntnis schrieb, war Multidrop-Unterstützung -- die Fähigkeit, Mail aus Mailboxes zu holen, die alle Mail für eine ganze Gruppe von Benutzern angesammelt hatte, und dann jede einzelne davon an die jeweiligen Empfänger zuzustellen.
Ich entschied mich für den Einbau von Multidrop-Unterstützung zum Teil deswegen, weil Benutzer es sehr nachdrücklich forderten, aber der Hauptgrund dafür war meine Überlegung, daß es einige Bugs aus dem Single Drop-Code herausrütteln würde, da es mich zwang, Adressierung in allgemeinster Form zu behandeln. Und genau so war es auch. Das Parsing RFC 822- konform zu bekommen kostete mich erstaunlich viel Zeit, die aber nicht für ein individuelles, besonders kniffliges Stück Code draufging, sondern weil es eine Menge Details gab, die alle voneinander abhängig waren und peinlich genaue Implementation erforderten.
Die Verbesserung lohnte sich aber; die Multidrop-Adressierung stellte sich als eine exzellente Design-Entscheidung heraus. Ich wußte danach auch, warum:
14. Jedes Tool sollte in der erwarteten Weise nützlich sein, aber wirklich großartige Tools bieten darüber hinaus unerwarteten Nutzen.
Der unerwartete Nutzen von fetchmail mit Multidrop ist der, daß damit eine Mailingliste mit Alias-Expansion betreiben kann -- und das von der Klientenseite der SLIP/PPP-Verbindung aus. Das bedeutet, daß jemand mit einem ISP-Konto eine Mailingliste ohne Zugriff auf die Alias-Dateien des ISP unterhalten kann.
Eine weitere bedeutende Änderung, die von meinen Betatestern gefordert wurde, war die Unterstützung von 8 bit MIME-Betrieb. Das war releativ einfach, da ich mir Mühe gegeben hatte, den Code 8-bit-clean zu halten. Nicht daß ich die Nachfrage für dieses Feature vorhergesehen hätte, aber ich befolgte einfach eine andere Regel:
15. Beim Entwickeln von Gateway-Software jeglicher Art ist jeder Aufwand gerechtfertigt, um den Datenstrom so wenig wie möglich zu beeinflussen -- und man darf Information *niemals* wegwerfen, außer der Empfänger verlangt es so!
Wenn ich diese Regel nicht befolgt hätte, wäre 8-bit MIME-Unterstützung schwierig und voller Fehler geworden. So aber war alles, was ich zu tun hatte, die RFC 1652 zu lesen und ein triviales Schnipsel von Header-generierender Logik einzubauen.
Einige europäische Benutzer nervten mich solange, bis ich eine Option einbaute, die die Anzahl der Nachrichten pro Verbindung begrenzte (so daß sie die Kosten für ihre teuren Telefonleitungen steuern konnten). Ich zierte mich lange Zeit und bin noch immer nicht ganz glücklich damit, aber wenn man für die ganze Welt Software schreibt, muß man auf seine Kunden hören -- das ändert sich auch dann nicht, wenn sie einem dafür nichts bezahlen.