Adding new functions to Red Hat Enterprise Linux: A process primer

People often wonder how to get new capabilities—new packages, new features in existing packages, or even bug fixes—included in Red Hat Enterprise Linux. The process for doing so is straightforward, but may be foreign to those with a background in traditional software products.

To summarize, the process is:
1)Get the new code accepted upstream.
2)Get it included in Fedora.
3)Get it included in Red Hat Enterprise Linux.

Although this article focuses on the Linux kernel, the steps apply to all Red Hat Enterprise Linux components and packages.

The key element in the process is that Red Hat tracks upstream. This means that Red Hat works closely with the open source community. Any new features must first be accepted upstream before they’re added to Red Hat Enterprise Linux.

There are numerous benefits to this approach. The biggest is that it keeps the OS and its users closely aligned with Linux as it evolves. There are no dead-end branches, incompatible features, or Red Hat-specific changes that must be maintained. New features added to Linux and key packages are easily integrated. It also means that all new development can and must be accepted by the community before integration.

There are also a number of challenges to the open source model. Some of these are misconceptions, while others have at least a kernel of truth.

Open source: Multiple paths to new capabilities
With proprietary software, only the owner of the software can add new features and capabilities. This makes the question of new functions quite straightforward. There is one source for new features, and they either agree to or reject a request for a new feature. If they don’t agree to add the requested function, there’s no recourse.

With open source development, there are many ways to add a new capability:

• The original author of the package can add it.
• The Linux distributor (such as Red Hat) can add it.
• You can customize your installation by adding it yourself.
• You can contract with or persuade someone to add it for you.
• Perhaps most importantly, anyone can add it.

With open source, it isn’t a question of who can add or enhance a feature or capability, it is a question of how widely that feature will be adopted. This changes the dynamics of adding new features from one of focusing solely on writing the code that implements the feature to one of addressing creation, integration, acceptance, and adoption.

Of course you can make any changes you want to your own copy of the code. But if you want broad use and support of your new features or bugfixes, you need to go through an acceptance process where other groups are persuaded to distribute and support the new code.

There is no single point of control in open source—there is no one who can order a new feature to be accepted. Red Hat can’t demand that others accept new developments by Red Hat. By virtue of being a recognized leader, we have considerable influence, but we must work within the community structure. This community includes not just programmers, but interface designers, testers, documentation writers, project managers, support people, and marketers.

So what’s Red Hat’s involvement?
Red Hat is both a developer/contributor and an integrator. We consciously chose to do targeted development and to build on the work of thousands of other participants in the open source community. That is, we want to be a part of this community, rather than going on our own. In some cases we look to the people with a vested interest in a new feature—for example, a driver for a new piece of hardware—to develop the needed software and push it upstream (i.e. get it accepted).