On various forums you can see people ask why Red Hat Enterprise Linux (RHEL) is chosen by so many over Ubuntu. Accepting the premise saying that both serve many of the same application needs, the short answer is often, support and documentation. Others may also add “lifecycle routines” as a crucial element to the mix. Logically, these benefits are closely linked to properties highly valued by most companies; stability (uptime), quick support (uptime), someone who actually can fix issues (uptime), and for enterprise level organisations, someone who can take the heat if s..t hits the fan (so you don’t have to fire your sysadmin). 

So what are the specific things Red Hat seems to have gotten right compared to Ubuntu? Let’s have a closer look.

Lifecycle routines

One of the first and most prominent things to take note of, is that the extensive support focus enables RHEL to have fundamentally different release lifecycles than Ubuntu. RHEL uses a minor-version stable release model, where each minor release (e.g., 9.1, 9.2, …) is an independent version with the ability to add Extended Update Support to ensure a longer support window. This provides a stable, long-term platform for environments with strict change control needs, but also comes with an extra support commitment for Red Hat. Their entire major release, normally consisting of around ten minor releases, is supported for 10 years.

In contrast, Ubuntu's Long Term Support (LTS) releases are only major-version stable. This means an LTS release is a single, continuous version, not a series of independently supported minor ones. While Ubuntu LTS releases are maintained for up to 12 years, they don't offer the same long-term feature stability found in RHEL's minor releases, probably due to the maintenance and support requirements that come with having such a release model. Lack of support can force you to choose a release format that might be sub-optimal for adoption among your users, even though we don’t know whether this is the case for Ubuntu choosing their particular release format. 

Robust security

With media writing about a constant flow of corporate data breaches and malicious hackers, governments are throwing out new regulatory standards and compliance laws on a monthly basis. This has led to having a firm security posture, taking preventive measures and complying with regulatory standards, becoming almost as crucial as the data itself. Such an approach has also become more important for smaller companies, with many claiming RHEL´s OS being one of the preferred solutions out there when weighting security. Red Hat has a customized build of their OS for everything major.

Ubuntu provides security checks only on packages from two repositories, where the largest being main. You can get security checks on packages from universe as well, being upstream Debian or the wider Ubuntu community, if making an upgrade. Even though this article is about Red Hat and Ubuntu, it is worth mentioning that for example Arch Linux don't have security teams, and are basing their security services solely on the community, which of course can work great for some users. The same goes for Debian, to a large degree, with some security patches being funded on a per-package level as opposed to complete repositories as with Ubuntu. 

This shows that large projects with significant user bases incorporate market-accepted security structures, by leaning on their communities. Maybe not good enough for the largest enterprises, but sufficient for maybe 90%+ of the market. 

Extensive documentation

To be honest, most large Linux distributors have pretty good documentation, and this surely includes both Red Hat and Ubuntu. However with a market-leading support focus, often follows extensive documentation. As good support can create good documentation if implementing solid tools and routines for transferring one-off support tickets to community-wide documentation. Many highlight RHEL´s STIG (Security Technical Implementation Guide) as unique, partly emphasizing the built-in automations and integrations such as the one with OpenSCAP. They also have multiple other more case-specific guides, as there is always someone else that has done what one is probably trying to do. That said Ubuntu also has great documentation and is praised by many for being accessible and community-centric. Being created to a large extent by the community, pro-bono support tickets often lead to an updated wiki. 

Best in class support, or?

As Red Hat provides support as a default part of the paid service, it is likely that you in theory can get your issue fixed faster than with Ubuntu, which means less downtime. However, there are several forum threads on the internet, not surprisingly, talking about bad support experiences with Red Hat. Yes, Red Hat often replies fast, due to the 19 000 employees vs Ubuntu/Canonical´s 1600, but the quality of the support is by many said to be sub-par. Despite having comprehensive certification programs for all new reps, it may be that the incentives just aren't good enough to stop turnover and retain Red Hats’s brightest engineers.  

Or maybe the quality must be considered against natural benchmarks, as this Experience from a reddit user: When I first was thrown into Linux at an Enterprise level, Red Hat support was better than Microsoft. Even if the problem existed outside of their product. Ok, so maybe it is better than other enterprise alternatives, but is it better than core team support for smaller repos? Probably not. Despite many claiming Red Hat is likely to employ a developer who actively participates in the development of the software, one long-time Red Hat employee we spoke to claimed that support was very much an own organization, while developers lived in Jira with little contact between the groups.

That said, it is important to note that “support” is not merely a synonym for “helpdesk”. In an enterprise context, it covers several other elements, such as an escalation path to the engineers that will fix the software if your environment is affected by a bug. It further includes periodic meetings with your account rep to discuss how the product is working for you and how the value can be increased (well, surely profit-motivated, but still convenient). 

Piecing it together - Takeaways for smaller projects

So what does this tell us? Well, it tells us increased adoption and a higher growth rate could be achieved if one has a good support system in place. Not alone, but among other things. Of course, high growth is not a goal for every project, and that is fine, but for many it is what they want to achieve: Have as many people as possible using their code. 

Despite very varied support experiences, many choose Red Hat over Ubuntu due to the comfort of having a solution that checks all the boxes; integrations, security, lifecycle maintenance, and support. And when you first have gone with a solution, the switching cost gets high, even though the experience might be something around average. This learning actually goes for any project regardless of size. You have to make potential customers comfortable with the thought of using your product. Having a system for support can help a long way with exactly that. 

Furthermore, having a reliable structured support in some way can let you have more integrations, more hardware-compatibilities, more releases, and so on. All these value-adding features may add great value to your users and increase growth and adoption for your project, but it comes at a cost - and that cost is usually more questions, bugs and breaking changes thrown your way from the community. In that case, you must be prepared to handle these reach-outs in an unoverwhelmingly way. Here structured support and community engagement can be your best friend. So get the bricks in place. It can be what tips the scale for a potential new user.