If LSP isn't truly open, then neither are most GNU projects. It was very common for the first 15+ years of GNU's existence for the public development process of a project to be "the single maintainer publishes a release archive whenever they feel like it"
It's a standard freely published and available for all to implement. If that's not "truly open" then we have moved the goalposts way too far.
That said, I guess the problem here is that for standards it helps if well, you collaborate with the people for which the standard is meant to be used by, which is presumably a little hard if there's a huge asymmetric relationship when it comes to Microsoft's concerns vs the rest of the world's concerns.
This is one of those cases where having a standards committee or consortium is the way to go. Committees have their problems, but I think it's only reasonable. If you think about it, doesn't it seem inevitable that eventually, big organizations that make editors would want a consortium of some sort to collaborate on protocols like this? LSP is really just the beginning, since there are plenty of things that editors would probably like to integrate deeper with, such as build systems.
I think a committee is a reasonable backup plan, and can even be done without Dirk's approval (see e.g. WHATWG done without the W3C's approval). If the LSP continues to be "good enough" then it seems unlikely.
> If you think about it, doesn't it seem inevitable that eventually, big organizations that make editors would want a consortium of some sort to collaborate on protocols like this?
Maybe? Editors tend to be an afterthought for most companies; JetBrains is the only company I can think of that is big on the LSP and for whom the editor is a primary experience.
> Maybe? Editors tend to be an afterthought for most companies; JetBrains is the only company I can think of that is big on the LSP and for whom the editor is a primary experience.
I have some thoughts:
- I think there will be more. At the very least, I suspect there is a reasonable chance Apple/XCode would eventually adopt LSP.
- Realistically, there aren't that many browser engines either. There's really just two truly distinct browser engines, and really only one of them is the main product of the company that produces it. Arguably there are already more distinct text editor engines that have LSP clients built-in today: Neovim, VSCode/Monaco, Visual Studio, IntelliJ IDEA, Eclipse, Zed, and probably more I'm not thinking of.
- I think that it is likely LSP clients will continue to appear in more places. In "cloud compute" UIs for things like serverless functions, inside of code forge's built-in editors, and so forth. It's not that it's necessarily that it's so easy to do it well, it's more that the value:effort ratio of doing it is pretty great, and every time someone develops a new high-quality LSP, it gets even better.
I never quite understood why Mozilla seems more interested in other things vs Firefox (the browser, not the other Firefox branded things).
Well, expand beyond "big companies", to include open source prijects, and non-profit foundations, and there are a lot of parties that might be interested in an LSP comity including both groups that develop editors (neovim, emacs, Jetbrains/intellij, eclipse, zed, etc.) and makers of lsp servers (ex. Google for gopls, Rust foundation for rust, etc.)
Of course someone else could just try to make a competing protocol with LSP, but I think that's a waste of time when it could most likely be incrementally and backwards compatibly improved quite a lot. And also, any given party only is one side of the equation, so any given entity only has so much sway here.
Exactly. And if "everybody" (except MS) in the committee agrees on the implementation of LSP, they can define a new common protocol too. The old LSP clients and servers won't stop working, they may slowly die out if the new protocol "wins".
Don't get me wrong, this is just a hypothetically perfect solution, which didn't happen before LSP and I'm sceptical that it will happen in the foreseeable future, as LSP is "good enough". And with "it" I mean that there won't be such a commitee, much less a new, common protocol.
It will always need a new, better and open protocol implemented in a successful editor or IDE to gain traction and spread (like what happened with VS Code and LSP).
Starting over with a new protocol, and replacing implementations for all the existing editors and languages would be a tremendous amount of work for relatively little benefit.
And either forking lsp, or creating a new protocol would cause fragmentation.
Also, VSCode is popular enough that even if the other editors forked LSP and made significant improvements, if VSCode wasn't on board, it would be a tough sell to get many languages and existing LSP implementations to adopt it.
Jetbrains' main feature are their own engines. And MS still has Visual Studio - without Code ;) - which doesn't use LSP. And Apple is Apple. So, who would that be? On the contrary I'd say that everybody who want's to get "big", must not use LSP to have something that sets the editor apart.
Jetbrains IntelliJ platform supports language servers and for example, WebStorm will use tsserver for TypeScript code. CLion also uses clangd, and there are also third-party plugins that use the LSP client.
> And MS still has Visual Studio - without Code ;) - which doesn't use LSP.
Microsoft Visual Studio definitely has a built-in LSP client, and yes, I mean "not Code". By default it will be used for tsserver (regular Visual Studio indeed supports TypeScript), and third-party plugins can use the LSP client too.
> And Apple is Apple
Of course, we'll see. Apple is stubborn yes. If they do LSPs, they'll do it their way specifically. That said, I personally think it's decent odds to eventually happen, especially seeing as the Swift programming language provides an LSP.
> On the contrary I'd say that everybody who want's to get "big", must not use LSP to have something that sets the editor apart.
Well, it's certainly possible to build richer features than the LSP can support if you build your code intelligence engine to be tightly integrated with your text editor, and it is true that a huge selling point of IntelliJ is indeed, their own custom code intelligence. However, I think this is a false dichotomy. There is definitely no reason a program that has its own framework for code intelligence systems can't also support LSP - I mean, both Visual Studio and IntelliJ do, and IntelliJ has always been mixing multiple sources of code intelligence together, as it still does today with clangd and tsserver, which in IntelliJ get combined with their own analysis and refactoring tools.
Modelling code intelligence the way Jetbrains always has probably won't go away any time soon, but I think it is pretty clearly not the future. The future is building code intelligence into the compiler, and redesigning the architecture of compilers to better accommodate these interactive, incremental use cases. Jetbrains seems to be a very smart company and I don't expect them to continue to cling to outmoded approaches if they prove to be less effective, and I suspect that as LSPs continue to improve Jetbrains will continue to lean on them and probably even contribute to them.
I will say though, at this point, not having a built-in LSP client does indeed set your editor apart quite a bit, although definitely not in a way that will be favorable!
And again, while (not-Code) VS may support LSP, it does not use one it for the main languages - C++, C# and F#.
I don't believe tsserver even use LSP. It feels a bit like "Let's make a standard that everyone should use so it's easy for vscode to integrate but for our own language we are not going to use it so it's harder to integrate in other IDE"
1. (As another commenter mentioned) Most GNU projects are not standards that are expected to be adopted by a significant number of implementers, and used by a huge number of users. Most GNU projects are totally fine having a few maintainers.
2. I am a lot more comfortable with a GNU project being run by a single maintainer than a public specification being owned by a corporation, where changes to that specification are largely driven by that company's product choices and profit motive.
And regardless, it seems a little weird to compare the GNU of the 80s and 90s to any public project today. In GNU's first 15 years the internet was nascent (at best!), and the number of people who implemented, used, and cared about these sorts of things were orders of magnitude smaller than they are today. Needs have changed.
Not to mention you're conflating apples with oranges, since a software standard is very different from an application. POSIX wasn't just one Bell Labs employee working by himself.
From the article:
> The LSP should be an open standard, like HTTP, with an open committee that represents the large community which is invested in LSP, and can offer their insight in how to evolve it.
There is no goalpost moving here.
The first two are well-defined and LSP meets the criteria for both.
“Open project” doesn’t have a definition or criteria. In this case, it probably means the community using a standard, controls the standard. The http protocol is an example of this.
Ultimately, they think the people in charge of the project are not listening to the people using it. This is a serious concern.
However, making a project “open” does not fix this problem. See systemd.
I hate dropping Wikipedia links but here is open standard: https://en.m.wikipedia.org/wiki/Open_standard