[JeremyNT]

It's the expensive k8s distribution for enterprises with large IT budgets. It adds enterprise-focused add-ons and is very opinionated. Its primary target is people who have a large existing IT staff dedicated to running on-prem / self-hosted, but lacks the expertise to run a "community supported" k8s distribution on their own, and maybe has no existing CI/CD workflows yet.

If your problem is "I have a BigCo with my own infra running RHEL" then it's almost definitely what you want. It follows the old saying of "nobody ever got fired for buying IBM." It gives your boss a vendor to yell at when things go wrong and its add-ons can provide an onramp for enterprise-type ops and devs who are still unfamiliar with CI/CD and containers.

Where it's not very good is if you're not a BigCo. If your org has one or more of the following characteristics consider other distros / managed cloud hosting first: a nimble ops team, existing cloud buy-in, a limited budget, a heavy "dev-opsy" culture (i.e. existing CI/CD/container processes), a desire to avoid vendor lock in, or less conservative management.

[PersonalOps]

I work for a company that recently reconsidered our stance on OpenShift. Long story short, we looked at vanilla k8s rather fondly because of nearly all of the counter-points. The factor that brought us back to OpenShift was the secure-by-default aspect and that some of the training wheels (OCP console) couldn't be replaced by vanilla in a secure way.

Here's what we do:

- We don't use "develop on OpenShift" features like Eclipse Che or on-demand Jenkins nodes to build a project

- We don't use OpenShift-specific resources if there's _any_ alternative in the vanilla kubernetes resource definitions (e.g., use Ingress instead of Route)

- Use outside CI/CD to handle building and packaging of the applications, then deploy them with Helm like any other Kubernetes cluster

- Use the OCP console like a crutch of last resort, preferring `kubectl` whenever possible

All of this helps avoid vendor lock-in as much as possible while still taking advantage of the secure-by-default approach to a kubernetes cluster.

Talking with Red Hat engineers, it sounds like the OpenShift-specific things are contributed upstream and, while they may not become available by exactly that name and syntax, essentially the same functionality does come into vanilla Kubernetes. Routes inspired Ingress resources, for instance. The official stance is for OpenShift users to prefer the vanilla resources because the OpenShift-specific ones are intended to be shims.

(not a Red Hat employee, just work for a company that is a customer)