Open-Source Cannot Live on Donations Alone

The other day I came across a new initiative for funding open-source development, called the Bitcoin Grant. My first thoughts were “pretty cool”, but then my cynical side woke up and reasoned “how is this better than the old donation button most open-source projects have? it just limits who can donate and how you can use those donations. Pretty hard to pay salaries in Bitcoins (yet)”. A recently launched service called Gittip does the same thing but with US dollars.

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 open-source. Why aren’t donations effective for open-source?

Can’t live on donations

How can donation money be used by open-source projects? Jeff Atwood was surprised to find out his $5k donation was left unused months after he had sent it to a .NET open-source project. He asked his friend, Jon Galloway, which responded “Open source projects run on time, not money. [redacted]”.

To progress, an open-source project needs the same resource as every software development project – developer time. You need dev time to fix bugs, you need dev time to add features, 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. If you can’t depend on funds from donations, they are relegated into the “nice-to-have” category. You can use it to pay off some external costs like hosting or running some ads (if it makes sense), but you can’t use it 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 in a way like “buy the 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 / 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 3 things can happen –

  1. 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).
  2. 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.
  3. 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 slowly die off.

Those options are ranked from the least likely (commercially viable) to the most likely (dying off) outcome.

Promoting open-source projects up the ladder

This is the main problem we are trying to solve at Binpress (the blog of which you are currently reading). How can we get more developers to –

  • Release more code into the open, reducing redundant development
  • Support and advance their open-source projects full time
  • Treat their open-source projects like they would their paid-for projects – i.e, like a professional business

The last part is of special note – we feel that treating open-source projects like a professional business, instead of a hobby or an altruistic endeavor is the key for sustainability for most projects. While the last 2 are admirable and open-source would’ve never have become as big as it is without them, they remove an important level of responsibility developers feel when providing support for their projects. As the initial enthusiasm wears off, complexity increases and issue reports start piling off, it’s hard for developers not to become less than cordial when providing support, or even not to provide support at all.

How do we do it? Binpress is a platform (marketplace) for developers to:

  1. Publish their open-source projects. Submissions are curated – we check that the code works, that it is well documented and follows a consistent coding style, and lastly that the project is not trivial. As I mentioned earlier, the need for a project to work like a business arises only when complexity / importance reaches a certain level.
  2. Gain visibility for their projects – we handle marketing, advertising, SEO, send out newsletters, reach out to communities, collaborate with relevant players in the field – all to bring attention to projects that passed our curation. Basically all the stuff that most developers hate to do and / or suck at.
  3. Find a licensing / pricing structure that works for them. We have created a license generator in cooperation with copyright lawyer (and open-source advocate), Jon Klinger. More on licensing below.
  4. Handle payments and payouts – we collect payments (for non-free licenses) through a variety of payment methods and issue payouts either through Paypal or a direct bank deposit. We swallow the various fees in our commission, making the process much smoother for developers.
  5. Provide communication channels and social proof, such as comments, reviews, feature suggestions, and of-course – issue tracking.

While a few of those attributes may remind you of open-source directories such as GitHub and Google Code – Binpress is an extension of those and not an alternative. In fact, we have an integration with GitHub that allows developers to add the commercial business layer on Binpress while hosting their code on GitHub.

About ‘free’ and ‘open-source’ – while the two have historically been conflated together and it’s hard to pay for something you are used to get for free – we believe that for open-source to mature from a hobby to a professional business, some commercial elements need to be introduced, whether it’s through the sponsorship of a big company like Google, paid support or paid licenses. The important thing is to enable the sharing and support of quality and useful source-code, and treat it like a professional business.

Many open-source projects have taken this route independently, and the few that have been highly successfully set an example for the rest. Projects such as MySQLMagentoRedhat and SugarCRM has shown how well this model can work, and we are trying to make it as accessible and available to any open-source project who wants to graduate from a hobby / pastime project. Not everyone agrees with this model – it’s hard to pay for something you are used to get for free – but we believe the outcome is a better, more sustainable ecosystem for sharing code.

Only the beginning

There are many developers making a good living from publishing their code on Binpress. Some are making silicon-valley comparable monthly salaries – for getting to work and support their personal projects. We think that’s pretty cool – but we’re just getting started. We haven’t exhausted all the possible ways for developers to support their projects full-time other than paid licenses.

For example, right now support is baked into the license – but we intend to make it independent to allow free open-source projects to monetize their support. We are still thinking about the specific implementation such as paid tickets vs. support periods, and whether to allow a mix of free and paid support (for example, bug fixes for free and new features are paid). We’d love to hear some feedback from the community on how they would like to have paid support added to their open-source projects.

Another option is customization services for open-source projects. We get many requests from clients who buy or download free components on our marketplace to provide post-purchase services for customization and further development based on the project. Right now we connect them to the developers manually, but we would love to offer the option for developers to provide such services for any open-source project they developed or are experts in.

Keep moving it forward

Getting more developers to share quality code and then support it as a professional business, while providing a curated inventory of code solutions to speed up development and increase robustness of projects, is a win-win proposition for both publishers and consumers of code.

We have been picking off steam as of late, and are seeing real validation that this concept can work and scale. We have been accepted into the 500 startup #6 batch which starts mid-April – we’re very excited about that and hope they can help us leverage our current momentum and help us take the open-source industry to the next level.

We are hiring! if you find our views compatible with yours and think you can contribute – especially in marketing, sales or community management, please send a quick shout-out to our CEO, Adam (email – his name[at]our domain).

You should also read our follow-up post on the subject titled Freedom, beer and open-source.

Author: Eran Galperin

Scroll to Top