Blog > Fully Open-Source VS Code
Fully Open-Source VS Code
Making VS Code AI-native for the community
1,128 words, ~ 6 min read
perspective
Microsoft now plans to fully open-source VS Code - specifically, the GitHub Copilot Chat extension and integration into the editor. Previously, Microsoft had open sourced the main source code under the MIT license for free usage - which excluded extensions.

Of course, it’s related to Cursor and Windsurf forking VS Code, making way too much money off of Microsoft investment. But it also raises the question of what Microsoft should try to do here and why. This post will explore these elements in more detail, before offering some predictions for how AI-driven value will be monetized.
Table of Contents
- A Principle for Open-Source
- Microsoft’s Approach to Open-Source
- Cursor and Windsurf: Microsoft’s Decision
- Capturing Value to Make Money
A Principle for Open-Source
I think a lot about open-source largely because I work on Apache Iceberg and Delta Lake (open source table formats). On the surface, it seems simple, foolish even; spending engineering effort on features given away for free to the larger community. Yet, the strategy is paramount.
I wrote previously on this topic at length. The key principle was to commoditize your complement, where companies pick one component of a system to dominate while giving away everything else for free. This forces competitors to fight companies on their turf, instead of on all fronts. With software’s easy reproducibility (unlike hardware), this is an extremely powerful methodology.
AWS is largely built on this thesis - it’d be great for them if all software was free. Then it becomes a game of who can host the software for the cheapest possible price. They have a unique advantage there because of their massive data centers, which is hardware - and thus extremely challenging to replicate.
Yet, AWS isn’t the downright winner. Despite Athena, Redshift, EMR, EKS, and countless other technologies, other non-hyperscalar vendors exist and do remarkably well. This principle helps explain the high-level idea, but reality is far more complex.
Microsoft’s Approach to Open-Source
Microsoft’s improved support for open source is best characterized by Linux. Early on, Microsoft hated Linux. Microsoft is the creator of Windows; why would they support Linux? Bill Gates was one of the early advocates of paying for commercial software. Yet Microsoft now actively contributes to Linux development and all over GitHub.
VS Code is a good example of Microsoft’s commitment to open source. They generally say:
Our guiding principle is that everything should be open source. If it isn’t open source, it must be cleanly separated from the
Code - OSS
repository so that it is always possible to fork the repo and build a functional editor.
They keep proprietary assets and code outside of the repository - including services they build. Additionally, anonymous telemetry gets sent back to Microsoft for statistics.
Overall, Microsoft is good about maintaining a real, open-source project. This has been largely successful: a lot of development is done on some combination of VS Code or Visual Studio (Microsoft’s full fledged IDE). It’s not complete dominance, for there are a few companies that use IntelliJ instead, typically in the Java/Scala ecosystems (Amazon, Databricks).
Cursor and Windsurf: Microsoft’s Decision
Enter Cursor and Windsurf: AI-native code editors that forked VS Code. These have been making a tremendous amount of money: Cursor had 100M ARR in February 2025, 200M ARR in March 2025, and now 300M ARR in May 2025. OpenAI bought Windsurf for 3B in May 2025.
Now say you’re Microsoft. For the past 10+ years, you have been growing a thriving open-source community. Now, startups are forking the editor and going outside that community to sell. This isn’t to trivialize the efforts of Cursor and Windsurf; these editors contain many, many optimizations to improve the AI integrations. In fact, this is why they needed to fork the entire editor instead of building an extension.
Microsoft has two options here to grow their community:
- Stop open-sourcing VS Code: Force Cursor and Windsurf to build and maintain their own editors.
- Make open-source VS Code AI-native: Bring open-source VS Code to parity with Cursor and Windsurf.
Microsoft did the second option by open-sourcing the key integrations in VS Code required to build out an AI-native experience, without giving away the backend (and the secret sauce). This allows competitors to get started with competing in the space, ultimately driving the ecosystem towards a better position. It also encourages folks to stay within the VS Code community, as forking is significantly harder to maintain compared to extensions. Finally, it maintains potential to monetize consumption similar to GitHub Copilot’s current pricing model - a decent but not fully capable free tier that is missing core enterprise features. As models improve, this becomes less and less important, but still drives revenue nonetheless.
Capturing Value to Make Money
Most devtool software was historically license based - especially tools to help write code like editors. In more recent years, for SaaS style products, there’s been a shift to usage/consumption based pricing. For AI products, there’s yet another model: outcome-based pricing, which Marc Benioff foresaw as the future of Salesforce pricing for their AI agents back in August 2024.

Outcome-based pricing is an interesting model in some scenarios, but not all. Sales leads might be correctly priced based on the number of qualified sales leads (ex: one that takes a first call with a company) instead of the usage or number of LinkedIn profiles scanned. In this scenario, though, there is a clear outcome which can be negotiated. When writing code, what is the right outcome? Even if one thinks they know the right outcome, is that really the ultimate outcome they have?
Today, plenty of companies hire agencies for development work by agreeing upon some final work, estimating the number of hours required, then billing as work continues. In that world, the company completely offloads the development work and pays in exchange.
With editors, the implicit agreement is the user does not relinquish control. Instead, the user is able to describe/comment what they want, and the editor helps them fill in the blanks as needed. This feels fundamentally different to hiring an agency - editors should encourage frequent iteration instead of slow feedback loops.
For now, I believe pricing based on licenses is still right for these editors. This is what GitHub Copilot, Cursor, and Windsurf use - though Windsurf allows for adding more credits per user to allow for more prompting, mixing in usage-based pricing. Cursor also caps the number of requests that can be made. These planks help offset the costs of hosting and running models at scale.
Will this be how it always works? Almost certainly not. We need better alignment on clear, immutable user goals with willingness to pay.
Found this interesting? Subscribe to get email updates for new posts.
First Name
Last Name
Previous Post
Iceberg v3, Two Talks, One Lakehouse