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

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

โปรเจกต์นี้เริ่มต้นด้วยส่วนผสมที่เหมาะสมทั้งหมดสำหรับความสำเร็จ นักพัฒนาได้เตรียม README ที่ขัดเกลา แนวทางการมีส่วนร่วม เอกสารความปลอดภัย และเว็บไซต์สาธิตอย่างระมัดระวัง หลังจากเปิดตัวในชุมชน Reddit เช่น r/selfhosted โปรเจกต์ได้รับความนิยมอย่างรวดเร็ว เมื่อจดหมายข่าว self-hosting นำเสนอโปรเจกต์นี้ ทำให้ repository ได้รับ 100 ดาวและดึงดูดผู้ใช้องค์กรจริง

เมตริกการวัดความสำเร็จของโครงการ:

• Repository ได้รับ 100 ดาวใน GitHub หลังจากเปิดตัวฟีเจอร์จดหมายข่าว
• ดึงดูดผู้ใช้ทั้งในกลุ่ม home server และองค์กรขนาดใหญ่
• ได้รับความสนใจจากผู้สร้างคอนเทนต์ในวงการ self-hosting
• มีฐานผู้ใช้ที่ใช้งานอย่างต่อเนื่องและต้องการการสนับสนุนโดยตรง

ต้นทุนที่ซ่อนอยู่ของความสำเร็จในโอเพนซอร์ส

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

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

ความรับผิดชอบของผู้ดูแลที่นำไปสู่ความเหนื่อยหน่าย:

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

กลยุทธ์ชุมชนสำหรับการพัฒนาที่ยั่งยืน

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

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

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

แนวทางแก้ไขที่ชุมชนแนะนำ:

• เปิดตัวโปรเจกต์ในรูปแบบ "ของขวัญ" โดยไม่มีคำมั่นสัญญาเรื่องการสนับสนุน
• ปิดการใช้งาน issue trackers และ pull requests
• กำหนดขอบเขตที่ชัดเจนเกี่ยวกับความคาดหวังในการดูแลรักษา
• ใช้การสื่อสารแบบ "โปรเจกต์เป็นสวน"
• อนุญาตให้ชุมชน fork เพื่อพัฒนาต่อ
• บล็อกหรือเพิกเฉยต่อผู้ใช้ที่เรียกร้องมากเกินไป

การตรวจสอบความเป็นจริงสำหรับผู้ดูแลที่มีแรงบันดาลใจ

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

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

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

อ้างอิง: For years I've always wanted to be an open-source maintainer