Introduction
Open Source software is an essential part of our daily lives. Whether we are aware of it or not, we all benefit from Open Source. It powers the hardware we rely on to access the internet or critical infrastructure, and it may be a vital part of our job as developers or researchers to create and/or maintain an open source project. However, Open Source projects may struggle to remain sustainable for the long term. If you don’t want Open Source software projects to disappear, it is thus important to (financially) support them. Part of this support consists of being able to compensate individuals for their contributions - otherwise there will be an unequal playing field in who could contribute to these projects in their own time.
Different definitions of getting paid
In the cases where people are paid to make contributions to open source projects as part of their job, studies have shown a distinction in what exactly they are paid to do, and the impact that has on how they interact with a project (Zhang et al. 2024; Dias et al. 2018).
At one end of the spectrum, someone may be ‘directly’ paid to work on a project. This means they are employed to contribute to a project and that is (one of) their primary responsibility. We would expect someone in this position to be deeply integrated into an open source community and its governance, because the objectives of their employment and the project will align closely. They will also likely, as a result of the way they are funded to contribute, have a significant influence within the community. This means they will have the soft power to steer the project and influence how it evolves.
At the other side of the spectrum, there are some new and long-time contributors who dedicate a part of their work hours to open source projects, whether that’s code-related contributions, community management roles, or something else. Their roles may or may not explicitly consider this as a main responsibility, and there is often a risk of contributions taking more personal time than the work hours allocated for this. This may cause conflict between their interests in the open source project, and their professional responsibilities.
Furthermore, there are different methods of financially compensating for contributions; some people will be paid as a fixed term or permanent contract, while others might be paid as consultants to contribute to research software. Permanent contracts offer stability, whereas consultancy can offer variability - some of this is being mimicked by institutional RSE groups that mandate their staff to work on at least two different projects in order to give them a variability in experiences. Alternatively, contributors to a project or community can be compensated for their time in non-financial ways. For example, they can receive mentoring or receive training and other opportunities to develop skills that might have otherwise required additional funding. One specific example is the Google’s summer of code program, where a student may receive funding to work on a project, but the funding does not come directly from the project team providing the mentorship. This means that although the team will have to do the mentoring, they will benefit from the work that will be done by the student.
The effects of (financial) compensation
Depending on the nature and size of the open source organisation, a person getting paid to work within a mostly volunteering community can produce a set of frictions and power dynamics (Zhang et al. 2024). In a volunteering organisation (whether it is an open source or not), it is understood that everyone is doing their best within the time they have available. However, when someone gets paid to do some tasks in the project, the expectations are different. What friction may this difference in expectations cause?
A paid individual will, most likely, have more time to dedicate to the project. This means that they will be developing and producing faster than the volunteers. Incidentally, the paid person has more time to think on the project, and that may give them more decisional power on what to do next. A paid individual may also not understand or know whether other contributors are paid or are volunteers, and thus may expect similar commitments from their peers.
Holding volunteer contributors accountable may look different from paid contributors, and these processes need to be transparent for the community. For example, we have experiences from Google Summer of Code where new contributors get paid a stipend for ~3 months, and mentors help those contributors to get involved in the project. However, when the new contributors do not work enough on the project, the workload then shifts to the mentors, which may lead to burning them out. While holding volunteer contributors accountable may look different from paid contributors, it is still important that there are adequate safeguards in place to avoid these unexpected workload shifts.
Lastly, if the paid contributor is financially compensated by a company then this might conflict with the values of the open source project. It is thus important to consider the impact on community dynamics when the influence of a paid contributor grows?
What to do when a billionaire appears
Money might solve many problems, but only if you understand how to spend it well. As part of an Open Source software maintainer team it is important to understand how much money could make a real impact in your project or community.
A grant offers £50,000: Would that employ one person or get distributed amongst your contributors? Who decides this? Would all your contributors be able or want to get paid with money for their work?
Similarly, if you find yourself in an elevator with a billionaire, what would you pitch you could achieve with £1,000,000?
All of this might seem wishful thinking, but this has happened before. Plan early and make sure you have community governance processes in place. Planning for something which ‘may’ happen can be problematic when people are stretched in terms of commitments but perhaps this can be tied into a wider piece on having a vision and roadmap for the project. Funders sometimes do have money that needs to be spent: Have your project ready to go so you can pitch it to them when needed!
Conclusion
The Open Source ecosystem needs to be supported in order to continue to exist. This includes support from funders and organisations for Open Source projects, but also compensation for contributions by volunteers. Open Source projects should consider how they can facilitate contributions by both paid and volunteer members, and how these different types of contributions are impacting the community dynamics. When funding is available, having a clear vision and project roadmap to utilize the funding will ensure a more sustainable project in the long run.
By ensuring that all contributors are compensated for their efforts, the Open Source ecosystem will be more inclusive of a wide range of contributors.
