 All right, I am going to have some fairly fine-grained stuff up here on the screen. So if you're in the back and you want to see what's going on, you might want to move up. This talk will be completely off message. Nothing in here is officially representing the interests or financial positions of Mozilla in any way. And of course, since every time you make a PowerPoint, Edward Tufty kills a kitten, this is done with some JavaScript instead of a proper presentation package. All right, so the part of Mozilla that I'm with is Mozilla Open Innovation, and we work on making open collaboration on the Internet work better. And three of the big problems that we're concerned with in open-source software are bias bugs and burnout. So low-quality software turns out to cost about $1.1 trillion worldwide. This is bad, and you can think of it as a market failure. Why is there a market failure in software? I mean, users prefer software to be released at a high level of quality, right? Also prefer to release software at a high level of quality, but given the presence of firms in the software market, all of which are trying to build network effects for particular projects, these firms are incentivized to release software at a low level of quality in order to get things out there quickly in order to build network effects. So why do we have connections between users and firms and between firms and peer production markets? Why out of the three ways of organizing productive human activity, either command and control within a firm or transactions in a market or cooperation in peer production like an open-source project? Why don't we have a direct connection between peer production and markets? And this market failure is only going to get bigger. We know that people who make $200 phones have trouble keeping them up-to-date with the security updates. Can you keep a $20 toaster up-to-date given software development, collaboration and quality the way it is? A related problem is the market for information about security defects. Even for extremely wealthy companies, such as Apple and Microsoft, the market price of vulnerabilities on the black market is much higher than those vendors can pay as part of a bug bounty program. That's for the best-funded bug bounty programs out there. For other companies that don't have the ability to pay competitive with state-sponsored or organized crime buyers for those defects, there's just no contest. So what is bug mark? This is the station that I stayed close to in Berlin. It's actually a station called Hackershire Marked, which means Hacks Market. Haka is the proper name. But bug mark is a futures market that trades on bugs in a bug tracker. This is something that we're doing research on right now. And our hypothesis is, Gary, wave your hand, Gary is doing research on this as well at University of Nebraska, part of the bug mark team. Our hypothesis is that using a market will result in new kinds of incentivization and information discovery. And most important, anyone with an interest in the software can trade in the market. The goals are to design a new system that will incentivize people to share information and incentivize people to perform software tasks. It will also enable peer production projects to use price signals to help determine users' priorities and efficiently allocate resources across projects. Remember that problem of having firms in the middle. If you've got, say, a software as a service company that has a choice between two features, one of which is going to produce $500 worth of value for 1,000 existing customers, but one of them is going to help them get two new $1,000 customers, they're going to go for the feature that brings in new customers rather than creating additional consumer surplus for the existing customers. So there's all kinds of really interesting to an economist kind of market failure stuff going on here in software. And so that's why we have this thing in the research phase. First of all, real simple scenario. A user can propose a contract, developer can accept the contract, do some work. The user closes out of their position at a loss, developer closes out at a profit, and the user gets their feature. Let's go through it step by step. All right, so here's Adam. Adam is a user of a particular software package. He's found a bug. He doesn't know how to fix it himself, but is interested in paying to get it fixed. First of all, Adam finds his bug in the issue tracker, and if there's no such bug in the issue tracker, then Adam can go ahead and create it. Next, Adam offers to pay for the bug fix by creating an offer to own the fixed side of a smart contract. Pays off in two weeks at a value of $200. Adam is offering to put up $160. If that bug is fixed, he'll lose his $160. If the bug goes unfixed, he'll get his original $160 back, plus $40 more if this contract is formed. Now, a developer, here's Beth, she sees the offer with a total value of $200. She can fix this bug, and she decides to buy the fixed side of the same futures contract. She's putting in $40. This contract will pay off $200 to Beth in the event that that bug is fixed. She'll get her original $40 back, plus the $160 that was put in by Adam. Total value $200, Adam put up $160, Beth put up $40. Beth is working, Adam is waiting, Adam sees that this contract has been formed. There are two possible outcomes. First outcome, Beth has fixed the bug, the project maintainer has resolved that bug, has closed, fixed. The contract matures, Beth gets the entire $200. Adam gets nothing, but he's got his bug fixed. The alternative, the bug stays open, Beth does not get her money. The $40 she put up goes to Adam, along with him getting his $160 back, Adam collects the entire $200. All right, boring, right? I just described an open source bounty and haven't companies been putting, hey, let's pay people to fix bugs, bounty systems on open source projects for 20 years now. How many people have used an open source bounty system? They're not super popular and we have some interesting hypotheses as to why people don't do open source bounties. This is my favorite. Imagine I find a bug in a web application and it needs some work done on JavaScript and it needs some work done on CSS. I put up a bounty. Now a JavaScript developer might work on the thing, nail the JavaScript part, get stuck on the CSS, but he's not going to say anything because he's trying to claim the entire bounty. Meanwhile, somebody else fixes the CSS, they get stuck on the JavaScript, again, they're trying to claim the bounty. So the extra overhead, the overhead on top of open source of contending for that bounty causes some possible productive cooperation not to happen. In bounty systems, there's the extra transaction costs above and beyond resolving the task of allocating the bounty to the appropriate fixer. Either you have people claiming bounties and then resolving it or you have people contending for bounties, it's not automatic. With bug futures, the contract ownership is decoupled from who reported the bug or who the bug is assigned to. Nobody can have a piece of any bug which incentivizes doing task sharing and incentivizes meta-info like reproducing a bug, translating a bug report from one language to another, assigning a bug to the correct subsystem, doing a code review on a bug. All that meta tasks, all those meta tasks are things that can be incentivized by who owns what pieces of what futures contracts. So in the case of the JavaScript CSS example, I would propose a smart contract. JavaScript developer buys the other side, works on it for a while, realizes, hey, I'm stuck on CSS. But that JavaScript developer can write a really good commit message, say, look, look what this JavaScript does, it fixes like 50% of this bug, you're going to want to buy out my side of it. The CSS developer comes along, they can buy the partially, they can buy out that fixed side of the contract, finish it, commit to work. Both developers have earned a profit on their part of the work. The bug assignee is never the same as the contract, the bug assignee does not necessarily have to be the same as the contract owner. It's never enforced that the owner of either side of the contract is the original reporter or the assignee. We also have the interesting use case of predicting discovery of bugs by category of vulnerability. So if you see a particular project that you believe, thanks to running some static analysis tool or some other knowledge that you might have, that a particular category of bug is likely to be found, you can trade directly on that prediction. And the market prices of these predictions can provide a signal to the people who are in a position to fix these issues, to come back and do the appropriate work. There's a company called QB that's doing a tool called QB Mind for resolving true false questions, and we're working with them on a microsite. So join the bug market now, it's mailing list if you're interested in getting an announcement when that microsite is up, it should be next month. Software quality problem, why are we dealing with this now? Well, go back and read everything Quinn Norton has ever written, of course. We've been conditioned to believe that software rots as fast as fruit. Clearly that's not sustainable, clearly we have a market failure. But was it open source originally supposed to fix all this? Anybody read the Fuzz Revisited paper from the 90s? This was a really interesting study. It said that 15 to 43% of the standard UNIX tools that were shipped with UNIX versions from Sun, IBM, SGI, Digital, and Next, 15 to 43% of them would just crash on random input. The versions that were bundled with Linux derived from the GNU tools, 9%. If you took vanilla GNU tools, 6%. You thought we were really on to something with open source. By 2004 though, every browser, every major browser but Internet Explorer, failed a Fuzz Test. And of course, we've got bugs out there that have logos. And the S in IoT stands for security, where the open source haters of the 90s write. I don't think they work. I think we've got some elementary market failures that we can fix. But I do think the clock is ticking. I do think regulation is coming. Here's Bruce Schneier saying that availability and integrity threats are important as real risks to life and property. Zaynep Tufeki in the New York Times. Zaynep Tufeki is the writer who predicted all the mental manipulation of Facebook and she predicted that stuff back at the time of the 2012 election. So definitely worth paying attention to when she says it is time to consider whether the current regulatory setup which allows all software vendors to externalize the cost of all defects and problems to their customers with zero liability needs reexamination. There's going to be a crackdown on the software business and we're going to either get over-regulated or we're going to have to fix our own market failures. The good news is we've got people trying to fix the problem at several different levels. People are trying to make better languages that catch things at development time rather than run time. People are trying to fix practices by building healthy and productive open source communities, getting the right people in, more eyes on problems and people are working on incentives building better markets. For keeping contributors, that's another place where we can do better with better markets, when people quit open source, why do they leave? Well it depends on what group of people you're talking about and what motivation they had to get into open source to begin with. The independence people who are contributing because of the recognition they feel for their work, they're going to leave because of more appealing outside work. They might leave open source because of lack of financial support for attending events. Fixers, again, better non-open source work opportunities. Citizens, these are the true believers. They're not as motivated by the financial rewards but a lot of people leave open source for start-up jobs where we really need people retained in projects and working on core fixes. All right, now time for what you all came for, the actual live demo. Again, if you want to move down and get a better look, then please do so. All right, so Bugmark is an online market for tradable software issues. In this demo we'll be working with issue tracker data from GitHub and Bugmark will give project manager and users a way to incentivize work and it gives developers a way to get paid for their efforts. All right, I'm going to do Bugmark from the point of view of two users right now. So in the first example, the first example user is Jane, the technical writer, who wants to get paid for experience and effort and I'm going to take a look at issues. All right, so find issues. Here's one, only show match this offer button on offer detail page. Have development bug that I can decide to fix, all right, and I'm going to say contribute to fix. I'm going to log in as Jane, am I on the right page here? Am I on the right page here? For Jane I want to buy fix though, right? Jane's the developer. Yeah. All right, so Jane is going to decide to buy the fixed side of issue 119. And so this is the interface that lets Jane spell out the terms on which she wants to get paid for this contract and I warned you about sitting in the back. Jane is saying I will deposit 10 tokens toward issue 119 being fixed on February 4th and will require a profit of 90 tokens. And this will set the unfixed market price at 0.9 and return a total of 100 tokens. So Jane is putting up sort of earnest money of 10 in order to earn a profit of 90 if she fixes this issue. So Jane's going to hit create offer and there's now an open offer on that issue. All right, and Jane is going to log out and come back in later. All right, so now I'm going to come in as Joe, he's a project manager who wants to incentivize a software fix. So Joe's going to look at the issues and that first one is high priority and as Joe, I want to invest in seeing this fixed as soon as possible. So I'm going to hit invest in fix. And you can see there are two buttons because there's already a developer on the other side of this interested in working on it. Joe's going to hit invest in fix and now Joe has to log in. All right, now Joe is going to say, looking at issue 119 and Joe sees that there's the existing open offer from the developer with a total volume of 100. And you can see that this one says fixed. Somebody's already offering to take the fixed side of this one. So Joe can just match this one. If I wanted to, I could go in and propose a complete offer on the other side filling in the whole form, but in this case, I'm just going to match the offer that's already there. All right, and so it says I will deposit 90 tokens toward issue 119 being fixed on and there's the date and will require a profit of 10 tokens. So Joe is going to match the offer, form the contract, and up here it says new contract is created. All right, and so Joe is going to log out. So this is not something you would see as a trader. This is just me as the demo administrator moving the clock forward eight days. All right, so prepare to travel in time. All right, now we can see at the bottom, it says demo time. All right, so here we are in the future, and Jane is going to come in, test one, log in as Jane, and Jane's, oh, it is now seven o'clock, Jane. And so Jane's side of the contract is paid off. And go back to Jane's info page. Yes, okay, here it is. Con 23, value 100, resolved and fixed. All right, any questions? Ah, yes, over there. Okay, so the question is why would a developer want to do this if the person reporting the bug can refuse to accept the fix, or just not accept it in the given period of time? The answer is that the bugs are not resolved by the individual developer or by the reporter of the bug. The bugs are resolved by the project maintainer. The same way that the project maintainer would resolve anyone's contributions. So it's entirely possible that the developer who fixes the bug is the maintainer. So that leads to the flip side of the question, which is, hey, wait a minute, why wouldn't the maintainer cheat? And the maintainers say, check in a bogus fix and close something as fixed, and then take the user's money. The answer is that the system depends on a trustworthy maintainer who's going to keep the bugs, who's going to keep all the metadata on the bugs correct. All the resolutions depend on the maintainers closing in the bugs. Yes, yes, the Gitcoin project is a great example of an open source bounty system, and I like open source bounty systems. I see them as having the problems of transaction costs and insufficient coordination among developers. I think it is possible to do a straight up open source bounty system that integrates with a futures market as well, though. This is the demo in play money mode. The actual blockchain is coming in February and March. It'll be on the Ethereum blockchain. The Ethereum blockchain lets us run the type of smart contracts that we're doing here. Well, we expect that people will be able to split up issues and trade issues at intermediate points between the starting and ending price. So it's entirely possible that a maintainer or code reviewer might buy the fixed side of the contract before resolving it. Or it's possible that someone could own one of the contracts for a short time in order to write a failing test. We don't know which particular trading patterns are likely to be helpful. What we do have is we just had an agreement to work with one of the major bounty systems providers, one of the open source bounty systems that's been up there for, I think, eight years now. We're going to be able to compare their history data against market data and see what kind of patterns people are able to take advantage of with one system that they hadn't been able to do with the other. Yes, question in the back. The question is, do you have to add the project to bugmark or can you just trade on it? We realize that bugmark depends on project maintainers closing issues fairly. And so we never want to get into the situation where we're trading on a project without the awareness of the maintainer. Okay. So in bugmark, the project maintainer is always going to have to sign up that project for bugmark. We're not just going to trade on things without the maintainer being involved. And yes, maintainers do have a lot of choices of incentivization systems that they can poke up to. Oh, yes. Sagan? Okay, the question is, does the maintainer become a bottleneck? The answer is yes. If a project has a maintainer who's not reliably closing things in a time frame that would resolve that contract, then that's going to make people extremely unlikely to want to trade on that. And that's where open source metrics like the chaos project from Linux Foundation will help. There are situations where you can look at how responsive a project is, how likely bugs are to be closed within a certain period of time, and you can use that open source metrics data to help decide, A, whether or not you want to participate in that market, and B, whether how far out you want to set the maturity date. I think we're getting kicked out, so thank you all very much for coming, and let me just switch back to my info here.