<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>Wowfunhappy</author><text>&amp;gt; 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&amp;#x27;t get permission to open source it.&lt;p&gt;&amp;gt; It is extremely hard to open source &amp;quot;some&amp;quot; or &amp;quot;most&amp;quot; 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.&lt;p&gt;Whatever the underlying cause, this strikes me as a perfectly good reason to be skeptical of Microsoft&amp;#x27;s forays into open source. It doesn&amp;#x27;t really matter what their intentions are—what you&amp;#x27;re describing is a company that can&amp;#x27;t do open source properly.</text><parent_chain><item><author>ohthehugemanate</author><text>See &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;code.visualstudio.com&amp;#x2F;docs&amp;#x2F;remote&amp;#x2F;faq#_why-arent-the-remote-development-extensions-or-their-components-open-source&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;code.visualstudio.com&amp;#x2F;docs&amp;#x2F;remote&amp;#x2F;faq#_why-arent-the...&lt;/a&gt;&lt;p&gt;I love that post, because it encapsulates exactly the kind of internal logic that traps not-fully-open organizations.&lt;p&gt;MS can&amp;#x27;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&amp;#x27;t used to open source, are discouraged from getting used to it, and&amp;#x2F;or don&amp;#x27;t have approval from legal to release code in the open.&lt;p&gt;This is not an EEE trap, this is normal bureaucracy for an organization the size of MS. Consider that for almost all of VSCode&amp;#x27;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.&lt;p&gt;They have the same problem with the C# debugger: owned by a proprietary team, can&amp;#x27;t get permission to open source it.&lt;p&gt;It is extremely hard to open source &amp;quot;some&amp;quot; or &amp;quot;most&amp;quot; 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.&lt;p&gt;Disclosure: I work for Microsoft in a totally unrelated department.&lt;p&gt;Also, fwiw i&amp;#x27;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&amp;#x27;s the only proprietary software on my toolchain (apart from my BIOS).</text></item><item><author>hardwaresofton</author><text>Forgive the kneejerk reaction but it sounds like we&amp;#x27;ve come full circle back to closed source IDEs. For what reason are any of those extensions closed source? Why are people using and championing tools with closed source extensions that check what they&amp;#x27;re running on (in order to force you to use&amp;#x2F;buy the original thing) in 2020?&lt;p&gt;You can pry emacs&amp;#x2F;vim from my cold dead hands -- Microsoft is trying (and succeeding) in google-chrome-ing it&amp;#x27;s way into the productive developer space. If that&amp;#x27;s true, I wonder what the Firefox in this analogy is? Atom? Emacs&amp;#x2F;Vim?</text></item><item><author>cercatrova</author><text>Note that this doesn&amp;#x27;t work with VSCode&amp;#x27;s Remote extensions, such as for SSH, Docker containers, and WSL. Those extensions are closed source and explicitly check that they&amp;#x27;re running on only VSCode. I thought of using this but since I mainly use WSL, this doesn&amp;#x27;t work for me. Still, a laudable effort.</text></item></parent_chain></comment><story><title>VS Code without Microsoft branding/telemetry/licensing</title><url>https://github.com/VSCodium/vscodium</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>Nullabillity</author><text>As a user it&amp;#x27;s still the same EEE trap, regardless of whether it comes from outright malice or is disguised as incompetence.</text><parent_chain><item><author>ohthehugemanate</author><text>See &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;code.visualstudio.com&amp;#x2F;docs&amp;#x2F;remote&amp;#x2F;faq#_why-arent-the-remote-development-extensions-or-their-components-open-source&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;code.visualstudio.com&amp;#x2F;docs&amp;#x2F;remote&amp;#x2F;faq#_why-arent-the...&lt;/a&gt;&lt;p&gt;I love that post, because it encapsulates exactly the kind of internal logic that traps not-fully-open organizations.&lt;p&gt;MS can&amp;#x27;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&amp;#x27;t used to open source, are discouraged from getting used to it, and&amp;#x2F;or don&amp;#x27;t have approval from legal to release code in the open.&lt;p&gt;This is not an EEE trap, this is normal bureaucracy for an organization the size of MS. Consider that for almost all of VSCode&amp;#x27;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.&lt;p&gt;They have the same problem with the C# debugger: owned by a proprietary team, can&amp;#x27;t get permission to open source it.&lt;p&gt;It is extremely hard to open source &amp;quot;some&amp;quot; or &amp;quot;most&amp;quot; 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.&lt;p&gt;Disclosure: I work for Microsoft in a totally unrelated department.&lt;p&gt;Also, fwiw i&amp;#x27;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&amp;#x27;s the only proprietary software on my toolchain (apart from my BIOS).</text></item><item><author>hardwaresofton</author><text>Forgive the kneejerk reaction but it sounds like we&amp;#x27;ve come full circle back to closed source IDEs. For what reason are any of those extensions closed source? Why are people using and championing tools with closed source extensions that check what they&amp;#x27;re running on (in order to force you to use&amp;#x2F;buy the original thing) in 2020?&lt;p&gt;You can pry emacs&amp;#x2F;vim from my cold dead hands -- Microsoft is trying (and succeeding) in google-chrome-ing it&amp;#x27;s way into the productive developer space. If that&amp;#x27;s true, I wonder what the Firefox in this analogy is? Atom? Emacs&amp;#x2F;Vim?</text></item><item><author>cercatrova</author><text>Note that this doesn&amp;#x27;t work with VSCode&amp;#x27;s Remote extensions, such as for SSH, Docker containers, and WSL. Those extensions are closed source and explicitly check that they&amp;#x27;re running on only VSCode. I thought of using this but since I mainly use WSL, this doesn&amp;#x27;t work for me. Still, a laudable effort.</text></item></parent_chain></comment><story><title>VS Code without Microsoft branding/telemetry/licensing</title><url>https://github.com/VSCodium/vscodium</url></story>