> Existing customers with up to 25 users can renew for one more year at the existing $4.00 rate, or get a free upgrade to Premium along with a staggered discount at the next renewal: $6.00 on year 1, $9.00 year 2 and $15.00 for year 3.
As I understand it, on-prem requires a license if you want the non-community edition features and the license costs exactly as much as the SaaS version.
The people most annoyed in the last thread were the ones who evangelized GitLab within their companies but hadn't yet convinced the company to pull the plug or transition to a paid plan. They now have egg on their faces as GitLab is no longer a viable option due to pricing.
I worked at a company that only used Gitlab's free tier for production deployments.
But instead of actually paying for their service to resolve various limitations we ran into, my manager decided he "had a bad experience with Gitlab" and so we switched providers.
I honestly don't know what people are thinking using a free tier for some service provider to run their company.
> I honestly don't know what people are thinking using a free tier for some service provider to run their company
Idk, at work we have a pretty big free hosted Gitlab ( across multiple machines and DCs) and there are very little limitations ( which are not worth the price jump from free to pretty expensive)
Yeah that's the bog standard method of moving forward every time something like this happens. never take something away from someone that they are used to... it will only breed resentment. you let them continue on at the old price and if they want xyz new shiny offering that you obviously think is worthwhile because you are charging 4x for it then they will move to the new tier and you are off the grandfather hook for that user. if they stop the service then you are off the hook and they can buy the new tier if they want to resume using the paid service.
edit: it amazes me that companies don't do this time and time again and suffer the negative repercussions of it every time.
They are nice enough to keep pricing for a reasonable amount of time for existing customers but it’s now much more attractive to use alternatives at lower costs.
It is reasonable until corp realizes GitHub might be cheaper. Since the core product is git (ignoring the lock-in with CI/CD and other related GitLab features), organizations with cost constraints could be forced to move and that might be a cause of annoyance.
I do love the product you guys make. And that's why I am so damn disappointed with this decision.
Can you please give me just a single good reason to convince my management why we are now going to spend MORE in this tool than for the full 365 package?
Can you give management a single good reason to waste hours of time migrating away from a working product because you’re disappointed?
If 240 additional bucks a year for a product that continuously moved features from higher to lower tiers for years now is too much for you then maybe you should adjust your expectations towards Enterprise software in general.
Gitlab is a very broad product and not just limited to Enterprise users. Some of us are in startups and others are introducing Gitlab in their companies from the bottom up. For these groups the new pricing is a big setback.
>Can you give management a single good reason to waste hours of time migrating away from a working product because you’re disappointed?
For a 1000 person org the reason is $240k/year. Can pay for a decent number hours of migration especially over an expected 10 year contract duration. And if you happen to need the top tier features than that'd be $1.2million/year in savings.
Github is deeply subsidized by Azure's marketing budget and benefits from larger scale. Gitlab can't compete head-to-head; they'll have to pivot or partner soon.
GitHub was acquired by Microsoft in 2018. Microsoft implemented a more generous free tier in 2020, but even before the acquisition the pricing structure was $7 - $21 per user, per month.
GitLab is now $19 - $99. If I wanted to move my organization to GitLab it would now cost me an additional $78 per user, per month. A total nonstarter, even if I desperately hated GitHub.
I don't understand the suddenness to this maneuver by GitLab. My guess is it is driven by the CI/CD minutes, but they have really thrown out the baby with the bathwater with their pricing structure.
Hasn't Gitlab just been a copying Github machine too from the start? I don't mean to start a fight but I've only ever seen praise from its launch as a wanted competitor, but no one seems to have mentioned the obvious? I know git wasn't invented by Github but from what I remember Github was a pretty clear roadmap for Gitlab.
They may be now but that's not surprising if you have a solid foundation of a highly successful business to copy efficiently and then can allocate more resources to additional features to differentiate?
Prior to the MS acquisition Gitlab had a much better CI story. MS has been grafting all of its DevOps tooling onto Github since the purchase so it is a bit more even now
Their original product was a pretty shameless carbon copy of github even down to the logo.
But their CI and other tools expanding, they seem to have come into their own.
For a few years, it seems like GitHub had completely stagnated and was riddled with politics and infighting. But they seem to have found their momentum again. We might switch back to GitHub because GitLab feels just messy and less polished right now.
Absolutely any feature present in a mainline product that isn't present in a prospective competitor will become a gigantic and unresolvable issue for any detractors.
"gitlab can't X"
"You can just do Y in gitlab to accomplish that, it's fine"
"but it's not X, it can't do X"
If a competing product is anything short of a reskin of whatever the current service, it is unacceptable and unworkable.
Having personally watched this dynamic play out in my co-workers, I don't feel inclined to criticize gitlab for re-implementing lots of github features.
Not really. It was at the beginning when they both only had core features for version control. But, if you compare them today and the last few years, Github is adding features that Gitlab had for a while. Mostly on CI/CD, Security, and Project Management.
Used git lab for the first time today and was shocked at how closely the ui resembled github’s - seemed like the exact same layout with the same buttons and content in the same places
I don’t see that level of carbon copying in Saas very often
It's in alpha (or beta at this point? Either way, point still stands). At some point they will set actual prices but they haven't yet. We won't really be able to compare the two on price until they do.
Been using it since 2016, and I would say the advantages are mostly related to their DevOps features - there are integrations with k8s, SentryIO, and Prometheus to help you with operations.
Their CI/CD pipelines also seem a bit more refined than GitHub actions - maybe it is just a maturity thing though? That could also just be my inexperience with GitHub Actions.
I think there are also some project management differences in how the items are setup. GitLab, at the premium tier, has epics where I believe GitHub doesn't any distinction.
That being said I believe you kind of trade features with GitHub depending on how much you pay for each platform. Both are pretty good products as far as I am concerned.
> Their CI/CD pipelines also seem a bit more refined than GitHub actions - maybe it is just a maturity thing though? That could also just be my inexperience with GitHub Actions.
My experience with CI/CD is that github action's is stellar, while gitlab-ci is a huge mess of features that don't compose well. For instance, in gitlab-ci, you can specify that the job should only run when a specific file changes with `only:rules`, very useful for monorepo setups. Separately, you can specify explicit dependencies in your steps to construct a sort of DAG of your steps with `needs`. Those two features independently work great, but when used together, things become very weird, down to causing YAML parsing errors...
Another similar experience: Child pipelines are a mess. Child pipelines can't depend on the parent steps, can't download artifacts from the parent steps. Similarly, the parent can't access the child pipeline' artifact.
CI has some fun interaction with bot accounts. By fun, I've had MRs started by bot accounts running in weird CI contexts where some environment variables were not set for whatever reason.
Overall, gitlab-ci feels... poor. Github-actions, on the other hand, has been a joy to use, and is a lot less surprising. Most features tend to be thoughtfully designed and work well together. I can't give many examples here as it's hard to point out things that just work, but I've done extensive work with both gitlab-ci and a github actions and I certainly prefer working with github actions any time of day.
Currently a starter tier user with more than 25 users, and I don't know how I feel.
We had been mulling an upgrade to premium, but the price jump is a tough sell for us. This kind of leaves us in an predicament. Will have to see what GitLab can offer us as per their blog post.
Compare/contrast to my former email provider. They gave 1 month notice to some people before almost doubling prices, and others apparently didn’t get any notice at all. Left them for a more expensive service— large and sudden price increases send a message of instability and bait and switch dynamics whether or not it’s actually the case. Gitlab, on the other hand is using a phase in approach. It gives customers time to adjust and prepare. Whereas they could have just hiked prices and exploited customers who didn’t have time to react. Of course you get pricing wrong sometimes (I guess even by 2-5x). But really you have to be careful with how you raise prices. Personally I’d rather have happy customers, although captive ones pay the same.
We're currently using the starter edition for exactly one reason, ldap integration.
Now we're supposed to pay $240 / employee for an ldap integration?!
Not sure what we'll do but I suspect scripting some ldap integration into our gitlab will be one of the best spent times in terms of ROI for me this year.
$240 a year (per engineer) to keep your engineers focusing on providing product value is beyond paying for itself.
Building custom in house tooling always costs 5x more than engineers believe, and ultimately doesn't improve your end product. This kind of tooling would probably require at least 100 engineers to justify the innate cost of building and maintaining it.
At 1000 engineers, that's a fulltime engineer to support the "ldap+gitlab community fork"...
Realistically that takes a lot less than a fulltime engineer to support.
Of course this assumes no other value is acquired from the license, but if we take the comment at face value it seems worthwhile to just add it yourself.
Seems somewhat unethical IMO (admittedly I'm not sure I can fully justify this feeling), and most good software engineers are paid enough to be able to be fairly ethical, but yes.
I guess something about competing with a group of people by using code that they almost exclusively developed feels wrong... but I'm not certain enough on this position to really argue it on the internet.
I don't have a firm answer to this, it's more of a feeling that "this is wrong", but here are some possible arguments. I'm not sure they are the best possible arguments, but they're a quick first pass at making the argument.
It is good for society as a whole if people release their work publicly/open source. People will only release their work publicly/open source if it doesn't substantially hurt their potential earnings. So it's best to avoid taking advantage of publicly released work in ways that hurts their earnings (all else being equal).
Profit should go to the person who did the work making something. In this case gitlab did the work, and the person adding ldap here is almost entirely freeloading off of their work to make a profit. That isn't fair - especially when the freeloader has a direct negative impact on gitlab's earnings.
The person adding ldap support is not doing useful work for society, rather they are just doing busy work to redirect a stream of money towards them, that's not good.
And to add to all of these - the person doing this work is a competent engineer. They have lots of other ways to make money that are perfectly ethical, they do not need to resort to this.
I've written my own gitlab-ldap integration when I was at a startup, done purely with the gitlab API and a cron job. It took me half a day, and didn't have to touch the script for the three years it was in production afterwards.
So, no, this was absolutely productive. This isn't a particularly hard problem to solve.
We have made significant saving on another product by putting a proxy doing Saml authentication in front of the app, rather than paying a crazy price that would have gotten us the Saml. Probably tougher to do for gitlab though.
Not sure if there is any special LDAP functionality, I don't know of, but we use Gitlab CE with LDAP at work. Also looking at the feature comparison [0], I can't find any LDAP related features in the paid versions, that aren't available in the free version. Maybe the feature you are using has been moved to Gitlab CE. Then you can move to the free version.
.. and happily so. We (few) devs like gitlab and it was a relatively cheap way to keep the devs happy. The feel-good factor about giving something back. Now it grows to a number that people will actually notice :/
Note that it's not the basic ldap authentication but ldap group sync and especially admin accounts in our case. Basic ldap auth works on the free plan. (ldap authed users take a subscription seat, which costs $0 on the free plan)
Yep Gitea supports LDAP authentication out of the box. People often self-host Gitea but now there are a bunch of hosted-for-you gitea options like Digital Ocean, Cloudron, Stellarhosted and https://hostedgitea.com (disclaimer: I built hostedgitea.com).
Okay, so I want to give gitlab the benefit of the doubt here. So look:
"GitLab is second only to Microsoft-owned GitHub in this market. GitHub is tough to compete with in part because of Microsoft's financial clout and the fact that GitHub is more a strategic asset to win developers than a profit centre."
Aren't ms kinda dumping the price here. As in selling at loss in order to kill competition. Wouldn't this be illegal in other industries. I get that the open source economy would be a bit confusing at times though.
I don't know. But I am desperate to find a good github alternative, so thanks for the suggestion. But at the same time isn't it quite easy to set up a github server?
> But at the same time isn't it quite easy to set up a github server?
I suspect a typo here - is on premise github a thing? [ed: judging by other comments github enterprise allows self-hosting - but unlike gitlab there's no Free software version]. Fwiw setting up a gitlab server is indeed quite straightforward.
You could look at Gitea. I switched from GitLab and find it’s a better fit for me. GitLab is probably better for large teams, but it’s bloated and overpriced for small developers IMO.
GitHub Enterprise hasn't raised its price since the Microsoft acquisition, it's still $21 per user per month. You get CI minutes now if you keep your repos public, but most enterprises don't. I don't think they are selling at a loss.
> One complication is that GitLab requires that all users in a group are on the same plan
Honestly that really sucks. We are not impacted by the change (we pay for a higher tier), but we have non coders that would benefit from having gitlab access who don't because the price (which would be the same as for devs) makes it not worth it :/
I think it would be interesting if we had a P2P network that was only for Open Source source code, and it would be backed-up on a bunch of servers around the world run by volunteers (to prevent data loss) at regular intervals...
(Note: This idea isn't fully fleshed-out yet. I'm sure that conceptually this idea has or would have a large amount of problems -- but all of those could in theory be solved in time with the correct engineering efforts...)
>The company's pricing handbook states reassuringly that "when in doubt, we will default to moving features to a lower tier" but the effect of the change is that any features in Bronze that are not in the free tier have been moved up.
This means they have no doubt in this particular case.
I guess we also can doubtlessly deduce what to think then.
Hosting it yourself does not give you any extra features. You still need to pay (the same price) for the premium features. The only benefit to self hosting is you have complete control of your data (which is important to some companies)
Reading through the comments on a few of these recent Gitlab posts, the self-hosted option has pricing parity with the SaaS option. I.e. most of the features gated to the $19/month Premium tier for the SaaS are similarly gated in the self-hosted option, and require paying the same $19/month cost in order to activate that extended feature set in self-hosted instances.
There do appear to be some features in the paid SaaS options that are available in the free/core self-hosted software, but I can't find a straightforward breakdown of what those all are.
I'm honestly surprised that GitLab didn't go for a-la-carte pricing where you can choose and pick add-on features as needed. It's what other enterprise SaaS platform with broad offerings seems to do with presumably great success (Okta, JIRA, etc.). I wonder if it's a purely by the numbers business decision or if there's technical/product issues which make that approach difficult for GitLab.
I wonder if Microsoft is going to embed Github into one of their 365 packages. They can offer Office + Teams + Github as one package and it will be impossible for Gitlab to compete for enterprise customers on their managed plans.
111 comments
[ 5.0 ms ] story [ 162 ms ] threadThis seems reasonable...
So it's not like gitlab is completely cutting people out of service.
But instead of actually paying for their service to resolve various limitations we ran into, my manager decided he "had a bad experience with Gitlab" and so we switched providers.
I honestly don't know what people are thinking using a free tier for some service provider to run their company.
We only use the CI/CD feature and host our own runners, free plan serves us well and gitlab.com just works.
Idk, at work we have a pretty big free hosted Gitlab ( across multiple machines and DCs) and there are very little limitations ( which are not worth the price jump from free to pretty expensive)
Reasonable for the user would be to just grandfather them in their current plan.
edit: it amazes me that companies don't do this time and time again and suffer the negative repercussions of it every time.
That is remarkable.
I think the blog post with me as the author https://about.gitlab.com/blog/2021/01/26/new-gitlab-product-... and the FAQ https://about.gitlab.com/pricing/faq-new-product-subscriptio... answer most questions. But happy to answer any other questions.
And a quick search with algolia justifies that : there are very little Gitlab threads where you have been absent.
Because of the expected volume we had a different process for responding on social yesterday and I wasn't part of that group.
Can you please give me just a single good reason to convince my management why we are now going to spend MORE in this tool than for the full 365 package?
If 240 additional bucks a year for a product that continuously moved features from higher to lower tiers for years now is too much for you then maybe you should adjust your expectations towards Enterprise software in general.
For a 1000 person org the reason is $240k/year. Can pay for a decent number hours of migration especially over an expected 10 year contract duration. And if you happen to need the top tier features than that'd be $1.2million/year in savings.
Buried if you will. As if they knew.
GitLab is now $19 - $99. If I wanted to move my organization to GitLab it would now cost me an additional $78 per user, per month. A total nonstarter, even if I desperately hated GitHub.
I don't understand the suddenness to this maneuver by GitLab. My guess is it is driven by the CI/CD minutes, but they have really thrown out the baby with the bathwater with their pricing structure.
But their CI and other tools expanding, they seem to have come into their own.
For a few years, it seems like GitHub had completely stagnated and was riddled with politics and infighting. But they seem to have found their momentum again. We might switch back to GitHub because GitLab feels just messy and less polished right now.
"gitlab can't X"
"You can just do Y in gitlab to accomplish that, it's fine"
"but it's not X, it can't do X"
If a competing product is anything short of a reskin of whatever the current service, it is unacceptable and unworkable.
Having personally watched this dynamic play out in my co-workers, I don't feel inclined to criticize gitlab for re-implementing lots of github features.
I don’t see that level of carbon copying in Saas very often
Their CI/CD pipelines also seem a bit more refined than GitHub actions - maybe it is just a maturity thing though? That could also just be my inexperience with GitHub Actions.
I think there are also some project management differences in how the items are setup. GitLab, at the premium tier, has epics where I believe GitHub doesn't any distinction.
That being said I believe you kind of trade features with GitHub depending on how much you pay for each platform. Both are pretty good products as far as I am concerned.
My experience with CI/CD is that github action's is stellar, while gitlab-ci is a huge mess of features that don't compose well. For instance, in gitlab-ci, you can specify that the job should only run when a specific file changes with `only:rules`, very useful for monorepo setups. Separately, you can specify explicit dependencies in your steps to construct a sort of DAG of your steps with `needs`. Those two features independently work great, but when used together, things become very weird, down to causing YAML parsing errors...
Another similar experience: Child pipelines are a mess. Child pipelines can't depend on the parent steps, can't download artifacts from the parent steps. Similarly, the parent can't access the child pipeline' artifact.
CI has some fun interaction with bot accounts. By fun, I've had MRs started by bot accounts running in weird CI contexts where some environment variables were not set for whatever reason.
Overall, gitlab-ci feels... poor. Github-actions, on the other hand, has been a joy to use, and is a lot less surprising. Most features tend to be thoughtfully designed and work well together. I can't give many examples here as it's hard to point out things that just work, but I've done extensive work with both gitlab-ci and a github actions and I certainly prefer working with github actions any time of day.
GitHub has caught on up on a few things since then.
We had been mulling an upgrade to premium, but the price jump is a tough sell for us. This kind of leaves us in an predicament. Will have to see what GitLab can offer us as per their blog post.
Now we're supposed to pay $240 / employee for an ldap integration?!
Not sure what we'll do but I suspect scripting some ldap integration into our gitlab will be one of the best spent times in terms of ROI for me this year.
Building custom in house tooling always costs 5x more than engineers believe, and ultimately doesn't improve your end product. This kind of tooling would probably require at least 100 engineers to justify the innate cost of building and maintaining it.
ldap integration sounds pretty simple though, so maybe not in this case
Realistically that takes a lot less than a fulltime engineer to support.
Of course this assumes no other value is acquired from the license, but if we take the comment at face value it seems worthwhile to just add it yourself.
It is good for society as a whole if people release their work publicly/open source. People will only release their work publicly/open source if it doesn't substantially hurt their potential earnings. So it's best to avoid taking advantage of publicly released work in ways that hurts their earnings (all else being equal).
Profit should go to the person who did the work making something. In this case gitlab did the work, and the person adding ldap here is almost entirely freeloading off of their work to make a profit. That isn't fair - especially when the freeloader has a direct negative impact on gitlab's earnings.
The person adding ldap support is not doing useful work for society, rather they are just doing busy work to redirect a stream of money towards them, that's not good.
And to add to all of these - the person doing this work is a competent engineer. They have lots of other ways to make money that are perfectly ethical, they do not need to resort to this.
I see opensource project that is missing usefull features and users who need them.
Why is "redirecting stream of money" towards me bad? Maybe I run orphanage and can use money more ethically...
That's a big part of the issue. It's not per engineer, as they don't allow mixing subscription levels.
So it's per everyone that needs some access.
So, no, this was absolutely productive. This isn't a particularly hard problem to solve.
This pretty much guarantees a phone call from your VP Engineering tag-teaming with the CFO.
[0]: https://about.gitlab.com/pricing/gitlab-com/feature-comparis...
[0] https://about.gitlab.com/pricing/
Note that it's not the basic ldap authentication but ldap group sync and especially admin accounts in our case. Basic ldap auth works on the free plan. (ldap authed users take a subscription seat, which costs $0 on the free plan)
"GitLab is second only to Microsoft-owned GitHub in this market. GitHub is tough to compete with in part because of Microsoft's financial clout and the fact that GitHub is more a strategic asset to win developers than a profit centre."
Aren't ms kinda dumping the price here. As in selling at loss in order to kill competition. Wouldn't this be illegal in other industries. I get that the open source economy would be a bit confusing at times though.
I'm unsure of how big the divide on features is.
> But at the same time isn't it quite easy to set up a github server?
I suspect a typo here - is on premise github a thing? [ed: judging by other comments github enterprise allows self-hosting - but unlike gitlab there's no Free software version]. Fwiw setting up a gitlab server is indeed quite straightforward.
Um... this has been MS's modus operandi for decades. Remember how you used to have to pay for Netscape Navigator and then MS gave IE away for free?
Honestly that really sucks. We are not impacted by the change (we pay for a higher tier), but we have non coders that would benefit from having gitlab access who don't because the price (which would be the same as for devs) makes it not worth it :/
https://gitlab.com/gitlab-org/gitlab/-/issues/213185
1. https://gitlab.com/gitlab-org/gitlab/-/issues/2105
(Note: This idea isn't fully fleshed-out yet. I'm sure that conceptually this idea has or would have a large amount of problems -- but all of those could in theory be solved in time with the correct engineering efforts...)
This means they have no doubt in this particular case.
I guess we also can doubtlessly deduce what to think then.
There do appear to be some features in the paid SaaS options that are available in the free/core self-hosted software, but I can't find a straightforward breakdown of what those all are.
"Transparency is one of our core values" - BULLSHIT !!
Isn't travis-ci doing something similar? Eliminating their free tier?