Zedless: ฟอร์กของ Zed ที่มุ่งเน้นความเป็นส่วนตัวและ local-first

• Zedless เป็นฟอร์กที่สร้างบนพื้นฐานของโอเพนซอร์สเอดิเตอร์ Zed โดยเน้น การปกป้องความเป็นส่วนตัว และสภาพแวดล้อมแบบ local-first
• Zedless ตัด การพึ่งพาคลาวด์ ออก และเปิดให้ผู้ใช้ ตั้งค่า โครงสร้างพื้นฐานตามสภาพแวดล้อมที่ต้องการได้เอง
• มีแผนจะลบ สปายแวร์และฟีเจอร์เทเลเมทรีระยะไกล ออกทั้งหมด
• ใช้นโยบาย ไม่ต้องโอนสิทธิ์ลิขสิทธิ์ของผู้ร่วมพัฒนา (No CLA) ทำให้นักพัฒนาทุกคนยังคงถือลิขสิทธิ์ของตนเอง
• ใช้เครื่องมือเพิ่มเติมเพื่อ ทำงานอัตโนมัติด้านการจัดการไลเซนส์ และให้สอดคล้องกับไลเซนส์โอเพนซอร์ส

---

แนะนำ Zedless

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

แผนการเปลี่ยนแปลงหลัก

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

การจัดการไลเซนส์และดีเพนเดนซี

• จำเป็นต้องมี ข้อมูลไลเซนส์ ของดีเพนเดนซีจากบุคคลที่สาม และใช้เครื่องมือ cargo-about เพื่อจุดประสงค์นี้
• ข้อควรระวัง
  • หากเกิดข้อผิดพลาด 'no license specified' ใน crate ที่คุณเขียนเอง จำเป็นต้องเพิ่ม publish = false ลงใน Cargo.toml
  • หากเกิดข้อผิดพลาดว่าไม่เป็นไปตามข้อกำหนดไลเซนส์ของแพ็กเกจที่เป็นดีเพนเดนซี ต้องตรวจสอบและระบุความเหมาะสมของไลเซนส์นั้นให้ชัดเจน
  • หาก cargo-about หาไลเซนส์ของดีเพนเดนซีไม่พบ ต้องเพิ่มรายการคำอธิบายที่ชัดเจนลงในสคริปต์

ความสำคัญของโครงการ

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

[GN⁺]

ความคิดเห็นจาก Hacker News

• ยินดีที่ได้เห็นความเคลื่อนไหวแบบนี้เกี่ยวกับ Zed ตอนนี้อาจยังไม่สมบูรณ์แบบแต่ก็น่าคาดหวังในอนาคต แต่ไม่ต้องการฟีเจอร์ AI และ telemetry เลย ช่วงหลังแทบไม่ได้ใช้ฟีเจอร์ AI ใน editor แล้ว ลองมาหลายครั้งทั้ง Copilot และอื่น ๆ ก็ยังไม่ค่อยน่าพอใจ รู้สึกว่าฟีเจอร์แบบนี้เหมาะกับตำแหน่งอื่นในกระบวนการพัฒนาซอฟต์แวร์มากกว่า เช่น code review หรือช่วยทำเอกสาร ยินดีจ่ายเงินให้กับบริการ sync settings หรือ subscription สำหรับการบำรุงรักษา แต่ไม่คิดว่าเครื่องมืออย่าง editor จะเป็นสินค้าที่ให้ ROI ตามที่ VC ต้องการได้ บางทีอีก 1 ปีอาจกลับไปใช้ Emacs กับ IntelliJ เหมือนเดิม
  • ดีใจที่ในที่สุดก็ได้เห็นความเห็นแบบนี้ ระหว่างที่หลายคนชม AI editor กันมากมาย ฉันกลับรู้สึกเหมือนตัวเองถูกทิ้งไว้ข้างหลังเพราะไม่เข้าใจว่าทำไมถึงตื่นเต้นกันขนาดนั้น ลองใช้ AI editor มาหลายตัวแต่ไม่เคยรู้สึกว่า workflow ดีขึ้นเลย สำหรับทีมเรา ปัญหาคอขวดไม่ได้อยู่ที่การเขียนโค้ด กลับเป็น code review ที่ไปได้ไม่เร็วพอ เลยกำลังพิจารณานำ AI code review มาใช้เพื่อลดภาระบางส่วน
  • ใน Zed สามารถปิดฟีเจอร์ AI ได้ บล็อก Zed: ปิดฟีเจอร์ AI
  • ถ้า Zed หยุดเพิ่มฟีเจอร์ AI แล้วหันไปโฟกัสที่การแก้ไขข้อความ น่าจะกลายเป็นผลิตภัณฑ์ที่ยอดเยี่ยมมากได้
  • ก็แค่ไม่ใช้หรือปิดฟีเจอร์ AI หรือ telemetry ไปเลยไม่ได้หรือ? มันไม่ได้ยัดเยียดต่อหน้าขนาดนั้น ส่วน telemetry ถ้าเป็นค่าเริ่มต้นแบบ OFF ก็คงดีกว่า แต่ถ้าปิดได้ง่ายก็โอเค
  • ความเห็นแนวว่าพร้อมจ่ายค่าสมาชิกรักษาระบบแบบนี้พบได้บ่อยใน HN หรือฟอรัมสายกี๊กหลายแห่ง แต่ในความเป็นจริงผู้ใช้แบบนี้มีน้อยเกินกว่าจะทำให้ผลิตภัณฑ์หรือบริษัทอยู่รอดอย่างยั่งยืนได้
• ฉันมีความรู้สึกปน ๆ กับการ fork อยู่เสมอ โดยเฉพาะ hard fork ยิ่งแล้วใหญ่ และ Zed เพิ่งเพิ่มความสามารถในการปิดฟีเจอร์ AI ทั้งหมดได้ อีกทั้ง telemetry ก็ opt-out ได้ เลยไม่แน่ใจว่าจำเป็นต้อง fork จริงหรือไม่ ดูจากรายการฟีเจอร์ที่เสนอ หลายอย่างก็พอจะ upstream กลับเข้าโครงการหลักเป็นฟีเจอร์พื้นฐานได้ หวังว่าจะเป็นแบบนั้น ยังจำได้ว่าครั้งก่อน ๆ อย่าง fork ของ Redis ทำให้ ecosystem แตกออกเป็นเสี่ยง ๆ
  • ฉันคิดว่าความจำเป็นของ fork มีไม่น้อย เพราะฝั่งนักพัฒนา Zed ก็เริ่มมีท่าทีชวนระแวงอยู่แล้ว เช่น ไม่ยอมให้ปิดฟีเจอร์บัญชี/การล็อกอินของ Zed ดังนั้นไม่เห็นเหตุผลว่าต้องกลัว ecosystem แยกตัว ตรงกันข้าม การมีเครื่องมือหลากหลายอยู่ร่วมกันน่าจะเป็นทางที่ดีและช่วยให้หลุดพ้นจาก lock-in กับ groupthink ได้
  • ต่อให้ telemetry เป็นแบบ opt-in ก็ยังรู้สึกไม่สบายใจอยู่ดี ฉันสลัดความรู้สึกที่ว่าซอฟต์แวร์อาจรายงานแม้กระทั่งไซซ์กางเกงในหรือเมนูอาหารเช้าของฉันออกจากหัวไม่ได้ และก็ไม่ไว้ใจการพึ่ง checkbox แค่ตัวเดียว อีกทั้งฟีเจอร์อื่น ๆ ที่ต้องคอยเลือก "ไม่ต้องการ" ทุกครั้งในแบบ opt-out ก็ยุ่งยาก โดยรวมแล้วฉันชอบความมินิมอลมากกว่า
  • ฉันมองว่าความจำเป็นในการ fork มีไม่มากอยู่แล้วเพราะ Zed เป็นโอเพนซอร์ส ดังนั้นถ้า Zed เปลี่ยนทุกฟีเจอร์ให้เป็นแบบ opt-in โดยปริยาย มูลค่าการมีอยู่ของ fork แบบนี้ก็จะหายไปเอง
  • การมีหลักประกันเพิ่มเติมว่าเมื่อเปิดใช้งานครั้งแรกจะไม่มีการอัปโหลดเบื้องหลังเด็ดขาดเป็นเรื่องที่ดี อ้างอิงไว้ก่อนว่าฉันก็รัน opensnitch ควบคู่ไปด้วยเพื่อป้องกันสองชั้น
• ข่าว fork แบบนี้ดูเร็วไปนิด โดยเฉพาะการโพสต์โดยไม่มี manifesto อธิบายว่าต้องการ fork ไปเพื่ออะไร ยิ่งทำให้รู้สึกแบบนั้น และพอเห็นคำว่า “no rugpulls” ก็เหมือนมีบางอย่างเกิดขึ้นกับ Zed ทั้งที่ผู้อ่าน HN ไม่ใช่ทุกคนที่จะตามประเด็นถกเถียงโอเพนซอร์สพวกนี้ตลอดเวลา
  • Contributor Agreement (CA) เป็นกลไกที่ทำให้ลิขสิทธิ์ทั้งหมดตกอยู่กับบริษัท เพื่อรองรับสิ่งที่เรียกว่า ‘license rugpull’ หรือการเปลี่ยนไลเซนส์ในภายหลัง การที่ Zed บังคับใช้ CA จึงก็หมายความว่าได้คำนึงถึงความเป็นไปได้ในการเปลี่ยนไลเซนส์ในอนาคตไว้แล้ว
  • เดิมที Zed ก็เป็นที่รู้จักดีว่าเป็นโปรเจกต์ที่เน้นคลาวด์และ AI ฉันคิดว่านี่แหละคือแรงจูงใจที่ชัดเจนของ fork นี้ มากกว่าจะเป็นดราม่าหรือเหตุการณ์ใหม่ที่เพิ่งเกิดขึ้นกะทันหัน มันคือเรื่องของทิศทางที่เห็นกันชัด ๆ และมีคนจำนวนมากไม่ชอบ
  • ฉันคิดว่า fork ครั้งนี้น่าจะถูกจุดชนวนจาก github discussion
  • Zed ได้รับเงินลงทุนจาก VC และสำหรับ fork ที่เน้น privacy/local-first แค่การขาดฟีเจอร์บางอย่างก็เพียงพอที่จะทำให้มันมีเหตุผลในตัวเองแล้ว แม้จะต้องตัดฟีเจอร์หลายอย่างที่ Zed ใช้เป็นจุดขายออกไป แต่จะเรียกว่า rugpull ก็ดูไม่ค่อยตรงนัก
• นี่คือรายการกระทู้ถกเถียงที่เกี่ยวข้อง
  • เหตุผลที่ Zed for Windows ล่าช้า
  • Sequoia ลงทุนใน Zed
• ฉันสงสัยว่า fork นี้จะนำไปสู่อะไรบ้าง ทำให้นึกถึงตอนที่ IO.js ซึ่งเป็น fork ของ node.js เคยเปลี่ยนทิศทางการพัฒนา node ไปได้เหมือนกัน และก็เตือนให้คิดได้ว่ายุคนี้ที่ telemetry กับ AI ถูกยัดเยียดไปทั่ว ยังมีกลุ่มนักพัฒนาที่อ่อนไหวกับเรื่องพวกนี้อยู่
• สิ่งที่ฉันอยากได้จาก Zed จริง ๆ คือการรองรับหลายหน้าต่าง ตอนนี้เอา agent panel หรือ panel อื่น ๆ ไปไว้บนจออีกจอไม่ได้ แนวทาง local-first ก็ดีอยู่หรอก แต่ฉันเองก็ใช้เครื่องมือ AI ด้วย ดังนั้นตอนนี้คงยังไม่ใช้ fork นี้ ถึงอย่างนั้นทิศทางแบบ no telemetry, no Contributor Agreement ก็เป็นสิ่งที่น่ายินดี ฉันชอบไอเดียของ fork นี้และขอให้โชคดี ฉันเคยใช้ Zed แบบไม่มีฟีเจอร์ AI ได้ดีมานานกว่าหนึ่งปีอยู่แล้ว ดังนั้นถ้าวันหนึ่งเบื่อ AI ขึ้นมา ก็อาจย้ายมาใช้ fork นี้ก็ได้
  • ฉันก็มีประสบการณ์เหมือนกัน เห็นการถกเถียงเรื่อง Zed มากมายเลยลองติดตั้งดู แต่พอเปิด panel แยกไม่ได้ หรือแม้แต่ตั้งค่าพื้นฐานที่ไม่มีการแก้มานานกว่าหนึ่งปีก็ยังเปลี่ยนไม่ได้ สุดท้ายก็ลบออกไปเลย
• ฉันรู้อยู่แล้วว่าสักวันต้องมี fork แบบนี้ออกมา จริง ๆ เคยคิดจะเริ่มเองด้วยซ้ำ แต่ยอมแพ้เพราะภาระการดูแลรักษาสูงเกินไป เคยนึกชื่อไว้ด้วยว่า zim (zed improved, เหมือน vim) เลยดีใจที่ได้เห็นโปรเจกต์นี้ออกมาสู่โลกจริง
• ความเห็นจากผู้เขียน: ต้นฉบับบน Lobsters, ไปยังโปรเจกต์ fork, ตอนนี้ฉันกำลังทยอยเอา telemetry, auto-update, การเชื่อมต่อ AI ที่ใช้ได้เฉพาะคลาวด์, dependency ของ node.js, การดาวน์โหลด language server อัตโนมัติ, การชวนซื้อของเพิ่ม และปุ่มล็อกอิน ที่ฉันมองว่าไม่จำเป็นออกไป เป้าหมายคือฟีเจอร์บนคลาวด์ของ Zeta edit ก็หากเป็นไปได้จะให้ self-host ได้เช่นกัน (เช่น รันการคาดเดา Zeta edit ผ่าน instance ของ llama.cpp หรือ vLLM) ในสถานะปัจจุบันมันใช้งานได้มากพอจะเป็น editor หลักได้แล้ว แต่เพราะมีการเปลี่ยนโค้ดเยอะ จึงมีขีดจำกัดในการหลบเลี่ยง merge conflict เลยกำลังทดลองแก้แบบอัตโนมัติในระดับ AST โดยใช้ tree-sitter และการทดลองนี้อาจพัฒนาไปเป็นเครื่องมือที่ช่วยสร้าง Zed เวอร์ชัน "ปรับให้เหมาะกับตัวเองและไม่ถูกทำให้ห่วยลง" ได้
  • ฉันอยากถามเรื่อง dependency ของ node.js ว่าผู้คนเริ่มเกลียด node กันตั้งแต่เมื่อไร และด้วยเหตุผลอะไร
• ฉันคิดว่า fork แบบนี้จริง ๆ แล้วอาจแค่ต้องมี pull request ที่ซ่อนฟีเจอร์ AI ของ Zed ไว้หลัง compile flag ก็พอ ไม่จำเป็นต้องเป็น ‘fork’ เต็มตัวด้วยซ้ำ แค่เปลี่ยนคำสั่ง build ก็น่าจะสร้าง Zed เวอร์ชันไม่มี AI จากโค้ดชุดเดียวกันได้ไม่ใช่หรือ