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:
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.
Mostly programming, market design and incentivization material this time.