1. 50

Blog post with short update linked in issue: https://about.gitlab.com/blog/2019/10/10/update-free-software-and-telemetry/

I couldn’t find the exact text sent by email to GitLab users on their blog/site, so I’ll paste it here. If that isn’t the intended usage of this text box, please let me know :-).

Dear GitLab users and customers,

On October 23, we sent an email entitled “Important Updates to our Terms of Service and Telemetry Services” announcing upcoming changes. Based on considerable feedback from our customers, users, and the broader community, we reversed course the next day and removed those changes before they went into effect. Further, GitLab will commit to not implementing telemetry in our products that sends usage data to a third-party product analytics service. This clearly struck a nerve with our community and I apologize for this mistake.

So, what happened? In an effort to improve our user experience, we decided to implement user behavior tracking with both first and third-party technology. Clearly, our evaluation and communication processes for rolling out a change like this were lacking and we need to improve those processes. But that’s not the main thing we did wrong.

Our main mistake was that we did not live up to our own core value of collaboration by including our users, contributors, and customers in the strategy discussion and, for that, I am truly sorry. It shouldn’t have surprised us that you have strong feelings about opt-in/opt-out decisions, first versus third-party tracking, data protection, security, deployment flexibility and many other topics, and we should have listened first.

So, where do we go from here? The first step is a retrospective that is happening on October 29 to document what went wrong. We are reaching out to customers who expressed concerns and collecting feedback from users and the wider community. We will put together a new proposal for improving the user experience and share it for feedback. We made a mistake by not collaborating, so now we will take as much time as needed to make sure we get this right. You can be part of the collaboration by posting comments in this issue: https://gitlab.us3.list-manage.com/track/click?u=195066e322642c622c0ecdde3&id=8c8ee4d0c6&e=f7a18cf5d0. If you are a customer, you may also reach out to your GitLab representative if you have additional feedback.

I am glad you hold GitLab to a higher standard. If we are going to be transparent and collaborative, we need to do it consistently and learn from our mistakes.

Sincerely, Sid Sijbrandij Co-Founder and CEO GitLab

  1.  

  2. 33

    Our main mistake was that we did not live up to our own core value of collaboration by including our users, contributors, and customers in the strategy discussion

    No, your main mistake was to decide to impose surveillance on your users, not that you forgot to ask them for permission to track them.

    I’m rather cynical about the whole thing. I think Gitlab is going to try again later, just in a more sneaky way.

    1. 2

      So if they would have asked and an overwhelming majority would have said ‘yes, please do and use the data to improve my experience’, then it would still be wrong?

      1. 11

        It would be, yes, because you can phrase the question in a way that most people will say yes while still doing the exact same thing. Manipulating people into accepting surveillance is also wrong and laws like GDPR at least try to prevent it in some way.

        1. 2

          “manufactured consent” being the literal industry term.

        2. 4

          They could collect it in a way that could only be used to improve the user experience. They might anonymize what they can, put a time limit on retention, host it on secure servers that get it through one-way link, have a NDA in place, etc. They can make it easy to disable or, even better, opt-in. There’s a lot that can be done to collect data on users while mitigating non-government risks that data brings in.

          The companies doing telemetry virtually never do anything like that, though. That means that, at best, they’re apathetic to any damage the data will cause their users (i.e. externality). At worst, they are going to or will later sell their users out to 3rd-parties that specialize in targeting them in ways they don’t want. Sometimes maliciously but mostly annoying. Any venture-backed company has financial incentive to squeeze every bit of value they can out of their users. Surveillance should always be considered evil in such scenarios given it will inevitably lead to the consequences I described.

          If they do it, they should have safeguards like I described. Heck, it would even make them look more trustworthy as a brand if users tolerated the telemetry to begin with. The situation might have gone totally the other way if Gitlab did it openly with legal and technical protections like I described. They should still make it optional for those that want zero tracking, though.

          1. 4

            The only way to safeguard user’s privacy and anonymity is to not collect the information in the first place. We have seen all sorts of databases abused, even those that people took the effort to anonymise in one way or another.

            1. 1

              I agree!

          2. 4

            Also consider the opposite scenario. What if the majority has replied “yes, that’s fine”. Would it be ok for them to impose surveillance even to the minority that doesn’t want to get tracked?

            1. 2

              Sure, yeah. Ethical behaviour and mass approval of behaviour are different things

          3. 9

            This comment stood out to me: https://gitlab.com/gitlab-com/www-gitlab-com/issues/5672#note_236161957

            The original text of the ToS e-mail, and the follow-up comments on this issue (“No current changes. We are not adding telemetry services to EE at this time.”, “we will not activate user level product usage tracking on … GitLab self-managed before we address the feedback and re-evaluate our plan”) does not engender confidence that GitLab’s corporate interests are aligned with our interest as a customer. So far, all of these comments have had a subtext of “here’s what we need to do before we go ahead and turn on telemetry anyway.” If GitLab’s stance is “we’re not going to activate tracking yet,” then my reaction is not “problem solved!,” but “I probably have a window of a few months to start doing an analysis of alternatives and plan my migration to another vendor before this issue comes up again.”

              1. 8

                I’m not sure what to make of it. On the one hand I think it’s great that GitLab chose to revert the announced changes, this means we don’t have to migrate our code on a really short notice. But on the other hand I am not sure if they can be trusted from now on. They deliberately wanted to use surveillance on their users and moved away from those so called ‘core values of their customers’. Who says they won’t try it again in the future? Or that they won’t try something more sneaky like using server log monitoring/analyses without people knowing instead of a third-party tracker.

                The worst thing I guess is that they didn’t expect such backlash (or as GitLab frames it ‘considerable feedback’), but seriously how can you not expect that? Most companies I know that use GitLab use it for the simple fact that it isn’t GitHub/Microsoft and that it always seemed to have a moral compass. It just doesn’t make sense to me…

                Migrating to another hosted git seems inevitable and I read a lot of positive things about sr.ht/sourcehut/sir hat lately here on Lobsters. Are there people here with first hand experience? Or is that considered too much offtopic?

                1. 27

                  I never saw the move from GitHub -> GitLab as anything but a temporary measure to buy time while we waited for GitLab’s leadership to crank the dial from “happy users” to “happy investors”. This problem will continue for any investor-backed company; it’s just a matter of time.

                  1. 2

                    Get a VPS and install gitea/gogs or ask people for using theirs. At least I keep an installation around.

                  2. 4

                    The thing I get the least about all this is that they had the foresight to realise they needed to prepare a bunch of material to explain this to people, and at no point did someone say “hey, is this actually worth the reputational cost?”

                    Like this transition to adding telemetry clearly became a pretty huge project, with stuff like cutting off the API access, and people thought “yeah this totally still makes sense”. They could have totally rolled this out for new users only, or they could have put a touch bit more effort to just use first-party telemetry in the first place.

                    Feels like so many unforced errors happened here beyond just the initial decision to add telemetry (which could have happened by going up a mostly non-technical org chart)

                    1. 2

                      and at no point did someone say “hey, is this actually worth the reputational cost?”

                      I don’t think we know that.

                      I know someone who works for GitLab and I’d describe her as smart, principled, and very aware of issues like this. If I had to bet - and this is purely speculation as I’ve heard nothing on the issue from her - I’d bet that there were people asking such questions, and they were overruled by more senior folk (i.e. those focused more on investor than customer requirements).

                    2. 4

                      There is one rule in building a brand, don’t betray your identity. They spent all that time building up an identity as a service that allows you to be independent. Then they decided to gather telemetry, and in a shady way no less. There will be a large group of people who will rightly never trust Gitlab again. Gathering telemetry can be a huge problem for certain business domains as well as user ideologies, and they should have known that was part of why users were picking their services over another.

                      1. 4

                        I am very concerned about Internet surveillance, and often do go to great lengths to keep my data private.

                        But this is a very strange hill to die on. I don’t get it

                        1. 3

                          I’m in the same boat. Does anyone know if there’s an article somewhere that describes why this was such a bad thing? As far as I’m aware, third party tracking is incredibly common across the web.

                          1. 3

                            I think that the problem wasn’t so much in the nature of the tracking, but in the kinds of people that GitLab is targeting - those opposed to any sort of monitoring on philosophical, instead of practical, grounds. Those people wouldn’t usually even rely on a company to do git hosting for them, and instead run a git server on a VPS. For them, GitLab’s devops tools and (apparent) commitment to privacy seemed good enough that they decided to give it a try - and when GitLab started planning to implement analytics, you heard them complain. This doesn’t happen (as much) with Google, because in addition to them just being an unapologetic nightmare for privacy, the users who would be complaining have already moved to better platforms.

                        2. 2

                          I got that email even though I deleted my GitLab account a few days ago.

                          Do they try to get people back that jumped the ship after Oct 23rd?

                          1. 4

                            Did you delete it in reaction to this or for other reasons?

                            Anyway I always assume a “delete account” button is a prayer and not a guarantee. Who knows what the fuck they do in the background…

                            1. 1

                              It was both: I didn’t really use it, and I wanted to show my disapproval of the new ToS.

                            2. 2

                              Large email “blasts” take a long time to go out. They first prep the list, and then start working through it over the course of a number of days. It’s not like they’re walking the account list and sending out an email for each one as they come across active accounts.

                            3. 2

                              I don’t think I’d be placated until they address the comment made by the CFO and why the speak of collaboration when there’s so many existing issues on their public-facing projects.