เมื่อใดที่กุหลาบจะไม่เป็นกุหลาบ?

เมื่อได้ศึกษาวิธีการของไลนัส และสร้างทฤษฎีว่ามันสำเร็จได้อย่างไรแล้ว ผมได้ตัดสินใจที่จะทดสอบทฤษฎีนี้กับโครงการของผมเอง (ที่ต้องยอมรับว่าซับซ้อนน้อยกว่าและทะเยอทะยานน้อยกว่ามาก)

แต่สิ่งแรกที่ผมทำ คือการปรับ popclient ให้ลดความซับซ้อนลง งานของคาร์ล แฮรริส นั้นดูดี แต่ก็ได้สร้างความซับซ้อนที่ไม่จำเป็น ตามแบบที่โปรแกรมเมอร์ภาษาซีหลายคนชอบทำ เขามองตัวโค้ดเป็นศูนย์กลาง และโครงสร้างข้อมูลเป็นส่วนสนับสนุนของโค้ด ผลก็คือ โค้ดนั้นสวยงามดี แต่โครงสร้างข้อมูลออกแบบตามอำเภอใจและค่อนข้างแย่ (อย่างน้อยก็แย่ตามมาตรฐานที่สูงอยู่แล้วของแฮ็กเกอร์ Lisp มือฉมังคนนี้)

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

ในราวเดือนแรก ผมทำตามแนวทางที่คาร์ลออกแบบไว้ ความเปลี่ยนแปลงที่สำคัญอย่างแรกที่ผมทำ คือเพิ่มการสนับสนุน IMAP ผมทำโดยการจัดระบบโพรโทคอลใหม่ให้เป็นไดรเวอร์ทั่วไปหนึ่งตัว และตารางวิธีการสามอัน (สำหรับ POP2, POP3 และ IMAP) การเปลี่ยนแปลงทั้งครั้งนี้และครั้งก่อน แสดงให้เห็นหลักการทั่วไปที่โปรแกรมเมอร์ควรจำให้ขึ้นใจ โดยเฉพาะสำหรับภาษาอย่างซี ซึ่งไม่ได้สนับสนุนชนิดข้อมูลแบบพลวัต นั่นคือ:

9. โครงสร้างข้อมูลที่ฉลาดกับโค้ดที่โง่ ทำงานได้ดีกว่าในทางกลับกัน

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

ณ จุดนี้ (ต้นเดือนกันยา 1996 ทำมาแล้วประมาณ 6 อาทิตย์) ผมเริ่มคิดจะเปลี่ยนชื่อโครงการแล้ว เพราะมันไม่ใช่แค่โปรแกรมสำหรับ POP อีกต่อไป แต่ผมยังไม่แน่ใจ เพราะมันยังไม่มีอะไรใหม่จริงๆ ในด้านการออกแบบ popclient รุ่นของผมยังไม่ได้พัฒนาเอกลักษณ์เป็นของตัวเองเลย

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

ผลลัพธ์จากมาตรการง่ายๆ เหล่านี้เห็นได้รวดเร็ว ตั้งแต่เริ่มโครงการ ผมได้รับการรายงานบั๊กที่มีคุณภาพระดับที่นักพัฒนาอยากได้ใจจะขาด และบ่อยครั้งที่มีวิธีแก้มาให้ด้วย ผมได้รับคำวิจารณ์ที่ให้แนวคิดที่ดี ได้รับเมลจากแฟนๆ ได้รับคำแนะนำคุณสมบัติใหม่ๆ ซึ่งนำไปสู่:

10. ถ้าคุณปฏิบัติกับผู้ทดสอบรุ่นเบต้า เหมือนกับเป็นแหล่งทรัพยากรชั้นเยี่ยมแล้ว เขาจะตอบแทนด้วยการเป็นทรัพยากรชั้นเยี่ยมให้

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

ความจริงแล้ว ตั้งแต่ผมเริ่มแก้ไขปรับปรุงบทความในปลายเดือนพฤษภาคม 1997 ผมพบว่าคนในรายชื่อเริ่มจะลดจำนวนลงจากเกือบ 300 คนในตอนแรก ด้วยเหตุผลที่น่าสนใจ คือ หลายๆ คนได้ขอให้ผมเอาชื่อเขาออก เพราะ fetchmail ทำงานได้ดีแล้ว จนพวกเขาไม่ต้องการมีส่วนร่วมในการสนทนาอีก บางที นี่อาจจะเป็นส่วนหนึ่งในวงจรชีวิตของโครงการแบบตลาดสดที่โตเต็มที่แล้วก็ได้