Not exactly. Maintain, perhaps, but Red Hat Linux was the standard before RHEL existed and everybody wanted a clone of Red Hat AS/RHEL to continue enjoying the free ride.
Let's also not forget that CentOS had a rocky (no pun intended) few years before Red Hat stepped in later on. A lot of folks gloss over the fact that there were periods of disarray with CentOS that involved some long gaps between updates, a whole kerfuffle about a founder disappearing and the domain ownership being in question...
CentOS, as a project independent of Red Hat, existed for about 10 years. This included several long periods of slow updates to minor versions and long waits for major versions of RHEL. (e.g. it took almost 3 months for CentOS to push out 5.6 after RHEL 5.6, and even longer to get CentOS 6 out of RHEL 6).
Before Red Hat took over CentOS a chief point of criticism was that CentOS took too long to update and the core group wouldn't let new folks in to contribute. (See: https://lwn.net/Articles/435744/ and https://web.archive.org/web/20190402181426/http://www.linux-...)
Now, users have Stream which is pretty much everything you'd have wanted except the ability to claim that it's exactly specific RHEL release. In my book a major improvement, unless what I want is the ability to get support for RHEL from vendors without actually paying for RHEL.
Additionally, CentOS Stream updates often lag behind RHEL updates. This is because Red Hat won't commit an embargoed security update to CentOS Stream until after it ships in RHEL, so the developers responsible for the update will sometimes forget to commit it to CentOS Stream until a week or two after it's shipped. You end up in a weird position where you get most updates faster than RHEL users, but you often have to wait to get critical security updates. I would be wary about using a system like this in production.
Or months, even. See httpd and php right now, and the CVEs solved this year. CentOS Stream doesn't have it, Alma has.
* httpd-2.4.37-54.module_el8.8.0+1256+e1598b50 (released 2022-12-08)
* php-7.4.30-1.module_el8.7.0+1190+d11b935a (2022-08-04)
Almalinux 8 is on:
* httpd-2.4.37-56.module_el8.8.0+3560+c8e5e57e.6 (released 2023-04-27)
* php-7.4.33-1.module_el8.8.0+3477+f828cbb0 (2023-01-13)
So meanwhile, for httpd the following was released:
* 2.4.37-56.6 - Resolves: #2190133 - mod_rewrite regression with CVE-2023-25690
* 2.4.37-56.4 - Resolves: #2177748 - CVE-2023-25690 httpd:2.4/httpd: HTTP request splitting with mod_rewrite and mod_proxy
* 2.4.37-56 - Resolves: #2162499 - CVE-2006-20001 httpd: mod_dav: out-of-bounds read/write of zero byte; #2162485 - CVE-2022-37436 httpd: mod_proxy: HTTP response splitting; #2162509 - CVE-2022-36760 httpd: mod_proxy_ajp: Possible request smuggling
* 2.4.37-55 - Resolves: #2155961 - prevent sscg creating /dhparams.pem
For php:
* 7.4.33-1 - rebase to 7.4.33, fix: due to an integer overflow PDO::quote() may return unquoted string
There are already issues filled in bugzilla:
Since before I became a Red Hatter, I have used CentOS for my personal servers and projects. I have struggled with CentOS Stream for that application, for example packaged kernel drivers from ELRepo. I can understand why many are upset about this. As a casual user, I am not upset, because I still have lots of options (RHEL Dev sub, Fedora, Ubuntu, Arch, etc.) If I had given a lot of time and effort that benefited the EL community, and in turn, Red Hat. I would probably be more upset.
I find myself torn on this issue. On one hand, I really want there to be a vibrant Enterprise Linux community where nobody has doubts or trust issues in participating. On the other hand, I also want Red Hat to continue to have a viable business model around RHEL so that the community continues to be able to benefit from all of the expertise that it gets from all of the people who get to make it their main focus because they can rely on a steady paycheck by doing so.
I think that when Red Hat was growing fast, it was easy for them to have a laissez-faire approach to downstream rebuilds. Now that the business is contracting, people have had to start making hard decisions. There's no more difficult decision to make, than to lay off people. I would not want to have a leadership role at Red Hat right now. I don't expect it's much fun.
I really worry about the impact that this has on goodwill. I think most people at Red Hat are also concerned about this. The ecosystem around RHEL will not be the same. EPEL, ELRepo, and all of the other communities that have flourished around the downstream builds are going to be impacted. Trust, when broken, is very hard to rebuild. Jeff's comments ("fool me once...") underscore the rift that is driving away good people. I worry about the long-term effects of this. I hope that this will not "kill Enterprise Linux" as many have suggested. I do believe, though, that it has been wounded.
Disclosure: I am currently employed by Red Hat.
From an outsider’s perspective, they were merged with IBM, “killed off” CentOS, and restricted access to the sources of their distribution within a relatively short span. It just looks bad and makes everyone feel like they have to justify that Redhat is still a good company.
Fully agree on the "PR Problem". It's tough to "control the narrative" in OSS. Based on my observations, I think Red Hat's approach is: Deliver the facts, ride out the storm, pick up the pieces and move on.
Well, you answered yourself why it went as it did. Don't you think answering to your shareholders is what keeps the company competitive and on the right course?
https://opensource.com/article/23/6/new-developments-opensou...
I'll bite. The value in RHEL was supposed to be in the support. CentOS helped establish and maintain RHEL as the defacto standard that everyone targetted and prevent the development of another. I mean if Debian becomes the default that actual reduces RHEL's value proposition for their paying customers. Reinforcing a platform's dominance is contributing value.