To be honest, you sound more like recent college graduate with minimal (no) experience working in enterprise.
You probably don't realize this given your lack of experience, but when you are running FOSS powered/adjacent enterprise equipment (think storage systems and compute fabrics) the bugs you encounter are often not things that simply show up on the first page of google.
There often isn't anyone to "wait" for (other than the resources you pay for), which is why if you value uptime and availability, you PAY for a support contract.
I was a staff level systems engineer at a major movie studio in California (owned a 24+PB tape library and a few petabytes of fast storage), and I can confidently say all of our dedicated support assets were valuable members of our broader team (first name basis, ask questions/raise issues with a text message, etc...).
In the rare occasion an engineer wasn't cutting it we would have our TAM get us a new one. Typically you are literally paying these people's salary as part of your contract so these are decisions that you as a customer actually have a lot of input into.
If you'd rather wait for someone to answer you on StackOverflow that's a decision you can make, but if you pull that move in any serious enterprise you will terminated pretty quickly.
The whole point of Rocky is to be bug-for-bug compatible with RHEL; your opinion on who can fix bugs faster is completely orthogonal to this discussion.
I'm flattered that I sound like a recent college graduate :) I've been a Unix systems administrator for more than a quarter of a century.
Wild generalization: Red Hat is mostly bullshit. Their support is good at handling the myriad quirks and bull they've intentionally added to their OS to differentiate their product, but they're not so good at things beyond that, in my experience. I'm generalizing, of course, but in too many instances Red Hat has been unique in having issues that other common OSes don't. In many environments I've set up proper servers with other OSes for comparison so I'd know when something is a Red Hat-ism.
If you're somehow authoritative because you've worked for a major movie studio with petabytes of storage, then I suppose I'm authoritative, too. I have and still work for major movie studios and I handle petabytes of storage, too :) Perhaps we know each other.
Red Hat couldn't get their OS to see all the zones of a StorNext, while at the very same moment identical hardware next to that Red Hat system running SuSE worked fine. Drives were swapped between the systems, and the problem followed Red Hat. It was a clean install. Red Hat support told us they couldn't do anything and said it was a StorNext problem. We contacted StorNext, and they were even willing to work with Red Hat. Red Hat required us to have a three way phone call to include the StorNext people and wouldn't answer their emails. I had to create email accounts for the StorNext people. It was extremely unprofessional and nothing moved on this until the company threatened to cancel Red Hat support entirely.
Unfortunately, my other experiences were more reminiscent of dealing with AT&T than dealing with an organization that wants to make things work.
You probably don't realize this given your lack of experience, but when you are running FOSS powered/adjacent enterprise equipment (think storage systems and compute fabrics) the bugs you encounter are often not things that simply show up on the first page of google.
There often isn't anyone to "wait" for (other than the resources you pay for), which is why if you value uptime and availability, you PAY for a support contract.
I was a staff level systems engineer at a major movie studio in California (owned a 24+PB tape library and a few petabytes of fast storage), and I can confidently say all of our dedicated support assets were valuable members of our broader team (first name basis, ask questions/raise issues with a text message, etc...).
In the rare occasion an engineer wasn't cutting it we would have our TAM get us a new one. Typically you are literally paying these people's salary as part of your contract so these are decisions that you as a customer actually have a lot of input into.
If you'd rather wait for someone to answer you on StackOverflow that's a decision you can make, but if you pull that move in any serious enterprise you will terminated pretty quickly.
The whole point of Rocky is to be bug-for-bug compatible with RHEL; your opinion on who can fix bugs faster is completely orthogonal to this discussion.