Gitlab pricing used to be something like $4/mo and they saw incredible growth.
They raised their rates to $19/mo and now are seeing slow growth.
In April they are raising to $29/mo- not sure what they think is going to happen.
Also, for anyone that actively watches, they have to wonder if there will be another price hike once you are on their platform.
Github Enterprise is only $21/mo and for most users it has all the same features of Gitlab.
Gitlab's main differentiator for a long time was CI, but now Github has its own equivalent (Actions).
It seems that Gitlab is only going to be left with
1) existing Gitlab users
2) users that want some enterprise feature set that doesn't exist on Github, and want it in a single platform without a third party
At $29 * 7 * 12 per year it became way cheaper for us to just piece together functionality we needed from nginx+cgit+homegrown database to store users/repos/acl/push info and a few git hooks written in a few lines of PHP. The cost is now independent of the number of developers using the system.
So far it did cost ~1 month of paying for github in dev time and I can't imagine it costing much more when we'll want to add some automation on top of the list of accepted pushes/ref updates, for which we did not have a need for so far.
Certainly beats installing 1GiB debian package of selfhosted gitlab and having to figure out why some stupid ruby service is eating increasing amounts of hundreds of MiB of RAM on an empty gitlab instance while doing nothing at all.
That's $2.5k/yr that can be put into something else.
I mean I dislike the gitlab pricing increases, and we are kind of regretting sticking with them (especially since everyone on the Gitlab instance has to pay for a seat, even when not using any of the premium features) considering how Github is cheaper and has a higher release velocity at this point... But to be very fair, we never saw what you describe about memory leaks or slow ruby services. Migrations are also usually silent and done in the background. I guess the software itself is pretty heavy, but predictably so (RAM usage rarely spikes, for example).
We have a 400+ seats instance, with a decade worth of code and it just works 99.99% of the time, and upgrades are generally painless. Though our instance is pretty vanilla, and internal to our corporation. The runners are more finnicky and buggier, especially since we have tons of different build targets but that's besides the point if we are just talking about using it as a dumb git repo. And if you only need it for that purpose why even pay instead of using the community edition?
(I'm in the AI team but I sometimes help the devops team that takes care of the instance to customize our AI pipelines, so I'm familiar with gitlab and with my colleagues experience with it)
The company I'm currently at uses a self hosted instance, which due to our "security"* constraints we're grossly behind in updates. Not to say that's Gitlabs fault at all, but the amount of issues we have near daily is hilarious (if it didn't simultanously crush productivity).
That said, I recall issues with the Gitlab Enterprise Support / whoever we contact about our license etc, mostly to do with slow or poor communication. Requests would sit for a month before we got a reply, often dismissive or generally unhelpful, though we _were_ on an outdated version so I don't blame them.
I vaguely recall an email about support ending on self hosted instances? I can't recall the details, but I know it triggered an internal investigation into moving away from Gitlab. EDIT: Pretty sure I'm remembering self hosted Jira, a quick Google search shows Jira EOL but no Gitlab.
All of that said, I largely blame my company for the failures here. I wouldn't expect any company to support self hosted, outdated versions. The support issues were annoying, but I'm also not sure how much I can blame Gitlab for that. I'm also struggling to remember the details, so take this as one mans hazy annecdote.
* film industry, security by obscurity in the worst ways, leads to incredibly outdated and neglected tech (we only _just_ transitioned to Python3, and that's only the core services)
At least parts of what you say ring true in my experience following GitLab releases more closely (e.g. 1-2 months behind). I would highly recommend not self-hosting if you're going to go with GitLab. Performance issues will appear and disappear between updates, and sometimes on a whim and you're never quite sure what you did or didn't do.
I did find the support staff to be fairly responsive, but most of that time felt like me collecting diagnostic information with little actionable material, and sometimes I would have to explain the same thing multiple times in the same support ticket because it switched hands.
If you do still opt to self-host, dig into their documentation: there are little nuggets and hacks they use internally that you'll want to use to get the right performance out of it.
I absolutely would not opt to self-host, but unfortunately that's not my department. I agree about the performance issues, most of our issues were performance related and did seem quite random (though unsure if that was our self hosted instance or a Gitlab issue, sounds like it could be both).
I will admit I'm probably overly harsh on the support staff, and misrepresenting the support issues we had. I wasn't directly involved in most of it so I'm parroting what I've heard from coworkers that were more involved, which isn't the whole story. Though the times I was directly involved (in support requests) the experience mostly matched yours, with a couple (albeit rare) cases of slow replies.
In terms of self hosting I 100% agree, and anyone who is thinking of setting up their own self hosted instance should take note of your comment.
Self hosting is fine... but only for an internal instance. The release cycle is pretty extreme, with a critical security update seemingly popping up every two weeks. I mean that's better than not patching the issues, but it still means you have to stay on top of it. Having an internal/private network instance doesn't actually help you all that much, but it still gives you a little more breathing room.
(and I know it might contradict my earlier comment saying that Github's release velocity is a plus, but it doesn't. Most gitlab releases don't introduce useful features, they mostly patch security issues and regressions. For example, the Runners are in a dire need of tons of features and an outright rework of some parts, but barely get any. Which is sad since they were so far ahead of the competition not so long ago.)
> The release cycle is pretty extreme, with a critical security update seemingly popping up every two weeks.
That just reminded me of my least favorite thing about their releases: they brag about releasig on time for however many months in a row, but they're always quickly followed up with bug and security fixes. I felt their presentation of consistency was misleading at best.
My bad experience was mostly just with installing gitlab on a 1GiB RAM VM, to see how it will fare and how easy it is to manage. I expect it to work for people who don't mind throwing a 16GiB+ RAM machine at it. But our dataset is currently like ~200 MiB and simple relatively dumb git hosting just works much better in our case.
GitLab should run fine on a machine with 4GB memory - this is the smallest recommended memory allocation, spec'd for up to 500 users. 2GB tends to work okay for testing but 1GB is indeed probably too small for all of the services to start. Postgres actually tends to be the long pole in the tent on small systems.
Sorry, but the recommended system requirements are an absolute joke. They might be OK if you really only do pure code hosting and don't use CI, container/package registries, project planning features and whatnot, but on our instance with 400 users, the sidekiq background jobs alone easily eat 12GB RAM (I had to extend sidekiq to 4 processes just to deal with the load, otherwise GitLab would become unresponsive).
The problem with a homegrown system is that every developer working within it will see it as a barrier rather than a cost saving. Whenever they can't do something that's trivial on Github/Gitlab it'll be a reminder that the company would rather save $xxx/year than make their job easier.
Ultimately, having a simple, well-integrated, industry standard stack that includes the same tooling every other company uses is a perk of working at a well-funded or profitable company. People leave for less.
Every morning we begin stand-up with a ritual, our whole team simultaneously muttering something arcane whilst manipulating the inner workings of Teams, hoping to appease the MS gods.
Shortly after the ritual is complete you hear a cacophony of "fucking teams wouldn't find my headset/camera", and the day begins.
Your team should have a strict policy to not do ANY work at all each day until the stand-up is complete, and not to do the stand-up until Teams is working correctly for every team member, no matter how long this takes.
Gotta love HN math. Calculations to two decimal places, starting with a number plucked from the high end of a distribution with standard deviation of at least 100K.
don't forget benefits, hardware, support staff portion, and possibly office. We typically calculate 50% over... so that's 120k at a likely low end.
we run ghe at work and I know we spend 8 hours 4+ times a year for a test upgrade and then an upgrade from an eng that makes above either of your estimates in salary alone.
None of this includes all the work we're not doing to build new integrations or features in the ci system that we get for pay for the product. But we're not a scrappy startup either. We're paying down much of the tech debt from being a scrappy startup, it's not been cheap.
Even if you throw out SF salaries as a wild outlier, this isn't actually that ridiculous. An average quality mid-career dev (5-10 years exp.) in a second tier market like Chicago/Denver/Austin/Boston can pretty easily make 170-200 in cash. "[A]ll up" is the key here tho; there's a big non-salary component in the US that doesn't exist in Europe. Tack on health insurance and the total cost to the company will easily blow past 250 right there. Plus, you're probably giving them some equity and a yearly bonus.
I'll be honest, it does sometimes blow my mind to see how low salaries are over there when I look at job postings and Who's Hiring and the like. I'm jealous of a lot of things Europeans take for granted, but it's wild to me to see senior positions in major European capitals paying the amount that I made two years out of a bootcamp.
Thing is, even in those 2nd tier markets, you're still looking more towards the top. I say this as someone having spreadsheets "I shouldn't have" from folks towards the top of acquisitions into larger companies that do pay well. Companies you've at least heard of, but certainly aren't disrupting a market. No, they're not the ones at the top of your list, but a fair number you'd consider respectable.
There's a lot of companies paying 2/3rds of that cash.
Then there's the bad ones, that are still trying to pay half. Seriously. They're not places you even realize exist, and if you went in for an interview you'd instantly sense you're not where you want to be. Places where you watch managers basically bully interviewees to look for immediate subservience, because they want to ensure they'll "yessir" without hesitation. These places absolutely exist. In all of those markets. I've seen quite a number of them.
-- -----
I know, this isn't what we all try to aspire to here, but I say this as someone with far too much experience with Boston (very specifically), Denver and Austin over the past 20+ years. I've had the "good but not amazing" and many "bad" companies as clients of mine. I've talked to their staff. I've done my damnedest to ensure the good eggs know where they stand in the market, and help them move on if they wanted to.
HN very much looks at 75th percentile on up. But once you go down the ladder in the compensation offered, you'll encounter a ton of people where $170-200K salary or salary+bonus would be a 20-30% bump in their comp in those markets. Then you get to the bad places, where they're legit making half and feel thankful for it.
US salaries don’t include employer payroll taxes, unemployment insurance, health insurance, retirement matching, etc. Total cost can easily be 2x advertised salary.
Yes. In Germany, if you are a good earner, you pay 42% taxes, plus obligatory healthcare about 900EUR/month, pension fund and unemployment insurance (also all obligatory). So if you earn 100k (which is already a high salary in Germany), you usually end up with less than half net. I know this sounds crazy to US citizens, but this system comes with several advantages which I wouldn't want to miss.
To be honest, I feel Europeans are simply being underpaid compared to US FAANG salaries. Not necessarily compared to EU FAANG salaries as they are lower and even if that's case, it's not glaringly obvious (to me at least).
I think the point is too many times developers are a penny wise and a pound foolish when it comes to build vs buy. Because they can build, and it is often fun if you haven't done it before.
Though I often don't take my own advice, I try to ask is what I'm about to build core to our ROI/product, is there an existing solution that gets us 80% there, and yes, what is the cost.
If it is not core to the business, won't drive revenue, and cost are not outrageous, which is a company by company truth, then I much prefer to spend X time building new product than recreating an existing product/tool.
One final point - don't forget to consider the maintenance costs, which in the long term often greater then the initial investment. If your CI goes down, you just blew away and savings you were planning on.
There are also maintenance costs with the off the shelf solutions. E.g. Gitlab self-hosted runners don’t handle very large artifacts well and frequently caused CI to timeout. We had to roll our own artifact management system.
In general I agree with you off-the-shelf is usually better but sometimes a custom tailored solution rather than a generic system can be better.
That's about ~1-2 hours a year and already has to be done, because that VM has been used to run other dev services. Also with simple solutions, the benefit is that there's usually nothing to debug. It just works.
And the cost of that has to be compared to cost of gitlab subscription and other gitlab related headaches.
… sometimes, I do think it's merited. We switched to Github Actions for our CI and it's been … mixed. It was a hell of a lot of work to switch (GHA is significantly different than what we were moving from and … buggy) and even then, some of the pricing on GHA high. 24¢/GiB/mo for storage[1] which is like 8×? 10×? the sort of cloud baseline, 50¢/GiB data transfer [2], and the runners are similarly costly, IMO. I'm not sure if GHA wins out, in part because we're not done switching.
You can do self-hosted runners aaaand… welcome to infra/ops?
A little NIH syndrome would do the industry good. We need more stuff invented. The current stuff is mediocre.
Yes, but all we used gitlab for was git repo hosting with push access control for about 40 repositories to allow sharing code via push/pull and not much else (almost no issues/pull requests). It's ridiculous to pay $2500/yr so that 7 people can do push/pull over slow growing set of ~200MiB of data when it can be handled in much more performant way by a 36$/yr (+ a small one time setup cost) VM we already had for running other things.
Running gitlab yourself is just too expensive. Too many docs to read, hard to understand, just too much software in general (just compressed deb package alone is 1GiB in size), hard to backup, hard to debug issues, would require a new separate much more expensive VM, etc. It does weird shit during installation, like contacting letsencrypt and trying to fetch a certificate and failing if the machine is IPv6 only, etc. etc. Recovering from that is not documented anywhere. Too many moving parts. Just sort of blergh for people who like simple solutions.
It doesn't sound like a 1-2hr/year self support software.
Gitlab is massive piece of software, and has inordinate HW requirements for the job we'd be using it for. Also it would not run on the VM we already have set up for other services, backed up, etc.
Gitea is fun and all, but it's not in debian repo, so would require manual updates. Annoying.
I reckon their growth was mostly killed by Microsoft purchasing GitHub and making private repositories free. Most of the open source community seem to be on GitHub anyway so it just removed any incitament for average people to join Gitlab. Once you're invested in one environment it takes something special to move.
This. A while ago Gitlab was really the better option: mostly free and more features (CI, project management...). Github caught up on features and price so why bother going against the network effect when the alternative is not even better?
- Github Action's design is much better, just look at [1] for example, there's a lot of low-hanging fruit in Gitlab that's not done for some reason
- I've had tons of issues with their kubernetes runners, hard to debug spurious system failures
- They still don't display the last N bytes of the logs when logs get long, just the first N bytes, which is entirely useless when a build fails
- It's awfully slow to navigate through pipelines, in particular child pipelines
- The `stages` things is just useless noise, I just wanna specify dependencies please, I don't want to be forced to also put each job in a stage, it's weird.
- You can't expose a secret only to a single job step; they don't really have finer granularity for job steps like Github Actions has -- they just generate a script.sh that's executed directly.
- Github has many more reusable actions from the community, I don't think Gitlab has that at all? At least not in a convenient way.
> Github has many more reusable actions from the community, I don't think Gitlab has that at all? At least not in a convenient way.
This is the big one.
Github’s ability and dominance in the social space means they have the most active actions ecosystems.
They made actions easier to import share and built marketplaces and now gobs of developers build value into it just for clout (and because they enjoy software of course).
If you think about it carefully, it’s actually a security nightmare. You have no idea what a random Github action you “uses:”d is doing, but in practice 90%+ of the time it doesn’t matter, you get good functionality and save time for free.
YES! We are getting awfully tempted to move at least my AI team to Github. We don't want to dedicate someone to figure out CI/CD/MLops pipelines, which would mostly amount to translating existing, published, official github action pipelines to something that can work on Gitlab. Our devops teams can help, but when in our case we need a pretty domain specific pipeline setup. Most of the pipeline related docs for Azure ML, for example, is based around very extensive github actions templates. It would take minutes to just deploy it there.
I mean in this particular case, it's unfair since microsoft would obviously favor github. But it's not like there's a marketplace where a community made version could be used as a replacement...
> The `stages` things is just useless noise, I just wanna specify dependencies please, I don't want to be forced to also put each job in a stage, it's weird.
You don't have to. GitLab supports dependencies. Using the `needs:` keyword.
> The `stages` things is just useless noise, I just wanna specify dependencies please, I don't want to be forced to also put each job in a stage, it's weird.
I think there a few things like this in GitLab (like the ability to run pipelines against both commits and pull requests) - GitLab give you a lot of flexibility... but so far it's all just been extra bother to deal with.
I disagree. Actions is really nice and I don’t have to set up and debug runners. In GitHub, I can have dedicated runners if I want, but99% of the time, I just use vanilla Ubuntu runners.
My fear though is that GitHub will Jack up their prices once I’m running everything. Right now they give 50k minutes per month, but that could change at any point. GitHub enterprise started out at $8/month and now it’s $20+.
> Github Enterprise is only $21/mo and for most users it has all the same features of Gitlab.
Of those things that I like more in Gitlab, it is deploy tokens: an easy way to be able to dole out permission to clone code where needed without having to bother with key management or user management. As far as I can tell GitHub has something like this but it requires setting up an app to talk to the API and isn’t nearly simple as the button available in Gitlab.
Not sure what you mean. Adding a deploy key is about as simple as I can imagine, definitely doesn’t require messing with apps, which I agree is a pain.
That's a different thing. Here's some info on deploy tokens: https://docs.gitlab.com/ee/user/project/deploy_tokens/. It's a one-off username+password pair that can be used for HTTP cloning without setting up SSH keys or creating users. As far as I can tell in Github you use either automatic tokens[1] or personal tokens[2]. Personal tokens look easier to set up, but they are tied to a user and not the repo or organization, which isn't great if you're using this for a company—you have to create a whole separate token user if you don't want it tied to someone's personal account. Automatic tokens require a script to manage.
As nice as this one feature of Gitlab is it is not a major show-stopper. Almost everything we need is available in most git services. So to GGP's point: we are likely to go for the most affordable option even if there's some tradeoffs.
It adds up. 29$ for GitHub, 19$ for GitHub Copilot, 20$ for ChatGPT Plus, a few codespaces and runners, perhaps 7.5$ for the sadomasochist project managers who wants Jira, and you may get a nice bill at the end of the month.
And then you have people like GitKrakken who ask 19$ for a git client, or Teleport who ask 36$ for a ssh client.
It does, but you have to associate these cost as part of the employee expense and not a separate budget line item. An extra $100 / month for tools needed by somebody being paid $5,000+ / month is nothing.
In my previous organisation $19/month (IIRC) was a dealbreaker. That was non-US so salaries are lower, and suddenly I had to explain why we absolutely needed the paid version so much (instead of sticking to the free one). To make it worse, most of the people that had access to gitlab were researchers/managers/non-technical people and not actually developers, so only a few people would benefit from the paid version. So we never bought the paid version.
> It seems that Gitlab is only going to be left with 1) existing Gitlab users 2) users that want some enterprise feature set that doesn't exist on Github, and want it in a single platform without a third party
Add in 3) people who want a reasonable option to self-host that's not charging you to oblivion.
GitLab Auto DevOps and (now) GitLab Ultimate are definitely compelling differentiators that Github doesn't currently have, but I can't see Github just _not_ responding to that in a big way.
The problem with these SaaS companies is that they all eventually become seduced into whale hunting (big enterprise) and the product ultimately suffers as they are forced to adopt whale pricing and focus on endless enterprise reqs that the whales say they want (and most of the time don't actually use). The product drifts or stagnates for their core use case and then another startup comes along to 'disrupt' the market and they do until the process repeats.
Here's their operating margin for the last 4 quarters:
Q1: -49%
Q2: -65%
Q3: -50%
Q4: -38%
So what you want is a business model where the company runs purely on VC money instead of on actual profit. SaaS companies like Gitlab usually can't operate at a profit with only free-tier and cheap-tier users - their overhead is way too high. Those tiers are a gateway drug offered at a loss to get people on board so that eventually the actually-profitable enterprise accounts will stack up enough to make up the loss. It's kind of a standard bait-and-switch pushed by the whole VC model. I'm personally hoping we see less of it now that the money spigot is drying up.
“Here is how platforms die: first, they are good to their users; then they abuse their users to make things better for their business customers; finally, they abuse those business customers to claw back all the value for themselves. Then, they die.”
I'm annoyed that they don't want my money. I'm a really basic user and try to keep my private and public stuff there instead of GitHub. I fit in a free tier and would happily pay maybe $5 for it. But I wasn't going to spend $20 and definitely won't spend $30.
Come on GitLab, I want to keep using you and see you succeed. Let me pay $5 for some token feature like extra GB of space and to vote with my money to keep you going. I'll even do it for a "supporter" badge on my profile.
This logic is simply not how you get money from ordinary consumers. If someone wants to support you at a level of $X for a service they're already getting for free, saying 'just give us $X*5' is not the right move.
I recently watched a video game community melt down because (due to exchange rate shenanigans) the pricing of a monthly pass was $5.99 instead of $4.99, and people got furious when (a non-employee) moderator said the equivalent of 'you don't have one dollar?'
It was bad enough that the developers laid off all the discord moderators and made a public apology, but they didn't say how many people chose not to renew their monthly passes.
This really misses the mark. They compete with free also, which is always nothing.
Github by comparison lets me pay like 5$/mo for LFS and 4$/mo for a team of one, bitbucket even lets you do up to 5 users for a total of 15$/mo , gitlab has nothing like that :(
I feel your pain, we all get used to super cheap development services. But now - well - there is no free lunch as they say, and I think we should stop demanding much for nothing.
Would they make money on $5 accounts? Does github make money on $4 accounts? Is it a sustainable pricing model or more like a “growth grab” which is not valued that much in 2023.
One thing I think is underrated is convincing students/hobbyists/personal users who then take those preferences/skills into the work place, that funnel seems especially useful when it comes to tooling. Gitlab seems to be missing that price point/market
I find it a mixture of frustrating and amusing the services (and software) that sell enterprise level packages but won't accept anything more than "free" from me either personally or my (tiny) business. I don't even need support - I just want to provide support. Just stick a Stripe charge form on there and say "best effort tech support" or even "no private support / forum only" and take my money damn it. :)
It's not necessarily about whether they're actually making money on those as opposed to covering their costs. Almost any successful company based around open source software (and often closed source) has a huge spread of customers sizes from the hobbyist who plays around with a few things all the way to Fortune 500 enterprises. By having a ramp up in terms of pricing it keeps folks invested in your platform. In cases where there's a big jump there's often quite a bit of hesitance to upgrade unless there's an overwhelming need.
Basically, it's aligning the success of your business to the success of your users. Most of what's offered in Gitlab Premium[1] would be of little value for a small development shop, yet if you have 5 users you're looking at $1000/yr for features that are unlikely to be used. It just doesn't make sense.
Too many things in Gitlab feel half-baked, like their requirements feature which is essentially just their issue tracker, no document management, just toss some issues in the bin. And they expect enterprises to pay for it because they checked the feature box.
I've had a good experience using GitLab for source code repositories, pipelines, and code reviews. I don't have much experience using it for issue tracking and document management since we use Jira & Confluence for that. For my own hobby projects outside of work the free tier has been great, and it was easy to host my own gitlab runner so that I don't have to pay for CI/CD minutes.
PR review UI seems very bad to me compared to both github and bit bucket. So it's probably a matter of what you got used to first.
One of its major issues is not displaying merge conflicts in some scenarios, just tells you of the existence of a conflict and you need to figure it out outside the UI.
Even though features are half-baked I still think the future is bright for them, especially if GitHub slips up or gets complacent. Intel showed us that it is possible.
Gitlab has been cursed by a marketing team that seemingly just can't imagine having mixed licensing levels. At a side effect, organizations that would adopt them at the low (free) tier (or just above) for the whole company, a higher tier for devs, and max tier for project management, etc, just can't. Instead they have to have separate gitlabs to cover the whole organization, which has a whole set of associated annoyances.
I speak from direct experience, at a company that had the mid level, liked the features, but was forced to eventually jettison them for the free tier to cut costs while broadening internal support.
And we reported this problem to them, this basic lack of a mixed tier system, something many customers want. But Gitlab can't seem to get it through marketing's head that being nearly everywhere is better than just running for few large companies. Running everywhere means that many devs would just bring along an expectation of having gitlab as a matter of course, spreading adoption like a beneficial contagion. Instead, any useful level is being priced into irrelevance from a smaller organization's perspective, something many devs will see at prohibitively expensive, and be the fomites for that perspective instead as they move between companies.
The result is terrible. Our company switched to Git on Microsoft Azure. Good job, Gitlab sales (heavy sarcasm). Hey, Gitlab management, have you checked to make sure your sales team isn't secretly taking kickbacks from Microsoft? (yes, I'm probably kidding, right?)...
What are you expecting someone with cancer to do? Sit in a room and do nothing forever? How do you think that's going to go for the business? You should be asking yourself these kinds of questions well before you think about speaking. You're commenting on a situation you're not involved in, and speaking out of ignorance.
hey, please have some tact. sid is a very active part of our community and almost certainly reading this post. dont say anything here you wouldnt say to a friend's face especially in his time of vulnerability.
It may just be me, but that sounds like something a friend would say? It’s not exactly a secret that you’ve made it, nor is it controversial that cancer sucks.
I didn't mean that in any sort of bad way. I'm sorry it was taken that way. It's just that it seems like incredibly bad luck to have "made it" on a level that most people can't imagine, and then you are struck with a serious illness like this.
As much as I love the product, I've really come to dislike Gitlab as a company. The constant price hikes and the gutting of the free tier aren't exactly developer-friendly.
I had a strange interaction with one of their sales people a few weeks ago.
We have a free premium open source developer account, plus Red Hat runs all the CentOS infra through gitlab and pays a ton of money to them. I received emails from a salesperson demanding that I book an appointment with them to discuss my account. (It sounded like a meeting which had real this could be done by email energy, or else was going to be a high-pressure sales pitch.)
I asked them which account they were talking about and if we could do this on email, but they literally wouldn't say what account it was related to, and just kept saying I must visit some (non-gitlab) site to book this appointment for a video call.
After several rounds of this and following up with someone who works with gitlab to check it wasn't an actual scam (it wasn't), I just ignored the guy.
Conclusion is they sounded desperate to make the numbers last quarter.
It feels like they've moved into the extract value phase for sure, maybe a bit forced by github actions removing their USP. I'm still using them for now, but I feel the day I move back to Github for the higher profile or self-hosted gitea/forgejo for the data control is coming.
It is especially annoying because of how transparent they are about it. You can follow along in merge requests and issues as they discuss exactly this.
Tbf 99% of other companies are still doing that, just not in the open.
It's a business, their goal is to make money. I kind of like that they're willing to let everyone see into the nitty gritty details of how they do that.
Yeah same here. Having to go to an Enterprise level to get free guest users is absurd, they've really stopped listening about product feedback, and the pricing model makes no sense...
As a user who really liked GitLab, there are a few things that made me consider to move back to GitHub:
1. They had a generous organization free tier, which was handy for stealthily moving companies to it (move a few repos, get people used to it, then move more repos, then when everyone recognizes the value, start paying). They ruined that as soon as they put a limit on the number of people that can be in an org for free. Moving stealthily was good because...
2. GitLab CI was best-of-breed, but GitHub Actions is really good too now (maybe better? I haven't used it enough to answer that).
3. The price is really high now, so it doesn't really make sense to even move a company over to it.
4. The community is (and has always been) on GitHub, so there was always a big reason to be there. Now that the rest of the GitLab offerings aren't as competitive, this wins.
I like the product - been selfhosting it for years...but frankly the complete absence of a hobby level tier between 0 and 29 makes it a non-starter for me as a managed solution
It just doesn't produce 29 worth value for me pm. Probably does for a corporate user though so i can see why they're doing it
What happened to Gitlab? They used to be one step ahead of Github in some areas, then seemed to go full enterprisey and lost their competitive edge. I smell some sales oriented strategies.
You made me curious and I checked their financial report.
Gitlab spent 310M of their total 580M$ of operational costs in sales in 2022.
Those seem crazy numbers, I see similar ratios in other financial reports (such as Cloudflare's).
On one side it means that those companies are essentially cash positive the moment they cut sales expenses, on the other hand GitLab imho does not provide enough over some competitors such as GitHub to make me bet on them 10 years from now.
Without knowing anything my guess is that they give big discounts to large accounts and write that off as sales/marketing cost. Only that it doesn't work because if you don't give me that price again I'll just pull the plug.
I think it's a consequence of going public. Enterprise is where the money is at, and public companies have huge amounts of pressure to chase the money. I have a lot of love for GitLab, so I hope the strategy works and they can reinvest profits into making the product better for all developers, not just enterprise, but at this stage of their lifecycle it seems this is the strategy they have to play.
TBF, I don't think Gitlab was ever ahead of, or even close to, GitHub. They got a lot of hype here a couple years ago when everyone decided they hated GitHub now because boo Microsoft, but that didn't mean GL was an actual competitor. People who migrated on hype got burned.
When was GitLab ahead of GitHub? I've been using both for as long as I remember, I always thought GitLab is more marketing than GitHub. Believe or not, I prefer BitBucket because I don't care much for CI integrations.
While you might not value it, GitLab’s CI story was for a long time way better than GitHub and even a number of dedicated CI/CD providers. If you want to build and deploy microservices from a monorepo independently based on what changed in a PR, for instance, then GitLab supports that out of the box whereas you need to hack something together yourself on Buildkite.
GitHub actions has significantly reduced the gap, and at least for me that was GitLab’s killer feature.
Meh, there is something to be said for having "anything" over "nothing", but as with many of GitLab features, you inevitably found yourself deep down some years old issue of theirs to find why something is broken or obviously nonsensical. That's before they went batshit insane on development of even more unfinished stuff, while the core ergonomics (Lint CI button anyone?) continue to border on unusable.
Ironically GitHub actions are now the vastly superior experience, despite the lack of bullshit checkbox features. Turns out you don't need so many of them beyond the basic "run something on a worker" flow.
Ah, I see. I never bother with CI features. I was playing with all the CI providers when they came out. Never truly got comfortable with them to run my personal projects. At work, we can't use those anyway.
There was a tiny period where github was a bit stagnant and gitlab felt more capable. Felt a bit like mysql vs postgres. Now I think github got the lead back (slightly simpler UI/workflow). But i don't know much.
Yeah that was before Microsoft bought GitHub. GH had been constantly exceeding expectations and GitLab trying to play catch up (which smells of bad product strategy).
Sad to see. We really loved gitlab, but the pricing was so horrendous for what we were using and couldn't be scaled to non-tech employees (e.g. wiki or just reading MRs), so moved to github and haven't looked back.
Interestingly gitlab pricing influenced us to rethink our own pricing and we spent a month building out granular permission controls to allow sales to craft licenses bespoke to a
client needs and charge less.
After a year our revenue has 2x and there's a nice upsell flow towards enterprise.
Instead of Gitlab actually attracting more customers, they're trying to extract more money from their existing customers. This never ever goes well. Why can CEOs not see this.
I'm moving to GitHub.
I've always championed the small guy, but the last couple of years have been terrible for Gitlab users.
I wish that were true but Oracle, Cisco, PayPal etc all seem to have succeeded in pivoting to more extractive business models over growth. At least in terms of earnings.
It's hard to blame them for every specific bug. It might be incredibly important to you, but not to others, and there's probably another showstopper bug for someone else that isn't important for you in return.
True, but at the same time built-in CI with your own agents was an area where they had a significant advantage over Github the fact it would routinely fail during evaluation has killed any prospect of Github to Gitlab migrations at at least 2 orgs I was involved with.
> It might be incredibly important to you, but not to others, and there's probably another showstopper bug for someone else that isn't important for you in return.
Yes, but that's not a good thing; IMO they've hit the point where they're dying by papercuts. If one user in a million has a completely awful show stopper bug, the product/business will probably be fine. If one in ten users has a fairly serious bug, they're in a bad spot. Obviously they're not at either of those extremes.... but I think they're closer to the latter than the former.
This is true of every large piece of software though. Pretty much every piece of software I use in anger has absolute showstopper bugs, but the alternative isn't betterm it's different.
Gitlab fell off once they went public, now it's shareholder value instead of ... developer value? They are also laughably slow at implementing features that have been readily available in competing products if you look at their issues page.
things like github and gitlab always struck me as oddities. it costs virtually nothing to deploy a containerized gitea and jenkins, or gitlab CE, and you have direct control over its performance and options without any spend.
call me old fashioned but these online git-o-matic sites just seem more like rent-seeking during a recession.
It seems that most of those concerns are not alleviated by using GitHub or GitLab SaaS: "figure out the software you want to use" (you still have to choose the platform), "figure out authentication" (you still have to link your SSO with the platform), "continuous integration systems (...) or production servers that pull from your Git repos, you're going to need to figure out how to connect all of this to the Git server" (you still have to do this), "Git version compatibility" (still a concern, unless you only write code from a browser).
I might be extremely naive in thinking this, but all the listed concerns on that blog post seem rather straightforward to account for. Is there a hidden complexity that I'm just not seeing?
There's always opportunity costs. What about regular maintenance and updates? What happens when a bug appears? What if the disk is full?
Working 50% freelance and 50% revenue-generating niche side-project, I always calculate my time costs. Assuming I earn $80 an hour as a freelancer and a hosted git costing $10 a month, if I estimate I will need an additional 15mins a month if I go self-hosted, then I'll pay for the hosted version.
I've seen enough projects, where they decided to self-host gitlab, only to have issues like disk full, updates needed, deployments not initiating.
When suddenly a team of 10 can't push or deploy for a day, there's additional costs there as well.
If you already have people maintaining self-hosted or cloud environments, adding GitLab to the mix would not cost anything extra. We self-hosted GitLab instance for many years at my previous job and after plugging it into monitoring/backup systems it was extremely low maintenance. Even updates were painless.
The first startup I joined, which was 12 people 20 years ago, had our own servers and an IT guy who took the alternate backup tapes home personally. When you have that, running as many services as possible locally, instead of paying for them, makes sense as you are increasing the value you get out of your operational capacity.
I now work in a start-up of 40 people, we don't have any servers or dedicated IT or DevOps staff. All admin gets done in the spare time of a couple of engineers, who have no desire to further lose their development time to admin/ops. It makes more sense to pay a subscription and let someone else deal with it. Even for the backend guys running that kind of service is more operationally complex than most of what they do - no-one has the experience of operating 'pets' class servers.
This comment strikes me as fundamentally misunderstanding the purpose of GitHub. I don't care that I can set up Gitea (and I already have an instance), I want GitHub because it makes it trivial for people to issue PRs to my code.
Then, because everyone has a GitHub account and knows how to use it, and everyone is already on it, everyone else goes on it too.
Not to mention that I don't need to maintain CI/container registries/asset hosts/pages myself.
There was an attempt to bring a distributed forge architecture to gitea and co. The idea being the project could be hosted on one instance but you could fork to your own to do your work before PRing back to the project.
Github but bring your own.
I believe the project died out but it was a good idea. All the benefits of Github without the lock in and single point of failure.
Git already has a distributed workflow for submitting patches: email[1].
Ultimately a "pull request" is just that; a request for someone to pull your branch into theirs. You can already add Git remotes from different services, review the changes locally, and collaborate over email. GitHub et al simply add a nicer UI for this, but there's no reason why you couldn't make a PR from one service to another. If only they'd be willing to interoperate, which is the biggest hurdle.
I'm not familiar with why that Gitea project failed, but I imagine that making this work for multiple instances of a single OSS project would be much easier.
It looks like gitea supports running a proc_receive hook which can be used to implement pull requests over git:// using a client like https://git-repo.info/en/
(full disclosure) I had written a proof of concept implementation that allows you to use the git-repo.info client to send PRs over git protocol, which you can find here https://github.com/pullreqr/pullreqr_githook
The primary impediment seems partially to be social/coordination where distributed git requires clients to be set up apriori, but it does work in cases where you are using it in house, etc.
I'd kind of be happy to spend more time on it, but with no one actually running the protocol publicly, there is no one to send/receive PRs to or from.
This is important, but also, “virtually nothing” is a lie. I think self hosting can work, but you have to be honest about the costs. Deployment, maintenance, rotating logs, training others on all this.
I think Github knows that and that's why it's turned into more of a "Social Media" site. Jr Dev's grind it and view it as a gateway to a job. Constant memes about "Green boxes". "Only want my Sr Dev's to have full green!111!!". In reality nobody cares, but you can tell that's how the marketing is going. And it's to the point that if I have a public product, I might as well put it on github and get that stuff for free. Even though I do run gitea in a docker container for 99% of my projects offline.
This - I had to move to GitLab from GitHub recently and getting all the tests to run with the new agents was 99% of my time. Pushing a git repo to a new remote is nothing.
That's because current CI platforms are the new lock-in. If you'd go the otherway around it'd cost you the same amount of time. It's a horrible abstraction layer.
Yeah I try and keep my stuff to depending on the bare miniumum i.e. bash/Docker/etc (jq and maybe Python) but invariably there is something that needs to change.
I made a garbage tool to pull repositories from gitlab to github or vice versa. I used it just to explore Go so it's not really prod ready but handy if you're just looking to move your code over.
We were allured to Gitlab as a total offering: code repo, issue and project management, auto devops.
We were developers trying to do everything then we hired project managers who wanted JIRA.
Then we outgrew autodevops and lately it just feels like Gitlab aren't aligned with our requirements at all.
We're paying $19/user/mo for 36 users and just to get status checks for screenshot regression testing we need to upgrade to $99/user/mo?
To get that with github and much more we can pay $24/user/mo.
It's always felt like they're trying to spread themselves too thin and add a billion half features. Like monitoring our GKE cluster from within Gitlab... Why wouldn't I just look at GCP when it's a billion times better and actually works
Personally I only care about GitLab because its open source with a good CI and because of Copilot.
If the supreme court says the copilot is fully legal, I would probably just revert to using Github for personal projects(their free tier is just unbeatable), i still use it more than anything else, because everything is on Github.
I am excited about Gitea Actions[1], as I feel gitea is generally only missing a decent CI system, and codeberg is growing fast.
What's your preferred CI/CD system to pair with Gitea? I tried Drone once and found the configuration to be nasty, specifically OAuth2 under Docker Compose. Also the Drone UI left a lot to be desired. This was a while ago so grain of salt etc.
I really like GitLab the product, and am part of their Hero and Core teams, however, the recent changes and changes pricing adjustments have me doubting if I can continue supporting them.
At work we use their hosted ultimate plan and we were looking to move to their premium but might instead go straight to a self hosted CE instance instead since there is nothing between free and $29/user/month (which is actually $348/user/year because they don't support monthly payments) and the free hosted plan is so crazy restricted.
* Fire the monetization team (yes this is a thing they have) and most of the sales team to reduce cost and hyperfocus on revenue
* Go back to implementing user requests
* Fixed the missed up pricing model, including guest accounts
* Stop releasing half-baked features like the recent subtask debacle
Contrary to the common opinion here, I've really enjoyed using GitLab and don't see many problems with it.
Lot of the comments here complaining about pricing. Please remember that GitLab's core is open source. If you think the managed offering is too expensive, just host an instance yourself. This is what I have been doing at home for years, and my company at work for even longer.
I think the main reason why I dislike the pricing is that there's no way to buy seats with different premium tiers. I'm sure they've done the maths, but it's a very hard sell to just upgrade from the community edition, knowing that you'll have to now restrict the instance knowing that even a casual user (marketing, sys.engineers, mech engineers, etc) will cost the same price...when that limitation just doesn't exist if you don't pay anything at all! It's just counterintuitive.
Good luck trying to get buy in for the Ultimate tier (1200$ per year vs 300$ for the normal paid tier) when only a few users need or use the improved reporting/security featuresEven if it's not a huge cost per se, it makes most premium features a lot less attractive. And remember, you can self host Github Enterprise for a lot less than Gitlab now.
Again, I'm convinced they know how to price their product a lot better than us, but as an enduser, it's a bummer. Because Gitlab is still an amazing product, if just for their open source core alone. So I really hope they figure out a way to be sustainable.
My small company pays for GitLab and I don't see the bill directly, but I definitely have enjoyed working with GitLab. GitHub actions may be catching up but GitLab ci/cd tools have worked great for a while now for us.
I assume that commenter is referring to Gitlab's famous advocacy for remote-only work. But, it's still completely irrelevant to their earnings forecast or stock price.
I think GP was referring to Gitlab itself being very vocal about fully remote. Without commenting on anything else in this thread, their company handbook[1] and the culture around it are something I find pretty interesting.
Github Enterprise is only $21/mo and for most users it has all the same features of Gitlab.
Gitlab's main differentiator for a long time was CI, but now Github has its own equivalent (Actions).
It seems that Gitlab is only going to be left with 1) existing Gitlab users 2) users that want some enterprise feature set that doesn't exist on Github, and want it in a single platform without a third party