These are carefully constructed truthful statistic lies.

Of all the free users, how many of them even have a repository? Out of all the users who have a repository, how many of them actually make any use of CI/CD?

They are saying "1.5%" to make it sounds small, but those 1.5% could account for a significant portion of total minutes of CI/CD used.

This seems... ambiguous, actually. I for one automatically took "free users" to mean free users of the CI/CD feature, not free users of GitLab. Meaning, the set of people who use > 0 CI/CD minutes. I'm actually surprised if that's not what they mean, given the entire point of the discussion is about how this affects users of the CI/CD feature. It's one thing to state things clearly and let the reader make incorrect inferences just due to natural assumptions, but writing the text itself ambiguously to induce that effect is a little different.

Hi, thanks for your feedback. We will consider making sure to clarify that going forward. Free users refers to users of the free tier of GitLab.

this isn’t a feedback loop for git

More importantly, it's not the same 1.5% each month. So if they're going to stay with with Gitlab, they'll need to switch over to paid, even if they're the 98.5% in other months.

That said, I'm not complaining about free.

Oh, that's even more devious if true! Although I'm not sure about this one, it might not be exactly the same 1.5% of users every month, but I'd guess most users CI/CD user stays relatively constant or increases at a gradual relatively constant rate, it doesn't jump up and down unstably month over month. I'd guess which users are in the 1.5% is relatively constant, right? Although you're right that the % of users in a given year that went over in any month must be somewhat more than 1.5%.

Man, I was expecting some sort of business/budget answer that I woudln't have insight into not being in this kind of business. I was not expecting straight up "misleading statistics, that number probably doesn't mean anything like it seems." :(

This is exactly it. 1.5% of users does not equal to 1.5% of CI/CD minutes. And such messaging isn't always dishonest. If you have 99 users using 100 minutes each and 1 user using 10 million minutes, setting the max limit to say 1000 is a net benefit for the system and its users, at the expense of the one outlier.

Yes, but in this case one user couldn't use 10 million minutes, they were already capped at 2000. Now they are capped at 400 instead. So that limits how extremely disproportionate the high percentile use could be. As I said, that 1.5% of users could have been using at most 1600 more minutes a month than the new max.

If the other 98.5% don't use any minutes, then it's an 80% reduction. That seems pretty good. We can't say more without real numbers though.

They can make infinite repos though!

Oh, that is devious if they meant 1.5% of all free users, not just 1.5% of users using CI at all. But I guess that does seem likely.

Great point.

And I guarantee you that they did the math to optimize for conversion and churn. Behind all product decisions are an army of analysts.

We certainly did the math. And a small percentage of the users generate a large percentage of the CI minutes. Hence the change.

It wouldn't surprise me if 90% (or more) of their free users use exactly 0 minutes of CI/CD per month.

So then it's more like 1 in 6 of the people that do use CI/CD need more than 400 minutes per month.

Just to be clear, these numbers are completely made up. They seem reasonable though.

This sort of thing happens a lot when you first set up a free plan. Some part of it turns out to cost more money than you expected, and it’s a small but growing segment. If you’re going to have to pull back in it eventually, why wait? Waiting might just annoy twice as many people when you inevitably have to introduce stricter limits later.

> and it’s a small but growing segment

They could have grandfathered the existing accounts into the 2000 minutes. Then the segment would no longer be growing and stay small, no?

Except in this case individual users will also grow. You'd have to do something like grant them their current usage plus some buffer (without letting them know ahead of time maybe, since otherwise this is gameable).

Why do you need a buffer? If you’re grandfathering in old and limiting new users more, what is gameable? Besides a small portion of people registering accounts in the short time between announcement and implementation?

The math works out if you presume that 20% or more of that 1.5% is converted into a paying customer. If I was using GitLab that much and could pay $20 to support GitLab but wasn't already a paid subscriber, I probably would think about it. (I'm thinking about it now, and I don't even use GitLab.)

Worth thinking about this in the context of fat-head vs. long-tailed distributions, or less formally "whales". A very small number of users (the "head" or "whales") can account for most of the area under the curve, which in this case is the cost of delivering free build minutes.

For a toy example, imagine one user uses 2k minutes, 10 use 100 minutes, and 1000 use 1 minute. In this case you have "Over 99% use 100 minutes or less", but 50% of your cost is going to the one 2k minute user.

I have no idea if this is their exact curve, just showing how a fat-head distribution could explain what they are saying. I'd expect the "demand" (i.e. minutes used if they were not constrained / all paid for) to be a power law distribution.

Also worth noting that there's a sort of bimodal selection effect going on here -- it's unlikely that you use exactly 2k minutes/month, since you'd be hitting your limit and that would be disruptive. So the closer you get to using 2k minutes, the more likely you are to pay for more than the free tier. So I'd expect this pricing change to also force some users that were previously on 400 minutes +- 100 to have to upgrade too; this will impact some of the 98.5% of free users that are using <= 400 _on average_ per month.

Don't forget the fact that you have the option of running pipelines on your own machines. I do this for all my projects, and only really use shared runners by mistake when I forget to set it up.

I am a little dismayed to find out that open source projects no longer get unlimited minutes, though.

Pretty incredulous position to take when a company offering free stuff makes adjustments to their free stuff

What position do you think I took? I just asked some questions out of curiosity, I did not mean to take any position.

Do you have a blanket position against being curious about the business models or policies or statements of companies offering free stuff about their free stuff? Does that apply to facebook and google too?

> Or they anticipated that number going up if they didn't make the change?

Do CI/CD minutes ever go down once you start? I suspect not.

They probably plotted the trend line and realized that they had to do something.

Or, it could be bifurcated. Most people use like 2 minutes but 1 in 100 use 2000 minutes.

They may also be tracking and saw that people were using the free 2,000 minutes as "overflow" with multiple accounts.

It’s because cost isn’t the issue. The change is designed to convince more free users to switch to a paid account.

OK. But they're saying the number of free users that would have to switch to a paid account is 1.5%, right?

Which doesn't necessarily seem like enough to justify a disruptive change that might scare customers... but I don't really know I'm hardly an expert or have experience in this kind of business. You think it is, is your hypothesis?

If they have 100x the free users than paid users it would totally be worth it. It depends on the numbers.

A service like that will have an enornous amount of free users who signed up but don’t ever use the service and count as 0.