How Red Hat’s Open-Source Negligence is Doing Actual Harm to the Linux Community (and Enterprise IT in General)

Linux is everywhere. It’s loved and relied on by many, and this technology shapes our world each and every day. The majority of the world’s top websites trust it to provide content to their users, and Enterprise IT wouldn’t be the same without it. The secret of what makes Linux so powerful, flexible, and scalable comes down to three things – open-source, passion, and community. And Red Hat is undermining all of those important aspects of what makes Linux the powerful, stable and scalable solution that it is – while also throwing their very own loyal customer-base under the proverbial bus.

In this article, I’m going to bring up several examples of how Red Hat has made misleading (or flat-out untrue) claims and promises, and also threw their own customer-base under the proverbial bus. But even with Red Hat poisoning their own water supply, the once-loved Linux company is only the symptom of a much larger problem. Company-backed Linux just can’t be trusted. Let’s take a look at why that is, but first we’ll summarize what’s happened recently.

Note: I’ve also released a video today that discusses this as well for those that prefer the audio-visual thing. This article will be slightly more up to date, but the moral of the story is basically the same.

Red Hat’s Most Recent Facepalm

On June 22nd, Red Hat announced that they were altering the specifics regarding how source code for Red Hat Enterprise Linux can be obtained. Some of the most critical distributions of Linux these days, such as AlmaLinux OS, Rocky Linux (among others) owe their very existence to this fact. But with the recent decision, Red Hat is essentially making that existence difficult to maintain.

In the many years I’ve worked with Linux, I never thought I’d see a time when Red Hat would literally be trying to destroy open-source projects. But as we’ll see as this article continues, that’s just the tip of the iceberg.

Red Hat causes Organizations to Endure Extra Work

If you’re a system administrator, you know how it is. You have to keep your organization’s servers running as best you can. That’s the job, and often, hours are long. It’s up to us to install patches, develop a root-cause analysis when things go wrong, and also upgrade to a newer release whenever our chosen Linux distribution reaches end of life. It’s not all that uncommon for this to feel like a mountain of work, but we love our job anyway. While we may be understanding when we have to give up a weekend, we’re less understanding when software itself causes us work, specifically, work that shouldn’t even be necessary.

The interesting thing here, is that Red Hat themselves have caused IT departments all over the world to become even more overwhelmed. Back in 2020, when CentOS (another distribution owned by Red Hat) changed direction suddenly, that meant that system administrators would have to either accept the new way forward, or move to something else if they didn’t like the direction CentOS was going. System Administrators chose CentOS 8 because it was a newer release of a tried and true distribution. It was stable, featured ten years of support, there was a lot to like. But what they didn’t know at the time, was that the release of CentOS 8 would later cause them to change distributions again, just over a year later.

AlmaLinux and Rocky Linux were among the top choices for an alternative way forward. They were built on the same source code as CentOS was, so they were able to provide system administrators a drop-in replacement for CentOS. This was an effort that was very much appreciated within the Linux community, even if adopting one of those new “downstream” distributions represented migration work in and of itself. So even though Red Hat pitched Enterprise IT a sudden curveball, we at least ended up with some really awesome new distributions of Linux – so there was a happy ending to this story. Unfortunately, the sequel was terrible. More on that later.

Red Hat Decisions are Harming Trust. Repeatedly.

When it comes to organizations, trust is everything. They need to trust their vendors, their employees, share holders (and more) in order to do business. For an organization that relies on their infrastructure, trust is even more important – their software decisions can make or break whether or not a threat actor is able to have an easy time breaking in, and the stability of their servers is paramount to online business. When a company can no longer even trust a vendor like Red Hat, that’s a very bad situation.

When CentOS 8 was discontinued in 2020, organizations missed out on 3,186 days of their promised 3,650 day support window. To be fair, Red Hat owns CentOS, and they can provide as much (or as little) support as they want to. Therefore, Red Hat didn’t do anything wrong from a “can they do that” perspective. (They can, and they did). But that doesn’t change the fact that they promised one thing, and did something else. Multiple times. That harms trust. And operating systems are definitely one of the top things that an organization relies on and needs to trust. By stripping away the support window that Red Hat promised users of CentOS, they undermined that trust.

And that heinous breach of trust should’ve been the ending to this story – it’s hard for an organization to forgive being put into the situation that they were. Instead, it was absolutely not the only occurrence of Red Hat making misleading or untrue claims. Another untrue claim was made on the CentOS FAQ article the company published to announce CentOS Stream being the new way forward (emphasis mine):

So here, it was being promised to organizations (and the entire Linux community) that source code for RHEL will continue to be made available for download. Due to this promise, AlmaLinux OS and Rocky Linux were able to exist. They rely on the source code at the center of this promise.

But what’s interesting, is that the screenshot above was taken from my recent video about this subject. I decided to take a screenshot of my own video because the pictured section of that website now looks like this (less than 24 hours after I finalized the video):

Yes, they crossed out that section. I have to give them credit though, they didn’t delete the original answer at least. This way, we have an actual tangible example of how untrustworthy they are, right there out in the open. It literally mentioned “Nothing will change about how the source code is published” just to completely go back on that. So, there you go, another outright lie, right there on their web site.

If any organization is able to trust Red Hat after this – it will baffle me. Red Hat has become the poster child for “take your business elsewhere”.

But I’m not even done yet.

Open-Source Stigma

There’s always been stigma in open-source, so to say that this stigma exists isn’t news. And to be fair, Red Hat themselves weren’t responsible for cultivating this stigma, they’ve had nothing to do with that (until now).

Let’s be honest, the idea behind open-source software and how it’s developed is somewhat strange. You’re able to download software, and the source code along with it, so you can even change it yourself if you so desire to do so. It’s a beautiful thing, but opponents will argue that allowing everyone to view source code may compromise security. I’m not going to argue that point since it’s largely irrelevant to this article. But during our current day and age, we’ve had our fair share of drama around open-source, and the more controversy the less adoption.

Some examples of more recent controversies include several accounts of library poisoning, bill of materials becoming the new norm, and even an entire University being banned from contributing to Linux. And how ironic that the first of the linked articles within that paragraph was from, a website owned by IBM (Red Hat’s corporate overlord) that’s also on the chopping block.

Putting all of this together, if any enterprise organization out there decides not to implement open-source software due to all of the politics and controversies nowadays, I can’t say I would blame their hesitance. Even though I’d disagree with open-source being a problem, I could understand why someone might think so.

With the recent news of Red Hat putting a paywall on their source code, the company is indirectly justifying organizations being nervous about open-source. In a way, this confirms their fears – Red Hat has always been a strong proponent of open-source, but now they’re locking it down. That’s sending a message to the Enterprise IT industry, but perhaps not the one they were intending. We literally have Red Hat creating additional stigma here, which is not only a detriment to the community that they serve, it’s also going to lower their own bottom-line when companies start to avoid purchasing support agreements due to Red Hat poisoning their own well.

Who should get paid?

Since my recent video was finalized, Red Hat made a statement regarding their stance on the entire situation. I’m not going to quote their entire response – instead I want to focus on this one quote in particular, from that article:

“I feel that much of the anger from our recent decision around the downstream sources comes from either those who do not want to pay for the time, effort and resources going into RHEL or those who want to repackage it for their own profit. This demand for RHEL code is disingenuous.”I feel that much of the anger from our recent decision around the downstream sources comes from either those who do not want to pay for the time, effort and resources going into RHEL or those who want to repackage it for their own profit. This demand for RHEL code is disingenuous.”

Of all the statements Red Hat has made, that might be the one that’s the most worthy of a facepalm yet. But the entire point of that comment was that people should be paid for their hard work. And you know what? I completely agree! I’m sure Red Hat doesn’t want to be a hypocrite and wants to lead by example, so I’ll suggest that the company start by paying these people:

  • Volunteer kernel developers that wrote the code that the company is profiting from
  • Individuals that submitted (or even fixed) bugs that were found in the code
  • All of the open-source projects that Red Hat uses in their distro, even those that develop common utilities such as text editors and any of the other countless things they profit from
  • Writers, bloggers, forum members or any of the other community volunteers to which a portion of their success can be attributed to
  • Even better, since it’s about being paid, why not pay all the people they laid off that lost their career at Red Hat due to the company making bone-headed decisions
  • Anyone else that contributed toward their success

To be fair, volunteers can’t expect payment. If they were paid for their contributions, then they’d be employees. But if these individuals can’t or shouldn’t expect payment, than neither should Red Hat.

And that’s just off the top of my head. But the hypocrisy doesn’t even end there. Here, with Red Hat’s recent (attempt) at a rebuttal, they’re claiming that downstream recompiles are “disingenuous” – but Red Hat themselves thought highly enough of these “downstreams” to purchase one. Yes, I’m referring to CentOS. The company is still backing CentOS (or its current iteration) and positioned it as a critical part of their build process. So they’re simultaneously referring to downstreams as freeloaders, while forgetting that CentOS itself was born from the very thing they’re trying to destroy!

In fact, if you want to watch a very accurate account of how Red Hat’s shenanigans are harming open-source, look no further than this video by Jeff Geerling. He was able to summarize the open-source issue in just over six minutes! And he has some very good points. Definitely worth a watch.

What it all means

Red Hat is obviously not the only Linux distribution owned by a company. But they’re certainly the most popular in the news right now, for all the wrong reasons. That’s part of the reason why they’re the focus of this article, but more than that, Red Hat has become the very best example of toxicity toward open-source. The only company that comes close is SCO, but give Red Hat enough time, and they’ll probably top them at this rate.

But again, Red Hat is just one example. Like I mentioned in my recent video, we also have Canonical dividing their community as well and causing controversies of their own (but with the focus on Red Hat recently, it’s hard to even think of Ubuntu right now.

The moral of the story is this – no organization should trust Linux distributions run by companies. They do not have your best interest in mind, as Red Hat has shown time and time again while making false claims and harming the very community they serve.

Let’s be clear – Linux belongs to US, and Red Hat is profiting from a community of passionate engineers and enthusiasts that helped it reach the top. Without us, there wouldn’t be a Red Hat. The company would do well to remember that.

Brand-New Course!

Discount Vouchers

Receive 5% off an LPI exam voucher!

Exclusive Member Features

Support the channel and receive exclusive perks!