
Open Source Micro-purchasing: An experiment in federal acquisition - jonmarkgo
https://18f.gsa.gov/2015/10/13/open-source-micropurchasing/
======
laurencerowe
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.

> 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.

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.

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.

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.

------
zaroth
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.

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.

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.

