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.
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'm open to being wrong through.