GitLab introduces user limits for Free users on SaaS

You do realize you suggested a $4752/yr option (4 developers) versus a $3192/yr (14users) option, right?. Again, we’re perfectly fine paying for our 4 developers and their associated resources, we just don’t see why we need 10 other licenses for commenting on an issue a couple of times a month.

@mrydzik yes I do, for a much broader capability. Thanks - I understand your point.

Thanks - in order to provide visibility to your storage consumption we needed to complete a datastore migration for the meta-data of one of the largest contributors to storage consumption on GitLab.com, the GitLab Container Registry.

Hi @lmcdo - Thanks for your feedback. The decision to limit free namespaces to 5 users was informed by data and research which balanced user impact with sustainability for GitLab.

I’m curious who carries out your data and research? Also, I’m curious who actually thought that those results were a great idea?

First Gitlab dropped the starter package, starting price now at $19 per user - which when Github has a $4 per user, you really are pricing yourselves out of the market. Even with that said, Github still has free user limits, with far less restrictions than Gitlab.

Now you limit the amount of users to a namespace, which is also far less than Github since collaborators at Github for public/private is unlimited.

So I’d like to hear of both research/data result sets which made you came to the conclusion that you should cripple your platform so much? All you are doing is simply pushing everyone away from Gitlab and on to Github. Github must be thanking you for all the users who would have wanted to pay for starter since it was pretty much the same price as Github Pro. But since you dropped that package you lost all that possible income. Now restricting the amount of users to a namespace or collaboration if you like to 5 users, you are pushing even more people to Github since they have unlimited collaboration.

Also, whilst I appreciate that open source projects can write to Gitlab and ask for their project to be given the ability to have more users than the limit - that is actually a pretty lame way of going about it. They can create a project/repo on Github, and do everything without having to make a request to increase the limit because there is no limit for collaboration. I could understand such a move to get Ultimate/pro features, but just to increase over 5 users is poor when by default that can be done elsewhere with zero hassle whatsoever.

Not only that, Gitlab and it’s communication is pretty poor when they take way too long to respond to support tickets that are opened anyway since if the user is a free user, the reply goes something along the lines of you don’t have a subscription. Anyone making such a request for open source projects to increase the namespace limit will be a free user, so you really need to address that properly and respond properly than just ignoring the request because Gitlab checked that they don’t have a subscription (free user) and ignore the request. Alternatively, create on the support ticket platform the appropriate option so that whoever responds actually doesn’t ignore free users and addresses their issues appropriately. For example, create an open source support request category (or something appropriate) and ensure that free users who do open a support ticket, get dealt with accordingly.

The only one I see winning here is Github. Gitlab has nothing to gain from this scenario and in fact has far much more to lose.

Hi,

Honestly, four weeks notice is ridiculous. Even the full period of three months is way too short.

I understand the difficulty of sustaining a free service, which is why companies should think twice whether they can afford that before offering it. But to effectively cancelling the free service (for larger teams), with this ridiculous short time of notice for existing customers, is just bait & switch.

A responsible way of doing this change would have been introducing the limit for new users and giving the existing user base at least 12 months of time to adjust.

You will lose 90% of the users affected. Financially you might think that’s not a bad thing at all…
However, some of these users will switch to paid plans from the competition - which means a lost opportunity of increasing your customer base.

And the real damage is on your reputation. This is not the way a responsible and trustworthy partner would act, and organizations don’t want to make business with non-trustworthy partners.

Just to confirm, this is what you call a namespace and this is shows the number of users in that namespace https://gitlab.com/groups/GROUP_NAME/-/usage_quotas#seats-quota-tab?

Hi @IbrahimBeladi, thank you for your question!

That’s correct, you can view and manage the users in your namespace by going to Group > Group Settings > Usage Quotas > Seats.

The way this is communicated is abysmal, to say the least.
I only got notice of this by chance while working on something CI related and noticing that notice about CI minutes (no mention about the user limit).
Only because I got curious I actually clicked on the link, only to find out that not only affects CI minutes (which per se are irrelevant to me as I employ my own runners for the majority of cases) but completely cripples the infrastructure I have build thus far.

By that time it was already very late April, so it doesn’t count as an Aprils fools anymore at least, even though one could take it very much as a bad joke…

As a former “Early Adopter”, as it was once called (I was using the platform even before that term existed, which was then phased out just like starter was), this is a pretty saddening move at the very least.

I was never very fond of the pricing model, not only because I don’t have that much money I can spare, but because it’s applying paid seats way too greedily.

People that report issues and provide feedback in general won’t benefit from most of the features, so why would I have to pay for their seats as well?
I’m fine with them being there as guests, but no, that’s only available for ultimate plan.

In my opinion, payment shouldn’t be about mere head counts, but the features in use by the particular person/team(or namespace in this case) as there’s a clear difference between a user and a contributor/developer.
But that’s beside the point here…

It just so happens that the core team I work with is just 6-7 people big, ignoring users of the issue tracker, so this very low limit is especially frustrating.
There are a few reasons why the team and most of it’s projects currently is private and can’t be applied for “open source” or the like.
But at the very least it’s not for profit, so there’s no income in that area either way. (one could call it a hobby if they really want, but imo it’s more than just that, there’s just no official way to have that recognized)

I know that at least 50% of the features offered on the free plan are being unused on our team (while others we could very much use are paid only) so there is quite a misalignment with those rigid plans.
for something that calls itself SaaS I kind of expect more flexibility…

And usage wise, the namespace for the team currently only uses up to 1GB space in total, spanning over multiple subprojects, so not very much, no shared runner usage, just currently around 15 users in total (as the issue tracker isn’t public yet)
That is not to say it won’t use more in the future, but as it stands it’s hardly relevant enough to be a financial issue to GitLab on its own.
Yet it’s on the verge of being culled away…

And just because of that, I’ll have to at least move the entire issue tracking elsewhere (likely GitHub),
just as things finally started being all under the same roof…
And depending on a few factors, might even move entirely away from GitLab.
There was and imo still is potential to GitLab,
but recent management decisions have increasingly made it very hard to see it that way.

This change won’t get Gitlab more money, it’ll only save them minimal money from the number of projects that migrate away. The first paid tier is too expensive for most user cases that are affected by this change, so the only option is for users to migrate away to other platforms. There are a number of projects I mange on Gitlab that will now need to be migrated away to other options, because the price jump caused by this just isn’t reasonable.

If I understand it right, paid users will consume free seats?

That does not make any sense and will severely cripple usefulness of GitLab. Why not always have 5 free seats per namespace? That would at least allow having few temporary visitors (for example customers) without the need to pay them subscription. Or how am I supposed to do that?

Overall pricing of GitLab is a mess - I pay to use a service but anyone who wants to participate in my namespace has to pay too? I have to pay to participate in others namespace, or even force maintainer of that namespace to pay (and for everyone else) to let me join (even though i am paying) if i am 6th user? Huge mess or overpriced mess - not sure which one.

We’re a not for profit, with multiple volunteers who just do occasional work. We’re happy to pay something for GitLab, but suddenly going to $19 per user per month is just completely unaffordable.

Is there any possibility of a higher threshold for non-profit organisations? Apparently not. So I guess we go elsewhere.

Seems that GitHub not only has more mindshare in the development community, it now also has much better value plans.

First of all, of course we are affected and of course this is a ridiculous decision. A better way to go would be to limit traffic or disk space use. Absolutely useless is to make the 5 latest active user the only ones who can use the namespace from then on. What if none of those is a maintainer or owner? Who can then make sure that the namespace can be used?

I am also quite disappointed to have found this out by accident, not by you contacting me. Do I see correctly that self-hosting within the free plan is a way to keep unlimited amount of users?

Yep, this is still possible, the changes only seem to affect gitlab.com. It just means managing and maintaining your own self-hosted install, which means regularly applying updates as well so that if a CVE risk appears, that it doesn’t get compromised - there are plenty of posts here relating to installs that were neglected in terms of updates and then compromised. I generally regularly update mine every time an update comes out, so once a week or so - it all depends on when the release is made, but then there are also other OS-related updates regularly as well.

Correct.

Self-managed GitLab won’t have this user limit. You can run GitLab EE without a license (which is the Free tier then), or GitLab CE (only open source components), on a cloud VM via Omnibus package installation or in Docker containers, in a Kubernetes cluster, or on a Raspberry Pi. See Download and install GitLab | GitLab for more details.

Hello @robmcdonell. Thanks for your feedback. We appreciate the work non-profits do with GitLab! We encourage you to consider using GitLab self-managed which does not have a user limit. More details are below. We don’t currently have a formal non-profit program but we encourage you to share some details about your non-profit in our issue (as it helps in our scoping of a potential program) and subscribe for updates.

Self-managed GitLab: You can run GitLab EE without a license (which is the Free tier then), or GitLab CE (only open source components), on a cloud VM via Omnibus package installation or in Docker containers, in a Kubernetes cluster, or on a Raspberry Pi. See Download and install GitLab | GitLab for more details.

Hi @j.dobr, Thanks for the feedback. GitLab charges for subscriptions at the parent namespace (group) level; every free group after June 22, 2022 will be limited to 5 users. If a namespace(group) has a paid subscription, then the namespace can have as many paid members as they’d like to pay for. If you’d like to manage separate pieces of work while maintaining the same users within one parent namespace, then we’d recommend using sub-groups. I hope this helps provide some additional clarity.

Does that mean that if you work for two organisations, with two different namespaces, then both organisations would have to pay a subscription for you?

@dnsmichi Thanks for replying to this part of Jorn’s question. Would you have an answer to his first question as well?

Thanks,
Helmuth

Hi @helmuthb - Gayle from the GitLab Product team here. Our technical implementation of user limits for free SaaS namespaces prioritizes keeping group owners and maintainers first, then most recently active users to fulfill the 5 user seat allocation per namespace. The scenario of a namespace without an owner or maintainer is very rare. We encourage you to review your namespace users and role assignments before June 22, 2022, when the user limit enforcement will go into effect.