Update on free software and telemetry | Hacker News Reader

Update on free software and telemetry

about.gitlab.com

256 pointssm4rk0260 comments

We have launched important updates to our Terms of Service surrounding our use of telemetry services. Starting with GitLab 12.4, existing customers who use our proprietary products (that is, GitLab.com and the Enterprise Edition of our self-managed offerings) may notice additional Javascript snippets that will interact with GitLab and/or third-party SaaS telemetry service (such as Pendo).

For GitLab.com users: as we roll out this update you will be prompted to accept our new Terms of Service. Until the new Terms are accepted access to the web interface and API will be blocked. So, for users who have integrations with our API this will cause a brief pause in service via our API until the terms have been accepted by signing in to the web interface.

For Self-managed users: GitLab Core will continue to be free software with no changes. If you want to install your own instance of GitLab without the proprietary software being introduced as a result of this change, GitLab Community Edition (CE) remains a great option. It is licensed under the MIT license (https://en.wikipedia.org/wiki/MIT_License) and will contain no proprietary software. Many open source software projects use GitLab CE for their SCM and CI needs. Again, there will be no changes to GitLab CE.

Key Updates:

- GitLab.com (GitLab’s SaaS offering)and GitLab's proprietary Self-Managed packages (Starter, Premium, and Ultimate) will now include additional Javascript snippets (both open source and proprietary) that will interact with both GitLab and possibly third-party SaaS telemetry services (we will be using Pendo(https://www.pendo.io)).

- 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.

If you have any questions please contact us at support@gitlab.com

Open articleView on HN

Don't go down this road.

The moment you place corporate needs ahead of user needs is the moment you start losing user advocates (UAs). New features are shiny objects that may attract interest, but UAs are your long-term lifeblood. They don't just use your product, they recommend it to friends, teams, bosses, and organizations.

I'm not going to be as pessimistic as others in this thread bc I know you guys have what it takes to do the right thing. But know that a tide change has occurred when it comes to privacy and data, and technical folks are keenly aware of the importance of protecting both.

This.

When your enterprise and open source offering start to diverge, there's no way back. Also your free and open core starts to feel like a freemium product.

I run 3 GitLab instances in various places for different people and organizations. If GitLab starts to go that way, I'll not install any new instances, won't recommend them and migrate my instances as soon as I can.

I agree that user advocates are our lifeblood and we're risking alienating them. 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 https://gitlab.com/gitlab-com/www-gitlab-com/issues/5672

> There were many more concerns than we expected.

I really don't understand how this can be true. Just reading it briefly I knew there were going to be a ton of concerns.

Honestly, it's shocking that this came as a surprise. It's like they don't know why they made Gitlab self-hostable.

> We will not activate product usage tracking on GitLab.com or GitLab self-managed before we address the feedback and re-evaluate our plan.

I would like to see a harder commitment: to simply not do this. Gitlab does not have any credible reasons to add product usage tracking that does not have substantial downsides, better to steer clear of this completely.

Judging from the discussion in [1], the "going down this road" already started to happen about half a year ago. Please notice how everyone in conversation seems to implicitly understand that their customers won't like the new forced telemetry, but still pushing on this, "for customers' own good" (with the only possible exception being made for public sector customers).

1. https://gitlab.com/gitlab-org/telemetry/issues/34

This is beyond stupid for GitLab.

The _PAID_ self-hosted instances will have non-optional telemetry that loads remote javascript inside an enterprise? Any enterprise that seriously wants to self-host will look at this statement and flip a table.

No, they won't flip a table. They'll talk to the sales guy, tell him "nope", and will receive instructions how to turn it off.

That is if anyone on the business end wants Gitlab, but that is almost never the case.

The business has to be sold on Gitlab by the developers.

Hello! GitLab employee, I understand the frustration however self-hosted customers on EE will not be affected. We opened an issue here to help clarify: https://gitlab.com/gitlab-org/growth/product/issues/164

Wow the blog host reads poorly then, when I read “self-managed” I assumed managed by the customer, not Hosted Gitlab. You might want to clarify that in the post..

We're testing this out on .com to see what value it really gives us and how it works, and depending on that then we might roll this out to EE. HOWEVER any move to do so will be properly communicated, and we're not going to implement it without carefully considering an appropriate opt-out strategy.

Yeesh. You guys just went from restoring my faith a bit a few months ago to this possibility? I’m sorry, but please get a grip here, it’s tiring being on this rollercoaster.

as long as it is out-out, instead of opt-in, it probably won't fly with any corporation.

edit: was trying to make a joke, it was a bad joke

What..?

I'm so sorry I was trying to make a joke, it's been a long day as the messenger trying to relay everyone's concerns about this back to our team.

I said "What..?" not because I didn't recognize the joke, but because nowhere did I bring up "security/privacy." My initial comment was stating that the blog post should clarify that these changes were not coming to EE immediately, because I (along with many others here) seem to have read it in such a way that it sounded like it was.

I hope I covered that in my other comment

As a disclaimer, I do not believe I've ever seen a captcha when logging in to GitLab. But according to https://docs.gitlab.com/ee/integration/recaptcha.html, you use reCAPTCHA?

Are you aware of the privacy concerns surrounding reCAPTCHA? https://en.wikipedia.org/wiki/ReCAPTCHA#Criticism

I was just trying to make a joke I'm so sorry. As for recaptcha we have an issue here with a ton of discussion around it that links quite a few more if you're interested: https://gitlab.com/gitlab-org/gitlab-foss/issues/46548

Quite a bit of discussion on a year old issue but.. its still not resolved? That doesn't instill confidence.

To clarify your clarification, a quote from that issue:

> We are not adding Pendo or Snowplow JS snippets to self-hosted versions at this time. We are carefully considering the appropriate opt-out functionality for telemetry that will work best for our customers, and we will clearly communicate to those customers when any change is made.

In other words, it's not that self-hosted will not be affected, it's that self-hosted will not be affected yet. That's an important distinction.

Also, why is it opt-out and not opt-in?

That's a trend going for years.

A lot of services, newsletters, promo, telemetry, are by default opt-out. When you install some chat app, it also syncs some data (e.g. contacts maybe?) and then you can go in the settings and opt-out for that sync..

because with opt-out they can first gather the data and keep it before you can opt-out.

I'm guessing because opt in doesn't generate enough useful results while opt out does.

Let's be real here, the difference between opt out and in is probably several orders of magnitude worth of data. It's like, would you rather have a Megabyte of telemetry to analyze or a Gigabyte?

Except it does, if you have a sufficiently convincing reason for people to opt-in.

Since a few weeks, our hackerspace - which used to publish all door unlocks on IRC with the nickname of the person unlocking it, by default - requires opt-in for nicknames to be published.

People recognize that this is an important social function of the space, because it ties together the IRC channel and the physical space, and thus the vast majority(!) of members have explicitly opted in.

This whole narrative that "if you make it opt-in, not enough people would ever do it" always conveniently leaves out that that's only true for things where people don't want to opt in, ie. usually things that benefit the service but not the users.

Right, which is why GitLab in this case wants opt out since their reason for collecting telemetry isn't particularly compelling

Never trust private companies to not screw you out.

Small companies are generally more trustworthy, until they come to a position of dominance, where they are just there to squeeze.

That clarification should explicitly address the original email that contradicted it (eg self managed EE would be getting telemetry).

Opt-out (ideally opt-in) is very important for enterprise customers, especially self-hosted.

Our enterprise security people would complain about data exfiltration risk. GitLab would only survive if the security people approve it & that is a LOT of extra work for the internal team that keeps GitLab sold within the company.

That does not mention anything about if I still have to agree to the new terms and conditions or not. Contrary to what you seem to think "at this time" is not very reassuring for me as a paying user.

I'm confused. Are you a Gitlab employee or are you addressing a Gitlab employee? Edit: From the parent commenters profile, it appears they are a Gitlab employee. The comment itself was confusing due to the comma after the Gitlab Employee

> We are carefully considering the appropriate opt-out functionality for telemetry

There's your problem. This should be entirely opt-in.

Will the opt-out be easily disabled during setup or will it be hidden in options?

We made this blog post before implementing the changes so we could gather feedback. The feedback is very negative. And some of the things we thought would help (respecting DNT) don't seems to matter much. We'll have a look at all the feedback and see what we can learn and adjust.

> We made this blog post before implementing the changes so we could gather feedback

Blog post isn’t the best way to collect feedback. Just ask your customers directly.

10 bad title on internet is enough to screw your reputation on 10m developers that probably don’t even follow up the story or even don’t bother to read anything beyond Reddit titles and comments. But then you have 10m developers telling their managers “Oh Gitlab isn’t good”.

Totally. I got a link to this post sent to me today by a co-worker, and already in my mind I've blacklisted using Gitlab in an enterprise environment. It's only now that I found this thread on HN that I learned this isn't set in stone yet. But most people don't read HN.

I agree that the tone of the blog post was more like an announcement than a proposal.

Please do revert, Sytse. Look at how governments are fighting Microsoft's urge to track users [0] [1]

We're in the process of taking a 50user Premium (aka self-hosted) GitLab subscription, don't make us reconsider and search alternative means.

[0] https://edps.europa.eu/press-publications/press-news/press-r...

[1] https://tweakers.net/nieuws/158892/

We're updating the blog post with https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/...

as long as the ToS doesn't reflect a change of heart, this does nothing. In enterprise environments, we can't base anything on blog posts, it's the ToS that matters.

ps: SOC2 does not inspire confidence as the whole of EAA needs to follow GDPR.

Thanks, we're pumping the breaks on this change completely, see https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/...

> GitLab's proprietary Self-Managed packages (Starter, Premium, and Ultimate) are unchanged for now. We do plan to enable product usage tracking for those packages, but will absolutely allow administrators of self-hosted instances to have easy control over whether tracking is enabled. We will communicate clearly in advance of any planned changes, and will clearly document how to control tracking in each customer environment.

This doesn't seem like you're pumping the breaks "completely".

It's baffling to me that you would try to run telemetry on self-hosted PAYING customers. Seems totally backwards.

A while later, they did pump the breaks completely by reversing the ToS changes.

This means they would have to change the ToS before trying to implement it again, which means the current result isn't moving the goalposts at all and is not a step forwards to the original solution.

See: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/... and https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/...

>The feedback is very negative.

I don't know what did you expect?

Why should I believe you care? I notice that you and your employees are here acting superficially nice to do damage control, but that's about it.

Of course the feedback is negative. You obviously knew it would be because you made that blog post in the first place. Three months from now you'll have made some cosmetic changes while still collecting basically all the data you wanted. Eventually you'll be ramping up to roll this into your enterprise offering. I'll do another round of source control tool research and hopefully be able to move gitlab to the NRND list in internal documentation.

That's how it will go, because that's how these things always play out. The world will keep spinning.

Too late to edit my post, but gitlab is planning to go public next year and had I know I wouldn't have posted the slight prodding I did. If this how they're gearing up we can calibrate our expectations of that company's future accordingly.

You serious? Telemetry for Gitlab?

I see only one option: remove all telemetry and make a blogpost about why that idea was bad that you will not implement it. And even doing so harm is already done. Now you can minimize harm by making such post as fast as possible.

The ONLY reason I started using Gitlab is to get away from shit like this, because Gitlab always advertised itself as a more consumer friendly option, both self hosted and hosted by you. Guess I was wrong to trust you and now I have to migrate away. Hassle I really didn't need.

Enterprise Win 10 user here... uh, I am the bringer of bad news...

Nevertheless I do think this is different since management defers decisions about software versioning and life-cycle management in general to developers. I do think this will cost them some hard earned customers.

Certainly a bad move and I doubt it will amortize.

I'm not sure how many people we employ. (more than 15k) and we're all using windows 10 without telemetry enabled.

However, I'm relatively sure that this is due to the efforts of our very talented Windows Systems Administrators. Nonetheless, it's possible.

Wow! That’s some change to just drop on us. Guess that settles the issue of whether or not we’re ever going to be able to use this in the enterprise with a big fat no.

I’m not really sure why they’re thinking this is a good idea.

If I tell the legal team that our source control software is sending off data to the vendor and some random (unspecified?) third parties, they’ll have a fit.

Hello, GitLabber here! We’re currently writing an issue explaining the situation, once it’s public I will link it here.

I think we as developers understand the rationale behind it. The outrage you may see is that in self hosted instances, the companies and people that pick that as their option do so because they want an isolated/independent system. Telemetry from a self hosted system is atypical, especially compared to SaaS that's hosted by you. It's more normal in apps people download that already use the internet, but you already have that option in what you host.

Frankly, I used to work at a DoD contractor and we ran GitHub Enterprise and GitLab behind secured networks. That kind of expectation -- that the software will never phone home -- was what let us run and justify them in the first place.

Edit: Looks like the comment I replied to has been changed, and essentially removed. I'm sorry if this is now out of context.

"Until the new Terms are accepted access to the web interface and API will be blocked. So, for users who have integrations with our API this will cause a brief pause..."

It's not even take it or leave it, one has to agree first in order to leave.

It seems whoever approved this, forgot why people arrived to GitLab from GitHub.

It's not that we do not understand that, we do, it's that we don't agree with such stupid and aggressive move considering enterprise setups (I certainly will not use this version if I can avoid it). Shame, this is exactly the opposite of why I migrated to Gitlab.

This is the issue they were talking about, I hope it clarifies some things! https://gitlab.com/gitlab-org/growth/product/issues/164

Not really, as you will see from the first user comment.

yeah, it's interesting: i figured that Lab always targeted/understood "enterprise" more than Hub, what with Hub's focus on more social type stuff (activity feeds etc.) and Lab always having a nice matrix of tiers that, while expensive, weren't prohibitive for enterprise users + foot in the door with self hosted

i wonder if their projections for enterprise aren't adding up, or Hub has started to eat their lunch enterprise wise with new features that Lab hasn't copied yet, or API integrations, or something else

Hello! GitLab employee, I understand the frustration however from what I can tell from your usecase you will not be affected. We opened an issue here to help clarify: https://gitlab.com/gitlab-org/growth/product/issues/164

I would prefer not to see GitLab employees all over this thread on every comment like those PR folks on Twitter.

Let people speak, and listen.

Trust me I understand, I was a developer prior to this job, but I do think this is necessary information to clarify what the blog post itself said. As the person who relays everyone's feedback to the rest of the company, I am listening, which is why this new issue was created in the first place. Thank you to everyone who provided feedback, I am doing my best to advocate for you.

I don’t understand why an ‘issue’ was created for this. It means absolutely nothing to me that there is an issue when the original blog post still blatantly announces that the next version of Gitlab Enterprise is going to exfiltrate our company data.

While I’m here. You also keep talking about opt-out functionality, but the only way this is going to go over reasonably well is if the whole thing is opt-in.

Except... A lot of enterprises use github enterprise, which I would imagine has similar telemetry? I don't actually know so perhaps I'm wrong...

I mean, you're not wrong necessarily, but some people specifically chose gitlab because it was _not_ being hosted elsewhere or harvesting data.

Choice is good, more things like this mean that there's less of a differentiating factor between hub and lab.

From the article "... To make GitLab better faster, we need more data on how users are using GitLab. SaaS telemetry products, which provide analytics on user behavior inside web-based applications, have come a long way in the past few years. They are an important tool for rapidly improving user experiences because you can understand what users are doing (or not doing) in the app. GitLab has a lot of features, and a lot of users, and it is time that we use telemetry to get the data we need for our product managers to improve the experience."

This doesn't seem like a sufficiently good justification add telemetry features which some users may find objectionable.

Perhaps those resources would be better spent on a feature that let the user who is annoyed by a slow operation to:

- Begin recording user interaction telemetry locally - Perform the slow or buggy operation - Stop recording, generating a data bundle file. - Allow the user to review the data bundle in human-readable format - Optionally take the data bundle to a less secured system as needed - Submit the data bundle to GitLab engineering as a well-filed issue

Done that way, I think most users would welcome the interaction with Gitlab. For telemetry, not so much.

That sounds like recipe for near-zero participation. I think both the intent and execution are spot-on here for GitLab. They are offering a very straightforward option for using GitLab, telemetry-free.

I'm not arguing for or against tracking, but I disagree with some of these assumptions:

1) 99% of users who have a bad experience are not going to be bothered to figure out how to record, review, and submit their session for the benefit of the service provider. If a page has issues loading, they're just going to give up and move on to the next thing.

2) User tracking isn't really related to performance in the first place. If some server side operation is failing or taking a long time to load, engineers will find out (and probably get paged) with user-agnostic internal performance metrics.

3) User tracking isn't just about finding out what's broken with the site, its about understanding how the site is being used in general so that you can validate your assumptions and make product decisions backed by data.

> If a page has issues loading, they're just going to give up and move on to the next thing.

It means that they are fine with these issues and don't need to have them fixed.

Or it means they're just going to switch to $competitor's product that doesn't have this issue.

You don't need telemetry or telepathy to hear the chorus of users screaming at the top of their lungs where to shove your telemetry feature.

Hello! Thanks for the feedback, we opened an issue here that might help clear some of this up: https://gitlab.com/gitlab-org/growth/product/issues/164

Telemetry is a lazy, paternalistic way of improving user experience. It's a method that lets you ignore the actual feedback you're getting from your users, because that involves dealing with actual human beings - who don't always write politely or coherently. Telemetry lets you avoid collecting feedback in a way that respects the user - through in-house studies, by contracting with outside users to perform on-site studies, and just by asking people and reading what they say (and treating it seriously).

GitLab, you're not a cut-throat company run by the Ferengi, desperate to eke out a tiny bit of extra profit by whatever means necessary. You have what it takes to do it right and set an example for others.

That is simply not true. Both matter, but telemetry is something you can trust far more than user feedback. Want to know how much a functionality is used, or how long a user spends doing a particular action - telemetry is the answer.

Compared to direct user feedback where a user might use some functionality twice a year, but rank it high as something that needs to be improved because it's sort of backwards. Instead of improving the performance and flow of the functionality they use hundreds of times daily, because they're reasonably happy with how it works. It's not that you don't want to fix the former, but it's obviously not business critical to perform often, and it's not considered high priority yet.

> Both matter, but telemetry is something you can trust far more than user feedback.

Disagree. User feedback, however biased or incoherent, is a direct representation of real people with real issues. Telemetry is a stream of context-free data from which you need to infer the hidden user feedback. Telemetry data seems to me to be much more prone to finding in it whatever it is that you want to find, or all the other failure modes that happen when people who analyze it have more skills in statistical tools than in doing science.

> Compared to direct user feedback where a user might use some functionality twice a year, but rank it high as something that needs to be improved because it's sort of backwards. Instead of improving the performance and flow of the functionality they use hundreds of times daily, because they're reasonably happy with how it works.

And all I want, all my life when using software, is for companies to fucking listen to that. If I say I'm reasonably happy with things I spend 95% of my time, then I am reasonably happy. I want you to fix the 5%-time case.

There's no direct relationship between how often you use a feature and how critical it is. To give a simplified example, when I'm using 3D Studio Max, 99% of my time is spent modelling, and only 1% (or less) is spent on saving the file. And yet, without that feature, I wouldn't even buy the program. This is of course a silly example, but most software has plenty of very important features executed very rarely (and some that are executed rarely because the experience sucks). Relying only on naive telemetry analysis is going to lead you to misprioritizing work on improving the product.

> And all I want, all my life when using software, is for companies to fucking listen to that. If I say I'm reasonably happy with things I spend 95% of my time, then I am reasonably happy. I want you to fix the 5%-time case.

soo much this!

Though you have to be careful not to fall into the https://xkcd.com/1172/ trap.

Sometimes a user might think they need feature A to make task B easier when in reality instead of doing B they actually want to do C but they never thought of it that way.

If you implement A, you take on maintanance burden when C would be way easier to implement and potentially much more useful for the majority of your users.

The way to tell whether the user needs feature A or C is by talking with them, and watching them use your product in context of their overall work. Telemetry does neither, and will not reveal to you that the user needs C instead of A. On the contrary, it's likely to make you double down on A, because that's what shows up in the data.

> Relying only on naive telemetry analysis is going to lead you to misprioritizing work on improving the product.

Which is exactly why I said both matters.

>If I say I'm reasonably happy with things I spend 95% of my time, then I am reasonably happy.

Isn't there a decent amount of psychology research showing this isn't the case. Not with happiness with a service in particular, but that we poorly report on our internal state and often are biased by factors that impact our self reporting but not our choices. What people say and what people do do not always align and thus it is possible for there to be a gap between what people want and what people say they want. If you try to meet the latter you can end up losing out to someone who tries to meet the former.

Now, that is research on average people (and particularly average college students), so when dealing with software developers talking about software issues it may not apply.

This seems a very appropriate observations, but the way it applies here is that it implies that feedback needs to be significantly contextualized with how users use your product. A criticism of telemetry would be that there is no reason to believe that you will know more about the meaning of the numbers you are collecting than about the user experience through feedback.

A typical story relevant here is that of a news site boasting about a rise in daily reads, where they define a read with being on a page for 3 seconds... that is clearly a meaningless number that maybe just means users are skimming through all your articles in hope that not all you have is terrible (could happen if you had some good content or a loyal audience)

There is. But one has to remember Egan's law[0] - it all has to add up to normality. Yes, there's an error term - frequently self-reported motivations and reality don't align. Reasons include people not understanding their motivations well, not being clear about weights of different motivations in them, or refusing to reveal either to researcher[1][2]. But it has to add up to normality. If I say I like your app, then you either you believe me, or assume that I'm wrong - which is not just disrespectful and patronizing in this context, but also either implies that either I in particular am crazy, or it invalidates the very idea of human emotions communicating anything.

And most importantly, even if my self-reporting isn't accurate, you don't know better, and telemetry won't tell you. If I say that I didn't press this button because it was red, you can doubt the accuracy of my report, but you don't get to conclude that my real reason was that the button was square and not round, or that it was on the left and not on the right. Or that the button is useless. Telemetry will only tell you I don't press it. Or perhaps you can run an A/B test to learn that I press the button when it's blue and round and on the right side (but you may miss the fact that I pressed it out of confusion, and reverted its effects three screens down the line).

Software developers are no different than real people, except that they have much more experience with computers - which means both familiarity with the UI and the ability to instinctively form a mental model of what's happening underneath, which sometimes leads us to intuitively avoid doing things that would break the application :).

[0] - https://wiki.lesswrong.com/wiki/Egan%27s_law

[1] - Plenty of motivations could be embarrassing, or weird. E.g. for a long time, I avoided using GNOME desktop and related software, simply because I had a visceral revulsion towards their logo, which featured a footprint. It's a kind of motivation that did affect me, but I wouldn't be too willing to reveal unless asked directly.

[2] - Also people sometimes report on motivations behind what they want to do, but not on the incentive conflict they're facing, and they then proceed to do something you wouldn't expect. This leads to silly arguments like "something is good because of revealed preferences", which latch on the difference between expressed preferences and observed behavior, completely ignornig the fact that observed behavior is heavily incentivized, essentially making people go against their preferences.

> Relying only on naive telemetry analysis is going to lead you to misprioritizing work on improving the product.

yes, but it does let you know where to place the ads and “special offers”

Which matters primarily if you're a Ferengi.

> Telemetry is a lazy, paternalistic way of improving user experience

> That is simply not true... but telemetry is something you can trust far more than user feedback

nutin said

You've just stated exactly why you shouldn't trust telemetry. You improve the parts that are good enough already and not the parts that are so bad users avoid them.

I didn't want to write an essay, so let me give you an example instead.

We've had a customers insisting that a particular feature was very important for them, however telemetry showed that they used that particular feature last time more than 26 months ago, and they discarded the resulting document anyway. Drilling down revealed that everyone thought that everybody else was using it sometimes, while the one user that had a need for it actually had a different and far more efficient workflow.

My point is that my department have telemetry, the support team and PO have user feedback. If those two versions of the truth does not match up, we discuss it, often involving some users. Neither is perfect, and if you have to choose, obviously listening to the users seems preferable. Just remember that if Henry Ford build what people asked for, he would have made faster horses (quote is probably not even from him, but it gets the point across).

To improve and make innovation you need many things, but especially empirical (telemetry), observational (watch the users), and anecdotal (listen to the users) evidence. Only with that you can make an informed decision.

Frequency of usage and importance may not necessarily correlate.

You can drive far by only using gas pedal and take the foot off it to decelerate. Does it mean that brake pedal is not important, because usage telemetry lists it as "rarely used, user does not know what he wants" ?

I work at GitLab. Support Engineering Managers were briefed about this a few days ago.

From inside GitLab Slack:

5d Scott Williamson We are not adding Pendo or Snowplow JS snippets to self hosted versions yet. That will likely come in a second phase of the project, and we will figure out opt in/opt out for those scenarios before launching. The reason we are communicating to those customers about it now is so we don't have to do the privacy policy change twice. So for now it's just .com customers. I will let @Tim Hey respond on where he would like discussion on this to go.

5d Support Engineer Thank you @Scott Williamson, I was hesitant to ping you as I know your time is valuable, but I'm glad that I did. :thank_you::thx::thankyou:

5d Tim Hey Hi @Support Engineer Looks like @Scott Williamson just beat me to the it. :sweat_smile:

5d Support Engineer You both are amazing and I can't thank you enough.

5d Tim Hey Also if you are interested in the being part of the discussion when we build out the opt in for scenarios like this I'd love to include you. I believe Lee was interested.

5d Support Engineer I'd love to be involved! If there's an opt-in or opt-out, it invalidates all the concerns I voiced here. Knowing this, I fully support the decision to add telemetry to self-managed and understand that it would be incredibly valuable for growth.

41m Support Engineer @Scott Williamson @Tim Hey @supportmanagers We have a lot of upset customers thinking that GitLab self-managed telemetry will be mandatory for Self-Managed GitLab moving forward (no opt-out/opt-in) . We need an official response and Zendesk template to help manage the influx

I am not sure it is a good idea to post internal slack conversations to a thread like this on HN.

I asked Scott, VP of Product, if he was okay with it. He was. In earnest, it should have been on an issue, so I could have linked to it directly.

The fact that Gitlab didn't include information about enterprise having opt-out ASAP shows how out of touch Gitlab is with (or how little they care about) enterprise customers. Or does Gitlab just not have enough Enterprise customers to care about?

> We have a lot of upset customers thinking that GitLab self-managed telemetry will be mandatory for Self-Managed GitLab moving forward

It may not be mandatory now but, by agreeing to the new Terms of Service, it can be mandatory at any time in the future without being notified/needing to agree to the change (since it's already in the ToS). This Slack conversation is just as short-sighted as the blog post.

I'm surprised the proposal to allow third-party scripts (something GitLab doesn't control!) to run on customer's closed environments made it out of a 30-minute meeting.

> I'm surprised the proposal to allow third-party scripts (something GitLab doesn't control!) to run on customer's closed environments made it out of a 30-minute meeting.

I've always been curious how this happens. How can a group of people who should know better just ignore or not realize the backlash that will come. There was not a single person who raised a red flag?

> That will likely come in a second phase of the project, and we will figure out opt in/opt out for those scenarios before launching.

You might want to pass on that the current opt in/out scenario won't work everywhere either.

Safari 12.1 removed the DNT header[0] because it was only being used for fingerprinting.

https://developer.apple.com/documentation/safari_release_not...

>Safari 12.1 removed the DNT header[0] because it was only being used for fingerprinting.

In retrospect, it's hard to imagine this working out any other way.

> 5d Scott Williamson We are not adding Pendo or Snowplow JS snippets to self hosted versions yet. That will likely come in a second phase of the project

Can it come in an ∞th phase instead?

> I work at GitLab.

HN is a good opportunity to reach out, so I will use it: there's some kind of dark pattern employed during this Terms-Of-Service switch.

GitLab does not allow to login without accepting the new TOS, which means that I cannot remove my account without accepting the new TOS.

I didn't use gitlab that much anyway, but the TOS change just reminded me about the need to close the account... yet "you must accept the TOS to login" does not allow to remove the account. So, accepting the new TOS is kind of forced upon if you want to find your way out (in other words, it's made inconvenient and we-will-drag-our-feet otherwise).

Can someone take a look into it? I received two template-responses from email support, but no action.

My support request is 136340.

Just send a GDPR data delete request. Let the lawyers deal with it.

Since GDPR topic was brought up, let me give some more details; GitLab seem to be well aware of GDPR.

This was initial response from GitLab to my request (let's call it Template1):

> We understand that you want to completely remove your GitLab.com account.

> Due to the complexity of servicing these requests, we're asking our users to

> please email gdpr-request at gitlab.com.

> Please ensure that you:

> - send the email from the address associated with your GitLab.com account

> - include the GitLab username you'd like removed

I did send an email to that address repeating my request, but shortly after I received this response (let's call it Template2):

> We have additional updates with regards to our TOS and Telemetry services

> below:

> We understand that the recent announcement regarding the update to our Terms of

> Service, specifically in regards to Telemetry, can lead to questions you have

> about how it impacts your usage of GitLab.

> To answer those questions and gather feedback on this recent update, we have

> created this Issue with additional clarification. As we firmly believe that

> everyone can contribute, we want to assure you all feedback you provide via the

> Issue is both welcome and appreciated.

> Kindly advise if you would still want us to proceed with this request.

I repeated my request, reaffirming that I want to remove and erase my account. In response, they sent "Template1" email again.

Edit:

to be fair, it's been less than 24 hours since the request, and the repeated template-response from GitLab may have been a hiccup on the support side.

But the whole new TOS switch could be handled much better and without dark patterns, i.e. during login, two buttons:

[Accept new TOS] [Decline and erase account]

However, right now there's simply no option to handle account removal conveniently when I want to decline the new TOS.

> [Accept new TOS] [Decline and erase account]*

Actually, that's still a GDPR violation. A user cannot sign away their rights in the ToS. From https://gdpr-info.eu/art-7-gdpr/ "Conditions for consent":

If the data subject’s consent is given in the context of a written declaration which also concerns other matters, the request for consent shall be presented in a manner which is clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language. Any part of such a declaration which constitutes an infringement of this Regulation shall not be binding. [..] When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract.

In other words, if Gitlab ties the consent for telemetry together with access to the service itself, the consent is considered not freely given and therefore not legally binding at all.

> In response, they sent "Template1" email again.

At this point I would simply wait the 30 days or whatever they have to respond and if they don't, complain to your data protection commissioner. They could get hit with a big fat fine for it, so its in their interest to make sure they respond correctly and don't send you around in circles.

That only applies to EU residents.

That only applies to Personal Data. It doesn't close your account or delete your source code. etc.

Yeah, cannot they just do a soft delete or change a bool like disableAccount from false to true, for example? :D

I believe this is what Discord does. If you delete your account, or if you request it to be deleted, it does not delete your comments, your name changes, your profile photo gets removed, but the comments are still there. Are they not considered personal data? Call me paranoid, but I do not believe that your comments actually get deleted even when you delete them either, I would say they just get hidden.

My email is in my profile. I can't find your ticket for some reason. I think the problem that you were experiencing was a bug, but we've rolled back the TOS Change so it might now become a non-issue.

Regardless, happy to clarify whatever I can.

A few hours after posting this I received another email, saying that per my request the account is being removed. I can see it removed now; I guess that's the reason the ticket is no longer there. Happy to see it resolved.

Curious to know what planet you guys live on that you think you could put non-opt-in 3rd party telemetry on enterprise-level software and not get this kind of feedback.

https://gitlab.com/gitlab-org/gitlab/commit/bd6e6180e61916ed...

I am (was?) a big supporter of GitLab and am having trouble believing what I’m reading. GitLab.com having analytics, whatever. But Gitlab EE having mandatory analytics? This just seems downright out of touch.

Hello! We're sorry for the confusion however EE is unaffected by this. We wrote an issue here to clarify: https://gitlab.com/gitlab-org/growth/product/issues/164

s/unaffected/unaffected yet/

EE being unaffected (for now) is not the point, the problem is the way this was announced, especially opt-out by default. I can't ever recommend GitLab in companies I work for now, because my trust in GitLab has been shaken.

> Enterprise Edition (EE) > > No current changes. We are not adding telemetry services to EE at this time.

Do I have to agree to the TOS at this time?

> In order to service the needs of GitLab.com and GitLab Self-Managed users who do not want to be tracked, both GitLab.com and GitLab Self-Managed will honor the Do Not Track (DNT) mechanism in web browsers. This means that, if you turn on Do Not Track in your browser, GitLab will not load the JavaScript snippet.

Ok so GitLab dotcom promises to honor DNT, which is good.

> GitLab Community Edition will continue to be free software with no changes.

So GitLab CE is not "affected" at all, which is better.

I've never used the Enterprise Editions, but what's to stop enterprise ops/sysadmins from just blocking the third-party requests at the DNS level (regardless of the DNT promise)? Another HNer mentioned this re: air-gapped deployments.

So in a purely practical sense, is the only noteworthy takeaway simply an extra production config step involving DNS?

> For GitLab.com users: as we roll out this update you will be prompted to accept our new Terms of Service. Until the new Terms are accepted access to the web interface and API will be blocked.

Blocking service until the user consents is illegal under GDPR, especially when the consent is requested for data collection that is not essential for providing the service, such as telemetry and analytics.

https://gdpr.eu/gdpr-consent-requirements/

> “Freely given” consent essentially means you have not cornered the data subject into agreeing to you using their data. For one thing, that means you cannot require consent to data processing as a condition of using the service. They need to be able to say no. According to Recital 42, “Consent should not be regarded as freely given if the data subject has no genuine or free choice or is unable to refuse or withdraw consent without detriment.”

Is this personal data?

Unless they anonymize absolutely everything, including our IP addresses, then yes, it is personal data.

https://about.gitlab.com/privacy/

> Third party tracking services gather certain simple, non-personally identifying information over time, such as your IP address, browser type, internet service provider, referring and exit pages, timestamp, and similar data about your use of the Website. We do not link this information to any of your personal information such as your user name.

They don't have to link your IP address to your name, because the IP address itself is already an identifier and so considered personal data.

Even then it just takes a very small amount of effort to argue that the anonymized data is still personal and can be linked back to individuals with a bit of statistical analysis.

In addition to dessant's links, the European Commission has a good page which lists out examples (including IP address) of what is considered personal data[1].

[1] https://ec.europa.eu/info/law/law-topic/data-protection/refo...

Anything that can be used to identify the user is considered personal data. Even something innocent enough like screen resolution can be personal data if you’ve got someone with a unique browser window size (let’s say they have a custom window manager that makes the window slightly smaller than the common screen resolution, and it never changes because it’s a filing window manager and they always keep the browser in the same place).

Despite using gitlab i'll probably report them to my country's organization that handles GDPR violations.

If I get locked out for not agreeing to their ToS before I'm finished migrating away, I'll be reporting them too. Then, when I'm done migrating, I will be doing a GDPR request for my data and another right of erasure request.

... I felt quite confirmed while reading this. After months of thoughts and plans, I finally invested some hours to install Gitea on my Synology NAS and migrating all GitLab projects there. Combined with Synology Drive + Wireguard running on an EdgeRouter by Ubiquiti, this feels somehow good. Of course, just for my personal files that don't require collaboration with others ...

They've gotta support the $2.74B valuation somehow. This is the ultimate fate of all VC-driven end-user businesses, the incentive model puts users well after investors. This problem is why I bootstrapped my business. https://sourcehut.org/blog/2019-10-23-srht-puts-users-first/

Very apropos comment and thanks for your service alternative!

And yet, you're already taking Sourcehut's money and using it to pay a developer that you've said won't be doing any direct work for Sourcehut [1].

How in the world can you possibly call it "putting users first" to take users' money and use it to pay someone to do things that don't benefit those users? Seems a lot more like you're using the company money to pay for things you want someone to work on, not your users. How can that be the company's top priority and the first hire?

(throwaway account because Drew holds grudges for years when people question him)

[1]: https://sourcehut.org/blog/2019-10-15-whats-cooking-october-...

Seems this has been vouched out of its shadowban, so I can reply now.

I'm extremely proud to be sponsoring Simon's open source work, and I'm looking forward to sponsoring others. I don't intend to turn SourceHut into an Uber-esque business where a veritable army of developers is sitting around and doing nothing. Most SourceHut users who have been keeping abreast of my plans have known that I wanted to re-invest the profits in open source, and this is how I've chosen to do it. This does benefit SourceHut users, by enriching the open source community in a way no other company is doing.

>(throwaway account because Drew holds grudges for years when people question him)

I don't know where this came from, but it's not really appropriate. It seems more likely that you have a grude with me.

>>(throwaway account because Drew holds grudges for years when people question him)

>I don't know where this came from, but it's not really appropriate. It seems more likely that you have a grude with me.

Reality: you've treated many people harshly over the years for disagreements, questioning, or what have you. There's a reason a few people come out of the nooks with anon accounts to speak up about this.

If you have a grudge then we should really just address it properly rather than bring it up in passive agressive comments in unrelated threads. You can email me at sir@cmpwn.com to discuss it in private or ~sircmpwn/public-inbox@lists.sr.ht if you want to discuss it in public.

[warning: biased, cynical and opinionated content ahead]

To me this whole debacle feels like a forced error. Gitlab needs to find a way to profitability - fine, I am very much in favour.

But I can't shake the feeling that somewhere, someone, has made the mental association that "more user tracking == more money". It's worked for Google and Facebook, and it looks to be working for -vomit- modern infosec industry, where ever more aggressive end-user surveillance seems to be the easiest way to get two or even three bites of the apple.

And that is why this whole thing feels like a re-enactment of a South Park episode:

  1. Get more user data
  2. ???
  3. Profit!

Because from what I have read so far in this thread and the early linked issue, it does feel like shoehorning invasive user tracking has been a foregone conclusion and figuring out a justification has come second.

Looks like it was forced on the devs by the CFO https://gitlab.com/gitlab-org/gitlab/merge_requests/14182#no...

> Gitlab needs to find a way to profitability

It's so much more than that. They need a way to justify their $2.75B valuation, and to keep going up. Profitability is a walk in the park in comparison.

It's quite absurd to refer to VC-driven enterprises like that considering the resource it's written on.

Do you mean to imply that VC-driven enterprises cannot be criticised on Hacker News because it's a YCombinator-operated forum? That's ridiculous, the mods go to great lengths to keep their bias away from their work here. That you can criticise Venture Capitalism on Hacker News is part of why I come here in the first place.

I do agree with you completely and HN is an awesome platform which I solely use as my main portal to the Internet even to not tech related things (to search for a training routine as an example).

It's hard to trust VC backed enterprises nowadays because even if founder is nice it is pretty challenging to go against investors. It's not asways a bad thing because it creates many opportunities for us, small/solo companies, when we can exist to provice stellar services for our customers.

I've counted four different people who announced they work at Gitlab, in various different departments of the company.

Appreciate you all showing up, on the one hand, when so many different roles are all showing up in a thread to offer justifications and explanations it looks very uncoordinated, this isn't a good look.

and so it begins.

(I was going to post a wall of text about maybe "compassion fatigue with users privacy at odds with debugging" or "the rise of the marketing department" or "monetization strategies"... but the four words above are more succinct)

No, it began when we all decided to tolerate involuntary telemetry in Windows. This is just a minor roadside attraction on the same highway.

How would be stop that? We can’t switch our whole enterprise over to OSX. We’re very effectively locked in still.

osx has lots of telemetry.

Unfortunately, migrating off Windows isn't actually always possible.

It can be sometimes, with a kludge. Or by understanding the internals of the toolchains you use. But not all toolchains _can_ be run under another operating system. Or can only be run by violating the rather expensive support contract.

What I read from this is that Microsoft tainted the word "telemetry". If they had called it something else they wouldn't get people mentally associating it with Windows 10.

Yeah. They would instead associated it with rockets and spacecraft and other similarly cool stuff.

Some folks took a different route. I started out as a .net dev (1.0) and ended up rebooting my entire skill set in favor of technologies that respect privacy.

"We" didn't. A majority may have. Many, many people consider Windows a dead product.

Many, many people consider Windows a dead product.

Well, the market share numbers tell a very different story.

You don't consider millions of people 'many'?

Sure, percentage wise, the majority of desktop computers are on Windows.

My point was that 'we' didn't accept Windows telemetry. Some people did.

Out of curiosity Gitlabbers, have you thought about using an onpremises, self hosted product analytics/telemetry solution like Countly so that you don’t have to share PII data with a 3rd party? (disclaimer as usual: I work there).

How does this help gitlab's customers? (sincere question, my initial reaction has already been voiced here by others)

Helps them see how people are actually using the product, what's difficult, what's popular, etc.

And, of course, helps them make more money so they can hire more people/stay alive/etc.

How this being mandatory without opt-in help Gitlab users, more specifically?

Hello! Thanks for your feedback, because of it we added a section on our new issue about why we're doing this: https://gitlab.com/gitlab-org/growth/product/issues/164

Heh, I read that as "How does this help gitlab's competitors?" and thought "isn't that obvious?"

GitLab employee here.

First of all, my apologies for the confusing messaging to our customer base. This change is only for our .com customers. 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. As an example, we currently have a feature called "usage ping" which sends back aggregate usage data, and self-hosted customers have the option to turn it off. We will continue to allow self-hosted customers to control the level of product usage data that is tracked in their environment, or turn it off completely.

We also will not add tracking to the Community Edition, so that is always an option for customers.

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.

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...

> 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.

> 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!)

> 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.

This is a bad move.

Why not do what every other software package does and when you install it, ask if you want to "send anonymised information to help us improve the product".

I now have to convince managers that GL is still safe to use and there's no data exfiltration risk!

Data is the new crack. They just can't resist it.

There was apparently months of internal discussion on this topic [0][1][2][3] (edit: particularly here [1.5] "It's not practical to send all of this metadata with every event, especially since we don't know what metadata we'll need ahead of time. In order to do anything beyond surface-level analysis, we need to be able to join on user_id."). In the end, the folks at the very top overruled the (relative) consensus that had been reached by Engineering, Product [4], and Compliance [5] that the tracking should only be done on an opt-in basis.

Paul Machle, CFO, responding in no uncertain terms that the consensus was not acceptable: "I don’t understand. This should not be an opt in or an opt out. It is a condition of using our product. There is an acceptance of terms and the use of this data should be included in that." [6]

The real juicy discussion seems to be on a private repo [7]. The final implementation plan [8] shows that tracking will be non-optional, including for self-hosted EE instances.

[0]: https://gitlab.com/gitlab-org/gitlab-foss/issues/64341

[1]: https://gitlab.com/gitlab-org/telemetry/issues/57

[1.5]: https://gitlab.com/gitlab-org/telemetry/issues/57#note_19041...

[2]: https://gitlab.com/gitlab-org/gitlab/merge_requests/14182

[3]: https://gitlab.com/gitlab-org/telemetry/issues/58

[4]: https://gitlab.com/gitlab-org/gitlab/merge_requests/14182#no...

[5]: https://gitlab.com/gitlab-org/gitlab/merge_requests/14182#no...

[6]: https://gitlab.com/gitlab-org/gitlab/merge_requests/14182#no...

[7]: https://gitlab.com/gitlab-com/gl-security/compliance/complia...

[8]: https://gitlab.com/groups/gitlab-org/-/epics/1937

> Paul Machle, CTO

Paul is the CFO.

facepalm thanks for the correction. Edited.

Why the fsck does the CFO get involved in what should be an engineering decision ? Why does he even get a say in it ?

Obviously the CFO sees that sweet telemetry cash

Exactly.

I worked for a company where the CFO got involved in engineering and operational decisions. And they were always terrible.

If I had a CFO who said that, and I was the CEO, he'd be fired.

Surely that's a soon to be former CFO considering the reputational damage he's caused. Gitlab on premise was an easy sell to companies and now they've lost trust and their main differentiating factor from github. How could I possibly recommend gitlab in future with people like this running the company?

That is an excellent analysis of how that Gitlab telemetry fiasco was conceived.

It is also good to see who was in charge of that fiasco: https://www.linkedin.com/in/paul-machle-445ba41/

Hope there will be way to turn off telemetry when self-hosting GitLab EE but looks like they are saying use CE which doesn't have some key features.

That's open core for you.

Yeah, this is yet another example for why you should not rely on open core. I use Gitlab because I liked their product but seems like I was burned again by using an open core product.

EE will respect a DNT header. Not amazing, but certainly not impossible to manage. (But on a per-browser basis is still a hack. It should be manageable by the instance itself. Maybe it will be once they have this ready everywhere.)

I also believe this isn't rolled out for self-hosted at all yet:

> 5d Scott Williamson We are not adding Pendo or Snowplow JS snippets to self hosted versions yet. That will likely come in a second phase of the project, and we will figure out opt in/opt out for those scenarios before launching. The reason we are communicating to those customers about it now is so we don't have to do the privacy policy change twice. So for now it's just .com customers. I will let @Tim Hey respond on where he would like discussion on this to go. [0]

[0] https://news.ycombinator.com/item?id=21339805

Hello! We're sorry for the confusion, self-hosted EE users are not affected by this change. We opened an issue here to clarify: https://gitlab.com/gitlab-org/growth/product/issues/164

To clarify: self-hosted EE users will not be affected yet. The issue implies that they will be affected at some point.

I hope the inclusion of these new features don't break Gitlab in air gaped environments (or those cases where the DNS is black holed so it doesn't work... though that may be a violation of the terms).

Given many major websites break if you enable tracker-blocking I would guess it will.

frontend devs urgently need to learn to write more robust code.

I work at GitLab in Support Engineering I'm talking with product now about this. We raised this when the conversation started as a concern, and I want you to know that internally I am advocating that it _doesn't_.

Wait, it's even a question? There are people internally asking for having air-gapped be impossible? I mean, is Gitlab just that tone deaf regarding enterprise or do you just have no enterprise customers to care about?

Well, looks like I no longer need to suggest we switch to Gitlab for our Fortune 100 :(

I see that as a severely negative development and that opens a lot of room for competitors. I don't think you made the correct decision here, Gitlab.

how do we pollute or poison the telemetry data?

That's a reasonable question for any required or opt-out telemetry collection.

So to make GitLab faster you are going to add more JS bloat. Ok.

Hi! GitLab employee here. We understand this is a topic that you all are concerned about, so we opened an issue to help clarify [1]. If you have any comments or concerns you’d like to relay back to us, you can do so there! We appreciate the feedback and want to be as transparent and accommodating as possible.

[1] https://gitlab.com/gitlab-org/growth/product/issues/164

Why is the following still open then? https://gitlab.com/gitlab-org/gitlab/issues/34833

Are those not conflicting each other? Genuinely curious.

> GitLab employee here. [..] If you have any comments or concerns you’d like to relay back to us, you can do so there!

In order to leave the feedback "there", one has to accept new Terms of Service. Folks who refused new TOS can not log in... Just in case if not all GitLab employees realize how bad the situation is.

But here's the feedback using HN, the user-friendly platform:

Please add an option to "delete and erase account" button when user decides to decline the new TOS.

https://news.ycombinator.com/item?id=21342650

Guess I’ll continue to self host Gitea and use SourceHut instead. Those are faster anyway.

Thanks for the suggestions! I'm going to start moving over.

Going to be interesting to hear from the people who left Github for Gitlab when Microsoft took over.

I wonder if the remote-ness of the company has contributed to the out-of-touch-ness of this idea.

But why? What can they possibly gain by this?

Hello! We opened an issue here including a section on why we made this change: https://gitlab.com/gitlab-org/growth/product/issues/164

That post doesn't really answer anything. There are far less privacy-invasive methods to "analyze usage".

Gitlab may have some watertight contract with pendo but that doesn't mean anything to me as a user since I cannot see what is transmitted and how often that is done.

Compare to how canonical does this: tell user we are about to send data and show them what is being sent.

Eh, look at comments coming from that account. If that's how they treat their users I think there's little to no chance this stuff will be reverted

its funny how "spying" became "telemetry". you see it everywhere..and it seems to we working.

Always beware those who try to control language.

A recent (thankfully failed) example is Nigel Farage talking about a "No Deal" brexit as a "Clean Break" brexit.

(sorry to bring up brexit, but it was a very recent example that sticks out in my mind)

So, time to go back to GitHub?

https://www.vice.com/en_us/article/ywen8x/13000-projects-dit...

I'm self hosting my projects on one of my servers but I have some projects on GitHub because I want them to be public. I copied them on GitLab one year ago and switched origin. I feel like I won't keep using that service now. Bitbucket is quite a pain to use so it's not an alternative.

You're welcome on SourceHut! Our business model is designed to incentivize us towards the users needs, so adding anti-features to push up a valuation or raise funds from VCs isn't in the cards.

Just wondering if there’s a pull request workflow now (not a fan of the patch-via-email workflow) and when do you think the service will be considered “stable”?

Check out the video here wrt pull requests:

https://sourcehut.org/blog/2019-10-15-whats-cooking-october-...

An article next month is going into detail on stability, but the short of it is that if the service meets your needs now, it's ready.

Given drew's (SirCmpwn on lobsters) responses to my comment[1] in a thread about pull requests vs email-patch workflows, it makes me think sourcehut won't be supporting PR workflows any time soon.

[1]: https://lobste.rs/s/zxokqi/finding_new_git_host#c_viqwir

Wow what an arrogant person. I was originally interested, but in reading that comment chain, all I heard was, “I don’t care what you think. My way is clearly the most superior way and you are less than for thinking any other way could possibly be valid.” That’s my cue to stay as far away as possible from a project, and it would be a shame to have such a daft and stubborn coworker for which I’m thankful I don’t!

An equal and opposing argument:

Email patches? You’re going to make me send an email patch? I can’t tell if you’re joking or serious... you’re... serious? Shall I write my patch into the computer via morse code as well? How could you possibly expect someone to take the time to jump through all the hoops that your massive ego and nostalgia for the past requires?

Oh wait, that sounds arrogant and childish too...

You say arrogant, I say opinionated. It's his product, his service, his rules. It's not like there aren't alternatives to choose from, and you're not forced to work on his service.

(This subthread reminds me that I meant to make an account there and start migrating some of my projects.)

I've always stated that a PR-esque workflow can be built on top of email, rather than replacing an existing system with a new walled garden like GitHub did. SourceHut is all about reaching out to the existing communities, and email is how git itself was designed to be used. In your sibling comment I pointed to a video which demos a new feature that allows you to prepare patchsets to be emailed in a manner which is very similar to preparing a GitHub pull request or GitLab merge request:

https://sourcehut.org/blog/2019-10-15-whats-cooking-october-...

I've always been of the opinion that email works better for me, and I think that too many people write it off without giving it its fair chance, but I've also conceded that many people enjoy the web-based workflow and I've been working on tools to accomodate them.

Pull requests that work through an email are an upcoming feature.

There was no reason to leave GitHub.

People started boycotting GitHub before GitHub even did anything wrong.

Github has tons of tracking.

GitHub is unreliable: GitHub bases the decision of blocking projects on the subjectivity of moderators. Bellow are two cases I could recall (I'm sure there are more):

1. https://news.ycombinator.com/item?id=19182956

2. https://tech.slashdot.org/story/13/12/14/1618239/github-take...

To me, not knowing when or why my software might be dropped is a fatal flaw for a service that exists to serve source code.

People started boycotting GitHub when it became Microsoft, with decades of evidence to back it up.

There have been, and continue to be, a variety of reasons to leave Github

edit: Ah I see you work for Microsoft. In that case it's not surprising you are stating that there are no reasons to leave

Tbh I was against the move way before I started working here.

Although I should say, I am pretty pissed off about them blocking Iran. Would've rather seen Microsoft apply for a sanctions waiver for github.

> People started boycotting GitHub before GitHub even did anything wrong.

Acquisitions happen all the time, but how many of those acquiring companies experience an almost immediate "mass exodus" of users? (I'm sure there have been others in recent history but I'm having trouble thinking of any at the moment -- other than GitHub, of course.)

Perhaps you should ask yourself why?

Why would all of those people immediately up and leave and boycott GitHub, especially "before GitHub even did anything wrong"?

Microsoft has certainly pulled the wool over the eyes of many... but some of us have both 1) been around for a while and 2) have a very good memory.

---

By the way... you aren't exactly "new" here, so surely you're aware that it's considered appropriate to disclose any relevant affiliations when commenting?

I mean...my bio has a link to my github which shows I work at Microsoft.

I spoke out against people moving out before I joined them. I certainly don't try to hide where I work :)

Thank you though, I'll add it to my bio.

GitHub seems to use both Google Analytics and it's own JS tracker.

I'm happy with self-hosting Gitea. This is for my own project though, so I don't know how it scales to large projects.

from gitlab:

https://gitlab.com/gitlab-org/gitlab/issues/34833#note_23515...

------------------

Here's an MR updating our blog post accordingly: gitlab-com/www-gitlab-com!33289 (diffs, comment 235139590)[2]

-------------------------

1 - https://gitlab.com/gitlab-com/www-gitlab-com/issues/5672 2 - https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/...

Did we get a reversion to the older ToS with this?

no concrete answer regarding that yet. I don't think the new ToS was published on gitlab.com already, so this might not be necessary.

I asked the question to get a clear answer, probably won't hear anything back regarding this.

edit: ToS has been rolled back as well: https://gitlab.com/gitlab-org/gitlab/issues/34833#note_23522...

> if you turn on Do Not Track in your browser, GitLab will not load the JavaScript snippet

This is actually awesome, and a very rare thing as far as I can tell.

I just deleted my Gitlab account. I'll be self-hosting personal projects from now on. It's clear that as an individual user of a third-party service you have virtually no control. No matter who you choose, the odds are that the owners of the service will eventually succumb to the siren song of VC money and sell their users' souls as a result.

Don't ever do this. I'm a huge gitlab advocate and I'm already wondering if I should regret that. Keep in mind that one thing that keeps gitlab alive is that which it is not: github/microsoft. If you erase that boundary then there is no longer any good reason to recommend gitlab over github.

Seems like a good time to ask: who is using source hut? How do they find the email driven merge request process?

Isn't a non-optional, opt-in-by-default third-party telemetry prohibited under GDPR?

> Until the new Terms are accepted access to the web interface and API will be blocked. So, for users who have integrations with our API this will cause a brief pause in service via our API until the terms have been accepted by signing in to the web interface.

Doesn't this make it not "opt-in-by-default"?

It offers no opt-out and blocks API and web access until you’ve accepted the new terms, so it effectively is opt-in by default.

this sounds like extortion.

Not according to the EU:

https://gdpr.eu/gdpr-consent-requirements/

You can look as the engineers wonder if this does, but the executive team decided otherwise: https://gitlab.com/gitlab-org/gitlab-foss/issues/64341

Hopefully that's a mens rea on violating GDPR.

From the summary:

> The primary responsibility of the new growth team is to run experiments

Ah, the new growth team. I guess that explains it all. They hired "growth hackers" now.

EDIT: interesting bits from the thread under that link:

> Luca Williams (PM/Fulfillment): The general consensus I've heard through many conversations and discussions from an executive level is that opt-in is not preferable. Opt-out is the default.

And that's precisely why GDPR happened. Because executives of companies think "opt-out is the default".

> Dennis Tang (Frontend Engineering Manager): Correct, you could still call it an opt-in though, as in they're "opting-in" not to see the notice again...

That's in context of calling a TOS change notification popup dismissal 'technically opt-in', but it's a pretty mind-mending way of interpreting what "opt-in" means.

> https://gitlab.com/gitlab-org/gitlab-foss/issues/64341#note_...

That would suggest they already collect a lot of data, but keep it anonymous. The proposal in the link would essentially turn it into instant GDPR violation.

I've mostly only skimmed the thread, but it seems to me that a lot of words were written about whether or not they should include a detailed opt-out feature, with apparently no one realizing that GDPR would require this to be opt-in.

It's certainly something that some EU data protection regulators are looking into. Here's a related story, this time in the context of Windows 10, from earlier this month:

https://www.gdpr.associates/dutch-dpa-microsoft-breaches-dat...

Hello! We're sorry for the confusion, we opened an issue here that might help clear things up. Feel free to voice any concerns or feedback there so it can be properly relayed back: https://gitlab.com/gitlab-org/growth/product/issues/164

edit: Comment no longer relevant since URL has been updated.

We updated the URL above to that one. Before that it was https://gitlab.com/gitlab-org/gitaly/issues/2113.

Which has been moved to https://gitlab.com/gitlab-org/gitlab/issues/34833, since it was using the wrong issue tracker before.

That doesn't mean you have to edit what it said...

It was a copy paste of a section of the blog post now linked, nothing more.

https://gitlab.com/gitlab-org/gitlab/issues/34833#note_23475...

For paying Gitlab customers, this sums up the general opinion well.

https://about.gitlab.com/blog/2019/10/10/update-free-softwar...

This would be a better link.

Ok, changed to that from https://gitlab.com/gitlab-org/gitaly/issues/2113. Thanks!

Additional discussion that is currently marked as a [dupe]: https://news.ycombinator.com/item?id=21343761

Why send user data to third party ? Don't they have the man power to build a db with all the logs and maybe add that to a securing ml bullshit for Enterprise ?

they just keep rolling out the hits

https://news.ycombinator.com/item?id=21274511

Seems they are preparing for selling to Google!

Looks like it's time to find a new service. This is very disappointing

Hello! GitLab employee here... No just kidding.

this is a clear violation of GDPR, unless they can really guarantee the data is 100% anonymous, gitlab was able to provide the service without telemetry & is now blocking access to the (self-hosted) service unless one consents to the new data gathering practices.

Best of all, 12.4 was released 2 days ago, the notification e-mail was sent out today...

Had to leave out the "Dear XY" and "Thank you,

GitLab Team" in order to fit into 2k char limit.

We've put in the URL above that has the same text.

Just use the DNT header and they won't track you.

This doesn't help the concern from enterprise users that they don't want their self-hosted software to phone home, ever.

Hello! Self-hosted users on EE are currently not affected, we opened an issue here to clarify: https://gitlab.com/gitlab-org/growth/product/issues/164

"Not yet" is small comfort.

DNT was a failure that shouldn't be depended on for anything.

Safari has already removed it in version 12.1 (https://developer.apple.com/documentation/safari_release_not...), so if that's the only opt-out mechanism there's no way for Safari users to make that choice. That probably includes all iOS users, since all iOS browsers just wrap Safari.

I wouldn't be surprised to see other browsers remove it eventually as well. Like Apple says, it ended up doing the exact opposite of what it was supposed to -- almost nobody obeys it anyway, and it hurts the privacy of people that try to use it by contributing an uncommon factor to their browser fingerprint.

DNT suffers from a lack of trust. I have turned it on by default, but I kind of assume that it's completely ignored.

Nobody really reads , not even smart hackers. That is my first thought after reading a lot of comments.

Reply on news.ycombinator.com