Open-source-washing has become a common practice: a company releases just enough of sources that people can’t criticise the product for being proprietary, but ensure that open-source builds are sidelined enough that everyone will use their closed-source binary anyway.
Android has perfected this. It pretends to be open-source, until you realize that AOSP is not Android. It is designed to be an inferior version with app compatibility problems and lacking access to flagship Android features like advanced cameras.
Similarly, you can’t build Chrome from source either. The Chrome you have is a closed-source binary with just enough of Chromium existing that you don’t worry about the DRM and whatnot that Google added.
Honest question: Did something change with Chromium? I had it on a few laptops for a while and except Google Hangouts I never experienced a single issue that impacted me working with it as my main browser, but that was at an old job until 2017.
Seems stable, no issues noted, just upgraded to 107.0.5304.68 from my package manager which dropped… yesterday. Been using it daily for many years. Couldn’t be happier.
I think OPs concerns are well-placed, but proprietary Android / Chromium fork(s) are what they are.
Corporations being evil and untrustworthy isn’t new, and the folks that contribute to (and ensure the usefulness of) the open source versions (to say nothing of users like me) are the real heroes of this story.
That really is not the case with VSCode though. VSCode is open source, period. Saying it’s not or that it’s « open source washing » is dishonest at best.
Some extensions are not open source, so what? They’re extensions. Anyone can make an open source version if they want. And some people actually do it.
Some extensions are not open source, so what? They’re extensions. Anyone can make an open source version if they want. And some people actually do it.
I would agree with you if you were just talking about random extensions. But that’s not the case. Not only are some extensions not open, they’re provided by Microsoft. And besides that, the agreements you have to accept in order to use them state that you can only use them if you also use Microsoft’s build of VS Code. Which has telemetry and such enabled. And on top of that, they’re the defaults if you work with the languages or file formats they touch.
That, for me, is a stretch beyond “They’re extensions.” (implying it’s just as useful without them) and “Anyone can make an open source version”. And I think this article, if you read it, outlined that reasonably well.
Because of that, I don’t think calling VS Code “open source washing” is dishonest at all. It’s absolutely being used to induce the use of proprietary extensions written by its authors and delivered as the defaults. We can disagree whether that’s “open source washing” or not. But it’s extremely bad faith to call that dishonest. I’m 100% sure OP was making an honest argument when they said that.
Marketplace Offerings are intended for use only with Visual Studio Products and Services and you may only install
and use Marketplace Offerings with Visual Studio Products and Services.
The Marketplace enables you to access or purchase products or services which are designed to work with and extend the capabilities of Microsoft Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, Team Foundation Server and successor Microsoft products and services (collectively, the “Visual Studio Products and Services”).
There’s nothing about “Microsoft’s build of VS Code”. I can see this being interpreted as how the OP wrote it, but I can also envision this as Microsoft saying if you want to use the marketplace, you need to use Visual Studio Code (or those other products), and from there we can speculate reasons. Other than that it’s got nothing to do with extensions but the marketplace itself.
So… take it all as you will. To me this reinforces my perception that Microsoft isn’t up to anything malicious in this case - they’ve found a “business configuration” that works with FOSS. As others have said I’m not even sure what’s to extinguish here. VS Code itself can be forked and maintained…
There’s nothing about “Microsoft’s build of VS Code”.
Only Microsoft can call their build of the codebase “Visual Studio Code”. I’m not allowed to compile it myself and call it that. I don’t see any way to interpret those terms of use in a way that lets me use my own build of that software (my build is not a “Visual Studio Product”) with the marketplace.
Furthermore, looking at this issue I don’t see how it’s possible to distribute a build of the software that uses the extensions marketplace.
That extension depends on pylance. Pylance is not open-source, and you don’t have the right to distribute it. If you want your users to use it with your build of MS’s open source release of VS Code (which, to be clear, is the only way for you to give users of your build the same python experience that users of MS’s get), the only path I can see is through the extension marketplace. Which is clearly disallowed.
I’m not sure this is a sign of malicious behavior, and if I made it sound that way, then I overstated my thoughts. But I am sure it’s an attempt, for some reason, to give a FOSS-y appearance to something that is meaningfully different from FOSS. Which makes the “open washing” verbiage in OP ring true for me.
That’s mostly accurate, to my eye. Though I think the extensions themselves (like the python/pylance example I cited) have license issues that induce the “papercuts” OP alluded to. Python is the space I care about here, but I expect I’d find something similar in .NET if I dug in there.
VS Code is not distributed under an open-source license, but a proprietary EULA. If you make your own build, it won’t have the exact same functionality as VS Code due to licensing restrictions.
Addition of proprietary code via extension interface is a clever licensing workaround. If the same code was built-in into VS Code you could clearly see that it’s a proprietary product a’la source-available or open-core model. But making it an extension is the “open-source washing” move I’m talking about. It makes VS Codium technically purely open-source, and yet most users use a build under a proprietary EULA and rely on proprietary extensions that the open-source build of the same application is not allowed to use.
BTW: I don’t mean it’s necessarily bad, but rather highlight it’s not the same thing as a regular open-source or libre project. Having a product mostly open-source and forkable with some effort is still better than a purely closed product. And having a proprietary product is fine too. Just beware of projects that try to have it both ways.
Is it designed to fracture, or not designed to unite? Both can cause the same conclusions but the framing is entirely different. I feel like it may be the latter.
Defaulting to proprietary extensions only usable on the proprietary build of VSCode, and NOT the open source build? Definitely designed to fracture. The vast majority of users don’t know or care about the language integration extension licenses. They will just know that using OSS derivatives of VSCode means they can’t use any of the extensions they are used to.
I have a pretty favorable view of Microsoft these days, and I like to assume people generally act in good faith, but this is clearly embrace, extend, extinguish all over again. Or at least embrace, extend, become the de facto standard and gain the lions share of the market without technically extinguishing anything. As the author points out, high quality competitors like JetBrains exist and do well.
What are they trying to extinguish? Jetbrains? Microsoft can’t really see Jetbrains as a threat. They wouldn’t even register on the C-level dashboard.
Microsoft has at least 400x Jetbrains’ revenue (based on 2020 numbers for both companies, it’s certainly a much bigger gap now), and this isn’t a market that’s going to grow by orders of magnitude like when they killed Netscape. I can’t see them bothering trying to extinguish anyone in the development tools space.
Disclaimer: I work for MS, but I am not involved in VS Code (and don’t use it because the remote extension doesn’t work with FreeBSD or other unusual platforms and so I’d have to switch editors for a bunch of places where I can’t use VS Code and I don’t want to confuse my fingers).
My impression is that the strategy for VS Code and a bunch of other things from DevDiv is not about extinguishing anything, it’s about not being extinguished. Historically, Microsoft made great dev tools and these encouraged people to build things that locked folks into their platforms. Now, with Mac and Linux being common systems for developers to run, supporting Microsoft platforms (even Azure, which focuses quite heavily on Linux hosting) is often an afterthought. If someone develops a .NET service with VS Code, there’s a lot more of a chance that they’ll think of Azure Functions instead of AWS Lambda as a deployment platform (for example) than if they write it in a purely Linux or Mac-focused environment.
Again, this is just my impression, but Microsoft is not trying to extinguish F/OSS for a couple of reasons:
These are the ecosystems where we hire engineers from. If we alienate them, our talent pipeline dries up.
We make a ton of money selling cloud services to folks that want to run F/OSS. With confidential cloud computing, we can offer the kinds of very strong privacy guarantees to small players (even individuals) that you could previously get only with hosting your own infrastructure. F/OSS developers are a huge market of people who build services on the kind of infrastructure that we’re building.
I’ve had few conversations with CVPs who are still a bit confused about how the open source ecosystem works and how best to contribute, but they’ve all been positive about the idea. For a lot of things, our policy is to open source unless there is a compelling business reason not to (whereas, apparently, a few years before I joined to default was to keep proprietary and open sourcing needed business justification). That’s a huge attitude shift, but in a company of over a hundred thousand people it takes a while a propagate everywhere.
Thanks for commenting on this. My (uninformed) take was similar - I think MS missed an entire generation of programmers for whom paying $$$ for a Visual Studio license was not only laughable - it wasn’t needed. They were making money not using MS tools.
I’m just a casual VS Code user, so I don’t know if there’s a market for proprietary, paid extensions. This would also track with MS historically - make it easy to code for MS products, and make money doing so.
I would argue it is indeed designed to fracture because it’s open source(ish), encouraging others to adopt it for their own projects (like Gitpod, as detailed in the article). That said I’m not quite sure how I’d frame it as “not designed to unite” so perhaps I’m misinterpreting.
Make those [proprietary] extensions the best version possible … .
This seems to be the key thing: the problem is that a corporation with money and domain expertise builds a better thing than OSS community, and doesn’t make it open, with various spill-over effects.
So I always use nix’s home-manager to set up VSCodium, which lets you specify market extensions. I suspect you might be using it too… do you know if this breaks the terms of service or anything?
LSP is worrying to me as well but I can’t quite explain why yet. It is scary that many community efforts have been abandoned in the rush to embrace LSP, an abstraction controlled and potentially limited by Microsoft. This puts them in a strategically advantageous position to control what sorts of dev features the OSS community can get. Meanwhile it seems full Visual Studio doesn’t use LSP for its most powerful features.
LSP is a protocol, not a technology. It’s actually one the best thing that could have happened for future editors and IDE: you just need to support LSP and you get compatibility with all the languages for free. Getting proper language support in editors was a pain before LSP.
It doesn’t prevent IDEs to support more than LSP, but LSP is now the bare minimum that we can expect to have anywhere. This is a great thing.
LSP is a good thing, but the fact that its effectively under Microsoft control is not. My main gripe about it is that to make the life of some VSCode developer easier, they decided all locations in LSP would be encoded as UTF-16 offsets from the start of the buffer (buffers themselves must be transfered in UTF-8 encoding, go figure). Every single LSP implementation now needs to have a UTF-8 to UTF-16 offset computation logic to be compliant.
I believe this could have been fixed if LSP had been a community project, because at the time this was widely noticed most LSPs implementations were just passing along byte offsets or codepoint offsets, so we could have just fixed the few implementations that used UTF-16 offsets and changed the spec. Unfortunately Microsoft has full control over the spec so nothing was changed and all LSP implementation had deal with that unnecessary complexity.
That particular problem was fixed in the latest version, from the change log
Add support to negotiate the position encoding.
But yeah, I also have gripes with what LSP technically is, and it’s stewardship.
For this reason (but moreso due to general architectural sanity), I strongly recommend to not hard-code LSP as a core domain model, but rather treat it as a serialization layer:
On the servers, produce a library for semantic analysis of code with language-specific APIs. You don’t have to make library’s API public/stable, just make sure it exists internally.
On the client side, provide hooks to populate completions, outline, symbol search, etc, but leave it up to an extension to wire those with LSP. These days we have LSP built into vim & emacs, but there’s no LSP support in VS Code. The just have an npm LSP library, which extension authors can choose to use.
I love LSP, the fact that I can use a fringe editor and get all the same language integration features of VSCode is amazing. Sure, it doesn’t get me the whole ecosystem of vim or emacs plugins, or every feature of intellisense, but it’s so much more than nothing.
If you had told me 15 years ago that such a thing would get traction, and that Microsoft of all people would be driving it, I would have guffawed my coffee all over the table.
Context: the ones I use are rust-analyzer/kakoune. I don’t think MS itself is involved in the stack at all, even in a legal sense.
I generally think LSP is great for allowing other editors to exist (while it’s not as good as stuff like PyCharm/VS classic, its basically better than everything else that was offered before).
However, one nasty thing that happens is that each language gets, roughly, the one blessed LSP client. In Python’s case, that has ended up being MSFT’s non-OSS client. It totally sucks the oxygen out of the room for alternatives, and it’s such a hard problem to begin with. Honestly not great.
Praising Microsoft/Big Companies for VS Code is like Stockholm’s syndrome. They get much more value from open source than they give back. I doubt the source code from windows is so sensitive that they can’t publish more of it.
I wonder how much of the blame is on the FLOSS movement. Let’s face it, the products of the FLOSS community are hard to use and very rough. Then along comes MS that pays developers and most importantly designers and UX people to actually put out something usable and people go for it.
It’s a similar discussion to “how much farther along the movement could be without Stallman”, or how apps are crap now because of Electron - but there are no good multiplatform UI toolkits, so people just use what solves their problems. And increasingly more of the times, seems like FLOSS ain’t it. MS saw that convenience is the Aquilles heel of FLOSS, and went for it.
Do you have evidence for your claim? I used to run a Linux users’ group which had an explicit commitment to not discriminating against folks because of their choice of text editor, and folks chose Vim and Emacs over other alternatives.
I think once you know vim and emacs, they’re so good that you don’t want to pick anything else (or maybe it’s just Stockholm Syndrome?). And most people probably learn them because they have this air of mastery and hacker coolness, not to mention a huge promise of increased productivity about them. However, they are not easy to learn. I guess that’s what @sardaukar means by “usable” - easy to pick up without first studying and training for at least a few weeks before you become at least somewhat productive.
I think in the case of VS Code this cuts much deeper than UX. The main value add of VS Code is not a pretty UX. Rather, it’s that the product as a whole provides semantic assistance when writing code, it’s a Post-IntelliJ tool. Delivering that requires specific technical know-how about building compilers which are good not only for batch-transforming source to object files, but also at providing on-the-fly completion, navigation and other IDE fluff. That’s very technical, compiler knowledge, but it also isn’t really a rocket science: we knew how to do this since at least (checks the date on Fowler’s post) 2005.
It’s just that OSS didn’t start building these kinds of tool at all, until Microsoft didn’t create the expectation, via LSP&TypeScript, that that’s how every language should work.
I much prefer the clean and ultra fast Sublime Text interface. Like a terminal, the screen is fully used up by code. VSCode has too much padding and margins for my taste - the screen looks busy. I also really love VIM bindings.
But VsCode mostly just works, while I lost my patience trying to setup Neovim LSPs and others.
I really would like a sublime or vim editing experience with the ease of use of VSCode.
I am hoping that Helix adds Copilot support though. Helix is so fast and pretty.
Yeah. I don’t like VS Code as my main editor that I use daily. I love VS Code for random one-off editing. It’s never 100% like IntelliJ, but it’s 80% without any effort.
Open-source-washing has become a common practice: a company releases just enough of sources that people can’t criticise the product for being proprietary, but ensure that open-source builds are sidelined enough that everyone will use their closed-source binary anyway.
Android has perfected this. It pretends to be open-source, until you realize that AOSP is not Android. It is designed to be an inferior version with app compatibility problems and lacking access to flagship Android features like advanced cameras.
Similarly, you can’t build Chrome from source either. The Chrome you have is a closed-source binary with just enough of Chromium existing that you don’t worry about the DRM and whatnot that Google added.
Honest question: Did something change with Chromium? I had it on a few laptops for a while and except Google Hangouts I never experienced a single issue that impacted me working with it as my main browser, but that was at an old job until 2017.
Posting using Chromium.
Seems stable, no issues noted, just upgraded to 107.0.5304.68 from my package manager which dropped… yesterday. Been using it daily for many years. Couldn’t be happier.
I think OPs concerns are well-placed, but proprietary Android / Chromium fork(s) are what they are. Corporations being evil and untrustworthy isn’t new, and the folks that contribute to (and ensure the usefulness of) the open source versions (to say nothing of users like me) are the real heroes of this story.
That really is not the case with VSCode though. VSCode is open source, period. Saying it’s not or that it’s « open source washing » is dishonest at best.
Some extensions are not open source, so what? They’re extensions. Anyone can make an open source version if they want. And some people actually do it.
I would agree with you if you were just talking about random extensions. But that’s not the case. Not only are some extensions not open, they’re provided by Microsoft. And besides that, the agreements you have to accept in order to use them state that you can only use them if you also use Microsoft’s build of VS Code. Which has telemetry and such enabled. And on top of that, they’re the defaults if you work with the languages or file formats they touch.
That, for me, is a stretch beyond “They’re extensions.” (implying it’s just as useful without them) and “Anyone can make an open source version”. And I think this article, if you read it, outlined that reasonably well.
Because of that, I don’t think calling VS Code “open source washing” is dishonest at all. It’s absolutely being used to induce the use of proprietary extensions written by its authors and delivered as the defaults. We can disagree whether that’s “open source washing” or not. But it’s extremely bad faith to call that dishonest. I’m 100% sure OP was making an honest argument when they said that.
Well I’m baited. After doing some personal hunting, here’s what I’ve found.
The quoted statement is false.
Reference: https://cdn.vsassets.io/v/M146_20190123.39/_content/Microsoft-Visual-Studio-Marketplace-Terms-of-Use.pdf
The statement must be referring to this:
There’s nothing about “Microsoft’s build of VS Code”. I can see this being interpreted as how the OP wrote it, but I can also envision this as Microsoft saying if you want to use the marketplace, you need to use Visual Studio Code (or those other products), and from there we can speculate reasons. Other than that it’s got nothing to do with extensions but the marketplace itself.
The Python extension, by Microsoft, is MIT. https://openvsxorg.blob.core.windows.net/resources/ms-python/python/2022.16.1/LICENSE.txt
So… take it all as you will. To me this reinforces my perception that Microsoft isn’t up to anything malicious in this case - they’ve found a “business configuration” that works with FOSS. As others have said I’m not even sure what’s to extinguish here. VS Code itself can be forked and maintained…
Only Microsoft can call their build of the codebase “Visual Studio Code”. I’m not allowed to compile it myself and call it that. I don’t see any way to interpret those terms of use in a way that lets me use my own build of that software (my build is not a “Visual Studio Product”) with the marketplace.
Furthermore, looking at this issue I don’t see how it’s possible to distribute a build of the software that uses the extensions marketplace.
That extension depends on pylance. Pylance is not open-source, and you don’t have the right to distribute it. If you want your users to use it with your build of MS’s open source release of VS Code (which, to be clear, is the only way for you to give users of your build the same python experience that users of MS’s get), the only path I can see is through the extension marketplace. Which is clearly disallowed.
I’m not sure this is a sign of malicious behavior, and if I made it sound that way, then I overstated my thoughts. But I am sure it’s an attempt, for some reason, to give a FOSS-y appearance to something that is meaningfully different from FOSS. Which makes the “open washing” verbiage in OP ring true for me.
(mobile reply) It seems the real issue is the marketplace and not so much the extensions themselves is what i mean :)
That’s mostly accurate, to my eye. Though I think the extensions themselves (like the python/pylance example I cited) have license issues that induce the “papercuts” OP alluded to. Python is the space I care about here, but I expect I’d find something similar in .NET if I dug in there.
VS Code is not distributed under an open-source license, but a proprietary EULA. If you make your own build, it won’t have the exact same functionality as VS Code due to licensing restrictions.
Addition of proprietary code via extension interface is a clever licensing workaround. If the same code was built-in into VS Code you could clearly see that it’s a proprietary product a’la source-available or open-core model. But making it an extension is the “open-source washing” move I’m talking about. It makes VS Codium technically purely open-source, and yet most users use a build under a proprietary EULA and rely on proprietary extensions that the open-source build of the same application is not allowed to use.
BTW: I don’t mean it’s necessarily bad, but rather highlight it’s not the same thing as a regular open-source or libre project. Having a product mostly open-source and forkable with some effort is still better than a purely closed product. And having a proprietary product is fine too. Just beware of projects that try to have it both ways.
Is it designed to fracture, or not designed to unite? Both can cause the same conclusions but the framing is entirely different. I feel like it may be the latter.
Defaulting to proprietary extensions only usable on the proprietary build of VSCode, and NOT the open source build? Definitely designed to fracture. The vast majority of users don’t know or care about the language integration extension licenses. They will just know that using OSS derivatives of VSCode means they can’t use any of the extensions they are used to.
I have a pretty favorable view of Microsoft these days, and I like to assume people generally act in good faith, but this is clearly embrace, extend, extinguish all over again. Or at least embrace, extend, become the de facto standard and gain the lions share of the market without technically extinguishing anything. As the author points out, high quality competitors like JetBrains exist and do well.
What are they trying to extinguish? Jetbrains? Microsoft can’t really see Jetbrains as a threat. They wouldn’t even register on the C-level dashboard.
Microsoft has at least 400x Jetbrains’ revenue (based on 2020 numbers for both companies, it’s certainly a much bigger gap now), and this isn’t a market that’s going to grow by orders of magnitude like when they killed Netscape. I can’t see them bothering trying to extinguish anyone in the development tools space.
Disclaimer: I work for MS, but I am not involved in VS Code (and don’t use it because the remote extension doesn’t work with FreeBSD or other unusual platforms and so I’d have to switch editors for a bunch of places where I can’t use VS Code and I don’t want to confuse my fingers).
My impression is that the strategy for VS Code and a bunch of other things from DevDiv is not about extinguishing anything, it’s about not being extinguished. Historically, Microsoft made great dev tools and these encouraged people to build things that locked folks into their platforms. Now, with Mac and Linux being common systems for developers to run, supporting Microsoft platforms (even Azure, which focuses quite heavily on Linux hosting) is often an afterthought. If someone develops a .NET service with VS Code, there’s a lot more of a chance that they’ll think of Azure Functions instead of AWS Lambda as a deployment platform (for example) than if they write it in a purely Linux or Mac-focused environment.
Again, this is just my impression, but Microsoft is not trying to extinguish F/OSS for a couple of reasons:
I’ve had few conversations with CVPs who are still a bit confused about how the open source ecosystem works and how best to contribute, but they’ve all been positive about the idea. For a lot of things, our policy is to open source unless there is a compelling business reason not to (whereas, apparently, a few years before I joined to default was to keep proprietary and open sourcing needed business justification). That’s a huge attitude shift, but in a company of over a hundred thousand people it takes a while a propagate everywhere.
Thanks for commenting on this. My (uninformed) take was similar - I think MS missed an entire generation of programmers for whom paying $$$ for a Visual Studio license was not only laughable - it wasn’t needed. They were making money not using MS tools.
I’m just a casual VS Code user, so I don’t know if there’s a market for proprietary, paid extensions. This would also track with MS historically - make it easy to code for MS products, and make money doing so.
Microsoft is trying to extinguish free software in general, and this is just a part of it.
I don’t really believe that’s the case.
I do. Just look at their actions.
I would argue it is indeed designed to fracture because it’s open source(ish), encouraging others to adopt it for their own projects (like Gitpod, as detailed in the article). That said I’m not quite sure how I’d frame it as “not designed to unite” so perhaps I’m misinterpreting.
Ha, that’s definitely a possible perception too :D. I like it.
This seems to be the key thing: the problem is that a corporation with money and domain expertise builds a better thing than OSS community, and doesn’t make it open, with various spill-over effects.
So I always use nix’s
home-managerto set up VSCodium, which lets you specify market extensions. I suspect you might be using it too… do you know if this breaks the terms of service or anything?Not really, I don’t use home-manager, just old-style repo with dotfiles and a plaintext list of extensions, and I use Microsoft’s VS Code.
LSP is worrying to me as well but I can’t quite explain why yet. It is scary that many community efforts have been abandoned in the rush to embrace LSP, an abstraction controlled and potentially limited by Microsoft. This puts them in a strategically advantageous position to control what sorts of dev features the OSS community can get. Meanwhile it seems full Visual Studio doesn’t use LSP for its most powerful features.
LSP is a protocol, not a technology. It’s actually one the best thing that could have happened for future editors and IDE: you just need to support LSP and you get compatibility with all the languages for free. Getting proper language support in editors was a pain before LSP.
It doesn’t prevent IDEs to support more than LSP, but LSP is now the bare minimum that we can expect to have anywhere. This is a great thing.
LSP is a good thing, but the fact that its effectively under Microsoft control is not. My main gripe about it is that to make the life of some VSCode developer easier, they decided all locations in LSP would be encoded as UTF-16 offsets from the start of the buffer (buffers themselves must be transfered in UTF-8 encoding, go figure). Every single LSP implementation now needs to have a UTF-8 to UTF-16 offset computation logic to be compliant.
I believe this could have been fixed if LSP had been a community project, because at the time this was widely noticed most LSPs implementations were just passing along byte offsets or codepoint offsets, so we could have just fixed the few implementations that used UTF-16 offsets and changed the spec. Unfortunately Microsoft has full control over the spec so nothing was changed and all LSP implementation had deal with that unnecessary complexity.
That particular problem was fixed in the latest version, from the change log
But yeah, I also have gripes with what LSP technically is, and it’s stewardship.
For this reason (but moreso due to general architectural sanity), I strongly recommend to not hard-code LSP as a core domain model, but rather treat it as a serialization layer:
On the servers, produce a library for semantic analysis of code with language-specific APIs. You don’t have to make library’s API public/stable, just make sure it exists internally.
On the client side, provide hooks to populate completions, outline, symbol search, etc, but leave it up to an extension to wire those with LSP. These days we have LSP built into vim & emacs, but there’s no LSP support in VS Code. The just have an npm LSP library, which extension authors can choose to use.
I love LSP, the fact that I can use a fringe editor and get all the same language integration features of VSCode is amazing. Sure, it doesn’t get me the whole ecosystem of vim or emacs plugins, or every feature of intellisense, but it’s so much more than nothing. If you had told me 15 years ago that such a thing would get traction, and that Microsoft of all people would be driving it, I would have guffawed my coffee all over the table.
Context: the ones I use are rust-analyzer/kakoune. I don’t think MS itself is involved in the stack at all, even in a legal sense.
Edit: spelling
I generally think LSP is great for allowing other editors to exist (while it’s not as good as stuff like PyCharm/VS classic, its basically better than everything else that was offered before).
However, one nasty thing that happens is that each language gets, roughly, the one blessed LSP client. In Python’s case, that has ended up being MSFT’s non-OSS client. It totally sucks the oxygen out of the room for alternatives, and it’s such a hard problem to begin with. Honestly not great.
Praising Microsoft/Big Companies for VS Code is like Stockholm’s syndrome. They get much more value from open source than they give back. I doubt the source code from windows is so sensitive that they can’t publish more of it.
I wonder how much of the blame is on the FLOSS movement. Let’s face it, the products of the FLOSS community are hard to use and very rough. Then along comes MS that pays developers and most importantly designers and UX people to actually put out something usable and people go for it.
It’s a similar discussion to “how much farther along the movement could be without Stallman”, or how apps are crap now because of Electron - but there are no good multiplatform UI toolkits, so people just use what solves their problems. And increasingly more of the times, seems like FLOSS ain’t it. MS saw that convenience is the Aquilles heel of FLOSS, and went for it.
Do you have evidence for your claim? I used to run a Linux users’ group which had an explicit commitment to not discriminating against folks because of their choice of text editor, and folks chose Vim and Emacs over other alternatives.
I think once you know vim and emacs, they’re so good that you don’t want to pick anything else (or maybe it’s just Stockholm Syndrome?). And most people probably learn them because they have this air of mastery and hacker coolness, not to mention a huge promise of increased productivity about them. However, they are not easy to learn. I guess that’s what @sardaukar means by “usable” - easy to pick up without first studying and training for at least a few weeks before you become at least somewhat productive.
I think in the case of VS Code this cuts much deeper than UX. The main value add of VS Code is not a pretty UX. Rather, it’s that the product as a whole provides semantic assistance when writing code, it’s a Post-IntelliJ tool. Delivering that requires specific technical know-how about building compilers which are good not only for batch-transforming source to object files, but also at providing on-the-fly completion, navigation and other IDE fluff. That’s very technical, compiler knowledge, but it also isn’t really a rocket science: we knew how to do this since at least (checks the date on Fowler’s post) 2005.
It’s just that OSS didn’t start building these kinds of tool at all, until Microsoft didn’t create the expectation, via LSP&TypeScript, that that’s how every language should work.
Totally agree.
I much prefer the clean and ultra fast Sublime Text interface. Like a terminal, the screen is fully used up by code. VSCode has too much padding and margins for my taste - the screen looks busy. I also really love VIM bindings.
But VsCode mostly just works, while I lost my patience trying to setup Neovim LSPs and others.
I really would like a sublime or vim editing experience with the ease of use of VSCode.
I am hoping that Helix adds Copilot support though. Helix is so fast and pretty.
Yeah. I don’t like VS Code as my main editor that I use daily. I love VS Code for random one-off editing. It’s never 100% like IntelliJ, but it’s 80% without any effort.
[Comment removed by author]