2 Post muss immer ankommen

Seit 1993 kümmere ich mich um die technische Seite eines kleinen Gratis-ISP namens  >Chester County InterLink (CCIL) in West Chester in Pennsylvania (ich bin Mitbegründer von CCIL und schrieb unsere einzigartige Multiuser BBS-Software -- man kann sie sich durch einen telnet zu locke.ccil.org  telnet://locke.ccil.org/ ansehen. Heute werden fast dreitausend Benutzer auf dreißig Leitungen unterstützt). Der Job gestattete mir nicht nur den Zugriff auf CCILs 56K-Leitung , sondern machte ihn praktisch unbedingt notwendig!

Dementsprechend gewöhnte ich mich an einen ununterbrochenen Zugriff auf Internet E-Mail. Aus komplizierten Gründen war es sehr schwierig, SLIP (Serial Line Internet Protocol) für die Verbindung zwischen meiner Maschine zu Hause (snark.thyrsus.com) und CCIL tauglich zu machen. Als ich endlich Erfolg damit hatte, fand ich das periodische Telnetten zu locke.ccil.org bald lästig. Was ich wollte, war eine sofortige Übermittlung meiner elektronischen Post zu meiner snark-Maschine und eine Benachrichtigung des Eintreffens, um sie gleich mit meiner lokalen Software bearbeiten zu können.

Ein schlichtes Weiterreichen durch  sendmail hätte nicht funktioniert, da meine persönliche Maschine nicht immer am Netzwerk angeschlossen ist und keine statische  IP-Adresse hat. Was ich brauchte, war ein Programm, das über meine SLIP-Verbindung die E-Mail abholte und lokal verfügbar machte. Ich wusste, dass es derartige Software gab, und dass die meiste davon ein einfaches Anwendungsprotokoll namens  POP (Post Office Protocol) verwendete. Es gab natürlich bereits einen POP3-Server als Teil von Locke's Betriebssystem  BSD/OS.

Ich brauchte also einen POP3-Klienten. So ging ich hinaus ins Netz und fand einen. Tatsächlich fand ich sogar drei oder vier. Einige Zeit lang verwendete ich  pop-perl, vermisste aber ein für mich sehr plausibles Leistungsmerkmal -- die Fähigkeit, die Adressen in abgeholter E-Mail umzuhacken, so dass auch die Antworten darauf richtig weitergereicht würden.

Das Problem war folgendes. Nehmen wir an, jemand namens joe mit einem Mail-Konto bei locke würde mir eine E-Mail schicken. Wenn ich dann die Mail zu mir auf meine snark-Maschine hole und dann versuche, darauf zu antworten, dann würde mein Mailer diese Antwort an einen nicht-existenten joe auf snark schicken. Ein händisches Ergänzen von @ccil.org wird schnell zu einer ernsthaften Plage.

Das war ganz offensichtlich eine Mühe, die sich der Computer machen sollte, nicht ich. Aber keiner der existierenden POP-Klienten konnte das tun. Und das bringt uns zur ersten Lektion:

1. Jede gute Software beginnt mit den persönlichen Sehnsüchten eines Entwicklers.

Das hätte vielleicht jedem sofort einleuchten sollen (schließlich gibt es das Sprichwort Not macht erfinderisch schon seit geraumer Zeit), aber viel zu oft haben Softwareentwickler ihre Tage mit der Arbeit an Programmen verbringen müssen, die sie weder gebraucht noch geliebt haben. Aber nicht in der Linux-Welt -- was vielleicht die überdurchschnittliche Qualität der von der Linux-Gemeinde geschaffenen Software erklärt.

Setzte ich mich also gleich hin und begann im Schaffensrausch einen brandneuen POP3-Klienten zu codieren, der mit den bereits bestehenden konkurrierte? Das kam natürlich nicht in Frage und war auch nicht nötig. Ich erforschte sorgfältig die POP-Utilities, die ich zur Hand hatte und stellte mir die Frage: Welcher davon kommt meinen Anforderungen am nächsten? Denn was gilt, ist dies:

2. Gute Programmierer wissen, welchen Code sie schreiben sollen. Großartige Programmierer wissen, welchen Code sie umschreiben (und recyceln) können.

Obwohl ich nicht behaupte, ein großartiger Programmierer zu sein, bemühe ich mich immer, einen zu imitieren. Ein wichtiger Charakterzug großartiger Programmierer ist konstruktive Faulheit. Sie alle wissen, dass man sehr gute Noten nicht durch sehr großen Aufwand, sondern durch sehr gute Resultate bekommt -- und dass es fast immer einfacher ist, bei einer guten Teillösung anzufangen als ganz von vorne.

 Linus Torvalds zum Beispiel versuchte erst gar nicht, Linux ohne grundlegenden Code auf der grüne Wiese zu erstellen. Stattdessen borgte er Code und Ideen von  Minix, einem Unix-ähnlichen Betriebssystem für PC-Clones. Schließlich war aller Minix-Code durch neu entwickelten Code ersetzt oder komplett umgeschrieben -- aber solange er präsent war, lieferte er ein Gerüst für den Säugling, der schließlich zu  Linux wurde.

Nach der gleichen Philosophie suchte ich nach einem bestehenden POP-Utility, das ausreichend gekonnt geschrieben war und als Grundlage für meine Weiterentwicklung dienen konnte.

Die Tradition der Weitergabe von Software der Unix-Welt war dem Recyceln von Code gegenüber immer sehr wohlwollend und aufgeschlossen eingestellt (was auch der Grund dafür ist, dass das GNU-Projekt Unix als sein Basis-Betriebssystem gewählt hat - und das trotz starker Vorbehalte gegenüber Unix selbst). Die Linux-Welt hat diese Tradition bis fast an die Grenzen des technisch Möglichen weitergeführt und stellt Terabytes an offen gelegtem Sourcecode zur Verfügung. Daher ist es in der Linux-Welt am wahrscheinlichsten, bei der Arbeit an eigenen Projekten auf ausreichend guten Source-Code zu stoßen, als irgendwo sonst.

Bei meinem Projekt funktionierte es. Zusammen mit den schon vorher gefundenen Programmen hatte ich nach meiner zweiten Suche insgesamt neun Kandidaten -- fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail und upop. Als erstes entschied ich mich für fetchpop von Seung-Hong Oh. Ich fügte meinen Code zum automatischen Umschreiben von Headern ein und nahm eine Reihe anderer Verbesserungen vor, die der Autor in seine Release 1.9 aufnahm.

Ein paar Wochen später aber stolperte ich über den Code für  popclient von Carl Harris und fand heraus, dass ich ein Problem hatte. Obwohl fetchpop ein paar gute und originelle Ideen implementierte (wie etwa seinen Daemon-Mode), konnte es nur POP3 bedienen und war auch sehr laienhaft geschrieben (Seung-Hong war damals ein brillanter, aber unerfahrener Programmierer und beides konnte man an fetchpop sehr gut erkennen). Carls Code war besser, sehr professionell und solide, aber dem Programm fehlten einige wichtige und knifflig zu implementierende Leistungsmerkmale, die fetchpop sehr wohl hatte (darunter auch die von mir geschriebenen).

Würde es sich lohnen zu wechseln? Wenn ich wechselte, müsste ich meinen schon geschriebenen Code verwerfen und würde dafür eine bessere Ausgangsbasis gewinnen.

Ein praktischer Anreiz dafür war die Unterstützung mehrerer Protokolle. POP3 ist das üblichste Protokoll für  Post Office Server, aber nicht das einzige. Fetchpop und seine Mitbewerber konnten kein POP2, RPOP oder APOP, und ich hatte bereits vage Pläne für einen Zusatz für  IMAP (Internet Message Access Protocol, das neueste und mächtigste Post Office-Protokoll), das ich nur so zum Spaß implementieren wollte.

Es gab aber noch einen - theoretischeren - Anreiz, einen Wechsel zu popclient zu erwägen. Das hatte mit etwas zu tun, das ich schon lange vor Linux gelernt hatte.

3. "Plane eines für den Papierkorb; auf die eine oder andere Art machst du das sowieso." (Frederick P. Brooks, "Vom Mythos des Mann-Monats", Kapitel 11, in Addison-Wesleys Übersetzung von Arne Schäpers und Armin Hopp).

Anders gesagt: oft versteht man das Problem gar nicht richtig, bevor man nicht die erste Implementation einer Lösung wenigstens halbwegs vollendet hat. Beim zweiten Mal hat man aber vielleicht schon genug gelernt, um es dann richtig zu machen. Wenn man also eine gute Implementation wünscht, sollte man sich darauf gefasst machen, wenigstens einmal ganz von vorne anzufangen [ JB].

Nun, so sagte ich mir, meine Verbesserungen an fetchpop waren mein erster Versuch. Auf zu popclient.

Nachdem ich am 25. Juni 1996 meine ersten Patches für popclient an Carl Harris geschickt hatte, fand ich heraus, dass er schon einige Zeit vorher jedes Interesse an seinem Programm verloren hatte. Der Code war ein wenig verstaubt und enthielt kleinere Fehler. Ich musste viele Änderungen machen und wir kamen schnell überein, dass es das logischste wäre, wenn ich das Programm einfach übernehmen würde.

Ohne dass ich es wirklich gemerkt hatte, war das Projekt eskaliert. Ich dachte nicht mehr einfach über kleine Patches für einen bestehenden POP-Klienten nach. Ich übernahm die Wartung eines ganzen Programmpakets und in meinem Kopf nahmen Ideen Formen an, von denen ich wusste, dass sie zu weitreichenden Umstellungen führen würden.

In einer Software-Kultur, die zur gemeinsamen Nutzung von Code ermuntert, ist das der natürliche Weg, auf dem sich Projekte weiterentwickeln. Ich tat nichts anderes, als folgende Regel zu leben:

4. Mit der richtigen Einstellung werden interessante Probleme dich finden.

Aber Carl Harris Haltung war sogar noch wichtiger. Er verstand, dass

5. Sobald man das Interessen an seinem Programm verliert, ist es die letzte Pflicht, es einem kompetenten Nachfolger zu überlassen.

Ohne es jemals diskutiert haben zu müssen, wussten Carl und ich, dass wir eine gemeinsame Vorstellung von der besten Lösung hatten. Die einzige Frage war für jeden von uns beiden, ob ich meine Qualifikation dafür beweisen könnte. Sobald ich das getan hatte, handelte er großzügig und gelassen. Ich hoffe, dass ich es auch so gut machen werde, sobald die Zeit gekommen ist.