Why we collect telemetry
...our team needs visibility into how features are being used in practice. We use this data to prioritize our work and evaluate whether features are meeting real user needs.
Sometimes HN drives me crazy. From this thread you’d think telemetry is screen recording your every move and facial expression and sending it to the government. I’ve worked at places that had telemetry and it’s more along the granularity of “how many people clicked the secondary button on the third tab?” This is a far cry from “spying on users”.
1) Metrics lead to wrong conclusion. There is software which has extremely rarely used features, I need it once or twice a year only, but the ability is why I use the software to begin with. If metrics get too much attention such things are removed as being unimportant ...
2) a lot of the tracking happening is way too intrusive and intransparent. There are valid use cases, however some large corporations especially, in the last had cases where they collected way too much, including private information, without really giving information about it. That overshadows good cases.
Yes, admittedly, the first time you do these things, they're difficult, hard and you have lots to learn. But as you do this more often, build up a knowledge base and learn about your users, you'll gain knowledge and experience you can reuse, and it'll no longer take you weeks or months of investigations to answer "Where should this button go?", you'll base it on what you already know.
> What I’m saying is that only relying on user interviews without supplementing them
I also took your "spend the weeks to months of expensive and time consuming work [...] Or you can look at the analytics" as a "either this or that proposition", where if we're making that choice, I'd go with qualitative data rather than quantitative, regardless of time taken. But probably it comes down to what tradeoffs we're willing to accept.
Usage data is the ground truth.
Soliciting user feedback is invasive, and it's only possible for some questions.
The HN response to this is "too bad" but it's a thought-terminating response.
What the ground truth usage data is completely ignorant of is that Netflix's copy is a crappy blurry transfer, and so I got dvds instead.
I haven't been in a single metrics discussion where we didn't talk about what we're actually measuring, if it reflects what we want to measure, and how to counterbalance metrics sufficiently so we don't build yet another growthhacking disaster.
Doesn't mean that metrics are perfect - they are in fact aggravatingly imprecise - but the ground truth is usually somewhat better than "you clicked it, musta liked it!"
One: Building a good UX involves guesswork and experiments. You don't know what will be best for most users until you try something. You will often be wrong, and you rarely find the global maximum on the first try.
This applies to major features but also the most trivial UI details like whether users understand that this label can be clicked or that this button exists.
Two: Like all software, you're in a constant battle to avoid encumbering the system with things you don't actually need, like leaving around UI components that people don't use. Yet you don't want to become so terse with the UI that people find it confusing.
Three: I ran a popular cryptocurrency-related service where people constantly complained about there being no 2FA. I built it and polished a UX flow to both hint at the feature and make it easy to set up. A few months later I saw that only a few people enabled it.
Was it broken? No. It just turns out that people didn't really want to use 2FA.
The point being that you can be super wrong about usage patterns even after talking to users.
Finally: It's easy to think about companies we don't like and telemetry that's too snitchy. I don't want Microslop phoning home each app I open.
But if we only focus on the worst cases, we miss out on the more reasonable cases where thoughtful developers collect minimal data in an earnest effort to make the UX better for everyone.
That's because you don't understand your users. If you did, you wouldn't need to spy on them.
> you rarely find the global maximum on the first try
One never finds the "global maximum" with telemetry, at best a local sort-of maximum. To find what's best, you need understanding, which you never get from telemetry. Telemetry tells you what was done, not why or what was in the people's mind when it was done.
For what, precisely? As far as I know, you can use it to know "how much is X used" but not more than that, and it's not a "ground truth" for anything besides that.
This is why telemetry happens, its faster, easier and more resilient to organizational turmoil.
I don't disagree with that, I was mainly talking about trying to deliver an experience that makes sense, is intuitive and as helpful and useful as possible, even in exchange for it taking longer time.
Of course this isn't applicable in every case, sometimes you need different tradeoffs, that's OK too. But that some favor quality over shorter implementation time shouldn't drive people crazy, it's just making different tradeoffs.
I think in terms of corporate teams this is the issue a lot of times, people just are not on the team long enough to build that knowledge. Between the constant reorgs, these days layoffs and other churn the no one puts in the years required to gain the implicit knowledge. So orgs reach for the "tenure independent knowledge base.
It literally is. The network itself is always listening: https://en.wikipedia.org/wiki/Room_641A
The mere act of making a network connection leaks my physical location, the time I'm using my computer, and the fact that I use a particular piece of software. Given enough telemetry endpoints creates a fingerprint unique to me, because it is very unlikely that any other person at the same physical location uses the exact same set of software that I do, almost all of which want to phone home all the goddamn time. It's the metadata that's important here, so payload contents (including encryption) don't even matter.
"Sure, you can spend the weeks to months of expensive and time consuming work it takes to get a fuzzy, half accurate and biased picture of what your users workflows look like through user interviews and surveys. Or you can look at the analytics, which tell you everything you need to know immediately, always up to date, with perfect precision." -> your analytics will never show what you didn't measure - it will only show what you already worked on - at best, it's some kind of validator mechanism - not a driver for feature exploration.
This kind of monitoring need to go through the documented data exposure - and it's a sufficient argument for a company to stop using github immediately if they take security seriously.
But I'd add that if you take security seriously you are not on Github anyway.
the other crowd that pretends otherwise are larping or only have some generic open source project that only a handful of people use or they only update it every 6 years
Probably because there is no "truth" here, only subjective opinion, there is no "winning", only "learning" and "sharing".
I could ramble the same about how "people relying on data never shipped an enjoyable thing to people who ended up loving, only care about shipping as fast as possible" and yadda yadda, or I can actually make my points for why I believe what I believe. I do know what I prefer to read, so that's what I try to contribute back.
Precision isn't accuracy and all that.
> it’s more along the granularity of “how many people clicked the secondary button on the third tab?”
You don't see the contradiction here?
If the questions you have can be answered by simple telemetry you are likely asking the wrong questions. E.g. a confused user will click all the buttons, while one thst efficiently uses your software to solve a very specific problem may always ever press the ssme ones.
The actually interesting questions are all about how your software empowers users to deal with the things they have to deal with. Ideally with as little buttons as possible. And if once a year they need that other button it will be there.
It is very easy to draw the wrong conclusions from telemetry.
You can tell the difference between those who build businesses and those who simply use them.
While you’re comparing different information sources, you might even want to consider telemetry, too.
Aggregating request statistics server-side unless you're only generating those requests to spy on what I'm doing on my computer is more like the not-spying you're talking about.
Are some companies spying on you the way you say? Yea, probably. Most of us just want data to know what's working and what's not.
I agree, but once you cross the borders out to the internet, I'd say you need to stop seeing that as "Me sitting at my computer at home", because you're actually "on someone else's property" at that point essentially. And I say this as someone who care greatly about preserving personal privacy.
Watching people move their mouse and click stuff on “your webpage” is fucking spying. It’s in my browser. On my machine. Not running on your hardware.
Tracking what I do on my own computer doesn’t stop being spying because the program I’m doing stuff in can make network requests. WTF.
Well, I was mainly talking about network requests, which are quite literally served by "my hardware" when your client reaches out to my servers, and they agree to serve your client. I do agree that it sucks that browser viewports now also are considered "mine" from the perspective of servers, but you do have a choice to execute that code or not, you can always say no.
I don't think it's as much "this attitude took over", people saying that the internet is the wild west and warning you "browse at your own peril" has been around for as long as I can remember.
The attitude that’s changed is that in the 90s and 00s a program that sent information about what you’re doing that wasn’t necessary and expected for how it operates would have been instantly, popularly, and unequivocally labeled spyware by a programmer crowd. Now it’s normal and you get a bunch of folks claiming it’s ok.
This is just nonsense tbh. Surveys and customer outreach solve completely different problems from analytics.
Survey data is still real data that can be used for "analytics".
Some people also hate telemetry. It feels invasive. I have a guess about what direction the percentage of consumers who hate telemetry is moving toward.
And the difference between what they do and what they want is equally shocking. If what they want isn’t in your app, they can’t do it and it won’t show up in your data.
Quantitative data doesn’t tell you what your users want or care about. It tells you only what they are doing. You can get similar data without spying on your users.
I don’t necessarily think all data gathering is equivalent to spying, but if it’s not entirely opt-in, I think it is effectively spying no matter what you’re collecting, varying only along a dimension of invasiveness.
Excellent point.
> but if it’s not entirely opt-in, I think it is effectively spying no matter what you’re collecting, varying only along a dimension of invasiveness.
Every web page visit is logged on the http server, and that's been the default since the mid 1990's. Is that spying?
Logging every page visited is not a technical requirement of serving the requested resource.
How will you know which page is having problems being served or is having performance problems?
Logging the requested resource is not a technical requirement of serving that resource.
We... we are talking about a CLI tool. A CLI tool that directly uses the API. A tool which already identifies itself with a User-Agent[0].
A tool which obviously knows who is using it. What information are you gathering by running telemetry on my machine that couldn't.. just. be. a. database. query?
Reading the justification the main thing they seem to want to know is if gh is being driven by a human or an agent... Which, F off with your creepy nonsense.
Please don't just use generic "but ma analytics!" when this obviously doesn't apply here?
[0]: https://github.com/cli/cli/blob/3ad29588b8bf9f2390be652f46ee...
And you know what happens when you reach out to talk to your customers like human beings instead of spying on them like animals? They like you more and they raise issues that your telemetry would never even think to measure.
It's called user research and client relationship management.
In the OSS world this is not a huge deal. You get some community that’s underserved by the product (ie software package) and they fork, modify, or build something else. If it turned out to be valuable, then you get the old solution complemented or replaced. In the business world this is an existential threat to the business - you want to make sure your users aren’t better served by a competitor who’s focusing on your blindspot.
However, the plural of "anecdote" is not "data". People are unreliable narrators, and you can only ask them so many questions in a limited time amid their busy lives. Also, there are trends which appear sooner in automated analytics by days, weeks, or even months than they would appear in data gathered by the most ambitious interview schedule.
There is a third, middle-ground option as well: surveys. They don't require as much time commitment from the user or the company as a sit-down interview. A larger number of people are willing to engage with them than are willing to schedule a call.
In my experience, all three are indispensable tools.
Yeah, sure. How long is that policy gonna last? How does a user even know that that checkbox does anything?
Once you’ve decided to break a social contract it’s not like you can slap a bandaid on it and it’s all okay now.
> I hope you try to build a business sometimes and open up your perspectives that maybe just maybe you don't have all the answers.
People were building successful businesses long before the Internet.
People in this case are likely extrapolating based on how user data is harvested in the industry at large. So there is bound to be (very likely) some characterization that is unfair to you.
Given modern data aggregation, really data vacuuming, and that software is opaque, it can be really hard to trust anyone with any aggregation of data. They say that they pseudonymize properly. The proof? Trust them bro. Then read yet another news article about how some data aggregation was either sloppily leaked or just a front for selling data.
A natural response to opaque practices by people you don’t trust is a hardline no.
Yes, vendors can, do, and should talk to users, but then a lot of users don't like receiving cold messages from vendors (and some users go so far as to say that cold messages should _never_ be sent).
So, the alternative is to collect some soft telemetry to get usage metrics. As long as a company is upfront about it and provides an opt-out mechanism, I don't see a problem with it. Software projects (and the businesses around them) die if they don't make the right decisions.
As an open source author and maintainer, I very rarely hear from my users unless I put in the legwork to reach out to them so I completely identify with this.
Everything went to crap in the metric-based era that followed.
Talking to users when you have hundreds of customers does no more than give you an idea of what those specific people need. If you have hundreds of users or more, then data is the only thing that reliably tells you these things.
More like flying based on your knowledge as a pilot and not by the whims of your passengers.
For many CLIs and developer tooling, principled decisions need to reign. Accepting the unquantifiability of usage in a principled product is often difficult for those that are not the target demographic, but for developer tools specifically (be they programming languages, CLIs, APIs, SDKs, etc), cohesion and common sense are usually enough. It also seems real hard for product teams to accept the value of the status quo with these existing, heavily used tools.
Flying based on the whims of your passengers would be user testing/interviewing, which is a complementary, and IMO necessary, strategy alongside analytics.
If you have too much emphasis on (invasive) analytics you might end up flying empty i.e. without customers.
This would be _absolutely insane_ telemetry to request from a user for any other piece of software, but it would be fantastically useful in identifying where people get frustrated and why.
That said, I do not trust Microsoft with any telemetry, I am not invested in helping them improve their product, and I am happy not to rely on the GitHub CLI.
Why is it that startups and commercial software developers seem to be the only ones obsessed with telemetry? Why do they need it to "optimize user journeys" but open source projects do just fine while flying blind?
whereas, commercial software has a disconnect between who are the users and developers are
Unthinkingly leaning on metrics is likely to help you build a faster, stronger horse, while at the same time avoiding building a car, a bus or a tractor.
No, because users have different needs and thoughts from the developers. And because sometimes it's hard to get good feedback from people. Maybe everyone loves the concept of feature X, but then never uses it in practice for some reason. Or a given feature has a vocal fan base that won't actually translate to sales/real usage.
> Would Git have been significantly better if it had collected telemetry, or would the data not have just been a distraction?
I think yes, because git famously has a terrible UI, and any amount of telemetry would quickly tell you people fumble around a lot at first.
I imagine that in an alternate world, a git with telemetry would have come out with a less confusing UI because somebody would have looked at the stats and for instance have added "git restore" right from the very start, because "git checkout -- foo.txt" is an absolutely unintuitive command.
Compilers and whatnot seem to suffer from the same problem that programs like git(1) does. Once you've put it out there in the world you have no idea if someone will still use some corner of it thirty years from now.
Thankfully, github has zero control over git. If they did have control they would have sank the whole operation on year one
> because somebody would have looked at the stats and for instance have added "git restore" right from the very start, because "git checkout -- foo.txt" is an absolutely unintuitive command.
How is git restore any better? Restoring what from when? At least git checkout is clear in what it does.
And this is exactly where disconnects happen, and where you need telemetry or something like it to tell you how your users actually use the system, rather than imagining how they should.
A technical user deep into the guts of Git thinks "you need to check out again this specific file".
A novice thinks "I want to restore this file to the state it had before I touched it".
Now we can argue about whether "restore" is the ideal word here, but all the same, end users tend to think it terms of "I want to undo what I did", and not in terms of git internals.
So a hypothetical git with telemetry would probably show people repeatedly trying "git restore", "git undo", "git revert", etc, trying to find an undo command.
This is a fundamental misunderstanding of both the user base who are by design all technical, and the use case that this tool serves: deeply technical and specific actions to a codebase.
Git is not just software. It is also a vernacular about how to reason about code change. You can't just make arbitrary commands do magic stuff by default and then expect that vernacular to be as strong as it is today.
Those "ergonomics" you're asking for already existed in other tools like CVS and subversion, they are specifically why those tools sucked and why git was created.
CVS and Subversion have nothing to do with this, they were extremely different to Git in the way they worked and lost for many reasons that have nothing to do with having command names understandable to normal people.
Surely, telemetry should help educate the tool maker to reveal the underlying model rather than coercing the model to reflect a bastardized worldview (as restore seems to).
Trying to wedge git into workflows that don't operate around git seems like a fool's errand. Either we must build tools around the workflow, or we must build the workflow around the tool.
This is part of why I find jujustsu so unintuitive: there is no clear model it's built around, only some sense of how to work with files I apparently lack. But perhaps it is the perfect tool for some workflow I have not yet grasped!
“a novice thinks”
Just learn your damn tools and stop whining.
For a dedicated "restore" it's worth it to me... (who will not maintain it)
These two commands operate on the same level of abstraction. And they should be equally powerful, which means that whichever you choose to learn will be able to serve all of your restore-content needs. That's what I mean.
Of course there is always the pedagogic cost of having two similar commands.
1. git doesn’t have a UI, it’s a program run in a terminal environment. the terminal is the interface for the user.
2. git has a specific design that was intended to solve a specific problem in a specific way. mostly for linux kernel development. so, the UX might seem terrible to you — but remember that it wasn’t built for you, nor was it designed for people in their first ever coding boot camp. that was never git’s purpose.
3. the fact that every other tool was designed so poorly that everyone (eventually, mostly) jumped on git as a new standard is an expression of the importance of designing systems well.
like how git needs you to “commit” changes as if you’re committing a change to a row in a database table? thats a design/experience issue to me, not an “it has commands” issue.
doesn’t change the bigger, more important fact that the struggles people have with git stem from the system design. i.e. the thing that ultimately determines what commands people need to run in what order (see points 2 and 3).
Also git has a UI.
This mattered because speed is the killer feature [1], and speed is often seen by users as a proxy for reliability [2].
[1]: https://bdickason.com/posts/speed-is-the-killer-feature/
I used Mercurial, professionally, back when there were a half-dozen serious VCS contenders, to contribute to projects that used it. I disliked it and found it unintuitive. I liked Git much better. Tastes vary.
Git made me feel like I was in control. Mercurial didn't.
Mercurial's handling of branches was focused on "one branch, one working directory", and made it hard to manage many branches within one working directory.
Mercurial's handling of branches also made it really painful to just have an arbitrary number of local experimental branches that I didn't immediately want to merge upstream. "Welcome to Mercurial, how can I merge your heads right now, you wanted to do that right now, right?"
Git's model of "a branch is just a pointer to a commit, commits internally have no idea what branch they're on" felt intuitive and comfortable.
Unfortunately this is due to a large part of "decision makers" being non-technical folks, not being able to understand how the tools is actually used, as they don't use such tools themselves. So some product manager "responsible" for development tooling needs this sort of stuff to be able to perform in their job, just as some clueless product manager in the e-commerce absolutely has to overload your frontend with scripts tracking your behaviour, also to be able to perform in their job. Of course the question remains, why do those jobs exist in the first place, as the engineers were perfectly capable of designing interaction with their users before the VCs imposed the unfortunate paradigm of a deeply non-technical person somehow leading the design and development of highly technical products...So here we are, sharing our data with them, because how else will Joe collect their PM paycheck, in between prompting the AI for his slides and various "very important" meetings...
I'm not sure if you're implying it's obvious but it's not obvious to me that it would be unhelpful.
Telemetry is a really poor substitute for actually observing a couple of your users. But it's cheap and feels scientific and inclusive/fair (after all you are looking at everyone)
I mean no solution is perfect, and some underused things are just only sometimes extremely useful, but data used smartly is not a waste of time.
You should be able to see what features are being used by seeing what server endpoints are being hit and how often. Don't need intrusive telemetry. Yes, it's not perfect. Many features could use the same endpoint. You could totally anonymise this and you could still get a great understanding what features users are using by looking at endpoint stats.
Companies need to decide whether they want customer goodwill or very detailed insight into what they are doing. By having invasive telemetry you may have less customers (people leaving for github competitors). Is it worth it ?
Git has horrible design and ergonomics.
It is an excellent example of engineers designing interfaces for engineers without a good feedback loop.
Ironically, you just proved your point that engineers need to better understand how users are actually using their product, because their mental visualizations of how their product gets used is usually poor.
People say this and never has written about the supposed failure of design. Git has a very good conceptual model, and then provides operations (aptly named when you know about the model) to manipulate it.
Most people who complains about git only think of it as code storage (folder {v1,v2,...}) instead of version control.
If you don't want to look at what people write you can't say that they haven't written about it.
> the supposed failure of design
I don’t think people complain about the internals of git itself as much as the complexity of all the operations.
If you want to read about complaints, you really don't have to look further than the myriad of git GUIs, TUIs and otherwise alternative/simplified interfaces.
The complexity is only there when you want to avoid learning what you’re doing. Just like find(1) is complex if you don’t know stuff about the file system or sed(1) is complex if you don’t know regex and line based addresing of a text file.
A lot of people who are using git don’t want to know what a commit is and their relation to branches. And then they are saying rebasing is too complex.
> If you want to read about complaints, you really don't have to look further than the myriad of git GUIs, TUIs and otherwise alternative/simplified interfaces
Git is a cli. The goal is always for you to find your workflow then create aliases for common operations. It does assume that you want complete control and avoid doing magic (which is what jj is doing).
Wanting magic is great (I use magit which makes git magical ;) ) but it’s like wanting to fly a plane without learning the instruments.
It's not that it's insufficient, new developers, product people and designers literally don't know how to make tasteful and useful decisions without first "asking users" by experimenting on them.
Used to be you built up an intuition for your user base, but considering everyone is changing jobs every year, I guess people don't have time for that anymore, so literally every decision is "data driven" and no user is super happy or not anymore, everyone is just "OK, that's fine".
1. It's anonymous
2. They're telling you they're doing it
3. You can opt out of it
Not saying that telemetry more valuable than privacy, just that it's a straightforward decision for a company to make when real benefits are only counterbalanced by abstract privacy concerns. This is why it's so universally applied across apps and tools developed commercially.
If I run "gh alias set foo bar", and that takes even a marginally perceptible amount of time, I'll feel like the tool I'm using is poorly built since a local alias obviously doesn't need network calls.
I do see that `gh` is spawning a child to do sending in the background (https://github.com/cli/cli/blob/3ad29588b8bf9f2390be652f46ee...), which also is something I'd be annoyed at since having background processes lingering in a shell's session is bad manners for a command that doesn't have a very good reason to do so.
All that said, having been in plenty of corporate environments I would be surprised if the data is anonymized and wouldn't be surprised if the primary motivator boils down to something like internal OKRs and politics.
I guess that's the price of regular and non-invasive software.
The software user has no means to verify the explanation or disclosure is accurate or complete. Once the data is transferred to the company then the user has no control over where it goes, who sees it or how it is used
When the company states "We use the data for X" it is not promising to use the data for X in the future, nor does it prevent the company, or one of its "business partners", from using the data additionally for something else besides X
Why "explain" the reason for collecting telemetry
Why "disclose" how the data is used
What does this accomplish
Cause the alternative is viewing all of your app as one opaque blob - you don't know exactly how it's being used, which features actually need your attention, especially if you're spread thin. If you're in consulting or something like that and the clients haven't let you configure and/or access analytics (and the same goes for APM and log shipping), it's like flying blind. Couple that with vague bug reports instead of automated session recording and if you need to maintain that, you'll have gray hairs appearing by the age of 30.
Take that disregard of measurement and spread it all across the development culture and you'll get errors in the logs that nobody is seeing and no insights into application performance - with the system working okay at a load X, but falling over at X+1 and you having to spend late evenings trying to refactor it, knowing that it needs to be shipped in less than a week because of client deadlines. Unless the data is something that's heavily regulated and more trouble than it's worth, more data will be better than less data, if you do something meaningful with it.
> Would Git have been significantly better if it had collected telemetry, or would the data not have just been a distraction?
Knowing the most common fuck ups and foot guns might inform better CLI design. Otherwise people saying that it's good have about as much right to do so as saying that it's bad (at least in regards to UX), without knowing the ground level truth about what 90% of the users experience.
Why not conduct a survey?
> vague bug reports instead of automated session recording and if you need to maintain that, you'll have gray hairs appearing by the age of 30.
If it's a customer, why not reach directly to him?
> with the system working okay at a load X, but falling over at X+1 and you having to spend late evenings trying to refactor it,
No one is talking about telemetry on your servers. We're talking about telemetry on client's computers.
Large amounts of time before getting feedback, low percentage of people responding, not an accurate sample of all users (you will get signal from the loudest ones) and inaccurate data (biases in perception) instead of measurable reality. Not useless, but not a full replacement for telemetry.
> If it's a customer, why not reach directly to him?
Layers of indirection (and also the slowness of getting through them). You might not control the processes and approvals needed to do that in a non-startup environment. You will probably control enough of the app to add various technical solutions to aid you in collecting information.
> No one is talking about telemetry on your servers.
I am. Culture of not collecting client side data also often comes together with a culture of not collecting server side data properly either. Competent teams will evaluate both. My argument is that all of this data can meaningfully help in development and that other approaches don't replace it well enough.
Also, gh cli is not about git, its about the github api. In theory the app has its own user agent and of course their LB is tracking all http requests, so not anonymous ever.
I've repeatedly talked about this on HN; I call it Marketing Driven Development. It's when some Marketing manager goes to your IT manager and starts asking for things that no customer wants or needs, so they can track if their initiatives justify their job, aka are they bringing in more people to x feature?
Honestly, with something as sensitive as software developer tools, I think any sort of telemetry should ALWAYS be off by default.
This isn’t that surprising to me. Having usage data is important for many purposes. Even Debian has an opt-in usage tracker (popcon) to see wha packages they should keep supporting.
What I’m curious about is why this is included in the CLI. Why aren’t they measuring this at the API level where they wouldn’t need to disclose it to anyone? What is done locally with the GH CLI tool that doesn’t interact with the GitHub servers?
Linux and Git are fully open source, and have big companies contribute to it. If a company like Google, Microsoft etc need a feature, they can usually afford to hire someone and develop _and_ maintain this feature.
Something like gh is the opposite. It's maintained by a singular organisation, the team maintaining this has a finite resources. I don't think it's much to ask for understand what features are being used, what errors might come up, etc.
> Git has served us well for 20+ years
Funny. I think that, but the usual HN narrative is that Git is UX hostile.
Yes, probably. Git is seriously hard to use beyond basic tasks. It has a byzantine array of commands, and the "porcelain" feels a lot closer to "plumbing" than it should. You and I are used to it, but that doesn't make it good.
I mean, it took 14 years before it gained a `switch` command! `checkout` and `reset` can do like six different things depending on how your arguments resolve, from nondestructive to very, very destructive; safe(r) operations like --force-with-lease are made harder to find than their more dangerous counterparts; it's a mess.
Analytics alone wouldn't solve the problem - you also need a team of developers who are willing to listen to their users, pore through usage data, and prioritize UX - but it would be something.
Sincerely, a Mercurial user from way back.
If it's truly pseudoanonymous then it's hardly spying, just sayin'...
Others have answered your actual question better than I could have.
"oh no, they're aware of someone at the computer 19416146-F56B-49E4-BF16-C0D8B337BF7F running `gh api` a lot! that's spying!"
>Would Git have been significantly better if it had collected telemetry, or would the data not have just been a distraction?
Definitely
Because they're too shy, lazy, or socially awkward to actually ask their users questions.
They cover up this anxiety and laziness by saying that it costs too much, or it doesn't "scale." Both of these are false.
My company requires me to actually speak to the people who use the web sites I build; usually about every ten to twelve months. The company pays for my time, travel, and other expenses.
The company does this because it cares about the product. It has to, because it is beholden to the customers for its financial position, not to anonymous stock market trading bots a continent away.
Bug fixing absolutely gets taken care of immediately, and our customers are very active in telling us about them through these strange new feedback mechanisms known as "e-mail" and "a telephone."
But we don't spy on people to fix bugs.
Nothing that the big tech "telemetry" is doing is about bug fixes. In the article we're all talking about the spying that Microsoft proposes isn't to fix bugs. Re-read what it wrote. It's all for things that may not appear for weeks, months, or years.
And to think that a trillion-dollar company like Microsoft can't figure out how, or doesn't have the money available to scale real customer feedback is just sticking your head in the sand and making excuses.
Microsoft doesn't need people to apologize for its failure.
Now, let's replicate this with GitHub. What can go wrong?
There are all sorts of best practices for getting info without vacuuming up everyone’s data in opaque ways.
I’m not saying they don’t engage in any of those practices, I am specifically talking about the hardware survey.
Well, you can start with everything a typical HTTP request and TCP connection comes with, surely they're already storing those things for "anti-fraud practices", wouldn't be far to imagine this data warehouse is used for analytics and product decisions as well.
I explicitly said I agree it’s a distinct possibility, but that’s not proof. If you have actual info on what they collect and how it’s used I can assess it. As it is we don’t know the extent or uses at all, we are speculating.
This was unnecessary and patronizing. Clearly this won't be productive as it's clear what I am trying to say, but you seem to intent on taking a narrow interpretation of my point to paint me as someone who blindly trusts Valve (I don't). Have a good one man.
The hardware survey is not that.
The problem I have with a lot of these analytics is that while there are harmless ways to use it, there is this understanding that they could be tying your unique identifier to behavioral patterns which could be used to reconstruct your identity with machine learning. It's even worse if they include timestamps.
Why not just expose exactly what telemetry is being sent when it's sent? Like add an option that makes telemetry verbose, but doesn't send it unless you enable it. That way you can evaluate it before you decide to turn it on. Whenever you do the Steam Hardware survey it'll show you what gets sent. This is the right way to do it.
The opt-out situation for gh CLI telemetry is actually trickier than it sounds. gh runs in CI/CD pipelines and server environments where you may not want any outbound connections to github.com at all, not because of privacy but because of networking constraints. In those environments, the telemetry being on by default means your CI fails or your Bastion host can't reach GitHub at all.
Compare this to git itself, which is entirely local until you explicitly push. The trust model is different: git will never phone home unless you configure it to. gh, being a wrapper around the GitHub API, has to make those calls to function - but that's separate from whether it should also be collecting and uploading your command patterns.
i'd be surprised if the inability to submit telemetry is a hard error that crashes the program
> Removes the env var that gates telemetry, so it will be on by default.
I can't help but guess if these are related.
If you don't want your requests tracked, you're going to have to opt out of a lot more than this one setting.
The line I drew: if deleting the short link removes all the data, it's analytics. If deleting the link leaves a profile somewhere, it's surveillance.
GitHub CLI is the opposite case — the data follows the user, not the artifact they created. That's the part that feels off.
A quick summary of my Claude-assisted research at the Gist below. Top of mind is some kind of trusted intermediary service with a vested interest in striking a definable middle ground that is good enough for both sides (users and product-builders)
Gist: WIP 31 minutes in still cookin'
P.S. You look like villain from Temu.
Those two words have almost exactly opposite meanings, and as stated, they are literally saying they are collecting identifiable data.
Embrace, extend, extinguish.
The first two have been done.
I give it five years before the GH CLI is the only way to interact with GitHub repos.
Then the third will also be done, and the cycle is complete.
I'll take that bet. How much are you willing to put on it?
I do not doubt this, already it seems to be a pain to deal with some repos on github without using gh. I do not know what gh buys you but I have never used it so I do not know if it is "better". To me the standard git commands are fine. But yes, I think the trend to forcing gh upon us is already being done.
None of these happened. none of them even appear to have happened, and none of them appear to have even been planned. It's all a hallucination by people that talk like this. It's all imaginary. Show me any evidence of anything like this. ANY AT ALL. Not a hunch, not something that could be interpreted that way, show me the very clear and repeatable steps that Microsoft used in the 90s to EEE something in anything they're doing today.
They're too busy copiloting everything and arguing with each other to do this. Show me Microsoft Git with extra features over the open source version. Show me Microsoft Linux with extra features over the open source version. Show me Microsoft ANYTHING with extra features over the open source version they copied, and show me the doors slowly closing behind me. You can't. Because it isn't happening.
git repos can't be locked up in the way you're describing. github is a wrapper around git. it would take an enormous amount of work for microsoft to change this fundamental decision in the design of github. GitHub is a git server, over both HTTP and SSH. These are core decisions of the software that everything else sits on top of. If pulling git repos over HTTP or SSH ever stops being supported, so many things are going to stop being supported, that it just won't be useful at all after that point.
the gh cli makes api calls, that's all. it just makes api calls easier. it exposes a lot of api calls as friendly commands. it's not something that most of github users are even aware of, much less use. gh is not going to lock someone into a github "ecosystem" A) because such a thing doesn't exist and B) again, most people don't use it.
Microsoft is far more likely to kill GitHub because of people with MBAs (aka "morons") who somehow call the shots in business these days. They are not going to pilot into the ground by EEE. They are going to pilot it into the ground because they don't know what they're doing, and they don't know what users want or what they like. That will be the fate of GitHub; incompetence will kill it, not cold, calculating, nefarious competence.
For example
gh pr checks --watch
Also, I believe GitHub Actions cache cannot be bulk deleted outside of the CLI. The first time I [hesitantly] used the gh CLI was to empty GitHub Actions cache. At the time it wasn't possible with the REST API or web interface.
The article doesn’t use the word “pseudoanonymous”, only “pseudonymous”.
# Atlas
export DISABLE_TELEMETRY=1
# CloudFlare
export WRANGLER_SEND_METRICS=false
export VERCEL_PLUGIN_TELEMETRY=off
# AWS
export SAM_CLI_TELEMETRY=0
export CDK_DISABLE_CLI_TELEMETRY=true
# ???
export DO_NOT_TRACK=trueAnd less social media shit, maybe adding better LFS alternative similar to huggingface and stuff.
Git isn't the popular choice in game dev because of this assets in tree hosting nonsense, why haven't we fixed it yet.
Similarly many edge cases, also finally they built stacked prs but man does it feel a under baked, and what it's like 2+ years late.
Please just improve Github, make me feel like I will be missing out if I am not on Github because of the features not because I have to be because of work.
* Dev tools because you need to be able to trust they don't leak while you're working. Not all sites/locations/customers/projects allow leaks, and it's easier to just blacklist anything that does leak, so you know you can trust your tools, and the same habits, justfiles, etc work everywhere.
* libraries that leak deserve a special kind of hell. You add a library to your project, and now it might be leaking without warning. If a lot of libraries decide to leak, your application is now an unmanageable sieve.
If you do need to run telemetry, make it opt in or end user only. But if you as developer don't even have control then that's the worst.
Hopfully the codeberg people can improve their UI - the UI is the single reason I still use github (and filing issues is super-simple). I could never handle gitlab because I hate their UI.
Note that GitHub is in the news in the last some months, negatively. I think we are seeing first wear-and-tear signs. If people are smart, this would be a time where real competition to Microsoft GitHub could work. GitHub without users would be dead. Microsoft seems unable to care - they sold their soul to AI. It is make-it-or-break-it for them now.
Today I use a Golang CLI made with ~200K LOC to do essentially the same thing. Yay, efficiency?
the old git command in your terminal
I think I'll keep using that
https://en.wiktionary.org/w/index.php?search=pseudoanonymous...
It is interesting how GitHub sort of prominently features this non-word in their article. Perhaps some South Asian or European person for whom English is a struggle.
There is no word that means "fake-anonymous". I would assume that the author of this article intended to write "pseudonymous" which is a real word with a real definition.
https://en.wiktionary.org/wiki/pseudonymous
But it would also be interesting if they very much intended the ambiguity of using a non-word that is more than it seems on the surface.
It might seems legit from them, but I'm quite sure that just listening to your user is enough. It is not like they lack an user base ready to interact with them or that they lack of bugs or features to work on.
In most cases, the telemetry is more a vanity metric that is rarely used. "Congratz to this team that did the flag that is the most used in the cli". But even for product decision, it is hard to extract conclusions from current usage because what you can and will do today is already dependent on the way the cli is done. A feature might not be used a lot because it is not convenient to do, or not available in a good way compared to an alternative, but usage report will not tell if it was useful or not. In the same way, when I buy a product, often there are a lot of features that I will never use, but that I'm happy to have. And I might not have bought the product, or bought another one if it was not available. But the worse would have the manufacturer remove or disable the feature because it is not used...
Regulators should wake up and fine them hard, so hard to become existential. Make an example for others not to follow.
I know lots of idealists -- I went to a public policy school. And in some areas, I am one myself. We need them; they can push for their causes.
But if you ever find yourself working as a regulator, you'll find the world is complicated and messy. Regulators that overreach often make things worse for their very causes they support.
If you haven't yet, go find some regulators that have to take companies all the way to court and win. I have know some in certain fields. Learn from them. Some would probably really enjoy getting to talk to a disinterested third-party to learn the domain. There are even ways to get involved as a sort of citizen journalist if you want.
But these sort of blanket calls for "make an example of GitHub" are probably a waste of time. I think a broader view is needed here. Think about the causal chain of problems and find a link where you have leverage. Then focus your effort on that link.
I live in the DC area, where ignorance of how the government works leads to people walking away and not taking you seriously. When tech people put comparable effort into understanding the machinery of government that they do into technology, that is awesome. There are some amazing examples of this if you look around.
There are no excuses. Tech people readily accept that they have to work around the warts of their infrastructure. (We are often lucky because we get to rebuild so much software ourselves.) But we forget what it's like to work with systems that have to resist change because they are coordination points between multiple stakeholders. The conflict is by design!
Anyhow, we have no excuse to blame the warts in our governmental system. You either fix them or work around them or both.
The world is a big broken machine. Almost no individual person is to blame. You just have to understand where to turn the wrench.
Corporations can and will do every scummy thing permitted to them by law, so here we are. Until the US grows a backbone on issues of privacy, we shouldn't be surprised, I suppose. But the US won't be growing such a backbone anytime in the near future.
export GH_TELEMETRY=false
export DO_NOT_TRACK=true
gh config set telemetry disabled (starting from version 2.91.0, which this announcement refers to)
gh version 2.90.0 (2026-04-16) https://github.com/cli/cli/releases/tag/v2.90.0
$ gh config set telemetry disabled
! warning: 'telemetry' is not a known configuration key
Also note that even though you get a warning about an unknown config key, the value is actually set so you're future-proof. Check `grep telemetry ~/.config/gh/config.yml`
What's strange is if you check your `~/.config/gh/config.yml` it will put `telemetry: disabled` in there. But it will put anything in that `config.yml` lol.
> gh config set this-is-some-random-bullshit aww-shucks > ! warning: 'this-is-some-random-bullshit' is not a known configuration key
But in my config.yml is
this-is-some-random-bullshit: aww-shucks
gh config set telemetry disabled