It's kind of a poisoned well situation. Whoever would purchase them would lead to the departure of many disgruntled users who basically were with Gitlab to stick it to Microsoft.
I've also never felt compelled to use Gitlab. They literally offer no significant advantage other than being an alternative to Github.
If I started over, I'd go with Drew's Sourcehut hub for the sake of actually shooting for something different.
I don't really see who would pay $8B for this business which has no moat-future.
Gitlab, GitHub and SourceHut are remotely comparable only if you care just about source code hosting. But Gitlab (and partially GitHub) is so much more - it grew to a beast trying to do everything for your project - project management, CI, analytics, communication... It's not for everyone, but for e.g. startups buying an all-in-one solution could be attractive to reduce the effort on getting all development tools set up and integrated.
Yep, as a paying customer, I'm still waiting for a way to reach each project page from any other page. Literally the easiest thing to make in the world, but still in limbos...
As for Gitlab and Github, I left ridiculous Jabbascript abominations behind and never looked back; Github now overriding usual keys like PageUp/Down and Home/End SPA style and not being able to display most stuff without JS is the straw that broke the camel's back for me.
It means that user feels the user interface is quite responsive.
It's not a very useful metric. A user having a flaky internet connection with high latency and low bandwidth and intermittent disconnections would complain that the platforms he uses are "slow".
Or a service is just bogged down by too many users but would be quite responsive if not overloaded.
EDIT: I was not writing about JIRA specifically. I agree that JIRA is ALWAYS slow. Ten years ago I had to wait five seconds after a button click. However I also had to handle a complain that something was slow just because that customer's internet was shit.
EDIT 2: I remember ten years ago an especially perverse variation. A friend of mine was complaining about the bad quality of video even after having upgraded his internet connection. The problem was asymmetric bandwidth. His friend had bad upstream and my friend just saw jerky movements and ugly artifacts and it was unusable for communication in a Signed Language.
I learnt that day: if something is slow, then it is not always easy to understand why. My friend was very disappointed in me.
Jira is slow all the time. Sourcehut might, potentially, in contrived circumstances be at risk of becoming slow, but it's so well optimized that it's an outside risk, rather than a guarantee. Surely you understand the difference between the two categories of software?
> A user having a flaky internet connection with high latency and low bandwidth and intermittent disconnections would complain that the platforms he uses are "slow".
On the contrary, a bad internet connection makes it much easier to distinguish slow and fast platforms.
Everyone doing anything has some controversy around them. At some point, we should just stop paying attention to internet dramas and focus on what matters. Like, fast issue trackers or continuous build with a novel feature to ssh into the state, when the build failed (which SourceHut supports: https://man.sr.ht/builds.sr.ht/build-ssh.md)
It's fine to be opinionated, but he's also very abrasive and you don't have to go far to find people who have had a bad experience with him at some time or another.
That being said, I haven't seen anything egregious for a couple of years, so maybe he's taken some of the honest feedback to heart.
For Github there's a sort of moat that it needs to work across IDEs, orgs, random people, etc. For Gitlab any org using it can harmonize on an IDE and the IDE can slowly introduce all of the CICD/collab with much better code quality and user experience than Gitlab since they rushed to copy Github rather poorly.
After using gitlab for a year I can boldly claim that it is inferior to github in every feature with subtle things being better in github which add up to a far better experience.
Gitlab tries to do a lot and never did anything that well. It's just perpetually catching up to github.
Having used both for about 9 years I would say that's not correct at all.
Github may have beaten Gitlab to the punch with Pages (whoopee) but CI is a far more important feature, and Gitlab CI existed for years before GA, and continued to be a far superior solution for a long time (and maybe it still is?).
Also, because Gitlab targeted enterprises they had a bunch of features that Github did not. Self hosting, Identity and role based access, weighted issues, project milestones and burndown charts, private issues, support for "innersourcing" of internal repositories. The list goes. Unlike Pages, which is useful but can be replaced by any other wiki, things like role based access to projects are really important. When I switched jobs a few years ago and had to use Github, it felt more like a hobbyist's web-based toy version, lacking a lot of "big-boy" features.
The one truly essential feature that separated them "for the 99%" was CI. Once Github introduced that, it shrunk Gitlab's lead.
But Gitlab are by no means playing catchup to to Github.
Wholly agree with you. I’ve been using both professionally for years in parallel and have seen the evolution.
Totally agree on CI being superior. The config syntax is a bit of a pain and is aching for some higher level abstraction. But it’s very powerful, e.g. easily supporting cross project dependencies and build status across project in one neat interface.
I also agree that GitLab was optimized for enterprise and that’s where the major feature disparity is. If you are using it only for small hobby projects you will feel that it’s nothing special. I’ve used a self hosted version at a fortune 100 and it was a huge boon to productivity there over GH EE.
> After using gitlab for a year I can boldly claim that it is inferior to github in every feature with subtle things being better in github which add up to a far better experience.
I find this remark baffling by how much it contrasts with reality. Others in this thread already commented on GitHub using terms like "mediocre". I wouldn't go that far but I am indeed aware that GitLab feels it works and is expected to work reliably, specially CICD which, unlike GitHub, they succeeded in turning it into a solved problem.
It's even more baffling reading bold claims like "Gitlab tries to do a lot and never did anything that well" when only a couple of years ago GitHub Actions were renowned for not even being prod-ready,whereas GitHub CICD just works and works well without requiring investing any thought into it at all.
The parent's post aligns with my own experience. I've been using GitLab for 2 years after switching companies and I can't think of anything that is an improvement over GitHub.
I never had any issues GitHub Actions for CI stuff at my previous two companies, both which used it heavily. GitLab CI also works fine, though I struggle to see how anyone could strongly prefer one or the other as my own experience is that they basically work the same. Both basically boil down to some yaml you can use to configure running stuff in docker containers.
The point is that it was GitHub that caught up for some simpler use-cases fairly recently, not the other way around. When I started using GitLab 6 years ago it made GitHub look like a toy where you had to reach for external services like Travis to do anything useful.
Fair enough, but the fact that GitLab was better 6 years ago doesn't do much to help the company right now.
I wasn't using GitLab 6 years ago so I can't comment on that, but I can comment that at least since 2022, I haven't found anything in GitLab that would recommend it over GitHub.
> Fair enough, but the fact that GitLab was better 6 years ago doesn't do much to help the company right now.
I don't think you got the point.
The whole point is that a couple of years ago GitLab was unquestionably the market leader and hands down the best service.
And since then it didn't got worse.
Best case scenario, alternatives like GitHub managed to put together similar offerings. That does not mean GitHub suddenly was the best. Far from it. Again, others in this thread used the term "mediocre" to describe GitHub, and this happens years after GitHub started to try to catch up.
To me, GitLab's CICD is by far the absolute best CICD system around. It has been like this for maybe a decade now. The container-centric approach to build jobs, a domain model for pipelines that is extremely simple and yet misses no usecase at all, UX that's unparalleled to the point that, unlike other CICD systems, doesn't even require a tutorial to get the basics to work... Things are so far apart that it boggles the mind how anyone who has any experience in CICD would even mention GitHub on the same sentence.
GitLab was the absolute best 6 years ago and, in spite of Microsoft's takeover of GitHub and rushing to bridge the gap, it still is. That's the whole point.
the rabbit hole goes deep, but both GitLab and GitHub reached parity around that time. (initially GitLab CI simply did a lot more, then GHA kind of took over with the ability to run multiple parallel workflows, and by arguably feeling a bit newer and having better "official" steps ... the GitLab auto-magic CI was ... always completely meh, IMHO.)
but GitLab kept adding the good stuff that Actions introduced, and it can do a lot of things, and with the Omnibus package it's very easy to self-host. (and upgrades are well supported, etc.) ... and of course GitHub self-hosting is only for enterprise editions.
sure, you can setup one GHA Runner on one VM (and each one one a new one), but that's it. nothing else is supported officially.
How is CI not a solved problem with GitHub Actions? I used and loved GitLab CI years ago and remember it feeling better to use than GHA (though maybe I’m remembering through rose tainted glasses), but GHA are just working nowadays, and the ecosystem of pre-made Actions is in good shape.
self-hosting GHA Runners (plural!) is ... hard (not impossible, and quite doable with enough investment, especially if one takes the dive into the murky waters of k8s), but it's not officially supported. (what's supported is here's a tarball we support these distros ... have fun.)
programming in YAML is still bad, composability is still an afterthought, etc.
For hosted runners that might be true. The best experience I’ve had with GHA self hosted runners was simply using a beefy VPS. At my current job, the self hosted runners were hosted on K8s using Arc and it was a… very unpleasant experience. We switched back to GH runners (turns out the free minutes + a few bucks a month is enough for our use case), but if we need to go back to self hosted I’ll advocate for a VPS.
> programming in YAML is still bad, composability is still an afterthought, etc.
I disagree on that. GitHub actions are as composable as it gets thanks to the ecosystem of actions. GHA is better than GitLab CI in this regard, and probably the best system I’ve used so far. It IS a bit clunky but overall I’ve been pretty satisfied with it.
I also disagree regarding YAML because you don’t program a CI, it’s mostly declarative work. The only conditions needed are a bit clunky to setup, I give you that, but it encourages to either keep the CI simple (no CI needs overly complex conditions), or move the logic to CI scripts in any scripting language.
Thought I'd plug my product because of the mention of actions-runner-controller on k8s. I wouldn't wish that on my worst enemy :)
It is a terrible experience riddled with many gotchas. I'm making WarpBuild to provide runners (cloud and BYOC on user's aws account) to provide more powerful, faster, and overall much better experience. Try us out - you're guaranteed to save both money and time.
it has to be reusable to be composable, ie. it needs some genericness, customization, etc. that usually requires logic, passing args, env vars, etc.
yes, writing programs (ie. an action) is the correct level of abstraction, but in general it just doesn't make much sense to have separate steps. (because for many cases unit testing and building artifacts can/should be done at the same time ... for example python/rust ... inside a container, download deps, build, then run tests, copy result to new layer, push)
> self-hosting GHA Runners (plural!) is ... hard (not impossible, and quite doable with enough investment, especially if one takes the dive into the murky waters of k8s)
Pre Microsoft I felt Gitlab was a lot better. It had a lot more features that actually worked. This was an era where Github didn't even have a built in CI solution.
Last time I used it, which was a few years ago now, it felt like Github had caught up and a lot of the Gitlab features were flaky or didn't seem to serve any purpose other than checking a sales tick list. Stuff like integrations that don't seem to really serve any purpose other than to say they are integrated.
> Stuff like integrations that don't seem to really serve any purpose other than to say they are integrated.
I don't think integrations are the example you think it is. The ones I tried work well and make it trivial to setup features that would otherwise feel like papercuts. I'm talking about things like being able to handle gitlab events without having to manage anything or provide your own event-handling infrastructure. If you have web hooks you need invoke or react to, as anyone who runs full CICD and cares about blocked pipelines does, with GitLab you don't need to worry about exposing custom endpoints and write controllers. For many, that is the difference between using notifications or not.
You can't pull a docker image from a private github container registry without a personal access token. Gitlab's group and project level deploy tokens are great.
That's not how I remember it. I agree that GitHub is ultimately the more polished product, which is why I eventually went back with my personal projects to it... But most of these platform features like CI Integrations, project repositories etc started at gitlab, and GitHub effectively copied them later
I think the Gitlab experience is slightly better when dealing with collaboration on private repositories with multiple people not necessarily in the same org. Also, Gitlab had free private repo support beyond what Github offered for a long time, so most of my private repos are on Gitlab.
As DevOps engineer I've used and managed both Gitlab and Github extensively, and Gitlab is just so much better. Things make sense there. Shame that it's so darn expensive.
Same. Been using Gitlab for years, but joined a new company using Github. I was appalled by how bad everything is compared to Gitlab, but especially ci/runners vs actions.
When you say managed, do you mean self hosting, or do you mean using the platforms for devops?
I can see how GitHubs self hosting story might be worse, because it’s just not designed for that, most companies don’t do it anymore, and I believe the product is deprecated.
As for doing devops from the platforms, I always found GitHub Actions better than GitLab CI, but I realise many feel the opposite.
> They literally offer no significant advantage other than being an alternative to Github.
I can self-host the community edition for free, and in addition to use it as a software forge and static websites hosting and deployment platform through GitLab Pages, I can use it to manage my users and have third-party services (like mattermost, hedgedoc pads, and other internally developped apps) for centralized login.
I really really hope that the buyer will keep the Community Edition alive, otherwise we'll have to move everything over to something else (I don't know what yet).
If you are using it for work, then it might be better to make everything paid. That would probably also reduce the cost per user, because we would have more users.
Per-user prices would be way to expensive. Thé self-hosted GitLab instance I manage is used for teaching and research. We don't use it to make money in any sort of way. We don't have the budget to pay for it. If we have to pay in the future we'll just (painfully) switch to another solution.
> I'll go rather go back to paper than to just move every last bit of my companies data into the hands of a single company (looking at you, Microsoft).
To me, given he critical importance of a working CICD, it feels like Microsoft controlling both GitHub Actions and Azure Pipelines poses a significant risk of having the proverbial rug pulled from under you. I don't expect Microsoft to invest on GitHub Actions enough to make them the clear winner in UX and cost, for example. Both Azure Pipelines and GitHub Actions are appallingly bad in UX, at least compared to GitLab CICD or even CircleCI or Travis, and I don't expect to turn that around due to their incentives to not make either one too competitive regarding the other in-house service. But that's just me.
The two best CI tools I've ever seen were Gitlab, as its approch was just working good (tm) and Teamcity, as its approach with the UI & Kotlin integration was just nice.
Then I've seen Azure Pipelines, which seem like an unfinished product because it competes with Github Actions, and then there is Github Actions which seem to come from someonw who loves to write k8s yml files (they do what they do, but they're unreadable).
Not GitHub Actions but Azure Pipelines: The sheer endlessness of logs, even for the smallest tasks there are hundreds of lines of logs, and it's nearly impossible to find the line you need if something went wrong.
Not the parent, but I'll bite: they are not the same. GitHub offers significant advantages over Gitlab, while Gitlab doesn't. Therefore I use GitHub. Once upon a time Gitlab had an advantage: they allowed private repo hosting for free. Now it's gone.
>They literally offer no significant advantage other than being an alternative to Github.
Gitlab had many features first. Namely, they had integrated CI way before GitHub did. Their open CI runners are really cool and easy to setup. GitHub had to scramble to put out their Actions product to compete.
I don’t know what the feature comparison looks like today, but many of the innovative features you probably use on GitHub were on Gitlab first. They had a way more innovation velocity for quite a while.
> I've also never felt compelled to use Gitlab. They literally offer no significant advantage other than being an alternative to Github.
I completely disagree. GitLab undoubtedly has the best CICD service. GitHub Actions feel poorly designed and half-baked in comparison to the point they barely feel prod-ready.
It's interesting to read into the thought process of anyone picking GitHub vs GitLab, because, other than being the default with tolerable shortcomings beyond copilot, there is no compelling reason to pick GitHub.
If anything, GitLab's Achilles heel is it's massive Product Management problem. I recall that access to some features like Group Access Tokens were unexplainably removed from free access without updating documentation or even it's UI. Apparently some GitLab PM made a call to pull them out without bothering to check for the customer impact loose ends, and all loose ends were simply left in place for customers to repeatedly pester support without any action.
I use both extensively and lean towards to opposite statement, though not as strongly.
GitHub Actions feels much more well thought out to me. The templating feels less hacky and the workflows via "uses" work really nicely for abstracting common bits of CI config into "packages". The downside is that GitLab CI feels easier to pick up and explain.
On the opposite side, GitLab CI feels like it was made for containers and k8s whereas GitHub Actions feels like it's just a VM (even if the runner software is technically more flexible than that). From a management perspective GitLab is nicer but as a user I often want to avoid thinking about any of the k8s quirks and just have an emphemerial VM to play with.
> They literally offer no significant advantage other than being an alternative to Github.
While I agree with most of your point, I'd suggest that being self-hosted is a fairly major draw for a certain group of people. There's a lot of overlap with the anti-MS cohort, but it's not exclusive. Most of the uses I've seen of GitLab in companies is those who stick it on a cheap VM and never pay for it.
GitHub has had a self-hosted offering in the past, the current availability is... cloudy, looks discontinued, they're trying to move people back online. It was always way more expensive though, targeting a completely different market to GitLab self-hosting.
Gitlab CI/CD is miles ahead of GitHub. GitHub is full of magic that you can't debug locally. Gitlab just makes sense and it's purely an orchestrator for stuff you can run locally.
They have a lot of advantages over GitHub as soon as you go beyond the simple task of hosting code and managing git workflow.
The main one are CI/CD Pipelines fully baked in: This is huge. It's fully integrated in the platform. You have full visibility over the CI/CD pipeline. You can even use their own runners.
One reason to use Gitlab is there CI much more powerful than Github Actions. I am converting pipelines to Github Actions/workflows at the moment and some limitations are just a pain in the butt. Like 8 workflow depth etc
> They literally offer no significant advantage other than being an alternative to Github.
In most large orgs I worked for they used Gitlab as their main platform (even though they had uses for GitHub too) for the main reason: they could host it whenever they wanted it and how they wanted, as opposed to GitHub where the only thing you can control is runners.
Sounds good on paper, but in reality you still need to pay the insane licensing fees if you need a usable product. It's like Android, I can download the source code and run it as long as I don't need extra features like a dialer and I don't mind majority of the Android apps not running on it.
If you need a truly open source solution then that would be Gitea not GitLab.
> Sounds good on paper, but in reality you still need to pay the insane licensing fees if you need a usable product.
Can you clarify what you mean by this? I ran a hosted Gitlab instance for a previous company for years with SSO, actions, container registry, on Gitlab CE. I never felt like I was missing anything.
While I'd definitely reach for Gitea if I wanted to be a purist about open source I honestly can't think of a Gitea feature that's not in Gitlab CE.
Their self hosted offering was really good some time ago. I feel like the peak was just after they added CI. Then it got bloated.
If you are trying to introduce source control to a traditional org that haven't been using it ever, then a self-hosted option with CI is a much easier sell than something in the cloud (in my experience).
For any kind of usage that needs github enterprise server, gitlab is a more viable solution in future. Software development infrastructure is important enough and complex enough that a single closed source solution cannot solve all problems.
Every time GL is mentioned, I am reminded of the 2017 incident where a person 'rm -rf' the primary pg data logs. The reenactment by Kevin Fang is always a good source of comedy on a bad day.
"pull request" isn't really native to git. "pull" is. A pull request is literally sending somebody a message and requesting that they pull a branch from your fork and merge it. A "pull request" in GitHub doesn't really do a pull under the covers at all.
"pull request" is a more recognizable term, but "merge request" is more technically accurate for what GitHub and GitLab do.
And is it really jumping through hoops to just name it something different? I usually think of that phrase as implying something more arduous.
That's a convenient generator for pull requests, sure, but a pull request is still a human mechanism, not a git mechanism. The "pull request" itself is still just a message requesting a pull, not some concept that git (either the commands or on-disk representation) is specifically aware of.
To that point, GitHub still does not use git-request-pull or even pulls to implement PRs, so the name is still not correct there. GitLab's naming is more accurate.
I just think we should have standardized naming conventions in order to allow clearer communication, while the CS field is moving exactly the opposite way because every company wants to have their own, unique nomenclature. This is ridiculous and only creates friction.
Imagine mathematicians having ten different names for "a curve", half of them considered offensive because why not.
I think merge vs pull is a different development workflow, which might appeal different organizations, tbh I never liked much the need of forking the entire repository to be able to contribute. Gerrit also doesn't require you to fork the repo first. Anyway, from my perspective that's s feature that GL provides vs GH, not just marketing.
Because that’s the TAM without enterprise cross sell, which you only get once sucked up into the spaceship. Teams, GitHub, with Microsoft, Slack with Salesforce, Hashicorp with IBM, and so on.
You either grind and love the grind, and make peace with your slice of the industry (Automattic [$7.5B value], for example) or you sell out and up when you get bored or tired.
All investment must be recouped, even in a purchase. 8B is a proud sum and it'll be attempted to be extracted from the users first. This is the beginning of the end, as we have seen over and over again.
Because GitLab couldn't be bothered to be a great, reliable, focused, self-hosted code development and CI/CD solution. They had to tack on half-baked copies of every dev tool in existence.
They are a great reliable pretty focused self-hostable dev/devops platform with a lot of trendy shit as extra. Most of which you get for free... they executed the open core model as well as possible (in this sector).
What do you think they should have done better that would have helped them (their bottom line, growth, brand, sustainability, or some combination of these)?
There's probably not much money in just hosting code (especially considering that the market has been "commoditized to death" by ... GitLab itself, among others).
It tends to go in cycles, with phases where companies are merged into conglomerates and then phases where parts are spun off into separate companies. There are various reasons for both parts of the cycle.
Megacorps are too powerful and have the ability to spend to get to low costs and high margins. They can also spend heavily and take losses for years in search of that efficient mature product. Then there’s all the blatantly anti competitive stuff like bundling things into existing contracts. Nothing will fix the consolidation unless we talk about this more and change the law. It’s not healthy for society to be controlled by a government and a handful of too big to fail companies.
in the beginning, the universe is a soup of particles with small density variations, over time things pull apart, giant stars form and consume more matter, giant galaxies, expanding away from each other more and more.
As a small startup I know I'm not really their core buyer, but I absolutely love Gitlab.
It's a bit worrying to think about the impact a purchase/merger might have on the product.
What the article doesn't make clear is how much of the company capital is public? If the founder owns 45% of voting shares and Google/Alphabet has 22%, are only 33% of the shares actually on the public markets?
Yes. So in effect this means that - conditional on the bylaws - they (a coalition of majority shareholders) can agree to deals without doing (proxy) votes. But since it's a public company the deal has to be fair to all (!) shareholders too. (And usually that's why a vote is "nice to have", but not sufficient. See the case of Tesla and Elon's compensation package, where laws protecting those who voted no on the package will override the shareholder vote. [thought it's pending appeal, etc.])
Gitlabs increased revenues are only due to price hiking and removing of lower tiers.
For example my bill with no additional needed features has risen from 6€ per user per month or so to €29 in something like 2-3 years.
I’m sure any serious buyer would look through that and realise some major churn is about to happen as renewals hit. - especially as they will be wanting customer/rev growth.
Good fit considering they’ve both embraced remote, preventing potential value destruction by an acquirer. DataDog also going big into cloud security recently with product releases, so perhaps a more engineering/dev focused Wiz “grow and roll up” play. DataDog and Gitlab combined would be worth almost $45B.
But their products are quite different. There's a large market that self-hosts GitLab for data soverignity reasons, and Datadog has no such offering.
I'm a GitLab user, I can't use Datadog because our customer contracts forbid data leaving the system (PHI, BAA won't suffice). I would reconsider GitLab if they were acquired.
I don't dislike Github but prefer Bitbucket, I feel they're a bit underappreciated, in part due to the massive market share that Github has. This could help turn things around.
I've worked - like everyone else here, I believe - extensively with GitHub in the past, as it was the de facto standard 1 decade ago.
Then, about 5 years ago I started working in a company that went the GitLab way, specifically due to the CI/CD support they provided directly in the platform.
At first, I didn't like the change so much, but as the project kept going, and we invested more and more in CI/CD, I can't see any going back. There's just nothing in GitHub that would allow us this kind of control and flexibly and automation over the build/testing/release process.
I get it if for your own personal development you prefer GitHub (I still do), but for anything of a medium/big size that's willing to invest time and money into a fully automated release process, GitLab is the way. And I guess that's where the value of GitLab to investors lies, in its appeal to the enterprise sector.
I like GitLab's product but I don't like the developments they've made in the last few years. It seemed to me to have been captured by too many product managers trying to make a name for themselves and became less of a cohesive user interface/feature set. The cost kept going up as they hired more and more people.
I wonder what it means to the government use of it. Every government entity I’ve seen thus far uses gitlab. And I’m guessing because self hosting critical.
They really fucked up their pricing. There is such a steep cliff to climb these days. Literally starts at $30/user/month. You can almost get GitHub enterprise and Copilot for that price.
But their open core model, fully remote organizational structure, and overall product quality is highly valuable. How many open source distros self-host GitLab? Debian, Arch, Alpine, postmarketOS, any I'm missing? Then GNOME, KDE, and free desktop have their own instances. How many companies self-host or use gitlab.com? There is real value and momentum there. Would be a shame to succumb to impatience and AI frenzy. I doubt datadog can steward the project in the same way.
Self host Forgejo and truck on with all the same features in a tiny footprint.
Gitlab has always been massive bloat that takes way too many people to maintain, and way too many resources to deploy. Not to mention proprietary feature gating that is a major turn-off to community contributions.
Why would that be the conclusion? By all means self-host, but you can self-host git (including just bare git on a server cloned over ssh) and it'll suck less than going back to rcs.
Hopefully someone decent buys it and reshapes the direction without major layoffs.
I use GitHub because there is no compelling reason not to and that’s what we have at work. But GitHub is stagnating and I have the idea of them having even more market share. Their AI propaganda is also insane.
Many companies have no choice but to self-host to comply with export control regulations. We use GitLab and drool over GitHub the whole time. But this is one advantage for GitLab, fundamentally we won't use GitHub because we need to control the data ourselves. Think for example of the defence industry, it's a big deal.
I've also never felt compelled to use Gitlab. They literally offer no significant advantage other than being an alternative to Github.
If I started over, I'd go with Drew's Sourcehut hub for the sake of actually shooting for something different.
I don't really see who would pay $8B for this business which has no moat-future.