Posten skall ut

Sedan 1993 hade jag haft hand om det tekniska på en liten 'Internet Service Provider' som hette Chester County InterLink (CCIL) i West Chester, Pennsylvania. Jag var med och startade CCIL och skrev vår unika programvara för fleranvändar bulletin-board. Du kan pröva den genom att telnetta till locke.ccil.org (telnet://locke.ccil.org). Numera servar vi nästan tretusen användare på trettio linjer. Jobbet gav mig tillgång till nätet dygnet runt via CCILs 56K linje - ja, egentligen var detta nära nog vad jobbet krävde!

Jag hade blivit tämligen van vid direktsnabb Internet e-post. Jag märkte att det blev besvärande att ständigt var tvungen att telnetta till locke för att se om där fanns e-post. Vad jag behövde var att få e-posten levererad till snark (min egen hemdator) så att jag blev meddelad när den kom och kunde hantera den med mina egna lokala verktyg.

Internets eget e-postbefordrings-protokoll, SMTP (Simple Mail Transfer Protocol), skulle inte passa så bra eftersom det fungerar bäst om maskinerna är fast anslutna till nätet, medan min egen maskin inte alltid är uppkopplad och saknar statisk IP adress. Vad jag behövde var ett program som kunde nyttja min intermittent uppkopplade uppringda förbindelse och hämta hem min e-post och leverera den lokalt. Jag visste, att det fanns sådana saker, och att flertalet av dem använde ett enkelt 'application protocol' som kallades POP (Post Office Protocol). POP har numera stöd hos flertalet vanligt förekommande e-post klienter, men på den tiden fanns det inte inbyggt i den e-post läsare som jag använde.

Jag behövde en POP3 klient. Så jag gick ut på nätet och hittade en. Ja, egentligen fann jag tre eller fyra. Jag använde en ett tag, men den saknade en naturlig finess, nämligen att plocka ut adressen ur hämtad e-post så att ett besvarande fungerade korrekt.

Problemet var följande: antag att någon som hette 'joe' på locke skickade mig ett e-brev. Om jag hämtade brevet på snark och sedan försökte besvara det, skulle mitt program glatt försöka skicka det till en icke existerande 'joe' på snark. Att editera adresserna för hand blev snart nog en pina.

Detta var något som datorn borde göra åt mig. Men ingen av de befintliga POP klienterna kunde! Detta ger oss vår första läxa:

1. Ett gott arbete börjar med att man kliar sin egen klåda.

Kanske skulle detta vara en självklarhet (det har läge sagts "Nödvändigheten är uppfinningarnas moder"), men alltför ofta använder programmerare sina dagar till att fila för sin lön på program som de varken behöver eller gillar. Men icke så i linuxvärlden - vilket kan förklara varför medelkvaliteten på programvara med ursprung i linuxvärlden är så hög.

Så kastade jag mig då in i en yster programmeringsyra för att koda upp en skinande ny POP3 klient för att tävla med de redan befintliga? Aldrig i livet! Jag undersökte noggrant alla de funktioner jag redan hade och frågade mig själv -vilken av dessa ligger närmast det jag vill ha? Därför att

2. Duktiga programmerare vet vilken kod som behöver skrivas. De framstående vet vad som finns att återanvända.

Jag låtsas inte att vara en framstående programmerare, men jag försöker imitera en sådan. Ett väsentligt drag hos de riktigt stora är konstruktiv lättja. De vet, att man inte får högsta betyg bara för att man anstränger sig, utan därför att man når ett bra resultat. Och att det är nästan alltid lättare att börja från ett gott ämne än från ingenting alls.

Linus Torvalds (http://catb.org/~esr/faqs/linus) till exempel, började inte med att skriva Linux från noll. Nej, han började med att återanvända kod och idéer från Minix, ett litet Unixliknande operativsystem för PC kloner. Så småningom blev all kod från Minix ersatt eller totalt omgjord, men medan den fanns där var den som en byggnadsställning för det som senare skulle bli Linux.

I samma anda letade jag efter en befintlig POP programvara som var någorlunda väl kodad, för att användas som en utvecklingsplattform.

Traditionen inom Unix-världen är att dela med sig av källkod och att vara välvillig till återvinning av kod (det är skälet till att GNU-projektet har valt Unix som sin plattform, trots reservationer om operativsystemet som sådant). Linuxvärlden har dragit denna tradition till sin gräns; den har terabyte av öppen källkod tillgänglig för envar. Så att använda tid till att leta upp någon annans nästan-tillräckligt-bra-kod ger sannolikt bättre resultat i Linuxvärlden än någon annanstans.

Det gjorde det för mig. Tillsammans med de jag redan hade funnit, gav min andra sökning nio kandidater - fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail och upop. Den som jag först fastnade för var fetchpop av Seung-Hong Oh. Jag lade in en 'header-rewrite' funktion i programmet, och gjorde en del andra förbättringar som dess författare accepterade i sin 1.9 utgåva.

Ett par veckor senare snubblade jag över koden för 'popclient' av Carl Harris, och såg att jag hade ett problem. Även om fetchpop hade en hel del originella tankar inbyggda (som dess möjlighet att köra som demon i bakgrunden), kunde den endast hantera POP3 och var ganska amatörmässigt kodad. (Seung-Hong var vid det laget en klipsk men oerfaren programmerare, och båda dessa drag syntes.) Carls kod var bättre, professionell och solid, men hans program saknade en del viktiga funktioner som fanns i fetchpop och som var ganska svåra att implementera (inklusive de jag hade kodat själv).

Stanna eller byta? Om jag bytte skulle jag slänga bort det kodningsarbete jag redan hade gjort i utbyte mot en bättre bas för den framtida utvecklingen.

Ett skäl att byta var att det fanns stöd för flera protokoll. POP3 var det vanligast förekommande bland protokoll för e-postservrar, med inte det enda. Fetchpop och de övriga konkurrenterna hanterade inte POP2, RPOP eller APOP, och jag hade redan en förhoppning om att kunna lägga till IMAP (http://www.imap.org) (Internet Message Access Protocol, det senaste och mest kapabla bland e-post protokoll), mest på skoj.

Men jag hade också en mer teoretisk anledning till ett byte, något jag hade lärt mig långt tidigare än Linux.

3. "Planera för att kasta en; det kommer du ändå att göra." (Fred Brooks, "The Mythical Man-Month", kapitel 11).

Eller, för att säga det på ett annat sätt, man förstår oftast inte riktigt problemet förrän man först har fått till en lösning. Andra gången kanske man vet tillräckligt för att göra det rätt. Så om man vill ha det rätt, måste man vara beredd på att börja om från början minst en gång [JB].

Så jag intalade mig att ändringarna i fetchpop var mitt första försök. Och så bytte jag.

Efter att jag skickat iväg min första sändning patchar till Carl Harris den 25 Juni 1996, fick jag veta att han hade tappat intresset för popclient vid det laget. Koden var en smula dammig, med vissa mindre buggar som hängde kvar. Jag ville göra många ändringar och vi kom snart överens om att det mest logiska var att jag tog över programmet. Utan att jag riktigt hade märkt det, så hade mitt projekt trappats upp. Nu grubblade jag inte bara på små patchar till en befintlig POP klient. Jag hade fått ansvaret för att underhålla en hel sådan, och jag hade idéer bubblande i skallen som jag kände skulle leda till väsentliga förändringar.

I en programmerarkultur som uppmuntrar till att man delar med sig av kod, är detta ett naturligt sätt för ett projekt att utvecklas. Jag tillämpade följande princip:

4. Har du rätt attityd, kommer intressanta problem att hitta dig.

Men Carl Harris attityd var väl så viktig. Han förstod att

5. Om man tappar intresset för ett program, så är ens sista plikt att lämna över det till en kompetent efterföljare.

Utan att ens behöva diskutera saken, visste både Carl och jag att det var ett mål för oss båda att den bästa lösningen skulle finnas därute på nätet.

Frågan var bara om jag kunde övertyga honom om att mina två händer var säkra händer. När jag väl hade lyckats med det, agerade han snabbt och med heder. --- Jag hoppas att även jag kommer att göra så i min tur.