När är en ros inte en ros?

Efter att ha studerat hur Linus har gått till väga och efter att ha funderat ut en teori om varför hans metod blev så framgångsrik, beslutade jag mig för att pröva teorin på ett nytt, låt vara betydligt mindre komplicerat och mindre ambitiöst, projekt.

Men först ville jag omorganisera och förenkla popclient en hel del. Carl Harris utformning var sund, men visade den sorts onödiga komplexitet som är vanligt förekommande hos många C programmerare. Han betraktade koden som central och datastrukturerna som ett bihang. Resultatet var att koden blev vacker, men att datastrukturerna var ad-hoc och ganska eländiga. I varje fall jämfört med den höga standarden hos denne gamle LISPhackare.

Jag hade emellertid också en annan avsikt med att skriva om programmet förutom att förbättra koden och datastrukturerna. Det var att ändra det till något som jag förstod fullt ut. Det är inte roligt att ha ansvar för, och att rätta fel i, ett program som man inte förstår.

Så de första månaderna följde jag helt Carls grundläggande konstruktion. Den första större förändring jag gjorde var att lägga till stöd för IMAP. Jag gjorde detta genom att göra om protokollmaskinerna till en generisk drivrutin med tre metodtabeller (för POP2,POP3 och IMAP) Detta och de tidigare ändringarna illustrerar en generell princip för bra programmering att ha i minnet. i synnerhet i ett språk som C som inte på ett naturligt sätt har stöd för dynamisk programmering:

9. Smarta datastrukturer och dum kod fungerar bättre än tvärtom.

Brooks, kapitel 9: "Visa mig din [kod] och göm dina [datastrukturer], och jag kommer att vara förbryllad alltjämt. Visa dina datastrukturer och jag behöver inte se din [kod], den kommer att var självklar."

Egentligen sade han "flödesschema" och "tabeller". Men med ett trettio år senare språkbruk så är det samma andemening.

Vid denna tidpunkt (tidigt i september 1996, sex veckor från noll) började jag tänka att ett namnbyte skulle lämpa sig. Det var ju inte bara en POP klient längre. Men jag tvekade, för det var ju inte något genuint nytt i konstruktionen. Min version av popclient hade ännu inte någon egen identitet.

Detta ändrades radikalt när fetchmail lärde sig att leverera e-post till en SMTP port. Jag kommer strax till detta. Men först: Jag sade ovan att jag hade beslutat använda detta projekt för att pröva min teori om hur Linus Torvalds hade lyckats. Hur gjorde jag det? På följande sätt:

1. Jag gav ut tidigt och ofta. Nästan aldrig mindre än var tionde dag och under intensiva perioder dagligen.
2. Jag lät min lista av betatestare växa och lade till alla som kontaktade mig om fetchmail.
3. Jag annonserade i betatestlistan inför varje utgåva, och uppmanade folk att delta.
4. Och jag lyssnade på mina betatestare, frågade om råd om utformningen och strök dem medhårs närhelst de sände in patchar och gav återkoppling.

Dessa enkla åtgärder lönades omedelbart. Från första början fick jag felrapporter av en kvalitet som de flesta utvecklare knappt kan drömma om, ofta med bra lösningar medskickade. Jag fick genomtänkt kritik, beundrarpost och insiktsfulla råd om nya faciliteter.

Vilket leder till:

10. Om man behandlar sina betatestare som ens mest värdefulla tillgång, besvaras detta med att de blir ens mest värdefulla tillgång.

Ett intressant mått på fetchmails framgång är projektets lista av betatestare. Fetchmail-vännerna. Vid tiden för den senaste revisionen, (Augusti 2000) var den 249 och den växte med två eller tre i veckan.

Faktiskt, som jag minns det från Maj 1997 så började listan förlora medlemmar från sin höjdpunkt på nära 300 av ett intressant skäl. Några personer bad att bli avskrivna eftersom de tyckte att fetchmail fungerade så bra att de inte längre behövde följa listan! Detta är kanske en normalt sätt att mogna för ett projekt i basarstilen.