Hacker News Reader

> I want to reiterate that we are using this data to improve the product experience.

This sentence holds zero meaning and is not helpful in any way.

Free software, like science, is built upon proof, not upon trust. Here you are asking your users to trust you, but you shouldn't need to do that in the first place. Trust is earned and cannot be asked for. The fact that most of your product has visible source code except for the tiny part with suspicious behavior does not help your case.

And I guess you will make it opt-in instead of opt-out for the self-hosted Enterprise Edition, right?

Edit: also, the email you sent out to your users is very different from your blog post. In the blog post you ask for feedback from your users, which is not the case in the email, which is written as an actual announcement that this is going to happen.

We've heard your concerns and questions. There were many more concerns than we expected. We’re going to process the feedback and rethink our plan. We will not activate product usage tracking on GitLab.com or GitLab self-managed before we address the feedback and re-evaluate our plan. We will make sure to communicate our proposed changes prior to any changes to GitLab.com or self-managed instances, and give sufficient time for people to provide feedback for a new proposal. We'll work in this issue: https://gitlab.com/gitlab-com/www-gitlab-com/issues/5672

Here's an MR updating our blog post accordingly: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/...

We also rolled back all changes to our Terms of Service and our Privacy policy, and we updated our blog post accordingly: https://about.gitlab.com/blog/2019/10/10/update-free-softwar...

> We have not yet added instrumentation to the self-hosted Enterprise edition versions, and we will not do so until we have a way for self-hosted customers to easily control whether tracking is enabled in their environment

Every single time a gitlabber speaks on EE, they use the "not yet added" verbage. This gives zero confidence to anyone!

Such a dumb move.

> I want to reiterate that we are using this data to improve the product experience. Currently we are blind to what is being used in the product, how customers flow through the system, etc. Without this usage data it is very difficult to build a great customer experience.

Here's why that line of reasoning won't fly with users:

- People are buying/using software for what it can do right now, not for what it can hypothetically do in the future. So the only change that matters in this context is before it didn't run untrusted third party javascript, and now it does. All in service of adding things that I probably don't want or need. (because again, if I chose to use it, it already does what I want). You're putting hypothetical new users over the clear desires of current ones.

- People made good design decisions long before they had a flood of data. There's a false equivalency here, you don't need this information to do your job well, you just want it.

The most major one though:

- You're (probably illegally because of GDPR?) holding the service hostage until people "agree" to this.

So to summarize, you're making a decision that potentially negatively impacts the security of your current users data by running untrusted 3rd party code, to gain data that might, vaguely, help you get new users. (Maybe you can replace some of the ones you're driving away!)