Donating to an open source project
Are donations effective for open source projects?
The other day I came across a new initiative for funding open source development called the Bitcoin Grant. While interesting at first sight, I was wondering: How is this better than the traditional donation button most open source projects have? The Bitcoin Grant then seems to limit who can donate and how you can use those donations (you can’t pay rent with bitcoins just yet).
Additionally, donations to fund open source projects hasn’t really panned out so far. I don’t have authoritative numbers, but from asking around and being involved in the community (mostly as a consumer of open source), it seems that donations are rarely a driving force behind the development of an open source product.
Why aren’t donations effective for open source?
If you can’t live on donations alone, how then can the donations that are made be used by open source projects? Jeff Atwood was surprised to find out his $5,000 donation was left unused months after he had sent it to a .NET open source project. He asked his friend, Jon Galloway, what was going on and he said basically that open source projects run on time, not money.
Open source projects require developer time. You need dev time to fix bugs, you need dev time to add features, and you need dev time to write documentation. If the donation stream is not regular and dependable enough to allow project team members to either quit their jobs (if working full-time) or reduce contracted hours (if working freelance), then donations are not going to add more dev time to the project. And, if you can’t depend on funds from donations, then they are relegated into the "nice-to-have" category. You can use them to pay off some external costs like hosting or running some ads (if it makes sense), but you can’t use them for anything important like salaries.
Donations for open source lack the urgency and personal empathy that charity causes have—such as donations to find a cure for a terminal disease or solve some ecological issue. The audience for those causes is much larger, and they make a much stronger emotional plea than open source—and in any case, most open source projects don’t need the money like those charities do—and so it’s usually phrased like: Buy a developer a cup of coffee.
The main purpose of donations to open source is to say "thank you" to the developer(s) rather than actually advancing the project.
Submit a patch is a common response when you open a ticket that is not interesting or urgent for the project maintainer. It’s never Send a donation. Because donations can’t buy dev time. For smaller open source projects, this is usually not a problem. A small audience, limited use-cases, and a small code-base mean less dev time is needed to support it. Once a project crosses a certain threshold of either popularity or complexity, developers who are paying the bills with other work have to start prioritizing on what to work on and what bugs to fix.
At this point one of three things can happen:
- The project will grow popular enough that it can be monetized (through premium licenses, support, or being bought off by a large company) that the original maintainer can dedicate himself to it (and maybe even grow the team).
- The project will grow popular enough and open enough (i.e, the original maintainer cedes control to the community) that the community can maintain it. Most projects do not cede this control though, and the bottleneck remains developer time of the original maintainers.
- As the project consumes more and more time just to maintain, developers get frustrated with the increasing number of (terrible / irrelevant / hard-to-fix / hard-to-reproduce) bug reports and not enough time to work on the parts they really want to. This is where many open source projects slowly die off.
These are ranked from the least likely (commercially viable) to the most likely (dying off) outcome.
Almost 95% of open source projects are no longer maintained after a year
(from Open Source By The Numbers)
In my opinion, the solution is a more widespread adoption of the dual and commercial licensing model as a financing option; and increasing the appeal of open source projects to businesses and enterprises through professional support and services.
Monty Widenius, the creator of MySQL, suggests an option he calls "Business Source"—which describes commercial licenses that have some open source aspects. It’s important to remember again, that the free part of most open source licenses talk about freedom and not pricing. Even though most of us are familiar with accessing open source free of cost, a strong case can be made that paying for the privileges of using open source is better for the software economy over the long run.
If open source can be a viable business opportunity, I think we will see several significant changes:
- More code would be released into the open, reducing redundant development.
- More developers could support and advance their open source projects full time.
- Increased professional and reliable approaches to open source development, making it more attractive to businesses and the enterprise.
I believe in this model enough that I made it my main mission in over the last two years to evangelize and support it. So, I developed and launched (along with other fine folks) a platform for connecting open source and businesses called Binpress.
And, Binpress helps developers monetize their open source projects. We already have multiple developers making Silicon Valley comparable salaries (over $100k annually) from working on commercial open source projects full-time.
Is this the best way to support open source? Time will tell. There is definitely room for many different options for sustaining and incentivizing open source. And, we can draw inspiration from the success stories of products such as MySQL, Magento, Red Hat, and SugarCRM to name a few.
Evolution of the industry
Combining open source with a commercial layer is a proven model, we just need to make it more accessible for the smaller, lesser known projects out there.
Getting more developers to share quality code and then support it professionally is a win-win proposition for both developers and businesses who need code solutions. Hopefully we will soon see a revolution in the software development industry, with commoditization of solutions for common requirements in software products. This would lead to reduced software development cost, increased robustness (both in features and stability), and more resources and options for developers to focus on creating something unique and of value.
There will always be demand for free (as in cost) open source code. There is no contradiction or conflict with the emergence of commercial open source solutions. It’s just another step in the evolution of our ecosystem.
Originally posted on Binpress blog. Reposted with permission.