INFORWARRIOR

ผู้เขียน : INFORWARRIOR

อัพเดท: 09 ม.ค. 2009 01.06 น. บทความนี้มีผู้ชม: 238205 ครั้ง

The The Cathedral and The Bazzar หรือในชื่อภาษาไทยว่า "มหาวิหารกับตลาดสด" คือหนึ่งในบทความที่ได้สร้างแรงบันดาลใจให้กับชุมชนนักพัฒนา
ซอฟต์แวร์โอเพ่นซอร์ส และมักจะกล่าวกันว่า นี่คือบทความที่ "ต้องอ่าน" สำหรับทุกคนที่สนใจโลกของโอเพ่นซอร์สอย่างแท้จริง


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

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


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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

3. “จงเตรียมพร้อมที่จะละทิ้งสิ่งเดิมไป เพราะไม่ว่าจะอย่างไร คุณก็ต้องทำมันอยู่ดี” (จาก The Mythical Man-Month,บทที่ 11 โดย Fred Brooks)

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

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

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

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


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

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


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

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



บทความนี้เกิดจากการเขียนและส่งขึ้นมาสู่ระบบแบบอัตโนมัติ สมาคมฯไม่รับผิดชอบต่อบทความหรือข้อความใดๆ ทั้งสิ้น เพราะไม่สามารถระบุได้ว่าเป็นความจริงหรือไม่ ผู้อ่านจึงควรใช้วิจารณญาณในการกลั่นกรอง และหากท่านพบเห็นข้อความใดที่ขัดต่อกฎหมายและศีลธรรม หรือทำให้เกิดความเสียหาย หรือละเมิดสิทธิใดๆ กรุณาแจ้งมาที่ ht.ro.apt@ecivres-bew เพื่อทีมงานจะได้ดำเนินการลบออกจากระบบในทันที