The Strategy Dilema In a former life I worked on an AI developer co-pilot. Back then, when these were coming to life, post GitHub Copilot, you had a strategy dilemma: AI developer co-pilot Do you build an extension for one of the largest ecosystems, and arguably largest wrt mindshare, in VS Code?Or, do you ignore that ecosystem and battle elsewhere?Oh, and since VS Code has an open source core, do you fork? Do you build an extension for one of the largest ecosystems, and arguably largest wrt mindshare, in VS Code? Or, do you ignore that ecosystem and battle elsewhere? Oh, and since VS Code has an open source core, do you fork? There are trade offs all over. When you build an extension, you are naturally constrained. The extension points and capabilities are limited, and there are a shocking number of things that you may expect that you can do, that you can't. All Extensions are Confined All Extensions are Confined The platform, by design, can't just open up everything because the trust it has on its own surfaces can't be placed on any third-party codebase. A platform has to design a technical trust model, but we have also seen that many also go further and have other processes to help with restrictions. Apple's App Store review and distribution system gives another level of control, and many others followed suit, including Microsoft with the Visual Studio Code Marketplace. Visual Studio Code Marketplace The VSCode Lock-in Microsoft’s terms do not allow forks or derivative products of VSCode to access the official Marketplace unless they are using an unmodified or officially sanctioned version of VSCode. This is primarily defined in: do not allow forks or derivative products of VSCode to access the official Marketplace Section 3.a of the Marketplace Terms of Use (for Publishers): “You may not use the Marketplace or any services provided through the Marketplace to enable or support any other product than the Visual Studio family of products, including Visual Studio Code as provided by Microsoft.” This clause is interpreted to mean: You cannot use the marketplace to distribute extensions to forked or branded versions of VSCode (e.g., VSCodium, Onivim, etc.).You cannot redirect marketplace traffic or replicate the marketplace without violating Microsoft’s terms. You cannot use the marketplace to distribute extensions to forked or branded versions of VSCode (e.g., VSCodium, Onivim, etc.). cannot use forked or branded versions You cannot redirect marketplace traffic or replicate the marketplace without violating Microsoft’s terms. cannot redirect marketplace traffic or replicate the marketplace What to do? OpenVSX The Eclipse Foundation launched the Open VSX Registry as an open alternative to the VS Marketplace, with these goals: Open VSX Registry open alternative Support open-source forks of VSCode, like VSCodium, Gitpod’s Theia, etc.Provide an extension registry that is open, legally redistributable, and community-driven.Offer a vendor-neutral governance model, unlike Microsoft’s tightly controlled marketplace. Support open-source forks of VSCode, like VSCodium, Gitpod’s Theia, etc. Support open-source forks of VSCode Provide an extension registry that is open, legally redistributable, and community-driven. open, legally redistributable, and community-driven Offer a vendor-neutral governance model, unlike Microsoft’s tightly controlled marketplace. vendor-neutral governance model This gave a path for products that wanted to support VSCode extensions, but it is very limiting for users as not all extensions are available there. They don't just magically show up after all. And as we will see, this becomes key in other ways. What to do? YOLO it Now, other tools haven't gone the OpenVSX path, and just.... download from the marketplace anyway. This is a scary path, as the rug can be pulled at any time, but some brave souls have given this a try, such as Cursor. I have been waiting with bated breath for Microsoft to make a stand... for a couple years at this point, but it wasn't happening. I wondered if Microsoft was being patient because the VSCode+Copilot pairing was the giant. Microsoft VSCode and GitHub Copilot This pairing is the other reason why being an extension within VSCode isn't the best position to be in, beyond the "platforms will limit your capabilities for privacy and security and UX and ... reasons". The VSCode and Copilot teams are different teams. In different orgs. With different goals. In the beginning it's a happy-ish family. VSCode is a great ecosystem to get into, and Copilot is using OpenAI, the leader on the model side. Great! But over time changes occur: VSCode doesn't want to be limited to Copilot as the other AI developer tool experience. All of this cool stuff is coming out of startups and other companies... why not embrace this too? You start to see a pattern where Copilot has access to APIs that other extensions don't have access to. Some of these open up in some way after some time, and others... don't. You can see that there are multiple reasons why: Partnering closely with another org within your broader company enables a different trust relationship and you can use this partnership to help flush out and iterate on APIs over time. There is the competitive situation, where one would like to keep their special access exclusive for as loooooooong as possible.Copilot doesn't want to be limited to VSCode as the only IDE experience. As they sell into the Enterprise they see how many JetBrains users are out there and they want access to that... and as many other IDEs as possible!Both don't want to be limited to OpenAI models when Claude Sonnet becomes known as a leader in codegen, and Gemini finally steps up to create something comparable or even better. VSCode doesn't want to be limited to Copilot as the other AI developer tool experience. All of this cool stuff is coming out of startups and other companies... why not embrace this too? You start to see a pattern where Copilot has access to APIs that other extensions don't have access to. Some of these open up in some way after some time, and others... don't. You can see that there are multiple reasons why: Partnering closely with another org within your broader company enables a different trust relationship and you can use this partnership to help flush out and iterate on APIs over time. There is the competitive situation, where one would like to keep their special access exclusive for as loooooooong as possible. Copilot doesn't want to be limited to VSCode as the only IDE experience. As they sell into the Enterprise they see how many JetBrains users are out there and they want access to that... and as many other IDEs as possible! Both don't want to be limited to OpenAI models when Claude Sonnet becomes known as a leader in codegen, and Gemini finally steps up to create something comparable or even better. The limits were too much for some companies, and thus they forked VSCode to make the UX changes they wanted, but were not possible via the extension points made available. Microsoft Finally Acts And when one of these forks becomes beloved in the developer sphere, Microsoft finally acted. The Remarkable Rise of Cursor In less than two years, they scaled from $1 million to over $100 million in Annual Recurring Revenue (ARR). For context, even the fastest-growing SaaS companies typically take 5 years to reach the $100M ARR milestone. Did Microsoft kill access to the marketplace for Cursor and other forks? No, that wasn't the move they made (it's still available to them!). Instead, developers started to notice: developers started to notice A ha! Microsoft doesn't just run the official marketplace, they also own some of the most popular extensions themselves, and these began to stop working on certain IDEs. This happened to coincide not only with the rise of Cursor, but also how the VSCode+Copilot combo was copying some of the features and UX that people were loving in these other IDEs, which has been covered by Patrick Debois in Copilot’s Quiet Comeback: GitHub’s AI Tool Isn’t Done Yet. Copilot’s Quiet Comeback: GitHub’s AI Tool Isn’t Done Yet I'm with Sam Denty, in the nuanced view of his thread. Sam knows this world well, since he worked at StackBlitz, with their browser based IDE (and now Bolt) that supports OpenVSX for the reasons we mentioned above. I'm with Sam Denty I want healthy competition. I want VSCode to open up more extension points so anyone can build great experiences without having to fork. I want changes to the marketplace rules so it can be more open. I want companies to be able to work together via open source so we can all gain from the rising tide (a la Chromium++). We are going through such an explosion in the world of development thanks to AI and the surfaces where we get to use it. What will be next? Will the companies with chess pieces on the board make moves that can help all? As developers what is our role to play? We can be clear on what we want to see… and we can adopt the tools that tie to our values.

Gitpod

OpenAI

OpenVSX, Cursor, and the Fight for an Open Development Future

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

8 AI Tools That You Should Be Excited About (And Adopt!)

The Noonification: How Often Do NFTs Pass The Howey Test? (1/13/2023)

Darwin's Hybrid Intelligence to Align AI & Human Goals for Startups & VCs

The Noonification: White Man (11/26/2022)

The Noonification: The Metaverse is a Sh*tshow (11/2/2022)

8 AI Tools That You Should Be Excited About (And Adopt!)

The Noonification: How Often Do NFTs Pass The Howey Test? (1/13/2023)

Darwin's Hybrid Intelligence to Align AI & Human Goals for Startups & VCs

The Noonification: White Man (11/26/2022)

The Noonification: The Metaverse is a Sh*tshow (11/2/2022)

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps