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.
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."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.
It's not sensible at all.
[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...
(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.
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.
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?
https://github.com/microsoft/vscode/blob/main/src/vscode-dts...
And you can hardly find any public information about these APIs. Well, unless someone asks -- As of 2 years ago, they didn't have any plans to "finalize" these APIs, i.e. make them public. You are advised to find other workarounds (which do work).
https://github.com/microsoft/vscode-discussions/discussions/...
This is much less "harmful" than Copilot though, I guess.
I pay for Golang, it took me some time to acknowledge that an IDE is slower than a lightweight code editor such as VSCode, but it feels great to use a tool entirely crafted for a language.
Oh, huh, really? I didn't know that. I've always done Rust in neovim with coc.nvim and rust-analyzer (well, ever since the latter existed, anyway), and that's been more than sufficient.
JetBrains has a Rust IDE now, though it's not free. What else is out there...?
I'm worried that Microsoft is succeeding at making the semi-proprietary version of VSCode the only viable option, while keeping the OSS forks as second-class citizens at best.
And while some make the alegory to IE its not the same since its not pre-installed on every machine, nor are they forcing you to use it. So while yes they have a lot of market share, they have nothing stopping you from forking it yourself or just using a different editor.
The VS Code team has kept some APIs in this "preview" mode for many many years. https://github.com/microsoft/vscode/issues/59921 is just one example, which has been requested since early 2018!
Although I pretty much disagree with their entire design value system even on the technical and UI levels (especially the latter), and can't see why anyone puts up with Windows. But clearly many people do, so obviously I'm missing something.
Microsoft is only doing open source since it proved to be an extremely useful way of doing things, not because they turned into an altruistic company that started caring more about making the world a better place rather than making money.
What is Cursor doing that they couldn't do as an extension?
What better way to get primary real world usage before stabilizing?
I bet they'd love if there were a way to have trusted testers that they could _force_ to make timely updates like they likely can with Copilot.
Maybe they should look into Chrome's Origin Trial system and make time-limited API tokens so that extension developers know that features relying on experimental APIs will break, even if the API itself doesn't. That seems to keep causal usage at bay and make sure that trial developers stay on top of things.
Others can choose to use or not use vscode. If they concern about the telemetry, build themselves or use other code editor then.
It is "free". Anyone can make an extension using the API features. However they do not allow anyone other than themselves to bring it to market (i.e. the official extension marketplace).
Before you introduce public APIs you need a use case and someone to spearhead them and copilot is doing that.
As for Microsoft not allowing installs of stuff like live share on other forks I guess it is because they are seen as different products and not part of the vsc codebase itself.
I would understand if extension authors would complain about not being able to access the same apis (might be the case) but at the end of the day they can still fork and do whatever they prefer.
Lots of companies out there thrive on forking vsc, from gitpod, stackblitz, cursor and many others. But they can't possibly expect to have all proprietary plugins too.
What other code editor has ever been so impactful and open in the last decades?
(and that's why I use emacs...)
But you can't expect from Microsoft to also open and share every single tool for vsc itself, you're still free to implement it though.
VS Code + GitHub + OpenAI exclusivity deals + Copilot = The best tools available for close to free.
To use the latest features they will only be found on MS branded tools like the ones above.
With the competition getting eliminated with total MS coverage of the developer ecosystem with almost everyone sitting on GitHub using VSCode and OpenAI.
Monopoly with close to no competition all without any regulatory scrutiny has been achieved internally. With the extending being the extinguish.
If they get too annoying, like really forcing copilot or something like that, there are several other editors to choose from. Until this day comes I'm having a positive experience with VSC.
Microsoft has already made it difficulty to compete with their “free” by giving away enough and locking down parts that would allow competition to easily fork it (Python LSP, Extensions marketplace).
Vim and Emacs seem to be thriving but I wouldn’t call them drop in replacements.
https://survey.stackoverflow.co/2024/technology/#1-integrate...
https://github.com/neovim/neovim/wiki/Installing-Neovim/921f...
VS Code doesn't have a lock on market share for IDEs the way say Google does on search.
There are plenty of other options either with or without CoPilot.
If these aren't finished, that most likely means that they still haven't stabilized enough to go through the full support and release pipeline--that usually means documenting them, publishing a couple of reference development samples, doing a public announcement, i.e., the full nine yards of fostering adoption of the product feature.
Which you typically will only do once the "preview" is stable and flexible enough to pass muster.
I mean, it's not as if there isn't a huge API surface for the editor (the sample extensions repo is huge - https://github.com/microsoft/vscode-extension-samples), and there are already samples out there to extend the Copilot functionality: https://github.com/joyceerhl/vscode-mssql-chat (I wrote my own based off this one for a personal project)
So maybe consider that those things just take time to build out fully before assuming the worst?
This isn't about feelings. This is about a multi-billion dollar corporation doing whatever it wants, yet again, to the detriment of other players in the market. Empathy doesn't have a place here.
It really is tiring to see people who earn hundreds of thousands a year crying about a lack of empathy. What a joke.
When did they stop?
He's not the messiah, he's a naughty businessman!
(Note: I shot my HN account then because the majority of the MS stuff on here was utterly intolerable for many of us who have been MS devs/users since day zero and have the mental scarring)
Edit: remind me to post this when MS staff are still asleep next time...
Now, coming back to private APIs, it's hard to know whether this is because Microsoft intentionally wants to keep competition out, or it is just hard to standardize/finalize APIs. I do know that VSCode development team takes extreme care when it comes to their APIs -- new features can take years before they are ready (most recenly coverage APIs, for example), and they don't want to release something when it's not ready, and I respect that. And to be fair, they have a number of "inline completion" APIs standardized as both VSCode APIs and LSP protocol (upcoming). I'm sure there is a lot to be desired, but it should be a nuanced discussion instead of simply "Microsoft bad".
(I am a VSCode extension & LSP author, not affiliated with Microsoft at all)
The “if” is carrying a lot of weight.
It gives Microsoft a solid competitive edge and a form of vendor lock-in in their otherwise mostly open product.
We don’t know that they’ll be temporary forever.
> They've stated the purpose of these "proposed APIs"
Just like how they said recall would not be a required feature, but is a dependency of the file explorer in the next version of windows?
Microsoft will say whatever looks good for them, obviously.
> last decade
But we do from the last 11+ years ;)
I’d always err on the side of not trusting giant monopolistic corporations with a history of garnering good will to cash in on it later.
Especially when that company has been very aggressively inserting itself in nearly every JS projects dependency/software delivery pipelines.
I gain nothing by trusting them, but I stand to lose my project’s independence from them.
Maybe the vi crew is actually onto something.
The fullness of time usually proves my brain's initial impressions right, as it seems to be doing now with Visual Studio Code.
I can still remember the monthly paroxysm of bliss that radiated throughout Hackernews, regular as clockwork, timed with Microsoft's monthly VS Code drops. Glad to see it enter its trough of disillusionment, at least on Hackernews.
I don't care for it being in the news though.
Aint_nobody_got_time_for_that.mov
Given the utter malarkey that's transpired since with GNOME, including the crappy UI revamps, the slowness (in the Windows 7 days, it was literally better just to use Windows on aging hardware), and the arrogant devs reinventing Windows 8 poorly and not listening to what users actually want, nor allowing users to make changes, I've been VERY happy keeping my environment GNOME-free.