Bounty Specification Discussion

[barwizi]

It is a real problem.   You assumption is that both teams produce equal results, but if we had picked one team that didn't have to compete then there would have been less diversity and quality would suffer.

If we start requesting proposals and funding them then we have a problem of evaluating the qualifications of individuals.   I suspect we will continue to learn what works best.  My goal is to find talent and hire them if possible and to use the bounties for long lead items that I do not have resources in house to handle.

There will be many different strategies that we will employ as we grow.

 I hereby tender my request for a new 100 PTS  (Open to neg)  Bounty to compile and maintain a "Skills Directory" comprised of those whose skills are now known to use to make referencing easy. It will include links to their previous works here as well as any information they wish to share. This may later be used as part of Keyhotee or any Directory type DAC.

[bytemaster]

It is a real problem.   You assumption is that both teams produce equal results, but if we had picked one team that didn't have to compete then there would have been less diversity and quality would suffer.

If we start requesting proposals and funding them then we have a problem of evaluating the qualifications of individuals.   I suspect we will continue to learn what works best.  My goal is to find talent and hire them if possible and to use the bounties for long lead items that I do not have resources in house to handle.

There will be many different strategies that we will employ as we grow.

[barwizi]

I see your points and I understand that the system as it exists now is something that has been developed and refined over time based on past experience.

Maybe I'm completely off base, I just think the bounty process, especially for large projects, in and of itself creates wasted effort.  Let's use the III website as an example.  Going through that bounty thread there are at least two submissions that look promising, super3 and itnom.  Two talented web developers/web dev teams.

How is it not a waste of time and effort for them both to be working on the same thing?  Only one site can get the bounty so the other is putting in all that effort for naught. 

Maybe my solution won't work (I'm not that vested in it as it only just came to me this AM, so I'm not offended that you're trying to rip it apart ), but there must be a better way to leverage the talent that appears on these boards so that work isn't duplicated.  The number one goal with my original suggestion was to maximize efficiency.

hehehe, i find that the best ideas i've heard come after stripping things down. I believe your proposal has it's uses, but not to try replace the Bounty syetm but to actually create a whole new class of jobs. Especially as you said for the larger more complex things.

I did not mean to offend, i am trying to ensure that development threads for bounties remain on topic, it makes a "log" of sorts.

[wasthatawolf]

I see your points and I understand that the system as it exists now is something that has been developed and refined over time based on past experience.

Maybe I'm completely off base, I just think the bounty process, especially for large projects, in and of itself creates wasted effort.  Let's use the III website as an example.  Going through that bounty thread there are at least two submissions that look promising, super3 and itnom.  Two talented web developers/web dev teams.

How is it not a waste of time and effort for them both to be working on the same thing?  Only one site can get the bounty so the other is putting in all that effort for naught. 

Maybe my solution won't work (I'm not that vested in it as it only just came to me this AM, so I'm not offended that you're trying to rip it apart ), but there must be a better way to leverage the talent that appears on these boards so that work isn't duplicated.  The number one goal with my original suggestion was to maximize efficiency.

[barwizi]

now we can truly engage this idea of yours.

So eseentially you are advocating a move to Tender rather than Bounty?

[wasthatawolf]

Moved from https://bitsharestalk.org/index.php?topic=1732.90 ...

The entire bounty system in its current form doesn't seem to be producing top quality products with any type of efficiency (i.e. the Invictus website).  I think everyone has great intentions and there is a lot of talent in the community but the process for disseminating, organizing and focusing that talent for complex tasks is so loose that we end up with a lot of accuracy and no precision.

I think betax nailed it here,

I have lots of spare money (pts), give me something quick, I don't know how to price it but I will give you what I consider what is fair considering the risk you take

These large bounties can be a huge risk to those that create submissions because in the end only one will be chosen and the others will not be compensated for their work.  At worst, it weeds out the best talent because they can't risk putting in the time to produce a final product that may not result in any compensation, and at best it results in a lack of focus because submitters must spend more time and focus on other projects that provide compensation necessary for their cost of living in the event their submission isn't chosen.   What we end up getting is a few average and above average submissions which are all accurate in that they meet the basic requirements of the project.  Also, in the end, the process is centralized.  The final decision is just a judgement call by bytemaster with no real measurable metrics (as most submissions meet the basic requirements).  Obviously, it's his company and he has the ultimate decision, but, why not create a new process that facilitates that decision to the point that by the end of the process its obvious to everyone what the final product will be.

Here's my solution:

Instead of asking developers to create completed content, why not create a transparent RFP (request for proposal) process and get the input of the community to decide on the the path we should take (what developer/informal group of developers/company should be chosen to complete the task).  Protoshare/Angelshare holders can vote for a proposal proportionally based on the number of shares they hold (not sure if this is possible...).  It is in the best interest of Protoshare/Angelshare holders to decide on the best value product that will grow the community and increase the value of their holdings.

Submitter's will include relevant samples of previous work, resume/references, a rough mock up of their design (if applicable), cost to complete the work, and some type of cover letter.

This should:

• Eliminate the need to set an arbitrary price (the market will decide)
• Open the process to top talent
• Give whoever is chosen the compensation they need to stay focused on the task at hand
• Allow for community input throughout the entire process

The RFP should define the project due date and incremental goals (each goal paired with a percentage of the total project cost) that must be shared with the community on a weekly basis for a comment and suggestion period (no longer than 24-48 hrs).  At the result of that period, the developer will make any necessary changes and submit that portion for final Approval.  Barring any major objections (or a veto by bytemaster), that portion is Approved, the developer is paid the portion of project cost associated with that goal and then moves on to the next task.  The development should be as open source as possible (easy with coding/writing, harder with graphic design) to allow for comments along the way to limit surprises during the more formal comment/suggestion period. 

Worst case, if the selected developer isn't producing, it will be obvious from the start and the RFP process can be re-opened to more proposals with a minimum loss of capital.  Best case, the developer produces great consistent content and the community is aware of the status of each project at all times.  Because the developer is being paid in PTS, it is in their best interest to stay on task and on time while producing quality work.

The biggest group of stakeholders are holders of protoshares and angelshares and with this process Invictus can empower those stakeholders to help make the decisions that will affect their wealth and ROI as an investor.

 

The size of the payout makes the risk worth your time, although this raises some questions.
Also you'll find that all bounties regardless of their size already have groundwork being laid out, read through them.

Also, in the end, the process is centralized.  The final decision is just a judgement call by bytemaster with no real measurable metrics (as most submissions meet the basic requirements).  Obviously, it's his company and he has the ultimate decision, but, why not create a new process that facilitates that decision to the point that by the end of the process its obvious to everyone what the final product will be.

Did you really read through the document? if so you'd note the insistence on publicity, this is to ensure open development processes kind of like conversation you have joined, showing that the system works. If it was not open, all you would have seen was a set of rules whose creation you could not trace, contest or help to form.

Instead of asking developers to create completed content, why not create a transparent RFP (request for proposal) process and get the input of the community to decide on the the path we should take (what developer/informal group of developers/company should be chosen to complete the task).

This is called a Tender and the only difference between the current system is name. Asking the community to decide who to choose to complte the task defeats the purpose, we are looking for someone who can complete the task. How do we decide without seeing their version of it? Keep in mind please that III is not the only entity that can post a bounty.

Submitter's will include relevant samples of previous work, resume/references, a rough mock up of their design (if applicable), cost to complete the work, and some type of cover letter.

lol, this is the crypto industry where we like our privacy. There are only two people on this forum that know who i really am, one of them being bytemaster, i'd like to keep it that way thanks. Trying to force disclosure like that will fall flat on it's face.

This should:

Eliminate the need to set an arbitrary price (the market will decide)
Open the process to top talent
Give whoever is chosen the compensation they need to stay focused on the task at hand
Allow for community input throughout the entire process

Lol, the thing that makes bounties get completed quickly is that number you want to remove. And trust me, i know a few of the guys here from other forums, you'd need college proffesors to beat some of them.

As a bounty hunter all i need to know is how much i am getting paid to produce a good quality product that will meet the posters requirement and when i should be done. If i have queries, i always ask, and along the way i open up my development process to the community for input kind of like what we are doing now.

The RFP should define the project due date and incremental goals (each goal paired with a percentage of the total project cost) that must be shared with the community on a weekly basis for a comment and suggestion period (no longer than 24-48 hrs).  At the result of that period, the developer will make any necessary changes and submit that portion for final Approval.  Barring any major objections (or a veto by bytemaster), that portion is Approved, the developer is paid the portion of project cost associated with that goal and then moves on to the next task.  The development should be as open source as possible (easy with coding/writing, harder with graphic design) to allow for comments along the way to limit surprises during the more formal comment/suggestion period.

As a person who is in full support of DACs and their uniqueness, also as a bounty hunter i reject the idea of "comment and suggestion periods" set in time, I want my customer to have full access to my work and be free to comment at anytime, i even tend to give them editing rights on my works which i post publicly. And piece-meal payments as good as that sounds would complicate the process, which we are hoping to be simple and straight forward.

Worst case, if the selected developer isn't producing, it will be obvious from the start and the RFP process can be re-opened to more proposals with a minimum loss of capital.  Best case, the developer produces great consistent content and the community is aware of the status of each project at all times.  Because the developer is being paid in PTS, it is in their best interest to stay on task and on time while producing quality work.

Again please read through the document and some of the Bounties and check their processes, the very mechanism of bounties does all that without need for supervision.

The biggest group of stakeholders are holders of protoshares and angelshares and with this process Invictus can empower those stakeholders to help make the decisions that will affect their wealth and ROI as an investor.

Software, graphics and other bounties emanate from ideas and suggestions that are already floating about in the community, some of the more III ones come from things they need to meet certain objectives. You'll find that quite a few of the ones on this subforum were requested by the community. Perhaps we can move this  conversation to the bounty discussion thread.. as you are also suggesting we scrap bounties.


As the person who is wrote this document and a bounty hunter, i have tried my best to stick to the rules i've written as a means of encouraging their adoption and thus far they seem to be working. Should there be need to chnage the system then that is another thing altogether but this document is about the rules and procedures of the bounty syatem, not the development of a new system. The reasons the bounty system is used not only by the crypto industry but by most huge tech and security firms are numerous, apart from creativity and speed they create a hiring pool for easier pickings later, which is worth more than you can imagine.

A lot of the people asking to change the system are not bounty hunters themselves, most are not even developers. Using the mind and working on these projects is time consuming and requires a certain temperament, otherwise nothing gets done. Before you start judging how much their paid, walk in their shoes a bit. 

I stand by my basic premise that the bounty system in its current form creates a lot of wasted effort by those whose submissions are not chosen and has not resulted in the highest quality products. 

All I'm attempting to do with this proposal is maximize the utility of all work done by members of the community while getting the highest quality, best value product on time and keeping everyone informed every step of the way.  I think we can all agree these things are important to us as stakeholders.

Being as this is just an informal idea, I expect certain aspects to be changed and better defined.  In the interest of being clear and concise here are my key points:

- Developers submit a proposal with some proof of ability to complete the task (I'm not suggesting disclosing your real identity, that's not what I meant by resume/references) -> best quality
- Project cost is not defined upfront, it is submitted as part of the proposal -> best value
- Once a proposal is chosen by the community, the developer is paid incrementally as work is completed (increments do not have to be time driven per say, but I think there should be a firm date for final project completion) -> incentivize "risk averse" talent to submit proposals
- Project is transparent and open to comment from inception to completion (I can agree we are basically at this point) -> community driven

I'm sure there are methods to facilitate a process like this that I haven't thought of.  I'm just throwing this all out there to see what other members of the community think.

Also, I don't think the bounty system is all bad and I think it can/does work great for smaller, specific tasks.  I just don't think it has been working that great for the larger more complex ones.

I would not know about wasted effort, have you taken part in any bounties? If so please provide links, perhaps i'll run into these wasted efforts then we can start agreeing.


Developers submit a proposal with some proof of ability to complete the task

That is pointless, why would i jump on a web dev bounty when i know nothing about it? It would become obvious when i fail to produce anyway. And the only way to prove you qualification is to produce relevant links or paperwork, which i iterate again, people like their privacy. The very nature of decentralization is privacy, the whole point becomes moot if i have to prove anything to anyone. All that is required is the submission of a product that meets the customers requirement and fits the quality spec. The development process is public so it's clear that the applicant is the one doing the work.

Project cost is not defined upfront, it is submitted as part of the proposal -> best value

The thing i feel you are not really appreciating is the difference between BOUNTY and TENDER. What you are suggesting is no different from the bidding system that was suggested earlier in this thread. The thing that is making people interested is not some noble cause to help the community, it's the price tag, and as a result they strive to produce products that meet the customer's expectations.

Try it and see what a bidding war will produce, cutthroat competiton and work that will either never be completed or simply will not be supported by the dev after completion. And what you are suggesting amounts to contracts which is something we are working pretty hard to avoid around here.

Once a proposal is chosen by the community

Ok, i have a personal Bounty, what does the community have to do with that? The rules and procedures are just that, rules and procedures applicable to bounties. Be they III or individual or other DACs.

III did not create bounties, we are simply defining the procedure in print.

paid incrementally as work is completed Please just read what i have told you to read, it gets boring to keep repeating that. it's right there stickied on the subforum.

Also, I don't think the bounty system is all bad and I think it can/does work great for smaller, specific tasks.  I just don't think it has been working that great for the larger more complex ones.

Please tell me what you understand by the words "to be defined" and "construction"

PLEASE LET US MOVE ALL CONVERSATION ABOUT REDEFINITION TO THIS THREAD https://bitsharestalk.org/index.php?topic=1679.0

You are going to make it harder for people to follow the development process for this bounty if you keep posting discussion issues here. I thank you very much for understanding.

[5chdn]

The bounty discussion should be sticky'd. 

[prateek300588]

Kool!!

You should check out the reply I have left under: "200 PTS - Bounty Rules and Procedures Document"

I believe what you talk of is a very potent idea.
Internal economics of organisational work, I have written a brief there

Declaring the bounty is a different topic, you should add 'negotiable'... If you compromise with the manager then you pay <= bounty
else
You pay >= bounty. Took me some time to think up a design for your process ("Rules and procedures"), if you like the thought let me know I would take time to think out a design.

 
Cheers!!

[bytemaster]

I want to be able to start a bounty discussion with something vague like:

1000 PTS to implement web-based wallet for BitShares like CryptoKit.

Someone could produce a half baked implementation that is ugly as hell and full of bugs and attempt to claim the bounty.

Imagine going into a home builder and saying, I want to buy a house and can pay $200K.   The home builder throws together a shack and sends you a bill without ever even discussing the details.  All bounties must start with a meeting of the minds and clear consensus on what is required.   This can only occur through forum discussion. 

Obviously when the home buyer approaches the builder they only know vaguely what they want and expect the builder to work with them before locking down the contract.

In our case I want to set the bounties high so I can demand excellence and completeness... these are not budget bounties designed to attract the lowest bidder minimal effort.  These are prizes to be awarded to someone who satisfies my vision for the bounty.   

[bytemaster]

One of my biggest concerns with bounties is that there is ALWAYS someone claiming they have completed the bounty and demand to be paid.  It must be very clear that these types of disputes do not lead to a revolt or loss of trust.  It almost always comes down to clearly defining objective criteria.  Unfortunately, for many things there is no objective criteria.

Many times people will try to claim a bounty on a semantic technicality based upon the letter of the agreement rather than the spirit of the agreement.   If we are required to be legalistic on every bounty specification it will dramatically increase costs and ultimately fail.   Instead, we need all parties to operate on the basis of trust, good faith, and two way meeting of the minds.  Especially when a bounty is still in the early phase of discussing requirements.

 

[bytemaster]

For coding bounties we should have a post-submission bug-finding bounty funded by deductions from the original.   In this way someone who submits code for consideration knows that their reward could be greatly reduced if too many bugs are found.  The final acceptance of the submission will be based upon the result of all bug finding.  Bug finders don't get paid unless their bug fixes are accepted into the final product.  So a those finding bugs will tend to focus their efforts only on the submissions that are likely to win and developers will be pro-active about quality control and standards compliance.
 

 

[luckybit]

I agree cooperation is better, so we want people to claim dibs on a particular bounty so no one can take it from them.  If two developers both want to go after a bounty then they would have to bid lower.  Obviously two people could bid on a task and accepting the lowest bid is not going to produce the best quality code as people will bid low and then deliver late (or not at all).  These false starts can delay the whole process.  In order to evaluate bids requires us to interview developers and from experience I can tell you that interviews are very poor predictors of performance.

This was my thinking on having a bounty token. The holder of the token owns the contract/bounty in the exact proportion of the amount of the token they own with 1 being a whole token and then divisibility down from that which they can distribute to others. Then whomever redeems the token gets their proportional share of the profit all in automated fashion.

I admit this would probably take a bit of work in itself to build but it's just smooth to me.  Interviews could probably be automated away unless you're hiring someone for a long term project and you want to see how they can work with others already on the team. For that interviews can perhaps tell you how they get along. Reputation could tell you who is known to be reliable and reliability does not mean that they always finish the task but that they distribute the task to someone else far in advance of the expiration date if they aren't up to the task. It's entirely possible that someone can take a bounty, start working on it, get 25% complete and find out they cannot do the other 75%. This person should be able to redeem their bounty profit from the 25% they did complete and whomever completes the other 75% should redeem their bounty profit.

I think that if you define tasks to be small enough that a competition involves first to complete at a certain quality level then it could work.  The goal would be to keep things small, well defined, and to separate DESIGN from implementation. 

I agree with this. Design has to be separated from implementation. A design contest for example could be great for theoretical researchers, but sometimes the best programmers who can create bug free code aren't up to date with the theoretical research side.

Given that github makes tracking code / commits easy that we can make open development a requirement as well.  Blatant copies of someone else's implementation would be easy to track and the copy-cat would always be a commit behind the leader.

Good point.

The result is that design ideas could be shared, but coding/implementation could not be shared UNLESS one contestant wanted to cooperate and share the bounty by working together.  Obviously two people working together and then splitting the bounty will have a better chance of winning than solo-players. 

One thing the bounties seemed to work well for are short simple tasks which a programmer can do by himself in a few hours. Automating things with scripts for example would work great using a bounty provided that a scripting language is built in to allow this.

In other words I think we could allow contestants to 'license' their contributions to each other and claim the prize.  A contribution that contains copied code without permission of the author would be rejected.  This will force a Nash Equilibrium where two parties must agree on how to divide the bounty rather than forcing us to be the judge.

Interesting. This could work.  Lets see how it goes using this method.

[bytemaster]

I agree cooperation is better, so we want people to claim dibs on a particular bounty so no one can take it from them.  If two developers both want to go after a bounty then they would have to bid lower.  Obviously two people could bid on a task and accepting the lowest bid is not going to produce the best quality code as people will bid low and then deliver late (or not at all).  These false starts can delay the whole process.  In order to evaluate bids requires us to interview developers and from experience I can tell you that interviews are very poor predictors of performance.

I think that if you define tasks to be small enough that a competition involves first to complete at a certain quality level then it could work.  The goal would be to keep things small, well defined, and to separate DESIGN from implementation. 

Given that github makes tracking code / commits easy that we can make open development a requirement as well.  Blatant copies of someone else's implementation would be easy to track and the copy-cat would always be a commit behind the leader.

The result is that design ideas could be shared, but coding/implementation could not be shared UNLESS one contestant wanted to cooperate and share the bounty by working together.  Obviously two people working together and then splitting the bounty will have a better chance of winning than solo-players. 

In other words I think we could allow contestants to 'license' their contributions to each other and claim the prize.  A contribution that contains copied code without permission of the author would be rejected.  This will force a Nash Equilibrium where two parties must agree on how to divide the bounty rather than forcing us to be the judge.

In summary competition can produce cooperation even for large tasks so long as the rules do not reward stealing.   I would suggest making use of github with regular commits a requirement.  If people copy then it can be contested and the reward shared.   I still think 'first to market' with the highest quality is the best way to get results.

[luckybit]

That said, these systems are chicken & egg.  Without a lot of jobs few developers will participate because they need a steady, predictable, source of new work before they consider freelance work full time.   The other problem is committing to a single developer who fails to deliver in a timely manner results in delays.  Eventually I would like to move to this model as it would be most efficient/profitable for both developers and employers.  But before we can do that we must bootstrap the development community.

I was thinking more along the lines of a combination marketing/development effort.  Everyone wants us to distribute PTS / AGS / BTS far and wide with 'give aways' that generate buzz and excitement.   In this market SPEED and QUALITY are the most important factors and with the amount of money to be made cost is almost no consideration.   So the way you get speed is to make it a race.  The way you get quality is to make it a requirement to win the race.   The way you get developers to compete is to make the prize outsized to justify the risk of losing.   The way you get a large number of developers is to pay bounties for referring the winner to the bounty. 

The problem I saw with the competition model in the documentation contest bounty in Mastercoin was that people did not and could not work together which sacrificed quality for competitiveness. I think cooperation can produce a better product than competitiveness in most situations. Competitiveness can get something completed faster but it also introduces risks which would not exist if work could be shared without any punishment. For this reason a bounty exchange model could work better because work could be divided up or exchange. You're right that there has to be a lot of jobs for the exchange model to work but if crowd funding takes off like we think it will there will be plenty of jobs for everyone.

How much marketing buzz and talent do you think we could recruit if we launched a well organized bounty campaign worth $1 million USD total divided among hundreds of bounties?  If these bounties were all competitions where the amount you earn from winning the race is 2-3x what you could earn with a straight up contract? 

I think competition for writing code does not necessarily produce better quality code. You could end up with code which is more buggy or less safe than usual. You could end up with programmers who would ordinarily share knowledge instead keeping it to themselves as trade secrets. You could end up with some trying to game the system to win the competition to get more money by stealing other peoples work.

For this reason I don't think it should be rushed but I do agree for certain specific tasks you can go with this model. For critical functionality or components I don't think competition beats cooperation and team work.

The goal would be to manage the campaign bounties in a way that is transparent, easy to understand, and predictable.  I would like to discuss how we could operate such a campaign.

I think it all depends on the budget. If the budget is big enough you could have the bounty exchange and the competitive campaigns running at the same time for different kinds of work. You could have teams working and cooperating and have competitions to solve really difficult design oriented problems.

A lot of problems with code are just about designing an algorithm or coming up with some pseudo-code. For stuff like this I think competition is best because the code does not have to work well or work at all, it just has to be some algorithm to solve some specific problem. For contests we need to find specific problems which remain unsolved and set high bounties which DECREASE over time. This would encourage people who have the solution to this problems sitting in their notes to open their notes and describe the solution. It could be in the form of a white paper, or a forum post with pseudo-code.

But I think if we are talking about writing code to secure our money we should do that cooperatively. Not a contest or competition to solve some tough theoretical problem but the focus is instead on writing secure, bug free code which can pass peer review and auditing. This in my opinion is very important.

[bytemaster]

We have plans to start offering a large number of bounties for every imaginable skill, but would like to establish some formal guidelines so that those attempting to win the bounty can have a predictable experience without many of the problems faced by prior bounties.   This thread is meant to foster discussion on ways to structure bounties to add clarity and prevent disputes or at least resolve them quickly.  The goal of the bounties is not to get the jobs done cheaply, but to get them done quickly and of high quality.   Lessons learned from past bounties:

1) Avoid subjective criteria
2) Keep submissions private to prevent copy cat
3) Set the bounty high enough to justify the risk
4) Define the deliverable clearly
5) Have a dispute resolution policy
6) Deadlines ? 

We would like to establish a checklist by which to rate the quality of a bounty specification and improve upon our execution of the bounties.

This idea would require a fully functioning Keyhotee and some sort of exchange platform but I figure I'll put it up for debate just to make conversation.

How about a bounty exchange platform with an Ask/Bid?
It would be centralized at first but could be made decentralized, and it's one way to determine who would be selected for the bounty in an automated fashion.

So basically if there are a lot of DACs which all need a similar job there could be an exchange built into Keyhotee with bids and asks for the really high priority important in demand type jobs.

First you'd put up your bidding price, then a bunch of potential bid fillers put up their asking price and according to the algorithm it would meet in the middle according to supply and demand at an equilibrium point. This would give the market the true price of the labor.

This is exactly where I would like to go to decentralize development / labor.   Centralized companies often have trouble allocating resources (their best employees) because it is centrally managed and there is no internal market to regulate demand from QA vs R&D vs Support for various developers.   I think it could be entirely centralized as there is nothing illegal with running a job board/market.   

That said, these systems are chicken & egg.  Without a lot of jobs few developers will participate because they need a steady, predictable, source of new work before they consider freelance work full time.   The other problem is committing to a single developer who fails to deliver in a timely manner results in delays.  Eventually I would like to move to this model as it would be most efficient/profitable for both developers and employers.  But before we can do that we must bootstrap the development community.

I was thinking more along the lines of a combination marketing/development effort.  Everyone wants us to distribute PTS / AGS / BTS far and wide with 'give aways' that generate buzz and excitement.   In this market SPEED and QUALITY are the most important factors and with the amount of money to be made cost is almost no consideration.   So the way you get speed is to make it a race.  The way you get quality is to make it a requirement to win the race.   The way you get developers to compete is to make the prize outsized to justify the risk of losing.   The way you get a large number of developers is to pay bounties for referring the winner to the bounty. 

How much marketing buzz and talent do you think we could recruit if we launched a well organized bounty campaign worth $1 million USD total divided among hundreds of bounties?  If these bounties were all competitions where the amount you earn from winning the race is 2-3x what you could earn with a straight up contract? 

The goal would be to manage the campaign bounties in a way that is transparent, easy to understand, and predictable.  I would like to discuss how we could operate such a campaign.