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.
4 Comments