code-for-a-living January 7, 2021

Open source has a funding problem

Relying on volunteers to maintain every open source project isn't long term sustainable. Funding open source projects could keep development moving, but would that funding be raised and who would pay for it?

Would you work for free? It is a simple but loaded question that requires additional context. Is it working to help a friend do something? Is it work that you would enjoy? Does the act of working for free give you some level of satisfaction? Your gut reaction to the question may have been a hearty, “No,” but many people volunteer for a variety of things all the time, so people will work for free when there is something in it they enjoy.

Open source development could be looked at as a form of volunteering. Many developers have donated their time to either maintain or contribute to open source projects. These developers may not care about being compensated for their time—they are just happy for the experience, challenge or may just like helping others.

Developers that do this for nothing more than a pat on the back are great, however, it can be difficult to rely upon for the open source ecosystem at large. Time commitments are likely the single largest issue at play here, as developers are often working on these projects in their spare time. Between work, sleep, and hanging out with friends and family, having a steady stream of volunteer commitment to a project can be difficult. This issue is magnified depending on the project itself and the skillsets required to do large, meaningful contributions.

Funding open source projects is a way to try and address this. Rather than have developers do open source work in their spare time, they can be financially compensated for it as part of their regular workday instead. The problem with paying for a developer’s contributions to open source projects is how that funding is raised and who pays for it.

Donations are commonly used as a basic means to raise funds—whether that be GitHub Sponsors, Open Collective, or Buy Me A Coffee, etc. While donations are very much appreciated by those who receive it, it relies on the goodwill of others and may only be a sustainable source of funding for extremely popular projects. This leaves the vast majority of projects without adequate funding, though they may not be any less worthy of it.

If open source funding cannot rely on donations, it needs to charge some sort of fee somewhere in the process. But, you say, isn’t open source supposed to be free? Open source is not about free software, it is about freedom of software. As described by the Open Source Initiative (OSI):

Open source enables a development method for software that harnesses the power of distributed peer review and transparency of process. The promise of open source is higher quality, better reliability, greater flexibility, lower cost, and an end to predatory vendor lock-in.

So what is exactly stopping open source developers charging for their work?

Potential licensing woes

There might not be anything as divisive when talking about open source as discussing project licensing. There are licenses that restrict how a project is used or who uses it, and others with no restrictions at all. Depending who you talk to, the mention of a copyleft license like GPL is enough to make some developers run to alternative projects under a more permissive license like the MIT license.

Some of these restrictions in these licenses may seem to be in opposition to openness and freedom that the OSI’s definition of open source proclaims. It may be better to think of these projects as “openly developed” rather than to a strict definition of open source. These types of projects are equally deserving of funding whether or not they are strictly open source. It is with their licensing, however, that these projects may be even more greatly impacted in seeking funding.

Having funding for an open source project requires people to know about and use the project. Developers that want to use the project need to agree to the license and, unless they moonlight as legal experts, understanding the legal ramifications of licenses can be difficult. This is what makes newer and more restrictive licenses less likely to be accepted—not every license that a developer encounters can be run by a lawyer to ensure compliance.

It is, however, in these more complex licenses configurations where open source developers often attempt to charge for their work. For example, having a dual license of MIT for non-commercial and a custom license for commercial purposes. Developers may have a good grasp of the permissive MIT license however may need to avoid the same project at their place of work due to the commercial licensing stipulation. This is an important distinction when considering who would be funding open source development.

The sources of funding

When looking to find funding, consider the different groups who may be consuming your open source project. You have other developers also doing open source work, non-commercial closed source work like what might be a hobby or side project, and commercial projects which may be open source or not. Each of these groups have different priorities and expectations.

Other developers with their own open source projects might seem like a good candidate—they understand and appreciate open source work and the time and effort involved. The problem here is that these developers would likely be using far more projects than they can reasonably fund. There is also the concern of this effectively being a closed ecosystem where developers are paying other developers who themselves are paying other developers. This creates a cycle where not only is there no additional money exchanging hands but the money being shared is slowly decreased through things like processing fees. This is not a viable solution to the funding problem.

Like developers who may use the project in their own open source work, those that have closed source hobby or side projects that depend on you are likely from the same pool of developers as the ones who also work on open source. This is again the cycle of developers paying developers with no real capital investment being added into the open source ecosystem. It might be better than nothing but is not a viable strategy long term.

Commercial use, on the other hand, is a good potential source of new capital for the ecosystem. Companies that use open source are likely gaining some advantage by using your project compared to another solution, potentially making them more efficient or being able to provide specific services to their own customers. Companies already pay for various pieces of software so one extra cost may not seem like a big deal. Unfortunately, but predictably, companies would like to keep their money so unless the case is compelling, they may opt for free solutions.

The value proposition for companies

To put it simply, why would a company want to fund your project? Companies in general don’t gravitate towards the idea of “doing the right thing” for the sake of it. Companies, however, may fund something if they can get something desirable in return. Ideally then, a company needs to be encouraged to use what you’ve built but still want a little more out of the deal.

Perhaps it is security, not in the technical sense but the peace of mind that the open source project won’t disappear next week. Sure, the source code might still be available but unless they have the technical prowess to build and maintain it themselves, the added security that funding the project could provide may be enough. In other cases, it may be to ensure that bugs in the project are resolved with a higher priority or speciality features are made that help the company.

Due to the long term nature of these reasons to fund a project, the type of funding most appropriate here is a recurring payment to help maintain the project. You wouldn’t want to have a one time payment and be on the hook for maintenance for the next 10+ years, you would want something to sustain the project over however long the life of the project is.

For companies to take these approaches though, they need to establish that the costs with funding the project are worth the risks of not funding it. The risks, however, heavily depend on how the open source project is being used, and for how long it may be used. In the short term, it may be companies with new projects integrating your project as a critical component. In the long term, it may be companies with fragile legacy projects which need support for older versions of your project. If your project broke or didn’t work in a manner they needed, it could cost them a large amount of money if their entire system fails. It is these cases where funding your project can reduce their risks, in turn helping their business continuity.

While that may seem straightforward or logical, it is not that simple. Even critically important projects that deal with security and cryptography can receive minimal funding. There is a great post by Aaron Stannard about the sustainability of open source projects with a case study about OpenSSL.

Prior to the “Heartbleed” vulnerability, OpenSSL received about US$2000 a year in donations—not very much for something that is used so widely. After the vulnerability, they received about US$9000 in donations. While it is difficult to put a total cost to the vulnerability, it has been estimated to be as high as $500 million—imagine the project even getting a fraction of that in funding prior to the vulnerability being announced.

Instead of funding the project directly, some companies may have their own developers contribute code back to the project. On the surface, this is great as having additional contributors can take a lot of work off of the maintainer. Even this has issues, as their goals and yours may not align. They might contribute new features you would need to support or bug fixes that break other workflows, changing how you spend your time on the project. Instead of writing any code yourself, you may be only running tests, reviewing pull requests, and validating issues. That may still put you ahead timewise; however; it may not be what you want to be spending your time on. While I wouldn’t want to discourage companies from contributing relevant, high quality pull requests, it is being mindful of what is best for the project, not taking over it.

If the value proposition is not there for the company, or the support they are providing is hindering more than it is helping, you may have to take your efforts a step beyond being an open source maintainer. You may need to create a company around your project.

Turning projects to products

Open source projects often have a very narrow scope. Maybe you have built a web crawler, an API client, a date format converter, a calendar widget, etc. By themselves, these are hard to market and sell as a company, and you could be stuck in the same funding situation you were when you started. Instead, you may want to try and repackage up the project in a larger product that would be marketable.

If you built a web crawler, maybe you are building a web service to automatically crawl sites with a simple API. If you built a date format converter, maybe a service that does language and formatting detection in strings and web pages. Different projects have different potential products and business models that could be shaped around them, and while not every project could easily do this, those that can find customers for this new product have found a way to help fund their open source development.

Projects from GitLab to re:dash have worked this way, taking a project and putting a product-spin on it. Both of these examples used a subscription model to bring income in for their project, allowing them to focus on their work and grow their teams. This in turn allowed more features to be added fast and for bugs to be fixed more quickly.

Starting a company to keep sustaining open source projects is a big undertaking. It can be an extremely time intensive process getting the company off the ground, requiring you to familiarize yourself with business accounting and other legal work, before even getting back to maintaining the code itself.

All of this is easier said than done and skips over the true nature of wanting funding for these projects. Different developers have poured their heart into their projects, dedicating large amounts of time and effort into making solutions, and sharing them with the world. While the code may live online somewhere forever, an open source project only truly survives if someone maintains it.

The human side of open source

To get the most well rounded understanding of open source funding problems, it is important to see multiple perspectives from other people in the community. There are two people I’ve followed for a while that have put a lot of time and effort into various open source projects.

James South, creator of ImageSharp (a .NET image processing library), has been trying to have his projects funded. Even with using Open Collective, GitHub sponsorships, and having commercial support licenses available, the project struggles for funding. I asked him for his thoughts and perspective about open source funding:

The funding side of open source is something I’ve struggled with for a long time now, experimenting previously with less permissive license models (with disastrous effect) and now attempting to fund my work with commercial support licenses. Maybe people look at the number of stars/downloads a project has and see that as a measure of financial success that they don’t think they need to contribute to, or maybe they don’t appreciate the effort involved… I don’t know. What I do know is that something must change. The current situation is untenable and extremely harmful to maintainers.

I also asked Dave Glick, creator of Statiq (a .NET static content generator) and Discover.NET (a site for .NET community resources), to share his thoughts on open source funding:

To the extent a maintainer wants funding (and considering funding isn’t appropriate for, or wanted by, everyone for every project), I think the best thing we as a community can do is accept that the status quo isn’t working. If we use that as a starting point, then the next question becomes “what can I do that’s different?” There are alternate licenses to consider. There are platforms like Tidelift, Sdkbin, and others trying new sales models. The more maintainers that start looking outside the historically accepted project funding mechanisms and start considering and supporting alternatives, the sooner we can normalize those alternatives and hopefully lift up the entire ecosystem of open developed software.

Making open source sustainable

Open source is fundamentally good with the transparency and flexibility it brings; however, as our reliance on it goes up, the overall investment back into the ecosystem has not. It can be easy to take for granted the time and effort many developers put into open source projects. Yet it is with their time and effort that we often save our own.

These developers are not greedy or selfish for wanting funding for their projects. To the contrary, they want funding to keep the project alive. A person has to eat, after all. Funding the project is a means of changing the maintainer’s timeshare—allowing themselves to put time into the project that otherwise would be used for other employment. There is only so much time in a day that a person can otherwise give.

Funding should not be a struggle for open source projects. We embrace open source into our codebases frequently but have yet to fully embrace the idea that funding it actually helps us too. The bug fixes and feature requests need to be implemented, tested, and reviewed by someone who themselves can only put so much time into the project.

While there has been some progress recently with an announcement from GitHub, changing how companies can invest in open source projects, it may take a while to see its impact in the open source ecosystem as a whole.

Unfortunately there is no perfect solution that will solve all funding problems for open source. This post, more than anything else, is to draw attention to the issue that various projects that we rely on heavily may need help. Perhaps start checking whether the maintainer of your favorite project is seeking funding and see how you can help them raise it. Maybe talk to your boss how the sustainability of the open source projects the company depends on is a useful investment for the company. It is with these small actions, and others, that maybe funding open source projects will be less of a problem in the future.

Tags: ,
Podcast logo The Stack Overflow Podcast is a weekly conversation about working in software development, learning to code, and the art and culture of computer programming.

Related

newsletter January 15, 2021

The Overflow #56: An engineering argument

Welcome to ISSUE #56 of the Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams at Netlify. This week, we say farewell to Winterbash 2020, look for evidence that a program is being emulated, and create a chess AI that matches the skill of a player instead of…
newsletter April 2, 2021

The Overflow #67: Forget Moore’s Law. Algorithms drive technology forward

Welcome to ISSUE #67 of the Overflow! This newsletter is by developers, for developers, written and curated by the Stack Overflow team and Cassidy Williams at Netlify. This week: inertial navigation, new research from MIT on who’s building our algorithmic commons, plus a conversation with Slack about APIs and open-source. From the blog Forget Moore’s Law. Algorithms drive…