Gitlab removes its 'starter' tier Users must either pay 5x more or lose features
theregister.com
theregister.com
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.
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...
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 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
This 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.
This means they have no doubt in this particular case.
I guess we also can doubtlessly deduce what to think then.
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 :/
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.
(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...)
Isn't travis-ci doing something similar? Eliminating their free tier?
"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?
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.
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.