While the CE version of GitLab will remain 100% FLO, GitLab.com just changed their ToS to add their integration of Pendo (some proprietary analytics, assistance, retention, telemetry product).
This is quite unfortunate in principle and for people who care about these things. It’s a potential sign of further compromises from them as they focus on getting profit.
Maybe wherever we mention our use of GitLab.com, we should mention this concern and suggest that people consider tools that block third-party requests, in this case presuming the scripts will be served by Pendo. I suppose it’s possible that GitLab will self-host the scripts, but the connection to Pendo should still be blockable.
I don’t actually care a lot specifically about this exact issue. I only care about what it means in terms of trust, principles, future concerns… I don’t like this sort of tracking norm that this is part of.
Since I haven’t yet posted the planned blog about us moving to GitLab.com, I suppose I should mention this as well, at least in a footnote if not more prominently.
Of course, everyone should be individually seeing their announcement email. Relevant quote showing at least better-than-typical caution from them:
We will disclose all such usage in our privacy policy, as well as what we are using the data for. We will also ensure that any third-party telemetry service we use will have data protection standards at least as strong as GitLab and we will aim for SOC2 compliance. Pendo is SOC2 compliant.
That doesn’t address the distinction that they previously had 100% FLO JavaScript, and that is now ending.
Update: from their blog post at https://about.gitlab.com/blog/2019/10/10/update-free-software-and-telemetry/ they mention honoring Do Not Track (DNT) browser settings. So, I suppose we could mention that alongside the reference to blocker tools. And that does still show GitLab carefully remaining the most-FLO&privacy-respecting of compromised non-FLO projects.
Thank you for posting about this. I saw the notice and do not like it at all. This is the sort of issue I care about, especially with the use of non-FLO JS. Adding it into any future blog posts is pertinent.
Update: they are halting the telemetry plans for now at least. The blog post I linked above has an updated heading linking to an issue where they are discussing this.
They got tons of negative feedback. ToS change is rolled back. That’s all I know for now.
GitLab apology email
For reference, here’s the full apology email they sent out:
Note: my email had an obnoxious and ironic tracking link to their issue ticket. I posted a complaint about it on the ticket. After my post they replied “Thanks for that observation. We noticed that email tracking was on just after we started sending out the emails and immediately turned the email tracking off. I believe it was enabled as a standard process which our marketing team follows and in light of the subject, was unfortunately overlooked on our part.”
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=bff9966702. 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
We noticed that email tracking was on just after we started sending out the emails and immediately turned the email tracking off. I believe it was enabled as a standard process which our marketing team follows and in light of the subject, was unfortunately overlooked on our part.”