Drew's comment there explains the fundamental issue.
> Drew DeVault @ddevault · 1 hour ago
> Obligatory disclaimer: I work for a GitLab competitor.
>Thank you for pumping the brakes, but this is still not great news. This language is the classic "defuse, wait, and try again later" approach to shoeing in unpopular changes. You're still hedging their bets with this language, rather than renouncing the original ideas. A similar tactic we've already seen is apologising for "bad communication" instead of the real problem: bad changes. Until a real apology is issued and the changes renounced, this isn't very meaningful.
"Reconsidering the approach" is CYA talk. What you're doing right now is an attempt at damage limitation instead of fixing the actual problem.
Third party telemetry is a cancer that no-one wants.
You, personally, don't even want it. You know you don't want it, but you're adopting the 'corporate mask'.
Just stop, please. For your own good, as well as that of the wider ecosystem.
Can you provide some insight onto what 'telemetry data' is being collected and what the data is being used for?
Edit: I don't think telemetry is always bad. Obfuscated telemetry tells me you're potentially collecting stuff that you don't want me to know about, but things like clicks, mouse-movements, etc. are important for understanding how users use a service and not inherently bad.
Hello - what we currently collect is here - https://about.gitlab.com/handbook/product/feature-instrument... and we of course will update that in the future to reflect the details of any telemetry we use - however as noted the team is circling back to evaluate all the feedback and concerns before considering how to improve our existing telemetry (which was the goal).
You need to contain this disaster now by showing unambiguously that you've heard the community and announcing that you're simply not going to do this. This is an existential risk for you. You've just unintentionally shot your own brand; it needs more than a little first aid. Talking evasively ("concerns") is undermining you further.
These things have a super short half life before people just write you off as untrustworthy. But if you reverse it quickly enough, you can turn it into a win. Do it now! The hourglass is getting to that point where there's just a little sand left and it feels like it's starting to accelerate.
Please listen to these comments. There are a lot of them:
There are multiple decisions: opt-in vs. opt-out, GitLab.com vs. self-hosted, DNT vs. in-app, first-party vs. third-party, aggregated data vs. user data.
As an example that we won't do opt-out self-hosted third party with user data doesn't mean we can't do opt-in GitLab.com first party with aggregated data.
Almost every SaaS company uses telemetry in some form to improve their product. We need it too to improve the the user experience of the product.
But we clearly made the wrong trade-offs so we'll go back to square one and make a new plan.
That makes sense, but from a communication point of view it doesn't connect with what people are feeling. The community has a strong emotional bond with you. You need to respond on that level so people feel like they've been heard. You don't need to make all those decisions first in order to do that. Maybe you should do an Ask HN about how to proceed with these options. At least announce that you fucked up, apologize, and say that however you go forward will be crafted together with the community.
As far as I'm concerned, there's only one decision and it's clear that you've already made it. Client-side telemetry is a hard no-go for me. Not that my opinion matters much. I've deleted my account and will be reversing my attempts to secure funding for my organization to move to Gitlab. This is a bridge that can't be un-burned as far as I'm concerned.
> We need it too to improve the the user experience of the product.
I really appreciate you guys engaging in this public discussion. I hope you take what follows in the friendly spirit I intend:
> We need it too to improve the the user experience of the product.
This ^^^^ sounds like exaggeration to me. Taken literally, you're saying that the gitlab user experience could not be meaningfully improved without adding telemetry.
I'm not a UI designer, but I'm fairly sure that before telemetry existed, product-improving iterations were a thing.
But based on other people's comments, I think this is a tangent. I suspect that 99% of people's upset is making the telemetry something other than opt-in. I suspect that if gitlab would just commit to making telemetry opt-in and GDPR-compliant, all would be right with the world.
Should have passed an A/B test on your headline with a focus group. Everything with all the Facebook privacy issues it's getting much harder to push tracking on the technically literate.
I personally don't care if your hosted one takes telemetry as but if it ever makes it to CE I'm dropping gitlab in favor of I guess paying for some other hosted service. That or I'll patch out the telemetry.
don't take these comments on HN seriously. there are 100 trolls that wine on here daily because you want to track if a button is in an optimal place. ignore it and keep building great products.
Alternatively, please _do_ take these comments seriously, since some of the people reading this post and following this discussion are the ones who help their organizations make purchasing decisions about on-prem VCS solutions. I'll certainly be making sure that the people at my organization who are evaluating which VCS to buy are aware of Gitlab's choices regarding telemetry.
Yes, this. As it happens, I am currently tasked with selecting a system like this to replace what we currently use. I was strongly leaning toward recommending Gitlab, but am no longer. (To be clear, I haven't ruled it out, either, despite the fact that I've stopped using it personally -- it's just that it's not the leading contender anymore.)
One thing worth considering is the possibility that the type of user that migrates from GitHub to GitLab on the basis of GitHub's lack of "purity" is going to perceive any "impurity" in GitLab not merely as a change, but as a betrayal.
> we've halted any movement on adding telemetry and are reconsidering our approach
Your firm communicated a willingness to break users’ tools, wilfully violate GDPR, and interrupt users’ business continuity, all to spice up some IPO metrics. That’s a lot of trust to rebuild.
I’d recommend putting guarantees against telemetry into your ToS. Also, a minimum announcement period before mandatory ToS revisions and a minimum amount of time before GitLab can nix users for not agreeing to a new ToS.
Backpedaling due to bad PR does not reestablish trust. Gitlab has demonstrated that they're willing to breach trust if they can get away with it. They're dead to me.
Do you really think anyone is naive enough to believe this sort of thing won't become the norm? It's pretty clear GitLab has drank from the poisoned well.
Your CFO is making these sorts of decisions, not developers. Good luck with the business, but I'm out.
I don't know what that means, but this is the handbook page on my position: https://about.gitlab.com/handbook/marketing/community-relati...
although I've been needing to update it a bit. My job is to basically relay feedback to the rest of the company, and relay any information back to you all that might be relevant. We don't wanna be out-of-touch with what people are really saying about us, and we wanna make sure you're input is received, so that's basically why my team exists.
My questions come from the fact that you, and others from Gitlab, are coming out of the woodwork in groups in response to public negativity and trying to play it cool, eg "wanna".
At least to me, it feels hollow, just like your response right now. It makes me think that Gitlab knew that there was going to be a backlash, and only sent your team out to mitigate damages. "There is no such thing as bad publicity" sort of deal.
If Amazon did the same thing you were doing right now, everyone would be up in arms.
It is the feedback from you all that is responsible for us rolling back the ToS and reconsidering our approach to this. My job, genuinely, is to relay concerns back to the people who make decisions like this. Sid has said in another comment that he wasn't expecting praise, but didn't expect the backlash to be this bad. If they were I really wish they would've given me a heads-up
I think you're reading too far into it. GitLab announced something and received a ton of backlash for it, so they are understandably trying to minimize damage.
It was more than an announcement. They cutoff access to gitlab and broke automated workflows. It shows that they don't know their customer base that well if they were willing to do that. Surely they knew they'd break automated workflows?
So, either they don't care that they broke those workflows when they made this change, or they didn't know that the workflow breakage would be bad. Both are shitty and implies a lack of understanding of their core user base. So, sending customer reps out like they are now screams to me that gitlab really only cares about presentation.
OK, here's what we're saying (most of which is covered by the GDPR principles):
1. Telemetry of any kind from a self hosted instance of your product MUST be opt in. Telemetry from your SaaS SHOULD be opt in.
2. The type and content of data that is collected MUST be documented.
3. That data MUST only be collected by Gitlab under a privacy policy and if it is collected by a 3rd party, that 3rd party MUST comply with the Gitlab policy. Changing a TOS doesn't cover it at 30 days notice doesn't cover it.
4. Under GDPR, any and all data collected MUST be available on demand to a customer. Even if Gitlab is not EU based, you sell to the EU and are therefore covered by the GDPR.
5. The data MUST NOT be saved if the customer ends their relationship with Gitlab and MUST be deleted on request of the customer if it is not required for the service to operate.
6. Under GDPR, the data MUST NOT be used for any purpose other than the documented purposes and MUST NOT be saved beyond the period required.
These are basic privacy principles that apply to ANY business, given that Gitlab operates on data that is highly sensitive (ie a corporation's IPR for their code, a corporation's requirement to also be compliant with GDPR etc), you should be operating to a HIGHER standard.
Thank you for this! We've been creating a point-by-point list like this as well but your point #2 especially is something I don't think we've included, I'll add it.
I agree the huge amount of copy-and-pasted or otherwise hollow responses from GitLab employees here and on their issue is annoying and counterproductive, but it's literally their jobs. Push back against GitLab, not their rank-and-file. It's undoubtedly a rough job.
