Open source is the backbone of most if not all software-based innovation and allows us all to benefit immensely. Despite this, open source developers are often expected to sacrifice their time and finances to satisfy the needs of the masses. Luckily there are some very generous individuals and businesses out there that donate funds and time to keep these, oftentimes fragile, ecosystems alive. However, unfortunately the amount of businesses that actually contribute is an incredibly small fraction of the total amount of businesses that use these projects.
Two primary established ways to contribute
There are definitely a few different established ways on how to contribute to an open source project. Very simplified, these approaches reside within one out of two main categories:
Code contributions
Donations and sponsorships
Some businesses contribute directly with code in the form of bug fixes, features, or new components and libraries that benefit the open source ecosystem, and of course, their own internal development. Many contributions may be narrow and specialized towards a very specific need, that the exact company has. Then, yes, you may contribute, but maybe not in a way that creates a huge value for the ecosystem as a whole. Other code related contributions beyond writing actual code, can be improving existing documentation, writing bug reports and doing quality testing, also usually valued forms of contribution.
If you don’t have the capacity or competence to contribute directly, funding and sponsorships are something most projects also are looking for. It doesn’t have to be one or the other, as some large (and smaller) companies do a combination of direct code contributions and funds. For funding, companies sponsor open source projects they rely on through platforms like Open Collective, Patreon, and the Linux Foundation's membership models. There is further an increased presence of crowdfunding campaigns where businesses can donate to funding of features they pick themselves.
The challenges with donations
Have you ever tried to encourage management to donate to open source?
Statistically the answer is probably no, and for those of you who have tried, many of you have experienced rejection. A large share of managers (but not all) don't understand the importance of donating to open source. And for startup founders it might be difficult to explain donations to investors, especially if they don't understand the ecosystem.
From a capitalistic perspective it might appear to make sense to not donate, but for long term sustainability businesses risk getting caught in a “tragedy of the commons” dilemma, where everyone consumes and few give . But this is definitively not something that they consider unless they have open-source enthusiasts onboard or people who evaluate dependencies frequently.
Still, donations and sponsorships can make up a significant part of a person’s income, especially for successful solo projects. However, there is still a naive notion among many developers that “If I just put my project out there, donations will flow in”. For example the creator and maintainer of BookStack points at an important nuance regarding the difference between having and not having an audience when starting up: “From my experience, people don't donate to code/projects, they donate to other people. Having a following, an audience, and being able to engage with that audience really helps in the area of donations. I only jumped in fully on the donation/sponsorship path after gaining an audience over 6 years of development, which I think really helped”.
So unless you also want to build your own personal social media brand and community presence, this might not be the best option for everyone.
A third, less explored way to contribute
For a tiny fraction however, leaning on donations might be sustainable. But it is always easier to ask for something if you can give something in return. One may logically think of the free code as “something” in return, but since it is open source, people are wired to disregard the actual code from the transactional equation. A thing one could offer then, is support. Support is by most not considered to be an integrated element of the open source definition, in the same way as the actual code. Many would therefore with support feel they receive “something” in return, and hence be more inclined to pay for the service than just the “free code”.
We acknowledge that we are of course biased in this psychological and philosophical question, but, we are still strong believers in the funding power that lies in offering support in exchange for funds.
From our perspective, this contribution value to any project is both direct and indirect. Direct in the way that you receive actual funds in exchange for helping people. And indirect in the way that it lets your project appear more professionalized, as well as it gives your team members the economic flexibility to allocate more time to developing new features and fixing bugs. How you may ask. By letting the project also help them with a potential revenue stream for any support they do, by virtue of being a part of the project.
Support as a third pillar of funding
So next time you think about how to fund your open source project, we recommend you consider this third path, in addition to direct code contributions and donations. There are probably multiple ways to regard this, but support can be seen as “donations with something in return”.
For many, premium support plans can be a bit excessive and expensive as they are often paid monthly and not depending on your particular needs. Today there are pay-as-you-go alternatives out there, i.e. through platforms such as Githelp, that are easy to set up and let users pay for what they get. This doesn’t have to replace donations, it can complement it, giving you more strings to play on.
Share Article