Open source: who's paying the bills?

Open source software isn’t free—someone else paid for it.

Working on open source software is often a voluntary pursuit. But for many there's an opportunity cost for that time: a salary that could have been earned, another cause that lost a little support, leisure time that had to take a backseat. And for everyone involved there are bills that need to be paid.

So, since we know open source software takes time to make, and that time isn't free, how do open source projects pay the bills today? Here are some of the common ways:

Subsidies

It’s very difficult to categorically claim this is the case, but I suspect that the most popular way—by a country mile—to sustain an open source project today is through personal or corporate subsidy in which the 'free time' of an individual or company pays for development and maintenance. This often takes two forms:

• Personal labor subsidies - Many open source developers have a day job and work on open source exclusively in their spare time.  In other words, they subsidize the work with the paycheck from their day job. Possible motivations for doing this include intellectual challenges, developing skills, helping others, and reputational benefit.

• Corporate labor subsidies - Less frequently (but still commonly) open source work may be directly funded by an employer, either as a side effect of their responsibilities at work (e.g. a component that is needed for a business application or strategy) or through an explicit allocation of time to work on an open source project.

Patronage

In patronage models, a group of people or organizations pool their resources to support a project—with free services, spaces to work and meet, or hard cash. Some patronage models come free of restrictions while other gifts are given to help incent projects to move in a particular direction. Here are a few key types of patronage:

• Donations to projects - A small number of popular, visible projects can collect considerable sums through no-strings-attached donations from individual and corporate users, either as donations to a charitable foundation associated with the project (e.g. the Python Foundation) or through a mechanism like Open Collective.

• Donations to individuals - A few individuals have succeeded with personal sponsorship campaigns to support their work on high-impact projects. These people typically use platforms like Patreon to support their work.

• Corporate patronage - In a few cases, large organizations pool capital to support open source projects together because they further corporate goals. A prominent example of this model is the Linux Foundation members and their supported projects.

• Grants - There are increasing examples of not-for-profit sponsorship of open source projects from foundations like the Ford, Alfred P. Sloan, and Gordon and Betty Moore foundations. Grants typically support work in exchange for agreed targets. For example, Libraries.io was initially supported by Ford's Internet Freedom Programme and Sloan’s Digital Information Technology programme. Unrestricted grants are typically reserved for projects that have established a strong rapport and basis of shared goals with their funders.

Products and services

Finally, projects can (and do) support themselves through commercial products and services. Over the last 20 years, a number of replicable commercial models have emerged around open source:

• Commercial distributions and assurances - This model is based on the 'one and one is three' principle of bundled services. By aggregating open source components into 'distribution', they become easier for commercial organizations to use effectively. By including some assurances with these packages, operators centralise much of the cost of adopting and using open source for larger companies, saving them that pain and expense. These distributions are provided on an annual subscription basis, with the cost tied to the value provided by the distribution and assurances offered. It's difficult to talk about commercial distributions of open source software and not mention Red Hat. Red Hat's Enterprise Linux distribution was launched nearly 18 years ago. Since that time, Red Hat has grown into a $3B open source business.

• Hosted Services - For some projects—usually larger, more complex 'direct' dependencies like database, cache, search, and messaging—there is the opportunity to provide a hosted SaaS service for paying customers. Project maintainers are typically the most knowledgeable and able people to instantiate and operate their own software. And in doing so they explicitly offer a number of assurances, including things like uptime, compatibility, and maintenance as part of the package. There are many singular examples of this—Discourse is a great example—but it's also fair to argue that Amazon Web Services, one of the fastest-growing IT businesses of the last 10 years, is in fact largely comprised of hosted open source software.

• Licensing - There are a number of strategies around licensing that can result in simple, scalable financial support for a project, the easiest of which is relicensing or dual licensing—removing the restrictions that otherwise stop a commercial organisation from using the software, in exchange for a fee.

• Enterprise features - There are also various forms of the "open core" model, in which a proprietary extension pairs well with a corresponding open source project.  Typical examples include extensions that are valuable only in commercial settings such as an enterprise LDAP and SAML extension, or compatibility with a paid-for CMS like Sitecore.

• Bespoke development and consulting - Individuals and corporate entities can provide custom software development and/or support related to open source software commercially. This category shares some of the characteristics of subsidised income, in that the work that is done subsidises the work that betters the project. Projects that use this method to best effect have a roadmap—an in-depth understanding of where the project should go—so that if and when the opportunity arises the development commissioned can benefit everyone involved.

• Merchandising, events, and sponsorship - These three things share a lot of characteristics: they involve considerable amounts of work that do not directly benefit the project and they have a strong separation between the source of the revenue and the use of the revenue. A strong example of this category of support working for a project is the Python Foundation and PyCon, the annual conference which raised over $2m in 2016 for the foundation and its projects.  

The need for balance

Sure, some of these models poke and pry at the edges of the open source philosophy, but open source in the modern era is about balance. A balance between the needs of the project and its contributors and the need to preserve the freedoms enshrined in its license. Equally, there has to be a balance between the implicit incentives and influences that exist when money is a part of an open source project. And often the best way for open source projects to do this is to use a combination of the models we’ve described.

For example, an open source project might have:

• Some volunteer contributors who works on the software project to feed their own curiosity.
• Some passionate individual users who donate small amounts of money to the project out of a sense of gratitude.
• A core team contributing work as part of their day job because their employer uses the project in a business application.
• A group of individuals who make themselves available for paid consulting to customize, extend, and deploy the software for specific applications, and use the proceeds of that to fund additional open source work.
• A company that provides the software as a hosted service and contributes its changes to the open source project out of a combination of good will and self-interest (so they don't need to self-maintain a perpetual fork of the project).

In fact, many of the most well-known open source projects use a combination of models.

Conclusion

Open source and commerce have been working reasonably well for decades. It's great there are a variety of solutions, and that by using them in combination we can protect a project from the influences that might come with any one source of income.

But what can we learn?  

For one, commercial models that are based on selling something of tangible value seem to scale better. But they can be less efficient at funneling revenue to the people actually creating and maintaining the software. Is it completely necessary for a foundation to have to put on a huge conference each year just to stay alive? For projects to spend countless hours writing proposals for grant-making institutions or donation drives?

Could we do better?  I think so, and that's what we're focused on at Tidelift.

If you are interested in learning more about open source sustainability, consider signing up for updates or following us on Twitter.