ต้องส่งเมลให้ได้

ตั้งแต่ปี 1993 ผมเป็นผู้บริหารงานด้านเทคนิคของผู้ให้บริการอินเทอร์เน็ตฟรีเล็กๆ ที่ชื่อว่า Chester Country InterLink (CCIL) ซึ่งอยู่ใน West Chester รัฐเพนซิลเวเนีย ผมเป็นผู้ร่วมก่อตั้ง CCIL และได้เขียนซอฟต์แวร์กระดานข่าวที่ไม่เหมือนใครและรองรับหลายผู้ใช้ของเราขึ้น ซึ่งคุณสามารถลองได้โดยเทลเน็ตไปยัง locke.ccil.org ปัจจุบันระบบนี้รองรับผู้ใช้สามพันคนด้วยสามสิบคู่สาย งานนี้ทำให้ผมสามารถเข้าสู่อินเทอร์เน็ตได้ตลอด 24 ชั่วโมง ผ่านเครือข่ายความเร็ว 56K ของ CCIL ความจริงความสามารถนี้เป็นเรื่องจำเป็นในงานแบบนี้อยู่แล้ว

ผมเคยตัวกับการรับส่งอีเมลได้อย่างทันใจ จนรู้สึกว่าการต้องเทลเน็ตไปยัง locke เป็นระยะๆ เพื่อเช็กอีเมลนั้น เป็นเรื่องน่ารำคาญ ผมต้องการให้อีเมลของผมถูกส่งไปยัง snark (ชื่อเครื่องที่บ้านผม) เพื่อที่ผมจะได้รับการแจ้งเตือนเมื่ออีเมลมาถึง และสามารถจัดการอีเมลด้วยโปรแกรมบนเครื่องของผมเอง

โพรโทคอลหลักสำหรับส่งเมลบนอินเทอร์เน็ต คือ SMTP (Simple Mail Tranfer Protocol) นั้น ไม่ตรงกับความต้องการ เพราะมันจะทำงานได้ดีต่อเมื่อเครื่องของเราต่ออินเทอร์เน็ตอยู่ตลอดเวลา แต่เครื่องของผมไม่ได้ต่ออยู่ตลอด และไม่มีหมายเลขไอพีที่แน่นอนด้วย สิ่งที่ผมต้องการคือโปรแกรมที่ติดต่อออกผ่านการเชื่อมต่อชนิดไม่ต่อเนื่อง และดึงจดหมายมาส่งบนเครื่อง ผมรู้ว่ามีโปรแกรมประเภทนี้อยู่ และส่วนมากมักจะใช้โพรโทคอลแบบง่ายๆ ที่ชื่อ POP (Post Office Protocol) ซึ่งโปรแกรมอีเมลทุกวันนี้ส่วนมากรู้จักและสนับสนุน แต่ว่าตอนนั้น มันไม่มีอยู่ในโปรแกรมเมลที่ผมใช้อยู่

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

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

สิ่งนี้เป็นสิ่งที่คอมพิวเตอร์ควรจะทำให้ผม แต่ว่าไม่มีโปรแกรมอ่าน POP ตัวไหนเลยที่มีอยู่ในขณะนั้นที่ทำได้ และนี่ก็พาเรามารู้จักกับบทเรียนข้อแรก:

1. ซอฟต์แวร์ดีๆ เริ่มมาจากการสนองความต้องการส่วนตัวของผู้พัฒนา

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

แล้วผมก็เลยกระโจนเข้าสู่การสร้างโปรแกรม POP3 ตัวใหม่อย่างบ้าคลั่ง เพื่อเอาไปแข่งกับตัวเดิมๆ ทันทีอย่างนั้นหรือ? ไม่มีวันหรอก! ผมได้สำรวจเครื่องมือจัดการ POP ที่มีอยู่ในมือ และถามตัวเองว่า ``โปรแกรมไหนที่ใกล้เคียงกับสิ่งที่ผมต้องการมากที่สุด?'' เพราะว่า:

2. โปรแกรมเมอร์ที่ดีย่อมรู้ว่าจะเขียนอะไร แต่โปรแกรมเมอร์ที่ยอดเยี่ยมจะรู้ว่าอะไรต้องเขียนใหม่ และอะไรใช้ของเก่าได้

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

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

ด้วยแนวคิดเดียวกัน ผมจึงค้นหาโปรแกรม POP ที่มีอยู่แล้ว โดยเลือกตัวที่เขียนไว้อย่างดีพอสมควร เพื่อใช้เป็นจุดเริ่มต้นในการพัฒนา

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

แล้วมันก็ได้ผลสำหรับผม เมื่อรวมกับโปรแกรมที่ผมพบครั้งก่อน การค้นหาครั้งที่สองเพิ่มรายชื่อโปรแกรมที่เข้าท่าขึ้นเป็นเก้าตัว คือ fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail และ upop ตัวแรกที่ผมเลือกคือ fetchpop ซึ่งสร้างโดย Seung-Hong Oh ผมได้เขียนความสามารถในการเปลี่ยนหัวจดหมายเข้าไป และปรับปรุงการทำงานอื่นๆ ซึ่งผู้สร้างได้รับเข้าไปใช้ในเวอร์ชัน 1.9

ไม่กี่สัปดาห์ต่อมา ผมบังเอิญได้อ่านโค้ดของ popclient ซึ่งสร้างโดย คาร์ล แฮร์ริส เลยพบปัญหาว่า ถึงแม้ fetchpop จะมีแนวคิดดีๆ ที่ไม่เหมือนใคร (อย่างเช่นการทำงานในโหมดดีมอนเบื้องหลัง) แต่มันทำงานได้กับ POP3 เท่านั้น และโค้ดของมันก็ค่อนข้างเป็นงานของมือสมัครเล่น (ตอนนั้น Seung-Hong เป็นโปรแกรมเมอร์ที่เก่ง แต่ขาดประสบการณ์ ซึ่งลักษณะทั้งสองแสดงให้เห็นในตัวโค้ด) ผมพบว่าโค้ดของคาร์ลดีกว่า ดูเป็นมืออาชีพและแน่นหนา แต่โปรแกรมของเขายังขาดความสามารถที่สำคัญและค่อนข้างทำยาก ที่มีใน fetchpop (ซึ่งบางอย่างเป็นฝีมือของผม)

จะเปลี่ยนไหม? ถ้าผมเลือกจะเปลี่ยน ผมต้องทิ้งสิ่งที่ผมสร้างขึ้นมา เพื่อแลกกับโปรแกรมใหม่อันเป็นฐานการพัฒนาที่ดีกว่า

แรงจูงใจในทางปฏิบัติที่จะเปลี่ยน คือการได้ความสามารถในการสนับสนุนหลายโพรโทคอล โพรโทคอล POP3 เป็นโพรโทคอลที่ใช้กันมากในเครื่องแม่ข่ายตู้ไปรษณีย์เมล แต่ก็ไม่ใช่โพรโทคอลเดียว fetchpop และโปรแกรมคู่แข่งตัวอื่นไม่สนับสนุน POP2, RPOP หรือ APOP และผมยังมีเค้าความคิดที่จะเพิ่ม IMAP (Internet Message Access Protocol) ซึ่งเป็นโพรโทคอลที่ออกแบบมาใหม่ล่าสุด และมีประสิทธิภาพมากที่สุดเข้าไปอีกด้วย เพื่อความมัน

แต่ผมมีเหตุผลทางทฤษฎีที่คิดว่าการเปลี่ยนอาจจะดีก็ได้ ซึ่งเป็นสิ่งที่ผมเรียนรู้มานานก่อนจะพบกับลินุกซ์

3. ``เตรียมพร้อมที่จะทิ้งสิ่งเดิมไป คุณได้ทิ้งแน่ ไม่ว่าจะอย่างไร'' (จาก เฟรด บรูกส์ ใน The Mythical Man-Month, บทที่ 11)

หรืออีกนัยหนึ่ง คุณมักจะไม่ได้เข้าใจปัญหาอย่างแท้จริง จนกว่าคุณจะเริ่มลงมือทำครั้งแรก พอลงมือครั้งที่สอง คุณอาจรู้มากพอจะทำสิ่งที่ถูกแล้ว ดังนั้นถ้าคุณต้องการทำให้ถูกต้องจริงๆ ก็ควรเตรียมพร้อมที่จะเริ่มต้นใหม่ [JB]

ผมบอกตัวเองว่าสิ่งที่ผมเพิ่มเข้าไปใน fetchpop เป็นความพยายามครั้งแรกของผม ดังนั้นผมจึงเปลี่ยน

หลังจากผมส่งแพตช์ชุดแรกไปให้ คาร์ล แฮร์ริส เมื่อวันที่ 25 มิถุนายน 1996 ผมพบว่าเขาเลิกสนใจ popclient ไปก่อนหน้านั้นแล้ว ตัวโค้ดดูสกปรก และมีบั๊กเล็กๆ น้อยๆ ประปราย ผมมีเรื่องที่อยากแก้หลายจุด และเราก็ตกลงกันได้อย่างรวดเร็ว ว่าสิ่งที่สมเหตุสมผลที่สุดคือผมควรจะรับโปรแกรมนี้ไปดูแลต่อ

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

ในวัฒนธรรมซอฟต์แวร์ที่เน้นการแบ่งปันโค้ด นี่เป็นวิถีทางตามธรรมชาติที่โครงการต่างๆ จะก้าวหน้าต่อไป ผมกำลังทำตามหลักการนี้:

4. ถ้าคุณมีทัศนคติที่เหมาะสม ปัญหาที่น่าสนใจจะมาหาคุณเอง

แต่ทัศนคติของ คาร์ล แฮร์ริส นั้นสำคัญยิ่งกว่า เขาเข้าใจดีว่า

5. เมื่อคุณหมดความสนใจในโปรแกรมใดแล้ว หน้าที่สุดท้ายของคุณคือ ส่งมันต่อให้กับผู้สืบทอดที่มีความสามารถ

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