การตอบโต้ที่ยอมรับได้ของ“ มันเป็นโอเพนซอร์สส่งแพทช์”? [ปิด]

อันตรายจากการแนะนำคุณสมบัติบางอย่างในผลิตภัณฑ์โดยเฉพาะโอเพนซอร์ซคือคุณจะได้รับการตอบกลับว่า "ทำไมคุณไม่ทำอย่างนั้น"

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

มีคำศัพท์ทั่วไปที่ใช้อ้างอิงถึงปัญหาการพัฒนาซอฟต์แวร์ เช่นBikeshedding มีคำทั่วไปที่ใช้เป็นหลักตอบว่า "ใช่ฉันรู้ว่าฉันสามารถเปลี่ยนแปลงอะไรก็ได้ในโลก - แม้กระทั่งแหล่งข้อมูลปิดฉันสามารถได้รับการว่าจ้างและไปเขียนรหัสนั้น แต่ในกรณีนี้ฉันแค่ทำ การสังเกตที่จริงแล้วอาจมีประโยชน์สำหรับ coder อื่นที่เหมาะสมแล้วที่จะทำการเปลี่ยนแปลงนั้น - หรือเพียงแค่พูดถึงความเป็นไปได้ "

[ps (สองสามวัน) - ฉันควรจะชี้ให้เห็นว่า "ส่งแพทช์" มักจะพูดด้วยอารมณ์เสียเปล่าและฉันกำลังมองหาคำตอบที่เหมาะสม]

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

สิ่งนี้ถูกกล่าวว่า"ส่งแพทช์" ไม่ใช่คำตอบที่ถูกต้อง มันไม่สุภาพ มันไม่ถูกต้อง แม้แต่ผลิตภัณฑ์โอเพนซอร์ซ "ส่งแพทช์" เป็นเวอร์ชั่นย่อของ:

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

แล้วการส่งแพตช์ล่ะ

มันไม่ง่ายเลย วิธีทำ:

• คุณต้องรู้ภาษาที่ใช้ในโครงการโอเพ่นซอร์ส

• คุณต้องสามารถโหลดซอร์สโค้ดจากการควบคุมเวอร์ชันเพื่อให้สามารถแก้ไขได้

• คุณต้องมีเวอร์ชันที่ถูกต้องทั้งหมดของการติดตั้งการพึ่งพาใด ๆ (รวมถึงทั้งไลบรารีรันไทม์และเครื่องมือการสร้าง)

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

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

• คุณต้องปรับตัวเองให้เข้ากับโครงการและนิสัยของนักพัฒนาที่มีส่วนร่วมอย่างแข็งขันกับโครงการ ตัวอย่างเช่นถ้าคุณใช้. NET Framework 4 ทุกวัน แต่โครงการใช้. NET Framework 2.0 คุณจะไม่สามารถใช้ LINQ หรือรหัสสัญญาหรือคุณสมบัติใหม่อื่น ๆ นับพันของกรอบงานรุ่นล่าสุด

• แพทช์ของคุณจะต้องได้รับการยอมรับ (เว้นแต่คุณจะทำการเปลี่ยนแปลงด้วยตัวคุณเองเท่านั้นโดยไม่ต้องมีเจตนาที่จะแบ่งปันกับชุมชน)

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

ดังนั้นจะมีการตอบโต้ที่ยอมรับได้กับ "มันเป็นโอเพนซอร์สส่งแพตช์"? ฉันไม่คิดอย่างนั้น ไม่ว่าคุณจะอธิบายให้คนที่เธอไม่สุภาพหรือคุณเพียงแค่หยุดพูดกับเธอ

การตอบโต้ที่ยอมรับได้คือส่งแพทช์

นี่คือคำตอบมาตรฐานเมื่อนักพัฒนาไม่คิดว่าพวกเขาจะทำอะไรในกรอบเวลาที่เหมาะสม แต่มันถูกนำขึ้นมาซ้ำ ๆ

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

หากคุณแสดงคำขอด้วยตัวเองซ้ำ ๆ การ "นำปะ" มาใช้อาจเป็นเรื่องที่ค่อนข้างสุภาพและมีทางเลือกที่สุภาพน้อยกว่า ...

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

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

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

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

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

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

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

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

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

การตอบโต้ที่ยอมรับได้ของ“ มันเป็นโอเพนซอร์สส่งแพทช์”?

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

ตัวเลือกของคุณคือ:

• ทำสิ่งที่คำตอบแนะนำ; เช่นใช้คุณสมบัติและส่งเป็นแพทช์ มันถูกเรียกว่า "ให้อะไรบางอย่างกลับมา"

• หาคนที่เต็มใจที่จะใช้คุณสมบัตินี้เพื่อเงินจริง อาจเป็นโครงการ (เช่นตอบแทนผู้สนับสนุน) คนที่เกี่ยวข้องกับโครงการหรือ "coder สำหรับการเช่า" แบบสุ่ม

• ค้นหาผลิตภัณฑ์ทางเลือก

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

ฉันได้มีส่วนร่วมในโครงการโอเพ่นซอร์ส OS ที่ใช้เวลานานและสิ่งที่น่ารำคาญที่สุดอย่างหนึ่งก็คือคนที่นั่งอยู่ใน "แกลเลอรีถั่วลิสง" และทำให้คุณมีข้อเสนอแนะเกี่ยวกับการทำสิ่งที่ "ดีกว่า":

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

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

แน่นอนการตอบสนองอื่น ๆ ต่อคนเหล่านี้คือการไม่ตอบสนองหรือเพิกเฉยต่อพวกเขาอย่างสิ้นเชิง

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

คุณไม่เท่ากับ (หรือคุณอาจเพิ่งทำไปแล้ว) ดังนั้นฉันขอแนะนำการตอบโต้ที่เหมาะสมในการ:

"ไม่มีทางที่ฉันจะทำได้ทำได้อย่างรวดเร็วและดีที่สุดเท่าที่จะทำได้ซึ่งเป็นสาเหตุที่ฉันขอให้คุณช่วยฉันตั้งแต่แรกโปรดเถอะ!"

ฉันเชื่อว่ามันขัดกับธรรมชาติของมนุษย์ขั้นพื้นฐานที่จะพูดแล้ว "โอ้ใช่สิ่งนี้ฉันใช้เวลานานและดีจริง ๆ ง่าย ๆ ที่ทุกคนสามารถเข้ามาจากถนนและทำงานได้ดีฉันสามารถ "

การตอบโต้ที่ยอมรับคือการแยกโครงการ

คำตอบที่ยอมรับได้ของ "ส่งแพทช์" คือ:

"ฉันไม่มีทักษะประสบการณ์หรือเวลาที่กำหนดดังนั้นคุณสามารถบอกฉันได้ว่าจะจัดส่งกล่องเบียร์ไปยังคนที่สามารถทำเพื่อฉันได้ไหม"

ส่งที่ครอบคลุมกรณีทดสอบ

"ถ้าคุณทำฉันจะรวมมัน" ดีกว่า "ไม่"

หากคุณไม่สามารถทำงานได้ด้วยเหตุผลใดเหตุผลหนึ่งให้อธิบายถึงสถานการณ์ต่อผู้ดูแลโครงการเป็นส่วนตัว

หากคุณไม่ต้องการมีส่วนร่วมในโครงการโอเพ่นซอร์สที่คุณต้องการใช้คุณควรมองหาการสนับสนุนเชิงพาณิชย์หรือผลิตภัณฑ์เชิงพาณิชย์อื่นแทน

"ขอบคุณสำหรับการตอบกลับ"

เพราะ:

• ที่ศูนย์ราคาอุปสงค์ (คำขอคุณลักษณะ) เกินกว่าอุปทาน (ผู้ให้บริการที่มีอยู่เพื่อใช้คุณสมบัติดังกล่าว)
• การดิ้นรนในสิ่งที่ให้ฟรีขาด IMHO คลาส
• นี่คือจุดรวมของ FOSS: ผู้คนนำผักและเนื้อสัตว์ของพวกเขาเองเพื่อเพิ่มสารอาหารลงในซุปหิน ถ้าฉันไม่สามารถบริจาคบางอย่างได้ฉันก็ควรจะขอบคุณที่ฉันสามารถกินได้ทั้งหมดและไม่บ่นว่าฉันไม่ได้กินดีกว่า

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

ในตอนท้ายของวันไม่มีอะไรที่คุณพูดจะโน้มน้าวให้นักพัฒนาทำงานให้คุณถ้าพวกเขาไม่ต้องการ

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

โดยส่วนตัวแล้วฉันจะได้รับการตอบกลับว่า "นี่เป็นปัญหาที่ทราบกันแล้ว แต่น่าเสียดายที่ไม่ใช่ปัญหาที่จะได้รับการแก้ไขเมื่อเร็ว ๆ นี้นักพัฒนากำลังทำงานกับปัญหาอื่น ๆ ไม่มี ETA ในขณะนี้"

การตอบสนอง "ส่งแพตช์" นั้นหยาบคายมากเพราะถือว่าหลายสิ่ง:

1. ผู้ใช้ทั้งหมดของโปรแกรมเป็นโปรแกรมเมอร์หรือผู้รายงานข้อผิดพลาดทั้งหมดเป็นโปรแกรมเมอร์
2. โปรแกรมเมอร์ทุกคนรู้ภาษาที่โปรแกรมนั้นใช้
3. โปรแกรมเมอร์ทุกคนรู้เกี่ยวกับปัญหาทุกชนิดที่โปรแกรมใด ๆ อาจมี
4. โปรแกรมเมอร์ทั้งหมดมีเวลาว่างในการทำงานในโครงการโอเพ่นซอร์ส

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

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

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

ต่อไปนี้เป็นไปตามการโพสต์โดย Jeremias Maerki (จากชื่อเสียง Apache FOP):

หากสิ่งที่ไม่ได้ผลสำหรับคุณคุณมีหลายตัวเลือก:

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

ฉันคิดว่ามันเป็นคำตอบที่สมบูรณ์แบบมากสำหรับคำตอบ "ส่งแพทช์"

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

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

@MainMa กล่าวว่าการเริ่มมีส่วนร่วมในโครงการใหม่เป็นเรื่องยากมาก นักพัฒนาส่วนใหญ่ไม่เข้าใจสิ่งนี้เนื่องจากพวกเขาได้ทำงานในโครงการเป็นเวลาหลายเดือน / ปีและมันสมเหตุสมผลสำหรับพวกเขา บางครั้งอาจเป็นความผิดพลาดที่แท้จริง

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

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

"ส่งแพทช์" กำลังทำให้โมโห แต่มันเน้นบางอย่างเกี่ยวกับ OSS และอาจเป็นสิ่งเตือนความจำว่า OSS ไม่เหมาะสำหรับทุกคนในทุกสถานการณ์อย่างน้อยก็ไม่ได้โดยไม่ต้องแน่ใจว่าคุณมีกรอบการสนับสนุนที่แน่นหนา ในบ้านจ่ายสำหรับหรือผ่านชุมชน)

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

เปลี่ยนเป็นทางเลือกที่บำรุงรักษาอย่างดี

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

"ฉันสามารถทำงานได้เพียงครั้งเดียว แต่ฉันสามารถบ่นได้หลายอย่างพร้อมกันฉันคิดว่าทั้งสองฟังก์ชั่นนั้นมีประโยชน์" - akkartik บน ycombinator

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

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

มีหลายวิธีที่ควรทำ

• ข้อเสนอคุณสมบัติและการลงคะแนน แต่มันต้องใช้เวลา

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

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

• ใช้ซอฟต์แวร์ที่เป็นกรรมสิทธิ์ซึ่งทำในสิ่งที่คุณต้องการ

• โปรดจำไว้ว่าซอฟต์แวร์ OOP มักทำให้กระบวนการรวมคุณลักษณะนั้นง่ายขึ้น

• การคร่ำครวญในรายชื่อผู้รับจดหมายบน irc หรือในฟอรั่มจะฉกฉวยโปรแกรมเมอร์และจะมอบกระสุนให้กับผู้สนับสนุน OSS

ไม่มีอะไรที่คุณสามารถพูดได้ว่าจะทำให้เขาทำ หลังจากทั้งหมดทำไมเขาควร? เพราะความปรารถนาของผู้ใช้คนหนึ่ง? เหตุผลไม่ดีพอ

แต่ถ้าคุณสามารถรวบรวมจำนวนผู้ใช้ที่สมเหตุสมผลและให้เหตุผลอย่างสมเหตุสมผล ("ฉันต้องการ" ไม่ใช่เหตุผลที่มีเหตุผล) ทำไมคุณลักษณะนั้นอาจมีประโยชน์โดยทั่วไปและกับคุณและจำนวนของผู้อื่นเขาอาจเปลี่ยนใจ .

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

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

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

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

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

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

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

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

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

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

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

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

ฉันสมัครใช้งานจริงเพื่อตอบคำถามนี้

มีความต้องการโต้โต้หรือไม่? การตอบสนองนี้มักใช้เมื่อนักพัฒนาทราบเกี่ยวกับปัญหา แต่ไม่คิดว่าสำคัญ

ฉันจะให้ตัวอย่างสดแก่คุณ ubuntu ลดการสนับสนุนระบบ systray (แต่สามารถแก้ไขได้ด้วยรายชื่อแอปสีขาว) และเพิ่มตัวบ่งชี้แอปใหม่ ปพลิเคชันบางอย่างเช่นดาวพฤหัสบดีเป็นที่พึ่งในการสนับสนุน Systray เพื่อให้นักพัฒนาบอกเกี่ยวกับ workaournd แทนการเพิ่มการสนับสนุนการตรวจสอบตัวบ่งชี้ดังนั้นผมจึงถามนักพัฒนาที่จะเพิ่มการตรวจสอบตัวบ่งชี้ suppory ตอบคือ"ส่งแพทช์." เมื่อถามถึงเหตุผลที่พวกเขาเลือกที่จะไม่ใช้สิ่งนี้ มีสิ่งนี้

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

ถ้ามันเป็นปัญหาทางเทคนิคที่แท้จริงฉันอาจจะลงมือทำ แต่นี่เป็นการวางแผนทางการเมืองอย่างแท้จริงดังนั้นฉันจึงไม่คิดอย่างนั้น

ไม่ฉันจะขึ้นบัญชีขาว

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

Bottom line: retort ที่ยอมรับได้จะส่งแพทช์ แต่ถ้าคุณไม่สามารถมีไม่จำเป็นต้องมีการโต้กลับ

เริ่มเงินรางวัลสำหรับสถานที่ที่คุณต้องการ

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

สิ่งที่ดีที่สุดที่ฉันนึกได้ก็คือ "คุณดูด"

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

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