Hacker News Reader

Comment by tempodox | Hacker News Reader

The actual announcement is here:

https://github.com/omnisharp/omnisharp-vscode/issues/5276

It's not quite as dramatic as the OP is making it out to be.

The web page is FUD, but the GitHub issue is describing yet another top level management decision which is totally not helpful source code wise and reputation wise.

Creating a bridging host component for tools with multiple intellisense or debugging providers is okay, but the host must be open source to control what is happening.

This is a strategic move to unify VS and VS Code ... And the open source debacle is the thing in between.

If they want to unify and not just have more control over the ecosystem, why not unify them over OmniSharp or other open LSP?

I don't think it is to unify. I wouldn't be surprised if it would be another revenue source. People may prefer the interface of VS Code, but prefer the backend tools in VS. Microsoft could end up selling plugins/add-ons/whatever for VS Code.

That ship has sailed. Which programming language in the top 20 is commercial regards revenue from compiler, Debugger and nowadays basic LSP stuff like IntelliSense, code inspection etc.

The only commercial aspect is productivity like IntelliCode, IntelliTrace, GitHub AutoPilot and friends. For that you pay JetBrains, Microsoft, GitLab etc. There they will make money.

probably because the plan is to mix it with their ML code generating tools

> host must be open source to control what is happening.

Open source does not mean that there is any control with other entities than Microsoft. We can see what is happening, but it is up the the Microsoft to decide what code is merged and so on.

Which is "source open". But we also need "open source" (which includes and OSI license), so we can package independent of Microsoft. There the critic about closing their ecosystem comes from.

I have a pull request out right now for an open source project that hasn't been merged because I'm not in control of it.

This. My first reaction was - why are we posting FUD here. Then you see it: they're switching from an OSS component to a new component, which *will not be open-sourced*.

Retiring code with architectural changes is fine, it's normal, it happens everywhere. I don't have a problem with it. Only the replacement should be comparable in licence. Which this one isn't.

> Retiring code with architectural changes is fine, it's normal, it happens everywhere. I don't have a problem with it. Only the replacement should be comparable in licence. Which this one isn't.

Not sure how you could perform the whole "extinguish" step without replacing any OSS/free/copyleft license with a closed-source version of it. "Extinguish" with OSS components would just be "embrace" or "extend", both of which Microsoft has already completed, so time to move on to the next step.

What does an IDE have to do with a software framework? Besides Java and eclipse, what other frameworks provide an open source IDE?

A programming language is defined by its attributes. Some measure speed, beauty, library reach but most modern language need productivity as a key attribute. There C# has its strength. And productivity includes debuggers, intellisense, etc. It requires a non traditional compiler etc. There is a powerful video of Anders Hejlsberg explaining this. And that guy knows about it.

These comments from an OmniSharp contributor are particularly enlightening:

https://github.com/omnisharp/omnisharp-vscode/issues/5276#is...

These things almost never are, and the purists risk a purist death spiral.

It reminds me of the closed source drivers debate.

Someone has a proprietary component they want to incorporate into an open source system.

The purists demand they open source that proprietary software if they want it integrated into the open source.

The developer wants a compromise, but the purists won't allow it, so the developer is left to pick up their ball and go home.

And it rarely ends with the developer open sourcing their proprietary system; they often just shrug and leave, which leaves the open source system behind on tech compared to closed source and then proprietary software truly eats the world.

> The purists demand they open source that proprietary software if they want it integrated into the open source.

...and as a result we got GPLv2, GPLv3, open Intel, AMD and Broadcom drivers. Lastly Paragon donated NTFS source code to kernel tree (...and probably many smaller examples I've forgot).

> The developer wants a compromise, but the purists won't allow it, so the developer is left to pick up their ball and go home.

Because purists don't care about the developer, they care about the user. MIT/permissive licenses are for developer freedom, but xGPL and other strong copyleft licenses are for users' freedom.

As a developer, I contribute to projects licensed permissively, but I license all my code with GPL, because I care about the user who's gonna use and explore it, and I don't want my handful of users to be locked out of developments.

> And it rarely ends with the developer open sourcing their proprietary system; they often just shrug and leave...

Again we have Intel, AMD/ATI, Broadcom, Logitech, Paragon software and others.

>MIT/permissive licenses are for developer freedom, but xGPL and other strong copyleft licenses are for users' freedom.

That's a bit to simple, being a user of FreeBSD i just want opensource, i would never use a FreeBSD-fork that is no open anymore, so i have even more freedom as a dev and a user.

>Again we have Intel, AMD/ATI,

The Intel driver is BSD and ATI is MIT, and i think it's absolutely logical for those two to take that license's, and not GPL.

But please don't get me wrong, GPL2 is a great license.

I think that the point here is that as a user, with MIT you may not have a choice. Of course, you would never choose a FreeBSD fork that isn't open. But if you buy a TV running a closed fork of FreeBSD you might never even find out. In that case, it was great for the developer: they were able to get a great OS for free. However, it was not great for the user: they get a closed OS that they can't patch, upgrade, downgrade, or change in any way that the developer doesn't approve of.

Ok look, i have that TV that run's Linux, they even send me a "CD" with all the source-code of linux/gnu of it, BUT there is that highly proprietary module loaded into the kernel, firmware and so on, so patching my TV is as easy as re-engineering a whole closed-source system.

In theory the idea is great, in reality it makes nearly no difference.

> MIT/permissive licenses are for developer freedom, but xGPL and other strong copyleft licenses are for users' freedom.

GPLv3 also provides plenty of protection for developers unlike other licenses, especially around patents.

Also, all developers are users of development tools and libraries.

Yes. All developers are users of the said tools, applications and libraries, but the reverse is not true. i.e. not all users are developers.

So, while I see this is a clarification, I don't think what I've said is blatantly wrong.

> I don't think what I've said is blatantly wrong.

Nobody accused you to do so. I wrote "also" in both sentences to add nuance to what you wrote and finesse it.

Sorry, my bad, honestly. I probably read it wrong, then. Didn't intend to sound too harsh, too.

What do you wish was done differently in the open source drivers debate exactly? We have closed nvidia drivers, they're shitty but they work, people who don't want closed drivers can avoid them, people who don't mind them can use them. It seems to have successfully pushed AMD to open-source their drivers, and now even pushed nvidia to make the in-kernel component of their drivers open-source.

Would you have wished that the Linux project should just have incorporated closed-source kernel modules into mainline? Who would that have helped?

Outside the GPU space, tonnes of companies are publishing their drivers' source code under the GPL. I don't think they would have if they didn't have to. Isn't this a good thing? As someone who works on embedded Linux systems for a living, I'm certainly very thankful that I don't have to deal with closed out-of-tree kernel modules.

Seems like the strategy has been extremely successful at achieving what it was meant to achieve. Whether those goals overlap with your personal ideals or not is a different story.

I've dealt in high-compute situations where the next-gen networking equipment required linux kernel shims. Always thought it sounded like a backdoor personally.

Microsoft is not releasing a partly open-source program, they're replacing an open-source {Python, C#} extension with a proprietary one that won't run on VS Codium or Arch Linux packages.

At the time of writing, the upvote:downvote ratio on the announcement issue is almost 1:20, so I'm initially skeptical about your implication that this is some kind of fringe part of the developer community.

To me it seems more likely to be a culture clash - one team is used to developing closed source tools that have been highly prized by the company in the past, and another team has had great success writing open source tools that are widely adopted.

My guess is that the adapter code project is currently within the former team's remit, leading to this situation -- but that's all complete conjecture on my behalf.

> Existing users will be able to choose between the open-source OmniSharp powered system that exists today, or the new “'LSP Tools Host” which will provide access to additional experiences.

If OmniSharp remains open-source, I think people can still add more features to it, right?

Do C# developers really use VSCode? I use IntelliJ (closed source) to write Java application because IDE provides far more features than an editor.

OmniSharp is not going away, but as a project it is significantly more limited in resources than the closed competitor.

(I just posted it on HN, the domain and website is not mine) I agree calling .NET closed platform because of the debugger and now LSP is over-dramatic simplification of the situation. However what else is it than Microsoft pushing a proprietary component into a thing which is currently open?

See the parallel thread about PyLance explains why it is a problem: https://news.ycombinator.com/item?id=31763107

Reply on news.ycombinator.com