[frenchie4111]

Everyone is reading this as intentional anti-competitive practices. While that may be true, isn't another reasonable explanation that the Copilot development team is moving as fast as they can and these sorts of workarounds are being forced through in the name of team velocity? It takes a lot more time/energy to push public APIs and it's probably a very different team than the team developing the copilot extension. Seems a bit like a "don't attribute to malice..." kind of moment to me

[peeters]

> Everyone is reading this as intentional anti-competitive practices. While that may be true, isn't another reasonable explanation that the Copilot development team is moving as fast as they can and these sorts of workarounds are being forced through in the name of team velocity?

Wouldn't another way of saying that be "the Copilot development team is leveraging their Microsoft ownership to create products in a way not available to the general marketplace?"

The goal might not be to squash competition, but blessing one client with special treatment not available to others can still be anti-competitive.

Whether that would fall afoul of any regulation is beyond my expertise. Naively, most companies have internal APIs that are not generally available. But then most companies don't have paid public marketplaces on their platform.

[canes123456]

Is it even not available to competitors? Visual studio is open source. Didn't cusor fork it and is building it features directly into the fork? Not doing something like this would make Copilot at a disadvantage.

[hu3]

I agree. Apple has been doing this for years as well.

[gavinray]

Seems like the only sensible comment in this thread so far.

Here's what I imagine it's like working on the Copilot team:

  > Mgmt: "We need this feature, and we need in 2 weeks."
  > Devs: "That feature is not technically possible."
  > Mgmt: "Well, figure out a way to make it possible. That's _your_ problem."

[MadnessASAP]

That is exactly the sort of management that has landed many a company in hot mater before, including Microsoft.

Whether the managers remain ignorant by malice of incompetence is irrelevant. Directing your subordinate to do something that they should reasonably know would break the law or be anticompetitive is still illegal.

The see no evil defense is a piss poor defense that is more likely going to be used to show you knew exactly what was going on.

[Sakos]

This doesn't fly when you're a company the size of Microsoft with the kind of influence and power they have. You can't just ignore the possibility or effects of engaging in anti-competitive behavior simply because it's convenient for you. That's not how it works.

It's not sensible at all.

[milkytron]

Sounds like when Slack started taking marketshare from Skype for Business and they pushed out Teams as fast as possible.

[immibis]

Government: "We fine you two zillion dollars. You should have listened to the dev."

[rcarmo]

The few people I know in the Copilot team(s) (not necessarily VS Code) are laser focused on prioritizing features based on customer demand, not top-down guidance :)

[tristan957]

Are other extensions like Codeium[0] allowed to publish under the same rules? I'm not saying your comment is incorrect, but unless Copilot competitors can get the same treatment, it seems extremely unfair and anti-competitive.

[0]: https://marketplace.visualstudio.com/items?itemName=Codeium....

[ctoth]

So basically the same way XMLHttpRequest was born[0]?

[0]: https://web.archive.org/web/20060617163047/http://www.alexho...

[Suppafly]

>Everyone is reading this as intentional anti-competitive practices.

Even if it is anti-competitive, I don't care. Why should VS Code have to support alternative AI assistants in their software? I understand why people would want that, but I'm not sure why microsoft has some sort of ethical or legal burden to support it. Plus it's open source, competitors can take it for free and add their own co-pilots if they want.

[colechristensen]

>Why should VS Code have to support alternative AI assistants in their software?

Because of the dominant position of Microsoft in various markets.

[thiht]

> Plus it's open source, competitors can take it for free and add their own co-pilots if they want.

They can and they do. The process is working.

[daedrdev]

I think you’ve made a good point here, its not like they force you to have vscode. I feel like it wont be super popular here thoguh

[creata]

It doesn't matter much whether it's "intentional" or "malicious", though. It's still anticompetitive behavior.

[heavyset_go]

Hanlon's razor falls apart when it's used outside of personal relationships and in situations where billions of dollars are on the line.

There is no functional difference between a Microsoft that's really excited about Copilot so that it quickly integrates it into their products and a Microsoft that's hellbent on making sure Copilot gets to use secret APIs others can't.

[throwaway19972]

> Everyone is reading this as intentional anti-competitive practices

Who cares about intention? Anti-competitive behavior is anti-competitive behavior.

[ddalex]

Anti-competitive behavior is absolutely fine though when not illegal. I don´t see how vscode could be constructed as having a monopoly when cursor freely forked it.

[solardev]

Embrace.

Extend. <-- We are here.

Extinguish.

Microsoft. Microsoft never changes. https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

[jimmaswell]

where's the embrace step? vscode is their own product in the first place.

[kelnos]

It is really a shame to me that everyone believes Microsoft has changed and would never behave like they did in the 90s and prior. They haven't changed. They just decided -- for a time -- that another strategy was in their best interests. They're deciding that again, and going back to their EEE playbook.

(It also occurs to me that a lot of people here probably aren't old enough to remember 20th-century Microsoft...)

[Forgeties79]

>Seems a bit like a "don't attribute to malice..."

I'm not saying you are wrong or that the rest of your comment isn't pretty valid, but a lot of people attribute malice to microsoft out the gate because they have history of operating out of malice.

[duskwuff]

> It takes a lot more time/energy to push public APIs

And, once an API is public, it becomes a lot harder to make changes to it. Iterating with a private API, then making it public once you've figured out the problem space, is a valid and useful approach.

[Arainach]

Iterating on a private API is fine. Allowing your internal AI assistant to publish to the extension store while consuming those private APIs while prohibiting any competitors from doing so is not.

[nosioptar]

> Everyone is reading this as intentional anti-competitive practices.

I think its fair to assume anticompetitive intent due to their history of anticompetitive behavior. Admittedly, in old enough to remember the crap they pulled all through the 90s.

[Deukhoofd]

While I can understand the part about hidden APIs, as they're in flux and experimental, the part that's weird about it to me is the "you can totally build it and share it just not on our marketplace" part. That just sounds to me like they're trying to bar their competitors from the VSCode Marketplace, making installing and updating a lot harder for users.

[kelnos]

I don't care if it's malicious or not. The fact remains that this team is using their position inside Microsoft to make use of tools in another product that a competing product wouldn't get to use.

This is one of the things MS got sued for back in the 90s. They shouldn't be allowed to do this again.

[nolok]

I would maybe entertain that idea in a vacuum, but that's Microsoft and they already did that in both Windows and Office before so no.

[kburman]

fork vscode, do whatever you want. merge back when ready.

[ghuntley]

Won't really help ya. As outlined at https://ghuntley.com/fracture/ as soon as you compile "VSCode" (MIT) the ecosystem fractures in a bad way (tm) including no-license to run majority of MSFT extensions (Language LSPs, Copilot, Remote Development). If you are a vendor producing a MIT fork then one needs to iterate the graph and convince 3rd party extension authors to _not use the MSFT extensions_ as dependencies _and_ to publish on open-vsx.

This is how Cursor gets wrecked in the medium/long term. Coding agent? Cool. You can't use Pylance with it etc. VSCode degrades to being notepad.exe. MSFT uses Cursor for product research and then rolls out the learnings into Copilot because only Copilot supports all of "Visual Studio Code" features that users expect (and this is by design)

[RandomThoughts3]

> intentional anti-competitive practices

> moving as fast as they can and these sorts of workarounds are being forced through in the name of team velocity

It’s not an either/or. That’s the same thing. The second part is the anticompetitive practice.

Giving advantage to your own teams so they can be there first and uncontested is approximately as anticompetitive as it can get.

[chrsig]

> While that may be true, isn't another reasonable explanation that the Copilot development team is moving as fast as they can and these sorts of workarounds are being forced through in the name of team velocity?

this strikes me as most likely. it is anti-competitive, but it's probably not their motive.

[nikeee]

Also regarding the wording "Proposed API": This seems like it's just some kind of incubator for APIs before marking them as stable. So that copilot thing may just be their incubator project. It may be not though.

[Lramseyer]

Not malicious, but still selfish. It's important to remember that the copilot extensions are an extremely effective way of monetizing VScode. So it seems more like they're kind of compromising on their API usage rules in order to get to market quicker. But allowing themselves to use the APIs before anyone else is in a way anti-competitive, because the only way one could compete would be to use the unfinished APIs. But that requires users to go through more hoops to install your extension.

I should also mention that I am a VScode extension developer and I'm one of the weirdos that actually takes the time to read about API updates. They are putting in a lot of effort in developing language model APIs. So it's not like they're outright blocking others from their marketplace.

[radiojosh]

Your VaporView extension looks amazing! I can't even fathom how to get that far along in extension development.

Do you have any links or resources you could direct me toward that were more helpful than Microsoft's basic how-to pages for learning VS Code plugin development? I attempted to build a VS Code extension, but the attempt fizzled out. I managed to make some progress in creating the simplest of UI elements and populating them. I'm particularly interested in building a GUI-based editor of JSON / YAML where a user can select a value from a prepopulated dropdown menu, or validating a JSON / YAML file against a custom schema. Any help or advice you could provide would be appreciated!

[rcarmo]

Check my comment elsewhere (it's now bobbing up and down). Some things just take time, no need to assume malicious intent.

[cbhl]

Frankly if they shipped it with `enabledApiProposals` I'd even go further and assume that they actually _intend_ to release public APIs once they've baked.

Like, why go through the extra work of gating it under `enabledApiProposals` and using the public manifest flag when you could put code in VSCode itself that is like "oh if this extension is installed let me just run some secret code here in the binary".

[npteljes]

I think you are on the mark. And, also, it's a happy accident that this also means an advantage for CoPilot.

[aithrowawaycomm]

I would think this is less team velocity and more about LSP/etc. I am not an expert on how this is developed, but I imagine it will take at least a couple of years for the dust to settle to decide on good public API abstractions for LLM codegen, and they don’t want to introduce anything public that they have to maintain in concert with 3rd parties.

That’s not to say the general concern about GitHub-VSCode smothering competition isn’t valid, but I agree that it’s probably not what’s happening here.

[Log_out_]

Can you point me to an example were the initial maliciousness was reverted permanently later?

[throwaway48476]

Seems like a false dichotomy. Move fast is just a public undocumented unstable API.

[sirspacey]

Thank you. This needs to be said & should be reported.

If we want a world that isn’t massively hostile to devs, like it is for most companies, this is the kind of advocacy we need and I’d love to see more people in tech putting it out there.

[waveBidder]

Yeah, the fact that they have direct access to VScode is anti-competitive. It doesn't require intent, it's baked in to the org structure.

[timcobb]

Could be, but definitely worth flagging at the top of HN for everyone to see!

[Arainach]

Disclaimer: I used to work at Microsoft. These days I work at a competitor. All words my own and represent neither entity.

Microsoft has the culture and the technology to tell private and public APIs apart and to check code across the company to ensure that only public APIs are called. This was required for decades as part of the Department of Justice consent decree and every single product in the company had scanners to check that they weren't using any private APIs (or similar hacks to get access to them such as privately searching for symbols in Windows DLL files). This was drilled into the heads of everyone, including what I assume are 90% of VP+ people currently at the company, for a very long time.

For them to do this is a conscious decision to be anticompetitive.

[dchest]

What a coincidence, I was just browsing Microsoft's Go fork (for FIPS compatibility, basically replacing Go crypto with OpenSSL and whatever API Windows has, just like there's a Google's fork that uses BoringSSL), and found this patch:

https://github.com/microsoft/go/blob/microsoft/main/patches/...

Upstream Go tricks Windows into enabling long path support by setting an undocumented flag in the PEB. The Microsoft Go fork can't use undocumented APIs, so this commit removes the hack.

So, even if they fork something, they have to strictly follow this guideline and remove undocumented API usage. I wonder if this only applies to Windows APIs though.

[skissane]

> Microsoft has the culture and the technology to tell private and public APIs apart and to check code across the company to ensure that only public APIs are called. This was required for decades as part of the Department of Justice consent decree and every single product in the company had scanners to check that they weren't using any private APIs (or similar hacks to get access to them such as privately searching for symbols in Windows DLL files).

I thought that only applied to private Windows APIs?

The antitrust case was about the Windows monopoly specifically, so other MS products calling Windows private APIs was in its scope. But, this is more comparable to another MS product calling a private Visual Studio API – I don't believe that was in the scope of that antitrust case. Did Microsoft have policies and processes against that scenario too?

[SSLy]

vscode is developed by VPs borged from github, no? those wouldn't know. not that I approve such things, certainly not.