มีหลายวิธีที่จะทำลายโปรเจกต์โอเพนซอร์ส และมีหลายจุดที่ต้องตำหนิ ผู้รับผิดชอบคนหนึ่งของ GitHub เชื่อว่าทั้งผู้ดูแลโปรเจกต์และผู้ใช้ควรถูกตำหนิ
ในรายงานเตือนใจเมื่อเร็วๆ นี้ในหัวข้อ “99 วิธีที่จะทำลายโปรเจกต์โอเพนซอร์ส” Brandon Keepers ผู้จัดการโปรเจกต์โอเพนซอร์สของ GitHub ได้ยกตัวอย่างวิธีมากมายที่โปรเจกต์โอเพนซอร์สล้มเหลวเพราะผู้ใช้หรือผู้ดูแลทำผิดพลาด Keepers ได้นำเสนอรายงานนั้นที่งาน O’Reilly Open Source Convention (OSCON) ในพอร์ตแลนด์ รัฐออริกอน เขายกตัวอย่าง N วิธีที่จะทำลายโปรเจกต์โอเพนซอร์ส
Keepers กล่าวว่า ผู้เข้าร่วมโปรเจกต์อาจทำสิ่งต่างๆ เช่น หลีกเลี่ยงการให้ข้อเสนอแนะเชิงสร้างสรรค์ ซึ่งทำให้ผู้ดูแลขาดแรงจูงใจ “เราไม่รายงานข้อผิดพลาด เราเจอปัญหาแล้วบอกว่า ‘นี่ต้องเป็นปัญหาของฉัน… คนอื่นจะรายงานปัญหานี้’”
ผู้เข้าร่วมยังอาจขี้เกียจ ถามคำถามโดยไม่ได้คิดให้ดี หรือไม่อ่านเอกสารอย่างละเอียด Keeper กล่าวว่า ถ้าอย่างนั้น ถ้าผู้ดูแลไม่ตอบคำถามของผู้ใช้เร็วพอ ผู้ใช้ก็จะโกรธพวกเขา “เราลืมไปว่า ผู้ดูแลทำงานนี้โดยสมัครใจในเวลาว่าง”
Keepers กล่าวว่า ในทางกลับกัน สำหรับผู้ดูแลโปรเจกต์ พวกเขาอาจทำให้ผู้ใช้ยากที่จะ “เข้าใจว่าโปรเจกต์นี้มีไว้ทำอะไร” ซึ่งจะทำลายความมั่นใจของผู้ใช้ พวกเขาอาจทำให้ผู้ใช้ยากที่จะเริ่มต้น “ง่ายที่สุดคือเราไม่บอกผู้ใช้ว่าจะใช้มันอย่างไร” ตรงกันข้าม ผู้ดูแลอาจคิดว่าผู้ใช้ที่เก่งที่สุดควรเข้าใจเองได้ ผู้ดูแลยังอาจทำให้โปรเจกต์ปรับแต่งไม่ได้ หรือต้องการการปรับแต่งมากเกินไป
การปล่อยเวอร์ชันที่ไม่น่าเชื่อถือและหลีกเลี่ยงการเผยแพร่แผนที่เทคโนโลยีของเวอร์ชันก็ทำให้เกิดปัญหาได้ Keeper กล่าวว่า: “เป็นที่รู้จักกันดีว่า เราไม่ชอบวางแผนซอฟต์แวร์ใหม่ ใช่ไหม? จริงๆ แล้วผมคิดว่า พวกเราหลายคนเรียกมันว่าการพัฒนาแบบ agile” เขามีความเห็นเกี่ยวกับวิธีการพัฒนาแบบ agile ที่ไม่ได้วางแผนโปรเจกต์ทั้งหมดล่วงหน้า “แต่จริงๆ แล้ว ถ้าไม่มีแผนเลย จะ agile ไปทำไม?”
ปัญหาอื่นๆ รวมถึง: การเลื่อนปล่อยเวอร์ชันเพราะการแก้ไขครั้งใหญ่ การทำการเปลี่ยนแปลงที่ทำลายในเวอร์ชันรอง และไม่มีเส้นทางอัปเกรดระหว่างเวอร์ชัน การไม่กล่าวถึงข้อจำกัดที่รู้จักของโปรเจกต์ซอฟต์แวร์ก็เป็นปัญหาเช่นกัน
Keepers กล่าวว่า ถ้าผู้ดูแลใช้ภาษากฎหมายที่คลุมเครือ ไม่ใช้สัญญาอนุญาตโอเพนซอร์สที่เหมาะสม จะทำลายความสมบูรณ์ของโค้ด การละเมิดสิทธิบัตร ลิขสิทธิ์ และเครื่องหมายการค้าก็เป็นปัญหาเช่นกัน
ถ้าผู้ดูแลดึงดูดผู้ใช้ก่อนที่โปรเจกต์จะพร้อม หรือตั้งชื่อโปรเจกต์ที่ไม่พึงประสงค์หรือออกเสียงยาก จะทำลายชื่อเสียงของโปรเจกต์ Keepers กล่าวว่า “ชื่อที่หาผ่าน google ไม่เจอ” ก็เป็นปัญหาเช่นกัน เขากล่าวถึงโปรเจกต์ที่มีชื่อเสียงสองโปรเจกต์: ภาษา Rust และภาษา Go เขาเชื่อว่า แม้โปรเจกต์เหล่านี้ยอดเยี่ยม แต่หาข้อมูลเกี่ยวกับพวกมันได้ยาก Keepers กล่าวว่า การหลีกเลี่ยงการโฆษณาโปรเจกต์อย่างแข็งขันก็เป็นความผิดพลาดเช่นกัน
Keepers กล่าวว่า ถ้าใช้อำนาจควบคุมมากเกินไป ไม่สนใจความกังวลเกี่ยวกับโปรเจกต์ หรือจัดการโค้ดที่มีส่วนร่วมไม่ดี จะทำลายความไว้วางใจของชุมชนอย่างสิ้นเชิง อีกปัจจัยหนึ่งคือไม่ขอบคุณผู้มีส่วนร่วมในโค้ด
อีกปัญหาหนึ่งคือ ผู้ดูแลไม่ยับยั้งพฤติกรรมที่ไม่เหมาะสมในการอภิปรายออนไลน์ Keepers กล่าวว่า: “อินเทอร์เน็ตจริงๆ แล้วเป็นสถานที่น่ากลัว” หลายคนกีดกันผู้หญิงและชนกลุ่มน้อย เยาะเย้ยคนที่ภาษาอังกฤษไม่ใช่ภาษาแม่ ผู้มาใหม่ในโปรเจกต์มักพบว่าตัวเองเป็นเป้าหมายของการเยาะเย้ย
หมวดหมู่ส่วนใหญ่ที่ทำลายโปรเจกต์เป็นปัญหาเล็กๆ ที่ไม่เด่น เช่น การขาดข้อมูล แม้พฤติกรรมเหล่านี้ไม่รุนแรง แต่สะสมกันจะทำลายชุมชนที่สร้างขึ้นรอบโปรเจกต์ และทำให้ผู้ดูแลหมดแรง Keepers เน้นว่า ผู้ดูแลต้องเป็นแบบอย่างที่ดีสำหรับโปรเจกต์ซอฟต์แวร์
โปรดระบุแหล่งที่มา: ความสัมพันธ์นักพัฒนา »
