Each platform you support comes with an associated cost. Typically you require:
- A build environment
- A separate test environment (for example, not having the development tools installed)
- Additional time to build and test new releases
- Additional resources to support each platform
CentOS aims to be binary compatible with Red Hat which lessens the need for a separate build environment. However, if you don't also have access to a CentOS environment, at least for testing, you might get caught out by subtle differences.
Theoretically you might be unable to reproduce an issue that occurs on a user's CentOS installation on your Red Hat installation.
You might also have to provide different installation instructions for dependencies due to the different repository organisation.
Red Hat as of RHEL 7 has split things up into many more repositories:
- atomic host
- optional variants of the above
- supplementary repos for the above
- beta repos for the above
In fact I count no less than 85 (as follows):
>yum repolist all | grep rhel | wc -l
This does not seem to be the case for CentOS 7 (please correct me if I'm wrong)
Moreover things available in one RHEL repository are not compatible with some of the others.
For example, docker from atomichost does not play well on my workstation install.
from 2016 mentions that (Oracle) Java cannot be installed directly on CentOS:
Red Hat has a contract with Oracle to redistribute Oracle Java SE
binaries (including the JDK and JRE) and to support those products as
part of a RHEL subscriptions. CentOS does not ship Oracle Java SE;
CentOS users who wish to use Oracle Java SE must download and install
it directly from Oracle.
Security patches are generally applied to CentOS very quickly:
- How long after Red Hat publishes a fix does it take for CentOS to
publish a fix?
Our goal is to have individual RPM packages available on the mirrors
within 72 hours of their release, and normally they are available
within 24 hours. Occasionally packages are delayed for various
reasons. On rare occasions packages may be built and pushed to the
mirrors but not available via yum. (This is because yum-arch has not
been run on the master mirror. This may happen when issues with
upstream packages are discovered shortly after their release, and if
releasing the package would break it's functionality.)
Red Hat provide extended life-cycle support for older versions (at additional cost). This means that you can get patches for critical CVEs for RHEL 5 while CentOS can simply write off CentOS 5 as no longer supported.
Notably there have been several critical CVEs affecting RHEL 5 since it (and CentOS 5) reached end of life.
See also Is CentOS exactly the same as RHEL?
With the rise of Docker we have a new difference:
Docker Community Edition (Docker CE) is not supported on Red Hat
You must instead buy Docker EE license.
You can install Docker-CE on RHEL using the CentOS repositories.
See install Docker CE 17.03 on RHEL7
But this is obviously an unsupported configuration.
This is an odd one as that decision is made by the Docker team and not Red Hat.
So presumably Red Hat could decide to support Docker CE if they wanted to?
The essential difference between them is still the same:
If you want commercial support and certification you need to pay for it (use Red Hat)
If you don't want it you can use CentOS.
From the CentOS FAQ:
Red Hat and the CentOS Project are building a new CentOS, capable of driving
forward development and adoption of next-generation open source projects.
This is corporate blurb but it could be taken as meaning Red Hat want RHEL to diverge from CentOS in some interesting but unspecified way.