ทีมพัฒนา MeshCore แยกทางกันจากข้อพิพาทเครื่องหมายการค้าและปัญหาโค้ดที่สร้างโดย AI
(blog.meshcore.io)- ในโปรเจ็กต์ mesh networking ที่เติบโตอย่างรวดเร็ว เกิดปัญหาซ้อนกันทั้งเรื่องการยื่นจดเครื่องหมายการค้าและการใช้โค้ดที่สร้างโดย AI จนทำให้ core team กับ Andy Kirby แยกทางกัน
- Andy Kirby ใช้ Claude Code อย่างกว้างขวางเพื่อขยายงานไปถึง standalone device, แอปมือถือ, web flasher และเครื่องมือ web config โดยทีมระบุว่างานส่วนใหญ่เหล่านี้เป็นงานแบบ vibe coded และมีการปกปิดเรื่องนี้
- จุดชนวนโดยตรงของการแยกทางคือ Andy ได้ยื่นขอ เครื่องหมายการค้า MeshCore เมื่อวันที่ 29 มีนาคมโดยไม่แจ้งทีม หลังจากนั้นการพูดคุยเรื่องเจตนาก็ล้มเหลวและตอนนี้อยู่ในภาวะขาดการติดต่อกัน
- core team ระบุว่า MeshCore อย่างเป็นทางการ มีเพียงแหล่งเดียวคือ GitHub repository ที่กำหนดไว้เป็น single source of truth และจะเดินหน้าพัฒนาเฟิร์มแวร์ ปล่อยแอป เอกสารเทคนิค และการพูดคุยกับนักพัฒนาต่อไปโดยมี meshcore.io เป็นฐานใหม่
- หลังเริ่มโครงการในเดือนมกราคม 2025 ก็มี โหนดมากกว่า 38,000 โหนด บน Map อย่างเป็นทางการ และมี ผู้ใช้งานแอปแบบ active มากกว่า 100,000 คน บน App อย่างเป็นทางการ ทำให้การแยกให้ชัดเจนว่าอะไรคือพื้นที่ข้อมูลทางการและใครเป็นผู้ดำเนินงานยิ่งสำคัญขึ้น
เบื้องหลังการแยกทาง
- ตั้งแต่เริ่มโครงการ ทีมพัฒนา MeshCore ได้ออกรุ่น MeshCore Companion, Repeater และเฟิร์มแวร์ Room Server ไปแล้วมากกว่า 85 รุ่น และรองรับฮาร์ดแวร์หลากหลายกว่า 75 แบบ
- ทีมระบุว่าตนเองระมัดระวังกับโค้ดที่สร้างโดย AIมาโดยตลอด แต่ Andy Kirby เริ่มทำงานอย่างอิสระโดยใช้ Claude Code อย่างกว้างขวาง และขยายขอบเขตงานไปทั่วทั้ง ecosystem ของ MeshCore ตั้งแต่ standalone device, แอปมือถือ, web flasher ไปจนถึงเครื่องมือ web config
- มีการระบุว่า Andy Kirby ปกปิดกับทีมว่างานส่วนใหญ่เหล่านั้นเป็นงานแบบ vibe coded
- ทีมได้จัดแบบสำรวจใน Discord ของ MeshCore ในหัวข้อ AI และความไว้วางใจ แต่ในเนื้อหาไม่ได้ให้ตัวเลขหรือผลลัพธ์เชิงรายละเอียดของแบบสำรวจเป็นข้อความ
- จุดที่ทำให้ความขัดแย้งปะทุอย่างจริงจังคือ มีการระบุว่า Andy ได้ยื่นขอ เครื่องหมายการค้า MeshCore ลงวันที่ 29 มีนาคม และไม่ได้แจ้งทีม
- ทีมพยายามหารือเรื่องเจตนาของเขา แต่การสนทนาล้มเหลว และขณะนี้อยู่ในภาวะที่ไม่สามารถติดต่อกับ Andy ได้
- ทีมระบุว่าพยายามแก้ปัญหานี้มาตลอดหลายเดือนที่ผ่านมา และสำหรับทีมที่ทำงานกับโครงการนี้มายาวนาน เหตุการณ์นี้รุนแรงถึงขั้นให้ความรู้สึกเหมือนคนในทีมไปจับมือกับหุ่นยนต์และทนายความ
MeshCore อย่างเป็นทางการ
- ประเด็นหลักที่กำลังขัดแย้งกันในตอนนี้คือ สิทธิในการใช้คำว่า ‘official’ โดย Andy ยืนยันอย่างหนักแน่นว่าเขาเป็นเจ้าของแบรนด์ และใช้คำนี้อย่างจริงจังกับสายผลิตภัณฑ์ MeshOS
- ทีมระบุว่า MeshCore อย่างเป็นทางการ ที่แท้จริงมีเพียง GitHub repository เท่านั้น
- repository ดังกล่าวทำหน้าที่เป็น source of truth ในการตัดสินว่าอะไรคือ MeshCore
- Andy ไม่เคยมีส่วนร่วมกับ repository นั้นเลยแม้แต่ครั้งเดียว
- หลังการแยกภายใน ทีมได้เปิด meshcore.io ขึ้นใหม่ เพราะ Andy ควบคุมทั้ง meshcore.co.uk และ Discord server เดิมอยู่ ทำให้แทบไม่มีทางเลือกอื่น
- หลังจากเปิดเว็บไซต์ใหม่ Andy ก็ใช้ Claude เพื่อคัดลอกแม้กระทั่ง look and feel ของเว็บดังกล่าว และคำขอให้หยุดก็ไม่ได้รับการตอบสนอง
การเติบโตของโครงการ
- MeshCore เริ่มต้นในเดือนมกราคม 2025 และเติบโตอย่างรวดเร็วมาก
- ณ เวลาที่เขียนบทความนี้ MeshCore Map อย่างเป็นทางการแสดง โหนดมากกว่า 38,000 โหนด ทั่วโลก และ MeshCore App อย่างเป็นทางการมี ผู้ใช้งานแบบ active มากกว่า 100,000 คน ทั้งบน Android และ iOS
- ยิ่งโครงการมีขนาดใหญ่ขึ้น ความสำคัญของพื้นที่ข้อมูลอย่างเป็นทางการที่ core team จัดเตรียมไว้ก็ยิ่งมากขึ้น
- ช่วงหลังยังมีการขยายตัวของ เว็บไซต์ MeshCore ที่อิงตามประเทศและชุมชนเมชในแต่ละพื้นที่ โดยยกตัวอย่างไว้ดังนี้
- Andy Kirby เคยมีบทบาทสำคัญในการโปรโมต MeshCore ผ่าน YouTube ส่วนตัว แต่ตอนนี้หันไปโฟกัสการโปรโมตผลิตภัณฑ์ของตนเอง
แนวทางการดำเนินงานต่อจากนี้
- core team จะเดินหน้าต่อโดยมี meshcore.io เป็นศูนย์กลางสำหรับ การพัฒนาฟีเจอร์เฟิร์มแวร์, การแก้บั๊ก, การจัดการ PR และการพูดคุยกับนักพัฒนา
- changelog ของเฟิร์มแวร์และแอปรุ่นใหม่ บทความบล็อก และเอกสารทางเทคนิค จะเผยแพร่ผ่านช่องทางต่อไปนี้
- ยังมีการเปิดเผยรายชื่อผู้มีส่วนร่วมในบล็อกและบทบาทของแต่ละคนด้วย
- Scott เป็นผู้ก่อตั้งโครงการและ lead firmware engineer และยังเป็นผู้พัฒนา Ripple firmware ด้วย
- Recrof เป็นผู้พัฒนา MeshCore Map อย่างเป็นทางการและดูแล Firmware Flasher พร้อมแบ่งปันมุมมองเกี่ยวกับการพัฒนา MeshCore Map ในช่วงแรก
- Liam Cottle เป็นผู้พัฒนา MeshCore App อย่างเป็นทางการ และมีแผนจะเผยแพร่คู่มือเริ่มต้นใช้งาน MeshCore App
- FDLamotte ดูแลงานเครื่องมือ Python สำหรับ MeshCore และงานแยกเฟิร์มแวร์ STM32
- Oltaco รับผิดชอบงาน OTA Fix bootloader ใหม่เพื่อเพิ่มความน่าเชื่อถือของการอัปเดตเฟิร์มแวร์
core team
- ปัจจุบันทีม MeshCore ประกอบด้วย Scott, Liam, Recrof, FDLamotte และ Oltaco
- ทีมนี้ระบุว่าจะยังคงเดินหน้าการออกแบบและพัฒนาคุณภาพสูงต่อไปบนพื้นฐานของซอฟต์แวร์ที่มนุษย์เขียนขึ้นโดยตรง
ฐานปฏิบัติการใหม่
- จากนี้ไป การปล่อยรุ่นอย่างเป็นทางการ เอกสารทางเทคนิค และการพูดคุยกับชุมชน จะดำเนินไปโดยมีเว็บไซต์ใหม่นี้เป็นศูนย์กลาง
- พร้อมกับเว็บไซต์ใหม่ ยังมีการเริ่มต้น Discord server ใหม่ ด้วย
- ในพื้นที่นี้ ผู้ใช้สามารถสื่อสารกับนักพัฒนา MeshCore ได้โดยตรง รับความช่วยเหลือเกี่ยวกับโครงการ และมีส่วนร่วมกับอนาคตของ MeshCore
- ช่องทางทางการที่เกี่ยวข้องมีดังนี้
- Official Website: https://meshcore.io
- Latest Updates: https://blog.meshcore.io
- Technical Docs: https://docs.meshcore.io
- Official GitHub: https://github.com/meshcore-dev/MeshCore
- Reddit: https://reddit.com/r/meshcore
- Facebook: https://facebook.com/groups/meshcore
- Discord: https://meshcore.gg
1 ความคิดเห็น
ความเห็นจาก Hacker News
ถ้ายังไม่เคยลอง ขอแนะนำให้ไปดู Reticulum อย่างจริงจัง
โปรเจ็กต์หลักดูเหมือนว่าตอนนี้ต้องการผู้ดูแลคนใหม่ และแม้ว่านักพัฒนาหลักจะมีจุดยืนที่ค่อนข้างแรงอยู่บ้าง แต่การออกแบบ ชั้นโปรโตคอลเครือข่ายแบบกระจายศูนย์ นั้นขัดเกลามาได้ดีมาก
แอปเดสก์ท็อปทำงานผ่านอินเทอร์เน็ต (IP) หรือการเชื่อมต่อ USB ของบอร์ด LoRa ที่มีอยู่เดิม และเมื่อไม่นานมานี้ผมซื้อ https://lilygo.cc/products/t-echo-lilygo มาลงเฟิร์มแวร์โอเพนซอร์สแล้วลองใช้งาน พบว่าประสบการณ์ทั้งการต่อ USB เข้ากับเดสก์ท็อปหรือเชื่อมต่อผ่าน Bluetooth กับ https://github.com/torlando-tech/columba นั้นดีมาก
ด้วยแอปนี้ Reticulum ให้ความรู้สึกเหมือนเป็น พลเมืองชั้นหนึ่ง ในแง่การรองรับการส่งข้อความ และแม้จะมีข้อจำกัด แต่ก็ส่งไฟล์หรือรูปภาพได้ด้วย
เพราะมันทำงานในระดับเครือข่าย คุณจึงสามารถสร้างแอปของตัวเองบน Reticulum ได้โดยตรง
สักวันคนก็คงจะตระหนักว่า LoRa ไม่มีทางตามความต้องการด้านแบนด์วิดท์และความเร็วที่เกินกว่าการส่งข้อความข้อความล้วนได้
ถึงอย่างนั้น ผมก็เคยลอง โทรเสียงแบบเรียลไทม์ ผ่าน Reticulum LoRa แบบ 1-hop แล้ว มันทำงานได้โอเคกว่าที่คิด
วิกิสำหรับเริ่มต้นอยู่ที่นี่: https://reticulum.miraheze.org/wiki/Welcome
ถ้ามองจากฝั่งคนที่อยากทำแค่แอป ประสบการณ์พัฒนานั้นน่าหงุดหงิดพอสมควร และถึงแนวคิดจะเท่มาก แต่ก็มีหลุมพรางที่ฉุดรั้งเยอะเกินไปจนดูไม่ยั่งยืนสำหรับการ bootstrap
โดยเฉพาะตอนที่พยายามพอร์ตสแตกเป็น Rust no-std เพื่อให้ไปรันบนอุปกรณ์ nrf52 LoRA และให้แพ็กเก็ต reticulum วิ่งบนเครือข่าย MeshCore เดิม แค่จะตรวจสอบว่าแพ็กเก็ตที่ผมสร้างมาถูกต้องไหมก็เหมือนฝันร้ายแล้ว
เห็นแต่ testbed เล็ก ๆ ตลอด
และก็สงสัยว่านั่นสำคัญจริงไหม
ไม่เข้าใจว่าทำไม โปรเจ็กต์ mesh ถึงเข้มงวดกับการบังคับใช้เครื่องหมายการค้าเกินเหตุแบบนี้
Meshtastic ก็คล้ายกัน และหนึ่งในเหตุผลที่ทำให้ผมหันมาสนใจ MeshCore ก็เพราะอ่านนโยบายเครื่องหมายการค้าของ Meshtastic แล้วรู้สึกว่ามันเกินไปมาก
การแบ่งปันแบบเสรีและไร้ข้อจำกัดไม่ใช่ค่าปริยายของโลก แต่กลับเป็นสิ่งที่ค่อนข้างพิเศษมากกว่า
ตอนนี้มันดูเหมือนเป็นกรณีที่มีคนคนเดียวไปจดทะเบียนเครื่องหมายการค้าในสหราชอาณาจักรโดยไม่ได้รับความเห็นชอบจากสมาชิกทีมคนอื่น ๆ และยังไม่ใช่กรณีที่กำลังไล่เล่นงานใครจริง ๆ
MeshCore มีผู้ใช้เกิน 100,000 คนแล้ว และรีพีทเตอร์ก็ผุดขึ้นทั่วโลกเหมือนวัชพืช แรงจูงใจที่จะ monetize ตรงนี้จึงสูงมาก
โดยเฉพาะคนที่พยายามจะ monetize ตรงนี้ก็มาจากฝั่งการตลาด ไม่ใช่ฝั่งพัฒนาเฟิร์มแวร์หรือแอป
เพียงแต่ดูเหมือนเขาไม่อยากให้งานของตัวเองไปมีส่วนกับ เครือข่ายสังหาร AI ที่หยุดไม่ได้
ถ้าการยื่นขอเครื่องหมายการค้าเป็นเรื่องจริง นั่นก็เป็นพฤติกรรมที่เป็นปฏิปักษ์และแย่มากแน่นอน แต่ผมจะไม่โกรธใครเพียงเพราะเขาใช้ Claude Code
ผมใช้ MeshCore จริงและรันรีพีทเตอร์หลายตัว แต่ไม่ได้สนใจเรื่อง AI-assisted coding มากนัก
เพียงแต่คิดว่าควรเปิดเผยเรื่องนี้ โดยเฉพาะถ้าเป็นซอฟต์แวร์ปิดซอร์ส
ความพยายามจะยึดระบบนิเวศผ่านเครื่องหมายการค้าดูบ้าพอสมควร และก็ยังติดใจด้วยว่า Andy ไม่ได้มีส่วนร่วมกับโปรเจ็กต์บน GitHub เอง แต่กลับทำแต่ส่วนต่อเติมเชิงพาณิชย์ส่วนตัว
ขณะเดียวกันก็ดูเหมือนทีมหลักของ MeshCore จะพยายามเสริม narrative ให้แรงขึ้นด้วยอคติต่อต้าน AI เช่นกัน
จริง ๆ แล้วผม สนับสนุน ที่เอาเรื่องนี้ออกมาพูดอย่างเปิดเผย
ใครก็ตามที่บอกว่าตัวเองรีวิวโค้ดกาก ๆ 1,000 บรรทัดที่ AI พ่นออกมาได้ครบถ้วนจริง ๆ กำลังหลอกตัวเองหรือหลอกคนอื่น และก็น่าจะไม่เคยรีวิวโค้ดขนาดใหญ่จริง ๆ มาก่อน
การอ่านข้อความ 1,000 บรรทัดกับการวิเคราะห์ผลกระทบด้านความซับซ้อนของโค้ดและ edge case นั้นเป็นคนละเรื่องกันโดยสิ้นเชิง และการรีวิวแบบองค์รวมเช่นนั้นอาจกินเวลาหลายวัน
แม้แต่ PR แค่ 100 บรรทัดยังใช้เวลาหลายชั่วโมงได้ แต่คนกลับปล่อยผ่านด้วยท่าทีแบบ “ผมตรวจหมดแล้ว” จึงทำให้ 0-day และการรั่วไหลมีมากขึ้นเรื่อย ๆ
เพราะงั้นผมถึงไม่มีทางเชื่อผลลัพธ์แนว “You are absolutely correct, apologies for the oversight, here's a revised version:”
ผมลองเล่นทั้ง MeshCore และ Meshtastic มาบ้าง รู้สึกว่าสนุกดีแต่ก็ ถูก hype เกินไป มากโดยรวม
แนวคิดนี้ยิ่งพร่าเลือนเพราะมีคนสาย SHTF เข้ามาปะปน
ผมสนใจการใช้งานด้านเครือข่ายเซนเซอร์ แต่บทสนทนาจริง ๆ ส่วนใหญ่กลับเป็นเรื่องของคนที่หมกมุ่นกับการส่งข้อความสั้น ๆ แบบ Hello World ไปมา ขณะที่กลับไม่ค่อยเห็นว่าหากเกิดสถานการณ์ SHTF จริง เครือข่ายแบบนี้จะทำงานได้แย่แค่ไหน
แอปมือถือทั้งสองตัวค่อนข้าง หยาบ ๆ และ Meshtastic ยิ่งน่าหงุดหงิดเพราะทีม UI ฝั่ง Android กับ Apple เหมือนไม่ได้คุยกันเลย
ถ้าใช้งานคนละแพลตฟอร์ม การ onboarding ผู้ใช้ใหม่หรือช่วยตอบคำถามต่าง ๆ จะยากมาก
มันสร้างได้ถูกและสนุกก็จริง แต่ก็อยากให้มี message persistence ที่ดีกว่านี้ อย่างน้อยเพื่อให้ข้อความไม่หายง่าย ๆ
แต่ถ้าเป็นสถานการณ์จริงจังที่ชีวิตผมต้องพึ่ง เครือข่าย mesh แบบนี้ ผมคงไม่สบายใจมาก
มันยังไม่เสถียรพอจะมองเป็นวิธีที่เชื่อถือได้ แม้ก็อาจยังดีกว่าไม่มีอะไรเลย
การตั้งค่าอุปกรณ์ก็เป็นปัญหาเหมือนกัน ตอนที่พยายามลงสภาพแวดล้อมพัฒนาทั้งชุดบน raspberry pi 3 เพื่อให้ทำงานได้จากจุดเดียวในที่ไม่มีอินเทอร์เน็ต หน่วยความจำกลับหมดก่อนระหว่าง build เว็บแอปขนาดใหญ่ซึ่งเป็นอินเทอร์เฟซไคลเอนต์หลัก
การ ขาดมาตรฐาน น่าจะทำให้การใช้งานในสถานการณ์ SHTF จริงแย่ลงอย่างมาก
เช่น แม้แต่เหตุผลว่าทำไมควรใช้ meshstastic แทน meshcore ก็ยังไม่ชัดเจน และในสถานการณ์แบบนั้น LoRa เองก็ดูไม่น่าใช่สิ่งสำคัญอันดับต้น ๆ ในหัวผมด้วย
ใช้ Mikrotik base station กับ Chirpstack backend ได้เลย และคู่แบบนี้ผ่านการพิสูจน์ในเชิงพาณิชย์มาเยอะมาก
แอปไคลเอนต์ ตัวนี้ยังปิดซอร์สอยู่เหรอ
ถ้าเป็นผมก็ตัดออกตั้งแต่ตรงนั้นเลย และก็ไม่แปลกใจเลยที่มีเรื่องแบบนี้เกิดขึ้น
แถมคงไม่จบแค่นี้ด้วย
ตอนนี้ไม่จำเป็นต้องมี ไคลเอนต์ปิดซอร์ส อีกแล้ว
รองรับ MQTT, community observers, bots, webhooks ฯลฯ และเริ่มต้นจากความต้องการไคลเอนต์สำหรับใช้งานประจำวันซึ่งไม่ผูกติดกับวิทยุ แต่ตอนนี้มันพัฒนามาเป็นไคลเอนต์คู่หูสำหรับผู้ใช้ระดับ power user ที่ค่อนข้างสมบูรณ์แล้ว
Radio API กับเฟิร์มแวร์เปิดอยู่แล้ว มีตัวเลือกอื่นอีกมาก และบางครั้งก็เหนือกว่าตัวเลือกปิดซอร์สในด้านฟีเจอร์ด้วย ดังนั้นผมไม่ได้ต่อต้านการปิดซอร์สบางส่วนเพื่อหารายได้มากนัก
https://github.com/jkingsman/Remote-Terminal-for-MeshCore
เมชในพื้นที่ของเราก็เพิ่งทดลอง meshcore กันเมื่อสัปดาห์ก่อน แต่ตอนนี้ความสนใจของผมแทบหายไปแล้ว
ผมเคยเห็น Andy Kirby บน YouTube แล้วรู้สึกว่าวิดีโอเขาดูเร้าอารมณ์ เกินจริง และ clickbait มากเกินไป จนทำให้ผมเอาคนนี้ไปโยงกับการดูแลโปรเจ็กต์ และตั้งแต่นั้นมาก็หมดศรัทธากับ meshcore
เรื่องครั้งนี้ยิ่งให้ความรู้สึกว่าสัญชาตญาณตอนนั้นของผมถูกต้อง
จากที่เห็นตอนนี้ เว็บไซต์ .io ใช้โลโก้ “MESHCORE” ส่วนเว็บไซต์ .co.uk ใช้โลโก้ “MESHCORE(tm)”
[1]: https://meshcore.io
[2]: https://meshcore.co.uk
ผมไม่เคยใช้โปรเจ็กต์นี้และก็ไม่รู้จักคนที่เกี่ยวข้อง
แต่ก็น่าสนใจที่ทุกครั้งมีคนออกมาทำนองว่า “จะ เขียนใหม่ทั้งหมดด้วย AI” สุดท้ายก็มักกลายเป็น ตัวปัญหาใหญ่ อยู่บ่อยมาก
แน่นอนว่าอาจไม่ใช่กรณีของคนนี้คนเดียว และผมก็ไม่ได้รู้เบื้องหลังทั้งหมด จึงตัดสินไม่ได้ว่าควรเชื่อโพสต์นี้ทั้งชิ้นแค่ไหน
แต่จากตัวอย่างเล็ก ๆ ที่ผมเจอ สัดส่วนสัญญาณต่อสัญญาณรบกวนถือว่าค่อนข้างดี
ผมก็เป็น ham เหมือนกัน แต่ไม่ใช่ประเภทที่จะรีบไปแจ้ง FCC ทันทีเพราะละเมิดกฎครั้งเดียว แค่รู้สึกกังวลกับท่าทีที่เหมือนไม่รู้หรือไม่สนใจว่าทำไมถึงมีกฎนั้นอยู่
ก่อนอื่น ผมก็ไม่มั่นใจเต็มร้อยว่าการตีความกฎนั้นถูกต้องไหม แต่ถ้าสมมติว่าถูก คนอื่นในเธรดก็ดูเหมือนจะยอมรับว่าการตีความนั้นถูกต้องเหมือนกัน
ในสายตาผม มันเหมือนมีคนพูดว่า “เรากำลังละเมิดกฎ เราควรแก้” แล้วได้รับคำตอบว่า “ใน Seattle มันไม่สะดวกเลยไม่ทำ” และ “ที่ Boston ก็ใช้ไม่ได้เหมือนกันเลยทำไม่ได้”
นี่ไม่ใช่เรื่องที่จะทำเหมือนกฎระเบียบเป็นทางเลือกสมัครใจได้
คนที่ใช้ ทรัพยากรคลื่นความถี่สาธารณะ ส่วนใหญ่ปฏิบัติตามกฎหมาย และถ้าโปรเจ็กต์ทำงานได้แย่ลงเมื่อใช้อย่างถูกกฎหมาย ก็เป็นหน้าที่ของโปรเจ็กต์ที่ต้องแก้
ด้วยเหตุนี้ผมจึงพอเข้าใจได้ว่าทำไมเหล่า ham รุ่นเก่าถึงยิ่งอ่อนไหวกับเรื่องพวกนี้มากขึ้นเรื่อย ๆ
ผมโอเคกับการใช้ AI ในการพัฒนา และยังมองว่ามันสำคัญในโลกการพัฒนาสมัยใหม่ด้วย
เพียงแต่โค้ดจาก AI กับโค้ดที่มนุษย์เขียนเองนั้นต่างกันชัดเจน ดังนั้นเรื่องนี้ต้อง เปิดเผย อย่างแน่นอน
ถ้าส่วนใหญ่ของโปรเจ็กต์ถูกทำแบบ vibe coding มันก็ไม่ชัดแล้วว่าคนนั้นมีสิทธิ์ยอมรับ DCO จริงไหม และมีสิทธิ์แจกจ่ายภายใต้ LICENSE ของโค้ดเบสนั้นหรือไม่
แค่ทำความเข้าใจว่าโปรแกรมทำอะไรอยู่ก็ยากพอแล้ว แต่ถ้าเป็นโค้ดที่มนุษย์เขียน อย่างน้อยก็ยังพอเชื่อได้ว่ามี เจตนา บางอย่างอยู่
โค้ดที่สร้างด้วย AI นั้นเราไม่รู้ด้วยซ้ำว่าทำไมมันถึงอยู่ตรงนั้น
มีคนจำนวนมากเอาโปรเจ็กต์ที่ vibe coded ไปโพสต์ทั่วอินเทอร์เน็ต โดยตอนแรกก็ปิดบังข้อเท็จจริงนี้แล้วบอกง่าย ๆ ว่า “ฉันสร้างมันเอง” พร้อมรับคำชมทั้งหมดไป
แล้วพอภายหลังเปิดเผยว่าตัวเองไม่ได้เขียนอะไรเลยและไม่รู้ด้วยซ้ำว่ามันทำงานอย่างไร ก็ค่อยเปลี่ยนมาบอกว่า “ใช้ AI ก็ไม่เห็นเป็นไร”
แต่การใช้ AI เป็นเครื่องมือ กับการคัดลอกแปะทั้งดุ้นโดยไม่เข้าใจอะไรเลยแล้วห่อให้ดูเหมือนเป็นผลงานตัวเองนั้น เป็นคนละเรื่องกันโดยสิ้นเชิง