TL;DR Microsoft is breaking its open and extension-friendly ethos with VSCode in order to cripple GitHub Copilot competitors with restricted APIs.

Background

When Microsoft launched Visual Studio Code (VSCode) IDE in 2015, promising to open-source most, if not all, of the source code behind it, I was both excited and a little confused. Microsoft has a history of building solid products and distributing like no other. Surely enough, in last year’s StackOverflow developer survey, almost 75% of respondents said they used VSCode. And it isn’t necessarily surprising - VSCode has really good inbuilt debugging, syntax highlighting, Git integration, etc, but much more importantly, has a vibrant extension marketplace and flexible customization on pretty much every setting available. The openness, both from a source code and an external contributor aspect, is what makes VSCode special, not the former set of features. It is an IDE that is powerful right out of the box but doesn’t feel constrained in any real way.

But there was a thought nagging me the entire time - Microsoft isn’t necessarily known to just “be the good guy,” so there must be an ulterior motive for capturing developers on their platform. VSCode is free, so it wasn’t money. Almost all of the code was open source, so there isn’t a whole lot of secret IP, and it didn’t seem like any actually powerful logic was “hidden.” Given the number of popular extensions not built by Microsoft, the motive couldn’t be control over all use cases. And while telemetry does exist, this is pretty easily disabled (not to mention, the telemetry code is all public). What does Microsoft really get? Maybe in the beginning, telemetry was the real answer, from whichever developers didn’t opt out. But it turns out even Microsoft didn’t see the answer coming.

Without knowing it, Microsoft built VSCode for GitHub Copilot.

How GitHub Copilot Changes the VSCode Story

In case you’ve somehow missed it, there is general consensus that generative AI is going to change how people work, and that includes software developers. GitHub Copilot was the first tool that brought LLMs to devs via code autocomplete. Microsoft owns GitHub. You can see where this is going. While Microsoft can keep VSCode open and free, they can totally charge for GitHub Copilot while still looking like the good guys with respect to VSCode, and you better believe developers will pay. VSCode is Microsoft’s distribution channel to developers to upsell GitHub’s AI tools. There is no way Microsoft could have seen this coming in 2015, but they landed on the goldmine.

You don’t believe me yet? Just look at the VisualStudio home page:

By all intents and purposes, this page is just an ad for GitHub Copilot.⁽¹⁾

But here’s where things get a little complicated. VSCode claims to be both open and extension creator friendly. This is, after all, the main differentiator compared to other standalone IDEs. For a while, Copilot was the only generative-AI-for-developers tool out there, but now there’s a million. And GitHub is quickly figuring out that it is really easy for a small yet strong team to completely outperform and out-develop Copilot. Ourselves at Codeium started as a Copilot alternative, but now also offer chat and search on top of autocomplete, not to mention more advanced code LLMs and up-to-date, higher quality training datasets. In just 9 months, we have completely flown past more than 3 years of Copilot development.

And we publish our extension on VSCode.

So with a generational opportunity in generative AI at their hands with GitHub Copilot and ownership of the largest distribution channel with VSCode, Microsoft has a decision to make - does it stay true to the ethos of VSCode and allow for fair competition, or does it wield ownership over VSCode as a weapon to try to squash Copilot competitors?

Probably to no surprise, Microsoft has chosen the latter.

What Microsoft has been Secretly Hiding

To dive deeper, for VSCode, the Copilot pair programmer experience is enabled by an API called the InlineCompletionProvider in order to show and accept suggestions that weren’t really part of the code. That’s the same thing that we and all other tools that involve code completion use. Unfortunately for Microsoft, they can’t “un-open-source” this API since that would break tons of other extensions and is generally a really bad look if they want to maintain the “open” facade.⁽²⁾

But what’s in the past is done - now knowing they have GitHub Copilot, Microsoft can create new APIs that would be useful for Copilot development and never release them, inherently restricting competitors.

There are now several of these restricted APIs, such as in-editor chat. This in-editor chat API does feel like a great experience for a pair programming extension, but is completely restricted. Copilot now has this as a UX advantage, which is objectively against the ethos of being open and being extension creator friendly. We know at Codeium we just care about making the best product for software developers, and there is definitely something disappointing to know that there are things that exist that could help us achieve that dream, but just kept out of reach.

What this Means for Copilot Competitors

So what does this actually mean for other people developing AI assistance tools like us? Well, of course we would like Microsoft to not restrict the access to these obviously useful APIs, but we aren’t holding our breath.⁽³⁾ We are still huge fans of VSCode, its ethos, and the fact that we have the ability to even reach developers in the first place.

Yes these restricted APIs are obstacles, but honestly not huge ones. Luckily for us, there are a lot of VSCode APIs that already exist that enable a whole lot of creativity and possibilities. Like the in-editor chat API that I mentioned earlier was restricted? Well, we were able to create a side panel with a chat window and little CodeLens buttons on top of functions to integrate “in-editor” for our Codeium Chat experience, which has been a huge hit:

Also, people do use other IDEs, from Jetbrains to Vim to web IDEs like Jupyter notebooks. Sure, Microsoft might use the better GitHub Copilot experience in VSCode to attract more users to VSCode, but it generally is hard to convince developers to switch IDEs. We are relatively stubborn people when it comes to these things. So there are still a lot of developers where this isn’t even really an issue.

On top of that, we actually think our main differentiators have nothing to do with the UX itself, For example, for enterprises, we have the ability to self-host the Codeium system and then locally finetune our models on all existing company code to create personalized experiences that will vastly outperform Copilot’s (and our own) generic model.

Speaking of enterprises, it turns out that VSCode restricts these APIs via the extension store. That is, you aren’t allowed to publish extensions that use these APIs, but for our enterprise customers who can directly use VSIX files that we send them, these APIs are actually still usable. So the experience isn’t theoretically stifled for our enterprise customers at all, just our customers on our free individual offering.

So why did we write this? We saw this coming - we were under no illusions that Microsoft wasn't going to try to make the most out of the GitHub Copilot opportunity. But for all of the reasons above, we actually don’t think that it is all doom and gloom when it comes to our ability to create products significantly better than GitHub Copilot.

Our main reason for writing this is education, and confirm what most people expected all along - Microsoft is big tech, and they are cool with being open and developer friendly as long as it doesn’t infringe on their potential earnings.

Oh, and if you want to use Codeium for free instead of paying for Copilot:

(1) Yes this is the general Visual Studio homepage and not the Visual Studio Code specific homepage, and the ad is technically about Visual Studio 2022, but the whole point being made here is that Microsoft is clearly thinking about their IDEs as a way to promote GitHub Copilot.

(2) The history of InlineCompletionProvider is a bit more complicated, and the details actually further support the core thesis here. The InlineCompletionProvider actually did start as a “Proposed API” that only GitHub had access to for Copilot. Microsoft ended up opening the API for everyone, but you can still find people complaining about it from before that action. GitHub Copilot to this day has access to enhancements to this API (such as a callback that is triggered when a completion is accepted) that other extension developers do not have access to.

(3) Interesting historical aside: in the early 2000s Microsoft was sued for antitrust, and one of the conditions for the settlement at the time was to share Windows APIs with third party companies for a couple years. Not that we are holding our breath for such a case, but there is a real possibility of this future if differences in API access get more and more egregious.