Work at GitLab, we've halted any movement on adding telemetry and are reconsidering our approach. More info is on this issue: https://gitlab.com/gitlab-org/growth/product/issues/164
> 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.
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.
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:
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.
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.
Edit: removed most of the post. Rewrote the rest of it.
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.
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.
Your CFO is making these sorts of decisions, not developers. Good luck with the business, but I'm out.