VS Code without Microsoft branding/telemetry/licensing
github.com
github.com
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 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.
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.
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.
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.
The bigger risk is that MS would start selling your usage without you even knowing, don't forget it's an advertising company as well.
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.
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.
- 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.
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.
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.
Because it still does not support ed25519 keys and because it is closed source you can do absolutely nothing to fix it.
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 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.
> "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.
[0]: https://en.wikipedia.org/wiki/Embrace%2C_extend%2C_and_extin...
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.
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.
https://chromium.googlesource.com/chromium/src/+/master/docs...
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?
> 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.
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).
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)
Make sure there's no offensive variable names and comments left over from that one guy who used to work here.
(And maybe not everything is offensive, but un-offensive terms exist?)
"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
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
> 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.
> 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.
vim scp://user@example.org//path/to/file
(Basically edits a local copy and pushes saves as scp uploads)
I've found this very useful in combination with a decent ssh config file.
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.
Same thing is done by JetBrains: you can have the open-source Idea CE for free, but if you want e.g. Spring-specific support in Java, you have to pay.
Whether this is a right balance for you, is for you to choose.
[Update: I didn't know the closed parts of VSCode are given away, too]
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?
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.
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.
On a windows cpu with WSL, it takes like 30 seconds to recompile a simple nextjs frontend...
WSL makes 0 sense when you have unix/bash available in the OS like is the case with Linux/Mac anyways.
Maybe the azure part... But I stick to heroku/netlify/vercel anyway.
People were also saying in a HN thread about WinGet the other day that privately-compiled builds would not have telemetry.
Only way for software to improve is to get usage data.
Would you rather be stuck with crappy software dictated by the needs and wants by the minority?
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.
That's a bold claim. Why not make something that works for the dev and then take user feedback into consideration?
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.
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?
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.
They report on things like button usage, time spent in app etc. Possibly personal information about the developer, although unlikely.
But your code? No no, they're probably not looking at your buggy code...
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.
And then they post the results publicly. https://devblogs.microsoft.com/dotnet/what-weve-learned-from...
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?
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.
I can't believe people don't even read the "proof" they provide themselves.
Does anything here seem malicious?
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.
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.
That’s very arrogant of you
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.
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.
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.
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).
Isn't that the point of today's discussion: you can use the privacy-respecting alternative instead?
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.
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.
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 ...
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.
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'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.
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.
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.
I don't know, but I'm pretty sure telemetry is not making UI worse.
why do you close the door when you go to the toilets? It's not like what you do in there is really not known.
It's ok if you're a boring type for your whole life.
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]
[0] https://medium.com/@stestagg/stealing-secrets-from-developer...
That's called stealing not telemetry.
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.
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.
Or is this Linux only?
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:
https://cdn.vsassets.io/v/M146_20190123.39/_content/Microsof...
> For this reason, VSCodium uses open-vsx.org, an open source registry for VS Code extensions.
> 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
Also you can't block telemetry by Windows firewall.
P.S. Proud hoster of VSCodium Linux repo https://gitlab.com/paulcarroty/vscodium-deb-rpm-repo
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?
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.
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.
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.
Therefore, you generate a 'clean' build, without the Microsoft customizations, which is by default licensed under the MIT license
> 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.
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.