> GitLab was the first code host to add more products (CI, security, ops, helpdesk, analytics, etc.) and create a whole suite, and GitHub followed.

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).

Gitlab used to stand alone in the "Github replacement" market, but these days Gitea is quickly closing in on them. I hope the competition will drive Gitlab to continue to compete, but the switch to "AI everything" makes me weary for its future.

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)…

GitLab is currently marketing itself as the "AI-powered DevSecOps platform" which in my view ditches it's history/brand as an open and transparent alternative to GitHub.

But GitHub enterprise is not a great product. So the other around, I wouldn't want to call Github a credible competitor to Gitlab.

Indeed. Github Actions runs because GitLab CI walked and Travis crawled. There's a clear evolution through line with how each laid the groundwork for the successor.

I disagree that GitHub Actions is much more powerful than GitLab. Both can be helped by a YC company, depot.dev, if you literally mean running containers quickly and reliably. GitHub Actions can be easier to set up if you like having stuff outside of your repo and an OCI image. GitLab may not have the actions library that GitHub has but it can pull docker images and that’s a powerful build library.

> I disagree that GitHub Actions is much more powerful than GitLab

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.

GitLab CI can suppress the checkout altogether, do stuff, and then trigger a downstream job.

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.

With great power comes great responsibility, and the responsibility to maintain what started out as “a few lines of groovy” is not one I’d ever take up again.

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.

Ah interesting, yeah the whole container build -> CI build has been a long-standing paint point for me across Github, GitLab, and even Jenkins. I will investigate what depot.dev is doing.... cause yeah, proper and intelligent on-demand rebuilding of based containers could be a game changer.

One of the founders of Depot here. Always feel free to ping me directly (email in my bio) if you ever want to chat more about container builds in general.

For sure! I've always felt like a bit of a loner in that the assumption in most of these platforms is that your build starts with either something barebones (just apt) or maybe your platform only (python3:latest).

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.