Amidst all the news from AWS re:Invent last week—mainframe modernization, database updates, ARM-based Graviton3, etc.—one thing might have slipped your notice yet deserves the spotlight: Amazon Linux 2022. AWS CEO Adam Selipsky didn’t mention it in his keynote, though it did earn a tweet from AWS Compute Services VP Deepak Singh (though so did this chess match and this tree). But that’s probably appropriate since Amazon Linux 2022 is the kind of big deal that is meant to fade into the background while offering stability, security, and performance.

It’s also an interesting release as much for what it isn’t as for what it is. For the first time, Amazon Linux 2022 isn’t based on Red Hat Enterprise Linux (RHEL) code (and has never been based on CentOS, the longtime RHEL clone that made waves in late 2020 when Red Hat announced it would eschew a fixed-point release pattern in favor of a rolling, “stream-based” approach). Instead, Amazon Linux 2022 is based on the Fedora community upstream project.

Don’t think that’s a big deal? Maybe you should ask the other big cloud providers what they intend to do now that Red Hat has announced the end of life of CentOS 8 at the end of 2021. Want to sell the U.S. government CentOS-based services? CentOS is no longer FedRAMP compliant. Switch to RHEL or another supported OS or don’t do business with the federal government. Ouch.

Whether prescient or simply lucky, AWS’ focus on Fedora could well pay significant dividends. But for enterprises wondering what to do with the CentOS free ride about to end, it’s perhaps worth remembering that “free software” often isn’t free.

“The most abused software in the history of computing”

It makes sense that each of the cloud vendors would build on CentOS. After all, everyone does. Everyone. Take a look at the underlying OS for some of the largest software-as-a-service providers on earth and you’ll find plenty of CentOS. Dig into IBM’s consulting practice and how the company for years told its customers to “just use CentOS.” European fashion brands that would never countenance someone selling a knockoff of their uber-expensive bags run CentOS. The entire telecom infrastructure of China runs on CentOS. (Yes, really.) Facebook is CentOS-based, too.

Nor is this CentOS usage relegated to test and development instances. In a conversation with someone close to CentOS, he shared a comment by an executive at a large cloud provider with many big customers running CentOS: “This is the most abused software in the history of computing. Our top 10 users of CentOS have over 50,000 instances, and they’re the who’s who of the Fortune 100. They know what they’re doing. These aren’t developers running dev/test. They’re not small companies.”

Why? Because CentOS has long been considered safe. Sure, Red Hat tried to tell customers that running CentOS in production was the equivalent of running with scissors in your hand (“Go ahead, but you’re bound to get hurt!”), but the reality was that it tracked pretty closely to RHEL, and Red Hat spent years teaching the market that “RHEL = safe.”

With the announcement of CentOS Stream coming a few years after Red Hat acquired CentOS, Red Hat made CentOS less safe. Suddenly CentOS went from “trusted RHEL clone” to “sort of squirrely RHEL beta code.” As mentioned, many people complained, but it’s not clear they would have liked the alternative much more. For years the CentOS community had struggled to keep pace with its popularity. It’s nice to be popular but less so when (a) you’re not getting paid for that popularity, and (b) you’ve got some of the world’s largest companies (banks, telcos, etc.) running massive swaths of their operations on CentOS and therefore demanding all kinds of changes to the code. That’s a prime recipe for maintainer burnout, which is a prime recipe for enterprises getting cut by those scissors they’ve been running around with.

Something had to give.

Red Hat stepped in to stabilize the CentOS community by employing its primary contributors. Red Hat, for its part, wanted a stable base for higher-level community projects like OpenStack and OpenShift. Fedora couldn’t provide that base as it moved too fast. Of course, Red Hat also wanted free-riding enterprises to understand that there really is no such thing as “free software” in any pure sense. To make the change less obnoxious to developers and smaller businesses, Red Hat made a big change to the RHEL Developer Edition to make it much more accessible (read: free!), while making RHEL free for up to 16 servers, thereby giving schools and other smaller organizations a cost-effective way to run a tested, certified, and supported Linux.

Interesting times in the cloud

None of this helps the managed service providers that are having to grapple with the changes to CentOS. As I suggested, it’s not so much that these companies need Red Hat to support them. They’ve been running CentOS unsupported for years. But the very nature of the Linux they depend on has changed. Dramatically. It’s one thing to run a clone of a well-tested, enterprise-class Linux. It’s quite another to run on beta software without any security or performance guarantees.

This starts to look very much like the “running with scissors” scenario that Red Hat tried unsuccessfully to apply to CentOS prior to CentOS Stream. It’s suddenly a silly exercise in “tripping over dollars to save pennies” given that the operating system—the foundation for a company’s applications, databases, etc.—is comparatively cheap compared to enterprise spending higher up the stack.

What to do? One obvious answer is to pay Red Hat for RHEL. For those disinclined to do so, Google has suggested alternatives to CentOS and has partnered with Red Hat to help customers move to a supported operating system. It’s less clear what Microsoft proposes for its Azure customers. AWS has already switched to Fedora and offers support. Yes, that underlying code is perhaps best described as alpha code, but AWS engineers will actively contribute to the upstream to improve it, and AWS stands fully behind it.

This is where things get a little iffy for AWS competitors. No one really wants to support yet another Linux distribution. This is the reason we’ve settled on RHEL, SUSE, and Ubuntu. AWS is first to market with their Linux. Due to market share, they’re likely the only provider big enough to convince ISVs and others to support their non-RHEL-compatible Linux. Now it’s on Google and Microsoft to figure out how to live in a post-CentOS world without the market share necessary to convince ISVs and others to support their OS. Remember, the way Red Hat won the Linux market was by creating an ecosystem around its certified OS. I’m hearing rumbles that they may combine around a SUSE-compatible offering, but it’s too soon to tell.

The only certain thing is that Linux is interesting again. That may not be a good thing, since it’s supposed to be the quiet foundation that doesn’t attract any attention.

[ Editor’s note: An earlier version of this article incorrectly said that Amazon Linux was originally based on CentOS. As noted by CentOS and Fedora contributor Carl George, “[Amazon Linux] has never been based on CentOS. AL1 and AL2 were derived from RHEL source code with some things ported from Fedora. CentOS moving upstream of RHEL has no effect on this. AL2022 is based on Fedora because porting Fedora packages to a RHEL base is painful.” We regret the error. We had tried to confirm AWS Linux usage but hadn’t received a response by the time of publication. ]