I agree that RH's move is selfish and counterproductive, but I don't really agree with the "betrayal" rhetoric, except in a very limited sense.<p>The core CentOS devs who were "acquired", along with the people from other RHEL-clone projects like Scientific Linux who merged with CentOS, are being stiffed here; but arguably they should have known they were making this kind of a risk when they agreed to be acquired with a governance structure that allowed RH to overrule whatever the CentOS Board did.<p>The users of CentOS have no right to be upset whatsoever. They've been benefitting from millions of man-hours of engineering time RedHat have spent making RHEL without paying a penny for it. Granted this all benefitted RedHat, but that's beside the point -- if you don't have a two-way relationship with someone, you don't have any right to be upset when they change direction.<p>Pre-2014, all of those users should have recognized that the group making CentOS might disappear at any time, leaving them having to switch away from their current setup; post-2014, all of those users should have recognized that RedHat might change their attitude at any time, leaving them having to switch away from their current setup. They chose to take that risk because it was free. Now it's time to pay the piper.
Not sure if I agree with the conclusion. maybe this is an issue, maybe times have changed. From my personal experience the 'stable' releases are just to slow to keep up with the demands on frequency of updates.<p>To illustrate what I mean, and this is ofcourse very subjective and dependent on my use case etc:
I work on and manage hosting for RoR applications.
I have a linux laptop I cannot develop on because I cannot install a recent version of ruby. Yes I can compile it manually or whatever, but that defeats the point of having distros etc.<p>On our hosting platform we use AWS linux, which is based of Centos. The latest version of Ruby on AWS linux is 7 years old. Our app probably wouldn't even run on it.<p>So we use containers. Special custom ruby images with recent versions build in a stable debian base.
Now I have the problem that a.o nginx and nodejs have no recent versions available; versions that we either need for features or just because random dependecies.<p>So maybe the market for stable == 5+ years behind is simply not that viable anymore. Other distro's fill that demand and now centos can offer a distro for situations where you need a bit more recent versions.
I'm not sure what the issue is here, TBH. CentOS Stream is <i>not</i> a pure 'rolling' distro; it's still tagged by CentOS major release, i.e. there will be a CentOS Stream 8, CentOS Stream 9, etc. The "rolling" logic applies to <i>minor</i> updates within a CentOS major release, but even before this, it's not like RHEL or CentOS were publicly releasing backported updates to earlier minor releases, so practically speaking you were forced to be on the latest minor release anyway. People are correct to point out that this is somewhat of a trade-off in stability but it was always there. The one thing that's new with Stream is that there will be a faster release process for these updates, and that's a very good thing.
My company got burned badly by this move but to play a little devil's advocate: there's no such thing as free lunch as it turns out sooner or later. Free/Open source != free as in beer. You either pay it in financial support or sharing of development and maintenance of such projects. Sooner or later.
There's a possibility that this isn't the big deal people think it could be. It all depends on the day to day stability of Stream. Red Hat distros already have a testing repository channel for example. If stream updates are QAed through something like this the resulting platform may well be stable enough for many use cases. It would be no different to enabling the 7x/8x repo in the current releases.<p>In many respects I'd rather have a slow trickle of updates than the current flood of each point release. We've had lots of experience of dealing with all those changes landing at the same time breaking things.
These stable packages just postpone the inevitable technological debt and when you have to pay the debt, it's too late.<p>I really hope these stable OS just die. Some debt could be avoided if RHEL/CentOS didn't exist.
So, it was my understanding that Fedora was the beta/testing upstream distro for RHEL. Features and development would go from Fedora -> RHEL -> CentOS, previously. With CentOS moving upstream of RHEL, it seems a bit strange doesn't the role overlap with where Fedora already is?
well as it says in the article "[with CentOS] you basically get a free Red Hat Enterprise Linux with same packages and same updates." - I assume that don't sit well with IBM, the owner of Red Hat the owner of CentOS.