Carl George

It is there. There's been a lot of misleading messaging around, CentOS is dead or you have to replace CentOS. No. There's differences, you should understand them, but I think there are a lot of positive changes that people are missing out on it because they're not just buying the marketing line of somebody that says, I want to be the new CentOS. Well, That's kind of flawed.

Why don't you just be a distro on your own, make your own reputation, and then see what CentOS is doing. If it works for you, then keep using it. I think it would work for a lot of people. There are some people that, I think there's one guy I know at work that says that if you have a RHEL-sized hole, we want to sell you RHEL. 10 year life cycle, vendor escalation. Assurances.

Yeah, assurances, the partner ecosystem.

Before we started recording, I was telling Adam that one of the big value propositions that I know Red Hat talks about a lot, but I think a lot of people miss out on, whether it's just phrasing or it doesn't convey well, is that Red Hat has spent literal decades and countless amounts of money building a partner ecosystem with hardware vendors, software vendors, and upstream communities, right?

and the big value premise you're paying for when you buy RHEL, and I'm not a RHEL salesman, this is going to sound very sales pitchy. You're an engineer. I'm very low in the weeds.

Yeah, 2019.

I think a good bit of nuance to that is that, yeah, I've only been there since 2019. Relatively short, I've been in the CentOS and Fedora and Apple communities before that. I got hired out of those communities to do it full time at Red Hat, which is another huge value that they do is employing people in open source projects to keep making open source, which we have.

There's a whole track yesterday here at the conference about open source sustainability and sustainability versus freedom and choice and open source purists and things like that. And yeah, a lot of people, the dream is to get paid to work in open source. I feel great, I've achieved that dream.

Other people aren't as lucky or they get it like, I know my last employer had a thing where it was like, well you can do open source part time and then this much time you have to do these things inside the company. You have a lot of that. And I know a lot of companies, their OSPO offices, open source programs office or equivalent name,

They struggle around how do we get our engineers to be better open source citizens. They're consuming all this open source. How do we turn them from just consumers into making sure the things we depend on continue to exist long term? Which is a theme that I'd like to segue off of in DescentOS.

So, big question, right? I started going on a little bit, started talking about how I wish I had a diagram of Fedora branching from Rawhide into its releases. Every three years or so, we'll take one of those Fedora releases and we'll branch it again and start building the next major version of RHEL. That starts as CentOS Stream, but before we've announced it. It's still very early.

We're still forming pre-alpha days. We're putting all this stuff together. And then at a certain point, they have enough of the changes that they want to go into the next major version of RHEL. Like we want this version of Apache, this version of OpenSSL. Maybe it's the same ones at the exact time they branched. Maybe they go one forward, one back.

Maybe they add a few other features, build a few things differently. but that is the process of turning the Fedora fast-moving, innovative project into the enterprise product, and that happens through CentOS. There's a lot of chat about how they talk about RHEL compatible and like the Enterprise Linux standard, other people with other projects. There isn't really a standard.

There's Red Hat making a product, and to whatever extent there is a standard of Enterprise Linux, CentOS defines that. That is where it happens. And so, because it's happening there, you can influence it. You can actually contribute to it.

I know you all have a big developer audience, and the analogy I used earlier was that if you've got a choice between two libraries, one that is active development, getting features, you can contribute to it, whether or not you have the ability to or the intent to, the fact that you can contribute to a vibrant project that's growing and active,

Would you rather use that or something else that says, yeah, we're going to be exactly the same as the other thing. And if you send us a bug report, if it's in the other thing, we're just going to close it. And you can't contribute here. We are bug for bug compatible. There's this whole mythos about bug for bug compatible.

And really, when someone says I want bug for bug compatible with RHEL, what they mean is I want RHEL without paying for it. That's really what it boils down to. It's a pretty blunt statement, but it's true. What's different from the past when CentOS originally started was that you can get just RHEL for free. There's a lot of free programs.

There's the, and this is going to sound sales pitchy again, but I'm telling you how to get free stuff. There's the Red Hat developer subscription for individuals. Anyone can sign up and get 16 free RHEL instances to do whatever they want to with. No limits. You can even use it in a business. It's just a little fuzzy because it is individual, right? You can't agree to the terms on behalf of an org.

So for most businesses of more than one person, it's not really going to work.

There is also another program, Developer Subscription for Teams, that'll give you, I don't remember the exact number. It's high. It's in the thousands of free RHEL instances in your non-production environments if you're paying for RHEL in production. And then there's also programs for giving open source projects free RHEL.