blog: Don Marti


Day-to-day experiences with bug futures

29 December 2019

In theory and in the lab, futures contracts are a proposed way to make the missing connection between open source and markets. Has everyone read "A market for trading software issues" in the Journal of Cybersecurity?? Here's a figure from Marktplatz zur Koordinierung und Finanzierung von Open Source Software: figure

The next interesting question is: how do futures work in a real project? Are bug futures just high-tech piecework? This is my subjective notes on participating in a small project using futures. (We got in the habit of using FIXED and UNFIXED, all-caps, for the two sides.) It feels like we're on to something, that the market is adding some information sharing and coordination power that's not available in the bug tracker alone. I'm looking forward to using markets in more projects in the future.

Habits: I did get into the habit of quickly selecting what to work on based on my FIXED positions. I think I'm more of a loss avoider than a profit maximizer, and I probably passed up some chances to buy into something I could have finished faster, and just take a loss when an issue where I held FIXED ended up being unfixed on the maturity date. Something to try in the future: I might be more willing to try to resell my FIXED positions at a loss if the project had more traders.

Pricing: As a project contributor, I tended to use price as a signal of my confidence in being able to get something to work. For an issue with a good description and (imho) a straightforward fix, I would offer to buy a large quantity of FIXED at a higher price, which means putting more of my own tokens at risk. This should help other participants judge the likelihood of completion of particular tasks by particular dates. The actual prices in the live, small, market ended up being quite a bit higher then the examples in the paper.

I did end up offering extremely low prices for less well specified issues. This was, I think, a useful signal for the people requesting the features. The better specified the issue, the more likely to get a reasonable offer. I don't know how this would be different in a project with more random wishlist bugs. There might be a trading opportunity for people willing to hold FIXED through the process of clarifying a feature request.

Maturities: I think a sensible "portfolio" view is important, and would like to experiment with better ones. As a random part-time contributor it was important to me never to build up too big of a workload for a particular maturity date. I did find myself making offers on an existing issue that didn't match an UNFIXED offer from a user, because I wanted a later maturity date. Offering a low price and a far-off maturity date was the best way to signal that either this issue is not comprehensible enough for me to fix, or it's too much for a single issue and needs to be split up.

I would like to see more live data on whether feature requesters try to buy UNFIXED positions on contracts with less crowded maturity dates (dates when fewer other contracts mature) to have a better chance of getting attention.

Next steps

If you're interested in trying bug futures for a live project, please let me know. I already have futures hooked up to one that's using Python+Flask for the server, and JavaScript+WebExtensions for the client. The market can also be hooked up to existing product. Currently supports GitHub but more integrations are certainly possible.

Mostly programming, market design and incentivization material this time.

Programmers Should Plan For Lower Pay

GitHub stars won’t pay your rent

Private BitTorrent trackers are markets

Russ Allbery: Review: On the Clock

What do I mean by Skin in the Game? My Own Version

Mozilla Web DNA survey shows the biggest pain points for web developers

The Early History of Usenet, Part I: Prologue

Eller's Algorithm

Why You Never Have Time

When an SQL database makes a great Pub/Sub

Mike Hoye: Over The Line

Artificial Intelligence: Threat or Menace?

Advantage Flywheels

3 Reasons Why Building A Remote Team Is One Of The Best Decisions We’ve Ever Made