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).
Gitlab is open core, (not great but better than nothing) while github is zero open source.
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?
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).
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.
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.
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.
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.
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
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.
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
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.
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.
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.