Daemonic Dispatches

A plan for open source software maintainers

• Free software is expensive. Software is expensive to begin with; but good quality open source software tends to be written by people who are recognized as experts in their fields (partly thanks to that very software) and can demand commensurate salaries.
• While that expensive developer time is donated (either by the developers themselves or by their employers), this influences what their time is used for: Individual developers like doing things which are fun or high-status, while companies usually pay developers to work specifically on the features those companies need. Maintaining existing code is important, but it is neither fun nor high-status; and it tends to get underweighted by companies as well, since maintenance is inherently unlikely to be the most urgent issue at any given time.
• Open source software is largely a "throw code over the fence and walk away" exercise. Over the past 15 years I've written freebsd-update, bsdiff, portsnap, scrypt, spiped, and kivaloo, and done a lot of work on the FreeBSD/EC2 platform. Of these, I know bsdiff and scrypt are very widely used and I suspect that kivaloo is not; but beyond that I have very little knowledge of how widely or where my work is being used. Anecdotally it seems that other developers are in similar positions: At conferences I've heard variations on "you're using my code? Wow, that's awesome; I had no idea" many times.
• I have even less knowledge of what people are doing with my work or what problems or limitations they're running into. Occasionally I get bug reports or feature requests; but I know I only hear from a very small proportion of the users of my work. I have a long list of feature ideas which are sitting in limbo simply because I don't know if anyone would ever use them — I suspect the answer is yes, but I'm not going to spend time implementing these until I have some confirmation of that.
• A lot of mid-size companies would like to be able to pay for support for the software they're using, but can't find anyone to provide it. For larger companies, it's often easier — they can simply hire the author of the software (and many developers who do ongoing maintenance work on open source software were in fact hired for this sort of "in-house expertise" role) — but there's very little available for a company which needs a few minutes per month of expertise. In many cases, the best support they can find is sending an email to the developer of the software they're using and not paying anything at all — we've all received "can you help me figure out how to use this" emails, and most of us are happy to help when we have time — but relying on developer generosity is not a good long-term solution.
• Every few months, I receive email from people asking if there's any way for them to support my open source software contributions. (Usually I encourage them to donate to the FreeBSD Foundation.) Conversely, there are developers whose work I would like to support (e.g., people working on FreeBSD wifi and video drivers), but there isn't any straightforward way to do this. Patreon has demonstrated that there are a lot of people willing to pay to support what they see as worthwhile work, even if they don't get anything directly in exchange for their patronage.

It seems to me that this is a case where problems are in fact solutions to other problems. To wit:

• Users of open source software want to be able to get help with their use cases; developers of open source software want to know how people are using their code.
• Users of open source software want to support the the work they use; developers of open source software want to know which projects users care about.
• Users of open source software want specific improvements; developers of open source software may be interested in making those specific changes, but don't want to spend the time until they know someone would use them.
• Users of open source software have money; developers of open source software get day jobs writing other code because nobody is paying them to maintain their open source software.

I'd like to see this situation get fixed. As I envision it, a solution would look something like a cross between Patreon and Bugzilla: Users would be able sign up to "support" projects of their choosing, with a number of dollars per month (possibly arbitrary amounts, possibly specified tiers; maybe including $0/month), and would be able to open issues. These could be private (e.g., for "technical support" requests) or public (e.g., for bugs and feature requests); users would be able to indicate their interest in public issues created by other users. Developers would get to see the open issues, along with a nominal "value" computed based on allocating the incoming dollars of "support contracts" across the issues each user has expressed an interest in, allowing them to focus on issues with higher impact.

I have three questions for my readers:

1. If this existed, would you — an open source software developer — sign up and use it?
2. If this existed, would you — a user of open source software — be likely to pay to support, and receive support from, an open source software developer?
3. Does anyone want to build this?

Pending the answers to the first two questions, I'm enthusiastic about this idea; if I wasn't already running Tarsnap I would probably go ahead and build this myself. But I'm not Jeff Bezos and there's no way I could run two startup companies at once; so finding someone else interested in building this would be crucial.

I think something like this could fill an important gap in the world of open source software. Maybe I'm crazy. Feedback requested.

Q: Are you talking about bounties for open source software development? There are websites for doing that.
A: No! This would be different from bounties in several ways:

1. Sponsors would be supporting a specific developer, not setting aside money for whoever comes along and claims it. This is important because bounties tend to result in horrible "drive-by coding" which causes problems for maintainers later.
2. This would be about providing ongoing funding for a developer, which would allow them to spend time on long-term code maintenance, not just chasing after the latest in-demand feature.
3. While there would be a "dollar value" attached to issues, that value would just be informational — telling the developer how much users care about that particular issue. The developer would get money from their monthly subscribers regardless of which issues they address. (Of course, if they don't respond to issues they may find that supporters cancel their ongoing funding.)