เมื่อฮาร์ดแวร์เลิกผลิต บริษัทควรต้องเปิดซอร์สซอฟต์แวร์

 (marcia.no)
4 คะแนน โดย GN⁺ 2026-01-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อ ผลิตภัณฑ์ฮาร์ดแวร์เข้าสู่สถานะเลิกผลิต (EOL) มีข้อเสนอว่า บริษัทควรต้องเปิดซอร์สซอฟต์แวร์นั้นโดยบังคับ
  • แม้ ขบวนการ Right to Repair จะมีความคืบหน้าแล้ว แต่มีการเสนอว่าในระดับสหภาพยุโรปควร บังคับทางกฎหมายให้เปิดเผยซอฟต์แวร์เมื่อถึง EOL
  • ยกตัวอย่างกรณี เครื่องชั่งน้ำหนักอัจฉริยะ ที่สูญเสียความสามารถในการใช้งานเพราะแอปหยุดรองรับ และกรณี Car Thing ของ Spotify ที่กลายเป็นขยะอิเล็กทรอนิกส์หลังเลิกผลิต
  • บริษัทไม่จำเป็นต้องเปิดเผยโค้ดทั้งหมด แต่ควร เปิดเผยเฉพาะสเปกฮาร์ดแวร์และโปรโตคอลการเชื่อมต่อ เพื่อให้ชุมชนพัฒนาแอปของตนเองได้
  • เพื่อ ความยั่งยืนและสิทธิของผู้ใช้ แนวทางโอเพนซอร์สที่ช่วยชุบชีวิตฮาร์ดแวร์ที่เลิกผลิตแล้วจึงเป็นสิ่งจำเป็น

ความจำเป็นของโอเพนซอร์สเมื่อฮาร์ดแวร์เลิกผลิต

  • เมื่อผลิตภัณฑ์ฮาร์ดแวร์เข้าสู่สถานะ EOL (End of Life) บริษัทควร เปิดซอร์สซอฟต์แวร์

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

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

    • มองว่า คณะกรรมาธิการยุโรป (European Commission) ควรกำกับให้บริษัทเปิดเผยซอฟต์แวร์เมื่อผลิตภัณฑ์เลิกผลิต

ประสบการณ์ส่วนตัวและกรณีปัญหา

  • ในกรณีของ เครื่องชั่งน้ำหนักอัจฉริยะ ฮาร์ดแวร์ยังทำงานปกติ แต่แอปถูกยกเลิกจน ฟังก์ชันการบันทึกข้อมูลหายไป

    • แม้จะยังเชื่อมต่อ Bluetooth ได้ แต่เพราะแอปไม่ได้รับการพัฒนาต่อ จึง แทบใช้งานต่อไม่ได้จริง
    • มีการตั้งคำถามทั้งเรื่อง ความไม่พอใจและความสิ้นเปลือง จากการที่ฮาร์ดแวร์สมบูรณ์ดีต้อง “ตาย” เพราะบริษัทหยุดสนับสนุน

  • มีการกล่าวถึงกรณีเลิกผลิต Car Thing ของ Spotify

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

ทางเลือกที่ทำได้จริง

  • บริษัท ไม่จำเป็นต้องเปิดเผยโค้ดทั้งหมด

    • เพียงเปิดเผย สเปกฮาร์ดแวร์และโปรโตคอลการเชื่อมต่อในรีโพซิทอรี GitHub ก็เพียงพอ
    • ชุมชนสามารถนำข้อมูลนั้นไป พัฒนาแอปของตัวเอง ได้

  • ด้วยแนวทางการพัฒนาใหม่อย่าง vibe-coding ทำให้ แม้แต่ผู้ที่ไม่ใช่มืออาชีพก็เข้ามามีส่วนร่วมได้ง่ายขึ้น

    • เรากำลังก้าวเข้าสู่ยุคที่ผู้ใช้ทั่วไปสามารถจัดการและปรับปรุงฮาร์ดแวร์ได้ด้วยตนเอง

ความยั่งยืนและสิทธิของผู้ใช้

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

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

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

 
GN⁺ 2026-01-15
ความคิดเห็นจาก Hacker News

  • วิธีที่แน่นอนที่สุดที่จะทำให้โปรเจกต์ EOL (End-of-Life) กลายเป็นโอเพนซอร์ส คือ เริ่มต้นเป็นโอเพนซอร์สตั้งแต่แรก
    คำสัญญาว่า “จะเปิดเผยหลังบรรลุเป้าหมาย” หรือการประกาศว่าจะเปิดถ้าบริษัทล้มละลาย ล้วนไม่มีความหมาย
    ต้องเริ่มเป็นโอเพนซอร์สตั้งแต่ต้น นักลงทุนและชุมชนจึงจะเชื่อถือได้
    ควรใช้เงินกับบริษัทที่ทำผลิตภัณฑ์โอเพนซอร์สและฮาร์ดแวร์แบบเปิด และสนับสนุนศิลปินที่เผยแพร่ผลงานอย่างเสรี
    การตำหนิบริษัทที่ไม่เปิดเผยหลัง EOL สุดท้ายก็เป็นเพียงการแสดงออกเชิงสัญลักษณ์เท่านั้น

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

  • ระบบส่วนใหญ่พึ่งพาห่วงโซ่การลงนามโค้ดและทำงานแบบ “fail closed”
    แต่เมื่อผู้มีอำนาจลงนามเดิมหายไป ก็ควรมีโครงสร้างแบบ “fail open” ที่สามารถมอบสิทธิ์การลงนามให้กับผู้ดูแลรายใหม่ได้

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

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

  • อุปกรณ์อย่างเราเตอร์ที่ secure boot ถูกฝังไว้ใน e-fuse ไม่สามารถแก้ปัญหาได้ด้วยการเปิดซอร์สอย่างเดียว
    ในกรณีเช่นนี้ ผู้ผลิตควรเก็บคีย์ลงนามไว้ในรูปแบบ escrow เพื่อให้หลัง EOL แล้วยังสามารถรันซอฟต์แวร์ใหม่ได้

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

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

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

  • แนวคิดนี้น่าสนใจยิ่งกว่าคำว่า “โอเพนซอร์ส” เสียอีก
    ตัวอย่างเช่น หาก UBNT เปิดเผยบูตเชนของอุปกรณ์ที่ EOL แล้ว จนทำให้ Cambium ใช้เฟิร์มแวร์นั้นได้
    ผลลัพธ์อาจไม่ใช่การสนับสนุนจากชุมชน แต่กลายเป็น การแข่งขันอัปเดตผลิตภัณฑ์แบบไม่มีที่สิ้นสุด

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

  • Google Nest Thermostat รุ่นที่ 1 และ 2 เป็นตัวอย่างชัดเจน
    โปรเจกต์ No Longer Evil ชุบชีวิตอุปกรณ์นี้ขึ้นมาใหม่ด้วย เฟิร์มแวร์โอเพนซอร์ส
    โดยตัดการพึ่งพา Google Cloud ออก และทำให้ผู้ใช้โฮสต์เซิร์ฟเวอร์เองหรือควบคุมได้อย่างอิสระ
    ส่งผลให้ฮาร์ดแวร์ราคาแพงกลับมามีชีวิตอีกครั้ง

  • รู้สึกว่าตอนนี้เราอยู่ใน ยุคมืด รูปแบบหนึ่ง
    เตาผิงรุ่นเก่าแค่ต่อพินหนึ่งลงกราวด์ก็ใช้งานได้ แต่รุ่นถัดมากลับเปลี่ยนเป็น โปรโตคอลปิด ที่เข้าถึงได้ยาก
    อย่างไรก็ตาม รุ่นใหม่ล่าสุดกลับรองรับมาตรฐาน OpenTherm อีกครั้ง ทำให้แฮ็กได้ง่ายขึ้น
    ทุกวันนี้มีฮาร์ดแวร์เปิดที่ใช้ ESP32 หรือ Raspberry Pi มากมาย จึงสามารถทำ GUI ด้วย ESPHome + LVGL เองและรวมเข้ากับระบบบ้านอัตโนมัติได้
    งานออกมาดีจนเพื่อนๆ นึกว่าเป็นผลิตภัณฑ์จากแบรนด์ดัง

  • ผมคิดว่า “เรื่องนั้นคงไม่เกิดขึ้น”
    โชคดีที่ตอนนี้ AI และ Android ทำให้การรีเวิร์สเอนจิเนียร์โปรโตคอลง่ายขึ้น
    แค่การวิเคราะห์ APK ก็ได้ข้อมูลมามากแล้ว ตอนนี้ผมกำลังทำทั้งแอปและเซิร์ฟเวอร์สำหรับ Limitless Pendant ที่ซื้อไว้ก่อน Meta จะเข้าซื้อกิจการ
    โดยยังไม่ได้เขียนโค้ดเองแม้แต่บรรทัดเดียว

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