FAQ

Primarily addressing potential problems post-mozfest research with implementing a public market:

Why are you doing this?

Because we want to help the people with the best skills and information contribute to solving the most important problems for collaborative projects.

To that end, we want to make peer production more effective. We are attempting to add more incentives to do useful work in peer production, and increase the breadth and range of work that people are willing to do.

More specifically, we would like project managers, technical writers, designers, support people, and security analysts (among others) to have as much incentive to work for open-source software projects as developers. We would like people to be able to perform partial work on a problem (including "meta" work such as bug triage) getting paid for that work by those who would like to use the resulting software. We want to build a system that incentivizes collaborators to work together, share information, and hand off problems to others where appropriate.

We think the first step in achieving this is to create new types of markets around software issues.

Do financial incentives to fix bugs kill other incentives, like altruism?

Small trials, measured steps. This is one thing that we will be trying to measure in early trials.

What if: Right before a contract on a bug fix is about to close, I just hit the close button myself on the bug tracker, fooling the oracle into thinking I have done verified work?

We are going to have to put systems in place to prevent that. The resulting loss of reputation is a disincentive to close a bug dishonestly. There are obvious systems that involve human intervention - those might work if people are incentivized appropriately to take action to prevent this problem. More complex systems that solve problems of this kind are being experimented with in blockchain-based systems.

What if: Having bet 50 bucks I could fix a bug, I get sick right before I check in, and lose my money?

Market prices might make this less important. If the bug is worth 1000 bucks, and you buy your interest at a price of 0.1 odds, then you put up $10. That's probably worth the risk and no big deal if you get sick one out of 100 times. This is still actually a hard human problem. How do you verify that someone got sick and didn't just decide to squat on a contract? There may be an auto-sell if you don't check in or some other weird solution, but a real solution might come down to a tough, messy, meatspace solution of some kind.

How will you deal with front-running?

See the use cases on the design page for now. More later.

Can we somehow use/does it make sense to use the findings of behavioral theories like loss & risk aversion and prospect theory (related to the topic of losing money and decreasing motivation) without creating dark patterns?

TBD - we're doing some research on this one.

Will Bugmark become an extra forum that dilutes project discussions or hosts harassment?

We are designing Bugmark to avoid these. This includes avoiding making user profiles and free-form chat features. In fact, our design philosophy is to allow no free form text of any kind. We don't need to allow that for any feature we can envision being useful.

Why use blockchain technology for this?

What can you do with a decentralized, automatable, transparent, immutable, permissionless, publicly maintained system anyway?

In many use cases, you can reduce fraud and build something predictable, survivable, and efficient - something you can trust long term.

These are desirable characteristics of long lasting systems in which the stakes are high and the number of participants is greater than one.

Think about accounting, voting, governance, central banking (and banking in general), law and markets - where we are playing.

Blockchain tech is not the only tech for the job - but it is the best tech for the job in many cases.

Here are a few reasons we find it interesting:

• Create more trustworthy markets with verifiable, immutable records. Why trust us? Don't. Verify.
• Reporting automation is easy (relatively) and pretty convincing.
• Survivable - bus factor infinite. Scaling and uptime of on-chain stuff is automatic. Constructs like smart Contracts, IPFS, ENS, all exist on "User Run Infrastructure".
• Collaborative development is the norm - apps are decomposed into APIs that evolve - and there is a big ecosystem out there already to integrate with - much of which expands market capabilities and governance.
• Standards based, resellable, programmable tokens can list on a broad ecosystem of exchanges - including decentralized exchanges - you gain liquidity and advanced instruments without the risk and expense of building a broader market - you get advanced trading products like options, derivatives, insurance - without having to implement those - and more than one market can gain access.
• Tradable tokens also, of course, make it possible to transfer ownership easily, and in a relatively verifiable manner - you don’t get that free anywhere else. Owners of tokens (and most cryptocurrency in general) can take total control of their money - keep it cold storage or on exchanges.
• Tokens are programmable, and can have complex characteristics - expiry, usage restriction, upgrades, etc.
• There is also a case to be made that pseudonymous accounts and complex privacy mechanisms (using SNARKS STARKS, etc.) might increase privacy or expand user bases in apps like security information markets.
• Incentivization integration - tons of potential, here - this is a deep topic.