Carl George

There's programs for giving educational institutions free or heavily discounted RHEL. There's tons of ways to get RHEL without paying for it. But there are definitely scenarios where Red Hat once thinks that, yes, this person should pay for RHEL. And a lot of those people are the ones that they use CentOS rather than just, I want an operating system.

They wanted just to get RHEL without paying for it or get a discount on their RHEL. They'd use, you know, 10% of their fleet on RHEL and then the rest on CentOS to cut cost. That was never a good fit for it because of small, subtle differences in the engineering and how it's built. One of those is that Red Hat Enterprise Linux actually has overlapping minor versions.

You can stay on, say, 9.0 after 9.1 and 9.2 come out, still get security updates, and some third parties only certify on specific minor versions. So if you've got third-party vendor software that hard requires 9.2 using anything that's on, you know, like...

one of the other rebuilds that's on 9.4 on Centro Extreme that basically has 9.6 content right now, it's a little bit ahead on minor versions, then if a vendor requires 9.0 strictly, then it might not work. But Red Hat will sell you 9.0 still with security updates. 9.2 might be a better example, because it doesn't last forever, you can't stay there forever, it's just an extension.

But those overlapping things are things that community projects have never had. CentOS never had them. And the new RHEL rebuilds that are trying to claim that they're the new CentOS, they don't have them either. They also have corporate sponsors that sell those extensions. They're trying to make their buck too, which is understandable. We're all trying to make money in open source.

The big value prop that I talked about with Red Hat with the ecosystem stuff is that, not that you'll just go use this and it's a cheaper price than RHEL, it's that you can go to the people creating this software. A lot of times they're maintaining it in RHEL, they're maintaining it in CentOS, and often times they're maintaining it in Fedora too.

Not always, but there's a huge, huge participation from Red Hat in Fedora all the way. It is separate from Red Hat, but we're very involved at every step of the process. So if you can make a feature request and say, I wish this software did this thing, Red Hat can say, all right, that's a good idea. Here's how we'd go about it.

First, we're going to put it in the upstream project where we're also participating. Then we'll build it in Fedora. And then it'll go into either the next minor version of RHEL or the next major version of RHEL, depending on how disruptive the change is. And then they put it in CentOS Stream Next. And then it goes into RHEL after that.

So having people that are holistic across the entire pipeline, that's the expertise thing. From the engineering angle, that's the real value I see looking at it with a set of engineering eyes.

Sure.

You mentioned about how it works differently now. I want to go into that a little more if I can. What do you mean by that? CentOS and working differently, right?

The IBM acquisition stuff is kind of tangential, right?

So CentOS started outside of Red Hat. And then I think it started around 2004. About 10 years later, the project was kind of on the ropes. Maintainers were burned out. They had day jobs. No one was getting paid to work on it. And what Red Hat saw was that... And it's kind of weird. It's a bit of an incompetence thing.

We had inside Red Hat development teams using CentOS to build with because we couldn't get out of our own way and give our own teams free RHEL. It's super messy, and it's gotten better since then. But at the time, that was kind of the state of things. That's pretty funny. Yeah. Maybe I should talk about that. But I think it's hilarious.

I'm just kidding. Nobody's told me I can't say that.

uh but that kind of drove it they basically red hat was like we want this this project to keep existing and so we're gonna you know they made job offers to all of the developers most of them took it a few of them turned it down and then um they basically came into red hat partially they were still kind of kept off to the side they're like well you're still kind of duplicating this product but we want you to keep going and and uh exist and so they kind of sat in that limbo for a while where they weren't growing they weren't getting

They weren't getting people resources, but they had the resources they need to focus their full time on it, get a paycheck, and keep the project going. That was a little bit of an infusion, but we still had this problem around this whole bug for bug thing and also being a duplicate of the product.

There would never be a business incentive to put the same engineering resources into your product and this project that is trying to match it as close as possible. That would never make sense. No business person would agree to that. but because of all the nuance around how it was being used as a development platform.

But we also saw the pain points of it being a development platform that lagged behind the thing it was trying to match, right? CentOS would typically lag about a month behind on the minor versions, like RHEL 7.6 would come out, and then CentOS 7.6 would be, it'd be 7.5 for a while, they'd finish the rebuild and publish it, and about a month later you'd get it.

So those rebuild gaps were real painful for the developers trying to use it as a platform to build on.