# The business case for supporting EPEL
Extra Packages for Enterprise Linux, also known as EPEL, is a collection of packages built and maintained by the community for use in Red Hat Enterprise Linux (RHEL), CentOS Stream, and RHEL-like distributions like Rocky Linux and Alma Linux.

If you don't use or know about EPEL, it's likely that you don't have to think about these things, in which case this article isn't for you. However, it might contain ideas for promoting sustainable uses of free and open source software that you can apply to other situations that are more relevant to you.

Who is this article for? I'm thinking of the team leads, managers, and directors in IT departments who make decisions about the tools that their organizations have access to.

I am going to make the case that if you use EPEL as part of your organization's infrastructure, you have an interest in keeping those packages available and as secure as they can be.

## Reason 1: Unmaintained packages may be removed from EPEL
As with every distro, packages have to be built and maintained for them to available to the users of those distros. If someone isn't doing the work of maintaining the packages, those packages become increasingly out of date. Eventually they may even be removed from the repository because of the security risk. All of this is avoided for as long as a package has a maintainer.

If you, as in someone in your organization, is the maintainer of a package that you use, then you don't have to worry about it falling by the wayside and potentially becoming a vulnerability. You get to make sure yourself that the package stays in the repo, is up to date, and remains compatible with the rest of your infrastructure or deployments. Plain and simple.

Of course there needs to be room to manage bandwidth. Depending on how critical that application is to the operations of your organization, that defines how important it should be for you to make sure that either you maintain it or that it is being looked after. XFCE may just be a nice-to-have for you, but Ansible might be critical to operations.

## Reason 2: You're the first to have any security patches
As cyber threats continue to grow in number of exploits found and the speed at which they're exploited, security is on every IT person's mind. Patching vulnerabilities is something that increasingly can't wait, and this extends to EPEL packages as well.

If you're the maintainer for an application you need, you have the ability to respond quickly to newly discovered vulnerabilities and protect your organization. Additionally, you acting in your own self-interest now protects all the other organizations that also depend on that package.

## Reason 3: Everyone else who uses that package can help you keep the package running well
As the maintainer of an application, others who also use the package will let you know of bugs as they arise - bugs that you may not have realized were there. Arguably it's not a big deal to squash bugs that you don't experience, but by becoming the hub for feedback for that package, you will also be smoothing out the experience for your own users who may not have thought to report the bug. You benefit from crowd-sourcing quality control.

## Reason 4: You can prepare for future releases before they come out
All future LTS releases of RHEL and RHEL-like distros will have their start as CentOS Stream. Therefore, if you plan on migrating to a release that is represented by the current version of CentOS Stream, you as the maintainer can and should be building against it. Rather than finding out at the end of the line whether your must-have packages will work in the latest releae of your enterprise distro of choice, you can ensure continuity by packaging the application yourself for your next upgrade.

## Reason 5: You're contributing to the long-term confidence in EPEL as a platform
The only reason we have packages in EPEL to begin with is because people are volunteering their time to maintain them. In a few cases you have companies committing resources to maintain packages as well, but there are few examples of that. If people don't believe that EPEL will stick around for as long as RHEL releases, maintainers can lose steam or burnout. By committing resources yourself to EPEL, you're shoring up confidence in the project - confidence that can encourage other organizations to invest in EPEL themselves.

## Potential solutions
If at this point you're thinking to yourself, "I would like to give back in some way, but what would that look like?", here are some ideas. Some are lower commitment than others if you want to help but need to remain flexible across other responsibilities.

1. Maintain at least one package of the ones you do use in your organization.
2. Take on the maintenance of at least one package even if everything you use is already covered so that you're at least giving back in some way. The average maintainer looks after 10 packages, so covering at least one should be an easier hurdle to cross.
3. Report bugs for the packages you are using.
4. Request packages from older EPEL branches in newer EPEL branches, i.e. EPEL 9.
5. Provide testing feedback for packages in the epel-testing repositories.
6. Depending on the number and importance of packages you use, consider how much employee time you want to dedicate to EPEL maintenance.
7. Integrate any EPEL maintenance you provide into the job descriptions of the responsible employees so that your team can continue being a responsible open source contributor into the future.

## Become a package maintainer
You can start by checking our the Fedora documentation on [how to become a package maintainer](https://docs.fedoraproject.org/en-US/epel/epel-help/).

If you need support, you can ask how to get started in the EPEL [Matrix channel](https://chat.fedoraproject.org/#/room/#epel:fedoraproject.org) (with IRC bridge). Here are other ways to [get in touch with the EPEL community](https://docs.fedoraproject.org/en-US/epel/#communicating_with_the_epel_sig).

## Since you've made it this far...
[Please take this quick survey about EPEL!](https://fedoraproject.limequery.com/396386) We're looking for feedback on how to improve EPEL in the future.

Also, here are additional resources you can check out on EPEL and how you can leverage it more.

- [What's EPEL, and how do I use it?](https://www.redhat.com/en/blog/whats-epel-and-how-do-i-use-it)
- [Frequently Asked Questions (FAQ)](https://docs.fedoraproject.org/en-US/epel/epel-faq/)
- [Joining the EPEL SIG](https://docs.fedoraproject.org/en-US/epel/epel-help/)
- [How can we be sure that someone will maintain the packages until end of life of the distribution the packages were built for?](https://docs.fedoraproject.org/en-US/epel/epel-faq/#how_can_we_be_sure_that_someone_will_maintain_the_packages_until_end_of_life_of_the_distribution_the_packages_were_built_for)
- [EPEL package maintainer generic job description](https://docs.fedoraproject.org/en-US/epel/epel-package-maintainer-generic-description/)
- [About EPEL](https://docs.fedoraproject.org/en-US/epel/epel-about/)
- [Extra Packages for Enterprise Linux (EPEL) - Fedora Docs](https://docs.fedoraproject.org/en-US/epel/)

## What do you think?
Do you think these reasons are valid? Are there others you think should be mentioned? Do you disagree with this idea? Continue the conversation in the comments below or in the Fedora Discussion board!