Design
- User Stories
- Functional Specs
- Contract Design Doc
- New Design wireframes
- Usability Testing Script
- IPC Discussion
- Comparables
- Potentially Crazy Feature Ideas
Bugmark is a marketplace for tasks, implemented as futures contracts on the status of issues in a bug tracker.
All market positions are tradable, which allows us to incentivize things like project management and human resources work. Users can buy positions on issues and work all or part of them, trade them, or subcontract them.
Bugmark introduces pricing signals into peer-produced projects that have not been present to date, without centralizing the projects further. Security evaluations are an example of the type of information that can be produced by bugmark. Price and volume data provide a signal of the severity of a known issue, or the likelihood of discovery of a yet-unknown issue.
Another key feature of Bugmark is that it is extensible. Payout algorithms can be defined and added to issues - so an issue can pay out in a way that incentivizes, for instance, the search for root cause bug fixes.
Ultimately, Bugmark could also be self supporting on its own market.
See also: The FAQ
Joe wants emoji on his blog. Joe sees that the project has an existing bug 31337: "Add emoji support." In order to incentivize a fix, Joe proposes a smart contract:
I will invest $18 if I can collect $20 on Sept. 1 if bug 31337 is unfixed.
Jane sees the smart contract proposal. She counter-offers: I will invest $2 and collect $20 on Sept. 1 if bug 31337 is fixed.
The smart contract is formed automatically. Joe invests $18.25 and Jane invests $2.25. Jane fixes the bug and the project maintainer closes it. She receives $20. The oracle that closed the smart contract receives $0.50. Joe loses his investment, but gains the feature, which he values more highly.
Jane writes a program to analyze security data and runs a study that shows that libraries that have substantial code formatting changes without adding new test code are more likely to have security issues discovered. She makes a list of libraries with this property, and, for each one. proposes to enter into a futures contract that will pay her if an entry in the CVE database contains a link to the library.
Frank maintains an image thumbnailing library that he believes is an exception to Jane's theory, because he has fuzz-tested and audited it. He forms one contract with Jane on his own library.
Mary is making a web site. She needs a library for image thumbnailing, so she looks at the market to see where it predicts that vulnerabilities will be found. She chooses Frank's library. Later she signs up with a service that will buy "CVE discovered" futures on all of a site's dependencies, in order to lower the risk of unpredictable updates by incentivizing more work like Frank's.
This is a more complex use case in which a payout algorithm is chosen that requires payment be made in installments. Alice fixes bug A, and starts receiving payments. If, during the installment payment period, Bob fixes bug B, and bug B is the root cause of bug A, then remaining payments redirect to Bob. This is just one example of Malvikas work on incentivizing deep fixes that can be incentivized with pluggable payout algos.
This is a simple side-effect of tradable contracts but it is worth mentioning.
If you own the fixed side of a contract (paying for a fix), and need to get your money out, you can sell your side of the contract partway through the fix (before the bug is entirely fixed, checked in, reviewed, etc.) - you will probably have to sell at a discount, effectively sponsoring the fix during the time you held your side of the contract.
If the underlying task of a contract is verified completed, but contract maturation has not been reached, then the person who completed the task can check in, and offer to sell her side of the contract - this is a no brainer for an investor to purchase, as the task has been verified - the fixer just wants the liquidity right away instead of later - should be easy to arrange and depending on the price this can be fair and amenable to all.
Rich knows that he can fix issue #123 in the Gravity Whitepaper repo: "create and embed diagrams visually describing the three capabilities models in section 4".
He sees that Sally has proposed to form a smart contract that would pay her $100 in the event that "Issue #123 in the Gravity repo remains unfixed on 1/1/19". Sally offers to buy the UNFIXED side of the contract for $80.
Rich invests $20 to buy the other side of the contract: a claim that that issue will be fixed on that data. Rich gets two out of the three images done, then life happens. Something comes up, he has to travel, and he realizes he doesn't have time to finish the work before the deadline.
So Rich checks in his partial work for all the world to see, then offers to sell his side of the contract for $50.
Joe buys out Rich's position, with the intention of checking in that last image, and closing out the issue. Joe checks in the last image, and closes out the issue.
In the end, Rich comes out ahead $50, having done partial work on the issue. Joe has a gain of $30. Sally has a loss of $80, but has the diagrams that she needs.
Tradable contracts are important for incentivizing partial work -- which is a key thing that futures markets can do but pure open source bounty systems have trouble with.
Joe wants emoji on his blog. Joe sees that the project has an existing bug 31337: "Add emoji support." Joe proposes a smart contract: I will invest $9 if I can collect $10 on Sept. 1 if bug 31337 is unfixed.
Jane sees the smart contract proposal, and understands that the blog project can only support emoji if the template package that it depends on supports them. Jane becomes an arbitrageur by taking the "fixed" side of Joe's contract, and the "unfixed" side of the "Add emoji support" bug in the template project.
Joe does not have to know the dependency relationship, and the market gives the arbitrageur an incentive to collect information about multiple dependent bugs into the best place to fix them.
Dudley Do-Right's open source project has a bug in it, users are offering to buy the "unfixed" side of the contract in order to incentivize a fix, and a trader, Eve, realizes that Dudley would be unlikely to let the bug go unfixed. Eve takes the "fixed" side of the contract before Dudley wakes up. The deal means that the market gets information on the likelihood of the bug being fixed, but the developer doing the work does not profit from it.
This is a "picking up nickels in front of a steamroller" trading strategy. Eve is accepting the risk of Dudley burning out, writing a long Medium piece on how open source is full of FAIL, and never fixing a bug again.
Front-running game theory could be interesting. If developers get sufficiently annoyed by front-running, they could delay fixing certain bugs until after the end of the relevant contracts. A credible threat to do this might make front-runners get out of their positions at a loss.
We are planning to conduct more research to understand the risks of front-running, and how to design a market that is resistant to it.
Ernie and Bert discover a software vulnerability. Bert sells it to foreign spies. Ernie wants to get a piece of the action, too, but doesn't want Bert to know, so he trades on a relevant CVE prediction. Neither Bert nor the foreign spies know who is making the prediction, but the market movement gives white-hat researchers a clue on where the vulnerability can be found.
A possible positive externality from BugMark is the potential to reduce the trustworthiness of underground vulnerability markets. The existence of a system that motivates those who know about zero-day vulnerabilities to leak information, and enables those leaks to take place with high confidentiality, may tend to lower the expected rewards of selling vulnerabilities in underground markets and drive more vulnerability sales to maintainer or vendor operated bounty programs.
This is an area where further research is necessary.
Chad manages a web site that depends on open source projects for long-term technology stack decisions. Chad hires a data scientist to report on project credibility and stability, and they use prices and volumes on bug futures as a credible signal of project quality and developer interest.
Bots might have several roles.
-
Move investments out of duplicate bugs. (Take a "fixed" position in the original and an "unfixed" position in the duplicate, or vice versa.)
-
Make small investments in bugs that appear valid based on project history and interactions by trusted users.
-
Track activity across projects and social sites to identify qualified bug fixers who are unlikely to fix a bug within the time frame of a contract, and take "unfixed" positions on bugs relevant to them.
-
For companies: when a bug is mentioned in an internal customer support ticketing system, buy "unfixed" on that bug. Map confidential customer needs to possible fixers.
-
Parse the dependency relationships among projects, and automatically invest in projects on which a company's tech stack depends.
Joe wants animated ASCII art in his blog. He buys the "unfixed" side of a tracking bug, in the expectation that he will lose but incentivize the fix.
Jane decides to fix it, does the work, and posts a pull request that would close the bug. But the maintainer is on vacation, leaving Jane's pull request unmerged. Another developer, Mark, is willing to take on the delay and risk of merging the work, and buys out Jane's position.
Bob spends a lot of time on a project's bug tracker, modifying metadata: assigning a bug to the correct subsystem, identifying dependency relationships, cleaning up spam, and moving invalid bugs into a support ticket tracker or forum.
Bob makes small market gains from modifying bug metadata in a way that makes them more likely to be resolved. He uses a simple interface where he estimates the likelihood that a bug will be fixed by a certain date, and the software calculated and places the appropriate trades.
Hans is a participant in an open source project where most of the developers speak one language. When an end user reports a bug in a different language that Hans knows, he posts a translation in order to help the developers fix it. When he believes that his translation is likely to increase the likelihood that the bug will be fixed, he can trade on his knowledge.
Alice knows Sam and Bob. Sam is a reliable coder and Bob is a domain expert with a solid understanding of the projects he participates in. In a secondary market, she invests in the outcome that all bugs on which Sam works this year, and all bugs reported by Bob, will be fixed successfully.
Neither worker achieves a 100% success rate, but Alice makes a profit by successfully predicting their general success level. (There is no reason secondary markets cannot be formed on the bug market data - this is all verifiable, immutable data.)
Joan is managing the development of a new retail site. She is selecting a database, and looking for a high-quality one.
Ray is a sales rep for an open-source database vendor. When preparing his sales deck for a meeting with Joan, he includes a live ticker from the database's bug futures market, to show that few issues are open and the market expects them to be resolved quickly. The ticker is provided by an open-source metrics company that runs an "index fund" on the database's bug futures.
Rose is the Director of Product Marketing for the database vendor. She invests in "fixed" futures on the "index fund" in order to add a strong quality signal to the database vendor's marketing message.
Anna is CIO of a bank, and the back office is running OpenAbandonWare 0.1, a widely used but no longer maintained software package. She is interested in incentivizing enough work on the package to see a measurable increase in the market-measured software reputation of the bank's stack -- but does not want to leak information about where the potentially vulnerable software component is installed.
Evan offers a personal cryptocurrency backed by hours of his work time. His "Evancoin" is trading at $250. Misha discovers a bug that he believes Evan could fix in two hours, and $1000 of FIXED is available for $250. Misha buys 2 Evancoin for $500, and a $1000 Bugmark FIXED contract for $750. Misha redeems his 2 Evancoin for the two hours of work, Evan fixes the bug, and Misha makes a $750 profit on his Bugmark position and a $250 profit overall.
https://docs.google.com/document/d/1nPgE3RSMw2uZrSuCoN7LBqBi2YKI_sIk2M_PVbnmG-U/edit
https://projects.invisionapp.com/share/CRE3H73X8#/screens
https://docs.google.com/document/d/1aUuRTFgvh5fOnSPOLr3dSaOr33ao8NiW7tUXxPo1XMs/edit?ts=59eeafa6
Dapp-V0-Functional-Specs - basic success flow of minimal smart contract
Dapp-V0.1-Functional-Specs - minimal dapp ui to go with the V0 contract
List here projects with design elements that we might want to emulate
- Augur https://app.augur.net/
- Gitcoin https://gitcoin.co/about
- Gnosis https://gnosis.pm/
- Good Judgement https://www.gjopen.com/
- Iowa Electronic Markets http://tippie.biz.uiowa.edu/iem/
- Inkling https://home.inklingmarkets.com
- Predictious https://www.predictious.com/
- Predictit https://www.predictit.org/
-
Futures - as described elsewhere
-
Odds - 10:1 - I give you 10 bucks if x happens, you give me 1 if not.
-
Payout algo contracts for installment or other payout mechanisms
-
Scoring algo contracts for user reputation
-
User data - we want pseudonymous users, but it would be nice to allow them to register metdata.
-
ERC20 contracts - all bounties and forecasts are tradeable.
-
User portfolios - a user contract is created at signup that holds all their bid contracts - it's tradable as well as a derivative.
-
Whisper - add secure messaging between users
-
Crowdfunding - make it possible to add to a reward or a future contract - join in with others.
-
Crowdfunding milestones - make it possible to build a milestone and payout each time an issue that is declared in that milestone is resolved.
-
Restrict reward to a github ID - "I will pay X if Y is closed by DATE by PERSON"
-
Feedback to github of market data. Start with a repo badge (https://github.com/dwyl/repo-badges) to take you to the market, and then see if we can extend that on a per-issue basis somehow, perhaps by allowing the oracle to use labels.
-
Restriction modes: Aside from resticting the issues allowed - we might want a setting to restrict the update of issues until they have been checked by the admin.
- Need to coordinate with Malvika to see what kind data researchers can use to learn how we might collect it into reports. We need researchy-type questions so we can start to see what should be collected, i.e. How effective are arbitraguers in addressing project management needs? How effective are they as recruiters?
See also: User Docs