It'll be interesting to see if this works. I rarely found it worth my while engaging in a job with a new client if it billed under 10-15 days. $3500 is only a few days work, so they'll have to ensure the administrative overhead in bidding and billing is minimised.<p>> Whoever has the lowest bid at the closing time will have 10 working days to ship the code necessary to satisfy the criteria. If the criteria are met, the vendor gets paid. It's that easy. If the criteria aren't met, the next lowest bidder gets 10 working days to ship the code. In order to make this work, we will provide acceptance criteria, instead of requirements. This limits the possibility of misinterpretation and ensures the quality of delivery.<p>I fear that the focus on tight acceptance criteria will encourage gaming the system. There's no incentive for the contractor to do more than the bare minimum. Even if you gain a reputation with the procuring team of being reliable they still have to go with the lowest bidder for the next job.<p>For contractors, the optimum strategy would seem to be bid without spending any time coming up with an implementation strategy, then drop any jobs you win that don't seem worthwhile after a few hours working out how to implement it.<p>Ultimately this becomes a test of how well the jobs can be specified. For this to be efficient they have to include the time spent internally preparing and assessing the result vs working over a longer periods with people with whom they can build a trusting working relationship.
I think it's a neat idea, but I'm not a fan of their proposed bidding structure. Specifically, I think they will have problems with under-bidding and then abandonment. If lowest-bidder is based on some government requirement though, it's funny to see such a forward-looking system continuing to be constrained by the same broken rule-set.<p>The prototypical bug bounty in an open source project is to assign an award based on the perceived value of the code, and then open it up to submissions, while providing a central place for anyone to post about their working on a solution, their progress, etc. People are encouraged to communicate openly about their progress, and any new entrants can decide based on that chatter if they should work on it, or assume someone else will claim the bounty.<p>The only job for the person awarding the bounty is clear acceptance criteria, and public feedback on submissions. Then there are potentially issues with split bounties if multiple people end up contributing to the final result. Again, awards are at the determination of the offerer, but generally I think it's best if they don't directly control/assign the work.