I've always thought of Gitlab as a privacy minded company, until now, and the botched attempts to listen to feedback are only worsening my impression. Please prove me wrong!
DNT is basically a failed technology; if you really care about not being tracked you would just block the trackers rather than asking them to pretty please not track you.
(Edited to add: as others have said, this should not be opt-out anyway. Opt-in is much less user hostile, and as far as I know is legally mandated in the EU anyway.)
Opt-out is pretty hostile UX for something you must have known would be seen as a negative by large swathes of the developer audience (and if you didn't see the negative reaction coming, then there's larger questions to be asked).
I'm a free user, so I'm "happy" insofar as I have very little say, but it's certainly a worrying step.
We didn't expect praise for more telemetry from the developer audience but we did underestimate the reaction. There were many more concerns than we expected. We’re going to process the feedback and rethink our plan. We will not activate tracing on GitLab.com or GitLab self-managed for now. We'll make sure to communicate in advance on our blog when we do have a new plan.
Be serious. You knew what the reaction would be. You gambled on it getting missed by the community and lost.
We published this change in a blog post and sent an email.
Also, might be a learning about engaging the community on things it understands - a common user of a SaaS platform might not have an understanding of tech, but a common user of a developer SaaS platform does.
If when I had next logged into the dashboard I got a modal that asked me "hey, here's a list of things we'd like to monitor to make your experience better, what data would you be happy we looked at?" I'd probably opt-in to some just to be helpful as I know the context.
I'm guessing a lot of your mid-market acquisition (though likely not revenue) is through word of mouth, migrations or "dark procurement" (?) - audiences that are ultra-sensitive to this sort of thing, so the misstep here is a question.
I would have thought this would be one of the most important steps in implementing this change. Surprises are never good for people working in this field.
* Devs are very sensitive to tracking. Especially opt-out rather then opt-in. We know what kind of data companies sit on. And opt-out is invasive.
* Gitlab is perceived as a developer friendly open source company. An alternative to the bloated/"enterprisey"/milk the customer stacks out there
* Self-hosting should come with a promise of privacy
* Disabling API/UI access without opt in is just a really bad move. You should have seen the anger coming from a mile away.
* The claim that you can't get insight into how Gitlab is used without client side telemetry is very dishonest.
You have a wealth of data in the DB and web server logs. True, you won't know how long a user fiddles with the mouse until they click a button. I understand the urge to optimize the UX. But user studies go a long way.
And let's be real: this isn't about optimizing button placement, but about showing some nice engagement graphs to investors.
Also, the whole response both in the issue and here was quite poorly handled in my opinion.
The back and forth here... Copy-pasting a reply to each commenter in the issue... (really?)
Just re-consider and put out a unified response.
We have a lot of data in the DB of GitLab.com but it was hard to understand it. Using a third-party service with client side tracking saves a lot of time and effort.
That's like me inviting you to my house and you show up with a pet pig. Your pig might be clean and well behaved, but I'm not letting it my house because it's a pig.
I trust GitLab and I'm ok with the spirit of what you're trying to do, but if you want me to opt-in to client side tracking from a 3rd party (in an untrustworthy industry), you'll need to convince me the company you're working with deserves to be trusted.
On a smaller project, we have implemented Gitlab CE and it was/is in the lead of the various alternatives.
Telemetry to any external service from inside our VPN is a definite no-go. Not to mention that it would be blocked in our configuration, but if that meant that the application didn't run, then we need to make another choice.
Telemetry to a specific provider that we have licensing and other arrangements with would be manageable, as long as the data collected was documented and we could determine that there was no possibility of data leakage beyond that declaration. It would need to be opt-in and it would need to be under conditions that both parties agreed to.
Tell your CFO that if he wants to sell to enterprise, particularly self-hosted enterprise, then he needs to get his head out of the "SaaS" world and deal in the world of Enterprise, where things like SOX and HIPAA and GDPR and PCI/DSS and other standards preclude "collecting data on our users".
I've always opted into telemetry because I assumed companies just use it to improve their products. I guess I've never actually been in the inside of a big company, though. Do they do something else with it I should know about?
Great!
Every single one of our concerns was raised by someone in your own MR thread. C'mon, you were just hoping people wouldn't raise too much of a fuss.
Alice> We want to do a thing, and we want everyone to do it without being able to realistically avoid it while still saying "we gave them an option"
Bob> Let's use DNT, it's used by almost no-one and is largely obsolete.
Alice> Perfect!
It's a bit like web sites that allow you to opt out of tracking and targetted advertising by directing you at the cookie config settings in your web browser. A token gesture.
DNT is dead as a dodo, and many people either use browsers that no longer support it or are strongly resistance to enabling it because it's used as a signal in fingerprinting browsers.
I'm not sure why you thought DNT would help.
Your EE users use your self-hosted product because they don’t want anything leaving their premises — not a single bit of data. If you require this, do you really think EA, SIEMENS, Ericsson, Lockheed Martin or Bayer are going to let any data from their instances with potentially secret and internal future projects leak out to you or your third parties? No, they won’t. They’ll require you signing a contract that you won’t track them, or they’ll switch vendors — you’re the small fish in that case.
Additionally, I’d suggest reading and understanding the GDPR — the text is actually surprisingly simple:
https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CEL...
So you, or in case of the EE Edition, your customers, have to have explicit, clear, and freely given[1] consent to allow any telemetry or tracking which contains PII to happen at all, and especially to give any PII to third parties. Pseudonymous data counts as PII. Data which contains the IP (such as a direct connection to a third-party server to transmit data) counts as PII.
[1] Even more interesting, freely given consent is defined as explicitly opt-in, and it has to be in clear and simple language, the default (and/or the biggest button) has to be rejecting everything, and the consent can not lead to any functional changes, so you can’t require opt-in to let the user access any functionality either.
"Enterprise Edition (EE) No current changes. We are not adding telemetry services to EE at this time."
Which was recently added after receiving a metric ton of backlash. You have to question their initial thought process here.
The original title was "Remove the ability to toggle sending telemetry data back to GitLab", then "Remove the ability for on-prem users to toggle sending telemetry data back to GitLab"
>I'm not familiar with the term "dark patterns".
Then you should not be suggesting changes like this in the first place.
>I want to highlight again that public sector customers will be excluded from this. I've mentioned many times that it's important we respect their strict privacy requirements.
But fuck private sector customers? What?
That sounds like something to rely on, especially given how they've handled this so far. Also, this wasn't originally there.
Emphasis mine, but the wording is notable.
Respect your users and respect yourself, roll back the change, make an apology PR piece and move on.
I think a big problem is that it was so unexpected! Especially the API changes, where people probably are wondering why things aren't working today. Some advance notice would have helped, probably.
I've used Gitlab in the past and will continue to use it here and there, though I host all my own repos at home with just regular old git and use Github for work, so take what I'm saying with a grain of salt because I'm technically not a heavy user of your service.
Enterprises have been dealing with GDPR, CCPA, and data privacy issues for several years now. The apparent fact that Gitlab doesn't recognize when they're running afoul of opt-out standard practices mechanisms, and has those vulnerabilities appearing to be not caught during the SDLC is probably causing a lot of second guessing of competency by your more mature customers.
edit: This isn't a problem unique to Gitlab. Microsoft, for example, has encountered and dealt with this problem (telemetry privacy issues) as well (https://docs.microsoft.com/en-ie/DeployOffice/privacy/overvi...). Search for "Microsoft Dutch DPIA" for all the sordid detail.
And why did the lead email mention SOC2 and not CCPA and GDPR?