ข้อบกพร่องในการออกแบบของ Visual Studio Code (2022)
(ghuntley.com)- Visual Studio Code แยก ซอร์สโค้ดภายใต้ไลเซนส์ MIT ออกจาก ตัวผลิตภัณฑ์ภายใต้ไลเซนส์กรรมสิทธิ์ ที่ Microsoft แจกจ่าย ทำให้ฟอร์กอย่าง VSCodium และ OpenVSCode Server ขัดแย้งกับระบบนิเวศทางการ
- บิลด์ทางการถูกแจกจ่ายพร้อมการตั้งค่าเฉพาะของ Microsoft ใน
product.jsonเช่น telemetry, gallery, logo ขณะที่บิลด์จากชุมชนจะเป็นบิลด์แบบ “clean” แต่ไม่สามารถเชื่อมต่อกับ Visual Studio Code Marketplace ได้ - VSCodium และ OpenVSCode Server ลบหรือไม่รวม telemetry ของรีลีสทางการ แต่เพราะข้อจำกัดด้านการเก็บข้อมูลของส่วนขยายเองและการเข้าถึง Marketplace จึงยากที่จะมอบ ประสบการณ์แบบ VS Code ตามที่ผู้ใช้คาดหวังได้เหมือนเดิม
- เมื่อส่วนขยายและ language server ของ Microsoft ถูกผูกกับผลิตภัณฑ์และบริการทางการ เช่น Pylance, โรดแมปของส่วนขยาย C#, และไลเซนส์ของเครื่องมือ C/C++ บริการคู่แข่งอย่าง Gitpod, GitLab, Datacoves, OpenBB, และ Foam ก็ยากที่จะมอบความสามารถเดียวกันได้อย่างถูกกฎหมาย
- แม้จะมีการพูดถึง OpenVSX, การพัฒนาเครื่องมือภาษาแบบเปิด, และการสนับสนุนผู้ดูแลรักษาโอเพนซอร์สเป็นทางเลือก แต่เมื่อ Microsoft เปลี่ยนค่าเริ่มต้นไปสู่เครื่องมือปิด ชุมชนและผลิตภัณฑ์คู่แข่งก็ต้องแบกรับทั้งความต่างด้านฟังก์ชัน การตั้งค่า และข้อจำกัดทางกฎหมายไปพร้อมกัน
ซอร์สโค้ดเปิด แต่ตัวผลิตภัณฑ์ถูกแจกจ่ายต่างออกไป
- เมื่อผ่านไป 7 ปีหลังเปิดตัว Visual Studio Code ได้กลายเป็นตัวแก้ไขโค้ดมาตรฐานโดยพฤตินัยในงานพัฒนาซอฟต์แวร์
- Microsoft เปิดเผย ซอร์สโค้ด ของ Visual Studio Code ภายใต้ไลเซนส์ MIT แต่ ตัวผลิตภัณฑ์ Visual Studio Code ที่ผู้ใช้ดาวน์โหลดนั้นถูกแจกจ่ายภายใต้ ไลเซนส์กรรมสิทธิ์ แยกต่างหาก
- ตามคำอธิบายของผู้ดูแลรักษา Visual Studio Code บิลด์ของ Microsoft ทำโดยโคลนรีโพ
vscodeแล้วเขียนทับด้วยproduct.jsonเฉพาะของ Microsoft- ไฟล์นี้มีฟีเจอร์เฉพาะของ Microsoft เช่น telemetry, gallery, logo
- บิลด์ที่สร้างขึ้นด้วยวิธีนี้ถูกแจกจ่ายภายใต้ไลเซนส์ของ Microsoft
- บทความวิจารณ์ว่าการแยกส่วนนี้คือกลไกหลักที่ Microsoft ใช้ในการแบ่งแยกชุมชนโอเพนซอร์ส
ข้อจำกัดที่ VSCodium และ OpenVSCode Server ต้องเผชิญ
- VSCodium คือ ดิสทริบิวชันเดสก์ท็อป ภายใต้ไลเซนส์เสรีที่ขับเคลื่อนโดยชุมชน
- ติดตามโครงการ MIT ต้นน้ำแบบอัตโนมัติและสร้างไบนารีบิลด์
- ให้บิลด์ที่ลบ telemetry ซึ่งมีอยู่ในรีลีสทางการออกไป
product.jsonค่าเริ่มต้นไม่ได้ตั้งค่า endpoint ของ Microsoft จึงได้บิลด์แบบ “clean” ที่ไม่มีการปรับแต่งของ Microsoft
- แม้ VSCodium จะใช้โค้ดเบสเดียวกัน แต่ก็ไม่สามารถหยุดการเก็บข้อมูลทั้งหมดได้อย่างสมบูรณ์
- ส่วนขยายสามารถเก็บข้อมูลได้เองอย่างอิสระ จึงต้องระวังส่วนขยายที่ติดตั้ง
- OpenVSCode Server คือ ดิสทริบิวชันเซิร์ฟเวอร์ ภายใต้ไลเซนส์เสรีที่เป็นพื้นฐานของ Gitpod
- ติดตามโครงการ MIT ต้นน้ำแบบอัตโนมัติ
- มีการปรับแต่งแบบ overlay บางส่วนในสาขา
gp-code/main - ไม่รวม telemetry ของรีลีสทางการ
- ดิสทริบิวชันทั้งสองไม่สามารถเชื่อมต่อกับ Microsoft Visual Studio Code Marketplace ได้ และข้อจำกัดนี้นำไปสู่การตัดขาดจากระบบนิเวศ
การเปลี่ยนผ่านของ Microsoft สู่บริการเป็นศูนย์กลางและกลยุทธ์ด้านเครื่องมือพัฒนา
- Microsoft เริ่มเปลี่ยนวิธีส่งมอบซอฟต์แวร์ตั้งแต่ราว 9 ปีก่อน
- จากแนวทางที่ทีม QA เฉพาะทดสอบบิลด์ ไปสู่การพัฒนาแบบ sprint, rolling release และอาศัย feedback จาก telemetry ของ Insider Build
- ในช่วงเวลาเดียวกัน หลังการปรับโครงสร้างองค์กร Microsoft ก็เปลี่ยนตัวเองเป็นบริษัทด้านบริการ
- Azure เติบโตขึ้นเป็นคู่แข่งจริงจังของ AWS ในช่วงนี้
- จากมุมมองของผู้บริโภค ความเปลี่ยนแปลงที่ใหญ่ที่สุดคือฐานลูกค้าได้ย้ายจากผลิตภัณฑ์ติดตั้งแบบ on-premises ไปสู่ โมเดลการบริโภคบริการ ที่ Microsoft เป็นผู้ให้บริการ
- ในพื้นที่เครื่องมือพัฒนา IDE ที่ไม่ใช่แบบสมัครสมาชิกก็ถูกมองว่ากำลังลดบทบาทลง
- มีการยก Apple Xcode เป็นข้อยกเว้น เพราะมีแหล่งรายได้อื่นรองรับ
- Visual Studio Code ถูกวิจารณ์ว่าเป็นช่องทางพาผู้ใช้เข้าสู่โมเดลบริการสำหรับระบบนิเวศเครื่องมือพัฒนาแบบครบวงจร
- GitHub Codespaces ถูกอธิบายว่าเป็น white label ของบริการเดิมที่เชื่อมกับ Visual Studio Online, Microsoft Dev Box, และ Microsoft Azure DevTest Labs
GitHub Codespaces และ Microsoft DevDiv
- Microsoft เข้าซื้อ GitHub ในปี 2018 และเปิดตัว Visual Studio Online ในปี 2019
- ภายในนั้นมีองค์ประกอบที่ใช้โฮสต์ “codespace” บนเครื่องโลคัล
- หลังจากนั้นองค์ประกอบที่เกี่ยวข้องรวมถึงทีม Codespaces ก็ย้ายไปอยู่กับ GitHub
- GitHub Codespaces ถูกอธิบายว่าเป็นโครงการของ DevDiv ที่ไปอยู่ภายใต้ GitHub
- ในวันที่ Nat Friedman ลงจากตำแหน่ง CEO มีการแชร์อีเมลปรับโครงสร้างองค์กรภายใน Microsoft
- Julia Liuson ได้เลื่อนตำแหน่งเป็นประธานของ Microsoft Developer Division
- โครงสร้างเปลี่ยนเป็นให้ Thomas Dohmke ซีอีโอของ GitHub รายงานต่อ Julia Liuson
- Developer Division ครอบคลุม Visual Studio, Visual Studio Code, .NET, C#, TypeScript, OpenJDK, Azure developer SDK, Azure App Services, Functions, Logic Apps, API Management, Dapr, Redis Cache, Spring Cloud และอื่น ๆ
- ตามอีเมลดังกล่าว Visual Studio และ Visual Studio Code มี การใช้งานเพิ่มขึ้นมากกว่า 16 เท่า นับตั้งแต่ปี 2014
- ก่อนการเลื่อนตำแหน่ง Julia Liuson ถูกกล่าวถึงว่าเป็นผู้ดำเนินการเปลี่ยนแปลงนาทีสุดท้ายที่สร้างความแตกแยกในชุมชน .NET
- ตามคำอ้างอิงจาก The Verge แหล่งข่าวนิรนามภายใน Microsoft มองว่าการเปลี่ยนแปลงนี้เป็นการตัดสินใจที่ขับเคลื่อนด้วยธุรกิจ
โครงสร้างระบบนิเวศที่ทำงานเป็น “การตัดขาดที่ถูกออกแบบไว้”
- ผลิตภัณฑ์คู่แข่งอย่าง Gitpod อาจอยู่ภายในระบบนิเวศของ Visual Studio Code ได้ แต่ก็ถูกวิจารณ์ว่า Microsoft สามารถสร้างความเสี่ยงทางกฎหมายและแบ่งตลาดได้ทุกเมื่อ
- ซอร์สโค้ดโอเพนซอร์สของ Visual Studio Code ช่วยดึงผู้ใช้เข้ามา แต่ทำให้บริการคู่แข่งมอบประสบการณ์ลื่นไหลแบบ Visual Studio Code ทางการหรือ GitHub Codespaces ได้ยาก
- ไม่ใช่แค่ Gitpod เท่านั้น บริษัทอย่าง GitLab, Datacoves, OpenBB, และ Foam ที่พยายามแข่งขันกับ Microsoft หรือ GitHub บนฐานซอร์สโค้ด VS Code ก็เผชิญปัญหาเดียวกัน
- เมื่อพึ่งพาเครื่องมือของ Microsoft ก็มีการยกตัวอย่างพื้นที่ที่บริการคู่แข่งให้ได้ยากอย่างถูกกฎหมายดังนี้
- Microsoft .NET C#
- ตลาด Python แบบใช้งานทั่วไปและด้าน data science
- Project Jupyter และตลาด data science เกือบทั้งหมด
- C หรือ C++
- คาดว่า Java อาจเป็นเป้าหมายถัดไป หากเครื่องมือของ Microsoft เข้าใกล้ระดับของเครื่องมือจาก RedHat
- ตามดัชนี TIOBE มี 5 ภาษา/ระบบนิเวศจากรายการข้างต้นที่อยู่ในกลุ่มยอดนิยมที่สุด และบทความอธิบายว่า Microsoft ยังมีอำนาจควบคุมที่ใกล้เคียงต่อ JavaScript ซึ่งอยู่อันดับ 7 ผ่าน TypeScript
การเปลี่ยนค่าเริ่มต้นและปัญหาส่วนขยายแบบกรรมสิทธิ์
- Microsoft ถูกวิจารณ์ว่าสามารถรอให้ได้การยอมรับมากพอ แล้วเปลี่ยนให้ ข้อเสนอแบบกรรมสิทธิ์ กลายเป็นค่าเริ่มต้นผ่านการอัปเดตส่วนขยาย
- ในชุมชน Python มีการยกตัวอย่างว่า Microsoft Python Language Server แบบโอเพนซอร์สถูกยุติ และ Pylance แบบกรรมสิทธิ์กลายเป็นค่าเริ่มต้น
- ตามคำอ้างอิงจาก Visual Studio Magazine Microsoft ไม่ได้บังคับผู้ใช้ให้ย้าย แต่ตั้งให้ Pylance เป็นค่าเริ่มต้นใหม่
- ส่วนขยาย Python มียอดดาวน์โหลดราว 50 ล้านครั้ง บน VS Code Marketplace และถูกระบุว่ามากกว่าส่วนขยาย Jupyter ซึ่งเป็นอันดับถัดไปราว 2 เท่า
- ในชุมชน .NET ก็ถูกยกเป็นกรณีคล้ายกันว่าการเปลี่ยนค่าเริ่มต้นกำลังดำเนินอยู่ผ่านโรดแมปของส่วนขยาย C#
- แม้จะมีเครื่องมือทางเลือกอย่าง Open.NET ผู้ใช้ก็ยังต้องเชื่อมการตั้งค่าแยกตามแพลตฟอร์ม
- บนเดสก์ท็อปสามารถใส่
ms-dotnettools.csharpลงในdevcontainer.jsonได้ - แต่บน Gitpod ต้องใส่เครื่องมือเปิดที่ยังไม่มีอยู่จริงลงใน
gitpod.ymlทำให้เกิดความต่างลักษณะนี้
- บนเดสก์ท็อปสามารถใส่
- ภายในระบบนิเวศทางการของ Microsoft การตั้งค่า
devcontainer.jsonเดียวกันสามารถทำงานได้ตรงกันทั้งบน Visual Studio Code เดสก์ท็อปและ GitHub Codespaces จึงกลายเป็น แหล่งการตั้งค่าเดียว
ข้อจำกัดทางกฎหมายที่เกิดจากไลเซนส์
- มีคำเตือนว่า หาก Gitpod, GitLab, Datacoves, OpenBB, Foam และรายอื่นพยายามเลี่ยงข้อจำกัดแล้วนำส่วนขยายของ Microsoft อย่าง
ms-dotnettools.csharpไปให้บริการบนแพลตฟอร์มของตน อาจถูกฝ่ายกฎหมายของ Microsoft ดำเนินการอย่างจริงจัง - แม้ผู้ใช้ของสภาพแวดล้อมพัฒนาบนคลาวด์ที่เป็นคู่แข่งจะติดตั้งส่วนขยายดังกล่าวด้วยตนเอง ก็อาจเข้าข่ายละเมิดไลเซนส์
- ข้อความไลเซนส์ของส่วนขยาย Microsoft C/C++ ระบุว่าสามารถติดตั้งและใช้งานซอฟต์แวร์ได้เฉพาะร่วมกับ Microsoft Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, Team Foundation Server และผลิตภัณฑ์หรือบริการของ Microsoft ที่สืบเนื่องต่อจากนั้น
- เงื่อนไขนี้ทำให้ผลิตภัณฑ์ที่อิง VS Code แต่ไม่ใช่ดิสทริบิวชันทางการของ Microsoft มอบเครื่องมือภาษาของ Microsoft แบบที่ผู้ใช้คาดหวังได้ยาก
แนวทางรับมือ: OpenVSX และเครื่องมือภาษาแบบเปิด
- มีเสียงวิจารณ์ว่าอนาคตของเครื่องมือพัฒนาซอฟต์แวร์ที่กำลังก่อร่างขึ้นนั้นกำลังมุ่งไปสู่ความปิด
- แม้องค์ประกอบบางส่วนอาจตรงตามนิยามของ OSI แต่กราฟองค์ประกอบโดยรวมอาจไม่เป็นเช่นนั้น
- โอเพนซอร์สเดิมถูกอธิบายว่าเป็นอาวุธทางการเงินที่ใช้ถ่วงดุลซอฟต์แวร์ on-premises แบบกรรมสิทธิ์และรักษาความเปิดของรูปแบบไฟล์
- พร้อมกันนั้นก็เชื่อมโยงกับเหตุผลว่าทำไมการหารายได้จากโอเพนซอร์สจึงทำได้ยาก
- มีข้อเสนอว่าอาจต้องมีขบวนการใหม่เพื่อต่อสู้กับ proprietary SaaS และค้ำประกันเสรีภาพของการประมวลผลแบบเปิด หรือกลับไปทบทวนขบวนการซอฟต์แวร์เสรีในยุค 1970
- Open-Source Sustainability Fund ของ Gitpod คือหนึ่งในความพยายามตอบโต้ปัญหาการตัดขาดของระบบนิเวศนี้
- ในช่วง 1.5 ปี ได้มีการแจกจ่ายเงิน มากกว่า 32,000 ดอลลาร์สหรัฐ ให้กับผู้ดูแลรักษาเครื่องมือ language server ของชุมชนโอเพนซอร์ส
- Gitpod สร้าง Open VSX เพื่อช่วยแก้ปัญหา Marketplace ในระบบนิเวศโอเพนซอร์สของ Visual Studio Code บางส่วน และมอบให้ Eclipse Foundation
- ความท้าทายใหญ่ที่สุดต่อจากนี้คือการพัฒนา เครื่องมือภาษาแบบเปิด ในทุกพื้นที่ที่ Microsoft ได้ย้ายชุมชนไปสู่ language server แบบกรรมสิทธิ์แล้ว
เนื้อหาที่ถูกเพิ่มในภายหลังจากการแก้ไข
- การแก้ไขเมื่อ 31 สิงหาคม 2022 สรุปว่า Microsoft สร้าง VSCode แล้วจัดทำดิสทริบิวชันฟรีแบบกรรมสิทธิ์และส่วนขยายฟรีแบบกรรมสิทธิ์ ก่อนจะผูกประสบการณ์ที่ดีที่สุดของแต่ละภาษาเข้ากับ VSCode แบบปิด
- การแก้ไขเมื่อ 16 ธันวาคม 2022 เสริมว่า Web IDE และประสบการณ์พัฒนาระยะไกลของ GitLab ซึ่งอิงกับ VSCode MIT ก็ประสบปัญหาเดียวกัน
- การแก้ไขเมื่อ 13 ตุลาคม 2023 ระบุว่า Project IDX ของ Google ก็อิงกับ VSCode MIT เช่นกัน และความคาดหวังว่า Visual Studio Code LSP สำหรับ .NET และ Python จะทำงานได้เหมือนเดิมนั้นเป็นไปไม่ได้และไม่ถูกกฎหมาย
- การแก้ไขเมื่อ 24 เมษายน 2025 วิจารณ์ว่า Microsoft ตั้งใจทำลายระบบนิเวศ VSCode เพื่อสกัดการแข่งขันจาก AI coding assistant อย่าง Windsurf และ Cursor
- ในวันเดียวกันยังเชื่อมโยงการเปิดตัวผลิตภัณฑ์คู่แข่งของ Microsoft กับการจำกัดการเข้าถึงฟอร์ก VS Code ของส่วนขยาย C/C++
5 ความคิดเห็น
กำลังพิจารณาทางเลือกที่จะใช้ vim หรือ zed อยู่ครับ
ผมใช้เทอร์มินัลที่ตั้งค่า opacity ไว้
พอจะทราบวิธีลบสีพื้นหลังของ nvim ไหมครับ?
ถ้าหาเรื่องนี้เจอ ผมก็อยากลองใช้ nvim มาก ๆ เลย...
ถ้าคุณใช้เทอร์มินัล kitty ตั้งค่าให้ใช้สีพื้นหลังเดียวกันก็น่าจะทำให้ใช้ความโปร่งใสได้ครับ
หรือจะลองพิจารณาปลั๊กอินแบบนี้ดูก็ได้..
https://github.com/xiyaowong/transparent.nvim
ขอบคุณครับ/ค่ะ เดี๋ยวจะลองตรวจสอบดูครับ/ค่ะ
สำเร็จแล้ว ขอบคุณ ขอให้เป็นวันที่ดีครับ
ความคิดเห็นจาก Hacker News
ในบางแง่ สถานการณ์นี้อาจกลายเป็นโอกาสได้ ระบบนิเวศของ VSCode ค่อนข้างเปราะบางในหลายด้าน
cpptoolsมีด้านที่ยอดเยี่ยมอยู่บ้าง แต่ก็มักทำงานผิดพลาด แทบดีบักไม่ได้ และคาดหวังได้ยากว่าส่วนขยายอื่นจะดีกว่ามากปัญหาที่ใหญ่กว่าคือโมเดลความปลอดภัยอ่อนแอมาก โดยส่วนขยายไม่ได้ถูก sandbox และไคลเอนต์ที่เข้าถึง repository ระยะไกลก็ไม่ปลอดภัยอย่างยิ่งโดยการออกแบบ
เวลาดูเฉพาะโค้ดของบริษัท อาจไม่ต้องกังวลมากนักว่า repository จะโจมตีตัวมันเอง แต่แน่นอนว่าส่วนขยายอันตรายเป็นสิ่งที่ต้องกังวล และเราคุ้นเคยกับการเชื่อถือเครื่องมือพัฒนาง่ายเกินไป
LLM ไม่ควรถูกเชื่อถือเด็ดขาด และการให้สิทธิ์ LLM ที่อาจพยายามโจมตีผู้ใช้ให้เขียนลง repository โดยตรง หรือรันโค้ด JS ในบาง context ของ VSCode นั้นไม่ปลอดภัย
ในระบบนิเวศที่ดีกว่านี้ เครื่องมือที่เทียบเท่า
cpptoolsควรไม่มีสิทธิ์เข้าถึงอินเทอร์เน็ต จึงไม่มี telemetry และควรทำได้แค่อ่าน workspace, สร้างไฟล์แคชของตัวเอง และควบคุม UI ได้ระดับหนึ่งเท่านั้นHTTPS_PROXYถูกตั้งค่าเป็นอะไรส่วนขยาย SSH ก็เริ่ม server process สำหรับทุกไคลเอนต์ที่ผู้ใช้เชื่อมต่อ และดูเหมือนว่าการคงสถานะหลังตัดการเชื่อมต่อก็ไม่สม่ำเสมอ
สุดท้ายจึงต้องใช้เวลามากไปกับการช่วยแก้ปัญหาที่พวกเขาสร้างขึ้นเองจากการใช้ VSCode
ไม่มีพื้นที่ตรงกลางระหว่างสองทางเลือก คืออนุญาตให้เข้าถึงส่วนขยายทั้งหมดใน marketplace ได้อย่างเปิดกว้าง หรือปิดล็อกทั้งหมดและให้ติดตั้งส่วนขยายได้เฉพาะจากไฟล์ local เท่านั้น
อย่างหลังสร้างภาระในการดูแลรักษา VSCode ไม่น้อย
compile_commands.jsonได้ โดยเฉพาะใน CMake ซึ่งค่อนข้างง่าย และทำให้clangdเห็นไฟล์นี้ได้ ส่วนขยายclangdสำหรับผมนั้นดีกว่ามากEmacs ที่ผมใช้ก็แทบไม่มีกลไกป้องกัน supply chain attack และส่วนใหญ่ใช้ตัวรวบรวมส่วนขยายของชุมชนที่ดึงมาจาก Git repository โดยตรง
อย่างไรก็ตาม มีข้อดีเล็กน้อยมากคือผู้ใช้ Emacs น่าจะมีสัดส่วนที่เข้าไปดู source code ของส่วนขยายที่ดึงมาจริง ๆ สูงกว่ามาก
Microsoft พูดมาหลายปีว่า “ความปลอดภัยคือทุกอย่างและเป็นสิ่งสำคัญที่สุดในตอนนี้” แต่กลับไม่ได้ดูแลแม้แต่พื้นฐานเช่นนั้นให้กับกลุ่มผู้ใช้ที่ผลกระทบจะหนักที่สุดหากสิ่งอย่าง SSH key ถูกขโมย และเป็นกลุ่มนักพัฒนาที่น่าจะตระหนักเรื่องความปลอดภัยมากที่สุด นี่ดูแปลก
สถานการณ์ที่ผู้คนติดตั้งส่วนขยายแบบสุ่ม ๆ และ Visual Studio Code แนะนำส่วนขยายใดก็ได้ภายใต้ชื่อ “รองรับภาษา” ดูเลวร้ายกว่าที่คิดไว้มาก
มีเธรดดี ๆ เกี่ยวกับส่วนขยาย
cpptools: https://github.com/microsoft/vscode-cpptools/discussions/126...ผมไม่ได้ขุดลึกถึงกระบวนการ build จากซอร์ส แต่จากโพสต์นี้ดูเหมือนว่าจะเป็นไปไม่ได้เลย
ดูเหมือนเราจะต้องมีคำศัพท์ใหม่เพื่อบอกว่า codebase ใดมี ไลเซนส์ OSS และ dependency สำหรับ build ของมันก็มีไลเซนส์ OSS ด้วยหรือไม่
mainคือซอฟต์แวร์เสรี,non-freeคือซอฟต์แวร์ไม่เสรี, และcontribคือซอฟต์แวร์เสรีแต่พึ่งพาสิ่งที่อยู่นอกmainซึ่งโดยปกติเป็นซอฟต์แวร์ไม่เสรีผมไม่ได้ชอบคำว่า
contribเองนัก แต่การจัดหมวดหมู่นี้ดูสมเหตุสมผลทีเดียวF/OSS จำนวนมากบน Windows และ F/OSS เกือบทั้งหมดบน macOS มี dependency สำหรับ build แบบ proprietary เช่น MSVC, Xcode, Apple framework และ GUI toolkit แต่ตัวมันเองก็ยังอาจเป็น F/OSS ได้
แต่กรณีนี้ไม่ใช่ปัญหาแบบนั้น หากเป็นสถานการณ์ที่พนักงาน Microsoft ซึ่งดูเหมือนเป็น maintainer กล่าวว่า “ไลเซนส์ของเราห้ามใช้ส่วนขยายใน distribution ทางเลือกของ VS Code ด้วย และใช้ได้เฉพาะใน distribution ทางการที่ Microsoft สร้างเท่านั้น”
นี่ก็คือซอฟต์แวร์ proprietary เฉย ๆ
เสรีภาพ 0 ในนิยามซอฟต์แวร์เสรีคือเสรีภาพในการรันโปรแกรมเพื่อวัตถุประสงค์ใดก็ได้ และถ้า distribution จากบุคคลที่สามของ VSCode ไม่มีสิทธิ์ใช้ส่วนขยายแบบเดียวกับ distribution ทางการ หรือไม่มีสิทธิ์ใช้ร่วมกับส่วนขยายที่เข้ากันได้ ก็ไม่ผ่านเสรีภาพ 3 เช่นกัน ไม่ว่าไลเซนส์ของโค้ดบางส่วนจะเป็นอย่างไร
คำกล่าวว่า “ถ้าคุณพยายามแจกจ่ายไบนารี language server ต่อในฐานะสิ่งที่คุณจัดหาเอง ไลเซนส์ runtime ห้ามไว้” หมายความว่าไม่ผ่านเงื่อนไขข้อ 1 ของนิยามโอเพนซอร์ส คือเกณฑ์การแจกจ่ายต่อ และ VSCode ที่ไม่อนุญาตให้ distribution ที่แก้ไขแล้วมีสิทธิ์เท่ากับต้นฉบับ ก็ไม่ผ่านเงื่อนไขข้อ 3 คือเกณฑ์งานดัดแปลงเช่นกัน
VSCode และส่วนขยายนี้ต่างก็ไม่ใช่โอเพนซอร์ส แต่เป็นซอฟต์แวร์ proprietary ที่มีองค์ประกอบโอเพนซอร์สบางส่วนรวมอยู่
นิยามซอฟต์แวร์เสรี: https://www.gnu.org/philosophy/free-sw.html.en#four-freedoms
นิยามโอเพนซอร์ส: https://opensource.org/osd
สิ่งสำคัญอีกอย่างคือ นิยามเหล่านี้ไม่ใช่ความหมายตามพจนานุกรมทั่วไป แต่เป็นคำที่ถูกสร้างขึ้นภายในขบวนการเพื่อจุดประสงค์ทางสังคมและเทคนิคที่เฉพาะเจาะจง
frontend เดียวกันนี้ก็อยู่ใน Visual Studio IDE ด้วย
ผมเข้าใจว่ามีส่วนขยาย C++ ที่เป็นโอเพนซอร์สเต็มรูปแบบบนฐาน
clangdเป็นทางเลือก แต่ผมอาจเข้าใจผิดก็ได้“ซอฟต์แวร์เสรีที่ Microsoft แจกฟรียังเปิดไม่พอ” ฟังดูเป็นข้ออ้างที่ค่อนข้างแปลกแม้เทียบกับมาตรฐานยุคนี้
เมื่อก่อนถ้าพูดถึง “IDE ฟรี” ก็หมายถึง Eclipse หรือ Vim ที่ติดส่วนขยายไว้เต็มไปหมด
ดูแล้วไม่ใช่ว่า Microsoft ไปขัดขวางทางเลือกแบบเปิด แต่เป็นเพราะทางเลือกเหล่านั้นดีน้อยกว่าเท่านั้น และเมื่อใช้ซอฟต์แวร์ที่บริษัทซึ่งต้องจ่ายเงินเดือนพนักงานและต้องทำกำไรสร้างขึ้น มันก็มีด้านแบบนี้อยู่แล้ว
คนที่รู้สึกว่าตัวเองควรได้ซอร์สโค้ดของซอฟต์แวร์ชั้นยอดของ Microsoft โดยอัตโนมัติ ควรลองดูว่าโอเพนซอร์สแท้ ๆ ที่องค์กรไม่แสวงหากำไรอิสระดูแลนั้นหน้าตาเป็นอย่างไร
มันคงใช้งานได้ และอาจมีดีบักเกอร์จริง ๆ ด้วย แต่มีโอกาสสูงว่าอีกไม่นานก็จะอยากกลับมาใช้ของเดิม
ผู้คนมองซอฟต์แวร์ที่ได้มาฟรีเป็นเรื่องธรรมดาเกินไป ไม่นานมานี้เอง IDE ยังต้องจ่ายเงินหลายร้อยถึงหลายพันดอลลาร์ และถ้าอีกไม่กี่ปีต่อมาต้องการเวอร์ชันใหม่ ก็ต้องจ่ายค่าอัปเกรดด้วย
ส่วนขยาย VSIX ควรเป็นมาตรฐานเปิดในระดับหนึ่ง แต่ส่วนขยายของ Microsoft อย่าง Pylance จะตรวจจับว่ากำลังรันบน VS Code ที่ไม่ใช่บิลด์ของ Microsoft แล้วปฏิเสธการทำงานอย่างแข็งขัน
ประเด็นหลักใกล้เคียงกว่าว่านักพัฒนากำลังถูกหลอก และเป้าหมายของ Microsoft คือการค่อย ๆ ปิดส่วนที่จำเป็น
ต่อให้ทำฟีเจอร์ได้ทัดเทียมกันแล้ว ขั้นต่อไปก็ยังมีปัญหาด้านประสิทธิภาพเหลืออยู่ และก็ไม่รู้ว่าจะถูกแก้เมื่อไร
แนวคิดเรื่องซอฟต์แวร์โอเพนซอร์สนั้นดี แต่ซอฟต์แวร์ที่ดีที่สุดในปัจจุบันแทบจะต้องจ่ายเงินจึงจะได้มาเสมอ
ผมรู้ว่าการใช้ Emacs และ Vim มีต้นทุนอะไรบ้าง ต่อให้ในทางทฤษฎีฟรีโดยสมบูรณ์ แต่ในทางปฏิบัติมีต้นทุนเป็นเวลา ความอดทน และความทุ่มเท และผมรู้ว่าทางเลือกของผมทำให้ตัวผมเอง ชุมชน และอุตสาหกรรมได้ประโยชน์
ตอนที่เคยใช้ IntelliJ ผมก็รู้ชัดเจนว่า JetBrains ได้ประโยชน์อย่างไร เพราะผมจ่ายค่าไลเซนส์และต่ออายุทุกปี
แต่การคำนวณของ Microsoft คืออะไร? เขาให้เครื่องมือที่สวยงามและใช้ได้ดีขนาดนี้แบบ “ฟรี” ทั้งหมด แล้วในอนาคตผมจะต้องจ่ายอะไรแลกมา?
ยากที่จะเชื่อว่ายักษ์ใหญ่ที่มีมูลค่าตลาดเทียบเท่า GDP ของเยอรมนีจะทุ่มทรัพยากรมหาศาลทำตัวแก้ไขโค้ด “ฟรี” เพียงเพราะรักนักพัฒนา และนักพัฒนาก็ควรสงสัยไว้บ้างอย่างน้อยสักนิด
ผมมองว่าซอฟต์แวร์ของ Microsoft ใกล้เคียงกับกองขยะฝันร้ายมากกว่า
ประเด็นของบทความคือเมื่อซอฟต์แวร์ซอร์สปิดแสร้งทำเป็นโอเพนซอร์ส มันส่งผลกระทบแม้ต่อคนที่ไม่อยากใช้มันด้วย แต่คุณพลาดประเด็นนั้นไป
เช่น ผมไม่อยากใช้ทั้ง Azure DevOps หรือ GitHub Actions แต่เพราะองค์กรที่ผมทำงานด้วยต้องเอาโปรเจกต์ขึ้น GitHub ผมจึงถูกบังคับให้ใช้
ผลคือผมรู้สึกว่าแรงงานและความรู้ของผมถูกนำไปใช้ให้ Microsoft เอาเปรียบผู้ใช้
สิ่งปลอบใจเพียงอย่างเดียวคือมันเป็นงานที่ได้รับค่าจ้าง และโดยส่วนตัวผมไม่ใช้ GitHub และจะแนะนำคนอื่นให้ทำแบบเดียวกัน
ถ้าไม่เสนอโมเดลว่าจะทำให้สมเหตุสมผลได้อย่างไรกับงบประมาณราว 20 ล้านดอลลาร์ต่อปีสำหรับ พนักงานประจำมากกว่า 50 คน ที่สร้าง VS Code คำวิจารณ์นี้ก็ฟังเหมือน “น่าหงุดหงิดที่พวกเขาทำให้บริษัทของเราเอาผลงานวิศวกรรมของพวกเขาไปเปลี่ยนแค่หน้าตาผลิตภัณฑ์ แล้วขายถูกลงเพื่อทำกำไรโดยไม่ต้องมีต้นทุนพัฒนาเองได้ยากขึ้นนิดหน่อย”
หากเปิดเป็นโอเพนซอร์ส ก็จะได้ความเชื่อถือจากชุมชนอื่น ได้โค้ดฟรี การตรวจบั๊กฟรี รวมถึงการเขียนและสนับสนุนส่วนขยายนอกระบบนิเวศของ Microsoft และ Microsoft เองก็ยังใช้มันต่อไปได้
ดูไม่ใช่ปัญหาซับซ้อนอะไรนัก
ในอดีต นั่นเป็นเส้นทางที่รับประกันไปสู่ความล้าสมัย
แม้ไม่มีผลงานวิศวกรรมของพวกเขา ก็ยังมี Emacs, Vim, Clang, GCC, IDEA, Eclipse, Firefox ฯลฯ
ผมจะสนใจของขวัญเป็นผ้าห่มแสนใจกว้างจาก Microsoft ก็ต่อเมื่อมันไม่ได้มาพร้อมฝีดาษเท่านั้น
แค่การรายงานเรื่องนี้เหมือนเป็นเรื่องน่าตกใจครั้งใหญ่ก็น่าขำอยู่บ้าง มันชัดเจนตั้งแต่แรกแล้ว เพียงแต่ดูไม่คุ้มที่จะไปสู้ด้วยจึงไม่ได้สนใจ
ปัญหาที่นักพัฒนาไลเซนส์ BSD/MIT ถูกเอาเปรียบนั้นผมก็ไม่ค่อยสนใจพอ ๆ กับปัญหาที่ว่าการปิด telemetry อาจทำให้โมเดลธุรกิจของ Microsoft สั่นคลอน
ทุกคนเลือกทั้งที่รู้ว่ากำลังเข้าไปสู่อะไร โดยคิดว่า “พี่ใหญ่บริษัทใหญ่จะมองเห็นเราแน่” และสุดท้ายเขาก็มองเห็นจริง ๆ ก็ขอแสดงความยินดีด้วย
ผมจะไม่อัปโหลดอะไรด้วยไลเซนส์ที่อ่อนกว่า AGPL แต่ท้ายที่สุดก็มีหลายเรื่องที่ผมใส่ใจมากกว่าซอฟต์แวร์มากนัก
ยังพยายามทำความเข้าใจอยู่ว่าปัญหาคืออะไรกันแน่
ฟังดูเหมือนหมายความว่า Microsoft กำลังทำส่วนขยาย
cpptools/C++ ที่ดีกว่าอยู่ แต่คอมโพเนนต์ของ Microsoft จำนวนมากเป็นแบบปิด จึงไม่สามารถ build เวอร์ชัน OSS แบบสมบูรณ์ได้แล้วถ้าผู้ใช้รู้ว่าตนใช้ส่วนขยายแบบเนทีฟบนเว็บอินเทอร์เฟซใด ๆ ไม่ได้ นั่นกลายเป็นปัญหาของฝั่งคนทำเว็บอินเทอร์เฟซหรือเปล่า
ถ้าผู้คนอยากใช้ ฟรีแวร์ แทน OSS ก็อาจน่าผิดหวัง แต่ไม่แน่ใจว่านั่นเป็นปัญหาจริง ๆ หรือไม่
ถ้าจะมีคำตอบ ก็น่าจะเป็นการสื่อสารให้ชัดขึ้นว่าใครควรรับผิดชอบ
ผู้ให้บริการโอเพนซอร์สควรทำให้ชัดเจนยิ่งขึ้นว่าสิ่งที่ตนเสนอเป็นโอเพนซอร์สและเป็นระบบนิเวศแบบเปิด และแจ้งให้นักพัฒนารู้ว่าไม่ใช่ทุกส่วนขยายจะเป็นเช่นนั้น และส่วนขยายทางเลือกของ Microsoft ก็ไม่ใช่เช่นนั้น
หากโครงการส่วนขยายหลัก ๆ เห็นพ้องกัน ก็อาจใส่ข้อความในคำอธิบายบน marketplace ได้ว่า
vscode-cpptoolsไม่ได้ใช้ไลเซนส์ที่ OSI อนุมัติ มี binary blob จำนวนมากที่ยังไม่ได้รับการตรวจสอบ และ Microsoft ไม่อนุญาตให้แจกจ่ายซ้ำในการ build แบบโอเพนซอร์สเนทีฟหรือในการให้บริการ VSCode สำหรับเว็บเซอร์วิสทั้งในแง่กฎหมายและวัฒนธรรม Microsoft คงไม่อยากปิดกั้นการเข้าถึง marketplace เพียงเพราะบางโครงการ OSS เปรียบเทียบเงื่อนไขไลเซนส์ของตนกับเงื่อนไขของ Microsoft
ตอนนี้ Apple เองก็กำลังเจอคดีความเรื่อง marketplace อยู่ และ Microsoft ก็คงไม่อยากมีคดี marketplace หรือคดีต่อต้านการผูกขาดอีกคดีหนึ่ง
จากนั้นสร้าง API อีกตัวที่มีฟังก์ชัน public เพียงฟังก์ชันเดียว โดยฟังก์ชันนั้นแค่เรียก
externไปยังไบนารีของไลบรารีนั้นแล้วนำ API ตัวที่สองขึ้น GitHub ภายใต้ไลเซนส์ MIT และประกาศว่าเป็นโอเพนซอร์ส
หากมองกว้าง ๆ ถ้าฟังก์ชันการทำงานของซอฟต์แวร์ 100% อยู่ในไบนารีที่ compile แบบซอร์สปิด การเรียกสิ่งนั้นว่า โอเพนซอร์ส ควรถูกมองว่าเป็นการโฆษณาเกินจริงหรือไม่ นี่คือประเด็น
กล่าวอีกอย่างคือ เมื่อมีคนก้าวข้ามเจตนารมณ์ของโอเพนซอร์สด้วยเหตุผลเชิงแสวงหาประโยชน์ ใครจะเป็นคนขีดเส้นแบ่ง
ไม่รู้ว่าฟังก์ชันของ
cpptoolsปิดอยู่ 100% หรือไม่ แต่ในทางปฏิบัติ ภายใน repository ที่ระบุว่าใช้ไลเซนส์ MIT ยังมีไลเซนส์อื่นอีกสามฉบับที่ต้องยอมรับต้องอ่านเยอะเกินไปกว่าจะเข้าใจว่าประเด็นจริง ๆ คืออะไร และแนวคิดเรื่อง “ระบบนิเวศที่แตกแยก” ก็ถูกพูดถึงหลายครั้งโดยไม่มีการอธิบาย
คำอย่าง “กาบหอยแครงดักแมลง ที่ออกแบบมาเพื่อทำให้แตกแยก” นี่หมายความว่าอะไรกันแน่ก็ไม่รู้
VS Code เป็น IDE ที่ดาวน์โหลดจาก Microsoft มาใช้ฟรีได้ เป็นผลิตภัณฑ์ ไม่ใช่แพลตฟอร์มหรือระบบนิเวศโอเพนซอร์สวิเศษที่ Microsoft ไม่ได้ควบคุม
ทุกคนอยากสร้างบริการสำหรับนักพัฒนาแบบ “อเนกประสงค์” แต่ดูเหมือนจะไม่มีใครอยากสร้างหรือให้ทุน IDE เอง หรือไม่ก็มันยากเกินไป
นั่นไม่ใช่ความผิดของ Microsoft
ไม่ได้จะปกป้อง Microsoft แต่เขาให้โค้ดเบสขนาดใหญ่มาใช้ฟรี และสร้างผลิตภัณฑ์ที่ส่วนใหญ่ก็ใช้ฟรีอยู่บนโค้ดนั้น
ถ้า fork ก็แค่เข้าเซิร์ฟเวอร์ของ Microsoft ไม่ได้เท่านั้น ซึ่งผมว่าก็ยุติธรรมพอแล้ว
และ Monaco เป็น editor ที่ดีมากอย่างท่วมท้น frontend ต่าง ๆ จึงนำไปใช้ ก่อนหน้านี้เมื่อ CodeMirror หรือ Ace เป็นตัวเลือกที่ดีที่สุด ก็มีคนติดตั้งพวกนั้น
มากกว่าจะมีแผนแม่บทใหญ่โตอยู่เบื้องหลังการสร้าง Monaco ดูเหมือนเป็นการมองเห็นโอกาสว่า หากทำให้เป็นโปรเจกต์อิสระ ก็จะเปิดทางให้เว็บ UI จำนวนมากเกิดขึ้นได้มากกว่า
ประเด็นที่ว่า “อนาคตของเครื่องมือพัฒนาซอฟต์แวร์ที่จะถูกสร้างขึ้นต่อจากนี้ถูกปิดอย่างสมบูรณ์ แต่ผู้คนกลับมองว่ามันโอเคเพียงเพราะบางคอมโพเนนต์เข้าเกณฑ์นิยามของ OSI และมองข้ามภาพใหญ่” เป็นปัญหาใหญ่มาก
โดยเฉพาะบริษัทหลายแห่งที่ได้รับเงินลงทุนจาก VC ใช้ คำว่าโอเพนซอร์ส อย่างหลวมเกินไป จนทำให้ภาษา ความหมาย และแม้แต่จิตวิญญาณของขบวนการโอเพนซอร์สเปลี่ยนไปในทางที่แย่ลง
YC เองก็สนับสนุนบริษัทหลายแห่งที่อ้างว่าเป็นโอเพนซอร์ส แต่ไม่ได้ยึดถือจิตวิญญาณนั้นเลย
การถกเชิงศีลธรรมอย่างจิตวิญญาณหรือจริยธรรมไม่ได้เกี่ยวข้องมากนัก
สิ่งสำคัญคือไลเซนส์ซอฟต์แวร์เป็นเอกสารทางกฎหมาย และที่ที่การตีความของมันมีความหมายคือในศาล
ดูเหมือนไม่มีคดีความเกี่ยวกับ VS Code มากนัก และโดยทั่วไป Microsoft ก็มักจัดการส่วนนี้ไว้ค่อนข้างเรียบร้อย
ในความหมายทางกฎหมาย VS Code ดูปลอดภัยพอสมควร จริงอยู่ที่ส่วนขยายบางตัวไม่ได้ใช้ไลเซนส์ OSS หรือเป็นซอร์สปิดไปเลย แต่ถ้าไม่ชอบก็ไม่ต้องใช้
ยิ่งไปกว่านั้น ก็สร้างโอเพนซอร์สขึ้นมาแก้เองได้ โอเพนซอร์สไม่ใช่สิทธิ แต่เป็นสิทธิพิเศษที่ผู้สร้างมอบให้ตามดุลยพินิจ ไม่ใช่สิ่งที่เรียกร้องได้
VS Code เป็นผลิตภัณฑ์ซอร์สปิดที่มีคอมโพเนนต์ OSS จำนวนมาก และเพราะมีคอมโพเนนต์เหล่านั้นมาก จึงมี VS Codium ที่เป็น OSS เต็มรูปแบบอยู่ด้วย
คอมโพเนนต์ OSS เหล่านั้นจำนวนมากถูกใช้ในผลิตภัณฑ์อื่นด้วย และบางส่วนก็เป็นโอเพนซอร์สโดยสมบูรณ์
คุณค่าของระบบนิเวศ VS Code อยู่ที่การทำให้คอมโพเนนต์และระบบนิเวศของผลิตภัณฑ์เหล่านี้เติบโตได้
ไม่มีใครมีสิทธิ์ได้ VS Code ฟรี ๆ จริง ๆ แล้วไม่มีใครมีสิทธิ์ได้อะไรฟรีเลย
ทางเลือกคือจ่ายเงินให้ IDE เชิงพาณิชย์ที่บวมเทอะทะ
VS Code นั้นดี ใช้ได้อเนกประสงค์ ฟรี และเปิดกว้างพอที่จะ fork ได้
ผู้คนลืมไปว่านี่คือ ผลงานทางวิศวกรรมที่น่าทึ่ง พอลองดูโค้ดแล้ว มันไม่ใช่ระดับของที่ได้มาฟรี ๆ
ไม่ว่าจะ Microsoft หรือบริษัทไหน ก็ไม่ได้ติดหนี้อะไรใครให้ต้องให้ฟรี และความรู้สึกว่าตัวเองมีสิทธิ์แบบนี้ควรถูกควบคุม
ปัญหาคือเมื่อของที่ให้ฟรีถูกออกแบบมาให้พาคุณจมลงไปในบึงของความรับผิดทางกฎหมายและความรับผิดทางการเงินที่ไม่มีเพดาน
โดยเฉพาะกับบริการอย่าง VSCode ที่ไม่ใช่การซื้อครั้งเดียว แต่ต้องพึ่งพา Microsoft ต่อเนื่องผ่านส่วนขยายและอัปเดต และในความเป็นจริงก็ถูกออกแบบมาแบบนั้น
แทนที่จะทำตัวเลือกง่าย ๆ ให้จ่ายครั้งเดียวอย่างเรียบร้อยแล้วจบ กลับเลือกทางที่จะรีดเงินจำนวนคลุมเครือในระยะยาวตามระดับการต่อต้านของผู้ใช้
เรื่องโอเพนซอร์สก็เช่นกัน ผมพูดอยู่เสมอว่าผมค่อนข้างกังขากับการนำเฟรมเวิร์กที่ไม่มีเงินก้อนใหญ่หนุนหลังมาใช้
การพึ่งพาอารมณ์แปรปรวนของวิศวกรอัจฉริยะนิรนามบนอินเทอร์เน็ตนั้นเสี่ยง
Microsoft จะทำเงินจาก VSCode เหมือนที่ Google ทำเงินจาก Chrome เพียงแต่ไม่ตรงไปตรงมาเท่านั้น
ผมคิดว่า OSS นั้นยอดเยี่ยม แต่ไม่ใช่เหตุผลที่ผมใช้ VS Code
ผมใช้เพราะมันแก้ปัญหาที่ผมต้องการเอดิเตอร์ที่ใช้งานได้ ไม่ใช่สัตว์ประหลาดอย่าง Eclipse
ในพื้นที่นี้ก็มีตัวเลือกอื่นอย่าง Sublime แต่ VS Code ให้ความรู้สึกว่ารบกวนน้อยที่สุดเสมอ
ก่อนหน้านี้ก็มี Adobe Brackets ที่คล้ายกัน แต่ไม่รู้ทำไมถึงช้ามากและมีบั๊กเยอะ
ถ้าคุณเป็นผู้คลั่งไคล้ OSS ประเด็นที่บทความชี้ก็ถูกต้อง แต่ท้ายที่สุดซอร์สโค้ดก็มีอยู่ และถ้าต้องการก็สามารถดำเนินมาร์เก็ตเพลซของตัวเองได้
มันต้องใช้เวลาและเงิน แต่ถ้าเชื่อในแนวคิดนั้น ก็ไม่ควรพึ่งพาบริษัทเทคยักษ์ใหญ่ ควรลงทุนเอง
ถ้ามีส่วนขยายกรรมสิทธิ์ที่ไม่อาจมีได้ก็น่าเสียดาย แต่ใครสักคนก็อาจทำเวอร์ชัน OSS ขึ้นมาได้
โดยรวมแล้วผมเห็นด้วยกับบทความ แต่ไม่ได้มีภาพฝันว่า Microsoft ทำแบบนี้เพราะมีศรัทธาต่อโอเพนซอร์ส และในกรณีเลวร้ายที่สุดก็ยังมีทางเลือกอื่น จึงไม่เป็นไร