GitLab introduces user limits for Free users on SaaS

No, I set up my own self-hosted GitLab since the pricing of GitLab.com is ridiculously expensive.

3 Likes

I don`t fully understand what do 5 users per namespace mean.

Does it mean that a project, created by an owner with a Free Plan can have up to 5 members only?
In my case we only use gitlab as a collaboration forum to create and manage tickets among the memebrs of the project.

Thanks for helping!

2 Likes

It is 24 days to 22 June. We have not received any notification (either in app or email). Additionally, neither Group information > Members nor Settings > Usage Quotas provide any notice of this upcoming change.

Fortunately, we were made aware of this post and moved to self-hosted.

Gitlab is an excellent product and we are grateful for its support for the community over the years. Unfortunately, the lack of communication for such a significant change is very disappointing.

4 Likes

Hello,

I just want to express my disappointment with GitLab limiting 5 users per namespace in Free plan.

Our company has 100+ people across multiple projects. While an outsider would just point out ā€œhaha just buy Premiumā€ (which would cost over $2000+ per month, which is NOT cheap and require approvals from the company top-level management), GitLab failed to realize that the alternative to paying at all is just migrating to GitHub which offers unlimited seat and private repository for free.

While I personally can vouch for the quality of the tooling in GitLab and consider the $19 per month per user to be justified, it is VERY difficult to convince the company to pay when the alternative is free.

It has been a great 7 years working with GitLab. Unfortunately, our business interest donā€™t appear to align, but thank you for all the great times. I hope you reconsider limiting the amount of user in the Free plan.

4 Likes

Running your own Gitlab instance is one way to do this, but you would need a VM with 4cpu, 8gb ram as a minimum. Either gitlab-ce or gitlab-ee without a subscription works fine. The main difference being if you decide in the future to ever want or need a subscription it can easily be applied to gitlab-ee. With gitlab-ce you cannot, but you can upgrade it to gitlab-ee and then do it.

3 Likes

The date has been changed, see the initial blog post:

2022-06-02 UPDATE: Weā€™ve heard your concerns about the enforcement timeline of the user limits. We are now moving the enforcement date to September 15, 2022. In addition, to ensure all users are aware of the upcoming change, email and in-app notifications will be rolled out through June, 2022

3 Likes

The decision is still stupid, but at least it sounds like they want to inform people about it now.

It will be interesting to see how this thread develops over the coming months, when people realise they will be affected.

4 Likes

@SAS-kaida I think user-level personal namespace does not support corrected calculations to date.

While @hachque didnā€™t tested on production, I checked it on production (SaaS), so much closer to the truthā€¦

With note from @helmuthb, the due is changed, so calculation might be fixed later to limits users up to 5 even in user.

1 Like

@tnir
Thank you!
I see, so you mean that the method of checking the conditions was not implemented in my usage (user level).

The enforcement has been postponed to September, and the official notification will come in June, so I will wait for the time being.

1 Like

@helmuthb Thanks for the information!

After your notice, I found the docs is not maintained simultaneously. Instead of GitLab team (or GitLab company GitLab Inc., who run on GitLab SaaS (gitlab.com) ), I am personally sorry for it. That would be fixed very soon (I hope) with docs: Update the enforcement date for free user limits (!89376) Ā· Merge requests Ā· GitLab.org / GitLab Ā· GitLab

@gdoud

How can your first paid plan be ā€œPremiumā€? Thatā€™s nonsensical.

Please add a Starter plan for $2-$5/user.

2 Likes

I have a question regarding users belonging to multiple groups.

Some of the members of our gitlab.com group are external, e.g. they are employees of a partner organization. They are currently counted in the Seats In Use in our group. We cannot pay gitlab license fees for them - they need to have their own gitlab invoice.

Should we ask them to create their own gitlab.com group (they donā€™t currently have one)? When they create their own group and the users will pay license fees in their group, will they stop being counted in our Seats In Use?

1 Like

Please add a Starter plan for $2-$5/user

Oh, they had that until beginning of last year. and they ditched it. See Features available to Starter and Bronze subscribers | GitLab

This would indeed have been a viable alternative, but somehow the management board (or whoever made the decision) decided to force everyone out of Gitlab or into a very expensive plan. I really dislike the way Gitlab is communicating with (e: and treating) us. As a consequence, we will move to Github (and pay them 5 bucks per month actually).

4 Likes

Ya, Iā€™m aware. I could have said ā€œrestoreā€ the starter/bronze plan, as opposed to adding a new one, but it might not have the same set of features.

We may also be forced to move to GitHub. What a mess.

2 Likes

Thanks for your feedback, @abartlet. We do have the GitLab for Open Source Program which provides free, unlimited seats of GitLab Ultimate (self-managed or SaaS) to qualifying Open Source entities. Have you considered applying? We do accept entities that accept donations into the program as long as they are non-profit. More details about the program requirements can be found in the link.

Iā€™m a member of many open source projects currently enjoying gitlab.com. The features provided are really excellent and Iā€™ve promoted use of GitLab as an alternative to GitHub for many open source projects, and even developed a significant interactive command line application for GitLab merge request reviewing. The projects Iā€™m involved in are spread across many top level group namespaces, since they have only partially overlapping contributor bases and thus better operate independently.

When the limits on CI minutes were announced last year I was not entirely surprised, as providing unlimited CI time for anyone was never going to be sustainable for a company. I was fairly confident we could find a viable solution though, whether it be reducing our CI usage, or adding private runners, or side loading an external CI system, or joining the Open Source Program in the worst case. There are many options.

The enforcement of a 5 member limit on the free tier though is quite a different prospect. Other Ultimate features we used by chance were non-critical things we could likely live without if it came to it, but the 5 member limit is a hard block. Quite a few of the projects Iā€™m involved in already exceed the proposed free tier 5 member limit. Any OSS project that wants to be a success over the long term usually aims to bring on board new contributors periodically, so can hit the 5 member limit of the free tier at any time. If a project is already at 5 members, this is limit is going to be a significant disincentive to add a 6th contributor. This compromises the suitability of gitlab.com as a service for OSS projects. It is critical that the on-ramp for adding new contributors to a project is smooth and have no disincentives, which is something GitLab has excelled at historically.

Given membership numbers, if we want to stick with gitlab.com weā€™ll already require many separate applications under the GitLab for Open Source Program, repeated each year, for each top level namespace which is a tedious bureaucratic burden. What is the real killer though are the terms & conditions (GitLab for Open Source Program Agreement | GitLab) weā€™re asked to agree to after the application for the Open Source Program is accepted, in order to activate the free license, which really require a good legal mind to interpret. Most concerning is the clause around financial liability

2.3 Notwithstanding any other terms stated within this Agreement or the GitLab for Open Source Program, in the event Member uses the GitLab Software for any purpose other than the Acceptable Purpose, Member shall be obligated to pay for such GitLab Software in accordance with the Commercial Terms. For the avoidance of doubt, Member shall be obligated to pay for all such use of the GitLab Software, including for any periods of use prior to the discovery of such usage outside of the Acceptable Purpose.

Picking one project Iā€™m involved in with 30 members. At GitLab Ultimate pricing of $99 /user/month, this term is asking the members to collectively accept a financial liability of ~$36,000 / year, should GitLab decide weā€™ve not been compliant with the usage rules, backdated potentially to when the project first activated its Open Source Program membership many years earlier. The interpretation of the phrase

does not seek to make a profit from the sales / provision of the Open Source Software, or any services related to such Open Source software

is really fuzzy when a number of the open source projectā€™s contributors are employed by software companies, even more so if copyright of the memberā€™s contributions is owned by the employer. Iā€™m not personally selling the software or services related to it, but my employer certainly could be - potentially without my knowledge in large enough companies. Further, if just one contributor who is a member of the project does something that violates this phrase, all the project members appear collectively financially liable to reimburse GitLab for the Ultimate level license fees. I may trust my co-contributors in terms of writing code, but Iā€™m not going to expose myself financially for the actions of people Iā€™ve never met. I imagine in practice GitLab would not want the bad PR of penalizing OSS project contributors like this, but none the less it is in the legal agreement so we have to consider the worst case implications of it.

Overall I canā€™t see myself being willing to agree to these Open Source Program terms for projects Iā€™m leading. Whatā€™s even worse is that if another project has already agreed to them, I fear I wonā€™t be able to become a participant in that project either, since I would not want to be exposed to the collective liability theyā€™ve already agreed to.

With these T&Cs for the Open Source Program it feels like the only real choices for OSS projects with 5+ members (or expecting to get there) are to use a self-hosted GitLab installation, or to switch to GitHub or another git forge :frowning: I appreciate that enforcement of the new limits has been pushed out a few months, as that at least gives projects time to explore their options instead of rushing.

8 Likes

Oh damnā€¦ Iā€™ve sent an application for OSS license for my selfhosted instance, but after seeing this Iā€™m starting to re-think if Iā€™ll use it even if the application is accepted.
I canā€™t be sure if any of the private projects of my users are for-profit.

1 Like

Hi @robert_t, thanks for the question. You are correct the best course of action here is to have the members of the partner organization create their own group, to reduce confusion Iā€™m going to call your current group group-A and their new group group-B. Once they have established their new group (group-B) you can go ahead and delete these users from your current group (group-A) at which point they will no longer be counted within your seats in use within group-A.

1 Like

No no, we cannot remove them from our group A. They need to have access to our (shared) repositories.

1 Like

This is disappointing and really stupid. Iā€™ve been advocating the use of GitLab for a long time, praised its CI and introduced many people to itā€¦

You either increase the free tier user limit (20-30), introduce a cheaper plan back (3-5$ per user) or we all just move to GitHub.

This is a greedy decision; I understand you were bleeding money with some things offered in the Free SaaS plan but at the same time you forgot that maybe a bit of your popularity was because of your community, because of those small teams using it for free and advocating it to others. That maybe those teams grew or those people moved to bigger companies and convinced everybody to use it too. And letā€™s be sincere, the big bucks do not come from your SaaS solution because that doesnā€™t make any sense for an organisation and you know it ( Workspace | GitLab ) and also because bigger organisations want to keep their data internally and localised where they want.

2 Likes

Thank you for this clear, wise and detailed description of the uncertainties and risks linked to the OpenSource program current conditions.

The ā€œnot commercialā€ clause of the programme is indeed very bad for OpenSource communities, as its definition is approximative and situations can be very diverse and complex, leading to exposure to large financial risks. Any real opensource project has users making some sort of profit from the project, and this is a good thing which should be encouraged and not restricted. It does not mean that there is any organization able to have enough resources to examine legal aspect, sign contracts, and provide funding for new gitlab.com paid plans or opensource programme.

With a 5 users limit on free plans, and the legal risks around the OS program, I currently see no real option on gitlab.com for Opensource projects in the future, which is really sad.

2 Likes