<story><title>LSP: The good, the bad, and the ugly</title><url>https://www.michaelpj.com/blog/2024/09/03/lsp-good-bad-ugly.html</url></story><parent_chain><item><author>aidenn0</author><text>RE: &amp;quot;Not a truly open project.&amp;quot;&lt;p&gt;If LSP isn&amp;#x27;t truly open, then neither are most GNU projects.  It was very common for the first 15+ years of GNU&amp;#x27;s existence for the public development process of a project to be &amp;quot;the single maintainer publishes a release archive whenever they feel like it&amp;quot;&lt;p&gt;It&amp;#x27;s a standard freely published and available for all to implement.  If that&amp;#x27;s not &amp;quot;truly open&amp;quot; then we have moved the goalposts way too far.</text></item></parent_chain><comment><author>jchw</author><text>I think &amp;quot;truly open&amp;quot; is not specific enough. Not being developed &amp;quot;in the open&amp;quot; is one thing, not having &amp;quot;open governance&amp;quot; is another thing.&lt;p&gt;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&amp;#x27;s a huge asymmetric relationship when it comes to Microsoft&amp;#x27;s concerns vs the rest of the world&amp;#x27;s concerns.&lt;p&gt;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&amp;#x27;s only reasonable. If you think about it, doesn&amp;#x27;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.</text></comment>
<story><title>LSP: The good, the bad, and the ugly</title><url>https://www.michaelpj.com/blog/2024/09/03/lsp-good-bad-ugly.html</url></story><parent_chain><item><author>aidenn0</author><text>RE: &amp;quot;Not a truly open project.&amp;quot;&lt;p&gt;If LSP isn&amp;#x27;t truly open, then neither are most GNU projects.  It was very common for the first 15+ years of GNU&amp;#x27;s existence for the public development process of a project to be &amp;quot;the single maintainer publishes a release archive whenever they feel like it&amp;quot;&lt;p&gt;It&amp;#x27;s a standard freely published and available for all to implement.  If that&amp;#x27;s not &amp;quot;truly open&amp;quot; then we have moved the goalposts way too far.</text></item></parent_chain><comment><author>aithrowaway1987</author><text>But that is not the standard for current GNU projects in large part because of all the easily avoidable friction. &amp;quot;If it was good enough for Richard Stallman in 1987, it&amp;#x27;s good enough for Microsoft in 2024&amp;quot; is just a dumb argument.&lt;p&gt;Not to mention you&amp;#x27;re conflating apples with oranges, since a software &lt;i&gt;standard&lt;/i&gt; is very different from an &lt;i&gt;application.&lt;/i&gt; POSIX wasn&amp;#x27;t just one Bell Labs employee working by himself.&lt;p&gt;From the article:&lt;p&gt;&amp;gt; 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.&lt;p&gt;There is no goalpost moving here.</text></comment>