I really hope that whoever buys them not to shut it down / change model. At CERN we rely on Gitlab enterprise and I have many CI files that would take weeks to re-write into GitHub actions (there are thousands for CERN overall). We are still suffering from RedHat decision to cut CentOS after relying on it and Fermilab/CERN shutting down Scientific Linux based on the assumption that CentOS is suitable.
It also makes the CERN's strategic decision to go full Open Source less appealing by time. Although there are many examples on how proprietary hurt us too (I see you there oracle).
> It also makes the CERN's strategic decision to go full Open Source less appealing by time. Although there are many examples on how proprietary hurt us too (I see you there oracle).
Surely FOSS is overwhelmingly preferable precisely for this reason - if you use github and they decide to screw you over you're stuck. If gitlab does decide to screw you over then you still have the source code for the last good version, and 1. you can patch/fork it yourselves, 2. you can hire someone else to patch/fork it, and 3. if there's a decent-size community then probably someone else will fork it. Or more concretely, yeah the CentOS thing sucked, but there are multiple replacement forks, which never would have been an option if it wasn't open source.
> It also makes the CERN's strategic decision to go full Open Source less appealing by time.
I think it's still the less risky option. Open Source at least usually makes migrating elsewhere easier. CentoOS -> AlmaLinux for example (or any of the other commercially supported CentOS replacements). Customers currently being exploited by Broadcom/VMware wish they had such options.
I like both companies, but there is strongly negative synergy. I'm sure there's some vision behind it, but like most such purchases, one side or both will likely crash-and-burn. That would be sad.
Aside from technology issues, the companies have a completely different culture and ethos. Universally, that's not preserved in acquisitions like these. Gitlab has a very unique culture of transparency, remote work, etc. which won't mesh at all with Datadog.
If the goal is some kind of integration, a much better model is a significant investment and partnership agreement. It's possible to have those permanently binding, while still being attached at the hip.
I really wanted Gitlab to succeed. I joined early on and used it quite a bit but by 2020 things changed and their message , pricing was all mess. I don't think I have ever used it since. But this was one startup I really rooted for.
I thought eliminating the cheap plan was a huge mistake. You can say that people shouldn't balk at paying $20 a month, but Github offers a plan for $4 per user, why should they pay more and all they get is features they don't intend to use? Ceding the entire low ground like that is shortsighted, especially since Github has an advantage in selling the same users an expensive plan if and when they need it.
We'd evaluated GitLab a while back for a previous company before GitHub Actions was launched because the CI coming in with GitLab was very tempting. Since we were a small team working with contractors, we were looking for a monthly subscription and were pretty shocked at immediately being rebuffed and asked to book annually. Genuinely insane at the time how insistent they were that we should simply pay up front for an entire year of seats that were likely never going to be used. We just went with GitHub
Their extreme focus on enterprise is probably the reason for the low traction they're getting. Can't believe how much money they're leaving on the table because of some of their more bone headed decisions. Not sure if that ever changed
> Their extreme focus on enterprise is probably the reason for the low traction they're getting. Can't believe how much money they're leaving on the table because of some of their more bone headed decisions. Not sure if that ever changed
That's exactly what happened. But they didn't do it well either. For example, they demanded that all users had to be the same level of subscription. Except many companies had people who would just log in to say use the wiki. But they had to be billed the same $99 a month as a developer who used most features.
They were so blinded by chasing dollars they lost market share.
We have 400 seats. You do the math, we started with 4$ and within 5 years the price got up to 30$. At some point you just have to question if it's still worth it, and for GitLab, that's a clear No when compared to GitHub.
It’s the principle of the thing. It’s not because the money is relevant to me, but because getting the thing through purchase approval is like 400% harder by increasing the price from $20 to $30 per user.
I put most of my open-source repos there for a few years, and got GitLab adopted at work too. They had similar feature set to GitHub and I didn’t want to support the latter’s near-monopoly status. After Microsoft bought GitHub and many large projects started migrating to GitLab (e.g. GNOME), I thought things were looking better.
But a few years in… I’ve given up and moved my repos to GitHub a year ago. It’s clear that my GitLab repos have nearly no visibility, and if no one finds the projects then there’s not much point in open sourcing it.
Red Hat uses Gitlab for CentOS Stream development (https://gitlab.com/redhat/centos-stream). However $8bn is a lot of money for what is basically a loss-making cost center. (I know it made a small profit recently, but Gitlab has lost money for a very very long time.)
It's a shame that Gitlab isn't profitable. Maybe it's just because I have to use it for work and am therefor familiar, but I've always slightly preferred it to Github. I also never really saw Github enterprise server being viable in the "we have to self host for security reasons" space, but maybe someone else has a different view.
The CI/CD alone in Gitlab is light years ahead of what Github has to offer. I'm really hoping that they can hold on in some way or that the core open source application stays viable.
True, however on the other hand something truly basic like “not spending time re-compressing and re-uploading a cache after a cache hit”, “use zstd with caches”, or even “add fucking timestamps to CI logs” doesn’t even have any equivalent in Gitlab CI.
Some might even say dynamically generating child pipelines, while cool, is a niche bandaid for some of the legacy tempting baggage they are unable to escape from that dramatically increases pipeline complexity whilst common use cases are still broken and still underserved.
It’s a janky pile of unnamespaced, hard to debug and fragile YAML-template-meta-programming hacks. Light years my ass.
The other big reason to self-host GitHub is avoiding their constant outages.
Controlling availability is a real benefit for larger companies (dev downtime) and those who need to be able to fix bugs in prod (roll forward) without being beholdent to GitHub's availability.
We ran github enterprise on our infra for several years. It was a pretty low overhead thing to run except if you’re really big. The nice thing was that we could customize the api rate limits which is really annoying with saas github.
Looks like they aren't profitable, they lack a real moat.
Literally anyone can just spin up a competing service. I'm actually surprised GitHub/Microsoft hasn't eaten their lunch yet.
Gitlab used to have a firm advantage in terms of build runners, but GitHub Actions have been out for a while.
I strongly suspect GitHub loses money ( of course you pay in other ways, wouldn't surprise me if GitHub actively blocks other LLMs from scrapping public repos while allowing co pilot to.).
How can anyone compete against a trillion dollar company that's fine with subsidizing an unprofitable business line?
Ultimately I don't think Gitlab or anything like it can hope to actually make money.
I think you are wrong. Not having a moat is a business model and a competitive advantage, and one which works well. As a customer, it gives me confidence that, if gitlab (or any similar company) screws up, I can host it myself. I go for open source precisely due to the lack of a moat.
That's what most open models rely on.
1) Hosted services are cheaper than running it myself, once I include staff time, so by default, I will go to the source vendor.
2) Even if there's a cheaper alternative, I'll gladly pay e.g. 50% more to go to the organization which wrote / maintains the product. Many companies just aren't that price-sensitive. If you pay $200k for a SWE, is saving $100/year worth it to go for gitlabknockoff.com instead of gitlab.com? Most big organizations wouldn't. The risk only comes in if gitlabknockoff was AWS, Azure, or GCP, which we're still learning what to do about.
3) There is a shallow moat in the forms of things like brand recognition, canonical URLs, etc.
If you're comfortable with e.g. a <100% profit margin, open models do just fine. Open models just mean you can't have a 10,000% markup or do an Oracle-style milking of customers. As a customer, that's why I pick open models.
Open models also mean I'm not SOL if you go out-of-business.
The friction comes in with a lot of hybrid models. Most things between open and proprietary don't work well. Datadog + gitlab are on opposite sides of this divide, and I don't see that working well.
I think the key bug in gitlab is exactly that: out-of-control costs. One of the key things about moatless models is you do need to keep costs under control.
Gitlab has 2,268 employees. That's probably an order-of-magnitude more than they need. With 226.8 employees, they would be wildly profitable. Now, once you take on employees, it's very, very hard to shrink. It takes a lot of disciplines not to overgrow workforce. So I'm not suggesting layoffs or anything specific to fix it.
Regarding costs: Gitlab is $29/month. Github is $21/month (or $4/month).
* If you're spending $200k on an employee, is it really worth saving $300 or whatever per year on tooling? Any difference in productivity will far overwhelm that.
* If a devops employee runs $200k per year, are you going to "host your own" to "save" a few grand?
Much of the market simply doesn't care about pennies, and bottom-feeders aren't super-profitable in either case. Bottom-feeders can be important from a network effects perspective, but for profit, going for the high-margin makes a lot of sense.
Honestly, I have no idea how I'd value gitlab; that's another story. But all else being equal, I'll pick open-source over proprietary. That is a competitive advantage over github.
1975 called. They'd like to loan you their copy of the Mythical Man-Month.
So to be clear: If all of those were SWEs, that would be 2,268 people to introduce bugs, and roughly 2.5M potential social links / interactions (and communications overhead).
The issue queue is what results.
Most projects are best done by about 2-10 person teams. That's about where you can maintain architectural coherence. Beyond 20, architectural coherence becomes impossible.
So would the perfect GitHub/GitLab competitor be a 20 person team of highly paid engineers ( 400K USD straight cash comp) with outsourced marketing and HR ?
I actually think most companies, particularly when VCs are pumping them full of capital, overhire.
I guess this is to signal to the market we're doing cool things...
From a purely "winning in the market" perspective, I think there-abouts. For optimal, I might go up a little bit more, since there are multiple products, but not a lot more. Some of the CI/CD stuff is pretty disconnected from the core product.
There are very, very strong individual pressures to overhire. "I managed a 500-person team" sounds a lot better on a resume or otherwise than "I managed a 5-person team" (even if the 5-person team did more).
I also wouldn't go all cash. I'd do the normal $150-$200k cash, and the rest in equity. I'd be very, very generous with equity.
There are also time pressures, whereas many things take time to build. 5 people x 4 years >> 20 people x 1 year, at least if kept productive (which is sometimes hard with longer timelines)
The features they put out are not really that great anymore and most issues are about the core product and not the thing they want to sell you like, duo.
Back when interest rates were near zero complained hired more people than they needed. The money was really good too, I was making more money 4 years ago.
A moat was a defensive ditch (often filled with water) built around medieval castles to make them harder to attack[1].
In the context of a company, when people talk about a moat they usually mean some unique feature or structural advantage that allows a company to maintain a competitive edge over time, makes it harder for a competitor to usurp the company's market position or steal their customers etc.[2]
So here a moat means "what does gitlab have that makes it harder for someone else to launch a git hosting thing and devs/companies/whoever just ship over to it?" To which the answer is clearly "not very much" given that github exists and does a very similar thing.
> The risk only comes in if gitlabknockoff was AWS, Azure, or GCP, which we're still learning what to do about.
Exactly! It really makes me wonder how GitLab thinks Datadog can help them defend against this risk. Then again, they're not open source - just open core.
> I'm actually surprised GitHub/Microsoft hasn't eaten their lunch yet.
It's not for lack of trying. GitHub are aggressively pursuing the enterprise market from a sales perspective but there's been three problems with their approach:
1. They're pushing SaaS over on-prem: enterprise services in general are trending this way, but it only really works when you're in a dominant position - like e.g. Atlassian - when you're competing it's going to leave you with less leverage with potential clients.
2. They're leaning very heavily on AI - this is a double-edged sword as it's currently selling well to clients as a pitch but anyone doing functional evaluations is looking at benchmarks & it's not really mature enough to deliver there.
3. They're iterating really slowly on their roadmap. This seems to be GitHub's (not Microsoft's) typical approach, which I'm honestly a big fan of, but when you're entering a market with existing mature players it's going to slow down sales.
I do think GitHub will ultimately take over - it'll just happen slower than expected.
I run an on-prem GitHub server. New features come 6-18+ months behind Cloud for the most part, our reps are always trying to get us to move to Cloud, and new features are often broken for weeks/months even after being released for on-prem.
Curious about your experience as I'm in a similar position (running ghe, want to stay on it, mgmt being sold on ghec) - I have other reasons for wanting to stay on ghe but my experience is recent features hit ghec first. Maybe that's a recent change in their release cycles?
GHES is a massive monolith running dozens (hundreds?) of services in Nomad, so it's not surprising to me that GH has a hard time supporting it and wants folks to move away from it.
I'm tired of slow, risky, late-night upgrades to the appliance. I'm tired of sending support bundles and being told to run a customized string of MySQL commands to resolve peculiar issues. I'm tired of checking the roadmap and telling folks "yes, they announced that feature, but it won't be available to us for at least 12 months." I'm tired of a feature eventually being in the GHES release notes, only for GitHub to have made a mistake and it not be available for another two versions.
We're moving to GHEC. I'm concerned about the semi-frequent outages there, but we're not running HA GHES so it has become a liability for us.
I would assume they are running it for a company, in which if said user gets hit by a bus you want to be able to bring someone else in quickly that can run the operation.
We have looked at GitLab in the past, but I wasn't involved in that process. Generally though:
- Enterprise support is very important to us
- Migrating thousands of repos and training hundreds of devs to use a new VCS is a huge and expensive task
- We have custom integrations with GitHub that would need to be rewritten as well
Subjective take: GH & GL are equally bad when it comes to bundled enterprise features, so the differentiator is going to be individual dev features & UX/DX. GH is much better at the latter - CICD might've been a differentiator in the past for GL but even before Actions a lot of companies were pretty happy going 3P here.
Mainly talking about sales, but also a lot of their newer enterprise-oriented new feature developments are either saas-first, or not (yet?) roadmappedb for on-prem.
Gitlab's biggest issue has always been their ridiculous approach to pricing. It simply isn't worth paying ~20-30x more per developer than comparable tools.
Feature segmentation can be entirely reasonable. However, gating something like "linking epics"[0] behind what used to be $99/month/user (now POA) is pure hubris.
> Gitlab's biggest issue has always been their ridiculous approach to pricing.
Yes it has been. They literally refuse to take money and be smart about it. For example, all users must be licensed at the same level. So if you have the $99 / month level, and want people to just edit the wiki, it's the same price. Instead of a much cheaper price. So instead of people doing that and them making more money, people just say "nah" and they lose money.
>How can anyone compete against a trillion dollar company that's fine with subsidizing an unprofitable business line?
It sounds like impossible, but it's not always. Sometimes large companies loose the focus and become slow. There can be multiple competing products and teams are prevented from building the best product in order to not interfere more profitable business. Microsoft for example has both GitHub and Azure DevOps.
One example of how the infinite resources do not always help. Year ago GitHub decided not proceed with adding support for Python packages in GitHub packages.
"This is no longer planned due to a change in our strategic priorities and the allocation of our resources towards higher-priority initiatives." [1]
> Microsoft for example has both GitHub and Azure DevOps.
Not sure what you meant, but this is indeed visible in GitHub, maybe in positive way. GitHub Runners are specifically coded with C# and ASP.NET Core and designed to be used on Azure, while not limited so. Maybe the adaption of current GitHub Actions would not happened so efficiently without this.
> Literally anyone can just spin up a competing service.
I don't think it's true, except in a very reductive meaning of "there's no legal or physical barrier to somebody making a competing service", which is true for most of the existing services. But making a repo service is much harder than just spinning up a git server. It's the surrounding UX story that makes it work - or doesn't. And anybody who uses these tools professionally would gladly pay for the low-friction UX that allows to remove handling of repos, permissions, builds, teams, CI/CD and all that from the list of worries. It's not easy to build such a system that works. It's not impossible - especially for the trillion-sized giants - but also trillion-sized giants repeatedly failed at projects like that (e.g. Google and social media) so there's a real niche for a company that does the right thing the right way, even without an impenetrable moat.
As the person who runs one of the largest cloud CI/CD services around, I can tell you exactly how they're making money... Actions.
GitHub would be making a VERY healthy margin on every minute of build time run on their platform, especially considering they don't have to pay a cloud platform for the compute like Gitlab or Bitbucket Pipelines do.
You'd be surprised actually. Once you factor in network costs, running your own on AWS is only ~50% cheaper than paying for SaaS.
Factor in the opportunity cost you pay by having to have a person manage a self-hosted CI/CD cluster rather than outsourcing it, and SaaS CI/CD is around 3x better value than self-hosted.
Happy to share more detailed numbers if people are curious...
> Ultimately I don't think Gitlab or anything like it can hope to actually make money.
Oh they can absolutely make money. Stop chasing enterprise dollars which is always hard. Start chasing hobbyists and small to medium sized business. Let people pay money for what they use. They could make a KILLING with small dollars. But that doesn't sell IPOs and get you bought out.
In lieu of a moat, they've always relied on going to social media to say "but we did it first!" when a feature was "copied" by Github, which is retrospective isn't very effective.
This is like one of those drunken hookups at the end of a night. Then when you wake up in the morning, there’s a sense of uneasiness and regret upon sobering up.
I sense a Datadog acquisition will likely fall through or somebody else will buy it. I really don’t understand how a cloud monitoring firm would stand to benefit from a code repository firm.
- ‘free’ monitoring with your GL hosted app. Get them hooked and vendor locked, and now you have a customer for life?
Wouldn’t having insights into the stack used by a company help with cross selling their monitoring suite? Example: if a company is committing code that is heavily involved with Redis, Datadog could come in and say “hey, need to monitor memory usage of your Redis clusters? We got a solution for that”
I would love to give Gitlab money, we live out of it at work, but charging a per user cost for self hosted instances is insane. I have budget to spend, but I can't justify $30 per seat per software per month, especially if I'm the one hosting it.
Can anyone tell me why someone would pay nosebleed prices for Gitlab when they could simply use Github? Like do they have some special use case that github doesn’t support? Do Gitlab customers just love giving away lots of money? Do they want to pay a premium just to feel “special”?
The part where it's not 'simply'. If you just have some Git repositories, and nothing else, then yes, you can use any of the Git hosting services, and it doesn't make any difference if you are using GitLab, GitHub, BitBucket, AWS (CodeCommit), Azure (similar), Google (similar), as a DVCS (using SSH or mail), or whatever else you can come up with (Gitea etc). Most of them are free for just some Git (including GitLab and GitHub).
But as soon as you do more than that, there is no more 'simply'. GitLab has features GitHub doesn't have, they both have features that aren't 1-to-1 comparable, and price wise if you use the same features on both sides, GitHub tends to cost more. And then there's the whole CI thing where you can't use GitLab CI files on GitHub Actions (but you can use GitLab CI in combination with GitHub repositories but that would cost more), shipping hierarchical organisational structures is either a PITA or not possible and updating all references everywhere on everyones machines is going to suck either way, which eats into the 'simply'.
Cost of migration, especially all the pipelines and project planning.
GitLab used to be a good deal. The bronze tier was 4$ and you had better CI than GitHub at the time. Then in 2021 they ditched bronze and went to the new three tier model, the cheapest being 20$ (apart from the free tier, which however is severely limited). Last year they increased it to 30$, and that does not even include AI features, which will cost you 20$ extra.
So nowadays, there is indeed pretty much no reason to chose GitLab other than self-hosting. We still have license until 2026 and I'm pretty sure we'll bite the bullet and start migration to GitHub before we renew. Sadly, I don't see much of a future for GitLab, apart from being acquired by Google, Meta or similar who can afford to run this at a loss for strategic reasons, like MS does with GitHub.
I'd think that self-hosting is a niche that grows in appeal over time.
We're one "they trained the LLM on our private repos and it leaked" scandal away from undermining a lot of trust in cloud services.
There are probably also businesses that end up into compliance scenarios where it's easier to walk an auditor over to the rack and point at the VCS server rather than trying to get the right testimony from the cloud providers.
For us, it's mainly for legacy reasons. We used to have a self-hosted GitLab instance as a fledling company and then switched to SaaS GitLab after the company grew and IT spent too much time maintaining it, with an Ultimate subscription to get access to the security tools.
If this was my company, we would be on GitHub since GitLab Ultimate is super fucking expensive and those security tools are buggy as hell. Not sure if the GitHub ones are any better, but surely they can't be worse. Granted, I don't know how much we actually pay since Ultimate price these days is "contact sales", but I'm pretty sure it used to be like $99/user/month.
(We also wouldn't be paying for Jira on top of GitLab/GitHub.)
> If this was my company, we would be on GitHub since GitLab Ultimate is super fucking expensive and those security tools are buggy as hell.
That’s my concern, too: there are some appealing features on paper but I’d bet it’s going to be like everything else where you get to debug a convoluted thicket of YAML & scripts when you get out of the simplest use-cases, and you can spend time writing tools to paper over the rough edges. GitHub certainly isn’t perfect but I feel it’s a lot less common that it seems like the developers don’t use their own product.
Github Advanced Security is $79/user per month (on top of $21/user per month for enterprise edition), but is actually really good. I’ve considered buying it for my own private repositories because it’s so nice (yes, a single person enterprise account is fine with Github too, and you can pay monthly).
I… used to like Gitlab, but it’s like they lost their way a few years ago and now I’d never recommend them.
GitHub's pricing page says that it's $49/user/month extra on top of that $21/user/month Enterprise fee. So even though it's kinda pricey, it's still less than the $99/user/month that GitLab Ultimate was.
GitLab on-prem is way, way, way more elegant than trying to get GitHub on-prem working. One of the things that makes me go, "Gah?" is that, well, Atlassian is more or less abandoning on-prem Bitbucket going forward. Perforce is, well, Perforce. Niche VCSs like SVN are rapidly getting impossible to keep running on modern platforms. All this really does seem to leave the field of "small to midsize companies who can't cloud" entirely to GitLab.
Which, I guess, says something about how expensive it is to run support for on-prem enterprise software. But that doesn't feel like an unsolvable problem, not with a customer field this rich. On-prem focused orgs tend to have wads of cash stuck up in them.
I think mostly support for both on-prem instances and SaaS, but your own dedicated instance. So stodgier places that don't like their code or pipelines in shared tenant environments. Maybe because their internal audit, cyber department, etc, are sticking to their policies that have been around a long time.
That would account for new sales. Then, lots of existing base because they used to be an inexpensive bundled repo+ci/cd solution. And anyone's proprietary ci/cd ecosystem becomes sticky and hard to migrate from once you put a lot of repos into it, whether that's Gitlab or any other provider. So people don't switch away because it's hard.
Probably not the "easiest", and it's not really production-ready yet, *but* it is the one open source solution for hosting open source software that will never be affected by the "Explores Sale" problem - the same way that BitTorrents have never had that problem: it is a fully decentralized, peer-to-peer network for hosting source code.
I have to say "Datadog" isn't exactly as scary as "Microsoft" was, back when it bought GitHub.
Ok, they didn't kill the open source community which is what we feared at the time (because they found a way to make more money from it), but I'm still more skeptical of Microsoft essentially controlling the world's open source software than Datadog buying an open core company.
But with Microsoft now painting everything with its "AI" brush, aren't you, as open source maintainers, concerned about keeping the world's FOSS on a proprietary platform?
Instead of selling itself, it should buy sourceforge. That will be one quick step to becoming a replacement to github with a network purchase. The ads are just cherry top.
Secondly, acquire an issue tracker software. With a huge base of private developers, project management software is a step over.
Thirdly, launch a news media site like download.com.
Investment price: $300 million + 400$ million plus $40 million.
So all the things they've been doing haven't been to improve their product, but just to make a ton of money. It certainly explains why they've been adding all these odd features instead of fixing their current ones.
Datadog is going to milk the cow because I don't see what else are they going to use this except push their monitoring solution to the GitLab enterprise customer base or jack the prices to recoup the investment.
Also - wondering what will the commerce look like in 500 years when everyone has bought each other over multiple generations.
A more optimistic view of the situation is that Datadog is already in the monitoring business and wants to go after the rest of the SDLC. There's certainly some value in correlating code changes with incidents.
Have you ever used Jenkins? Even if I don’t like Gitlab I’d choose it over Jenkins any day of the week.
It’s not strictly terrible, just ancient. Like you are trying to drag 2000’s enterprise software through the intervening 20 years and make it work for today.
I've indeed used Jenkins. For all my professional uses, it served perfectly well. Newer releases come with pipeline and k8s support etc., so I'm not of the opinion that just being ancient is a disqualifier.
agreed. Jenkins has suffered from a lot of problems - plugin maintenance across version upgrades being key - but it has also overcome a lot of these problems. It gets criticism just for being... "old". But it is an automation server that is as battle-tested as they come!
Also, being old gives it a huge advantage: you can bet you won't need a major rewrite of your pipelines in a couple of years when e.g. GitLab sells, or Microsoft decides GH actions aren't so free (or fast) any more, etc.
If this news elicits such a strong reaction as this, it makes me wonder why you are even using Gitlab right now, if there is even any likelyhood of such an outcome?
It also makes the CERN's strategic decision to go full Open Source less appealing by time. Although there are many examples on how proprietary hurt us too (I see you there oracle).