> If you're a freeloader...

It's dishonest to leave that conditional off the quote. The work and risk/stress involved in running a supportless shop is quite high. So if they are freeloading by using Rocky then Red Hat is also freeloading.

I do think it's funny that they weren't even number 1 on that list though. Guess they are at least getting a lot of volunteer work from other companies!

The others are almost all hardware manufacturers doing new hardware enablement.

There's also different types of contributions. Hardware vendors like Intel and AMD are mostly contributing their own hardware drivers (and a lot of that, especially in AMD's case, is just autogenerated hardware definitions), whereas Red Hat is mostly contributing to core kernel functionality.

It's hard to tell without more context of your own whether you're supporting what I said, or refuting the argument that Red Hat are freeloaders, which is an argument I did not make.

and that's just the kernel. Red Hat also runs or contributes to a bunch of other projects that are significant, especially relating to containers.

Not just containers, all the core linux stuff. gcc, binutils, gnome, systemd, etc.

One of the major differences between buying a support contract with RH and buying one from literally any other vendor is that RH doesn't sell support for things without having someone active in that project's community.

AKA, there is a good chance the gatekeeper that your !RH support provider is talking to is a RH employee or funded by RH. Put another way, rocky can't afford to hire 1k engineers to maintain all those packages, nor can anyone else so your trusting that the bug you want fixed can be fixed by a drive by contributor. This is part of the reason that RHEL has such a small package list too, just about every single package in that list has someone working upstream.

So, you won't get stuck like i did 15 years ago with a glibc bug that the company your paying a support contract to can't fix. Sure that distro patched their own version, but the change got dropped a couple years later during a rebase, and it was the only distro with the fix. Meaning our product only ran on that specific distro + version until we reopened the bug with RH and they actually got it fixed upstream.

To be clear, you're less likely to get stuck like that. There's plenty of bugs open that Red Hat doesn't fix because it's either too problematic or affects too few people. Sometimes that's eventually solved with a point release and them rebasing to a newer package version which includes an upstream fix, sometimes it just persists. I'm not saying it's common, but it's happened, and happened to us. Encountering a bug and finding the KB article with only workarounds and then a bugzilla entry that's been open for a couple years isn't exactly common, but I also wouldn't count it as all that rare in my experience.

Also to be clear, I wasn't making a case abovc that Red Hat doesn't provide a lot of benefit to the open source community, just that Red Hat could not exist without that same community. I do not begrudge Red Hat making money. I do think they're being extremely shortsighted if and when they shut off the larger open source community's uses of their core OS product. They're making their whole ecosystem much harder to get talent for if they do that, and it's not like entities running Rocky or Alma are just going to spring for RHEL. We trade on our staff's skill as System/Linux Administrators, and the core OS is not as important as all that. It's like if Python started requiring licensing fees. You'd get some short term return on that and some larger entities will just pay, but you'd see python usage in the general community plummet, with all that entails about its future.

Maybe to their eyes it makes more sense in this current world of startups and VC to just exclude the smaller players, since those companies that grow organically to a size where Red Hat's pricing makes sense are much rarer?

>Not just containers, all the core linux stuff. gcc, binutils, gnome, systemd, etc.

Depending on who you're talking to, this may not be a good thing.

... and looks like they're locking many of those changes to the source code behind their own paywall.

While it may technically be legal (ie crafted by lawyers to make sure of it), that still seems like a pretty shitty thing to do.

Red hat upstreams a lot of their patches, much more than Debian or Ubuntu.

I'm aware, I used to work for Red Hat (2010-2015). :)