ซอฟต์แวร์โอเพนซอร์สหมายถึงอะไร? เมื่อคุณต้องอธิบายให้ผู้อื่นเข้าใจ จะสื่อสารคุณค่าและสาระสำคัญของโอเพนซอร์สได้อย่างไร? ตั้งแต่คำว่าโอเพนซอร์สถูกเสนอครั้งแรกในปี 1997 อุตสาหกรรมได้เรียนรู้บทเรียนที่ได้มาอย่างยากลำบากมากมาย เราไม่ควรลืมบทเรียนเหล่านี้
ด้วยเหตุนี้ ฉันจึงรวบรวม 12 ยีนวัฒนธรรม ซึ่งในความเห็นของฉันจะช่วยแบ่งปันประวัติศาสตร์ สร้างเวที และให้บริบทสำหรับนิยามของโอเพนซอร์สและความหมายที่มีต่ออุตสาหกรรมซอฟต์แวร์ทั้งหมด
ยีนวัฒนธรรมแรกๆ เกี่ยวข้องกับการสร้างซอฟต์แวร์ ฉันเชื่อว่าพวกมันกำหนดสิ่งที่เราถือว่าเป็นโครงการโอเพนซอร์สที่ประสบความสำเร็จ เพราะพวกมันเป็นแง่มุมพื้นฐานที่เกี่ยวข้องกับตัวซอฟต์แวร์เอง โครงการที่เข้าใจยีนวัฒนธรรมเหล่านี้จะประสบความสำเร็จ ซอฟต์แวร์ที่ใช้สัญญาอนุญาตแบบเปิดกว้างและเน้นชุมชนอาจเป็นกลไกการนำซอฟต์แวร์กลับมาใช้ใหม่ที่ยอดเยี่ยมและมีประสิทธิภาพสูงสุดที่เราใช้ในการสร้างและดูแลรักษาซอฟต์แวร์ที่ดี
ยีนวัฒนธรรมแรก: เราแบ่งปันซอฟต์แวร์ตั้งแต่เริ่มเขียนซอฟต์แวร์
ในช่วงปลายทศวรรษ 1950 IBM ได้จัดการประชุมคอมพิวเตอร์ซึ่งดำเนินต่อเนื่องมาจนถึงทุกวันนี้ ชื่อว่า SHARE DEC เริ่มต้นในทศวรรษ 1960 สนับสนุนชุมชน DECUS ซึ่งคุณสามารถซื้อเทปที่เต็มไปด้วยซอฟต์แวร์ที่ผู้อื่นเขียนและมอบให้ในการประชุม USENIX เริ่มต้นในทศวรรษ 1970 ในช่วงเวลาที่ใช้เทปเผยแพร่เวอร์ชันแรกๆ ของ UNIX แต่การปฏิบัติการแบ่งปันนี้สามารถย้อนไปถึงงานพัฒนาบนคอมพิวเตอร์ที่ตั้งโปรแกรมได้เครื่องแรกที่ Institute for Advanced Study ใน Princeton ในทศวรรษ 1940
ยีนวัฒนธรรมที่สอง: การเขียนซอฟต์แวร์ที่ดีเป็นงานที่หนัก
ฉันเชื่อว่าการแบ่งปันลดลงเหลือความเป็นจริงง่ายๆ นี้: การเขียนซอฟต์แวร์ที่ดีเป็นเรื่องยาก ในด้านการพัฒนาซอฟต์แวร์มีอัตราสองประการ: จำนวนบรรทัดโค้ดที่นักพัฒนาสามารถเขียนได้โดยเฉลี่ยในหนึ่งวัน และจำนวนข้อผิดพลาดต่อพันบรรทัดโค้ดที่ผ่านกระบวนการพัฒนาที่สมเหตุสมผล ความก้าวหน้าทั้งหมดในด้านซอฟต์แวร์ตั้งแต่วิวัฒนาการของภาษาไปจนถึงสถาปัตยกรรมการนำกลับมาใช้ใหม่ หมุนรอบแนวคิดหลักนี้: เขียนซอฟต์แวร์ที่ดีขึ้นมากขึ้นด้วยโค้ดน้อยลง ความก้าวหน้าในด้านความน่าเชื่อถือของการสร้างซอฟต์แวร์ การจัดการการกำหนดค่า เครื่องมือและกระบวนการตรวจสอบ และการทดสอบ มีจุดประสงค์เพื่อลดจำนวนข้อผิดพลาดที่ผ่านกระบวนการส่งมอบซอฟต์แวร์ที่สมเหตุสมผล
ยีนวัฒนธรรมที่สาม: ไม่มีการขยายขนาดโดยไร้ระเบียบ
การเขียนซอฟต์แวร์ที่ดีต้องมีระเบียบ หากคุณดูซอฟต์แวร์ที่เป็นผลิตภัณฑ์ที่ประสบความสำเร็จหรือโครงการโอเพนซอร์ส มักจะถูกสร้างขึ้นโดยมีการตรวจสอบโดยเพื่อน ใช้การควบคุมเวอร์ชันและการจัดการการกำหนดค่า มีระบบอัตโนมัติในการสร้างและกรอบการทดสอบที่พัฒนาขึ้นพร้อมกับซอฟต์แวร์ หากไม่มีการตรวจสอบ การจัดการการกำหนดค่า และระบบอัตโนมัติในการสร้างและทดสอบ ซอฟต์แวร์จะไม่สามารถขยายในชุมชนผู้ใช้ และไม่สามารถขยายเป็นผลิตภัณฑ์ให้ผู้ใช้นับหมื่นคน กลุ่มแกนกลางที่ต้องดูแลซอฟต์แวร์ต้องสามารถตอบคำถามว่า “ซอฟต์แวร์ทำอะไร”
กฎของ Linus สามารถกล่าวโดยทั่วไปว่า “ด้วยความสนใจเพียงพอ ข้อผิดพลาดในโค้ดทั้งหมดจะปรากฏขึ้น” ฉันคิดว่านี่แสดงให้เห็นความสำคัญของกระบวนการตรวจสอบการส่ง การวิจัยแสดงว่าข้อผิดพลาดที่พบในขั้นตอนการตรวจสอบมากกว่าที่พบในขั้นตอนการทดสอบ ชุมชนที่แข็งแรงจะต้องมีกระบวนการตรวจสอบที่เข้มงวดในการเช็คอินโค้ด
ยีนวัฒนธรรมที่สี่: ซอฟต์แวร์มีลักษณะแบบไดนามิกโดยธรรมชาติ
โปรแกรมพัฒนาไปพร้อมกับการใช้งาน ข้อผิดพลาดถูกค้นพบแล้วแก้ไข พบการใช้งานใหม่ ซึ่งขับเคลื่อนฟีเจอร์ใหม่ โปรแกรมได้รับการขัดเกลาและเสริมความแข็งแกร่งอย่างต่อเนื่อง โปรแกรมถูกย้ายจากสภาพแวดล้อมหนึ่งไปยังอีกสภาพแวดล้อมหนึ่ง น่าเสียดายที่ลิขสิทธิ์กลายเป็นกลไกในการ “ปกป้อง” ไปป์ไลน์การเผยแพร่ซอฟต์แวร์ในปี 1980 ผู้คนอาจไม่เข้าใจว่าซอฟต์แวร์พัฒนาเร็วแค่ไหน การพัฒนาเวอร์ชันลอกเลียนแบบเร็วแค่ไหน หรืออาจไม่เข้าใจว่าหลังจาก IoT และเวิลด์ไวด์เว็บเกิดขึ้น ความเป็นไดนามิกนี้จะเร่งขึ้นเท่านั้น เราแบ่งปันแบนด์วิดท์เครือข่ายจากขนาดเทป ตารางกำหนดการประชุม และความล่าช้าในการตีพิมพ์นิตยสาร ไปสู่การสร้าง ปล่อย และดูแลรักษาแบบเรียลไทม์ทั่วโลกตลอด 24 ชั่วโมง
ลองดูยีนวัฒนธรรมบางอย่างที่เกี่ยวข้องกับด้านชุมชนของซอฟต์แวร์โอเพนซอร์ส
ยีนวัฒนธรรมที่ห้า: คุณมักจะได้รับมากกว่าที่ให้
นี่คือประสิทธิภาพทางเศรษฐกิจของการพัฒนาแบบร่วมมือในชุมชน การมอบสิ่งต่างๆ อย่างต่อเนื่องถือเป็นเส้นชีวิตของการพัฒนาซอฟต์แวร์โครงการ ผู้มอบสิทธิ์มอบโค้ดหรือให้เวอร์ชันแก้ไขโดยไม่มีความเสี่ยงมาก แต่ได้รับประโยชน์คือซอฟต์แวร์ทั้งหมดสามารถใช้ได้ตามที่ผู้มอบสิทธิ์เห็นสมควร สำหรับการมอบสิทธิ์แบบผ่านทาง นี่อาจเป็นการมอบสิทธิ์สำคัญเพียงอย่างเดียวที่นักพัฒนามอบให้ ไม่ว่าประสบการณ์และความเชี่ยวชาญของพวกเขาจะเป็นอย่างไร
การได้รับคืนมากกว่าที่มอบให้ใช้ได้ทั้งกับบุคคลและบริษัท ทรัพยากรและการลงทุนเฉพาะจากบริษัทใหญ่บางแห่งเช่น Red Hat, Intel และ IBM ทำให้พวกเขาสามารถใช้ระบบปฏิบัติการ Linux ทั้งหมดเพื่อดำเนินกลยุทธ์ทางธุรกิจที่แตกต่าง บริษัทสามารถเปลี่ยนโครงการซอฟต์แวร์ที่ดีให้เป็นผลิตภัณฑ์ที่แก้ปัญหาของลูกค้า
ยีนวัฒนธรรมที่หก: การมีคนกินฟรีเป็นกุญแจสู่ความสำเร็จ
มีข่าวลือว่าในทุกๆ 1,000 ผู้ใช้ในโครงการโอเพนซอร์สหนึ่ง 100 คนอาจรายงานข้อผิดพลาดของซอฟต์แวร์ ในจำนวนนั้น 10 คนมอบเวอร์ชันแก้ไขที่เป็นไปได้ และในจำนวนนั้นเพียง 1 คนอ่านแนวทางการมอบสิทธิ์อย่างละเอียด ในความเป็นจริง ชุมชนมีสามเส้นทางสู่ความสำเร็จ (ความสำเร็จของชุมชนวัดจากการมอบสิทธิ์โค้ด) หนึ่งคือซอฟต์แวร์ต้องติดตั้งและใช้งานง่ายอย่างยิ่ง เพื่อให้โครงการได้รับผู้ใช้จำนวนมาก สองคือในกลุ่มผู้ใช้จะต้องมีนักพัฒนา ซอฟต์แวร์ต้องสร้างและทดสอบได้ง่ายอย่างยิ่ง เพื่อให้นักพัฒนาที่ต้องการเปลี่ยนแปลง (เพื่อผลประโยชน์ส่วนตัว) สามารถเปลี่ยนแปลงได้ง่าย สามคือต้องสามารถมอบการเปลี่ยนแปลงกลับไปยังโครงการได้ง่ายอย่างยิ่ง เพื่อให้การมอบสิทธิ์ไหลเข้ามาอย่างต่อเนื่อง การมีคนกินฟรีจำนวนมากหมายความว่าคุณทำได้ดี ดังนั้นหากมีผู้ใช้จำนวนมาก จะมีศักยภาพมากสำหรับนักพัฒนา และความเป็นไปได้ในการมอบสิทธิ์จะตามมา แต่ความรับผิดชอบของโครงการคือต้องทำให้สิ่งต่างๆ ง่าย
บริษัทที่พยายามสร้างโครงการโอเพนซอร์สมักเข้าใจชุมชนได้ยาก พวกเขาคิดว่ามีคนต้องมอบสิ่งต่างๆ ให้พวกเขา พวกเขาคุ้นเคยกับการสั่งการชุมชน (เช่นเว็บไซต์นักพัฒนา) แทนที่จะร่วมมือ มีสามยีนวัฒนธรรมที่ใช้กับบริษัทและโอเพนซอร์ส
ยีนวัฒนธรรมที่เจ็ด: ไม่สับสนระหว่างผลิตภัณฑ์และโครงการ
โครงการคือชุดซอฟต์แวร์ที่ใช้งานได้จริงซึ่งสามารถติดตั้งและรันเพื่อแก้ปัญหาบางอย่าง เป็นการทำงานร่วมกันและการสื่อสารที่พูดด้วยโค้ด คุณต้องเข้าใจว่าโครงการไม่ใช่ผลิตภัณฑ์ ผลิตภัณฑ์คือสิ่งที่ทำกำไรจากการแก้ปัญหาของลูกค้า แม้ซอฟต์แวร์ที่ยอดเยี่ยมมากมายมาจากโครงการโอเพนซอร์สที่ทำงานได้ดีและลดงานวิศวกรรมบางส่วน แต่ยังมีงานหนักที่ต้องทำเพื่อเปลี่ยนมันเป็นผลิตภัณฑ์ที่แก้ปัญหาให้ลูกค้า เช่น Linux kernel เป็นโครงการ Fedora เป็นโครงการดิสทริบิวชัน แต่ RHEL เป็นผลิตภัณฑ์ ผลิตภัณฑ์ทำกำไรจากการตอบสนองความคาดหวังด้านคุณค่าของลูกค้า ผลิตภัณฑ์สามารถติดตั้งและรันโดยค่าเริ่มต้น มีการรับประกันและการชดเชย และมีบริการ (การสนับสนุน การอัปเกรด การฝึกอบรม และการให้คำปรึกษา) รวมถึงเอกสารสำหรับผลิตภัณฑ์เฉพาะ พวกมันอาจเป็นส่วนหนึ่งของพอร์ตโฟลิโอผลิตภัณฑ์ที่ใหญ่กว่าซึ่งรวมถึงฮาร์ดแวร์และบริการ
ข้อสรุปหนึ่งของยีนวัฒนธรรมนี้อาจเป็น: “ไม่มีใครมาสร้างผลิตภัณฑ์ให้คุณ”
ยีนวัฒนธรรมที่แปด: ไม่สับสนระหว่างลูกค้าและชุมชน
หากยีนวัฒนธรรมที่เจ็ดเกี่ยวข้องกับวิศวกรรมและโมเดลธุรกิจ ยีนวัฒนธรรมที่แปดก็เกี่ยวข้องกับข้อความและการขาย ชุมชนและลูกค้ามีคุณค่าที่แตกต่างกัน ลูกค้าจ่ายเงินเพื่อเร่งแก้ปัญหาและลดความเสี่ยง ในขณะที่ชุมชน (และบุคคลในชุมชน) สร้างโซลูชันของตนเองผ่านความร่วมมือ บริษัทบางแห่งที่ใช้ซอฟต์แวร์โอเพนซอร์สคิดว่าชุมชนโครงการเป็นส่วนหนึ่งของไปป์ไลน์ผลิตภัณฑ์ พวกเขาคิดแบบนั้นมากขึ้นเมื่อพบลูกค้าในฟอรัมชุมชน พวกเขาอาจคิดด้วยซ้ำว่าโครงการชุมชนเป็นสิ่งที่ลองก่อนซื้อ แต่ทั้งหมดนี้ผิด
บริษัทสื่อสารกับชุมชนที่เกี่ยวข้องแตกต่างจากที่สื่อสารกับลูกค้าที่จ่ายเงิน การสื่อสารแต่ละครั้งมีเครื่องมือและกฎการมีส่วนร่วมเฉพาะ รวมถึงตัวชี้วัดที่ต้องบันทึกและพิจารณา สมาชิกชุมชนมีคุณค่ามาก แต่พวกเขาไม่ใช่ลูกค้า
ยีนวัฒนธรรมที่เก้า: บริษัทแบ่งปันซอฟต์แวร์ที่มีสัญญาอนุญาตแบบเปิดกว้างมานานก่อนนิยามโอเพนซอร์ส
Project Athena (X11, Kerberos) เริ่มต้นในปี 1983 Open Software Foundation (OSF/Motif, OSF/1) เริ่มต้นในปี 1988 DEC และ Sun พัฒนา Ultrix และ SunOS จากเวอร์ชัน BSD แรกๆ ตามลำดับ นี่ไม่ใช่พฤติกรรมใหม่
สุดท้าย ยีนวัฒนธรรมบางอย่างเกี่ยวข้องกับการอภิปรายด้านสัญญาอนุญาตและกฎหมายเกี่ยวกับซอฟต์แวร์โอเพนซอร์ส
ยีนวัฒนธรรมที่สิบ: เสรีภาพซอฟต์แวร์และสัญญาอนุญาตโอเพนซอร์สเป็นหัวข้ออภิปรายที่แตกต่างกัน
การโต้วาทีเรื่องเสรีภาพซอฟต์แวร์กับซอฟต์แวร์โอเพนซอร์สเหมือนกับการโต้วาทีว่าประชาธิปไตยดีกว่าทุนนิยมหรือไม่ หรือโต้วาทีว่าเสรีภาพในการพูดสำคัญกว่าตลาดเสรีหรือไม่ ทั้งสองเป็นการอภิปรายที่สำคัญในตัวเอง ผู้คนมักมีความโน้มเอียงตามธรรมชาติต่อหัวข้อใดหัวข้อหนึ่ง แต่เป็นการอภิปรายที่แตกต่างกัน ภาษาเสรีภาพซอฟต์แวร์ถูกกำหนดโดยสิทธิผู้ใช้ ในขณะที่ภาษาซอฟต์แวร์โอเพนซอร์สถูกกำหนดโดยคุณลักษณะของสัญญาอนุญาต นี่เป็นการอภิปรายที่แตกต่างกัน
ยีนวัฒนธรรมที่สิบเอ็ด: ทุกโครงการโอเพนซอร์สต้องการสัญญาอนุญาต
สัญญาอนุญาตกำหนดว่าผู้อื่นสามารถใช้ซอฟต์แวร์ได้อย่างไร ซอฟต์แวร์ได้รับความคุ้มครองภายใต้กฎหมายลิขสิทธิ์ ต้องเลือกสัญญาอนุญาตที่ได้รับการอนุมัติจาก OSI สัญญาอนุญาตที่คุณเลือกประกาศสัญญาทางสังคมที่คุณต้องการในชุมชน แม้ในปีที่ผ่านมาหลายคนเลือก Apache Software License เป็นค่าเริ่มต้นว่าเป็นสัญญาอนุญาตที่ “เป็นมิตรกับธุรกิจ” แต่อาจไม่จำเป็นต้องเป็นเช่นนั้น สัญญาอนุญาตแบบตอบแทนหรือสัญญาอนุญาตแบบอิสระไม่ใช่การพูดถึงซอฟต์แวร์เสรีหรือซอฟต์แวร์โอเพนซอร์ส สัญญาอนุญาตแบบตอบแทนอาจเป็นสัญญาอนุญาตที่เป็นมิตรกับระบบนิเวศมากที่สุด
ยีนวัฒนธรรมที่สิบสอง: มูลนิธิมีที่ทาง
องค์กรไม่แสวงหากำไรสามารถให้สนามแข่งขันที่เท่าเทียมและความเป็นกลางด้านความเป็นเจ้าของทรัพย์สินทางปัญญา ทำให้บริษัทสามารถมุ่งเน้นโครงการโอเพนซอร์สที่ดำเนินการได้ดีโดยเฉพาะ
บทสรุป
ในช่วงกลางถึงปลายทศวรรษ 1990 เพื่อนร่วมงานและฉันใช้ซอฟต์แวร์ที่มีสัญญาอนุญาตแบบเปิดกว้างเปิดบริษัทซอฟต์แวร์ ในเวลานั้นคำว่าโอเพนซอร์สยังไม่ปรากฏ ไม่มีความลึกลับมากนัก เรารวบรวมและย้ายแพ็กเกจประมาณ 250 แพ็กเกจที่มีสัญญาอนุญาต 25 แบบที่แตกต่างกัน (รวมถึง Berkeley License, MIT License และ GPLv2) และรวมกับซอฟต์แวร์ของเราเอง รวมถึงซอฟต์แวร์สำคัญบางส่วนที่ Microsoft เป็นเจ้าของ ซึ่งสัญญาอนุญาตอนุญาตให้เราใช้ เราพัฒนามันเป็นผลิตภัณฑ์ที่บริษัทของเราสนับสนุนอย่างเต็มที่ โดยใช้สัญญาอนุญาตของผลิตภัณฑ์เราเอง เรามีส่วนร่วมในชุมชนที่ทำงานร่วมกันเหล่านั้นในรูปแบบต่างๆ ในฐานะกลุ่มวิศวกรและนักธุรกิจ เราสามารถเติบโตในชุมชนระบบ UNIX ได้ ด้วยประวัติศาสตร์อันยาวนานของความร่วมมือและการแบ่งปัน
มองย้อนกลับไปที่ยีนวัฒนธรรมเหล่านี้ ฉันคิดว่าพวกมันเหมือนกับที่ฉันจะเขียนไว้เมื่อ 20 ปีก่อนทุกประการ
คุณจะเพิ่มยีนวัฒนธรรมแบบไหน? คุณมีประสบการณ์แบบไหน? ยินดีรับฟังความคิดเห็น
โปรดระบุแหล่งที่มา: ความสัมพันธ์นักพัฒนา »
