แล้วผมก็อยู่กับการออกแบบที่เนี้ยบและมีนวัตกรรม อยู่กับโค้ดที่ผมรู้ว่าทำงานได้ดี เพราะผมใช้อยู่ทุกวัน และอยู่กับผู้ทดสอบเบต้าที่เพิ่มขยายขึ้นเรื่อยๆ ผมเริ่มรู้สึกทีละนิด ว่าผมไม่ได้ผูกพันกับการแฮ็กเล็กๆ น้อยๆ ของตัวเองที่อาจจะบังเอิญมีประโยชน์กับคนอื่นบางคนอีกต่อไป แต่ผมกำลังเขียนโปรแกรมที่แฮ็กเกอร์ที่ใช้ยูนิกซ์และอ่านเมลผ่าน SLIP/PPP ทุกคนต้องมี

ด้วยความสามารถส่งเมลต่อไปยัง SMTP ทำให้ fetchmail นำหน้าคู่แข่งไปไกลจนถึงขั้นสามารถเป็น ``killer'' หรือโปรแกรมอมตะที่เติมช่องว่างได้อย่างเฉียบขาด จนทำให้ตัวเลือกอื่นไม่ใช่แค่ถูกทิ้งไป แต่แทบจะถูกลืมไปเลย

ผมคิดว่าคุณไม่อาจจะตั้งเป้าหรือวางแผนเพื่อให้โปรแกรมมาถึงจุดนี้ได้เลย คุณต้องเป็นไปเอง ด้วยแนวคิดการออกแบบที่ทรงพลังพอที่ผลลัพธ์ที่ออกมาจะกลายเป็นสิ่งที่เลี่ยงไม่ได้ เป็นธรรมชาติ หรือแม้แต่เหมือนถูกลิขิตไว้ วิธีเดียวที่จะได้สุดยอดแนวคิดอย่างนั้นมา คือต้องมีความคิดจำนวนมาก หรือไม่ก็มีวิจารณญาณทางวิศวกรรมที่นำความคิดของผู้อื่นมาใช้ โดยที่เจ้าของไม่นึกว่าจะนำมาใช้ได้ขนาดนี้

แอนดี้ ทาเนนบอม มีความคิดเริ่มแรกคือสร้างยูนิกซ์ง่ายๆ สำหรับ IBM PC โดยเฉพาะ เพื่อใช้เป็นตัวอย่างในการสอนหนังสือ (เขาเรียกมันว่ามินิกซ์) ไลนัส ทอร์วัลด์ ผลักดันแนวคิดของมินิกซ์ต่อไปจนไกลเกินกว่าที่แอนดี้จะเคยนึกถึง และมันก็กลายเป็นสิ่งมหัศจรรย์ ในทำนองเดียวกัน (แต่ขนาดเล็กกว่า) ผมนำแนวคิดบางอย่างของ คาร์ล แฮร์ริส และ Harry Hochheiser มาใช้ แล้วผลักดันต่ออย่างจริงจัง ในบรรดาพวกเรา ไม่มีใครสักคนที่เป็น `ผู้คิดค้น' ในแบบที่ผู้คนนึกฝันว่าเป็นอัจฉริยะเลย แต่จริงๆ แล้วผลงานทางวิทยาศาสตร์ วิศวกรรม และการพัฒนาซอฟต์แวร์นั้น ส่วนมากไม่ได้เกิดจากอัจฉริยะที่เป็นผู้คิดค้นเลย เรื่องพวกนั้นเป็นตำนานปรัมปราของแฮ็กเกอร์เสียมากกว่า

ผลลัพธ์ที่ออกมาร้อนแรงพอๆ กัน จะว่าไปแล้ว ก็เป็นความสำเร็จชนิดที่แฮ็กเกอร์ทุกคนฝันถึงเลย และนั่นหมายความว่า ผมต้องตั้งมาตรฐานของตัวเองให้สูงขึ้น และในการทำให้ fetchmail ดีได้อย่างที่ผมมองเห็นความเป็นไปได้นี้ นอกจากผมจะต้องเขียนเพื่อสนองความต้องการของตัวเองแล้ว ยังต้องเพิ่มความสามารถที่คนอื่นที่อยู่นอกแวดวงของผมต้องการอีกด้วย ในขณะเดียวกัน ก็ต้องรักษาตัวโปรแกรมให้เรียบง่ายและแน่นหนาดังเดิมด้วย

ความสามารถสำคัญอันแรกที่ผมเพิ่มเข้ามาหลังจากตระหนักถึงความจริงข้างต้น คือการสนับสนุน multidrop หรือความสามารถที่จะดึงเมลจากกล่องเมลรวมที่รวมเมลของผู้ใช้กลุ่มหนึ่ง ไปกระจายให้กับผู้ใช้แต่ละคนตามที่จ่าหน้าในเมล

ผมตัดสินใจที่จะเพิ่มการสนับสนุน multidrop ส่วนหนึ่งเพราะมีผู้ใช้จำนวนหนึ่งเรียกร้อง แต่สาเหตุสำคัญคือ ผมคาดว่ามันจะช่วยแก้บั๊กต่างๆ ในโค้ดส่วน single drop ออกไปด้วย เพราะจะเป็นการบังคับให้ผมมาสนใจกับการจัดการเรื่องที่อยู่เมลในรูปทั่วไปจริงๆ เสียที และมันก็เป็นอย่างที่ผมคิด การแจงที่อยู่เมลแบบ RFC 822 ให้ถูกต้อง กินเวลาของผมไปมาก ไม่ใช่เพราะว่าโค้ดของมันยาก แต่มันมีรายละเอียดที่เกี่ยวพันกันค่อนข้างเยอะ

แต่การเพิ่มการจัดการที่อยู่เมลแบบ multidrop เข้ามานั้น กลายเป็นการตัดสินใจที่ยอดเยี่ยมเกี่ยวกับการออกแบบ ตอนนี้ผมรู้ว่า:

การใช้ fetchmail แบบ multidrop ที่คาดไม่ถึง คือใช้ทำเมลลิ่งลิสต์ โดยเก็บรายชื่อสมาชิกและกระจายเมลในฝั่ง เครื่องลูกข่าย ของการเชื่อมต่ออินเทอร์เน็ต ซึ่งหมายความว่า ใครก็ตามที่มีเครื่องต่อกับอินเทอร์เน็ตผ่านบัญชีของ ISP ก็สามารถจัดการกับเมลลิ่งลิสต์ได้ โดยไม่ต้องอาศัยแฟ้ม alias ในฝั่งของ ISP เลย

การเปลี่ยนแปลงที่สำคัญอีกอย่างที่นักทดสอบของผมเรียกร้องคือ สนับสนุน MIME (Multipurpose Internet Mail Extensions) แบบ 8 บิต ซึ่งอันนี้ทำค่อนข้างง่าย เพราะผมได้ระวังให้โค้ดทำงานแบบ 8 บิตได้มาตั้งแต่ต้น (กล่าวคือ โดยไม่พยายามใช้งานบิตที่ 8 ที่ไม่ได้ใช้ในรหัส ASCII มาเก็บข้อมูลในโปรแกรม) ที่ผมทำเช่นนี้ไม่ใช่เป็นเพราะคาดไว้ก่อนว่าจะต้องเพิ่มความสามารถนี้ แต่เป็นเพราะผมทำตามกฎอีกข้อหนึ่ง:

ถ้าผมไม่ปฏิบัติตามกฎนี้ การสนับสนุน MIME แบบ 8 บิตจะยากและเต็มไปด้วยบั๊ก แต่สิ่งที่ผมต้องทำจริงๆ ก็แค่อ่านมาตรฐานของ MIME (RFC 1652) และเพิ่มส่วนแก้ไขข้อมูลส่วนหัวนิดเดียว

ผู้ใช้บางคนจากยุโรปเรียกร้องให้ผมเพิ่มตัวเลือกในการจำกัดจำนวนเมลที่จะดึงในแต่ละครั้ง (เพื่อที่พวกเขาจะได้สามารถควบคุมค่าโทรศัพท์ได้) ผมปฏิเสธเรื่องนี้เป็นเวลานาน และผมก็ยังไม่ชอบความสามารถนี้เท่าไรนัก แต่ถ้าคุณเขียนโปรแกรมให้โลกใช้ คุณต้องฟังเสียงของผู้ใช้ เงื่อนไขนี้ไม่ได้เปลี่ยนแปลงเพียงเพราะเขาไม่ได้ได้จ่ายคุณเป็นตัวเงิน