การปล่อยซอฟต์แวร์โอเพ่นซอร์สเร็วเกินไป [ปิด]

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

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

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

นี่เป็นความกลัวที่ไม่มีมูลความจริงไหม?

ฉันเชื่อว่าคุณควรปล่อยซอฟต์แวร์โอเพ่นซอร์สโดยเร็วที่สุด ไม่มี "เร็วเกินไป" สำหรับสิ่งนั้น (แต่ควรรวบรวม)

^{หรืออย่างน้อยก็เผยแพร่ซอร์สโค้ดอย่างเร็วและต่อเนื่อง (เช่นการกดgitubบ่อยครั้ง) โดยไม่ทำการเผยแพร่อย่างเป็นทางการ}

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

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

^{ดังนั้นคุณต้องทำให้งานประจำวันของคุณปรากฏบนซอฟต์แวร์ฟรีของคุณ! ผู้มีส่วนร่วมภายนอกจะโกรธเมื่อแพทช์ของพวกเขาไม่ทำงานหรือเป็นรหัสต้นฉบับของซอฟต์แวร์ล่าสุดของคุณซ้ำ}

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

TL; DR:

ปล่อยก่อน ปล่อยบ่อย

เรื่องเล็ก ๆ น้อยส่วนบุคคล:

ฉันตื่นเต้นมากเกี่ยวกับโครงการที่ฉันกำลังทำอยู่ ชอบตื่นเต้นจริงๆ ฉันนอนไม่หลับตอนกลางคืนตื่นเต้น ดังนั้นฉันเลยผลัก co-dev ไปปล่อย v1.0 เร็วกว่าที่เขาต้องการ

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

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

มันอาจไปทางอื่นอย่างง่ายดายเช่นกัน เราอาจเพิกเฉยต่อรายงานข้อผิดพลาดเหล่านั้น หรือเราอาจไม่ตอบสนองอย่างรวดเร็ว มันอาจจะเป็นเรื่องที่แตกต่างถ้าเราใช้เวลา 3 เดือนในการปล่อย v1.1 แทนที่จะใช้เวลาสองสามสัปดาห์

มันเหมือนกับซอฟต์แวร์โอเพ่นซอร์ส การสื่อสารเป็นสิ่งสำคัญ

แจ้งผู้ใช้ว่าสถานะของซอฟต์แวร์คืออะไรและทำไมจึงมีให้ดาวน์โหลด

ซอฟต์แวร์จะนำไปสู่ปัญหาของลูกค้าเสมอไม่ว่าจะผ่านการทดสอบอย่างเต็มที่หรือไม่ก็ตาม ลูกค้าส่วนใหญ่ยอมรับความจริงนั้นและลูกค้าบางคนไม่เคยทำ แต่หากซอฟต์แวร์จะนำไปสู่ปัญหามากกว่าที่คาดการณ์ไว้อย่างสมเหตุสมผลมีข้อผูกมัดทางศีลธรรมในการแจ้งความเสี่ยงแก่ลูกค้า ข้อมูลควรอยู่ในรูปแบบย่อ (ป้ายกำกับ "Alpha / Beta / EarlyAccess") * และรายละเอียด: รายการปัญหาที่ทราบวิธีแก้ไขและข้อควรพิจารณาพิเศษเช่นหากเป็นไปได้ว่าข้อมูลอาจเสียหายได้

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

ไม่มีความรับผิดชอบทางศีลธรรม แต่อย่างใด ไม่มีใครถูกบังคับให้ใช้งานซอฟต์แวร์ที่ผ่านการอบมาแล้วของคุณ

สิ่งเดียวที่ต้องกังวลคือความน่าเชื่อถือของคุณ

ประสบการณ์ของฉันคือมีความสมดุลที่จะประสบความสำเร็จ

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

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

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

สำหรับจุดสุดท้ายฉันคิดในสิ่งต่าง ๆ เช่น:

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

ปัญหาประเภทนี้ทำให้เกิดภาพลักษณ์ของ "vaporware" ที่อาจสั่นได้ยากเว้นแต่คุณจะเปิดกว้างเกี่ยวกับการไม่มีรหัสการทำงานที่จะเริ่มต้น

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

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

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

บทความ " 4 Shifty Details เกี่ยวกับ 'Open Source' .NET ของ Microsoftโดย Liu Qihao & Ciaran O'Riordan กล่าวถึงความเป็นไปได้ในการตีความสัญญาสิทธิบัตร Microsoft สำหรับ. NET Library และ Runtime Componentsเพื่อแยกการใช้ CLR ที่ไม่สมบูรณ์ในลักษณะเดียวกัน . แต่สิ่งนี้ไม่ได้ใช้กับแอพพลิเคชั่นที่ทำงานใน CLR