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.
I don’t know if it’s legal or not, IANAL, but it feels definitely anti competitive.
Sort of. The core is, and the installable binaries with telemetry and properietary extensions are not.
The open source, telemetry-free version of VSCode is called VSCodium: https://vscodium.com/
> Didn't cusor fork it and is building it features directly into the fork?
Yes, in their recent interview with Lex Fridman they argued that life as an extension is too limiting.
The main reason we criticise Microsoft for doing this and not them is just their size and market dominance.
Why jump through hoops to make competitors better able to hotwire their own AI into VSCode, or hotwire Copilot into their own IDE, when it's easier to iterate fast and remain unpredictable?
Because that is the competitive philosophy that allowed VS Code win in this space. It fits with that great quote from Bill Gates: "A platform is when the economic value of everybody that uses it, exceeds the value of the company that creates it."
By having VS Code give a priority to another MS/GitHub product that they aren't willing to give competitors, they're diminishing VS Code's value as a platform, and encouraging competitors to build their own IDEs rather than building on top of it.
Embrace, extend, and extinguish
`--->
Please consider what you are going to say before you say it.
If you want to have a discussion, then let's have one. Step one is to have the discussion in good faith. If you're not capable of that, then don't respond at all.
Do as I say , not as I do?
Consider how C# support in VSCode got nerfed recently:
https://news.ycombinator.com/item?id=31760684
https://github.com/dotnet/vscode-csharp/issues/5276
There was another event only a few months ago, but I can't find the reference.
The open source, telemetry-free version of VSCode is called VSCode. The VSCodium people simply build it for you and package it for you.
The sole thing you can actually download and run while calling it VS Code - a trademarked name - is neither open source nor telemetry-free.
If you choose to drive it, it's full price.
No it’s not. Visual Studio is a proprietary product and the latest version is Visual Studio 2022.
Visual Studio Code is open source, and it is about as close to Visual Studio as Lightning is to Lightning Bug.
https://news.ycombinator.com/item?id=41891653
https://news.ycombinator.com/item?id=41884187
https://news.ycombinator.com/item?id=41809351
https://news.ycombinator.com/item?id=41639205
https://news.ycombinator.com/item?id=41384888
Now, I'm not a big fan of VS Code as of lately. I find the changes, that first broke Customize UI + MonkeyPatch extensions to make it look not completely shit on macOS, and now the change that broke APC too that replaced the first two, completely user-hostile and the PM response in GH issues to that very poor. But this specific lie about what is OSS and what isn't, and how it's used annoys me a lot. You are not helping with the problem.
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."It's not sensible at all.
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.
[0]: https://marketplace.visualstudio.com/items?itemName=Codeium....
[0]: https://web.archive.org/web/20060617163047/http://www.alexho...
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.
Because of the dominant position of Microsoft in various markets.
They can and they do. The process is working.
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.
Who cares about intention? Anti-competitive behavior is anti-competitive behavior.
Extend. <-- We are here.
Extinguish.
Microsoft. Microsoft never changes. https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
Today's "embrace" is of the web dev ecosystem, which before VSCode's dominance consisted of Jetbrains, other IDEs, text editors, etc.
Now with VScode and Github, they control much of the dev ecosystem, shrink competitors' marketshares by making them free to end-users (subsidized by other Microsoft businesses), expand them with new capabilities (even before secret APIs), etc.
(It also occurs to me that a lot of people here probably aren't old enough to remember 20th-century Microsoft...)
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.
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.
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.
This is one of the things MS got sued for back in the 90s. They shouldn't be allowed to do this again.
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)
> 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.
this strikes me as most likely. it is anti-competitive, but it's probably not their motive.
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.
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!
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".
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.
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.
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.
Other way around:
In 2011 [Erich Gamma] joined the Microsoft Visual Studio team and leads a development lab in Zürich, Switzerland that has developed the "Monaco" suite of components for browser-based development, found in products such as Azure DevOps Services [0]
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?
This means that Office shouldn't use private Windows APIs and pin itself to the taskbar. It means that Surface shouldn't have special integrations (whether with Windows, Copilot, or whatever) that aren't available to third parties. It means that Azure shouldn't build things that are only available to Office. You build for the platform. The push was originally around a legal mandate, but it turns into a culture.
Whatever the scope of the legal mandate was, it expired over a decade ago now.
Culture can change over time. Even if Microsoft had this culture strongly when you worked there, it might have become much weaker in the years since. Within a corporation, culture can also vary a lot between different teams/divisions/etc - maybe it is still strong in some parts of the company but gone in others.
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.