You are correct on this observation. The answer is most people/organizations don't actually know if they need to be RHEL compatible. Outside of any places that

You are correct on this observation. The answer is most people/organizations don't actually know if they need to be RHEL compatible. Outside of any places that have a compliance requirements, where saying you are RHEL compatible by using CentOS is the easiest path to checking a box. However if you are operating in an arena where compliance certification is needed you would just pay for RHEL and charge the cost to your customer. We paid for support for RHEV/RHV for a number of years and it was useless. You ended up troubleshooting most of the work yourself and in our case we could have just run Ovirt and skipped the whole inventorying and licensing of cores. The "having someone to blame" or a support contract baffles me for open source. Why advocate for using open source if executive suite is concerned with downtime? They aren't passing the savings back to you and what did having a contract save you if you have to get director or c-level people on the phone to escalate? Presumably they are getting paid more per hour than a number of other people. You have now paid support, plus Dev/Ops troubleshooting, then getting an executive involved. Not to mention how big does your organization need to be for a vendor to consider "your" issue to be a real issue to them. The back porting and LTS that most people talk about seems to be out of place for a time in which security is now falling under insurance and you need to be regularly updating anyway. Every security audit has one of these "banner shows this version, oh but wait did you check OVAL, or its a back-ported version" conversations. Wasn't this the point of all the fancy DevOps tools, workflows, containerization, etc. Shouldn't you be able to roll out new packages and OS versions quickly since you have all your automated tests implemented?