Or, what Voltron can teach us about improving open source development.

Get the newsletter

Earlier this year, Tidelift conducted a survey of over 1,200 professional software developers and open source maintainers. We found that 83% of professional software development teams would be willing to pay for better maintenance, security, and licensing assurances around the open source projects they use. Meanwhile, the same survey found that the majority of open source maintainers receive no external funding for their work, and thus struggle to find the time to maintain their open source projects.

So, to put what we learned succinctly:

Many open source maintainers lack the funding necessary to maintain their projects to a professional standard

Professional development teams will pay to get more dependability around the open source software they already use

Our conclusion?

It's time to pay the maintainers.

Not just because they deserve to be compensated for their amazing work creating the software infrastructure our society relies on (they do!). But also because there is a ready-made market of professional developers willing to pay for assurances they are in the best position to provide.

Here's an idea for how to do it.

The free-rider problem opportunity

In the open source world, we hear a lot about the free-rider problem. It is so easy to download code and get to work that users often don't stop to think about 1) who is actually writing the code they are using, and 2) what is the motivation for them to continue to write that code and maintain it.

If you are a student or a weekend hacker, you probably don't really care. You just want access to a specific package that solves a problem you have this very second. And the process of using a new open source package is so frictionless that you don't even realize you're doing it. Just type npx create-react-app hello-world, a wall of text scrolls by, and you've installed over 1,000 distinct, new open source dependencies, each with its own creator and maintainers (hopefully! 🤞).

So, what's the problem?

The problem is someone out there wrote that code you are using. And they may or may not be getting compensated for their work (spoiler: they probably aren't). As a result, they may or may not be looking after that software on an ongoing basis.

Therein lies the opportunity.

Professional application development teams also benefit from the frictionless nature of open source experimentation and exploration when they are creating their applications. Just like hobbyists and students, they download and use the code for free.

But when that software needs to go into production in a professional organization, messy, difficult questions emerge.

Is anyone actively working on this package?

Will they continue to maintain it in the future?

Does it have any known security vulnerabilities?

What license is it distributed under, and how compatible is that with our usage?

Will I regret my decision to use this package in two years?

The funny thing is, even if these professional developers have their checkbooks in hand, for many projects there is nothing to buy. There's no commercial offering available, and no consistent set of promises about quality and dependability from project to project.

Professional developers don't want to pay for software. They want to pay for promises about the future.

Think about the companies that have been most successful building profitable businesses around open source software, companies like Red Hat, MongoDB, and Cloudera. The thing they have been able to provide—and the reason professional development teams are willing to pay them big bucks—is they make promises about the future and follow through on those promises.

Meaning: If you use this code, we promise it will continue to work. When changes are made to packages the code depends on, it will continue to work. When hackers attempt to exploit vulnerabilities, they will be fixed quickly, and things will continue to work.

These companies give professional developers consistent answers to concerns like these. When you buy a subscription from them, you know who to contact if there is an issue. You know someone is agreeing to keep the code functioning well into the future. You know someone is watching out for security issues and keeping you out of dependency hell.

This is worth a lot of money to a lot of organizations.

Yet, for most open source projects out there—projects used every day in critical settings—no one is making these promises.

Why not?

Voltron and the benefits of size

In the 1980s, there was an animated TV series called Voltron. It was the story of a giant super-robot made up of a bunch of smaller vehicles. The typical Voltron storyline involved the evil Drule Empire wreaking havoc on some poor Galaxy Alliance planet. The Voltron team would come to the rescue, but invariably they could never defeat the Drules—until the good guys had the bright idea to bring all their vehicles together to form the Voltron super robot. Like this:

The Drule Empire was pretty tough competition, but once Voltron assembled, watch out.

What if we applied a similar principle in the open source world? For massive projects like Linux, Mongo, and Hadoop, the scale is big enough that a profitable company can form around the project. But the vast majority of open source packages out there—numbering at least into the millions—can't achieve the kind of scale where it makes sense to build a large company infrastructure around them.

But if they were to band together to create the open source equivalent of a super robot, it could be a win-win, helping professional development teams and open source maintainers alike. Professional developers get software they can depend on. Open source maintainers get paid. Simple and beautiful.

There's a move underway in the industry to provide better support for key projects and packages. It's something we at Tidelift and many others are working to solve. If this is a conversation you're interested in, please join us.

Topics

About the author

Donald Fischer - Donald Fischer is co-founder and CEO of Tidelift, which makes open source work better—for everyone. Tidelift gives software development teams a single source for purchasing and maintaining their software, with professional support and maintenance from the experts who know it best.

4 Comments

It's not clear to me that monetization of open source development is a good thing. For one thing, it isn't like there is just one maintainer for some package. There are many, and their contributions are highly variable. One person may make a large number of commits, but mostly cleaning up kinds of improvements, and someone else may make few, yet do things which markedly advance the capabilities. So you need to arbitrate this, and this creates a layer of arbitrators, who want to be compensated for their work too. Soon you get to a corporate culture. What if open source contributors don't want that?

I believe the big issue is not just whether the maintainers get paid, but how they get paid and who their boss is when they get that pay.

Frequently, companies are glad to hire maintainers on staff to gain influence over the project. This is usually implicit rather than explicit, and the best maintainers are very good at, effectively, extracting funding from their employer to work on what they think is best for the project. But that's a highly complex political skill that not every maintainer wants to (nor should have to) develop.

This is why I have devoted my career to building charitable infrastructure that can fund development work in software freedom projects. At Software Freedom Conservancy, we have at least seven maintainers from five different projects regularly funded to work on their project. (And there are more, that's just what I could count quickly in my head while writing this comment. Here's a few blog posts that talk about that.

I really believe that where and how the developer gets funded matters. USA 501(c)(3) charities must act in the public good, and do work that benefits the entire public. By extension, developers who work for a charity can focus completely on making the world better with their software, and they aren't themselves (or even work regularly with those who are) required to meet sales targets, or otherwise make sure the endeavor generates revenue for the organization. Ultimately, everything a FLOSS charity does is basic software freedom infrastructure, maintenance, and R&D for the community.

And, this isn't just a pitch for Conservancy. There are many charities where one can affiliate their project and get this done. In addition to Conservancy, there's FSF, Software in the Public Interest, and even Open Source Initiative is looking into doing some of this as well.

Finally, another thing not mentioned in the article that developers often need as much as direct payment for development work is funding for travel to hackfests and conferences (which is also easier to raise money for as the amounts aren't as much). We do that too at Conservancy.

Footer

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat.

Opensource.com aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. Red Hat and the Red Hat logo are trademarks of Red Hat, Inc., registered in the United States and other countries.