Microsoft has removed its official C/C++ extension from downstream forks of VS Code, including VSCodium and Open VSX Registry. This means users of these open-source alternatives will lose access to features like IntelliSense, debugging, and other language-specific functionalities provided by the proprietary extension. While the core VS Code editor remains open source, the extension relies on proprietary components and Microsoft has chosen to restrict its availability solely to its official, Microsoft-branded VS Code builds. This move has sparked controversy, with some accusing Microsoft of "embrace, extend, extinguish" tactics against open-source alternatives. Users of affected forks will need to find alternative C/C++ extensions or switch to the official Microsoft build to regain the lost functionality.
Microsoft has taken a step that has agitated some members of the open-source community by removing the popular C/C++ extension from the publicly accessible source code repositories of its open-source versions of Visual Studio Code, specifically VSCodium and VS Codium. These community-driven forks exist to provide a build of VS Code free from Microsoft's proprietary telemetry and branding elements. The C/C++ extension itself, while developed by Microsoft, is released under an open-source MIT license. However, the pre-built binaries distributed with VSCodium and VS Codium previously leveraged Microsoft's proprietary marketplace and build infrastructure.
Microsoft's justification for this action centers around its desire to encourage users to utilize the official, Microsoft-branded VS Code builds for optimal C/C++ development experience. The company argues that the pre-built binaries provided in the marketplace are specifically optimized for use with official VS Code releases, claiming they offer enhanced performance and stability. They posit that attempting to use these binaries with modified VS Code builds might lead to unpredictable behavior and a subpar user experience. Microsoft emphasizes that the source code for the C/C++ extension remains open-source and accessible on GitHub, allowing community forks to build the extension themselves.
This change has implications for users of VSCodium and VS Codium who rely on the pre-built C/C++ extension for C and C++ development. While these users can technically continue to benefit from the extension, they now face the added complexity of building the extension from source. This adds a barrier to entry, especially for users who may lack the necessary build tools or familiarity with the build process. It's worth noting that this move doesn't affect the availability of the extension for the official Microsoft VS Code distribution, where it remains readily accessible through the marketplace. This action underlines the complexities and occasional tensions inherent in navigating the intersection of open-source projects and proprietary offerings, particularly when a commercial entity plays a significant role in both spheres.
Summary of Comments ( 245 )
https://news.ycombinator.com/item?id=43788125
Hacker News users discuss the implications of Microsoft's decision to restrict the C/C++ extension in VS Code forks, primarily focusing on the potential impact on open-source projects like VSCodium. Some commenters express concern about Microsoft's motivations, viewing it as an anti-competitive move to push users towards the official Microsoft build. Others believe it's a reasonable measure to protect Microsoft's investment and control the quality of the extension's distribution. The technical aspects of how Microsoft enforces this restriction are also discussed, with some suggesting workarounds like manually installing the extension or using alternative extensions. A few users point out that the core VS Code editor remains open-source and the real issue lies in the proprietary extensions being closed off. The discussion also touches upon the broader topic of open-source sustainability and the challenges faced by projects reliant on large companies.
The Hacker News thread discussing the Register article about Microsoft removing the C/C++ extension from VS Code forks has a moderate number of comments, focusing primarily on the licensing implications and the motivations behind Microsoft's decision.
Several commenters express concern over the increasingly restrictive licensing landscape surrounding open-source software, with this move by Microsoft seen as another example of a company attempting to control the ecosystem around its products. They argue that this could stifle innovation and competition, particularly for smaller players or community-driven projects that rely on forking as a development strategy.
Some commenters speculate that Microsoft's motivation is to steer users towards their officially supported VS Code builds and extensions, potentially to gather more telemetry data or control the user experience. Others suggest that it might be a strategic move to limit the viability of competing code editors built upon VS Code's open-source foundation.
The discussion also touches upon the technicalities of the licensing change. Some commenters clarify the distinction between the open-source VS Code editor itself and the proprietary extensions that Microsoft provides, pointing out that Microsoft is within its rights to control the distribution of its proprietary code.
A few commenters express understanding for Microsoft's position, arguing that they have invested heavily in developing these extensions and have a right to protect their intellectual property. They counter the concern about stifling innovation by suggesting that developers can still create and distribute their own C/C++ extensions for forked versions of VS Code, albeit without the direct integration with Microsoft's specific implementation.
A compelling point raised by a commenter is the potential chilling effect this could have on community contributions to VS Code. If developers perceive that their work might be restricted or appropriated by Microsoft, they may be less inclined to contribute to the project in the future. This highlights the delicate balance between open-source collaboration and proprietary interests.
Finally, some commenters offer practical advice on how to continue using the C/C++ extension with forked versions of VS Code, including using older versions or exploring alternative extensions.
Overall, the comments paint a picture of a community grappling with the complexities of open-source licensing and the evolving relationship between proprietary software and community-driven development. The discussion is nuanced, with commenters offering a range of perspectives on the implications of Microsoft's decision.