I think VS code - or rather, Language Server Protocol - was a successful execution of a combination of "fire and motion" and "commoditize your complement".

LSP commoditized IDEs, by disentangling IDE features from underlying programming language. To be honest, I'm very grateful for that - that's how I get to write C++ in Emacs, with clangd and lsp-mode, and enjoy most of the benefits of Visual Studio at fraction of performance price (and crashes). What were IDEs complementary to, for Microsoft? Not sure, but I'm guessing the Azure platform.

As for fire and motion - it so happens that LSP is intrinsically tied to VS Code. It may be an open protocol, but VS Code is essentially the reference implementation, so the protocol is shaped by the needs and ideas of Microsoft. Language server development gets directed by MS, while LSP clients play constant catch-up game with VS Code, leading more and more developers to switch to the latter.

I'm not sure whether to consider this a good or bad development: it's pretty clear Microsoft is doing this (and other things, like GitHub acquisition) to cast their nets over the whole practice of software development - but on the other hand, LSP is a genuine improvement for the industry, and huge at that, and with pretty much no strings attached.

VS reboot is probably how they sold it internally, but it really really is Microsoft's way of saying "don't look at our Windows spyware and other nasty things we do which actually matter in the real world, look at this cool open source project!".

Out of curiosity, are you a VS code user? And did you switch to it from VS or another IDE?

I have experience using VS from work and other (open-source) IDEs from hobby projects.

Coming from open-source, VS Code seems pretty large, unwieldy, and corporate.

Coming from VS, VS Code is reactive, flexible, configurable, and modern.

What I want to say is that "A fresh reboot of VS" isn't just a marketing gimmick, it's something that I would think many VS users (especially those that haven't gotten used to VS's oddities for 10 years) have been clamoring for.

As someone who, after fond childhood memories, wanted to give modern VS a shot on a large C++ codebase, and immediately retreated back into Emacs, I have to agree: VS Code is a breath of fresh air, and a promise of a better IDE.

I mean that wrt. the state of Visual C++ - I spent months coding in unaugmented Emacs, without support of LSP[0], running build commands manually, because that was more productive than VC++ that would regularly freeze or crash for no reason. The only reason I keep it around now is because I need its build tools, and because of its debugger, which works great[1].

It's a stark difference compared to my experience with Visual C#, which I consider a solid, robust product.

--

[0] - Took me a while to block off some time and get clangd to work with the idiosyncrasies of both the codebase and my Emacs setup; now that I've done that, I'm a happy camper and need VS Code no more.

[1] - Of course, I invoke it on demand via `devenv /debugexe`, not by keeping the project open in Visual Studio. On that note - if anyone knows a good replacement for MSVC debugger, I'd love to try it. Extra points if it works with Debug Adapter Protocol - though as far as I can tell, there aren't any DAP-compatible debuggers for C++ outside of vscode-cpptools.

One man's spyware is another man's telemetry

Why not both? I don't think anybody disagrees with the idea that telemetry is useful, and that there are genuine reasons to implement it in VScode (as well as other MS products). Heck, there are open source telemetry products and even Linux users happily install telemetry packages such as popularity-contest.

The only thing that bothers people is how this tech has been implemented by Microsoft in their product, with all possible dark patterns, starting with opt-out to changing telemetry controls subsequent versions to not being able to opt out at all, depending on the product.

Although some components like e.g. microsofts C++ extension are not open source (or at least only partially open source)