Khiếm khuyết trong thiết kế của Visual Studio Code (2022)

• Visual Studio Code tách biệt giữa mã nguồn theo giấy phép MIT và sản phẩm theo giấy phép độc quyền do Microsoft phân phối, khiến các fork như VSCodium và OpenVSCode Server xung đột với hệ sinh thái chính thức
• Bản build chính thức được phân phối với các thiết lập dành riêng cho Microsoft như telemetry, gallery, logo trong product.json, còn các bản build cộng đồng là bản build “clean” nhưng không thể kết nối với Visual Studio Code Marketplace
• VSCodium và OpenVSCode Server loại bỏ hoặc không bao gồm telemetry của bản phát hành chính thức, nhưng do việc thu thập dữ liệu của chính các extension và hạn chế truy cập Marketplace, chúng khó cung cấp nguyên vẹn trải nghiệm VS Code mà người dùng kỳ vọng
• Khi các extension và language server của Microsoft, như Pylance, lộ trình extension C#, hay giấy phép công cụ C/C++, bị gắn với sản phẩm và dịch vụ chính thức, các dịch vụ cạnh tranh như Gitpod, GitLab, Datacoves, OpenBB, Foam khó có thể cung cấp hợp pháp cùng chức năng
• OpenVSX, phát triển công cụ ngôn ngữ mở và hỗ trợ maintainer mã nguồn mở được nêu như các phương án thay thế, nhưng khi Microsoft chuyển mặc định sang công cụ độc quyền, cộng đồng và sản phẩm cạnh tranh phải cùng gánh khác biệt về tính năng, khác biệt cấu hình và ràng buộc pháp lý

---

Mã nguồn mở nhưng sản phẩm được phân phối theo cách khác

• Sau 7 năm ra mắt, Visual Studio Code đã trở thành trình soạn thảo gần như là tiêu chuẩn thực tế trong phát triển phần mềm
• Microsoft công bố mã nguồn của Visual Studio Code theo giấy phép MIT, nhưng sản phẩm Visual Studio Code mà người dùng tải xuống lại được phân phối theo một giấy phép độc quyền riêng
• Theo giải thích của maintainer Visual Studio Code, bản build của Microsoft được tạo bằng cách clone repository vscode rồi ghi đè product.json dành riêng cho Microsoft
  • Tệp này chứa các chức năng dành riêng cho Microsoft như telemetry, gallery, logo
  • Bản build được tạo theo cách này được phân phối theo giấy phép của Microsoft
• Trọng tâm phê phán của bài viết là sự phân tách này chính là cơ chế cốt lõi để Microsoft chia tách cộng đồng mã nguồn mở

Những giới hạn mà VSCodium và OpenVSCode Server phải đối mặt

• VSCodium là bản phân phối desktop theo giấy phép tự do, do cộng đồng dẫn dắt
  • Tự động bám theo dự án upstream MIT và tạo các bản build binary
  • Cung cấp bản build đã loại bỏ telemetry có trong bản phát hành chính thức
  • product.json mặc định không cấu hình endpoint của Microsoft, nên tạo ra bản build “clean” không có tùy biến của Microsoft
• Ngay cả VSCodium dùng cùng codebase cũng không thể chặn hoàn toàn mọi hoạt động thu thập dữ liệu
  • Extension có thể tự thu thập dữ liệu độc lập, nên cần cẩn trọng với các extension được cài đặt
• OpenVSCode Server là bản phân phối server theo giấy phép tự do, làm nền tảng cho Gitpod
  • Tự động bám theo dự án upstream MIT
  • Có một số tùy biến overlay trên nhánh gp-code/main
  • Không bao gồm telemetry của bản phát hành chính thức
• Cả hai bản phân phối đều không thể kết nối với Microsoft Visual Studio Code Marketplace, và hạn chế này dẫn tới sự đứt gãy hệ sinh thái

Sự chuyển dịch lấy dịch vụ làm trung tâm của Microsoft và chiến lược công cụ phát triển

• Microsoft bắt đầu thay đổi cách cung cấp phần mềm từ khoảng 9 năm trước
  • Chuyển từ mô hình đội QA chuyên trách kiểm thử bản build sang phát triển theo sprint, rolling release và phản hồi telemetry từ Insider Build
• Cùng thời kỳ đó, thông qua tái cơ cấu tổ chức, Microsoft chuyển thành một công ty dịch vụ
  • Trong giai đoạn này, Azure đã phát triển thành đối thủ thực chất của AWS
• Thay đổi lớn nhất từ góc nhìn người tiêu dùng là cơ sở khách hàng chuyển từ sản phẩm on-premise cài đặt cục bộ sang mô hình tiêu thụ dịch vụ do Microsoft cung cấp
• Trong lĩnh vực công cụ phát triển, các IDE không theo hình thức thuê bao cũng được xem là đang giảm dần
  • Các trường hợp có nguồn doanh thu khác, như Xcode của Apple, được nhắc đến như ngoại lệ
• Visual Studio Code bị phê phán là cửa ngõ đưa hệ sinh thái công cụ phát triển sang mô hình dịch vụ tiêu thụ end-to-end
  • GitHub Codespaces được mô tả là white label của các dịch vụ sẵn có liên quan tới Visual Studio Online, Microsoft Dev Box, Microsoft Azure DevTest Labs

GitHub Codespaces và Microsoft DevDiv

• Microsoft mua lại GitHub năm 2018 và công bố Visual Studio Online năm 2019
  • Dịch vụ này bao gồm một thành phần để host “codespace” cục bộ
  • Sau đó, các yếu tố liên quan, bao gồm đội Codespaces, được chuyển sang GitHub
• GitHub Codespaces được mô tả là một dự án DevDiv đã thuộc GitHub
• Vào ngày Nat Friedman rời vị trí CEO, một email tái cơ cấu tổ chức nội bộ của Microsoft được chia sẻ
  • Julia Liuson được thăng chức làm chủ tịch Microsoft Developer Division
  • Cơ cấu trở thành CEO GitHub Thomas Dohmke báo cáo cho Julia Liuson
  • Developer Division bao gồm 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, v.v.
• Theo email này, Visual Studio và Visual Studio Code đã ghi nhận mức tăng sử dụng hơn 16 lần kể từ năm 2014
• Julia Liuson được nhắc đến là người đã thực thi thay đổi vào phút chót khiến cộng đồng .NET bị chia tách trước khi được thăng chức
  • Theo trích dẫn từ The Verge, một nguồn tin ẩn danh nội bộ Microsoft xem thay đổi này là quyết định lấy kinh doanh làm trọng tâm

Cấu trúc hệ sinh thái vận hành như “sự đứt gãy được thiết kế”

• Các sản phẩm cạnh tranh như Gitpod có thể tồn tại trong hệ sinh thái Visual Studio Code, nhưng bị phê phán là Microsoft có thể tạo rủi ro pháp lý bất cứ lúc nào để chia cắt thị trường
• Mã nguồn mở của Visual Studio Code thu hút người dùng, nhưng khiến các dịch vụ cạnh tranh khó cung cấp trải nghiệm mượt mà như Visual Studio Code chính thức hay GitHub Codespaces
• Không chỉ Gitpod, các công ty muốn cạnh tranh với Microsoft hoặc GitHub dựa trên mã nguồn VS Code như GitLab, Datacoves, OpenBB, Foam cũng gặp vấn đề tương tự
• Khi phụ thuộc vào công cụ Microsoft, những lĩnh vực sau được nêu là các khu vực mà dịch vụ cạnh tranh khó cung cấp hợp pháp
  • Microsoft .NET C#
  • Thị trường Python mục đích chung và khoa học dữ liệu
  • Project Jupyter và phần lớn thị trường khoa học dữ liệu
  • C hoặc C++
  • Java được dự đoán có thể là mục tiêu tiếp theo nếu công cụ của Microsoft tiến gần tới mức của công cụ RedHat
• Theo chỉ số TIOBE, 5 trong số các ngôn ngữ và hệ sinh thái trên nằm trong nhóm phổ biến nhất, và Microsoft được mô tả là có mức kiểm soát gần với JavaScript, ngôn ngữ phổ biến thứ 7, thông qua TypeScript

Chuyển đổi mặc định và vấn đề extension độc quyền

• Microsoft bị phê phán là sau khi đạt đủ mức chấp nhận, họ có thể biến sản phẩm độc quyền thành mặc định thông qua cập nhật extension
• Trong cộng đồng Python, Microsoft Python Language Server mã nguồn mở đã bị ngừng và Pylance độc quyền trở thành mặc định
  • Theo trích dẫn từ Visual Studio Magazine, Microsoft không ép buộc người dùng chuyển đổi nhưng đặt Pylance làm mặc định mới
  • Extension Python ghi nhận khoảng 50 triệu lượt tải xuống trên VS Code Marketplace, được nhắc là khoảng gấp đôi extension Jupyter phổ biến tiếp theo
• Trong cộng đồng .NET, lộ trình extension C# cũng được nêu như một trường hợp đang diễn ra quá trình chuyển đổi mặc định tương tự
• Ngay cả khi các công cụ thay thế như Open.NET được tạo ra, người dùng vẫn phải liên kết riêng cấu hình cho từng nền tảng
  • Trên desktop có thể đưa ms-dotnettools.csharp vào devcontainer.json
  • Trên Gitpod thì phải đưa một công cụ mở chưa tồn tại vào gitpod.yml, tạo ra khác biệt kiểu như vậy
• Trong hệ sinh thái chính thức của Microsoft, cùng một thiết lập devcontainer.json trở thành nguồn cấu hình duy nhất hoạt động nguyên vẹn trên Visual Studio Code desktop và GitHub Codespaces

Ràng buộc pháp lý do giấy phép tạo ra

• Bài viết cảnh báo rằng nếu Gitpod, GitLab, Datacoves, OpenBB, Foam, v.v. lách hạn chế để cung cấp các extension Microsoft như ms-dotnettools.csharp trong dịch vụ của mình, họ có thể đối mặt với phản ứng pháp lý mạnh từ đội ngũ pháp lý Microsoft
• Ngay cả khi người dùng môi trường phát triển cloud cạnh tranh tự cài đặt extension đó, việc này cũng có thể vi phạm giấy phép
• Điều khoản giấy phép extension Microsoft C/C++ nêu rằng phần mềm chỉ có thể được cài đặt và sử dụng cùng Microsoft Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, Team Foundation Server và các sản phẩm, dịch vụ kế nhiệm của Microsoft
• Vì điều kiện này, các sản phẩm dựa trên VS Code nhưng không phải bản phân phối chính thức của Microsoft khó có thể cung cấp nguyên vẹn công cụ ngôn ngữ Microsoft mà người dùng kỳ vọng

Hướng ứng phó: OpenVSX và công cụ ngôn ngữ mở

• Có ý kiến phê phán rằng tương lai của các công cụ phát triển phần mềm đang được xây dựng hiện nay đang đi theo hướng khép kín
  • Ngay cả khi một số thành phần đáp ứng định nghĩa của OSI, toàn bộ đồ thị cấu hình có thể không như vậy
• Mã nguồn mở vốn được mô tả là một vũ khí tài chính để kiềm chế phần mềm on-premise độc quyền và duy trì tính mở của định dạng tệp
  • Đồng thời, điều này cũng liên quan tới lý do khó kiếm tiền từ mã nguồn mở
• Bài viết gợi ý rằng có thể cần một phong trào mới nhằm bảo đảm tính mở của tự do điện toán trước proprietary SaaS, hoặc xem xét lại phong trào phần mềm tự do thập niên 1970
• Open-Source Sustainability Fund của Gitpod là một trong những phản ứng trước vấn đề đứt gãy hệ sinh thái này
  • Trong 1,5 năm, hơn 32.000 USD đã được phân phối cho các maintainer công cụ language server của cộng đồng mã nguồn mở
• Gitpod đã tạo Open VSX và trao tặng cho Eclipse Foundation nhằm giải quyết một phần vấn đề Marketplace của hệ sinh thái mã nguồn mở Visual Studio Code
• Thách thức lớn nhất trong tương lai là phát triển công cụ ngôn ngữ mở ở từng lĩnh vực mà Microsoft đã dịch chuyển cộng đồng sang language server độc quyền

Nội dung được thêm trong các lần biên tập sau

• Bản chỉnh sửa ngày 31/8/2022 tóm tắt rằng Microsoft đã tạo VSCode, cung cấp bản phân phối miễn phí độc quyền và extension miễn phí độc quyền, rồi gói trải nghiệm tốt nhất theo từng ngôn ngữ vào VSCode ở dạng đóng
• Bản chỉnh sửa ngày 16/12/2022 bổ sung rằng Web IDE dựa trên VSCode MIT của GitLab và trải nghiệm phát triển từ xa cũng gặp cùng vấn đề
• Bản chỉnh sửa ngày 13/10/2023 nêu rằng Project IDX của Google cũng dựa trên VSCode MIT, và kỳ vọng Visual Studio Code LSP cho .NET và Python sẽ hoạt động nguyên vẹn là điều không thể và không hợp pháp
• Bản chỉnh sửa ngày 24/4/2025 phê phán rằng Microsoft đã cố ý phá vỡ hệ sinh thái VSCode để kìm hãm cạnh tranh từ các trợ lý lập trình AI như Windsurf và Cursor
  • Cùng ngày, bài viết liên hệ việc Microsoft ra mắt sản phẩm cạnh tranh với hạn chế truy cập của các fork VS Code vào extension C/C++

[unsure4000]

Tôi đang cân nhắc chuyển sang dùng vim hoặc zed.

Tôi đang dùng terminal có thiết lập độ trong suốt,
mọi người có biết cách bỏ màu nền của nvim không?
Chỉ cần tìm được cái này thì tôi rất muốn thử dùng nvim...

[siscof]

Nếu bạn dùng terminal kitty thì có lẽ chỉ cần đặt cùng màu nền là sẽ áp dụng được độ trong suốt.
Hoặc bạn cũng có thể cân nhắc plugin này..

https://github.com/xiyaowong/transparent.nvim

[unsure4000]

Cảm ơn bạn. Tôi sẽ tìm hiểu thử.

[unsure4000]

Đã thành công. Cảm ơn. Chúc bạn một ngày tốt lành.

[GN⁺]

Các ý kiến trên Hacker News

• Ở một khía cạnh nào đó, tình huống này cũng có thể là một cơ hội. Hệ sinh thái VSCode khá mong manh ở nhiều mặt
  cpptools có những điểm rất ấn tượng, nhưng thường xuyên hoạt động sai và trên thực tế gần như không thể debug; cũng khó kỳ vọng các extension khác tốt hơn đáng kể
  Vấn đề lớn hơn là mô hình bảo mật rất yếu: extension không được sandbox, và các client truy cập repository từ xa cũng cực kỳ không an toàn ngay từ thiết kế
  Khi chỉ xem code của công ty, bạn có thể bớt lo repository tự tấn công mình, nhưng extension độc hại thì đương nhiên vẫn phải lo, và chúng ta đã quá quen với việc dễ dàng tin tưởng công cụ phát triển
  Tuyệt đối không nên tin LLM; việc trao quyền cho một LLM — thứ có thể cố tấn công người dùng — được ghi trực tiếp vào repository hoặc chạy mã JS trong một số ngữ cảnh của VSCode là không an toàn
  Trong một hệ sinh thái tốt hơn, công cụ tương đương cpptools sẽ không có quyền truy cập Internet, nên cũng không có telemetry; nó chỉ nên có thể đọc workspace, tạo file cache của riêng nó và thao tác UI ở mức nhất định

  • VSCode về mặt thiết kế che khuất trạng thái thực tế của môi trường phát triển, nên khi giúp người dùng bị kẹt, nhiều lúc thậm chí không biết họ đang đăng nhập vào máy tính nào, file nằm ở đâu trong filesystem, đang dùng Python interpreter nào, hay HTTPS_PROXY được đặt thành gì
    Extension SSH cũng khởi chạy một server process cho mỗi client mà người dùng kết nối, và việc giữ trạng thái sau khi ngắt kết nối có vẻ không nhất quán
    Cuối cùng lại tốn rất nhiều thời gian giúp họ sửa những vấn đề do chính việc dùng VSCode tạo ra
  • Mô hình bảo mật của VSCode cũng là mối lo lớn với đội an ninh thông tin của chúng tôi
    Không có vùng trung gian giữa hai lựa chọn: cho phép truy cập mở tới mọi extension trên marketplace, hoặc khóa hoàn toàn và chỉ cho cài extension bằng file local
    Lựa chọn sau tạo gánh nặng đáng kể cho việc duy trì VSCode
  • Nếu bạn có hoặc có thể tạo compile_commands.json, đặc biệt việc này tương đối dễ với CMake, và có thể để clangd nhìn thấy nó, thì extension clangd với tôi tốt hơn nhiều
  • Nếu client truy cập repository từ xa về mặt thiết kế là cực kỳ không an toàn, tôi tò mò editor nào là tốt nhất về bảo mật extension bên thứ ba
    Emacs mà tôi dùng cũng không có nhiều cơ chế để chặn tấn công chuỗi cung ứng, và phần lớn dùng các bộ tổng hợp extension cộng đồng lấy trực tiếp từ Git repository
    Tuy vậy, có một lợi thế rất nhỏ là có lẽ tỷ lệ người dùng Emacs thực sự đọc mã nguồn của extension họ tải về sẽ cao hơn nhiều
  • Nếu đúng là extension không được sandbox thì khá ngạc nhiên
    Microsoft đã nói suốt nhiều năm rằng “bảo mật là tất cả và hiện là điều quan trọng nhất”, vậy mà lại không lo nổi cả điều cơ bản như thế cho nhóm người dùng chịu tác động lớn nhất khi những thứ như SSH key bị đánh cắp, đồng thời cũng là nhóm developer ý thức về bảo mật nhất, thì thật kỳ lạ
    Tình huống mọi người cài extension ngẫu nhiên, còn Visual Studio Code thì đề xuất extension tùy ý dưới danh nghĩa “hỗ trợ ngôn ngữ”, trông tệ hơn nhiều so với tôi nghĩ

• Có một thread hay liên quan đến extension cpptools: https://github.com/microsoft/vscode-cpptools/discussions/126...
  Tôi chưa đào sâu quá trình build từ source, nhưng đọc bài này thì có vẻ hoàn toàn bất khả thi
  Có lẽ sẽ cần một thuật ngữ mới để diễn đạt việc một codebase có giấy phép OSS, và cả các phụ thuộc build của nó cũng có giấy phép OSS hay không

  • Chuyện này thật sự nghiêm trọng. Nếu sau này Microsoft chôn vùi thread đó, người đời sau sẽ thắc mắc chúng ta đã nói về điều gì
  • Debian chia bản phân phối thành ba thành phần: main là phần mềm tự do, non-free là phần mềm không tự do, còn contrib là phần mềm tự do nhưng phụ thuộc vào thứ nằm ngoài main, thường là phần mềm không tự do
    Tôi không hẳn thích bản thân thuật ngữ contrib, nhưng cách phân loại này có vẻ khá hợp lý
  • Chỉ vài bình luận nhỏ này thôi cũng phơi bày chính xác vấn đề mà hệ sinh thái lớn hơn đang đối mặt, và nó có khả năng trở nên tệ hơn nhiều, nhanh hơn nhiều so với tưởng tượng
  • VSCode không phải là mã nguồn mở, và extension này cũng không phải mã nguồn mở
    Nhiều F/OSS trên Windows và gần như toàn bộ F/OSS trên macOS có các phụ thuộc build độc quyền như MSVC, Xcode, framework Apple và bộ công cụ GUI, nhưng bản thân chúng vẫn có thể là F/OSS
    Tuy nhiên trường hợp này không phải là vấn đề đó; ở đây một nhân viên Microsoft có vẻ là maintainer đã nói rằng “giấy phép của chúng tôi còn cấm dùng extension trên các bản phân phối VS Code thay thế, và chỉ được dùng trên bản phân phối chính thức do Microsoft tạo ra”
    Đây đơn giản là phần mềm độc quyền
    Quyền tự do 0 trong định nghĩa phần mềm tự do là quyền chạy chương trình cho bất kỳ mục đích nào bạn muốn; nếu một bản phân phối VSCode bên thứ ba không có cùng quyền dùng extension như bản phân phối chính thức, hoặc không có quyền dùng với extension tương thích, thì bất kể giấy phép của một phần code là gì, nó cũng không vượt qua được quyền tự do 3
    Câu “nếu bạn định tái phân phối binary language server như sản phẩm tự cung cấp thì giấy phép runtime cấm điều đó” có nghĩa là nó không vượt qua điều kiện 1 của định nghĩa mã nguồn mở, tức tiêu chí tái phân phối; và VSCode, nếu không cho phép các bản phân phối đã sửa đổi có cùng quyền như bản gốc, cũng không vượt qua điều kiện 3, tức tiêu chí tác phẩm phái sinh
    Cả VSCode lẫn extension này đều không phải mã nguồn mở, mà là phần mềm độc quyền có chứa một số thành phần mã nguồn mở
    Định nghĩa phần mềm tự do: https://www.gnu.org/philosophy/free-sw.html.en#four-freedoms
    Định nghĩa mã nguồn mở: https://opensource.org/osd
    Điều quan trọng nữa là các định nghĩa này không phải nghĩa thông thường trong từ điển, mà là những thuật ngữ được tạo ra trong nội bộ phong trào, với mục đích xã hội và kỹ thuật cụ thể
  • Theo tôi hiểu, extension này dùng một frontend C++ độc quyền được lấy từ EDG theo giấy phép thương mại
    Cùng frontend đó cũng có trong Visual Studio IDE
    Tôi biết là có một extension C++ hoàn toàn mã nguồn mở dựa trên clangd làm lựa chọn thay thế, nhưng cũng có thể tôi nhầm

• “Phần mềm tự do mà Microsoft cung cấp miễn phí vẫn chưa đủ mở” nghe như một lập luận khá lạ, ngay cả theo tiêu chuẩn hiện nay
  Trước đây, “IDE miễn phí” thường có nghĩa là Eclipse hoặc Vim gắn đầy extension
  Nhìn vào thì có vẻ không phải Microsoft đang cản trở các lựa chọn thay thế mở, mà đơn giản là các lựa chọn đó kém hơn; và khi dùng phần mềm do một công ty vừa phải trả lương cho nhân viên vừa phải tạo lợi nhuận làm ra, vốn dĩ sẽ có những khía cạnh như vậy
  Những ai cảm thấy mình đương nhiên phải được nhận mã nguồn phần mềm tốt nhất của Microsoft thì cứ nhìn xem phần mềm mã nguồn mở thật sự do một tổ chức phi lợi nhuận độc lập duy trì trông như thế nào
  Nó sẽ chạy được, thậm chí có thể có cả debugger thật sự, nhưng rất có khả năng chẳng bao lâu bạn sẽ muốn quay lại
  Mọi người đang xem phần mềm nhận miễn phí là điều quá hiển nhiên. Cách đây không lâu, một IDE có thể tốn vài trăm đến vài nghìn đô la, và vài năm sau nếu cần phiên bản mới thì còn phải trả phí nâng cấp

  • Khó mà nói Microsoft không cản trở các lựa chọn thay thế mở
    Extension VSIX đáng ra ở một mức nào đó phải là một chuẩn mở, nhưng các extension của Microsoft như Pylance lại chủ động từ chối hoạt động nếu phát hiện đang chạy trên VS Code không phải bản build của Microsoft
  • “Phần mềm tự do mà Microsoft cung cấp miễn phí vẫn chưa đủ mở” không phải trích dẫn từ bài viết, cũng không phải luận điểm của bài viết
    Trọng tâm gần với việc các lập trình viên đang bị đánh lừa, và mục tiêu của Microsoft là dần đóng các phần thiết yếu
  • Nhìn dự án Asahi Linux cũng tương tự. Họ đang làm những việc phi thường, nhưng ngay cả việc đạt mức tương đương các chức năng cơ bản với một chiếc laptop 3 năm tuổi vẫn còn đang tiếp diễn
    Sau khi đạt tương đương về chức năng, tiếp theo vẫn còn vấn đề hiệu năng, và cũng không biết khi nào mới giải quyết được
    Ý tưởng về phần mềm mã nguồn mở là tốt, nhưng ngày nay phần mềm tốt nhất gần như luôn là thứ phải trả tiền mới có được
  • Vấn đề của tôi là không biết kế hoạch lớn của Microsoft là gì
    Tôi biết cái giá khi dùng Emacs và Vim. Dù về lý thuyết là hoàn toàn miễn phí, trên thực tế vẫn có chi phí về thời gian, sự kiên nhẫn và tận tâm; và tôi biết lựa chọn của mình mang lại lợi ích cho tôi, cộng đồng và ngành
    Trước đây khi dùng IntelliJ, tôi cũng biết chính xác JetBrains kiếm lợi như thế nào. Vì tôi trả phí giấy phép và gia hạn hằng năm
    Nhưng phép tính của Microsoft là gì? Họ cung cấp một công cụ đẹp và khá tốt như vậy hoàn toàn “miễn phí”, thì trong tương lai tôi sẽ phải trả cái giá nào?
    Khó tin rằng một tập đoàn khổng lồ có vốn hóa thị trường ngang GDP của Đức lại bỏ nguồn lực khổng lồ để làm một trình soạn thảo mã “miễn phí” chỉ vì yêu lập trình viên; lập trình viên ít nhất cũng nên hoài nghi một chút
  • Cụm “phần mềm tốt nhất của Microsoft” nghe như một câu đùa
    Theo tôi, phần mềm của Microsoft gần giống một đống rác ác mộng hơn
    Ý của bài viết là khi phần mềm đóng giả vờ là mã nguồn mở, nó ảnh hưởng cả đến những người không muốn dùng nó, nhưng bạn đang bỏ lỡ điểm đó
    Ví dụ tôi cũng không muốn dùng Azure DevOps hay GitHub Actions gì đó, nhưng tổ chức nơi tôi làm việc phải đưa dự án lên GitHub nên tôi bị buộc phải dùng
    Kết quả là tôi có cảm giác công sức và tri thức của mình đang được dùng để Microsoft khai thác người dùng
    Niềm an ủi duy nhất là đây là công việc được trả lương; còn cá nhân tôi không dùng GitHub và cũng sẽ khuyên người khác làm như vậy

• Nếu không đưa ra được một mô hình để biện minh cho ngân sách khoảng 20 triệu đô la mỗi năm cho hơn 50 nhân viên toàn thời gian làm VS Code, lời phê bình này nghe như: “Thật bực mình vì họ khiến công ty chúng ta hơi khó chịu hơn trong việc lấy thành quả kỹ thuật của họ, chỉ đổi lớp vỏ sản phẩm, rồi bán rẻ hơn để kiếm lợi mà không tốn chi phí tự phát triển”

  • Việc Microsoft tự làm IDE để dùng nội bộ ở nhiều bộ phận và chi ngân sách cho một công cụ hiện đại, linh hoạt là điều có thể hiểu được
    Nếu công bố nó dưới dạng mã nguồn mở, họ có thể giành được niềm tin từ các cộng đồng khác, nhận được mã miễn phí, kiểm tra lỗi miễn phí, cũng như các extension được viết và hỗ trợ ngoài hệ sinh thái Microsoft; còn Microsoft vẫn có thể tiếp tục dùng nó
    Tôi không thấy đây là vấn đề phức tạp lắm
  • Đó không phải vấn đề của tôi. Vấn đề của tôi là không để năng lực nghề nghiệp của mình phụ thuộc vào thiện chí tiếp diễn của Microsoft
    Trong lịch sử, đó là con đường bảo đảm dẫn tới lỗi thời
    Ngay cả không có thành quả kỹ thuật của họ thì vẫn có Emacs, Vim, Clang, GCC, IDEA, Eclipse, Firefox, v.v.
    Tôi chỉ quan tâm đến món quà chăn hào phóng của Microsoft khi nó không đi kèm bệnh đậu mùa
  • Mô hình kinh doanh của họ tệ không phải là điều tôi lo. Họ không phải một đứa trẻ nghèo bị lợi dụng vì đưa ra quyết định sai lầm
    Chỉ là việc đưa tin chuyện này như một bất ngờ lớn thì hơi buồn cười. Nó đã rõ ràng ngay từ đầu, chỉ là mọi người không để tâm vì trông có vẻ không đáng để đấu tranh
    Vấn đề lập trình viên dùng giấy phép BSD/MIT bị khai thác cũng chẳng khiến tôi quan tâm hơn vấn đề mô hình kinh doanh của Microsoft có thể lung lay vì người dùng tắt telemetry
    Ai cũng nghĩ “đàn anh tập đoàn lớn sẽ để mắt đến chúng ta” và vẫn lựa chọn dù biết mình đang bước vào đâu; mà thực tế họ đã được để mắt đến, vậy thì chúc mừng
    Tôi sẽ không đăng gì với giấy phép yếu hơn AGPL, nhưng rốt cuộc vẫn có những việc tôi quan tâm hơn phần mềm rất nhiều

• Vẫn đang cố hiểu vấn đề thực sự là gì
  Nghe như ý là Microsoft đang tạo ra một phần mở rộng cpptools/C++ tốt hơn, nhưng vì nhiều thành phần của Microsoft bị đóng nên không thể build được một phiên bản OSS hoàn chỉnh
  Và khi người dùng nhận ra họ không thể dùng phần mở rộng native trên bất kỳ giao diện web nào, thì điều đó lại trở thành vấn đề của phía làm giao diện web hay sao
  Nếu mọi người muốn dùng freeware thay vì OSS thì có thể đáng thất vọng, nhưng tôi không chắc đó có thật sự là vấn đề không
  Nếu có câu trả lời, có lẽ là thông báo rõ hơn ai phải chịu trách nhiệm
  Các nhà cung cấp mã nguồn mở nên nói rõ hơn rằng sản phẩm họ cung cấp là mã nguồn mở và là một hệ sinh thái mở, đồng thời cho nhà phát triển biết rằng không phải mọi phần mở rộng đều như vậy, và phần mở rộng thay thế của Microsoft thì không
  Nếu các dự án phần mở rộng lớn cùng thống nhất, họ có thể thêm thông báo trong mô tả marketplace kiểu như vscode-cpptools không dùng giấy phép được OSI phê chuẩn, có nhiều binary blob chưa được kiểm tra, và Microsoft không cho phép phân phối lại trong các bản build mã nguồn mở native hay trong việc cung cấp VSCode cho dịch vụ web
  Về mặt pháp lý lẫn văn hóa, Microsoft hẳn sẽ không muốn chặn quyền truy cập marketplace chỉ vì một vài dự án OSS so sánh điều khoản giấy phép của mình với điều khoản của Microsoft
  Apple hiện cũng đang vướng kiện tụng về marketplace, và Microsoft chắc không muốn một vụ kiện marketplace hay một vụ kiện chống độc quyền khác

  • Lấy ví dụ đơn giản: tạo một API chỉ có một hàm công khai, rồi biên dịch API đó thành binary theo giấy phép mã nguồn đóng
    Sau đó tạo một API khác cũng chỉ có một hàm công khai, và hàm đó chỉ extern gọi tới binary thư viện kia
    Đưa API thứ hai lên GitHub với giấy phép MIT và tuyên bố đó là mã nguồn mở
    Nhìn rộng ra, vấn đề là nếu 100% chức năng phần mềm nằm trong binary đã biên dịch mã nguồn đóng, thì việc gọi nó là mã nguồn mở có nên bị xem là quảng cáo sai sự thật hay không
    Nói cách khác, đây là vấn đề ai sẽ vạch ranh giới khi có người vượt quá tinh thần của mã nguồn mở vì lý do bóc lột
    Tôi không biết chức năng của cpptools có đóng 100% hay không, nhưng thực tế là trong repository được ghi là giấy phép MIT đó còn có thêm ba giấy phép khác mà bạn phải đồng ý

• Phải đọc quá nhiều mới hiểu được ý chính thực sự là gì, và khái niệm “hệ sinh thái bị phân mảnh” xuất hiện nhiều lần mà không được giải thích
  Những cách nói như “cây nắp ấm được thiết kế để gây phân mảnh” rốt cuộc nghĩa là gì thì tôi không hiểu
  VS Code là một IDE miễn phí có thể tải từ Microsoft, là một sản phẩm, chứ không phải một nền tảng hay hệ sinh thái mã nguồn mở kỳ diệu nằm ngoài sự kiểm soát của Microsoft
  Có vẻ ai cũng muốn tạo ra dịch vụ dành cho nhà phát triển “đa dụng”, nhưng lại không muốn hoặc không thể làm IDE hay tài trợ cho IDE, hoặc việc đó quá khó
  Đó không phải lỗi của Microsoft

• Không có ý bênh Microsoft, nhưng họ đã cung cấp miễn phí một codebase khổng lồ và xây dựng trên đó một sản phẩm phần lớn là miễn phí
  Nếu fork thì chỉ không truy cập được máy chủ của Microsoft; như vậy có vẻ cũng đủ công bằng rồi
  Và Monaco là một trình soạn thảo cực kỳ tốt nên các frontend mới dùng nó. Trước đây khi CodeMirror hay Ace là lựa chọn tốt nhất thì người ta cài chúng
  Thay vì có một kế hoạch tổng thể khổng lồ đằng sau việc tạo ra Monaco, có vẻ đúng hơn là họ nhìn thấy cơ hội rằng nếu biến nó thành dự án độc lập thì sẽ mở ra vô số UI web

• Điểm rất lớn là “tương lai của các công cụ phát triển phần mềm được tạo ra về sau đang hoàn toàn đóng, nhưng vì một số thành phần đáp ứng định nghĩa của OSI nên mọi người bỏ lỡ bức tranh toàn cảnh và cho rằng như vậy là ổn”
  Đặc biệt, nhiều công ty nhận vốn VC đang dùng thuật ngữ mã nguồn mở quá lỏng lẻo, làm biến đổi theo hướng xấu cả ngôn ngữ, ý nghĩa và tinh thần của phong trào mã nguồn mở
  YC cũng đang hỗ trợ nhiều công ty tự nhận là mã nguồn mở nhưng hoàn toàn không tuân theo tinh thần đó

  • Vấn đề không hẳn là các công ty làm như vậy, mà là người dùng và nhà phát triển không mấy quan tâm hoặc không chia sẻ những lo ngại đó
    Những luận điểm đạo đức như tinh thần hay đạo lý không liên quan nhiều lắm
    Điều quan trọng là giấy phép phần mềm là văn bản pháp lý, và nơi cách diễn giải của nó có ý nghĩa là tòa án
    Có vẻ không có nhiều vụ kiện liên quan đến VS Code, và Microsoft nhìn chung thường sắp xếp ổn phần đó
    Theo nghĩa pháp lý, VS Code trông có vẻ đủ an toàn. Đúng là một số phần mở rộng không dùng giấy phép OSS hoặc hoàn toàn là mã nguồn đóng, nhưng nếu không thích thì đừng dùng
    Hơn nữa, bạn có thể tự tạo mã nguồn mở để sửa nó. Mã nguồn mở không phải là quyền, mà là đặc ân do người tạo ra tùy ý trao, không phải thứ có thể đòi hỏi
    VS Code là một sản phẩm mã nguồn đóng chứa nhiều thành phần OSS, và vì có nhiều thành phần như vậy nên VS Codium hoàn toàn OSS cũng tồn tại
    Nhiều thành phần OSS đó cũng được dùng trong các sản phẩm khác, và một số thì hoàn toàn mã nguồn mở
    Giá trị của hệ sinh thái VS Code nằm ở việc nó giúp các thành phần này và hệ sinh thái sản phẩm phát triển mạnh

• Không ai có quyền được nhận VS Code miễn phí. Thực ra chẳng ai có quyền được nhận bất cứ thứ gì miễn phí
  Lựa chọn thay thế là trả tiền cho các IDE thương mại cồng kềnh
  VS Code ổn, đa dụng, miễn phí và đủ mở để có thể fork
  Mọi người quên mất rằng đây là một sản phẩm kỹ thuật đáng kinh ngạc. Nhìn vào mã nguồn thì đây không phải thứ có thể xuất hiện miễn phí ở mức đó
  Dù là Microsoft hay công ty nào khác, không ai nợ ai miễn phí cả, và kiểu ý thức về quyền được hưởng này cần được kiểm soát

  • Đúng, thà cứ gắn giá vào là được. Người ở đây cũng nhận đủ giá trị từ VSCode nên sẽ trả tiền
    Vấn đề là khi một thứ được cung cấp miễn phí trên thực tế lại được thiết kế để đẩy người dùng vào vũng lầy trách nhiệm pháp lý và trách nhiệm tài chính không có trần
    Điều này càng đúng với một dịch vụ như VSCode, vốn không phải mua một lần, mà khiến bạn tiếp tục phụ thuộc vào Microsoft thông qua tiện ích mở rộng và cập nhật; thực tế nó được thiết kế như vậy
    Họ đã không tạo ra một lựa chọn dễ dàng là trả một lần gọn gàng rồi xong, mà chọn cách về dài hạn rút ra một khoản tiền mơ hồ tùy theo mức độ phản kháng của người dùng
  • Các sản phẩm JetBrains có giá trị nên tôi đã trả tiền nhiều năm. So với tính năng của Eclipse thì chúng vượt xa, và đáng để trả tiền
    Với mã nguồn mở tôi cũng luôn nói vậy: tôi hoài nghi khi chọn dùng một framework không có nguồn tiền lớn đứng sau
    Phụ thuộc vào sự thất thường của một kỹ sư thiên tài ngẫu nhiên trên Internet là rủi ro
    Microsoft sẽ kiếm tiền từ VSCode. Chỉ là không trực tiếp như cách Google kiếm tiền từ Chrome
  • Có thật sự đáng kinh ngạc về mặt kỹ thuật không? Việc dùng công nghệ trình duyệt cồng kềnh và một ngôn ngữ như thể được thiết kế trên khăn ăn để tạo ra một IDE chỉ vừa đủ chạy được, theo tôi cũng “ấn tượng” ngang với việc dựng một cây cầu đi bộ dài 1 dặm bằng que kem và kẹo cao su

• Tôi nghĩ OSS rất tuyệt, nhưng đó không phải lý do tôi dùng VS Code
  Tôi dùng vì nó giải quyết vấn đề cần một trình soạn thảo dùng được, chứ không phải một con quái vật như Eclipse
  Trong mảng này cũng có các lựa chọn khác như Sublime, nhưng VS Code luôn có cảm giác ít gây cản trở nhất
  Trước đây cũng có Adobe Brackets tương tự, nhưng không hiểu sao nó rất chậm và nhiều lỗi
  Nếu là người nhiệt thành với OSS thì những điểm bài viết nêu ra là xác đáng. Nhưng rốt cuộc mã nguồn vẫn có đó, và nếu muốn thì bạn cũng có thể vận hành marketplace của riêng mình
  Tốn thời gian và tiền bạc, nhưng nếu tin vào ý tưởng đó thì nên đầu tư thay vì phụ thuộc vào các tập đoàn khổng lồ
  Nếu có tiện ích mở rộng độc quyền mà mình không thể có thì đáng tiếc, nhưng ai đó cũng có thể tạo phiên bản OSS
  Nhìn chung tôi đồng ý với bài viết, nhưng tôi không ảo tưởng rằng Microsoft làm vậy vì niềm tin vào mã nguồn mở, và trong trường hợp xấu nhất vẫn còn lựa chọn khác nên không sao