Personally, I think that changing focus on CentOS Stream is going to make CentOS (and maybe even RHEL) better in the same way and for the same reasons that Fedora is a better distribution than Red Hat Linux was. CentOS Stream should fix the biggest problems that CentOS has had in the past, providing a reliable, free LTS distribution with community participation.
Having read the announcement, along with hundreds of reactions in blogs, forums, and mailing lists, I am of the opinion that all (or a reasonable approximation thereof) of the vocal concern is the result of the overloaded term "stable" as it applies to software distributions. If we imagine a spectrum of individuals in which one end of the spectrum is individuals whose primary occupation is in release engineering for software distributions and the other end is individuals who primarily consume software distributions, I would expect that individuals on one end to mostly use the term "stable" in the sense of compatibility and semantic versioning, and the other end to use the same term in the sense of having fewer bugs. The use of that word causes people at one end of the spectrum to infer a completely different message than people at the other end intend to communicate.
If we never use the ambiguous term "stable" and instead use the terms compatibility and reliability (the two common meanings of "stable" at different ends of the spectrum), I think that various aspects of CentOS Stream will be better than CentOS, or the same as CentOS.
With respect to compatibility:
I think most developers are familiar with semantic versioning. Semantic versioning is used by some applications and libraries to indicate the nature and extent of changes. The version is presented numerically as Major.Minor.Revision. When new interfaces are added, the minor number is increased. Those changes don’t affect backward compatibility. When individual interfaces are changed or removed, the major number is increased. Those changes aren’t backward compatible. That allows consumers to infer that if an application is compatible with 8.1, then it is also compatible with 8.2 and later, but might not be compatible with 9.0.
Red Hat Enterprise Linux applies that concept to the entire software distribution, providing independent software vendors a convenient means of communicating their compatibility. If they’ve tested their application on RHEL 8.2, then any RHEL 8 host patched to at least that release is expected to run the application. Moreover, Red Hat will continue to publish security patches to each given minor release’s channel, allowing consumers to "pin" a host to a minor release. Those hosts will not receive feature updates, but will mitigate vulnerabilities.
CentOS Stream isn’t going to feature minor releases, and isn’t going to provide semantic versioning of the distribution. The same application that the vendor has validated on RHEL 8.2 will run on a fully patched CentOS Stream 8 host, but might not run on a host that isn’t fully patched. On the surface, it appears that CentOS users will lose the convenience provided by semantic versioning. I would simply point out that the CentOS developers have never supported running CentOS in any state other than fully patched. They don’t publish security information in the package repositories, and they don’t support any means of pinning a host to a minor release.
For practical purposes, CentOS Stream will need to be fully patched for compatibility purposes, just like CentOS is, and will be equally suited for production purposes.
To put a really find point on that: Semantic versioning is only meaningful for hosts that are not fully patched. A fully patched host is expected to be compatible with any application validated for that major release.
With respect to reliability:
Many of the people concerned about the change in focus refer to CentOS Stream as a "beta" for RHEL. That is not how Red Hat or the CentOS maintainers describe CentOS Stream( anywhere that I've seen), and I think it ignores most of the development, testing, and distribution pipeline.
At the risk of oversimplifying that pipeline a whole lot, in the future Free Software will pass through several stages on the way to RHEL:
Stage 1: (Software Development) The majority of development and testing is done in individual upstream projects, outside of Red Hat.
Stage 2: (Release Development, aka Rawhide) The initial work to build and integrate individual packages with the rest of the software distribution is done in what is essentially a development branch of the software distribution.
Stage 3: (Stable[1], aka Fedora) Packages that have passed through review and QA are published for general use. There is no minor release, as major releases occur every 6 months and are supported for only 13 months, anyway. Compatibility is maintained by prohibiting significant version changes for applications and libraries "whenever possible." Users expect no new features during a release, but no breaking changes either.
Stage 4: (Long Term Support, aka CentOS Stream) Packages that CentOS Stream includes from Fedora have proven reliable in a variety of workloads managed by many users of Fedora. These packages are expected to be very reliable as a result of testing by their developers, by package maintainers, and by real-world users. They are included in CentOS Stream when they are ready.
Stage 5: (Long Term Support with Semantic Versioning of the OS, aka Red Hat Enterprise Linux) Packages that RHEL includes from CentOS Stream have a similar level of QA, but package updates that introduce new features and interfaces are accepted only once every six months when Red Hat publishes a minor release.
There’s a lot of concern that CentOS Stream will offer less reliability than RHEL, but there’s currently no reason to believe that will be true. There is no evidence that the minor releases that are part of the RHEL lifecycle improve reliability, and as far as I know that's not the reason they're used. Their function is to offer semantic versioning of the OS.
CentOS Stream will probably offer the same level of compatibility and reliability that CentOS does today, and should be equally appropriate or inappropriate for production use in the future as CentOS is now in that respect. And that brings me to the one aspect where I think CentOS Stream will resolve the one major, glaring problem that CentOS has today, that most users ignore: Security.
With respect to security:
Today, CentOS is a release stage after Stage 5 described above. The CentOS maintainers begin work on a minor release after that release is available to RHEL consumers, and the process of rebuilding those packages is often very time consuming. CentOS maintainers have to reverse-engineer the exact order in which packages are built, with the exact set of installed and available packages in the build environment in order to ensure that the resulting package actually uses the same interfaces that RHEL’s packages do. All packages require that ordering and build environment matching, but most packages are published in small sets and ordering is much easier to identify than it is when they are published in a large batch.
As a result, security updates can’t be published for CentOS while the maintainers are rebuilding the minor release, because the build dependencies aren’t available yet. Those windows occur every six months, and are typically a month or more in length. [2]
Today, CentOS users accept the risk that for roughly two months out of the year, their systems may have known vulnerabilities with no patch to remediate the problem. Personally, I think that’s a huge risk that needs to be weighed against the costs of RHEL licenses whenever CentOS is used in production.
The good news is that CentOS Stream looks like it won't have that problem. CentOS Stream updates still won’t be prepared early, while vulnerability details are embargoed, but there aren’t any windows in which CentOS Stream can’t immediately begin work on preparing updates once the embargo ends. That means that CentOS Stream will be as secure as CentOS is today in between minor updates, and significantly more secure than CentOS is today while its maintainers prepare minor releases.
The trade-off of significantly improving security in exchange for giving up semantic versioning of the OS is a huge improvement for production purposes.
In addition, the announcement of the change in focus indicates that Fedora maintainers should have much better visibility into work going on within the RHEL release engineering process, and more opportunity to participate in that work, and I look forward to that. CentOS’s big security problem has always been compounded by the lack of any external visibility into the process.
Based on the information available today, I expect CentOS to be a very reliable, reasonably secure distribution of GNU/Linux with Long Term Support. And judging by Red Hat’s mention that Facebook’s internal groups either are already using an internally curated OS built from CentOS Stream, or will be using it soon, I think I’m not alone in believing that.
1: I’m using the term "stable" here because I expect it to have both common meanings: compatibility isn’t broken within a release, and the software is expected to be reliable.