When “Open” Isn’t Open Enough: Rethinking Trust in Dev Tools

Tuesday, May 6, 2025 - 13:00 by Thomas Froment

The rise of AI is redefining the development tools landscape, fast. It’s no longer just better code navigation or debuggers. Today, IDEs are becoming intelligent assistants, with AI at their core. But with this shift comes new tension: control, ownership, and freedom in developer tools are being challenged in ways we’ve seen before, and predicted. Now, it’s happening at full speed.

If you’re building developer tools, or betting your company’s productivity on them: it’s time to look beyond the surface of “open source” and ask: Open for whom? And for how long?

🔍 A Real-World Example: When a Key Extension Disappears

In April 2025, a change from Microsoft affected the availability of the C/C++ extension in all forks of VS Code, including Cursor and VSCodium. Developers relying on these tools suddenly lost access to core functionality like IntelliSense and debugging. For many, an essential part of the toolchain was no longer available, overnight…

This wasn’t a bug or a technical failure. It was the result of a license clause that had been part of the extension since 2020, specifying it could only be used within Microsoft products such as VS Code, Visual Studio, or Azure DevOps. What changed in 2025 was the enforcement of that clause, which until then had remained largely dormant: Read the full story on The Register.

To be clear, this is not about blaming Microsoft. The company operated fully within its rights. And this kind of strategic shift is not unique: it’s something we’ve seen across many companies and platforms, especially when competition tightens around emerging technologies like AI.

Cursor’s team responded by announcing a move toward community-maintained, open alternatives. But the disruption had already made its impact. For many developers, it wasn’t just about this one extension. It was a reminder that even widely-used tools can become restricted with little notice, especially when key capabilities become strategic differentiators.

This moment reflects a broader pattern: as AI becomes central to developer experience, more vendors may choose to consolidate their ecosystems.

🧩 Fracture by Design

This development did not come out of nowhere. As Geoffrey Huntley wrote in 2022, the VS Code ecosystem was structured in a way that makes fragmentation likely.

While the core source code of VS Code is open under the MIT license, what most developers interact with as “VS Code” includes much more than that. The distributed version ships with Microsoft-built binaries, access to a proprietary extension marketplace, and a set of closed-source components. These parts are not open, and the restrictions around them are deliberate.

Projects like VSCodium and OpenVSCodeServer have worked to remove telemetry and Microsoft branding. But despite being based on the same open codebase, they are still blocked from using the full Microsoft marketplace. Increasingly, they are also unable to access important capabilities like Live Share, Remote Development, and now, C/C++ support.

These constraints are not the result of technical limitations or oversights. They reflect clear product choices, built into the architecture and licensing of the platform. For developers maintaining forks or building on top of the codebase, the gap between what’s open and what’s actually usable continues to grow.

⚠️ “Open” as a Strategy, Not a Philosophy

In a recent blog post, Wiechtig explores a broader tension that’s becoming more visible across the industry. For many large vendors, open source is used primarily as a growth strategy rather than a long-term principle. The objective is not always developer freedom, but often adoption and market share.

VS Code is a well-known example. It gained traction quickly, thanks to its open source core and the support of a highly active community. At the same time, Microsoft maintained control over key parts of the product: the builds, the branding, the marketplace, and several essential integrations.

Once AI capabilities started to become a differentiator in development tools, the strategy shifted. The platform remained open at its core, but critical parts of the ecosystem became harder to access. Projects like Cursor, which had invested heavily in this ecosystem, are now finding themselves excluded from key components.

This is not an isolated case. We’ve seen similar transitions with other projects, such as Elastic, Terraform, and Redis. Each started as a fully open project, grew rapidly with community support, then eventually moved to more restrictive licensing once they reached a dominant position.

In that context, open source is sometimes less a commitment and more a phase in a broader business plan.

⚙️ Forking VS Code: The Trade-Offs Become Clear

At first glance, forking VS Code might seem like a straightforward solution. Several teams have followed this path, especially when building AI-native development tools. Cursor, Google’s IDX, and others have all tried to take the open core and adapt it to their needs.

But the deeper you go, the more the trade-offs become apparent.

As outlined in this article “Is Forking VS Code a good idea”, the reality is the following:

You lose access to the Marketplace.
You lose proprietary extensions.
You lose compatibility guarantees.
You take on a potential maintenance burden.
You risk user confusion and feature gaps.

Forks lose access to the official Marketplace and the ecosystem around it. Many of the most widely used extensions are either proprietary or tied to services controlled by Microsoft. Features like Live Share or Remote Development are not available. And with the recent C/C++ restriction, even more functionality is falling behind that same line.

Maintaining a fork over time is also a significant burden. VS Code is under active development and evolves rapidly. A single release can touch hundreds of files and restructure major parts of the build system. Keeping up requires full-time effort, and divergence from upstream can happen quickly, even unintentionally.

There’s also the issue of expectations. Users coming from official VS Code builds often assume a certain level of compatibility and polish. Forks that can’t deliver the same integrations or fluid updates are at a disadvantage, regardless of how capable the underlying code may be.

And then there’s the broader challenge: when one vendor controls the rules of the ecosystem, competing within that space, while respecting those rules, can become increasingly difficult.

🛠️ Eclipse Theia: A Different Approach to Tooling

There is another path, one that doesn't rely on forking or retrofitting an existing ecosystem built around closed components.

Theia, Theia AI and the AI-powered Theia IDE are truly open and vendor-neutral technologies for developers and for building AI-enabled IDEs and tools:

Theia is an open platform designed from the beginning for extensibility, flexibility, and transparency. It’s not just an IDE, but a foundation for building developer tools, general-purpose or highly specialized, without hidden dependencies or usage restrictions.

With the Theia IDE and Theia AI, the focus is on giving developers and tool builders control. The stack is modular. You can choose what to include, what to change, and how to deploy it. Whether you're integrating AI features, building collaborative tooling, or targeting air-gapped environments, you’re not tied to a vendor's infrastructure or licensing terms.

Theia supports key open standards like the Language Server Protocol (LSP), Debug Adapter Protocol (DAP), and Monaco editor. Extensions can be installed from Open VSX, and projects like Open Collaboration Tools offer alternatives to features like Live Share. For AI coding assistance, Theia Coder provides an open, inspectable way to integrate LLM-based support without relying on closed APIs or opaque data flows.

More importantly, Theia is built and maintained in the open. It is community-driven, vendor-neutral (as an Eclipse Foundation project) and designed for reusability across domains and organizations.

🧭 Choosing Carefully

The changes we’re seeing in the VS Code ecosystem are not random. They reflect a clear direction: maintaining central control over distribution, key features, and strategic integrations. For many developers, especially those working on long-lived tools or infrastructure, this creates uncertainty.

Forking and adapting a closed ecosystem may work for a while, but the friction tends to grow over time. Every new restriction or compatibility break introduces more overhead and risk.

By contrast, working with an open platform like Theia means investing in something where the rules are transparent and where the architecture supports flexibility rather than limiting it.

There’s no single right choice for everyone. But for those who care about autonomy, inspectability, and long-term maintainability in their development tools, it’s worth looking closely at where your foundation comes from, and where it’s headed.

Sources: