Note that this doesn't work with VSCode's Remote extensions, such as for SSH, Docker containers, and WSL. Those extensions are closed source and explicitly check that they're running on only VSCode. I thought of using this but since I mainly use WSL, this doesn't work for me. Still, a laudable effort.
Forgive the kneejerk reaction but it sounds like we'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're running on (in order to force you to use/buy the original thing) in 2020?
You can pry emacs/vim from my cold dead hands -- Microsoft is trying (and succeeding) in google-chrome-ing it's way into the productive developer space. If that's true, I wonder what the Firefox in this analogy is? Atom? Emacs/Vim?
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 guess we can gauge how much embrace+extend+extinguish MS is doing by whether Atom gets winded down or goes into maintenance mode. I know it's not as popular as VSCode is now, and development has slowed since it burst onto the scene, but if anyone at Github actively works on Atom maybe those people should be worried about being reassigned.
For Microsoft, the text editor market is not something they need to dominate, but they absolutely do need positive developer mindshare. Why would they possibly care about extinguishing the competition?
You're not going to convince me that EEE applies to text editors for pushing Azure. Decisions on what Cloud platform to use are not made by a developer's choice of text editor, but by executives over fancy dinners, or the CEO's personal favourite in a startup.
But developers sometimes are or become CTOs or technical decision makers. These two statements are contradictory:
> For Microsoft, the text editor market is not something they need to dominate, but they absolutely do need positive developer mindshare. Why would they possibly care about extinguishing the competition?
> You're not going to convince me that EEE applies to text editors for pushing Azure. Decisions on what Cloud platform to use are not made by a developer's choice of text editor, but by executives over fancy dinners, or the CEO's personal favourite in a startup.
For positive developer mindshare, every little bit matters. For pushing Azure adoption, every little bit matters. New generations of developers using VSCode in coding bootcamps and undergraduate courses will keep the habit of using VSCode for a very long time. One click deploy-to-Azure plugins that works just that little bit better than the equivalent deploy-to-<somewhere else> or with remote development functionality will combine with the loss-leader that is cloud credits to make it just that little bit easier to choose Azure. Just that little bit of better integration with Github and NPM.
All of this seems far fetched, but it's how you build market share from behind. Microsoft is in it for the long haul, even if the pace is glacial, progress is progress. Again, it's not necessarily bad for every involved developer, it will definitely be great for most in terms of productivity or other benefits. Microsoft's incentives must be aligned with getting rid of the competition if possible, it's how for-profit public companies work, but before that's even possible, they need mind-share -- you can't just buy mind-share, you have to build it sometimes.
> "Embrace, extend, and extinguish" (EEE),[1] also known as "embrace, extend, and exterminate",[2] is a phrase that the U.S. Department of Justice found[3] was used internally by Microsoft[4] to describe its strategy for entering product categories involving widely used standards, extending those standards with proprietary capabilities, and then using those differences in order to strongly disadvantage its competitors.
> Embrace: Development of software substantially compatible with a competing product, or implementing a public standard.
> Extend: Addition and promotion of features not supported by the competing product or part of the standard, creating interoperability problems for customers who try to use the "simple" standard.
> Extinguish: When extensions become a de facto standard because of their dominant market share, they marginalize competitors that do not or cannot support the new extensions.
Embrace: MS enters the lightweight editor (Atom) space with VSCode
Extend: MS extends VSCode with proprietary WSL/SSH/whatever code that they use their deep pockets to maintain and push people to VSCode ("it works better with WSL")
Extinguish: VSCode becomes the defacto standard. It remains to be seen whether Atom will be affected by this in actuality but it's already been supplanted in popular marketing IMO. VSCode is already more popular than Atom AFAIK.
This also seems to be a perfect description of what chrome is doing with internet standards -- I wonder how common this exact strategy is in business, even if they don't call it EEE
People who've been around for a while have been arguing for years that Chrome is doing exactly what Microsoft did with IE back in the day and a browser market dominated by Chrome and Chrome-a-likes is not healthy.
Sadly, too many people haven't been around for long enough to have seen it all before, and they fall for the new shiny every time. Then we get a few years of bad results where one product dominates and that part of the industry only evolves in the directions that suit the business controlling that one product, until eventually sufficient opposition has built up that a viable competitor is produced and we start to move forward again.
I agree, which is why I referred to it as "google-chrome-ing" (very awkward term) in my original post.
The Chrome teams (the ones that deal with standards, improving chrome, etc) are certainly filled with good people trying to improve the web, but there is such a conflict of interest there with a more open web or a web with certain features. Those employees are obligated to be on the wrong side of those discussions in really insidious/subtle ways sometimes, and those at the level at which strategy is conducted have a clearer view but have an even stronger incentive.
I don't see how this is related to what Chrome is doing. What Web APIs have been implemented in Chrome that are available as proprietary closed source only? Looking at Google's wiki, I do not see any APIs that are omitted from Chromium:
You say this as if Atom is some sort of widely used standard. Atom and VSCode are just two players in a wide ecosystem of editors and IDEs, most of which Microsoft has no control over. And I'd bet that most people using other tools (e.g. Visual Studio, JetBrains IDEs, Vim, Emacs) have very little inclination to switch to Atom or VSCode.
I agree, and this is why I'm glad people like RMS exist, even if he is difficult/off his rocker/whatever else -- the free software movement and the ideas it espouses would almost surely have not made it this far (and benefited all of us) without people who cared so much to tip the scale.
Why does it matter? The remote extensions for WSL and SSH in Visual Studio Code are extremely useful and actually work. Why should we care if they are closed source or not?
Because if it breaks, you can't fix it. If it reports on you, you won't know. If it decides to not allow SSHing into a server that it has blacklisted, you can't change it.
I'm having trouble with the question, it sounds like it's equivalent to "why bother open sourcing useful, currently-working software X", and that's just the "why is open source good" question, right?
I can somewhat understand WSL being closed source -- maybe it's got some proprietary MS stuff in there that is legally restricted, or they just don't want people using the interfaces they used? But tools like SSH grow because they're open source, not because they're closed, seems somewhat misplaced there.
> Because if it breaks, you can't fix it. If it reports on you, you won't know. If it decides to not allow SSHing into a server that it has blacklisted, you can't change it.
Are these the only reasons you have problem with it being closed source?
I'll happily use the closed source version when MS is developing who can handle 4 digit number of issues and likely to fix issues you care about and more.
If someone black lists your SSH server publicly, you seem to have a bigger problem than an extension being closed source.
I use neither Windows nor VS Code if I can avoid it -- I prefer slower progress than getting orders of magnitude more features ahead of time, for giving up control I consider fundamental, because I feel that I'm well served by the tools that are available in the open source space. I don't achieve theoretical maximum productivity without tools like VSCode and all the things they might provide and it hasn't been a problem in my career yet.
It's totally fine for other people to be fine with the trade off, but for me VSCode is an incremental gain, not a huge absolute one -- maybe it will have some killer feature (or more likely some partner/employer will force it on me because it's the current zeitgeist and because of some custom plugin) that I'll need someday, but that day is not today.
I would be OK with WSL being close-sourced, as long as the interface (including programmatic interfaces) to which you interact with it are open and documented.
Vendor lock-in is what i would see as bad-faith actor's action. A product being good should be the only lock-in required.
I'm curious, and please don't take this as an attack or sarcasm because it's not, it's a genuine question. Do you only use open source software? There is nothing close source on your machines?
I do not use only open source software, there's definitely closed source software on my machine, nvidia gfx drivers for example.
But I am also not a full on fanatic -- the world is gray, not black & white (for me at least). Since I am familiar with popular good open source tooling in this space, I'm surprised others who might feel the same might compromise at this particular junction, and that was my knee jerk reaction.
I can't say I do as much for the F/OSS community as others out there do but I donate to the authors of the tools I use, the EFF, and Letsencrypt (the amount of value they deliver is insane) from time to time.
Sorry for being snarky but genuinely curios : Why does it matter that anything is open source in that case if the criterion is that it should work and be useful? In this case, this is equivalent to a chrome extension being closed source. Sure its better than nothing but I would actively prefer an open source one over closed source.
Using/preferring open source software has some facets.
- First one is the stance. If I'm developing open source software, I want to build it on open source pillars. This ensures that I can just share the project file with the repository.
- Second one is access to source. I've chatted with a guy who had a problem with Eclipse CDT. He also reported a bug. I reproduced the bug and reported to bugzilla under his report. Someone looked to it in 24 hours after my reproduction and it's fixed and pushed.
I'm using Linux and open source software most of the time for the past 15 years. Open source tools gave me a better overall experience because being able to diagnose and workaround a problem makes my life much easier. If I can I'll push a patch, otherwise I'll report.
I have some closed source applications inevitably and if they're a bit complex and have some bugs, I'm a sitting duck waiting for answers to my e-mails and updates which fix bugs. This doesn't happen all the time because every developer has a time budget and will rightly spend its time on higher impact bugs. If you hammer a piece of software enough, you'll probably hit a bug which is not a big impact for most people but affects you in a big way. These kind of problems turn your relationship sour with that app.
This is why I use Eclipse for last 16 years or so. Yes it's not the prettiest, it's not the fastest but, it's well polished under the hood, I can access the devs and the source and it's overall stable and extremely feature rich.
Counterpoint: OSS usually lacks polish and only works well if your workflow is sufficiently similar to the developers' workflow. Linux is great if all you're doing is developing software with popular tools/languages, but if you want to use your computer like a normal person for a change, it's pretty bad. I've consistently had issues with basic functionality like HiDPI scaling, trackpad and wifi drivers, power management, and just general polish. That's not to say that Windows and macOS are amazing and perfect - they aren't. But they're a whole lot better than Linux for normal use.
> OSS usually lacks polish and only works well if your workflow is sufficiently similar to the developers' workflow.
On the polish side, you're not entirely wrong, but it's debatable. On the UI side, most of the applications doesn't have the level of polish of paid applications however, some of the open source software is extremely capable and stable at the foundation level.
Amarok can handle ~350GB music archive with its metadata without even sneezing but, JuK shivers and dies when encounters the archive (both open source). Eclipse is a very robust piece of software while its UI is old, dated, and relatively ugly (I like it as it is though). Similarly Digikam is probably the best large photo management application out there with some very nifty features. There are not many multi-TB capable photo libraries out there. All of these software is free software. Also, Darktable, while is not the best, I use it more than my many paid and expensive photography applications because its tools and results are so good. These are the ones I use regularly. Not any of these applications force you to use it in a particular way because many people have provided feedback to it and they have large development teams and user bases.
I think we can say that software without big user bases force the workflow of the developer because, developer(s) cannot think any other way. Genuinely asking, can you provide some examples to such software? I may be biased since I'm using this thing 15+ years and may have lost some perspective, honestly.
> Linux is great if all you're doing is developing software with popular tools/languages,
I want to politely disagree with this. I'm an old school C++ developer who uses Eclipse and takes some photos and postprocess/edit them with purely free software and, I think it works better than most Mac tools that I paid substantial money.
> but if you want to use your computer like a normal person for a change, it's pretty bad. I've consistently had issues with basic functionality like HiDPI scaling, trackpad and wifi drivers, power management, and just general polish.
I didn't recently install Linux to any modern laptop built in ~2 years but, I have an HP EliteBook 850 G2 at office. This thing is running Debian since day one and almost everything (Trackpad, WiFi, power management) is working out of the box (I didn't compile anything or fiddle under the hood) and it runs solid 7 hours before its battery depletes. In your defence the fingerprint reader was unsupported at that time so I didn't fiddle with it and since I was not doing any hard work, I disabled its discrete graphics. I only reboot it when I install a new kernel to it.
My office desktop has a 2K display and, everything scales on XFCE4 and GTK out of the box. I didn't do do any tweaking. On the polish side, out of the box DEs are all ugly. A good theme and a good wallpaper makes them top notch I think. I personally use XFCE4 on my desktop and KDE on my laptop (and home desktop) and, I can say that, KDE can boost productivity of an average user 3-4x just with included search & indexing facilities and usability features.
> That's not to say that Windows and macOS are amazing and perfect - they aren't. But they're a whole lot better than Linux for normal use.
Nothing is perfect. Neither Linux, Windows or macOS. they are all tools. I love Linux because I believe what it stands for and I can work blazing fast with it but, I also have a Mac and support my families Windows systems. macOS is the most time-efficient system out there. Linux with KDE is a very close second. Well, windows is the same experience for me since Windows 95 (productivity wise, not stability).
Progress is only possible if we're honest to each other and ourselves. I'm not a Linux zealot and if I sounded like one, I'm genuinely sorry.
Why is open source so much better at handling bug reports in your eyes than a dev team working on closed source? Both of those options are able to fix reproducable bugs within 24 hours, that's not something exclusive to OSS Plenty of open source projects just shrivel up and die without any more changes
Short answer: Because this is my experience over the long term.
Long Answer: I didn't say that only open source can fix bugs in 24 hours but, in order to get your bug fixed in 24h in a closed source software, you need to pay some top dollar for that service. Otherwise you'll most probably wait for the next point release which may or may not contain a fix to your bug.
In most closed source software, the process is completely opaque after your bug report is acknowledged. You don't know when will it fixed or ever be fixed. That's not a joyful wait sometimes.
OTOH, you're absolutely right. Not all bugs in OSS is fixed in 24h straight. Some got never fixed or fixed out of the tree. Also, an awful lot of software dies. OSS projects probably die more because they are one man shows most of the time unless they get a loyal following and they are very very good. However, you can compile and patch a dead open source project. You can't revive closed source software once it's dead and bit-rotten.
I want to give a couple of fresh examples, from Intel.
I have an HP Spectre X2 detachable tablet PC which runs Windows 10. This PC has an embedded Intel Wireless Dual AC 7265 card. Out of the box, thing works great. Rock solid. Windows updated its driver in some point and that driver which, has WHQL seal and everything, crashes that wireless card. You need to reset the card every time the card goes low power mode and comes back.
Intel has an even more recent driver, which does not fix the issue. The PC has a full fleet of updates too. BIOS, ME firmware, board FW and what not. Nope. The problem is still there. What's the best solution? Roll back that driver to initial version. Now it works. Can Intel fix this? Of course! In 24h? Why not? Will they fix it? Of course not! Why? AC 7265 is EOL, so no incentives. However, on paper all of these drivers support 7265.
2nd example is e1000e Linux driver, again from Intel. This is an open source Intel Ethernet card driver which supports whole fleet of cards. From lowish-end to top end silicon. Intel added a new feature to this driver and some cards started to crash, incl. mine (relevant bugzilla is [0]). Patch is isolated, distributions rolled it back relatively quickly and many people are back on track. Kernel people are still looking at it without rush since, everything is working without the latest patch.
Who wrote the last crashing patch? Intel. Can they fix it? Of course! Even in 24h? They may if they really want to. Will they fix it? Of course not! Why? Not enough incentives.
Bonus: While unrelated to both, I've waited a company to change a string comparison to case insensitive mode (or just capitalize the first name of the file they bundle) for a software that I bought for over a year. I reported that thing 10+ times! They didn't fix it ever. I changed the name of the file on every update. Over and over.
I thought the same of my CD of Soldier Of Fortune game I got when Loki games ported it to Linux (closed source).
Now I can't play it. And as that, I am sure there are tons of other (more useful than a game) software that people just lost access to run and they did not have the source code to migrate it or pay someone else to do it.
I assume these extensions require communicating with some central server (owned by Microsoft) to exchange information with peers at some point during its use.
Allowing the extension to run in contexts outside of VS Code could be an issue for them?
> I assume these extensions require communicating with some central server (owned by Microsoft) to exchange information with peers at some point during its use.
So I'm no WSL expert but why would Windows Subsystem for Linux or SSH need to communicate with some central server? Also unless they're doing some obfuscation, you're going to see those URLs in the binary to start with, no? Or you just... watch where it calls out to?
> Allowing the extension to run in contexts outside of VS Code could be an issue for them?
How? If it's a warranty issue then they should just issue the right statements in the license and make sure no one is under the impression that there's a warranty attached?
I tried to think of some too but security doesn't pass my admittedly simple sniff test.
Technically, somewhat similar. Socially, hell no! If you visit the Idea home page, it's a normal product page. It offers to buy the full product or download the free edition. Their business is pretty obvious. On the other hand, VS Code page has misleading "Free. Built on open source." in big letters under the headline. What's their business?
It seems to me that VSCode is developing toward greater intergration with Azure and GitHub as a cloud platform.
e.g. if you look at the docs presently https://code.visualstudio.com/docs , you see some signs of it already with a section dedicated to azure containing extensions dedicated to managing and deploying to parts of azure from within VSCode.
Of course it is, the sole reason Microsoft is doing these things is to sell Azure.
Don’t get me wrong, my organisation has a several decade long partnership with Microsoft and they are one of our greatest business partners on the tech side, but the company hasn’t changed one bit. They’ve simply changed what is is they are selling from software licenses to cloud, and having lots and lots of easily available mostly open source tools is how they do that best.
Just look at their image transformation from evil monopoly to open source champion. But everything they do, works better if you buy their products. .Net core runs perfectly well without Azure, but it works just a tad better with things like application insights. VSC works perfectly well on Linux or OS/X, but it works just a little bit better with Azure integration or/and on Windows with WSL.
Of course, that was the theory from the start: they made VSCode to get developer attention and nudge them towards Microsoft cloud. Fine. How does it explain why «those extensions are closed source and explicitly check that they're running on only VSCode»?
I have no idea. My first guess is that they contain libraries that they are not allowed to distribute as source, and that they have only been tested on VSCode.
Offtopic but for anyone wanting something like VSCode's remote extensions but foss there is tramp mode in emacs which lets you edit files over ssh and a few other protocols.
It'd be really cool if all open source was just designed with this in mind by the original coders. branding/telemetry/licensing should be explicit compile-time parameters that, left unspecified, exclude it completely.
That is exactly how most open source projects (including VS Code itself and others like Chromium) already behave. You can easily clone and build the source code, which has no logos or telemetry or anything else. Microsoft itself then takes this code, bundles in their copyrighted stuff and distributes the final application from their website.
The project explicitly says that is how VSCode is set up. The parameters are unspecified by default, and only specified by the Microsoft in their internal and official builds. The project is providing precompiled binaries using the default configuration.
I do believe that is what the parent poster is saying? That they hope that _every_ project out there could do this as well, when such (anti-)features exist. I could see how you might misinterpret the comment if you skimmed over it or didn't have English as first language though.
It depends on the trademark situation. If you have a restrictive trademark license (e.g. not allowing modifications) then you're basically waiving credit; you can't have both.
Yeah, or addons that can be easily disabled. I mean the core application can be licensed with a permissive open source license, anything closed-source can be put in addons.
Apps in the 90s didn't have user data. I was approximately as productive on apps from the 90s as I am in modern apps today. I am more frequently frustrated by modern apps.
I think this is something we need to study somehow even if it feels very true. I often find myself wondering why they’ve made something worse than it was a few years ago. Many parts of iOS and windows 10 have degraded from what they were.
This rings true. We have experts in funneling people to open their wallets but a dearth of ppl who are good at delighting, unless they see it as a way to make you open your wallet.
Were you as productive then? I don’t know what kind of work you do, but I recently put together a website with a map displaying some public data around Covid-19. That website can be viewed in seconds by essentially anyone on a 3g or better internet connection by nearly any computer or smartphone released in the last 5 years.
I can’t imagine I would be able to delivery even the basic mapping and data visualization features in the 1990s in the same time frame, and it certainly wouldn’t have the ease of distribution.
... what? So people weren't productive before computers? What does your story have to do with being productive or with productivity between now and the 90s or the tools you used?
Yes, people were vastly less productive at a huge number of tasks before computers. Tools and machines make people more productive. I’m very confused that this seems to be controversial. I suspect there is some unstated definition of “productivity” at play here that I am unfamiliar with.
It's not controversial, you're talking about a tangential subject. Your example has nothing to do with being productive, just that there are much more tools available now. Your example couldn't even be possible in the 90s and you're not saying anything about text editors.
That is true, but it is also easy to argue that the users who voluntarily consent to sending telemetry, or who don't block "mandatory" telemetry using methods beyond the developer's control, aren't a representative sample either.
For example, in what should have been a surprise to no-one, it turned out that "power users" who spend a lot of time with a certain application and heavily customise its UI for their needs were also more likely to change default telemetry options to turn things off. Similarly, systems at work that are managed by specialist staff in large organisations tend to be more tightly locked down than what you find in a small office where Bob sets things up for the new starters when he has a couple of hours free from his usual job.
Consequently, when certain big-name software developers redesigned their whole UI, proudly declaring that the new version would be more effective because it was based on what their objective telemetry data had told them about how the application was used, power users instead found the new UI confusing and inefficient. There is always some resistance to change in these situations, but when you have a significant and influential part of your market still not upgrading to your newer products years later and citing the UI as one of their reasons, you've probably made a mistake on that one.
The fact that this is unpopular convinces me that most HN posters don't work on real commercial products. Or if they do, then I don't care to use the products they develop.
Can anyone explain to me why I should be concerned about vs code telemetry? I have zero personal information in the IDE and all the code I work on is already in the public domain with an open source license, so why should I care?
How right or wrong it is to collect information about people and what they do is not entirely determined by how much personal information there is to get.
Just like how right or wrong it is to break into someones house is not entirely determined by what they take, or how much personal information you have in your house.
But yes, if you don't have anything valuable in your house, maybe you don't need to be concerned about people breaking in, but that doesn't make it more right.
Such analogies really depend on what the telemetry contains (granted, I don't know in this case). I.e. you describe it as stealing from inside the house. Say, VSCode figuring out your email adress and reporting it. But it might as well actually be pretty anonymous non-personal data i.e. more like looking at the outside of a house and taking note of that. Say, VSCode reporting the theme you use, and just that.
> Say, VSCode reporting the theme you use, and just that.
Wouldn't that be like looking through the windows to see what clothes they wear or at what time they go to bed or who they sit at the table with?
Just because you are outside of someone's home it doesn't mean you can't invade on their privacy.
Why does an editor need to do telemetry to begin with? Mind your own business. If you don't want to give me something for free, don't. Don't make something free and then feel like you have the right to spy on me. Charge me for using it.
Wouldn't that be like looking through the windows to see what clothes they wear or at what time they go to bed or who they sit at the table with?
Hehe with 'theme' I was actually just thinking about the color of the outer walls, should have made that clear. Even then: passing by a house and peeking through a window once is usually legal and as far as I know doesn't require consent (at least not in my country). Stopping in front of the window and staring inside for hours, not so much. Nor is passing by at the exact same time everyday and peeking inside.
Why does an editor need to do telemetry to begin with? Mind your own business
I'm not advocating in any direction here, be it pro or against telemetry. My point merely is that before making analogies, you'd better first check what telemetry exactly is being collected otherwise your analogy might be completely off.
Telemetry is commonly used for statistics on how a product is used, to learn for example if the user interface is counter intuitive or obnoxious with a much better sample size than their own team.
I also note that we still don’t have a clue in this discussion what the telemetry even includes despite tools and probably even documentation detailing this already existing. But I guess it’s more fun to debate this from a philosophical standpoint than the product in question.
From everything I’ve read, MS (and other telemetry-happy developers like JetBrains) see telemetry as a way to gather statistics about UI interaction patterns and popularity of this or that component, so that they can prioritise development towards the most popular features and problems. It’s a bit like our good old “Popularity Contest” package in Linux, but applied to UI elements and behaviours. It’s the sort of thing that resulted in a massive Paste button on the first Office ribbon, because telemetry said Paste was the most used feature.
Sometimes I wonder if I should turn all telemetry on, so that they’d have a datapoint that actually matches my workflow rather than Joe Schmoe’s. It’s a bit invasive though, and culturally speaking is a horrible model (“I can’t change things unless you let me watch what you do all the time”).
Obviously if you care about privacy you should keep telemetry off, but to be honest, if you don’t trust Microsoft to respect common decency about private code, you just shouldn’t use a tool they built in the first place. I use JetBrains tools and trust them enough to leave telemetry on (“voting” for my preferred features, effectively). If you do any politically-sensitive work, though, you should absolutely stay the hell away - because then it doesn’t matter what they do with it today, but what they could do if they wanted (i.e. under pressure from authorities).
Obviously if you care about privacy you should keep telemetry off, but to be honest, if you don’t trust Microsoft to respect common decency about private code, you just shouldn’t use a tool they built in the first place.
Isn't that the point of today's discussion: you can use the privacy-respecting alternative instead?
It's still effectively developed by MS, so it might be doing something funky outside of "regular" telemetry and you wouldn't know unless you fully audit the entirety of the codebase.
Sure, but now we're comparing an open source product you can build yourself that might be doing something shady but where we have no evidence of that, against a product derived from the open source version that is openly adding privacy-eroding functionality, and with a corresponding privacy policy that is ambiguous at best about how far it will go.
I also note that we still don’t have a clue in this discussion what the telemetry even includes despite tools and probably even documentation detailing this already existing.
Unless there are clear statements and guarantees that nothing will change in future updates without the user's express consent, the statements themselves aren't worth much anyway in this kind of discussion.
Microsoft's privacy policies are notoriously opaque, to the point where you'll have trouble verifying that, for example, they aren't granting themselves the right to upload your source code. This observation almost invariably attracts downvotes, but anyone who thinks I'm exaggerating can easily refute the point by citing the places in Microsoft's documentation that say otherwise and guarantee not to change that in the future.
My point is that it's not just what information is being taken that matters.
Even if you don't take anything it's still wrong to do things inside someone's computer or home without permission.
Maybe VS Code asks for permission properly and gives the user sufficient control and has good defaults,
I don't know, but it's difficult to do that properly because people don't understand computers as well as they understand the rest of life.
By "computers" I really meant "the complexity in the software that computers run".
Computers do very complex things and most of those things can't be directly seen.
So if you want to tell someone about what some software is doing, it's not always easy.
Because some other people might be working with code that is not in the public domain, or code whose mere existence should be kept hidden (so even relatively innocent things like project, file or branch names should be kept secret)?
I personally prefer tools that don't spy on me. In 99% of cases I probably won't care, but I don't want to take the chance of the 1% where a telemetry request would send out something I'd rather keep private which is why I want tools that are private by design.
My screwdriver doesn't spy on me and report what kinds of screws I use it with, the hammer doesn't either, I want my text editor to behave in the same safe and predictable manner.
As an application developer it's quite frustrating to be left completely in the dark about how people actually use my applications. All I can do is guess. Those guesses are most probably incorrect and the app won't be as good as it could.
Just a simple button click heat map would be very useful info to have. But then sending click heat map is the same thing as stealing credit card info in the minds of many ...
> to be left completely in the dark about how people actually use my applications
You don't have to be left in the dark. You can ask people for feedback (yes that used to be a thing) or run user testing sessions (yes that used to be a thing too but seemingly not anymore when we look at the quality of modern software).
> the app won't be as good as it could
I have yet to see any evidence that telemetry improves software quality enough to warrant the privacy trade-off. If there is a correlation it seems to be opposed; telemetry started becoming popular in the last decade, and the last decade is also the time around which software started declining in quality or usability (see Windows 8+, certain changes to macOS and iOS, bloated or user-hostile websites, etc).
> Just a simple button click heat map would be very useful info to have.
That heatmap thing will also at least leak my IP address, software version and a persistent UID that will allow the backend server (whether self-hosted, or powered by a nasty ad-tech company like Google analytics) to keep a log of my IP changes and usage patterns.
> You can ask people for feedback (yes that is still a thing)
That's not very reliable. It's quite common behavior that people give feedback only when they are not happy so you can get feedback like "this is horrible" although it still works nicely for the silent 99%.
> or run user testing sessions (yes that used to be a thing too but seemingly not anymore when we look at the quality of modern software).
Difficult to do for projects with $0 budget. I'm also interested in the long term (experienced) users behavior which is not possible with such testing sessions.
> That heatmap thing will also at least leak my IP address, software version and a persistent UID that will allow the backend server (whether self-hosted, or powered by a nasty ad-tech company like Google analytics) to keep a log of my IP changes and usage patterns.
* IP address - I don't care about your IP, that does not give me any useful info
* software version - sure, I'd like to know which version you run. Is that really privacy violation though?
* persistent UID - that's a matter of discussion, for me what's important is behavior within one session, connecting several sessions is not so important and I could do without it, so no persistent UID
Each of these items could be a matter of discussion - it would be nice to move the discussion from "all telemetry is literally evil" to "what's acceptable to collect?".
I disagree with feedback not being reliable. I think that detailed feedback from someone being not happy give you more details than a heatmap for example. I also think that feedback from a user who takes the time to actually leave feedback (and so is more invested in the product, and likely to give you repeat business) might be more valuable than one-off users.
> I'm also interested in the long term (experienced) users behavior which is not possible with such testing sessions.
Is it not possible to reach out to those users and invite them to such a session in exchange of $$$?
> I don't care about your IP, that does not give me any useful info
True but some malicious third-parties might care, whether it's the analytics service itself (Google Analytics comes to mind) or even a law enforcement request to capture/access such data. You are basically creating a potential liability for the user; some people might not want the software to phone home for certain reasons and I think the default should always be safe so telemetry is "off" by default.
There's also the issue that telemetry is typically opaque and the user has no visibility or control over what is sent, so out of an abundance of caution they opt out. I think a good improvement would be to queue all the telemetry data locally, and then periodically ask the user to review, edit/redact & send it if they want to. Apple has done it relatively well there where if an app crashes they allow you to review the report before sending it, and I actually send these the majority of the time (unless it's a process dealing with sensitive data) despite having OS-level telemetry disabled.
> I think that detailed feedback from someone being not happy give you more details than a heatmap for example.
Detailed feedback is definitely nice, but it's quite rare & not sufficient. It's again one person's view, people also often can't articulate what's wrong. Usage patterns across many users may reveal what's wrong ...
> that feedback from a user who takes the time to actually leave feedback might be more valuable than one-off users.
Both are valuable - one-off users might be people who got confused enough to be discouraged from using the product. That's extremely useful info.
> Is it not possible to reach out to those users and invite them to such a session in exchange of $$$?
Impossible for projects with $0 budget.
It's also very unreliable since people working on artificial test data have very different behavior than when they are working on their production data.
> ... people also often can't articulate what's wrong.
Then you’re not asking the right questions to get useful answers. People often can’t articulate anything well unless they’ve had the practice of doing so. I regularly interact in professional and private settings with people who regularly cannot articulate their thoughts, feelings, or ideas on things. I get them to do so by asking the right questions, digging deeper into what responses they give, and putting it all together.
The questions you ask determine the understanding and clarity you receive.
This gets brought up all the time and what I can't figure out is why user interfaces have gotten worse over the last 10 years, even as developers have gathered unprecedented amounts of information from telemetry. Is the most common feedback developers get from telemetry "good, but needs more whitespace"?
Telemetry tells your ISP and national military your usage patterns, too. When, where, and how often you use the tools is itself private.
Imagine a private journal that reported to the government every time you wrote in it, and what city you were in when you did so.
Furthermore, VS Code is specialized software. Using it in certain places allows a specific user to be tracked and identified out of millions of more "normal" traffic patterns, as developers are still a tiny minority in society.
Because maybe developers in your bank or hospital are using IDEs with nasty telemetry that might expose data on you? Maybe they are editing a branch called "workaround-for-mr-cachestash-bankrupcy-account-bug"?
Indeed. And since they are very open as to what they collect, feel free to point out anything disturbing.
As for the publicly posted results, it seems to me like they try to understand who uses their products and how. That's not worse than basic website analytics, and that's data they certainly need in order to prioritise their development.
But I may be missing your point. Can you point to a specific datapoint in those documents that you object to, and explain why?
When they post full csv files with all kinds of command line arguments including typos, who's to know your "dotnet run fix-aspycts-bankrupcy-account" command, where you forgot the first "run" argument, won't end up in a csv some day?
I can't believe I have to argue about how bad it is to have CLI tools send their arguments as telemetry. Even half-arsed lately introduced attempts at redaction doesn't change the fact that the entire mindset of the developers are poison.
And how exactly do you think they would look at all the source code in the world? Humans are too expensive.
So probably AI. How would AI tell the difference between valuable banking software full of bugs and your side project full of bugs?
Also from there, why would you include a customer's personal information in your code, or even have it on your own machine?
Really, the chances of vscode's telemetry leaking personal user information is super extra low, unless you're obviously doing something wrong with your code.
Ah, and finally, if you're using github, they have a much more efficient way of getting your code anyway.
It's interesting, if we look at the size of webpages in everyday browsing, which can go from tens of megabytes to a few kilobytes when blocking tracking/analytics scripts.
I wonder what would be the back of the napkin calculations for network traffic and energy savings (local and server side) of regulating tracking and telemetry?
Is there an environmental case to be made against modern web practices on tracking and telemetry?
I've really come to dislike Google over the past decade or so, but I do like that their Speedtests, Lighthouse etc don't hide this fact from you.
Pretty much all sites I've been asked to look at were getting low scores because of Google Tag Manager, Adsense and the like. It has a very measurable impact, and yeah, removing it speeds up the page.
The environmental case will probably not fly for regulation, but it just might in public shaming of large companies. "Hey, $company, your usage of $trackingTech uses as much power per year as an average family of four. Is that really in line with your green approach?"
This is exactly one of the reasoning pillars i'm using in arguments about the "innocuous" nature of telemetry and tracking.
Any new product that collects telemetry/does tracking requires storage that is bought and connected to a power source with high availability given it performs I/O all the time.
>>I have zero personal information in the IDE and all the code I work on is already in the public domain with an open source license, so why should I care?
Off the top of my head: API tokens and other credentials that live right in the file while you develop and debug.
Those are quite sensitive. To put more wight on the issue[0]
Since when does the telemetry even send out any contents of any files?
Since pretty much forever? At the very least, many programs with built-in telemetry have included things like memory dumps of key areas at the time of a crash, which could include data the user was working on at the time.
More seriously, I invite you to read Microsoft's extensive privacy policies and try to satisfy yourself that they don't grant themselves the right to upload your code. They are sufficiently nebulous and ambiguous that they could probably be interpreted that way.
>> Since when does the telemetry even send out any contents of any files?
To me it's not evident otherwise until i'm capable of observing bare data itself. Not obfuscated, not in some proprietary format to secure it in-transport but the raw stuff.
MS states there's no reliable way to let people see the data being collected (even under GDPR) as there's no sing-in experience provided.[0]
While a part of the statement is true, most of privacy conscious VSC users aware that every installation of the product has a unique `machineId` property. Can be located at Output -> Log (Shared).
The [0] provides some elaboration:
"We do send information that helps us approximate a single user for diagnostic purposes (this is based on a hash of the network adapter NIC) but this is not guaranteed to be unique. For example, virtual machines (VMs) often rotate NIC IDs or allocate from a pool. This technique is sufficient to help us when working through problems, but it is not reliable enough for us to 'provide your data'."
So, given the premise the user can be identified by a NIC plus a machineId (which looks to be an UUID) — it's easy to get access to collected data. As soon as ability to verify no really critical data is collected, i'll switch back from VSCodium.
I choose to trust MS are using the telemetry for improving VS Code, which I genuinely love, and accept the "risk" that MS somehow abuses the telemetry. I see this risk way lower than e.g. Google or Facebook abusing data they can collect about me.
That's a Flatpak version of Visual Studio Code, which only works on Linux. Unfortunately, it's unmaintained and stuck on version 1.41.1 (December 2019).
Arch Linux users do have access to a fully open source version of Visual Studio Code in the community repository, which includes access to the Visual Studio Marketplace:
Not sure if it's still possible to access the vast extension marketplace from Microsoft, which is the true value. If I remember correctly, that can only be accessed from the VS Code released by Microsoft.
the readme for vscodium says they've put up an alternative place: https://open-vsx.org
> According to the VS Code Marketplace Terms of Use, you may only install and use Marketplace Offerings with Visual Studio Products and Services. For this reason, VSCodium uses open-vsx.org, an open source registry for VS Code extensions
Extension marketplace access it might, but I wonder if the .NET debugger will work with it. I remember it was specifically prohibited to run on the non-microsoft built vscode. Without this extension, the .NET coding experience is very meh
Yep, it also works fairly well. I'm maintaining a couple services at my day job that are designed to only work on Linux. VS Code is also involved because we're heavily using the Remote Development feature (which only works in MSFT's VS Code, not in VSCodium, because of licensing) to run the IDE core inside the container, so the dev environment is well standardized and portable across devs/host OS
.NET core works pretty well on Linux - I have an ASP.NET Core side project and work exclusively from a Linux machine. The other two maintainers work from Macs.
This is the right way to lay out a fork. It can be clearly traced and reviewed in a short amount of time. I’ll still use mainline VSCode but it’s nice to see someone handling the “just one purpose” approach without throwing in a lot of other unnecessary things.
MS does not allow their branding to be distributed in unofficial builds. So if you want a custom build of VS Code, you are required to swap out the branding.
Barely-educated guess based on Debian / Mozilla stances on the matter: un-branding an OSS project can be necessary to avoid trademark infringement.
edit re sibling comment: yup, the MIT licensed code provided by microsoft is apparently unbranded (i.e. it wasn't "removed"). This is almost certainly done for trademark protection.
> This repository contains build files to generate free release binaries of Microsoft's VSCode. When we speak of "free software", we're talking about freedom, not price.
> Microsoft's downloads of Visual Studio Code are licensed under this not-FLOSS license and contain telemetry/tracking. According to this comment from a Visual Studio Code maintainer:
> When we [Microsoft] build Visual Studio Code, we do exactly this. We clone the vscode repository, we lay down a customized product.json that has Microsoft specific functionality (telemetry, gallery, logo, etc.), and then produce a build that we release under our license.
> When you clone and build from the vscode repo, none of these endpoints are configured in the default product.json. Therefore, you generate a "clean" build, without the Microsoft customizations, which is by default licensed under the MIT license
> This repo exists so that you don't have to download+build from source. The build scripts in this repo clone Microsoft's vscode repo, run the build commands, and upload the resulting binaries to GitHub releases. These binaries are licensed under the MIT license. Telemetry is disabled.
> If you want to build from source yourself, head over to Microsoft's vscode repo and follow their instructions. This repo exists to make it easier to get the latest version of MIT-licensed VSCode.
> Microsoft's build process (which we are running to build the binaries) does download additional files. This was brought up in Microsoft/vscode#49159 and Microsoft/vscode#45978. These are the packages downloaded during build"
That's the entire contents of the link. Which part of that do you think explains why they don't use Microsoft branding?
> none of these endpoints are configured in the default product.json
Literally all it says is that by default it doesn't use Microsoft branding. It never says 'why'. At all.
But only if you trust Microsoft to honour that setting indefinitely, and not for example to just change it back later or hide something shady behind another option instead. At this point, a lot of people understandably don't.
Sure, and then you could check again every time there is an update. But why bother, when there is already an uncontaminated version readily available to solve this problem for you?
Technically you don't, just like any other software, but the risk is surely significantly lower since everyone including Microsoft is saying that what Microsoft is doing is taking that same code and then adding its contaminants on top.
Sure, but almost all software is not produced by a giant corporation with a well-established track record of pushing user-hostile changes via updates, including overriding or reverting the user's explicitly chosen privacy settings, and including taking such actions in the recent past.
Microsoft is not on your side when it comes to privacy and data security. It has made this abundantly clear both by its actions and by the statements of its senior leadership. However much anyone here might like VS Code, it is still a Microsoft product, while the alternative under discussion is not.
I'm genuinely surprised so many people seem to be leaping to the defence of VS Code here. Why? It's the same application, just made worse by Microsoft's telemetry (and the accompanying infamously opaque privacy policies). Unless you need one of the extensions that is tied specifically to the official Microsoft version, why wouldn't you go with the safer option?
I'm not defending MS just curious. Safer option is not convinent by any means. The fork linked is also open to malicious behaviour. The maintainer can sneak in any code, issues we seen similar to npm.
So if you feel this way about MS then you cant be on Windows. Apple have also been known to report users location secretley on iPhones. I'm on OSX and i dont entirely trust them either. Theres too many holes here, really have to patch them all if this is the stance we are taking.
Theres too many holes here, really have to patch them all if this is the stance we are taking.
I agree that the modern spyware infesting our operating systems is also a significant concern. I disagree that having more than one problem to deal with is a good argument for not trying to solve the one at hand.
Do you guys turn JS off completely while surfing the net because you don't like someone analyzing your uses? It's hard to imagine what your comfortable life would look like.
For the same reason offbrand Firefox builds are called things like Icecat. Mozilla/Microsoft make the code available as open source, but that doesn't include a license to use the official name/logo or the company's brand. So if you roll and distribute a build without their authorization, you have to call it something else.
I’m sure Microsoft would hate any tweaked version hosted by third-party developers to use their branding (even if the only change is tweaking a few configuration variables by default)
You don't need to remove branding to disable tracking for corporates like Amazon. For example, They might have some firewall in the network which blocks tracking API.
You need to remove branding to be allowed by Microsoft to distribute an unofficial build. You need to distribute an unofficial build to make sure that the application isn't trying to find holes that might have been accidentally left in your firewall. (Quick, without googling, which ports and dest IPs do you need to block? Which ports/dest IPs will you need to block in the next version that hasn't been released yet? Yeah, a losing battle.)
Note that this only includes Microsoft's telemetry, and it seems that Microsoft uses the built in telemetry tooling within their extensions. However, community extensions can still use their own telemetry, which this wouldn't prevent.
Is there a listing maintained of all the telemetry info. sent? I personally am not in principle against telemetry, if they do not leak any private info. and are not to chatty.
