ผู้ดูแลโครงการโอเพนซอร์สยอดนิยมต่างมีความยากลำบาก คนแปลกหน้าที่มาขอความช่วยเหลือจะด่าคุณเพราะไม่ได้ตอบคำถามทันเวลา หรือไม่ได้ช่วยค้นหาคำตอบที่พวกเขาต้องการ ผู้ดูแลโครงการโอเพนซอร์สมักจะเก็บความเครียดไว้จนเป็นโรคทางจิต ถ้าคุณมีโครงการโอเพนซอร์ส บางทีคุณอาจเข้าใจแล้ว
Nolan Lawson เป็น PM ของแพลตฟอร์ม Web ของเบราว์เซอร์ Edge ของ Microsoft มีส่วนร่วมในโครงการโอเพนซอร์สหลายโครงการ เช่น PouchDB, optimize-js และอื่นๆ การเป็นผู้ดูแลโครงการโอเพนซอร์สเป็นอย่างไร? มาดูประสบการณ์ตรงของเขาในช่วง 7 ปีที่ผ่านมา
หลายร้อยคนต่อแถวรออยู่นอกประตูบ้านคุณ พวกเขารอคอยอย่างอดทนให้คุณตอบคำถาม รับฟังการร้องเรียน ตอบ Pull Request และ Feature Request
คุณอยากช่วยพวกเขาทุกคน แต่คุณผลัดดไปเรื่อยๆ บางทีคุณอาจทำงานหนักมาทั้งวัน หรือคุณเหนื่อยแล้ว หรือบางทีคุณแค่อยากใช้เวลากับครอบครัวและเพื่อนในวันหยุดสุดสัปดาห์
แต่ถ้าคุณเข้าสู่ github.com/notifications Notification จะเตือนคุณอย่างต่อเนื่องว่ามีกี่คนกำลังรอคุณอยู่:
screenshot showing 403 unread GitHub notifications
เมื่อคุณพยายามหาเวลาว่างสักหน่อย คุณเปิดประตูต้อนรับคนแรก (คือการจัดการกับปัญหาแรก ซึ่งอาจมีมากกว่าหนึ่งคน เช่นเดียวกันข้างล่าง) พวกเขาเป็นคนใจดี พวกเขาอยากใช้โครงการของคุณ แต่สับสนกับ API พวกเขาวางโค้ดในคอมเมนต์ GitHub แต่ลืมหรือไม่รู้วิธีฟอร์แมตโค้ด ทำให้โค้ดรกไปหมด
โชคดี คุณแก้ไขคอมเมนต์ของพวกเขาเพื่อเพิ่มบล็อกโค้ด ฟอร์แมตโค้ดให้ แต่ยังมีโค้ดจำนวนมากที่ต้องอ่าน
นอกจากนี้ คำอธิบายปัญหาของพวกเขาค่อนข้างเข้าใจยาก บางทีอังกฤษอาจไม่ใช่ภาษาแม่ของพวกเขา หรือพวกเขาไม่ถนัดในการเขียน ไม่ว่าจะด้วยเหตุผลใด คุณพยายามเข้าใจข้อความที่พวกเขาส่งมา
คุณมองด้วยความเหนื่อยล้าไปที่อีกหลายร้อยคนที่รออยู่ข้างหลัง คุณอาจใช้เวลาครึ่งชั่วโมงเพื่อเข้าใจโค้ดของคนแรกนี้ หรือคุณอาจแค่อ่านผ่านๆ แล้วให้ลิงก์ไปที่บทแนะนำหรือเอกสาร ซึ่งอาจช่วยพวกเขาแก้ปัญหาได้ คุณยังแนะนำอย่างเป็นกันเองให้พวกเขาลอง Stack Overflow หรือ Slack
คนที่สองหน้าบึ้ง แสดงความไม่พอใจ พวกเขาบ่นเรื่อยเวลาว่าโครงการของคุณเสียเวลาสองชั่วโมงของชีวิตพวกเขา เพราะ API บางตัวไม่ได้ผลตามที่โฆษณา คำพูดของเขาค่อนข้างรุนแรง ทำให้คุณรู้สึกไม่สบายใจ
คุณไม่เสียเวลากับคนนี้มาก คุณพูดง่ายๆ ว่า “นี่เป็นโครงการโอเพนซอร์ส ดูแลโดยอาสาสมัคร ถ้ามี Bug ในโค้ด โปรดส่งเทสเคสที่สามารถทำซ้ำได้หรือ PR”
คนที่สามพบข้อผิดพลาดที่พบบ่อย วิธีแก้ไขง่ายมาก คุณเคยเห็นข้อผิดพลาดนี้หลายครั้ง แต่จำวิธีแก้ไขไม่ได้ อยู่ที่ Stack Overflow? Wiki? รายชื่ออีเมล? หลังจากค้นหาใน Google สักครู่ คุณวางลิงก์แล้วปิด Issue
คนที่สี่เป็นผู้มีส่วนร่วมประจำ คุณจำชื่อพวกเขาได้จากการประชุมชุมชนหลายครั้งและโครงการพี่น้อง พวกเขาติดอยู่ใน Issue ที่ค่อนข้างซับซ้อน และส่ง Pull Request เพื่อแก้ไข น่าเสียดายที่ Issue นี้ซับซ้อน ดังนั้น PR ของพวกเขามีหลายย่อหน้าที่น่าเบื่อเพื่ออธิบายปัญหา
อีกครั้ง คุณมองไปที่อีกหลายร้อยคนที่รออยู่ คุณรู้ว่าคนที่สี่นี้ใช้เวลามากกับโซลูชันของพวกเขา และโซลูชันนี้น่าจะสมเหตุสมผล Travis เทสผ่าน ดังนั้นคุณคิดจะคอมเมนต์ว่า “LGTM” แล้ว merge Pull Request
อย่างไรก็ตาม คุณเคยถูกทำร้ายจากสถานการณ์แบบนี้มาก่อน ในอดีต คุณ merge PR โดยไม่ได้รีวิวอย่างเพียงพอ และในที่สุดมันทำให้เกิดปัญหาใหม่เพราะสิ่งที่คุณไม่ได้คาดการณ์ บางทีเทสผ่าน แต่ประสิทธิภาพลดลง 10% หรือมันทำให้เกิดหน่วยความจำรั่ว หรือบางที PR นี้ทำให้ผู้ใช้ใหม่สับสนกับโครงการ เพราะมันทำให้ API ดูซับซ้อนเกินไป
ถ้าคุณ merge PR นี้ตอนนี้ อาจมีปัญหาเพิ่มเติมในอนาคต เพราะคุณแก้ปัญหาของคนนี้โดยขัดจังหวะเวิร์กโฟลว์ของคนอื่น ดังนั้นคุณเก็บมันไว้ รอให้มีเวลามากขึ้นก่อนจะจัดการ
คนที่ห้าพบ Bug ใหม่ แต่คุณรู้ว่าจริงๆ แล้วมันเป็น Bug ในโครงการพี่น้อง พวกเขาบอกว่ามันขัดขวางการเปิด App ของพวกเขา คุณรู้ว่านี่เป็นปัญหาใหญ่ แต่เป็นเพียงหนึ่งในหลายปัญหา ดังนั้นคุณไม่มีเวลาแก้ไขตอนนี้
คุณตอบว่า นี่ดูเหมือนเป็นปัญหาจริง แต่เหมาะกับการเปิดใน Repo อื่นมากกว่า ดังนั้นคุณปิด Issue ของพวกเขา คัดลอกไปยัง Repo อื่น แล้วเพิ่มคอมเมนต์แนะนำว่าจะเริ่มแก้ไขจากตรงไหนในโค้ด แม้คุณสงสัยว่าพวกเขาจะทำจริงๆ ไม่กี่คนที่จะทำ
คนที่หกพูดแค่ว่า “ตอนนี้สถานการณ์/สถานะเป็นอย่างไร?” คุณไม่รู้ว่าพวกเขาพูดถึงอะไร ดังนั้นคุณดูบริบท พวกเขาคอมเมนต์บนเธรด GitHub ที่ยาวเกี่ยวกับ Bug ที่มีอยู่นานแล้วในโครงการ หลายคนไม่เห็นด้วยกับโซลูชันปัจจุบันของปัญหานี้ ดังนั้นมีการอภิปรายมากมาย
ใต้ Issue เฉพาะนี้มีมากกว่า 20 คอมเมนต์ การอ่านและจำทั้งหมดต้องใช้เวลานาน ดังนั้นคุณตอบแค่ว่า “ขออภัย Issue นี้เปิดมาสักพักแล้ว แต่ยังไม่มีใครแก้ไข เรายังพยายามเข้าใจขอบเขตของปัญหา ควรเปิด Pull Request!”
คนที่เจ็ดเป็นแค่บอท GreenKeeper ปัญหาของพวกเขาง่ายมาก ยกเว้นว่า Repo พิเศษนี้มีเทสที่กระจายตัวค่อนข้างมาก และเทสนี้ล้มเหลวด้วยเหตุผลที่ดูเหมือนผิดพลาด ดังนั้นคุณต้องรีรันเทสเพื่อดูว่าผ่านไหม คุณรีสตาร์ทเทส และพยายามจดจำไว้ว่าจะกลับมาดูหลังจาก Travis รันเสร็จ
คนที่แปดเปิด Pull Request แต่ Repo นั้นค่อนข้าง active ผู้ดูแลอีกคนได้ให้ฟีดแบ็คแล้ว คุณมองเธรด คุณเชื่อว่าผู้ดูแลคนอื่นจะจัดการได้ ดังนั้นคุณมาร์คว่าอ่านแล้ว แล้วไปต่อ
คนที่เก้าดูเหมือนจะพบ Bug ที่คุณไม่เคยเห็นมาก่อน แต่น่าเสียดายที่พวกเขาไม่ได้ให้รายละเอียดเพียงพอว่า “ปัญหานี้เกิดขึ้นได้อย่างไร” เบราว์เซอร์อะไร? เวอร์ชัน Node ไหน? เวอร์ชันโครงการไหน? พวกเขาใช้โค้ดอะไรเพื่อทำซ้ำ? คุณขอให้พวกเขาชี้แจง แล้วปิดแท็บ
ปัญหาไหลเข้ามาเรื่อยๆ
ไม่นาน คุณรับมือคนแบบนี้ 10-20 คน ยังมีอีกกว่า 100 คนรออยู่ แต่ตอนนี้คุณรู้สึกหมดแรง ทุกคนไม่บ่นก็มีปัญหาให้ตอบหรือมีคำขอเพิ่มฟีเจอร์
ในระดับหนึ่ง การแจ้งเตือน GitHub เหล่านี้คือด้านลบของโครงการที่ไหลออกมาเรื่อยๆ เมื่อพวกเขาพอใจกับงานของคุณ จะไม่มีใครสร้าง Issue หรือ Pull Request มีเฉพาะเมื่อพวกเขาพบว่าขาดอะไรไป ถึงจะทำเช่นนั้น แม้คุณจะใช้เวลาน้อยในการอ่านการแจ้งเตือนเหล่านี้ แต่ทั้งทางจิตใจและอารมณ์มันเป็นการสิ้นเปลือง
ภรรยาของคุณสังเกตว่าหลังจากทำธุระเหล่านี้เสร็จคุณมักจะหงุดหงิด บางทีคุณพบว่าตัวเองด่าเธอโดยไม่มีเหตุผล แค่อารมณ์ไม่ดี เธอถามคุณว่า “ถ้างานโอเพนซอร์สทำให้คุณโกรธขนาดนี้ ทำไมคุณยังทำมัน?” คุณหาคำตอบที่ดีไม่ได้
คุณสามารถหยุดพัก จริงๆ แล้วตอนนี้คุณอาจเข้าใจแล้ว ในอดีต คุณเคยหยุดพักจาก GitHub หนึ่งหรือสองสัปดาห์ เพื่อสุขภาพจิต แต่สุดท้ายเพราะมีหลายร้อยคนรออยู่อย่างอดทน (ให้คุณจัดการปัญหา) คุณต้องหยุดพัก
ถ้าคุณติดตามการแจ้งเตือน GitHub อย่างต่อเนื่องในอดีต คุณอาจจัดการ 20-30 รายการต่อวัน ในทางกลับกัน คุณปล่อยให้มันสะสม ดังนั้นตอนนี้มีหลายร้อยรายการ คุณรู้สึกผิด
ในอดีต ด้วยเหตุผลนี้หรือเหตุผลอื่น คุณปล่อยให้ Issue เหล่านี้สะสม คุณอาจเห็น Issue ที่ไม่มีใครตอบเป็นเดือน โดยปกติ เมื่อคุณกลับไปหา Issue นั้น คนที่เปิด Issue มักไม่ตอบ หรือพวกเขาตอบว่า “เราเลิกใช้โครงการของคุณแล้วไปใช้อันอื่น ปัญหาของฉันก็หาย” นี่ทำให้คุณรู้สึกแย่ แต่คุณเข้าใจความผิดหวังของพวกเขา
คุณรู้จากประสบการณ์ว่า สำหรับ Issue เก่าเหล่านี้ การตอบที่ใช้ได้จริงมักเป็นแค่การพูดว่า “ฉันจะปิด Issue เก่าเหล่านี้ ถ้ายังเป็นปัญหาสำหรับคุณ หรือคุณสามารถให้รายละเอียดเพิ่มเติมได้ โปรดเปิด Issue ใหม่” โดยปกติไม่มีใครตอบ บางครั้งมี แต่เป็นแค่คอมเมนต์โกรธ บ่นว่าทำไมให้พวกเขารอนานขนาดนี้
ดังนั้นตอนนี้คุณอยากจัดการกล่องจดหมายการแจ้งเตือนของคุณบ่อยขึ้น หลายร้อยรายการมากเกินไป คุณอยากให้ตัวเลขนี้ลดลงเหลือร้อย หลักสิบ หรือแม้แต่ตำนานที่ว่างเปล่า ดังนั้นคุณดันตัวเองต่อไป
ดึงดูดผู้มีส่วนร่วมใหม่
หลังจากจัดการ Issue แบบนี้มากพอ แม้กล่องจดหมายของคุณจะว่างในที่สุด สุดท้ายอาจยังมี Bug และ Pull Request สะสมอยู่มาก แท็กสามารถช่วยได้ — เช่น คุณสามารถมาร์ค Issue ว่า “ต้องการทำซ้ำ” หรือ “มีเทสเคส” หรือ “แพตช์แรกที่ยอดเยี่ยม” “แพตช์แรกที่ยอดเยี่ยม” มีประโยชน์โดยเฉพาะ เพราะพวกมันมักดึงดูดผู้มีส่วนร่วมใหม่
อย่างไรก็ตาม Issue ที่คุณส่งที่ดึงดูดผู้มีส่วนร่วมใหม่ มักเป็นประเภทที่จัดการง่ายมาก ประเภทนี้ Issue ให้อาสาสมัครใหม่บันทึก มีค่ามากกว่าที่คุณจะทำเอง คุณสร้าง Issue แบบนี้บางอัน เพราะคุณรู้คุณค่าของมัน ให้คนใหม่เข้าร่วมโอเพนซอร์ส เมื่อผู้เขียน Pull Request บอกคุณว่า “นี่เป็นการมีส่วนร่วมครั้งแรกของฉันในชุมชนโอเพนซอร์ส” คุณรู้สึกดีมาก
แต่คุณรู้ว่าโอกาสที่พวกเขาจะกลับมานั้นน้อยมาก โดยปกติเพื่อนเหล่านี้จะไม่กลายเป็นผู้มีส่วนร่วมประจำหรือผู้ดูแล คุณสงสัยว่าคุณทำอะไรผิด คุณควรปรับปรุงอย่างไร จึงจะดึงดูดผู้มีส่วนร่วมใหม่ให้ช่วยลดภาระของคุณได้
คุณมีโครงการหนึ่งที่ดูแลตัวเองได้เกือบทั้งหมด คุณไม่ได้แตะมาหลายปี แต่มีกลุ่มผู้ดูแลที่ตอบทุก Issue และ PR ดังนั้นคุณไม่ต้องทำเอง คุณรู้สึกขอบคุณผู้ดูแลเหล่านี้มาก แต่คุณไม่รู้ว่าคุณทำอะไรถึงทำให้ผู้มีส่วนร่วมหลายคนลงทุนกับโครงการนี้ ในขณะที่โครงการอื่นๆ สุดท้ายมีแค่คุณ และมีเพียงคุณคนเดียวที่รับผิดชอบ
มองไปข้างหน้า
คุณไม่อยากสร้างโครงการใหม่ เพราะคุณรู้ว่ามันจะเพิ่มภาระการดูแลของคุณ จริงๆ แล้วมีผลกระทบย้อนกลับ ยิ่งคุณประสบความสำเร็จ คุณยิ่งได้รับ “การลงโทษ” ในการแจ้งเตือน GitHub มากขึ้น
คุณยังจำความรู้สึกดีใจตอนสร้างได้ เขียนโครงการใหม่จากศูนย์และความสุขในการแก้ปัญหาที่ไม่เคยถูกแก้มาก่อน แต่ตอนนี้คุณเริ่มชั่งน้ำหนักความสุขนี้ เพราะโครงการใหม่ทุกโครงการจะต้องดึงเวลาจากโครงการเก่า คุณไม่รู้ว่าถึงเวลาที่จะปล่อยวาง Repo เก่าของคุณอย่างเป็นทางการหรือยัง หรือมาร์คว่า Unmaintained
คุณไม่รู้ว่าสถานการณ์แบบนี้จะดำเนินต่อไปนานแค่ไหนก่อนที่คุณจะหมดไฟ คุณเคยคิดจะทำงานโอเพนซอร์สเป็นงานประจำวัน แต่หลังจากคุยกับเพื่อนที่ทำงานโอเพนซอร์สเป็นอาชีพจริงๆ คุณรู้ว่าโดยปกตินั่นหมายถึงการให้โครงการโอเพนซอร์สเฉพาะเป็นงานประจำวันของคุณ นี่ไม่เป็นประโยชน์สำหรับคุณ เพราะคุณมีโครงการหลายสิบโครงการข้ามหลายสาขา ที่ต่างแย่งเวลาของคุณ
สิ่งที่คุณต้องการมากที่สุดคือโครงการที่ดูแลตัวเองได้มากขึ้น คุณพยายามปฏิบัติตามแนวปฏิบัติที่ดีที่สุดทั้งหมด: คุณมี CONTRIBUTING.md และแนวทางพฤติกรรม คุณมอบสิทธิ์อย่างอบอุ่นให้ทุกคนที่ส่ง PR คุณภาพสูง อย่างไรก็ตาม การทำแบบนี้กับทุกโครงการก็ใช้พลังงานมาก ดังนั้นคุณไม่ได้ขยันเท่าที่คุณหวัง
คุณยังรู้สึกผิดเรื่องนี้ เพราะคุณรู้ว่าโอเพนซอร์สมักถูกมองว่าเป็นสโมสรพิเศษของชายผิวขาวที่มีสิทธิพิเศษ (เช่นคุณ) ดังนั้นคุณกังวลว่าคุณไม่ได้ทำมากพอที่จะแก้ปัญหานั้น
ที่สำคัญกว่า คุณรู้สึกผิด: ผิดเพราะคุณรู้ว่าคุณสามารถช่วยบางคนแก้ปัญหาของพวกเขาได้ แต่คุณปล่อยให้ Issue ของพวกเขาถูกเพิกเฉยเป็นเดือนก่อนปิด หรือมีคนเปิด Pull Request แรกของพวกเขาใน Repo ของคุณ แต่คุณไม่มีเวลาตอบ ซึ่งอาจทำให้พวกเขาท้อแท้จนไม่อยากมีส่วนร่วมในโอเพนซอร์สอีกเลย ความรู้สึกผิดของคุณเป็นเพราะสิ่งที่คุณทำแล้ว และสิ่งที่คุณไม่ได้ทำ และเพราะคุณไม่สามารถดึงดูดคนมากขึ้นมาแบ่งปันประสบการณ์ที่น่าสมเพชของคุณ
รวมทั้งหมดเข้าด้วยกัน
ทุกสิ่งที่ฉันพูดข้างต้นเป็นประสบการณ์ของฉันเอง ฉันไม่สามารถอ้างว่าฉันเป็นตัวแทนของผู้ทำงานซอฟต์แวร์โอเพนซอร์สทั้งหมด นี่คือความรู้สึกของฉันเอง
ฉันทำงานโอเพนซอร์สมานานพอสมควรแล้ว (ประมาณ 7 ปี) ฉันไม่อยากบ่นเรื่องเหล่านี้ เพราะฉันกังวลว่าจะถูกตีความว่าเป็นรุ่นพี่ที่ควรรู้ดีกว่านี้มาบ่นอย่างเกินจริง ท้ายที่สุด สถานการณ์นี้ไม่ใช่ฉันทำให้เกิดขึ้นเองหรือ? ฉันสามารถออกจาก GitHub ได้ทุกเมื่อ ฉันไม่ได้เซ็นสัญญากับใคร
แล้วฉันไม่ควรรู้สึกขอบคุณหรือ? งานโอเพนซอร์สที่ฉันทำช่วยสร้างตำแหน่งของฉันในชุมชน ฉันได้รับเชิญให้ไปพูดในที่ประชุม บน Twitter ฉันมีผู้ติดตามหลายพันคน ที่รับฟังความคิดของฉัน และให้ความสำคัญกับความคิดเห็นของฉัน พูดได้ว่า ฉันได้งานที่ Microsoft เพราะประสบการณ์โอเพนซอร์สของฉัน ฉันจะบ่นอะไรอีก?
อย่างไรก็ตาม ฉันรู้ว่าคนอื่นๆ ที่อยู่ในตำแหน่งเดียวกับฉันหลายคนหมดไฟแล้ว เพื่อนๆ ที่เคยกระตือรือร้นในการ merge Pull Request จัดการ Issue เขียนบล็อกโชว์โครงการของพวกเขา แล้วก็หายไปโดยไม่มีร่องรอย สำหรับบางคน ฉันไม่อยากเปิด Issue ใน Repo ของพวกเขาด้วยซ้ำ เพราะฉันรู้ว่าพวกเขาจะไม่ตอบ ฉันไม่ได้คัดค้านพวกเขา แต่ฉันกังวลว่าฉันจะกลายเป็นเหมือนพวกเขา
ฉันได้ใช้มาตรการป้องกันตัวเองจำนวนมาก ฉันไม่ใช้อินเทอร์เฟซการแจ้งเตือน Github อีกต่อไป — ฉันใช้ตัวกรองอีเมล เพื่อให้ฉันสามารถจัดหมวดหมู่การแจ้งเตือนตามโครงการ (ประเภท Unmaintained สามารถเพิกเฉยได้) หรือตามประเภทการแจ้งเตือน (เธรดที่ถูกกล่าวถึงหรือที่ฉันคอมเมนต์มักจะมีความสำคัญก่อน) เพราะเป็นอีเมล มันยังช่วยให้ฉันทำงานออฟไลน์และจัดการทุกอย่างในที่เดียว
ฉันมักจะได้รับอีเมลขอความช่วยเหลือในโครงการที่ฉันเลิกดูแลนานแล้วอย่างน่าประหลาดใจ (เช่นโครงการนี้ ฉันยังได้รับอย่างน้อยหนึ่งฉบับต่อเดือน) และโดยปกติฉันไม่ตอบ ฉันยังเลือกที่จะเพิกเฉยคอมเมนต์ใต้บล็อกโพสต์ของฉัน ไม่ตอบคำตอบบน Stack Overflow และคำถามใต้รายชื่ออีเมล ฉันยังยกเลิกการติดตาม Repo ที่ฉันคิดว่าผู้อื่นดูแลดีพออย่าง active
อีกเหตุผลหนึ่งที่สถานการณ์นี้น่าผิดหวังมากคือ คุณค้นพบมากขึ้นเรื่อยๆ ว่าการจัดการ Issue ดึงเวลาจากการดูแลโครงการจริงไปมาก กล่าวอีกนัยหนึ่ง ฉันมักมีเวลาพอแค่อ่าน Issue แล้วพูดว่า “ขออภัย ฉันไม่มีเวลาดูตอนนี้” การกระทำของการตอบเพียงอย่างเดียว ก็ใช้เวลาส่วนใหญ่ที่ฉันสำรองไว้สำหรับโอเพนซอร์ส
Issue templates, GreenKeeper, Travis, travis_retry, Coveralls, Sauce Labs… มีเครื่องมือทางเทคนิคมากมายที่จัดการปัญหาการดูแลโอเพนซอร์ส ฉันรู้สึกขอบคุณสำหรับเครื่องมือเหล่านี้ ถ้าไม่มีเครื่องมืออัตโนมัติเหล่านี้ ฉันคงไม่สามารถรักษาสติได้ แต่ในบางจุด คุณจะพบ Issue มากมาย ที่ปัญหาทางสังคมในนั้นมากกว่าปัญหาทางเทคนิค คนหนึ่งคนไม่เพียงพอ ฉันยังไม่ได้เข้ารายชื่อผู้ดูแล npm 100 อันดับแรก และฉันก็หมดไฟแล้ว ฉันนึกภาพไม่ออกว่า 100 คนนั้นรู้สึกอย่างไร
ฉันบอกภรรยาของฉันแล้วว่า ถ้าเราวางแผนจะมีลูก ฉันควรเลิกทำงานโอเพนซอร์ส ฉันรู้สึกว่าฉันไม่สามารถดูแลครอบครัวและดูแลโครงการโอเพนซอร์สพร้อมกันได้ ฉันคาดการณ์ว่าการเลิกทำโอเพนซอร์สคือโซลูชันสำหรับปัญหาหลักของฉัน ฉันแค่หวังว่ามันจะมาในรูปแบบบวก เหมือนการเริ่มต้นบทใหม่ของชีวิตฉัน ไม่ใช่ในรูปแบบลบ เช่นการหมดไฟอย่างไม่มีมารยาท
ความคิดสุดท้าย
ถ้าคุณอ่านมาถึงตรงนี้ และคุณสนใจในปัญหาที่รบกวนชุมชนโอเพนซอร์สและโซลูชันที่เป็นไปได้ คุณอาจต้องการศึกษา Roads and Bridges ของ Nadia Eghbal มันน่าจะเป็นการวิเคราะห์ที่ชัดเจนและลึกซึ้งที่สุดเกี่ยวกับปัญหานี้
ฉันยังเปิดรับคำแนะนำ แม้ฉันจะจำไว้ในใจว่าฉันไม่อยากผสมเงินและแรงงานในโครงการโอเพนซอร์ส (อาจเป็นเพราะอุดมการณ์ที่ไร้เดียงสา) แต่ฉันเคยเห็นมันทำงานได้ในโครงการอื่นๆ
โปรดทราบว่า แม้ข้อความข้างต้นแสดงด้านลบของโอเพนซอร์ส แต่ฉันยังคงรู้สึกว่ามันเป็นสิ่งที่มีคุณค่าเพิ่มเติมในชีวิตของฉัน ฉันไม่เสียใจเลย แต่ฉันหวังว่าบทความนี้จะเป็นประโยชน์สำหรับทุกคน ให้คุณเห็นว่าเป็นอย่างไรที่จะกลายเป็นเหยื่อของความสำเร็จของตัวเอง และคุณจะรู้สึกหนักใจเพราะงานที่ยังไม่เสร็จ
สิ่งหนึ่งที่ฉันเรียนรู้จากประสบการณ์มีส่วนร่วมในโอเพนซอร์สคือ: ยิ่งคุณมีส่วนร่วมมากเท่าไหร่ ยิ่งมีความต้องการจากคุณมากขึ้นเท่านั้น ฉันตระหนักว่าปัญหาแบบนี้ ไม่มีวิธีแก้ไข
โปรดระบุแหล่งที่มา: ความสัมพันธ์นักพัฒนา »
