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.
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
> 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).
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.
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.
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.
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.
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.
> 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.
> 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.
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.
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.
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.
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.
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..
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.
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.
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.
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
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.
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
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.
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
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.
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
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.
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.
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.
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.
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.
>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 :).
[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.
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" ?
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.
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 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
> 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?
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 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.
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.
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.
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.
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.
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?
> 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
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.
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.
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.
> 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.
> “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.”
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.
> 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].
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).
... 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/
[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.
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.
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.
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)
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.
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.
(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)
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.
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.
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.
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).
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.
> I want to reiterate that we are using this data to improve the product experience.
This sentence holds zero meaning and is not helpful in any way.
Free software, like science, is built upon proof, not upon trust. Here you are asking your users to trust you, but you shouldn't need to do that in the first place. Trust is earned and cannot be asked for. The fact that most of your product has visible source code except for the tiny part with suspicious behavior does not help your case.
And I guess you will make it opt-in instead of opt-out for the self-hosted Enterprise Edition, right?
Edit: also, the email you sent out to your users is very different from your blog post.
In the blog post you ask for feedback from your users, which is not the case in the email, which is written as an actual announcement that this is going to happen.
We've heard your concerns and questions. There were many more concerns than we expected. We’re going to process the feedback and rethink our plan. We will not activate product usage tracking on GitLab.com or GitLab self-managed before we address the feedback and re-evaluate our plan. We will make sure to communicate our proposed changes prior to any changes to GitLab.com or self-managed instances, and give sufficient time for people to provide feedback for a new proposal. We'll work in this issue: https://gitlab.com/gitlab-com/www-gitlab-com/issues/5672
> 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!
> 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!)
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!
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.
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?
> 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.
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]
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.
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).
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?
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.
> 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.
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.
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”?
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.
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:
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.
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?
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.)
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):
> 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?
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.[1]
Here's an MR updating our blog post accordingly: gitlab-com/www-gitlab-com!33289 (diffs, comment 235139590)[2]
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.
> 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.
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.
> 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.
> “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.”
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
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:
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 ?
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...
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.
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.