3 ms·

RE: "Not a truly open project." 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

RE: "Not a truly open project." 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.

aithrowaway1987 2y ago
But that is not the standard for current GNU projects in large part because of all the easily avoidable friction. "If it was good enough for Richard Stallman in 1987, it's good enough for Microsoft in 2024" is just a dumb argument. 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.
- deleted 2y ago
  [deleted]
- cryptonector 2y ago
  Building and maintaining a community is hard work. Even just talking to all comers is hard work. You need a team for that, but if you're a team of one then the community is likely going to suffer. You could find external contributors to promote to committers, but that's work too, and maybe LSP's maintainer doesn't want that (or maybe LSP's maintainer's employer (MSFT) doesn't want that). Apart from what MSFT wants, the rest is just as likely to happen for small enough projects whether they be GNU projects or not.
deleted 2y ago
[deleted]
leni536 2y ago
Most GNU projects are typically not standards/specifications but programs and libraries. That's a significant difference IMO.
kayodelycaon 2y ago
Yeah… this is can be confusing. “Open source”, “open standard”, and “open project” are different concepts. 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 https://en.m.wikipedia.org/wiki/Open_standard
- deleted 2y ago
  [deleted]
kelnos 2y ago
Two things: 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.
jchw 2y ago
I think "truly open" is not specific enough. Not being developed "in the open" is one thing, not having "open governance" is another thing. 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.
- aidenn0 2y ago
  > 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. 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.
  - jchw 2y ago
    Yes I certainly agree, there is not really much of an impetus for this to happen right away or anything. In the long term, though, I do suspect it is inevitable. > 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.

aithrowaway1987 2y ago

But that is not the standard for current GNU projects in large part because of all the easily avoidable friction. "If it was good enough for Richard Stallman in 1987, it's good enough for Microsoft in 2024" is just a dumb argument. 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.

deleted 2y ago
[deleted]
cryptonector 2y ago
Building and maintaining a community is hard work. Even just talking to all comers is hard work. You need a team for that, but if you're a team of one then the community is likely going to suffer. You could find external contributors to promote to committers, but that's work too, and maybe LSP's maintainer doesn't want that (or maybe LSP's maintainer's employer (MSFT) doesn't want that). Apart from what MSFT wants, the rest is just as likely to happen for small enough projects whether they be GNU projects or not.

deleted 2y ago

[deleted]

leni536 2y ago

Most GNU projects are typically not standards/specifications but programs and libraries. That's a significant difference IMO.

kayodelycaon 2y ago

Yeah… this is can be confusing. “Open source”, “open standard”, and “open project” are different concepts. 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 https://en.m.wikipedia.org/wiki/Open_standard

deleted 2y ago
[deleted]

kelnos 2y ago

Two things: 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.

jchw 2y ago

I think "truly open" is not specific enough. Not being developed "in the open" is one thing, not having "open governance" is another thing. 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.

aidenn0 2y ago
> 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. 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.
- jchw 2y ago
  Yes I certainly agree, there is not really much of an impetus for this to happen right away or anything. In the long term, though, I do suspect it is inevitable. > 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.