บทความ มหาวิหารและตลาดสด ฉบับดั้งเดิมของปี 1997 จบลงด้วยภาพข้างต้น คือภาพที่หมู่โปรแกรมเมอร์อนาธิปัตย์ที่ทำงานกันเป็นเครือข่ายอย่างมีความสุข เอาชนะและท่วมทับโลกแห่งลำดับชั้นการบริหารของซอฟต์แวร์ปิดแบบเก่า

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

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

มีประเด็นสำคัญอยู่ในข้อโต้แย้งนี้แน่นอน และอันที่จริง ผมได้สร้างแนวคิดที่คาดหวังว่า คุณค่าของการบริการในอนาคต จะเป็นกุญแจสำคัญของเศรษฐศาสตร์การผลิตซอฟต์แวร์ อยู่ในบทความ The Magic Cauldron

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

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

ไม่ว่ามันจะเป็นอะไร แต่ไม่ใช่การดำเนินการที่รับประกันได้ในเรื่องกำหนดการ การใช้งบประมาณ หรือการทำได้ครบตามข้อกำหนดแน่ๆ หายากมากที่จะมีโครงการที่ `มีการจัดการ' ที่สามารถบรรลุเป้าหมายใดเป้าหมายหนึ่งได้ โดยไม่ต้องพูดถึงการบรรลุครบทั้งสามเป้าหมายเลย และดูจะไม่ใช่ความสามารถในการปรับตัวตามการเปลี่ยนแปลงของเทคโนโลยี และบริบททางเศรษฐกิจในช่วงชีวิตของโครงการเช่นกัน ชุมชนโอเพนซอร์สได้พิสูจน์ให้เห็นถึงประสิทธิผลที่มากกว่า มาก ในแง่ดังกล่าว (เช่น ดังที่ใครก็สามารถตรวจสอบได้ โดยเปรียบเทียบประวัติศาสตร์ 30 ปีของอินเทอร์เน็ต กับครึ่งชีวิตที่สั้นๆ ของเทคโนโลยีเครือข่ายที่สงวนสิทธิ์ หรือเปรียบเทียบค่าโสหุ้ยของการย้ายจาก 16 บิต ไป 32 บิต ในไมโครซอฟท์วินโดวส์ กับการเปลี่ยนรุ่นของลินุกซ์ที่แทบไม่ต้องใช้ความพยายามเลยในช่วงเดียวกัน ไม่ใช่แค่ตามสายการพัฒนาของอินเทลเท่านั้น แต่รวมถึงการย้ายไปยังฮาร์ดแวร์ชนิดอื่นกว่า 12 ชนิด รวมถึงชิปแอลฟา 64 บิตด้วย)

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

ฉะนั้นแล้ว อะไรคือสิ่งที่จะได้จากการจ่ายค่าโสหุ้ยของการบริหารดังกล่าว?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

กลายเป็นว่า ผลที่สำคัญที่สุดอย่างหนึ่งของความสำเร็จของโอเพนซอร์ส ก็คือการสอนเรา ว่าการเล่นเป็นวิธีที่มีประสิทธิภาพทางเศรษฐกิจที่สุดสำหรับงานสร้างสรรค์