IMAGE - Midjourney

Today many users of code, commercial and hobbyists, have gotten spoiled with not only getting the code for free, but also having the person or team representing the project that created the code, helping out with implementation, dependencies, best practices and misinterpretations without getting a penny in return. For larger projects this may work to some extent, especially if you have a separate product or commercial initiative that rides the ARR wave (annual recurring revenue). But for smaller OS projects it is less sustainable, as solely basing your sustainability on donations can be a tough hustle long term. 

So what do you do then. Do you start to ask for payments, and if so, how? Many have rightfully raised the concern of paying people for doing OS development, talking about misaligned incentives and wrong motivation. But it is important not to mix up apples and oranges here, or in other words, development and support. Many would probably argue that this conflict is most present and crucial when talking about prioritizations related to roadmap planning and developing new code or features for a repository, and less true when it is related to pure support, with the intent of making it possible for others to use the source code in a frictionless way. 

IMAGE Midjourney

Regardless of how you put it, building free code out of the goodness of your heart, is by many argued to be a privileged mindset from people who had the opportunity to work for free, or who just are ignorant to the fact that having a source of income is necessary to survive. The screenshot below, where a person is reacting to a text written by Jacob Kaplan-Moss, “Paying people to work on Open Source is actually good”, is maybe simple, one-dimensional or exaggerated, but it paints somehow a picture of where the sentiment among many are moving, in line with what we see ourselves, an increasing willingness to pay, especially among businesses. 

https://www.reddit.com/r/programming/comments/1asl4au/paying_people_to_work_on_open_source_is_good/ 

One should be careful with putting a price tag on feature prioritizations, but if one introduces paid support, one can maybe avoid exactly that. From our own experience and research, there is a willingness to pay for help if it exists. 70% out of 46 developers we asked, all working for various companies, said they would be willing to pay for OS support if it was low-barrier. 

We understand that there might be good arguments for keeping support free as well, but after talking to repo owners and a long list of different developers, we experience surprisingly limited resistance on the topic, probably as it has a few quite apparent benefits that most OS projects should take into account. Here are those we have taken particular note of. 

Extra source of funding

Support can act as a convenient extra source of funding, or for commercial actors, help to cover parts of costs related to offering support (as suggested by a large semiconductor company we talked to). For many projects new revenue streams naturally makes it easier to let contributors spend more time on the project, either through extra funding for the organisation or direct compensations from letting the contributors also act as helpers. From our own research and chats with OS projects, funding is raised as one of the main factors that makes it challenging to allocate enough time to support. As a bonus, funding, or increased financial stability, also makes it easier to commit to long term roadmaps, and hence boost the value of the project among its users beyond the actual support. 

Easier to engage contributors

Having something to offer in return, beyond self-realization, personal growth and interesting tasks, could spark an extra motivation. Especially if the project is moving into more of a set, operational and mundane state. From our own research the factors that are highlighted as making it challenging to help users are lack of time, not enough team members, and funding.

Actually 82% of those 26 repositories we talked to said availability - not having sufficient time to allocate for helping those who need help - was their largest concern. Sequentially, when following up with - To what degree would you have spent more time on helping others, if you were paid for your support? - the average number among all 26 respondents was 7/10. There seems to be quite convincing data supporting the claim that paid support could strengthen the support availability and -quality among projects in general. Increasing the team availability improves the first impression among new users, and the experienced long-term sustainability among larger enterprise users. 

Help core contributors (or community in general) with a stream of income

This one is closely linked to the prior point. Connecting any validation of helpers qualified for support to actual contributions to the code base, could in some cases help to maintain a core of contributors. In other words, “support qualification” could to some extent be an option to salary, either for everyone or some. Assessing contributors' activeness could be a qualitative measure done by the project owner(s), linked to number of commits, the difficulty level of a commit, or just general time spent on the project. 

Paying people can further help secure quality from the persons who help out, and reduce the risk of burnout. Especially for developers that have a flexible job, and can adjust their other engagements accordingly, in line with any payments from the project. Not having to solely spend their spare time on OS endeavours, but instead free some of the working hours to it, can be more long-term sustainable. 

Higher quality support

Again, closely linked to the point above, supporting people with payments can help to offer higher quality support, as one has an incentive to spend more time on each request, one may feel more energized and less burnt out. Actually, this may contribute to users getting more out of the repo and their code base, as the helper may feel more obliged to handle tickets in a structured, efficient and swift manner. Which again can help with growth and adoption, at least for some projects.  

Let contributors live and feel their users´ problems (even more)

If it was an option: Why is paid support better than having a regular day job? Because paid support lets you live and feel the problems of your users every day. People building great products, whether it is closed or open source software, or something totally different, often spend a ton of time doing support, as it helps you get a deeper understanding of your users´ pain points and needs. There are multiple examples of great founders who have sworn to support long into the scaling phase, such as Jeff Bezos (Amazon) or Stewart Butterfield (Slack). Most jobs also require some form of fixed hours, and often require 100% positions. Support however, does to a large extent let you regulate the workload yourselves (given that there is activity), making it easier to also designate time to develop the code and new features even further. 

Helps to sort out “noise”

Popular projects can receive a s**t load of user requests of all types and forms. This is particularly challenging for trending repos, that haven´t been able to scale their team as fast as the user base. Knowing what to prioritize can therefore be a challenge. Who is asking how they can “xxxx” out of curiosity, and who is wondering about the exact same thing because it is of great value to their own popular product or project. Charging a small amount can help to naturally sort out requests that may be “noise”, as, if one doesn't want to pay a small amount to get help, one can assume the request is less important. This point was brought forward by separate repositories we talked to. 

A more logical transaction for management

For many companies, asking management to prioritize donations can be a tough sell. Of course, many managements understand the value of open source projects and the open source community, but this is not necessarily the majority. This point is proven through the number of businesses who actually make donations to open source. Paying for support however, through tickets and issues they actually need help with, is for many a much more logical transaction, as you get something in return. 

Structured support complement other issue channels

70% of the repositories we talked to, list unrelevant issues in Git - Issues that are only misunderstood usage of their library/SDK, and not an actual bug, as a challenge they have experienced. Having other issue channels that can complement bugs or feature requests, can help to move what may be experienced as noise on for example Github, to a platform where it more naturally belongs. 

Does not conflict with OS philosophy

Not a benefit in itself, but an important point still. When The Open Source Initiative defines “Open Source”, they do it in accordance with ten criteria a software license must meet. None of these criteria restrain an open source project from charging their users for support, as the core essence of this definition is related to having an open and admissive licensing model, whereas paid support is a service, not a restriction on the code´s usage or distribution. 

There are probably several other arguments that could have been highlighted here as well, but these are from our perspective a few central ones. Whether paid support actually could be a substantial funding source for a project, surely also depends on the nature of the project. Some projects inherently need more support and assistance, due to factors such as amount of code, code complexity, documentation, whether the code is mission-critical for an average user, dependencies, and so on. In addition to the varied need of support, it also depends on the willingness to pay for help among its users. Having certain commercially successful users, of course gives another willingness to pay, than the opposite. And are you having a “less niche project”, relying heavier on AI may be an excellent option. Hence, paid support is not necessarily the monetary saviour for any project, but all projects could benefit from it to some extent, even though it is just a tiny bit.