I love that post, because it encapsulates exactly the kind of internal logic that traps not-fully-open organizations.
MS can't open source the remote Dev extensions, because the service that runs it (and much of the client code) comes from other, proprietary offerings and codebases. More concretely, they come from other teams that aren't used to open source, are discouraged from getting used to it, and/or don't have approval from legal to release code in the open.
This is not an EEE trap, this is normal bureaucracy for an organization the size of MS. Consider that for almost all of VSCode's lifetime, the OSS version has been perfectly full featured, only missing telemetry and copyrighted brand marks. Remote Dev extensions are less than a year old.
They have the same problem with the C# debugger: owned by a proprietary team, can't get permission to open source it.
It is extremely hard to open source "some" or "most" of your code, especially in a company whose USP is tight integration between pieces. The legal quagmires are horrendous. A tool that crosses so many lines, like an integrated IDE, are backed into positions like this.
Disclosure: I work for Microsoft in a totally unrelated department.
Also, fwiw i'm a lifetime vim devotee... used it as my primary IDE for a long time and still use it daily. But vscode won me over exactly with the remote code extensions. Now it's the only proprietary software on my toolchain (apart from my BIOS).
> This is not an EEE trap, this is normal bureaucracy for an organization the size of MS. [...] They have the same problem with the C# debugger: owned by a proprietary team, can't get permission to open source it.
> It is extremely hard to open source "some" or "most" of your code, especially in a company whose USP is tight integration between pieces. The legal quagmires are horrendous. A tool that crosses so many lines, like an integrated IDE, are backed into positions like this.
Whatever the underlying cause, this strikes me as a perfectly good reason to be skeptical of Microsoft's forays into open source. It doesn't really matter what their intentions are—what you're describing is a company that can't do open source properly.
I assume that it depends on old code. With old code opensourcing can be really tough.
One reason of course is "embarrassment" as it's "ugly" code and you want to run a full review and audit and eventually cover private APIs from other modules. That's however solvable.
More complicated is another reason: Legacy software often contains code contributed by contractors and acquired from external vendors, where there is no license for making it open source. Sometimes such third party code is even deeply webbed in and legal review is a pain as you have to figure out the origin of essentially each line of code. This can be a lot of work.
I observed how Sun did this with Solaris and over multiple years managed to bring it down to a handful libs with third party code (some internationalisation thing comes to mind, meanwhile replaced in the illumnos sphere)
> One reason of course is "embarrassment" as it's "ugly" code and you want to run a full review and audit and eventually cover private APIs from other modules. That's however solvable.
Make sure there's no offensive variable names and comments left over from that one guy who used to work here.
All the more reason me not to care. safetyism is destroying society IMO
"It's now very common to hear people say, 'I'm rather offended by that.' As if that gives them certain rights. It's actually nothing more... than a whine. 'I find that offensive.' It has no meaning; it has no purpose; it has no reason to be respected as a phrase. 'I am offended by that.' Well, so f'in what." --Steven Fry
>>This is not an EEE trap, this is normal bureaucracy for an organization
Except that "normal bureaucracy" is built on, and is infact an EEE Trap...
EEE is part of MS Culture, if you believe the rhetoric it "was" part of the culture (past tense) but things like this show it is still very very much ingrained in the very fabric of MS
>Consider that for almost all of VSCode's lifetime
Hmm VSCode is about 5 years old, so 20% of its life now has been Extending OSS with proprietary code, that is not a good statistic IMO
Thank you for pointing to this -- I will take this into consideration -- I figured it was something like this for WSL, but not for SSH, but that link explains the context very well.
> Also, fwiw i'm a lifetime vim devotee... used it as my primary IDE for a long time and still use it daily. But vscode won me over exactly with the remote code extensions. Now it's the only proprietary software on my toolchain (apart from my BIOS).
I do want to clarify that I do not think VSCode is a bad tool -- it is a fantastic tool, evidenced by how many people are getting value from it and investing in it. You could technically run VIM inside it if you wanted, so on some level it's probably strictly better on some level. I was mostly worried about it being a trojan horse of sorts, I don't use it so I hadn't heard about the remote extensions and it caused my knee-jerk reaction -- appreciate you adding the context and showing that this was anticipated by the VS team.
Emacs does this too -- I think it was the pioneer for this sort of functionality.
One thing I'm jealous of VSCode (as an Emacs user), is the Google Docs-style collaborative editing. Seems particularly useful for pair programming in the covid-work-from-home era.
I love that post, because it encapsulates exactly the kind of internal logic that traps not-fully-open organizations.
MS can't open source the remote Dev extensions, because the service that runs it (and much of the client code) comes from other, proprietary offerings and codebases. More concretely, they come from other teams that aren't used to open source, are discouraged from getting used to it, and/or don't have approval from legal to release code in the open.
This is not an EEE trap, this is normal bureaucracy for an organization the size of MS. Consider that for almost all of VSCode's lifetime, the OSS version has been perfectly full featured, only missing telemetry and copyrighted brand marks. Remote Dev extensions are less than a year old.
They have the same problem with the C# debugger: owned by a proprietary team, can't get permission to open source it.
It is extremely hard to open source "some" or "most" of your code, especially in a company whose USP is tight integration between pieces. The legal quagmires are horrendous. A tool that crosses so many lines, like an integrated IDE, are backed into positions like this.
Disclosure: I work for Microsoft in a totally unrelated department.
Also, fwiw i'm a lifetime vim devotee... used it as my primary IDE for a long time and still use it daily. But vscode won me over exactly with the remote code extensions. Now it's the only proprietary software on my toolchain (apart from my BIOS).