CIQ, Oracle and SUSE are pooling their collective efforts to form the Open Enterprise Linux Association (OpenELA), a trade group committed to developing Linux distributions compatible with Red Hat Enterprise Linux (RHEL) by providing open and free Enterprise Linux (EL) source code starting later this year.
EL is the base operating system that RHEL and SUSE Linux Enterprise, Oracle Enterprise Linux, Ubuntu from Canonical and Rocky Linux from CIQ are built upon.
The effort is a direct response to a decision made by Red Hat to no longer make the source code for RHEL available to organizations that want to build RHEL-compatible platforms based on a Linux distribution. In place of RHEL, the code to enable downstream distributions of Linux that would be compatible with RHEL will be provided. The initial OpenELA will be on RHEL versions EL8, EL9 and possibly EL7.
Wim Coekaerts, executive vice president of software development at Oracle, said there have already been instances where organizations migrated from one distribution of Linux to another. The goal of OpenELA is to reduce fragmentation that might occur with RHEL source code no longer available to the open source community.
Alan Clark, a member of the SUSE office of the CTO, added that this approach will preserve the flexibility organizations have today as it is specifically applied to RHEL-compatible platforms.
It may be a while before RHEL-compatible distributions of Linux based on EL are available, but the time and effort required to replace the operating system is much less than in prior years. It’s not clear to what degree IT organizations are concerned about the Red Hat decision, but if they are, they will need to decide to what level they will swap out operating systems versus deploying a different distribution of Linux for new application environments going forward.
Conflicts involving various forks of projects continue to be an issue for the open source community. Mostly those forks are created because of differences in business models, but other factors play a role including the pace of innovation and, regrettably, personality conflicts among maintainers of open source software projects.
Regardless of the root cause for creating multiple distributions of any given project, each variant adds complexity that DevOps teams need to navigate. Dependencies on specific versions of open source software can create issues when specific capabilities are not available on another platform that a DevOps team is using to deploy an application. As a result, some organizations prefer a proprietary platform such as Windows simply because they perceive navigating the compatibility issues they may encounter to be more challenging than they can handle.
The trade-off is that open source software drives innovation faster as the pace at which contributions are made accelerates over time. It’s like most democratic processes—it’s a little messier than any other form of governance.
