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 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.
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.
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.
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.
We're in the process of taking a 50user Premium (aka self-hosted) GitLab subscription, don't make us reconsider and search alternative means.
ps: SOC2 does not inspire confidence as the whole of EAA needs to follow GDPR.
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.
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/...
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”.
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.
I don't know what did you expect?
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.
However, I'm relatively sure that this is due to the efforts of our very talented Windows Systems Administrators. Nonetheless, it's possible.
The business has to be sold on Gitlab by the developers.
> 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.
Small companies are generally more trustworthy, until they come to a position of dominance, where they are just there to squeeze.
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..
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?
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.
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.
Are you aware of the privacy concerns surrounding reCAPTCHA? https://en.wikipedia.org/wiki/ReCAPTCHA#Criticism
There's your problem. This should be entirely opt-in.
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.
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
Choice is good, more things like this mean that there's less of a differentiating factor between hub and lab.
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.
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.
Let people speak, and listen.
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.
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.
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.
It means that they are fine with these issues and don't need to have them fixed.
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.
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.
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.
soo much this!
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.
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.
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)
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 :).
 - https://wiki.lesswrong.com/wiki/Egan%27s_law
 - 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.
 - 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.
yes, but it does let you know where to place the ads and “special offers”
Which is exactly why I said both matters.
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" ?
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 is simply not true... but telemetry is something you can trust far more than user feedback
From inside GitLab Slack:
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:
Tim Hey Hi @Support Engineer Looks like @Scott Williamson just beat me to the it. :sweat_smile:
Support Engineer You both are amazing and I can't thank you enough.
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.
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.
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
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'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 support request is 136340.
Regardless, happy to clarify whatever I can.
That only applies to Personal Data. It doesn't close your account or delete your source code. etc.
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.
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
> 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.
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.
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.
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 because it was only being used for fingerprinting.
In retrospect, it's hard to imagine this working out any other way.
Can it come in an ∞th phase instead?
Do I have to agree to the TOS at this time?
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?
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.”
> 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.
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.
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
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 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.
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)
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.
>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.
(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)
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.
Well, the market share numbers tell a very different story.
Sure, percentage wise, the majority of desktop computers are on Windows.
My point was that 'we' didn't accept Windows telemetry. Some people did.
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.
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.
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.
Here's an MR updating our blog post accordingly: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/...
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.
Here's why that line of reasoning won't fly with users:
- 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!)
And, of course, helps them make more money so they can hire more people/stay alive/etc.
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!
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." 
The real juicy discussion seems to be on a private repo .
The final implementation plan  shows that tracking will be non-optional, including for self-hosted EE instances.
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.
It is also good to see who was in charge of that fiasco:
Paul is the CFO.
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:
frontend devs urgently need to learn to write more robust code.
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.
Are those not conflicting each other?
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.
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)
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.
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.
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.
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...
(This subthread reminds me that I meant to make an account there and start migrating some of my projects.)
People started boycotting GitHub before GitHub even did anything wrong.
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.
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 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.
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
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.
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.
Here's an MR updating our blog post accordingly: gitlab-com/www-gitlab-com!33289 (diffs, comment 235139590)
1 - https://gitlab.com/gitlab-com/www-gitlab-com/issues/5672
2 - https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/...
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...
This is actually awesome, and a very rare thing as far as I can tell.
Hopefully that's a mens rea on violating GDPR.
> 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.
Doesn't this make it not "opt-in-by-default"?
For paying Gitlab customers, this sums up the general opinion well.
This would be a better link.