Open source is a powerful economic boost for software developers and software users.

When software developers can match their own skills and interests to development tasks, they create more software value for less investment in coordination and management.

When software users can evaluate and adopt new software without the transaction costs of licensing and license audits, then people and organizations get more software value for less administrative overhead.

As long as we can keep people doing open source, the benefits are transformative. But how can we design economic systems that incentivize people to stay or become active in open source and earn a sustainable income?

Incentives Research is part of the movement to go beyond the old answers, which already help support open source in a few niches, to discover new models that make higher quality open source a viable alternative in more software categories.

Old answer 1: Cognitive surplus

Much of the world’s open source has been the result of what Prof. Clay Shirky calls cognitive surplus. People like to build fun things and do creative work. When we have free time we often occupy it with arts and crafts, games and collaboration.

Some cultures and institutions can supply copious free time to some members. If you have a flexible corporate job at Bell Labs, or are a student at a university in Finland, you have the freedom to allocate your development skills to solve interesting and important problems.

However, free time is not a reality for most people who are qualified to create value with software. High education costs and corporate short-termism are squeezing out the free time that naturally turned into open source productivity. Today, a fortunate few may enjoy cognitive surplus, but how can open source become a reality for the micromanaged many?

Old answer 2: Complementary goods

Open source programs are complementary goods to many other products and services, as pointed out in the Some Easily Rebutted Objections to GNU’s Goals section of Richard Stallman’s 1985 GNU Manifesto. Stallman suggested that

A manufacturer introducing a new computer will pay for the porting of operating systems onto the new hardware.

Today, this model is a significant part of the open source economy, as hardware companies pay developers to write and release Linux support for their products. The developers are both valued members of the Linux kernel project and valued employees. Linux is the highest-profile open source success story in part because, as a general-purpose OS kernel, it is a complement to so many other goods. Joel Spolsky explains the model in Strategy Letter V.

Open source development is also the complement to a developer’s paid labor, when used as part of the GitHub is the New Resumé effect. And in the open source service and support model, code is the complement to support.

While complements are one way to keep open source development paid for, many situations in which software can create value are not as an easily tied complement to something else. Good examples include CAD and other content creation applications, where complements are less well coupled, and per-seat pricing and proprietary licensing still dominate.

Increasing quality levels

Developers would prefer to release open source software at a high quality level and get paid for it. Many users would prefer to use software at a higher quality level if they could pay for it. The current software market, though, incentivizes companies to release at a low quality level, in order to get early adoption and build network effects.

Our approach is to build a new kind of market, one that allows users to hedge their software quality risks while enabling developers to trade on the likelihood of bug fixes. Market mechanisms enable participants to quantify software risk, then enable users with a preference for high quality and developers with a preference for high quality to interact directly, not through the filter of software companies that win by releasing early at a low quality level.

Part of a new software financing model

Futures contracts are part of a family of tools for software incentivization that includes subscriptions systems and open source bounties. Incentives Research builds on the basic futures market system to incentivize more complex tasks that require coordination among participants.

Incentivizing partial work and meta work (such as bug triage and writing failing tests) would be prohibitively expensive to manage using bounties claimed by individuals, where each claim must be accepted or rejected. The bug futures concept addresses this with radical simplicity: the owners of each side of the contract are tracked completely separately from the reporter and assignee of a bug in the bug tracker. And bug futures contracts can be traded in advance of expiration. Any work that a participant does that meaningfully changes the probability of the bug getting fixed by the contract closing date can move the price.

A developer might choose to buy the “fixed” side of the contract, do some work that makes it look more fixable, then sell at a higher price. Developers and project managers might choose to do day trading of small steps, such as translating a bug report originally posted in a language that the developers don’t know, helping a user submit a log file, or writing a failing test. Trading is structured and incentivized so as to reward accurate predictions on accomplishing a software task, which has potentially transformative implications for the so-far intractable task of predicting software milestones.

With the right market design, participants in a bug futures market have the incentive to communicate, by sharing partial work and metadata. Our market design is built around the concept of incentivizing collaboration and meta work, not simply individual tasks subject to contention.