Contribution Model

Akashdeep Dhar, Fedora Council, Fedora community Version 1.0 Last review: 2026-02-19

The Fedora Project is a community of people: contributors, end users, and everyone in between. There is a strong culture of volunteer-driven work as well as a diverse mix of people who are paid to work upstream in Fedora. The collective of interactions, workflows, approaches, and processes in the community serves its volunteer-oriented open source ecosystem. Having an understanding of this foundational model can help anyone looking to seek assistance, request features, report issues, or generally interact with the contributors of the Fedora Project.

Community Responsibility

The Fedora Project is a vibrant community of people from varied cultural backgrounds and different walks of life, working together to achieve a shared goal β€” to promote and support the Free and Open Source Software (FOSS) ecosystem and its philosophy by building the Fedora Linux distribution and its variants. This is best represented through the Four Foundations of the Fedora Project: Freedom, Friends, Features, and First. While Red Hat primarily sponsors the project and includes paid contributors from Red Hat and other companies/organisations (both for and non-profit) that have an interest in Fedora Project, a significant portion of the work is driven primarily by volunteers or individuals on their own merits – working on their contribution area of choice as and when they can do so.

This includes software packaging, quality assurance, infrastructure maintenance, design creation, documentation writing, community moderation, etc. This distinction is not a minor detail – it is the foundational reality of how we work on a day-to-day basis. We operate on a model of "Best Effort," meaning that contributions are made by the community members when they have the time, capacity, and interest to do so. Unlike a standard commercial service model, where a transaction guarantees a specific output or timeline, community members engage with their area of contribution not because they have to or need to, but because they want to – and this is encouraged by Fedora Project leadership.

Volunteer Reality

Our model of contribution differs significantly from that of the industry, where a "client-provider" relationship ensures specific deliverables and certain accountability in return for a transaction.

We operate on a "peer-to-peer contribution model" in the Fedora Project.

  • We are volunteers. A significant part of contributors' work on their areas of Fedora Project in their free time, after their day jobs and personal responsibilities have been met.

  • We work on what we use, enjoy, and believe in. Packagers maintain software they are involved in, and hence have a vested interest in churning out quality outcomes.

  • Our capacity is fluid. A contributor’s availability can increase or decrease due to life events, employment changes, or work burnouts.

  • Our work is self-assigned. Progress often happens when a contributor voluntarily steps up to do it, as there is no central authority that assigns tasks to volunteers.

  • Assume volunteership while engaging. While many contributors to the Fedora Project are sponsored, offer them agency over actions and empathy over progress while engaging.

Managing Expectations

Because of the blend of volunteering community and corporate-driven contributions, interactions in Fedora Project may differ significantly from what you experience within a commercial organization.

Understanding these differences can help reduce potential frictions from certain disagreements and make your time contributing to the Fedora Project more productive and rewarding.

Requesting updates

A common source of friction arises when users request a task, e.g., a new package or a refreshed update, as soon as possible. There is no "department" dedicated to fulfilling these requests. If a package does not exist, it is likely because no volunteer has stepped up to maintain it yet. If a package is outdated, the maintainer may be occupied or no longer using that software. In such cases, requests are welcome as "suggestions" and not "assignments", and hence, they may remain unfulfilled if no community members have the time or interest to take ownership of them.

Support/accountability

When things break sometimes, or requests go unmet, it can feel like there is a lack of support in a certain community area. However, in our contribution model, accountability is paramount to the health of the said community area and not to a customer contract. We are accountable for following and meeting Fedora Project’s technical and community guidelines. But on the other hand, we are not accountable for following and meeting individual deadlines or specific feature requests, though we always strive to help achieve them wherever and whenever possible.

Progressing Forward

The most effective means to see a change in the Fedora Project is to participate in the process. This not only allows for the change to actually take place, but also in a sustainable manner.

Here are some ways in which one can effectively work with the community.

  • Step up to the cause. If something needs to be done (with respect to package updates, documentation mistakes, website changes, etc.), try doing it. Open a pull request, provide feedback on a change proposal, or add your voice to the feedback loop.

  • Collaborate instead of demanding. Present your requests as notifications for visibility rather than demands for work. The most effective manner to ensure a positive outcome delivered swiftly and polished is to actively offer your assistance in the process.

  • Be kind and considerate. Remember that the person on the other end is most likely a volunteer using their spare time to help you, so being patient helps. Always remember to be empathetic to their position and be appreciative of what progress they make for you.

  • Prefer stewardship over control. Leadership is about enabling others to succeed, so encourage shared ownership and welcome different perspectives, while preferring progress over polish and understanding that voluntary participation is finite in nature.

  • Switch hats with accountability. Starting or stopping with leading endeavours should always be followed up with a mindset shift, including intrusion avoidance, tone control, proactive guidance, and exhaustive documentation while engaging with contributors.