About EPEL

EPEL was started because many Fedora contributors wanted to use the Fedora packages they maintain on Red Hat Enterprise Linux (RHEL) and its compatible derivatives.

Goals of the EPEL Effort

Make high quality packages that have been developed, tested, and improved in Fedora available for RHEL and compatible derivatives such as CentOS and Scientific Linux.

Work closely with the Fedora Project to achieve this goal -- use the
same guidelines, rules, policies, and infrastructure, as far as
possible.

If we hit problems, solve the problems with the other parties and
groups of Fedora, such as Packaging Committee, instead of creating
EPEL-only solutions; EPEL-only solutions introduce confusion for
packagers and users, and make porting packages between Fedora and EPEL
harder.

For the rare cases where it is not possible or desired to remain
synchronized with Fedora, maintain add-on documents for EPEL that
describe the differences and the reasons for them.

Who Needs These Packages

Enterprise Linux User/Administrator Perspective

Every user and admin has experienced at least one desired package
not being included and supported in RHEL. This project gives you a place
to promote, support, and benefit from packages that exist in Fedora
and were not included in a RHEL version.

Whether it is a package your company needs as part of its standard
install, or software you want available so you and your users can do
your work and have your fun, Fedora enterprise packages are a good
method to build support and community around particular software needs.

Community Perspective

Many members of the Fedora community are also users/administrators of
enterprise-Linux based distributions that are derived from Fedora, such as
RHEL and CentOS. Everyone has their own reasons for promoting a
particular piece of software. EPEL packages are the
best way to gain users and support from enterprise Linux users.

ISV/IHV Perspective

The benefits of building upon EPEL as an ISV or IHV have great potential. If your software package currently packages its own copies of open source libraries or well-known tools, you can rely upon EPEL to provide those packages. For example, Perl modules are often needed and repackaged, yet can be available through EPEL instead. You let dependencies be met by EPEL, and your team concentrates on what they do best: develop, support, and provide your product(s).

Additionally, if you are on an ISV/IHV team that utilizes open source software packages to deliver your products, you have the opportunity to contribute to EPEL. This ensures a community of support, review, and testing for packages that your customers depend on for your products.

For independent software and hardware vendors, this is how you get
your software into the enterprise ecosystem:

Use the Fedora process to get your favorite software in to the repository:

Get an entirely new package into Fedora.

Become a co-maintainer for the package you want to have enterprise-level longevity.

Package a free and open source library or other shareable software source to build a community around your applications.

Gain the additional six to twelve months of Fedora testing and feedback.

Be ready for RHEL beta testing before the alpha snapshot is taken, gaining another three to six months lead time.

Ship your enterprise-ready version with the RHEL GA.

Ongoing support and package maintenance is a part of your free and open source development process, along with advancing the technology in parallel in Fedora.

Academia Perspective

Aside from the usual need for software that wasn't included in RHEL,
there is a large opportunity for academia to provide students with
learning opportunities beyond piecemeal open source project
experience.

Where a typical free and open source learning experience for a student might be to
dive into coding or documentation, Fedora enterprise packaging is one
way to gain cross-over experience. The real-world, hands-on
experience includes supporting a free and open source community and user base,
creating an enterprise community around the software, and managing
feature enhancements, bug fixes, and security updates across all
communities.

Red Hat Perspective

This is a simple imagination exercise.

Imagine you are a company that enables a large, fully open and free
Linux based distribution for the general world communities
(cf. Fedora), while supporting a large, fully open Linux based
distribution for its customers (cf. RHEL).

Imagine that what is in your enterprise distribution is what you think
you can support for your customers, and is influenced by what those
customers are asking for. Would it be in your best interest, or the
best interest of your customers, to pull in every single software
package you possibly could? Would you be able to provide QA and
support on such a large package set?

Imagine that it is easier to pick your package set (the ones you
support), and to enable the promotion and community support of
enterprise-quality packages.

If you look around, you see that people have put in great effort to
provide these packages that did not make it into RHEL. The Fedora
enterprise packages are a way of enabling, growing, and honoring the
work that has come before.