---
I do think the change in leadership is probably more a continuation of Gitlab moving from a developer focused company to one focused on enterprise sales, so the product is probably going to continue to feel less interesting for me. They were pretty innovative in how open they were, so I hope at least some of that survives.
Indeed, he has cancer.
By taking a strategic role, investors are less worried because they know the CEO is still around.
But in this case it looks like it is legitimately a health reason. I hope he heals quickly.
He has cancer.
OP got to that.
I was saying the choice of a business-focused replacement with a track record of prepping companies for acquisition (vs say getting someone internal or with a more engineering track record) is a sign of changing direction, however.
One migrated from Github Enterprise Server explicitly as a cost saving measure. One migrated from Bitbucket Server because the writing seemed very much on the wall for Atlassian's self-hosted solution with the Jira pricing model change and a trial migration from Jira Server to Jira Cloud had gone so badly the whole thing was called off (though they did pay up for JIRA Data Center, JIRA was deemed less replaceable than Bitbucket apparently). The last went from Gitlab CE to Gitlab EE, so maybe there wasn't the hardest investigation of alternatives on that one, but they did at least claim they looked at Github Enterprise server as an alternative.
Now none of these companies used Exchange, Azure, Office, Teams, etc. etc. so maybe there's a bunch more discounts and synergy if you're fully bought into the MS ecosystem
GitLab was the first code host to add more products (CI, security, ops, helpdesk, analytics, etc.) and create a whole suite, and GitHub followed. GitLab also built for the enterprise years before GitHub started to give appropriate love to the enterprise. Some people think that GitLab is a GitHub clone. Quite the opposite!
Even if you don't use GitLab yourself, you've been a huge beneficiary of the dev workflow GitLab envisioned and created, and of the competition they've given to Microsoft/GitHub. Competition in this space makes everything better.
Disclaimer: I've worked with Sid and his team in the past.
Few people realize how long it's been since GitLab was a simple clone -- there has been a ton of legitimate net new innovation, and that happened under Sid (and of course all the awesome people working at GitLab).
Another thing that's actually insanely under-discussed is how openly GitLab runs and how that's been a successful model for them. I'm not sure I know another open core company that has been so successful in the space of developers who bend over backwards to pay nothing and spend hours of their own time (read $$$$$) to host their own <X>.
IMO they are the only credible competitor to GitHub, and they're open core, huge open source orgs, small companies, and large companies trust them (rightfully so), and they've built this all while being incredibly open and to this day you can still self-host their core software (which is a force multiplier for software companies).
Without Gitlab, Github would've taken years, maybe even longer, to develop what it has become today. I don't think Gitea and its forks would exist.
Now if only Github would go the extra mile and copy another feature from Gitlab (IPv6 support)…
It is, by leagues.
Even something simple like running a step before clone/checkout is impossible with Gitlab CI, let alone any of the actual powerful stuff.
But really that’s emblematic of the whole thing, where some particular workflow is possible but extremely awkward and hacky. You feel like you’re fighting the system and wish you were just writing whatever it is as a few lines of groovy in a Jenkinsfile.
There’s a middle ground between overly flexible and very constrained, and I think GitHub actions nails that.
Individual steps/actions are reusable components with clear interfaces, which is tied together by a simple workflow engine. This decoupling is great, and allows independent evolution.
As a point to this: GitHub actions doesn’t even offer git clone functionality: it doesn’t care about it. Everyone uses the core “GitHub/checkout” action, but there is nothing special about it.
The same for caching - the workflow/steps engine doesn’t give two shits about that. The end result of this decoupling is things like sccache and docker can offer native integrations with the cache system, because it’s a separate thing.
However, I've typically dealt with builds that have a very heavy dependency load (10-20GB) where it isn't desirable to install everything every time— I'd rather have an intermediate "deps" container that the build can start from. But I don't want to have to manually lifecycle that container; if I have a manifest of what's in my apt repo vs the current container, it should just know automatically when a container rebuild is required.
- 2021, Bill becomes CEO of NewRelic. 2023, NewRelic was acquired.
I'm seeing a pattern here.
> New Relic to be Acquired by Francisco Partners and TPG for $6.5 Billion
Sounds like he is good salesman, the numbers are quite good.
I also bought some stock a while back because I liked the product -- praise Jah if they all make out like bandits if it sells, I just hope the new owner doesn't let the product shit the bed.
If the other commenters are correct that the new CEO has a track record of pursuing private equity type acquisitions, then I fear GitLab CI is destined to become the next Travis CI.
* Bad error handling. Ruby errors leak through. Although the underlying error is my user error, returning it to me as an underlying Ruby exception is really unhelpful. It basically shows that they didn't validate inputs at all. The input is trusted, so it's probably not a security issue, but it's a huge usability and developer experience issue.
* Config format is weird and deficient. Surprisingly difficult to programmatically generate. Can't generate new jobs into the current pipeline. Must generate child pipelines. See above for the load amplification issue therein.
GitHub actions still aren’t k8s native, you actually have to install docker on your “runners” like it’s the year 2010. Pitiful.
I get the point about it not being ideal for self-hosted runners, not having ephemeral storage etc. But I disagree that the hosted GitHub Actions runners don't provide a good experience. If your build needs it - e.g. you're building something to deploy to your K8s cluster, use your Dockerfile and build in Docker. If you just want to compile some code, what's the point?
He is the guy responsible for the absolute train wreck that was the Azure portal v2 (post silver light) and v3 (Ibiza). He lied to Scott Guthrie, buried efforts to benchmark or in any way measure CSAT or usability, and stabbed many many people in the back.
Dude was also borderline incompetent.
His partner and buddy in the whole fraud was Jonah Sterling who managed to continue to get promoted and is one of the top design leaders at Microsoft despite having zero UX/UI/Interaction skills or knowledge and costing Microsoft years of wasted effort and ruining many design careers by overpromoting his directs to boost his own career trajectory.
After working with so many Microsoft execs who were either astoundingly incompetent or downright malicious people - it saddens me every time I see another one get named to a csuite of another company.
Oh, that description explains why the core pipeline authoring and capabilities have made almost no progress in the last few years. I actually thought gitlab still branded itself as a "classic" dev ops tool.
Ironically I was very open to paying for a service, but the “AI AI AI!” lost them at least one sale.
There was a short break after the first talk concluded during which about a third of the attendees left, myself included.
When my company was acquired by $MegaCorp, I noted one of vendors was like "trusted by $MegaCorp" because yes technically, they got a check from $MegaCorp but $MegaCorp was not interested in becoming further customer.
Ironically, the JetBrains autocomplete is better than their DUO plugin - JetBrains is faster and the GitLab plugin causes my IDE to completely lock up at least once a day.
“GitHub with a worse UI except GitHub’s has been getting worse for years so now they’re both similarly bad so never mind”
“Worse gitea but with more features so sometimes it’s better”
I love that it implies there is a more comprehensive DevSecOps platform that isn't AI-powered.
Can't believe they'd put "AI-powered" there when it can't even be used to find exact word matches.
After the pricing change, you had to start paying immediately (from the 6th user onwards or something), which made it a nonstarter because no company would start immediately paying for a Github replacement they didn't even know they wanted.
Together with Github being priced very cheaply, plus having free private repos, plus having the entire OSS world on it (for my OSS projects), I switched to it and never looked back.
I was a huge gitlab fan and would not have thought much of anything else, but the pricing made that impossible. The product has also suffered greatly as a result of the years of poor decision making at the top. It's one of the most unfortunate outcomes I can recall.
They still don't make a profit. So much more a "try to become profitable in a changing financial landscape that will give us much less runway to do so" than "short-term profit grab"
For him, it may be bad, or it may be just realizing either outcome, time is short.
Also, as far as I can, the security centre wouldn't let you download a .csv of current security issues in the repo - the UI lets you do a bunch of filtering, but the .csv always gives you everything, including issues that you've closed.
We gave up on that and decided to use another tool.
My gripe with GL is that all features are like this now. There is no invest into the basic building blocks, just yapping for the next trend. Most customers for GL use it on premise because they want to use it on prem. I would focus on Features that benefit that crowd, but hey I am just an developing not a gilded c suite.
Or replacing "For example, If you're charging for API requests" to "For example, If you're charging for LLama AI Model API requests".
Heck, I had to review a doc change at work that was pretty stupid. Like one thing we offer is an S3-compatible endpoint. But someone thought we should clarify that you can upload AI models there too and all our docs should include an "AI developer" section for how to upload a blob that also happen to be a model or a lora or whatever.
Because apparently Minio is for AI these days: https://min.io/
When the AI craze stated, so many people in my company came to me asking “if we can run AI workload”? another thing we offer is fairly generic compute meant for your average web applications or micro service etc. Initially I said “I don’t think so. We don’t have GPUs nor do we have any ability to express hardware requirements beyond CPU and Memory. We’ll need to do some work to include GPU into that”.
Then hilariously I learned that you don’t need GPUs or ASICs to be able to run “AI workloads”. If your compute allows you to call OpenAI rest APIs, then you’re also “AI Ready”.
or.. something.
Edit: I did not see before that Sid had cancer. I send him wishes for a good recovery!
On a burner account as I am a New Relic employee.
Bill Staples was a nice enough guy, but at New Relic he was specifically brought in as CEO to get the company prepared to be sold. Which is the exact same thing he did at Marketo before that.
He has no relevant tech experience, except when it comes to preparing a company to be sold in the next 2-3 years.
FWIW, I found them easier to deal wit than github, so will hang tight to see how this plays out.
Nothing they’ve done since they were created has ever moved them in a more open source friendly direction, and they’ve broken a ton of promises both implicit and explicit along the way.
GitHub OTOH has only become more open source friendly (minus the AI stuff, but I suspect Gitlab is no better on that front).
In general, Github still feels like it's built for hobby coders (focusing on simplicity instead of configurability - which doesn't have to be a bad thing) while Gitlab feels like it's built for professional teams from the ground up.
I have never used Github Actions. Can you explain or give some examples what doesn't make sense?
To reuse code, Gitlab CI has simple template files which you can import into your toplevel .gitlab-ci.yml, and you have an inheritance system to derive new jobs from other jobs. That's a very simple and powerful system.
Code reuse in Github works with above mentioned 'actions' where each action seems to be a whole repository of stuff instead of a single file like in Gitlab CI.
Gitlab CI seems to be designed by people who know what they do and what their users need, while Github Actions seems to be designed by architecture astronauts, and has only afterwards and reluctantly been hammered into a shape where it does the things most users expect.
Gitlab CI actually seems like it was made for CI in the first place.
Protected branches and associated secrets. Much cleaner construct on gitlab.
GitHub actions defacto seems to be tracing yaml to compiled JavaScript to hopefully that right source to shell commands.
Gitlab seems to be yaml to shell commands.
Nested projects. Nice midspot between monorepo and access control management.
API. I may be out of date on it but I recall the gitlab apis as pretty sensible. The github apis for administration has a very odd rest/graphql split.
It can also render the complete pipeline config (making it easy to run and debug the problematic parts locally just by copying the relevant parts, even if they're hidden in and include somewhere).
Compare the gitlab UI with phabricator for example. The workflows are mostly a strange mixture of whatever github made up on the back of a napkin and Stakeholder-consultant slop.
Gitlab is open core, (not great but better than nothing) while github is zero open source.
One talks about open source because it's the de facto home of open source. The other is actually open source.
Could you elaborate if you can?
The main reason for Forgejo is moreso that Gitea as a project was taken over by a company instead of being run as a non-profit. Some of the dev team felt uncomfortable with that and forked it.
Personally I haven't seen much reason to switch from Gitea to Forgejo - this is the sort of ideological issue that I'd rather kick the can down the road on until Gitea Ltd goes bad (and in an assumption of good faith, I'll assume that it won't.)
It's not that difficult to move git repositories around after all.
For years, "self-hosting" Gitea wasn't done because it was missing a bunch of useful collaboration features. Now, it looks like that gap has been closed. All of the specific features mentioned in that issue seem to have been fixed, and the big remaining task is figuring out below to actually migrate all the existing data out of GitHub -- which doesn't seem to be super high on the priority list.
If you made an offer to buy it for ~$15B right now, the board would basically have to approve the sale.
Mid sized newer companies likes Hashicorp or datadog or vercel who target developers as customers .
Gitlab gives access to a large audience of developers to cross sell most dev tools so all these orgs can get a lot of returns paying more than the standalone value of gitlab itself.
The best fit would be companies like Hashicorp who have strong open source pedigree so users won’t be turned off and leave
HashiCorp might not be the best fit anymore. Last year, they switched to a license that isn't open source: https://news.ycombinator.com/item?id=37081306
In my mind just like LinkedIn , GitHub and Microsoft are every distinct entities with a lot of differences on how they work , Hashicorp and IBM parent are different and will remain so. Integrating into Hashicorp for Gitlab would be very different than integrating into IBM core with different values for both businesses .
GitLab supports storing the Terraform state and includes Terraform templates however they are moving to OpenTofu in 18.x [2]
1. https://docs.gitlab.com/ee/ci/secrets/hashicorp_vault.html 2. https://docs.gitlab.com/ee/update/deprecations.html
If an acquisition has to make sense there should be a clear path to monetize it, for IBM core or its HashiCorp unit or any other buyer that will not just be through some light integrations alone, they can achieved with partnerships after all you don't need to buy the organization for it.
https://www.reuters.com/markets/deals/google-backed-software...
Given New Relic is a direct competitor, Bill Staples' background makes even more sense.
I seriously don't understand the deals being made in tech. Most of the makes no sense, not even retrospectively. I get Microsoft buying Github, that was a part of their open source strategy and they've always put a high value on developers.
I wouldn't buy them for that myself, but Gitlab made $200 million in revenue in Q3 2024 [1]. So $800 million a year in revenue.
I've seen worse purchases.
[1] https://ir.gitlab.com/news/news-details/2024/GitLab-Reports-...
There might be some potential for Gitlab complement your other business, in which case you may not see the lack of profit as that big of an issue. The problem is that if you can't make those $8billions back in future profit, then you're going to start making changes to the Gitlab offerings until they do become profitable.
That might be what the new CEO is suppose to do, pump up those numbers, and make it look like a sane investment.
The main question is probably the price.
I would be excited if IBM acquired them and put them under the red hat umbrella, because as history has shown, it may mean that gitlab ends up becoming much more open. They may open up the entire product instead of doing the open core model.
AWS shut down their service, if AWS can "easily" integrate with Gitlab, I see a lot of potential on the deployment side to increase AWS revenue.
Google isn't know for its hands-off approach nor long term view for service growths. Gitlab is essential to balance Github's impact, I'd hate it to go in the graveyard.
Horrific outcomes: Atlassian, Oracle, or IBM buys it.
Great outcomes: Google, Amazon, or JetBrains ($7B private valuation) buys it.
I think it would make more sense for a number of companies to invest in Gitlab, to ensure that there is a 3rd. party tool available, as to not "force" users into the hands of Github and Microsoft.
That's probably the best case, Google, Amazon, IBM, JetBrains and a few others create a company, with themselves on the board, and tasks that company with buying and running Gitlab. Having Google alone buy it and you may as well just migrate now pending the inevitable disinterest and shutdown. So I guess that I disagree, Gitlab makes more sense as an independent company, that it does as part of companies that already had failed competing products.
My guess is the ever popular MicroFocus (Now OpenText) who will buy everything that it on the edge of popularity.
I don’t see GitLab replacing BitBucket.
But GitLab price annually for the same amount of users that we have for Bamboo and BitBucket is higher in licensing fees. We have to do things self hosted because of regulatory and compliance reasons.
There is probably a business case to be made for the inefficiency that we see with Bamboo.
BitBucket DC is pretty solid and never goes down. It integrates well with all the other Atlassian products like Jira or Confluence. Our instance is also highly available and fault tolerant.
https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-...
YouTube, Google Maps/Earth, Android, DoubeClick, DeepMind, Firebase, HTC (Pixel)
Don't discount Google's M&A game.
Doubleclick is to Google what McDonald Douglas’s is to Boeing.
It's a lot easier/more common for Google to kill internal projects and small acquisitions.
A $16B write-down is far less likely, especially when many Googlers internally realize how much a threat Microsoft is with GitHub + VS Code.
As a former CentOS user, I politely disagree with this.
Good point, red hat is far from perfect. The way they handled cent was incredibly disappointing.
New Relic went through a few reorgs during his tenure, but they didn't freeze hiring until after the sale.
Then there are things like having roadmaps for the future to make you look attractive.
Then there are vulture things to make your numbers look good which can range from doing neglected cleanups of actually unnecessary costs to cutting costs in ways that really suck for customers and employees.
I think a lot of people would say this is not true. I worked with Bill a little at Microsoft, where he ran an x,000-person engineering org, and my experience was that he was a competent, detail-oriented, product-focused leader. You might disagree but, in any event, running an x,000-person org in a large tech company does qualify you for CEO positions, at least in the eyes of people who make those decisions.
This isn’t secondhand either. I witnessed him multiple times telling reports to bury findings, stop research that made the product look bad, and actively prevent anyone from going over his head to higher leadership.
Not sure how much more relevant you can get....
Bill Staples was a nice enough guy, but at New Relic he was specifically brought in as CEO to get the company prepared to be sold. Which is the exact same thing he did at Marketo before that.
He has no relevant tech experience, except when it comes to preparing a company to be sold in the next 2-3 years.
So other than his relevant experience he has not relevant experience?
Uh...
The team that runs this Hacker News comment site also invests in startups from time to time. GitLab did pretty well.
:-)