"ลูกค้าแบบชำระเงินของเราต้องการ X คุณจะแก้ให้เมื่อไร?"

 (twitter.com/maximilianhils)
2 คะแนน โดย GN⁺ 2023-07-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • กรณีผู้ใช้ระดับองค์กรรายหนึ่งที่มีลูกค้าในอุตสาหกรรมที่มีการกำกับดูแล (เช่น ธนาคารและหน่วยงานรัฐบาลกลาง) เรียกร้องกำหนดการรีลีสถัดไปของเครื่องมือโอเพนซอร์ส mitmproxy ในอิชชูสาธารณะ พร้อมกดดันว่าลูกค้าของบริษัทตนไม่สามารถใช้ซอฟต์แวร์ได้ เนื่องจากมีช่องโหว่ระดับ High และ Critical ที่เป็นที่ทราบแล้ว
  • ช่องโหว่ดังกล่าวอยู่ในส่วนของไลบรารีที่ mitmproxy ไม่ได้ใช้งาน จึงเป็นสถานการณ์ที่ไม่มีผลกระทบต่อผู้ใช้จริง
  • เมนเทนเนอร์ไม่ได้ปฏิเสธคำขอ แต่ตอบว่าหากต้องการรีลีสแพตช์อย่างทันท่วงที ก็ควรทำ สัญญาซัพพอร์ตแบบชำระเงิน (support contract) พร้อมชี้ให้ดูอีเมลในโปรไฟล์
  • ผู้ใช้ระดับองค์กรมองคำตอบนี้ว่าเป็น "เรื่องล้อเล่น หรือความพยายามกรรโชกที่พรางไว้อย่างแนบเนียน" และส่งอีเมลประท้วง
  • ประเด็นสำคัญคือ แม้คำถามเรื่องกำหนดการรีลีสจะสมเหตุสมผล แต่จำเป็นต้องมี ท่าทีแบบร่วมมือ เช่น "จะช่วยได้อย่างไรผ่านการมีส่วนร่วมหรือการสนับสนุนเงินทุน" และผู้เขียนคอมเมนต์เดิมได้ส่งคำขอโทษอย่างจริงใจในภายหลัง

เบื้องหลังเหตุการณ์

  • ตามคำอธิบายบริบทที่แนบมา มี ช่องโหว่ในไลบรารี หนึ่งที่ถูกแจกจ่ายร่วมกับ mitmproxy แต่ช่องโหว่นั้นอยู่ในส่วนที่ mitmproxy ไม่ได้ใช้ จึง ไม่มีผลกระทบต่อผู้ใช้จริง
  • หลังจากประเด็นนี้กลายเป็น กระแส (went viral) ภายนอก ได้มีการอธิบายบริบทเพิ่มเติมแล้ว

คำเรียกร้องแรกของผู้ใช้ระดับองค์กร (อิชชูบน GitHub)

  • เมื่อ 16 ชั่วโมงก่อน ผู้ใช้คนหนึ่งกล่าวถึงสมาชิกโปรเจกต์อีกคนคือ @Prinzhorn และถามถึง วันเป้าหมาย (target date) สำหรับรีลีสถัดไป
  • อธิบายว่าลูกค้าใน อุตสาหกรรมที่มีการกำกับดูแล (regulated industries) เช่น ธนาคารและหน่วยงานรัฐบาลกลาง ถูกข้อกำหนดห้ามใช้ซอฟต์แวร์ที่มีช่องโหว่ระดับความรุนแรง High หรือ Critical ที่เป็นที่ทราบแล้ว
    • ระบุว่าบริษัทต้องการกำหนดจุดยืนของตนเองเกี่ยวกับการรอคอย (waiting) แต่จำเป็นต้องมี กำหนดการเป้าหมายในรูปแบบใดรูปแบบหนึ่ง

คำตอบของเมนเทนเนอร์ mhils

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

อีเมลประท้วง ("Concerning response")

  • ต่อมา มีอีเมลหัวข้อ "Concerning response" ถูกส่งจากที่อยู่โดเมน us.ibm.com ไปยัง github@hi.ls (ระบุวันที่ Jul 14, 2023)
  • ขึ้นต้นว่า "Mr. Hils" และระบุว่าตั้งใจจะอธิบายคำขอเรื่องกำหนดการเป้าหมายให้ชัดขึ้น เพื่อให้ได้ คำตอบโดยตรง แทนที่จะทำให้เรื่องบานปลายหรือทำให้ GitHub issue tracker รกด้วยถ้อยคำที่ไม่จำเป็น
    • ระบุว่าหวังว่าอีเมลติดตามฉบับนี้จะไม่ถูกมองว่าไม่พอใจ เพราะนั่น ไม่ใช่ เจตนา
  • ในส่วนที่ถูกเน้น ระบุว่าสมมติว่าคำตอบของเมนเทนเนอร์เป็น เรื่องล้อเล่น ไม่ใช่คำตอบอย่างเป็นทางการของโปรเจกต์ หรือที่แย่กว่านั้นคือ ความพยายามกรรโชกที่พรางไว้อย่างแนบเนียน (thinly veiled extortion attempt) (จากนั้นประโยคขาดช่วงระหว่างตรวจเอกสารทางการของโปรเจกต์)

สรุปจุดยืนของเมนเทนเนอร์

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

ปิดท้าย

  • ผู้เขียนคอมเมนต์เดิมได้ส่ง คำขอโทษอย่างจริงใจ (genuine apology) มา และเมนเทนเนอร์รู้สึกขอบคุณจากใจจริง
  • ขอให้ทุกคน ตั้งสมมติฐานว่าผู้อื่นมีเจตนาดี (assume good intentions) และปฏิบัติต่อกันด้วยความกรุณา

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-07-16
ความคิดเห็นใน Hacker News

  • ถ้าอ่านอีชูนี้https://github.com/mitmproxy/mitmproxy/issues/6051 จะเห็นว่าคำขอของ IBM สมเหตุสมผลกว่าที่เห็นในทวีตมาก
    ปัญหาคือมี CVE อยู่ใน dependency ของ mitmproxy และแม้ว่า mitmproxy จะอัปเดต dependency ไปแล้วตั้งแต่เดือนมีนาคม แต่จนถึงตอนนี้ก็ยังไม่ได้ออกรุ่นเสถียรที่รวมอัปเดตนั้นเข้าไป ฝั่ง IBM กำลังถามว่า “มีแผนจะติด release tag เมื่อไร มีกรอบเวลาที่จะสื่อสารกับลูกค้าได้หรือไม่”
    โดยเฉพาะอย่างยิ่ง พวกเขาไม่ได้ถามว่า “จะซ่อมเมื่อไร” สิ่งที่ต้องแก้จริง ๆ ไม่มีแล้ว และคำถามใกล้เคียงกว่าคือ “มีแผนจะออกรุ่นใหม่ที่รวมการอัปเดต dependency นี้เมื่อไร”
    ผมไม่คิดว่าคำถามแบบนี้ไม่สมควรนะ แน่นอนว่าถ้าต้องการให้การแก้ไขแบบนี้ถูกปล่อยออกมาภายในช่วงเวลาที่กำหนด การขอสัญญาซัพพอร์ตก็ไม่ใช่เรื่องไม่สมเหตุสมผล แต่การตอบทันทีว่า “หากต้องการสัญญาซัพพอร์ตให้ติดต่อทางอีเมล” ก็ดูแรงไปหน่อย

    • คำถามแรกสุภาพและสมเหตุสมผล และคำตอบของ @mhils ก็เช่นกัน สิ่งที่ไม่สมเหตุสมผลเลยคืออีเมลติดตามจากฝั่ง IBM หลังจากนั้นที่กล่าวหาว่าเป็น “ความพยายามรีดไถที่อำพรางไว้อย่างผิวเผิน”
      Maximilian ไม่มีหน้าที่ต้องให้กำหนดการออกรุ่นกับคนที่ไม่ได้จ่ายเงิน และถ้า IBM ต้องการไทม์ไลน์จริง ๆ การเสนอให้จ่ายค่าใช้จ่ายก็ไม่ได้แปลกอะไรเลย ถ้า IBM มองว่าสำคัญขนาดนั้น วันนี้เลยก็สามารถทำ internal release ของ mitmproxy เองได้
    • การถามหา วันออกรุ่น เป็นคำขอที่สมเหตุสมผลอย่างยิ่ง เพียงแต่คำตอบของผมได้รับอิทธิพลจากบริบทมาก
      เหตุผลที่ผมบอกว่า “หากต้องการสัญญาซัพพอร์ตให้ติดต่อทางอีเมล” คือ 1) ผมได้บอกไว้แล้วในเธรดนั้นว่าจะไม่ออกรุ่นแพตช์สำหรับเรื่องนี้ และ 2) อีกฝ่ายเน้นย้ำถึงผลกระทบที่มีต่อลูกค้าที่จ่ายเงินของพวกเขา
      ดังนั้นตอนนั้นจึงไม่มีอะไรให้พูดมากไปกว่านั้น ผมเห็นด้วยว่าน่าจะพูดให้ดีกว่านี้ได้ แต่ก็ไม่รู้สึกว่าคำตอบของผมเกินเลยอย่างสิ้นเชิง
      ตัว CVE เองก็เป็นข้อมูลมั่ว และพวกเราก็ไม่ได้ใช้ส่วนนั้นของ dependency นี้
    • จุดนั้นค่อนข้างชัดเจน ปัญหาอยู่ที่การสื่อสารหลังจากนั้นที่ใช้คำว่า “การรีดไถที่อำพรางอย่างผิวเผิน” ซึ่งห่างไกลจากความสมเหตุสมผลมาก
    • อย่างที่ผู้ดูแลโปรเจ็กต์อธิบาย CVE นั้นไม่ได้ส่งผลกับ mitmproxy จริง ๆ สุดท้ายแล้วมันเป็นแค่การช่วยให้ฝ่ายความปลอดภัยกาช่องในเช็กลิสต์ได้หนึ่งข้อเท่านั้น
      ในเมื่อผู้ร้องขอได้ประโยชน์จากแรงงานฟรี ทำไมผู้ดูแลต้องทำงานฟรีด้วย
      สิ่งที่ไม่สมเหตุสมผลคือท่าทีที่ FrugalGuy มองว่าเป็นเรื่องปกติ ถ้าจะเรียกร้องให้ผู้ดูแลโอเพนซอร์สทำงานฟรี แล้วพอไม่ได้ดั่งใจก็กล่าวหาว่าเป็นการรีดไถ ก็ต้องเป็นคนหน้าด้านในระดับพิเศษทีเดียว คุณไม่สามารถบังคับข้อเรียกร้องกับอาสาสมัครที่ทำโปรเจ็กต์ free/open source แบบพาร์ตไทม์ได้
    • ถึงอย่างนั้น น้ำเสียงเชิงข่มขู่ ที่ใช้ในอีเมลถึงผู้ดูแลก็ยังไม่เปลี่ยนอยู่ดี

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

    • ถ้าเป็นโปรเจ็กต์ของผม ผมคงไม่เสนอ สัญญาซัพพอร์ต เพราะประเด็นกฎหมายแรงงานและภาษีสำหรับผมมันซับซ้อนเกินไป
      การที่เขาเสนอเรื่องสัญญาแบบนั้นจริง ๆ แล้วก็ค่อนข้างใจดี FrugalGuy อาจได้รับคำตอบว่า “ส่ง pull request มา” ก็ได้ และไม่รู้ว่าเขาจะชอบแบบนั้นไหม
    • ถ้าตัดเรื่องอารมณ์และตัวบุคคลออกไป ผมสงสัยว่าในฐานะโปรเจ็กต์ซอฟต์แวร์ อะไรกันแน่ที่ขัดขวางไม่ให้ mitmproxy ออก เวอร์ชันใหม่ ได้ทันที
    • พออ่านสิ่งนี้แล้วผมอยากลบคอมเมนต์ใน GitHub ของตัวเอง แต่เธรดถูกล็อกไว้แล้วเลยลบไม่ได้
    • ผมไม่เข้าใจว่าการมีส่วนร่วมหรือเงินจะแก้ ปัญหาเรื่องการออกรุ่น ได้อย่างไร ถ้าเป็นบั๊ก ก็แก้แล้วส่งเป็นแพตช์ได้
      แต่ถ้าปัญหาคือไม่มีการออกรุ่นสำหรับการแก้ไขที่ทำเสร็จไปแล้ว ผมก็ไม่ค่อยเข้าใจว่าจะใช้การมีส่วนร่วมหรือเงินมาแก้เรื่องนั้นได้อย่างไร
    • ถึงอย่างนั้น มันก็เป็นความพยายามรีดไถอยู่ดี

  • ฟังดูเหมือนพวก คนโง่ด้านความปลอดภัยสารสนเทศ แบบฉบับ ที่ไม่รู้ด้วยซ้ำว่าสิ่งที่ตัวเองจะ “แก้” คืออะไร พอระบบอัตโนมัติแจ้งว่ามี CVE ก็คิดว่าต้อง “แพตช์” ทันที
    พวกเขาไม่ตรวจเลยว่าข้ออ้างใน CVE คืออะไร หรือรูปแบบการใช้งานของตัวเองมีความเสี่ยงจริงหรือไม่ ไม่รู้ ไม่สนใจ และไม่ใช่โปรแกรมเมอร์ สิ่งเดียวที่รู้คือ ต้องลบเครื่องหมายถูกในเช็กลิสต์ให้ได้
    เคยมีเรื่องคล้ายกันกับ h2database เช่นกัน มี “นักวิจัยด้านความปลอดภัย” คนหนึ่งพบว่าถ้าคุณทำสิ่งที่เขาบอกว่าไม่ควรทำ ก็จะเกิดเรื่องไม่ดีขึ้น แล้วก็ยังไปเรียกร้อง CVE จนได้มา ถ้าดูละเอียดจะเห็นว่าเป็นเรื่องเหลวไหล แต่สำหรับคนพวกนี้ สิ่งสำคัญมีแค่ว่า CVE นั้นมีอยู่
    คำพูดของนักพัฒนา h2database: https://github.com/h2database/h2database/issues/3686#issueco...
    “ผมไม่ค่อยเข้าใจว่าทำไมต้องเห็นอกเห็นใจแม้แต่นิดเดียวกับ ‘บริษัทใหญ่’ ที่ใช้โปรเจกต์โอเพนซอร์สซึ่งพัฒนาโดยอาสาสมัคร จะจ้างใครสักคนด้วยเงินบริษัทมาจัดการก็ได้ หรือไม่ก็จ่ายเงินให้ไลบรารีเชิงพาณิชย์ที่คล้ายกัน”

    • พวกเขาอาจรู้และเข้าใจทั้งหมดนี้อยู่แล้ว แต่ก็อาจไม่แคร์ก็ได้ บางทีผลงานอาจถูกวัดจากการลบเช็กลิสต์ได้เร็วแค่ไหน และการปฏิเสธมากเกินไปอาจเสียเปรียบมากกว่าการอนุมัติมากเกินไป
      ต่อให้มีอำนาจให้ข้อยกเว้นในบางกรณี แต่การจะอธิบายเหตุผลของการตัดสินใจนั้นอาจต้องเขียนเอกสารเพิ่มอีก ซึ่งเอกสารเพิ่มนั้นทำให้ช้าลง และส่งผลเสียต่อ KPI ของตัวเอง
    • โอ้โห CVE นั้นชวนอึ้งจริง ๆ
      “ถ้าส่งรหัสผ่านผ่าน command line โปรเซสอื่นในระบบสามารถเห็นได้ด้วย ps”
      ก็แน่อยู่แล้ว ถ้านี่นับเป็น CVE ระดับ “ความรุนแรงสูง” งั้นฉันก็ควรเรียกตัวเองว่านักวิจัยด้านความปลอดภัยได้เหมือนกัน ฉันนึกถึงแอปอย่างน้อยห้าหกตัวที่ยอมให้ทำแบบเดียวกัน พร้อมแค่ติดคำเตือนว่า “อย่าทำแบบนี้”
    • เห็นด้วยสุด ๆ ฉันทำงานในอุตสาหกรรมที่มีการกำกับดูแล และภาพที่เกิดขึ้นคือ
      ทีมความปลอดภัยสารสนเทศยก ช่องโหว่ ที่โผล่ในรายงานขึ้นมา แล้วผู้จัดการก็กลัว
      นักพัฒนาต้องคอยอัปเดตตลอด แม้แต่ dependency ที่ไม่ได้รันใน production ก็ยังต้องทำ ขอข้อยกเว้นได้ แต่ก็เป็นปัญหาปวดหัวอีกแบบหนึ่ง
      แล้วจากนั้นผู้จัดการก็สงสัยว่าทำไมงานพัฒนาถึงช้าลง
    • ฉันทำงานกับ SaaS vendor ในอุตสาหกรรมที่ยังมอง SaaS ว่า “แปลกใหม่” อยู่นิดหน่อย และได้รับ แบบสอบถามด้านความปลอดภัย ไร้สาระพวกนั้นอยู่เรื่อย ๆ โดย 90% ของคำตอบคือ ไม่เกี่ยวข้อง
      และฉันยังสงสัยด้วยซ้ำว่ามีใครตรวจคำตอบที่เหลือจริง ๆ หรือเปล่า

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

    • คำตอบที่ดีที่สุดคือ “อัตราค่าจ้างของฉันคือ $XYZ ต่อชั่วโมง และฉันรับเป็นเงินสดหรือเช็ค”

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

    • ทำแบบนั้นมา 27 ปี คุณก็จะได้เลื่อนเป็น Program Manager Secure Engineering and Incident Response ของ IBM

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

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

  • ระหว่างที่ใช้โอเพนซอร์สแล้ว ยังไปเรียกร้องซัพพอร์ตอีกนั้น แสดงถึง ความรู้สึกว่าบริษัทมีสิทธิ์โดยชอบ อย่างมหาศาล อยากให้ไลเซนส์ที่มีข้อจำกัดการใช้งานถูกใช้อย่างแพร่หลายกว่านี้ และอยากให้ OSI ไม่ได้เอาแต่พูดว่า “นั่นไม่ใช่โอเพนซอร์ส!!!” เฉยๆ
    ไลเซนส์แบบนั้นช่วยป้องกันสถานการณ์ลักษณะนี้ได้

    • GNU AGPLv3 ทำให้ทนายองค์กรหงุดหงิดมากพอจนในทางปฏิบัติอาจทำงานคล้ายไลเซนส์ไม่เชิงพาณิชย์ได้ แต่จริงๆ แล้วมันไม่ใช่ไลเซนส์ไม่เชิงพาณิชย์ และผ่านเกณฑ์ทั้งของ OSI และ FSF
      ไม่ว่าอย่างไร การที่ OSI และ FSF ยืนกรานแข็งกร้าวในเรื่องนี้ก็เป็นสิ่งที่ดี ถ้าลำดับความสำคัญของคุณไม่ตรงกับพวกเขา แล้วทำไมพวกเขาต้องเปลี่ยนตัวเองเพื่อทำให้คุณพอใจด้วย
      ก็แค่ใช้ไลเซนส์ที่คุณชอบ แม้พวกเขาจะไม่รับรองก็ตาม ไม่เข้าใจว่าทำไมถึงต้องเป็นปัญหา ในเมื่อแต่แรกคุณก็ไม่ได้แชร์คุณค่าร่วมกับพวกเขาอยู่แล้ว ทำไมองค์กรเหล่านั้นต้องมาประทับตรารับรองตัวเลือกไลเซนส์ของคุณด้วย
    • เห็นด้วย แต่ลองดูว่าใครเป็นคนออกค่าใช้จ่ายให้ OSI: https://opensource.org/sponsors/
      สำหรับสปอนเซอร์องค์กร การไม่สนับสนุนข้อจำกัดการใช้งานไม่ใช่ข้อบกพร่อง แต่เป็นคุณสมบัติ
      รอบๆ นิยามของโอเพนซอร์สและซอฟต์แวร์เสรีก็มีความยึดติดแบบหลักคำสอนอย่างหนักเช่นกัน ถ้าคุณไม่ทำตามนิยามนี้ ก็พร้อมจะโดนรุมโจมตีได้ง่าย และนิยามเหล่านี้มักถูกปฏิบัติราวกับเป็นคัมภีร์ ผู้สนับสนุนจำนวนมากไม่ยอมรับแม้แต่ความเป็นไปได้ที่มันอาจต้องปรับให้เข้ากับความเป็นจริงของปี 2023
      ต่อให้พยายามสร้างคำใหม่เพื่อหลีกเลี่ยงความขัดแย้ง นักเคลื่อนไหวฝั่งโอเพนซอร์สและซอฟต์แวร์เสรีก็ยังยืนกรานจะใช้ภาษาของตัวเองและควบคุมการเล่าเรื่องต่อไป ภาษานั้นถูกออกแบบให้มีนัยเชิงลบภายในกลุ่มของพวกเขาเอง
    • ฉันไม่อยากให้ข้อจำกัดการใช้งานถูกใช้แพร่หลายขึ้น ไม่เลย ถ้าหมายถึง “ข้อจำกัดการใช้งาน” ที่อยู่นอกเหนือขอบเขตของ การบังคับให้แชร์ภายใต้เงื่อนไขเดียวกัน ในระดับต่างๆ ที่ LGPL, GPL, และ AGPL มอบให้
      เสรีภาพของผู้ใช้ในการรันซอฟต์แวร์เพื่อวัตถุประสงค์ใดก็ตามคือเสรีภาพข้อ 0 และ Stallman ก็อธิบายไว้อย่างน่าเชื่อมากว่าทำไมข้อจำกัดการใช้งานถึงไม่ช่วยอะไร: https://www.gnu.org/philosophy/programs-must-not-limit-freed...
      เช่นเดียวกับข้อปฏิเสธการรับประกัน ซอฟต์แวร์เสรีถูกมอบให้โดยไม่มีเงื่อนไข คุณยังได้รับเสรีภาพในการแก้ไขมันตามต้องการเป็นของแถมอีกด้วย แต่กลับไปเรียกร้องซัพพอร์ตและการบำรุงรักษาฟรีด้วยนั้นเป็นเรื่องเสียมารยาท ต่อให้เปลี่ยนไลเซนส์ ก็ดูไม่น่าจะทำให้คนเสียมารยาทแบบนั้นหายไปได้
    • คิดว่าคนส่วนใหญ่คงไม่ได้อยาก ต่อต้านองค์กร ถึงขนาดนั้น ไม่อย่างนั้นแต่แรกก็คงไม่เลือกใช้ไลเซนส์แบบ permissive
      และก็อาจมีทางเลือกที่เป็นมิตรกับโอเพนซอร์สมากกว่าบริษัทโดยไม่ต้องพึ่งไลเซนส์ก็ได้ เช่น ถ้าใครจะรายงานปัญหาร้ายแรง ก็ต้องเปิดเผยโค้ดที่ใช้ทำให้เกิดปัญหาซ้ำได้
    • ไม่ค่อยแน่ใจว่ามันจะแก้ปัญหาได้อย่างไร ซอฟต์แวร์นั้นก็น่าจะยังถูกใช้ในสภาพแวดล้อมทางธุรกิจอยู่ดี และก็ยังจะมีคนที่เรียกร้องซัพพอร์ตแทนนายจ้างของตัวเองอยู่ดี
      แม้แต่ในยุค 80 ตอนที่ซัพพอร์ตมักให้กันฟรี ก็ได้ยินเรื่องบริษัทที่ทำแบบนี้กับซอฟต์แวร์เถื่อนอยู่บ่อยๆ สิ่งเดียวที่ลดพฤติกรรมแบบนี้ได้คือสัญญาซัพพอร์ตแบบเสียเงิน
      การตอบโต้ที่เป็นจริงได้มีเพียงการฟ้องร้องเรื่องละเมิดไลเซนส์ แต่ก็มีนักพัฒนาโอเพนซอร์สไม่มากนักที่มีทรัพยากรจะทำแบบนั้นได้กับบริษัทใหญ่ ไม่ต้องพูดถึงบริษัทระดับบนๆ

  • พฤติกรรมของ “FrugalGuy” นั้นไม่เป็นมืออาชีพและดูเป็นเด็ก แต่ผู้ดูแล mitmproxy ก็สามารถตอบได้ดีกว่านี้ ด้วยคำตอบที่ทั้งสุภาพและหนักแน่น โดยไม่เปิดช่องให้เกิดความเข้าใจผิดหรือดราม่า
    “ตามไลเซนส์ของ mitmproxy ซอฟต์แวร์นี้ให้มาแบบ as-is โดยไม่มีการรับประกัน และผู้ดูแลโครงการก็กำลังติดภารกิจกับลำดับความสำคัญและงานส่งมอบอื่นอยู่ในขณะนี้”
    “ดังนั้น คำกล่าวใน GitHub issue tracker เพียงอย่างเดียวจึงไม่เพียงพอที่จะใช้กำหนดลำดับความสำคัญของ issue วิธีเดียวที่จะยกระดับความสำคัญของ issue ได้คือทำสัญญาซัพพอร์ต ซึ่งมีให้ที่ [here] และเรายินดีหารือรายละเอียดเพิ่มเติม”

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

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

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

  • https://github.com/mitmproxy/mitmproxy/issues/6051#issuecomm...

    • อีเมลติดตามผลที่ OP ลิงก์ไว้นั้นเกินเส้นไปมาก แต่โพสต์บน GitHub นี้เองฉันไม่คิดว่ามีอะไรน่าตำหนิ แม้แต่คำตอบแบบ “จ่ายเงินสิ” ก็ไม่ได้มีปัญหา
      การถามง่ายๆ ว่า “มีวันเป้าหมายสำหรับรีลีสถัดไปไหม?” ไม่ใช่ปัญหา เพราะมันไม่ใช่การเรียกร้อง
      คำพูดว่า “เรากำลังพยายามสร้างตรรกะภายในเพื่อรอ และต้องการวันเป้าหมายบางอย่าง” นั้น คำว่า “ต้องการ” อ่านได้ว่าไม่ได้เป็นการเรียกร้องไปยังนักพัฒนา mitmproxy แต่เป็นการสะท้อนว่าคนอื่นกำลังเรียกร้องจากเขา
      ในคอมเมนต์นี้ เขากำลังขอความช่วยเหลือพร้อมอธิบายแรงจูงใจเชิงธุรกิจและส่วนตัวของคำขอนั้น ก่อนที่จะย้อนกลับมาทางอีเมลพร้อมคำอย่างการขู่กรรโชก มันก็ยังไม่มีปัญหาอะไร
    • ตัวบุคคลเฉพาะเจาะจงสำคัญด้วยหรือ
      ในโพสต์ต้นฉบับมีทั้งบริบทและนายจ้างรวมอยู่ด้วย เห็นได้ชัดว่าผู้เขียนตั้งใจหลีกเลี่ยงเรื่องนั้น แต่การเอา GitHub issue จริงมาเผยแพร่ก็เป็นพฤติกรรมที่แย่เหมือนกัน
    • FrugalGuy เนี่ยนะ จนพูดไม่ออก