---
# The State of Enterprise Linux in 2022
**URL:** https://crunchtools.com/the-state-of-enterprise-linux-in-2022/
Date: 2022-01-03
Author: fatherlinux
Post Type: post
Summary: Background Recently, the Enterprise Linux (EL) supply chain has been pretty interesting. The announcement of CentOS Stream as an upstream for Red Hat Enterprise Linux (RHEL) in late 2020, the announcements of Alma Linux and Rocky Linux as downstream rebuilds, and the announcement of AWS Linux 2022 being built as a downstream of Fedora areContinue Reading "The State of Enterprise Linux in 2022" →
Categories: Articles
Tags: Community, Container Engines, Linux, Red Hat, RHEL
Featured Image: https://crunchtools.com/wp-content/uploads/2022/01/The-State-of-Enterprise-Linux-in-2022-2.png
---
## Background
Recently, the Enterprise Linux (EL) supply chain has been pretty interesting. The announcement of [CentOS Stream](https://blog.centos.org/2020/12/future-is-centos-stream/) as an upstream for Red Hat Enterprise Linux (RHEL) in late 2020, the announcements of [Alma Linux](https://www.businesswire.com/news/home/20210330005690/en/CloudLinux-Establishes-AlmaLinux-Open-Source-Foundation-Launches-First-Stable-Release) and [Rocky Linux](https://news.itsfoss.com/rocky-linux-announcement/) as downstream rebuilds, and the [announcement of AWS Linux 2022](https://aws.amazon.com/about-aws/whats-new/2021/11/preview-amazon-linux-2022/) being built as a downstream of Fedora are all really big movements in this space. Even going back to 2019, the [announcement of Red Hat CoreOS, with CRI-O](https://www.redhat.com/en/blog/red-hat-openshift-container-platform-4-now-defaults-cri-o-underlying-container-engine), as an image-based version of RHEL 8 managed by OpenShift 4 was a completely groundbreaking way to think about managing an EL server. This makes the beginning of 2022 a great time to take a look at the EL supply chain, identify the major suppliers and consumers, and do a bit of public analysis.
I wrote this blog because I think most of the public perspectives, analysis and critiques, in blogs, on Twitter, and such, come from members of the upstream and downstream communities. While I think these community focused perspectives are very good, and important, I thought it might also be interesting to hear the perspective of somebody actually responsible for the business health of RHEL Server. I’ve seen a lot of wild theories on why Red Hat makes some of the decisions it does, and I think transparent articles like this might help quell those. For full transparency, **I work at Red Hat and I’m the Product Manager for RHEL Server**, so I have my expertise and my biases, but I try to be fair to each of the projects discussed. My daily focus is on paying RHEL customers, and I’m not shy about that, but these are my personal thoughts, and not those of Red Hat officially. I warn you to read this post with your own critical eye, but this is similar to the voice you’d get out of me if we sat down and had beer together.
OK, with that out of the way, let’s take a look at a drawing to help us break down the basic relationship between the major *suppliers* and *consumers*. But, before we do, let’s quickly define what a *supplier* and a *consumer* actually means in this context. In the [Delicate Art of Product Management with Open Source](http://crunchtools.com/the-delicate-art-of-product-management/), I propose that open source projects can be thought of as suppliers in an open source supply chain, much like the supply chain in any manufactured products. For example, Volkswagen buys fuel injectors from Bosch and Tesla buys tires from Michelin. In this same way, open source products and projects rely on suppliers, the difference with free and open source software is, you buy it with your time, instead of money. I think it’s a useful model for analyzing the EL space.
Before we dig into the state of EL in 2022, let’s go back a short three years and see what things looked like in 2019.
## The State of Enterprise Linux in 2019
In 2019 things were fairly simple. Fedora was the place where innovation and development happened. New versions of upstream code were integrated, tested and used in Fedora. The focus has always been on innovation over a long life cycle..
Then, every 3-5 years, a new RHEL release would snap from an upstream version of Fedora. For example, RHEL 8 was based roughly on Fedora 28. This RHEL work would continue for a period of time, really behind mostly closed doors, and then it would be released to the world as a new major version, along with the *full* source code. Technically, releasing all the source code is not a legal requirement because many of the packages which are included in RHEL are released under less restrictive licenses which don’t require redistribution (Apache, BSD, MIT, etc). Red Hat releases the full source code because we think it’s the right thing to do.
When a new major version of RHEL is released, the Fedora project builds and maintains a community supported package repository called Extra Packages for Enterprise Linux (EPEL). Versions of EPEL align with major versions of RHEL and often enable RHEL customers to more easily run workloads which have dependencies which are not supported in RHEL. To be clear, these extra packages do not carry the same level of support as those that are in RHEL but they are quite usable and often at a quality level similar to Fedora. Many people rely on software in EPEL because it’s easier than building and maintaining packages themselves, and they’re OK with incurring the risk, because they can always build the packages themselves if necessary.
[](http://crunchtools.com/wp-content/uploads/2022/01/The-State-of-Enterprise-Linux-in-2022-1.png)
Once this new major version of RHEL is released, the downstream derivatives like CentOS Linux and Oracle Linux would begin their work and attempt to release as soon as possible. This is pretty much what the ecosystem looked like for RHEL 4, RHEL 5, RHEL 6, and RHEL 7.
Historically, one of the challenges with this ecosystem is that the RHEL derivatives really didn’t provide a lot of value for paying RHEL customers, which means it wasn’t sustainable open source. When a bug was filed in CentOS, or a patch offered, there was really no way to get the code into RHEL. A given major version of RHEL was, for all intents and purposes, a read-only open source project, similar to Google’s Android.
- RHEL Customers could file support tickets with Red Hat and have their voice heard, but there was no solid process for submitting patches or pull requests
- CentOS Linux users could file bugs with the CentOS Project, and they mostly went nowhere
- Oracle users, it seems, mostly waited for Red Hat patches to be released and incorporated into OEL, similar to CentOS Linux, though there seems to have been some cases where Oracle would do the work and patch something before CentOS Linux
- Contributors could submit patches to Fedora, but then they’d have to wait 3-5 years to see their changes land in the next version of RHEL.
As can be seen from the list above, this model from 2019 created misaligned incentives. Most users couldn’t really effect change in a given major version of RHEL or be good members of open source communities and contribute back. This model promoted usage, but not contribution. Looking forward to 2022, I’m happy to say that those incentives are looking a lot more aligned…
## The State of EL in 2022
Fast forward to 2022, and the supply chain of upstream and downstream projects and products is quite a bit more complex. This is a testament to the health of the EL supply chain and I’m optimistic that this will promote contribution as well as adoption and growth of RHEL as a technology standard.
Fedora remains the source of innovation for the entire EL ecosystem. In general, packages start out in Fedora and are only included downstream once they are considered mature enough (stability, security, performance, customer need, etc). CentOS Stream is now the upstream for RHEL and development of the next version of RHEL (RHEL 9 at the time of this writing) happens in the open. This is a major change which gives contributors a chance to influence the next major version of RHEL, as well as submit patches during its life cycle. This is a critical difference which makes RHEL 9 very special in my mind.
The CentOS project can now welcome contributors from far and wide, and the changes in CentOS Stream benefit everyone, including RHEL users. This better aligns the incentives between Red Hat and CentOS, fostering a real community. This also gives the RHEL derivatives a chance to contribute to CentOS Stream for their own benefit, promoting sustainable open source (a hot topic nowadays given examples like the [recent log4j exploit](https://arstechnica.com/information-technology/2021/12/patch-fixing-critical-log4j-0-day-has-its-own-vulnerability-thats-under-exploit/)). If RHEL goes away, so do the RHEL derivatives. Let that sink in…
[](http://crunchtools.com/wp-content/uploads/2022/01/The-State-of-Enterprise-Linux-in-2022-2.png)
Now, let’s talk about some of the dynamics with the major suppliers and consumers in this supply chain.
## The Major Suppliers
Fedora supplies CentOS Stream and EPEL, CentOS Stream supplies RHEL, and RHEL supplies the rest of the ecosystem. If users want to push the boundaries of what’s possible in Linux, they are welcome to contribute to Fedora, but if users just want to nudge the direction of RHEL, they contribute to CentOS Stream.
In 2022, there’s still an open question as to whether most non-paid users really want to consume CentOS Stream as a replacement for the original downstream CentOS Linux, but there’s definitely evidence of success if you search Reddit, HackerNews, Stack Overflow, Quora, etc. Knowing RHEL from the inside, I think CentOS Stream is viable for most development use cases, and light production use cases. If somebody needs a heavy production use case, making a bunch of money, I don’t know why they wouldn’t want to use RHEL (more on free RHEL later).
There’s also evidence of people not being satisfied with a continuously delivered distribution which releases patches asynchronously, even if those changes are tested, often minor, and generally non-disruptive compared to a standard Linux distribution. For those people, I’d first recommend checking out the 16 node, no-cost RHEL individual developer subscriptions. You can use these personal no-cost subscriptions even if you are part of a larger commercial or government organization. These 16 nodes can be used by the individual developer for demos, prototyping, QA, small production uses, and cloud access (aka at AWS, Azure, GCP and friends). You get full access to patches and with [Simple Content Access](https://access.redhat.com/articles/simple-content-access), even subscription-manager is easier to use. For more information on how to get these subscriptions, check out the [No-cost Red Hat Enterprise Linux Individual Developer Subscription FAQ](https://developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux). I have to think that this is a great option for original CentOS Linux users.
OK, with that out of the way, let’s move on to the major consumers in this supply chain.
## The Major RHEL Consumers
To simplify this, I’m going to break this down into three classes of consumers:
- Red Hat Consumers
- Fedora Consumers
- RHEL Derivative Consumers.
### Red Hat Consumers
First, there’s the Red Hat consumers like [RHEL CoreOS](https://docs.openshift.com/container-platform/4.9/architecture/architecture-rhcos.html) and [Red Hat Universal Base Image (UBI)](https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image).
RHEL CoreOS isn’t a standalone operating system, it’s built from RHEL bits, but released, upgraded, and managed as part of OpenShift. As of 2022, it can be thought of as an image-based RHEL 8 container host, managed by OpenShift. A better understanding of how CoreOS works can be found in this article: [Red Hat OpenShift Container Platform 4 now defaults to CRI-O as underlying container engine](https://www.redhat.com/en/blog/red-hat-openshift-container-platform-4-now-defaults-cri-o-underlying-container-engine).
If you’re looking for an image-based version of RHEL that you build and release yourself, outside of OpenShift, then check out [RHEL for Edge](https://www.redhat.com/en/resources/linux-for-edge-datasheet). This isn’t shown in the drawing above because it *is* RHEL. It’s built, managed, installed, and upgraded by the end user. It’s just a different deployment mechanism.
The next consumer of RHEL is Red Hat Universal Base Image (UBI), which is essentially a freely redistributable derivative of RHEL specifically designed for development and production use cases with containers. This makes it quite a good alternative to other RHEL derivatives, when your use case is limited to worrying about what’s in the container image (which is often true for developers). Really, UBI is three things. It’s a set of base images (micro, minimal, standard, init), a set of application images (python, ruby, node.js, httpd, nginx, etc) and a set of unrestricted RPM repositories which lets you update any UBI base image whenever and wherever you want. For more information, check out the [UBI 8 Product Page](https://catalog.redhat.com/software/containers/ubi8/ubi/5c359854d70cc534b3a3784e), [FAQ](https://developers.redhat.com/articles/ubi-faq), and [e-Book](https://developers.redhat.com/e-books/red-hat-universal-base-images-ubi).
Of course, I believe that the UBI images are the highest quality and most flexible set of container images available in the market. They’re built on the same trusted foundation as Red Hat Enterprise Linux and they provide container developers/users with access to proven bits that work just as well in production as they do in development.
### Fedora Consumers
This is a recent, and interesting breakthrough. Going forward, Amazon has[ announced that Amazon Linux 2022 and beyond will be derived from Fedora](https://aws.amazon.com/about-aws/whats-new/2021/11/preview-amazon-linux-2022/). I think we’re all still analyzing what this means, but it will be interesting to watch.
In particular, I’ll be watching to see if the Amazon Linux team contributes upstream, files bugs, submits patches and drives improvements in Fedora. This would be great as it would create more value for the entire EL supply chain, including future versions of RHEL. I’m hopeful, so let’s watch together.
### RHEL Derivative Consumers
This includes the likes of Rocky Linux, Alma Linux, Oracle Linux, Cloud Linux, Springdale Linux and numerous others. I don’t proclaim to be an expert on any of these downstream rebuilds, but they do seem to all follow a pretty standard pattern. They take the RHEL source code, put it back together, and release Linux distributions with distinct “brands” and distinct “value propositions.”
The good news in 2022 is, the builders/contributors of these downstream RHEL rebuilds can now actively participate in CentOS Stream to drive changes which everyone can inherit. It seems like a lot of the leaders in those communities understand that, and are actively participating, including in the [CentOS Special Interest Groups (SIGs)](https://wiki.centos.org/SpecialInterestGroup).
I’m very hopeful and optimistic that this will create a much healthier relationship with RHEL. Now, their users, when they file bugs, submit PRs or write documentation, can drive improvements in RHEL and the RHEL ecosystem. I think this is a fair trade and quite exciting.
## Conclusion
Looking back a year since the original [announcement that CentOS would shift focus](https://blog.centos.org/2020/12/future-is-centos-stream/) in December 2020, I think we’ve made a lot of progress. I think the upstream and downstream relationships are now solidifying and this is probably the most sophisticated supply chain for open source software in the world. I’m not aware of any other open source product that has created as much gravity as RHEL.
In fact, I’d argue that we are all still learning what this is, and what it can be, together. I think people forget that we’re not done learning about open source, open organizations, and how they scale. I think this is the largest scale example today, but might there still be larger supply chains in the future?
It’s exciting because I think there’s better potential for value creation in the RHEL supply chain, and therefore better value capture opportunities for everyone, including RHEL customers. Let’s look forward to another post in 2023 to see how things have evolved. In 2023, I’d like to analyze some of my predictions on how contributions are flowing, how they’re creating value, and how customers and users are capturing value.
---
## Categories
- Articles
---
## Navigation
- [Home](https://crunchtools.com/)
- [Articles](https://crunchtools.com/category/articles/)
- [Events](https://crunchtools.com/category/events/)
- [News](https://crunchtools.com/category/news/)
- [Presentations](https://crunchtools.com/category/presentations/)
- [Software](https://crunchtools.com/software/)
- [Beaver Backup](https://crunchtools.com/software/beaver-backup/)
- [Check BGP Neighbors](https://crunchtools.com/software/check-bgp-neighbors-nagios/)
- [Chev](https://crunchtools.com/software/chev-check-vulnerabilities-script/)
- [Graph BGP Neighbors](https://crunchtools.com/software/grpah-bgp-neighbors/)
- [Graph MySQL Stats](https://crunchtools.com/software/graph-mysql-stats/)
- [Graph Sockets Pipes Files](https://crunchtools.com/software/graph-sockets-pipes-files/)
- [MCP Servers](https://crunchtools.com/software/mcp-servers/)
- [Petit](https://crunchtools.com/software/petit/)
- [Racecar](https://crunchtools.com/software/racecar/)
- [Shiva](https://crunchtools.com/software/shiva/)
- [About](https://crunchtools.com/about/)
- [Home](https://crunchtools.com)
## Tags
- Community
- Container Engines
- Linux
- Red Hat
- RHEL