Particularly for systems that are installed as appliances in customer data-centers, where you as the vendor are both (a) responsible for the appliance as a whole to continue working but (b) have little / restricted access to continue maintaining it, RHEL helps you sign long multi-year support contracts for said appliance with the customer while keeping your maintenance costs to a minimum (since the cost of hiring more support engineers then flying them out is going to be higher than the RHEL license cost).
Long term support and ability to have someone on the line when it breaks.
Not everyone (probably not many too) have experts that will track a kernel bug or know how some obscure interaction works.
If you have knowledgable people in-house the RHEL is essentially useless and WILL actively make your life harder compared to just installing Ubuntu or plain Debian as they like to mess up and segment software that normally would be in same repo... but if you don't, and "just need a software that happens to run on Linux", it's cheaper to pay for few servers than hire top level Linux expert.
When we used it many of the "wait, this doesn't work like in vanilla Linux" could be traced to some RHEL engineer changing stuff to work for their enterprise customers.
Like we had audit fail on too old SSH encryption modes enabled. The encryption modes that were disabled and deprecated in that version of SSH but Redhat brought it back with a patch, presumably to support some legacy environments of their customers.
They also do some utter mess with openssl, like removing a bunch of EC curves and various FIPS-related stuff of dubious security impact, re-adding sha1 support and bunch of other stuff
Once you are the default choice that has other network effects, so yes.
For example if you are a software vendor who needs to ship a proprietary kernel module - think something like software to control a lab instrument - only Red Hat has a credible kernel ABI scheme with the required scale (because of the reasons I gave in GP). So every ISV in this situation specifies RHEL and requires that you run your software on a purchased copy of RHEL for support reasons. And usually the ISV software costs many multiples of the cost of a RHEL license, so it's lost in the noise.
> only Red Hat has a credible kernel ABI scheme with the required scale (because of the reasons I gave in GP).
Other distros also don't change kernel version during stable phase so I don't even know what you mean by that. Hell, RHEL kernels have more changes than say a Debian kernel over lifetime of a version.
What Red Hat uniquely does is to backport features into older version of the kernel, so statements like "you need kernel x.y.z for this to work" don't really apply, you need to find whether they backported that feature or not.
We've also experienced some "fun" with how they manage it and versions in general for example:
* Driver bug was backported from newer kernel (they backported "performance improvements" not bugs) in rhel5, so we lost VLANs on our upgrade canary
* Same bug was backported to rhel6 with same disastrous result 6 months later
* One of servers stopped booting because they changed version of LVM in STABLE DISTRO (think it was rhel6), and new LVM version deprecated/renamed some flag that we used, that made it fail on boot.
So yeah, we're very happy we migrated off it. And in Debian distro upgrade works too!
The thing is that, with RHEL and a good-enough contract, from a management perspective you can yell at them until it gets fixed. Everywhere else, you're on your own.
Sorry but paywalled content is really not a valid argument.
I agree with you that there is value in kABI stability, but this comment does nothing to convince others. Do you have a better freely accessible resource?
I have seen huge law firms use Redhat's distribution. There are service level agreements, dedicated support engineers as part of the contract. It is gives peace of mind, sense of security and large firms always prefer solutions that have enterprise support, you cannot cheap out when data/security leak can impact share price.
I think you've nailed it with this comment. A big organisation thinks completely differently to a small organisation or individual. A big organisation will happily spend a lot of money to reduce risk. They like having a number to ring 24 / 7 to support software that they depend on. The money they spend on a support subscription will be a tiny fraction of their profits, and so they don't blink at the cost, even though it seems a lot of money to you and me.
They also make Fedora which is the distro of choice for me and hundreds of thousands of others.
And I use RHELlikes (Alma/Rocky) in my homelab just cause its similar to Fedora and Red Hat's documentation is much better than reading random blogs on how to do stuff on Ubuntu/Debian.
One example is companies who don't need strict compliance themselves, but have some customers who do.
If 10% of your customers need this for compliance, then you have to test and certify that your stuff works with something like RHEL - and so that becomes an option, or even the default option for the other 90% of your customers.
Plenty, LTS is a big factor and a lot of companies now got burned with CentOS.
LTS is key because migrating OS and recalibrating everything is expensive as fuck for large organizations.
As the amount of manhours needed to migrate everything, retest and retool everything and retain and update all your internal documentation is stupendous.
Also having real support for a product is worth its weight in gold in a corporate environment because it allows you to offload responsibilities when stuff breaks.
When was the last time you got a feature your business needed included in the upstream kernel? Red Hat customers pay Red Hat engineers to take their business needs and turn them into upstreamed functionality.
