redhat has benefitted from centos and the other clones immensely by the fact that an entire generation of SREs trained on their distro. entire businesses (like my old one) were built around partnering with redhat and providing support and consulting for RHEL and the clones.

the redhat partner network was bootstrapped on the back of the clones. you lab with the clones and then start working with the real thing.

and yes, sometimes users who wanted support went with consultancies like mine and not upgrading to RHEL, it’s true. but that does not matter because when consultancies like mine were working on large contracts with large commitments we would suggest that RHEL be used instead of clones so that there was a point of accountability.

and really, that is and remains the only reason to buy a commercial Linux system: the contracted accountability in the form of the SLA. if a deployment does not require an SLA, then withholding the product just creates a situation where they will use a different one.

that results in a brain drain: the users who would have stayed in your ecosystem (via a clone), will now go learn a different ecosystem. and this causes you to lose your partner network as consultants retire.

you will be able to watch this shift by observing the evolution of middleware.

for example, lets talk about, say, cPanel. yes, really: cPanel is still around, and people still use it.

or lets talk about SolusVM. yes, really: that exists too, and for better or worse, it is the backbone of the traditional VPS industry.

today, these are built and deployed on RHEL or, more commonly, the clones.

tomorrow? they will be refactored and deployed on alternatives.

if i were to make a bet, i could see OpenSUSE capturing that entire segment of the RHEL/clone userbase within 2 years. later, those products will likely move more heavily in the direction of containerization, but OpenSUSE gives them a landing pad for the short term.

and when that happens? there goes the bulk of the SREs who got their first taste of SRE work by managing a hosting provider. that remains a *huge* segment of the redhat trained SRE footprint.

mike's post on LinkedIn, where he says that redhat defines "freeloaders" as people who only buy a minimum amount of RHEL licenses while using the clones heavily is spin.

RH have always hated the existence of the clones. they have used various legal chicanery, arguably in violation of the GPL, to attempt to force customers into moving all of their machines to RHEL, and away from clones.

@ariadne The problem is Oracle. It’s my understanding RH helped the clones quite a bit, but this all started due to Oracle Linux.

@jollyrogue

actually, from what I have heard, the problem is Rocky in this case πŸ™ƒ

yes, for a while, RH embraced the "community" clones. but that was because there really was not any choice.

but, now, they would rather those users become perpetual beta testers for the next RHEL release instead.

as for Oracle and the other commercial clones: yes, there has been a lot of friction there, but Oracle fought back and as far as I understand, there has just been a quiet truce in recent years

@ariadne True. The clones were good marketing, and I’m not disagreeing with that.

Interesting about Oracle.

Is it Rocky? They seem to be the least problematic. πŸ˜† The new clones are all iffy all around, and I wasn’t going to touch them unless I was forced to, like GitLab did for a couple of my test boxes.

@jollyrogue yes, the problem is that Rocky is taking away users who they would like to redirect onto Stream.

@ariadne @jollyrogue I don't think it's just that; rebuilders are also taking users that would otherwise buy RHEL because they need certifications.

See FIPS for example. Getting certified is expensive. A huge amount of developer time goes into making the crypto libs compliant, the rebuilders just take that effort and re-submit. I have no way to confirm this directly, but I've heard rebuilders going around doing sales marketing with their certification (that they don't yet have).

@ariadne @jollyrogue Take a look at the "Rocky Linux 8.6 OpenSSL Cryptographic Module" submitted at https://csrc.nist.gov/Projects/cryptographic-module-validation-program/modules-in-process/iut-list.

Getting crypto FIPS-certified is what currently pays my salary, so I know a thing or two about it β€” but I have no idea how they plan to get OpenSSL on 8.6 (which is OpenSSL 1.1) certified under FIPS 140-3; that would require a huge amount of dev effort and many patches in my opinion. Where is that development effort happening? It's not here: https://git.rockylinux.org/staging/rpms/openssl/-/commits/r8

Implementation Under Test List - Cryptographic Module Validation Program | CSRC | CSRC

The IUT list is provided as a marketing service for vendors who have a viable contract with an accredited laboratory for the testing of a cryptographic module, and the module and required documentation is resident at the laboratory.  The CMVP does not have detailed information about the specific cryptographic module or when the test report will be submitted to the CMVP for validation. When the lab submits the test report to the CMVP, the module will transition from the IUT list to the MIP list. If you would like more information about a specific cryptographic module or its schedule, please contact the vendor.

CSRC | NIST

@ariadne @jollyrogue That leaves me wondering: are they just planning to get 140-3 certification for what RHEL ships and certified under 140-2? I don't think that's possible.

I may be wrong, but if I'm not: do they know that this is doomed to fail, and if they do, are they telling their customers that they never really expect to get that certification, or do they just happily go around and tell potential customers and users "yeah, it'll come eventually, just buy support now".

@ariadne @jollyrogue https://forums.rockylinux.org/t/fips-validation/4803/26 asks this exact question, but there has never been an answer.
FIPS Validation

Brian, I see that Rocky 8 OpenSSL is still IUT for FIPS 140-3. What version of Rocky 8 openssl is currently being tested for CMVP? RHEL8 is maintaining their 1.1.1 certification under the FIPS 140-2 requirements, but CMVP is longer accept new submissions for 140-2. With the RHEL8 upstream being OpenSSL 1.1.1, I am assuming that Rocky has submitted 1.1.1 for FIPS 140-3, but I have heard that there were new FIPS 140-3 requirements that may not be able to be met with OpenSSL 1.1.1. If Rocky is ...

Rocky Linux Forum