"Bounty" approach for small pieces of code?

[Hal Fulton]

I seem to recall there was some discussion here of
people paying small amounts for small pieces of code
(a la rentacoder).

Speaking from the paying end, I'm thinking something
more as a stipend or a courtesy amount -- nothing
competitive, you understand.

Of course, speaking from the opposite end, I wouldn't
object if someone offered me a large sum of money for
a weekend of coding...

Does this concept seem interesting to anyone? Worth
discussing?


Cheers,
Hal

 

[Mark Hubbart]

I seem to recall there was some discussion here of
people paying small amounts for small pieces of code
(a la rentacoder).

Speaking from the paying end, I'm thinking something
more as a stipend or a courtesy amount -- nothing
competitive, you understand.

Of course, speaking from the opposite end, I wouldn't
object if someone offered me a large sum of money for
a weekend of coding...

Does this concept seem interesting to anyone? Worth
discussing?

Are you meaning something like a combination of RubyQuiz and Google
Answers? If so, I think that would be a great idea

cheers,
Mark

 

[Ara.T.Howard]

I seem to recall there was some discussion here of
people paying small amounts for small pieces of code
(a la rentacoder).

Speaking from the paying end, I'm thinking something
more as a stipend or a courtesy amount -- nothing
competitive, you understand.

Of course, speaking from the opposite end, I wouldn't
object if someone offered me a large sum of money for
a weekend of coding...

Does this concept seem interesting to anyone? Worth
discussing?

puts 'yes' # that'll be two cts ;-)

-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| renunciation is not getting rid of the things of this world, but accepting
| that they pass away. --aitken roshi
===============================================================================

 

[Hal Fulton]

Are you meaning something like a combination of RubyQuiz and Google
Answers? If so, I think that would be a great idea

Something like that, yes.

Hal

 

[Bil.Kleb]

I seem to recall there was some discussion here of
people paying small amounts for small pieces of code
(a la rentacoder).

I'm definitely interested on the paying end, but
I haven't figured out if the Federal Acquisition
Regulations allow me to use rent-a-coder, etc.

Any other gov-types out there that know?

Later,

 

[Ara.T.Howard]

I'm definitely interested on the paying end, but
I haven't figured out if the Federal Acquisition
Regulations allow me to use rent-a-coder, etc.

Any other gov-types out there that know?

we pay some guys to do work for us. in addition to a regular contract we have
a fund to nickel and dime them for small projects. i'll ask how it works.

cheers.

-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| renunciation is not getting rid of the things of this world, but accepting
| that they pass away. --aitken roshi
===============================================================================

 

[Wayne Pierce]

Take a look at:

http://farsite.hill.af.mil/reghtml/regs/far2afmcfars/fardfars/far/13.htm#P172_25875

Depending on the price this is likely to fall under the micro
purchasing exception of FAR Part 13.2. Micro-Purchasing exempts you
from most of the FAR regulations, if you meet some requirements on the
price and project scope (c: the project must be directly related to
your business vs. speculative research).

There's much more at the first link, which should answer just about
any question you have. I've never been on the admin side of
procurement, but don't see any reason why you wouldn't be able to do
this. So long as you make the bidding open and fair, while not
costing the government more money in the process.

Wayne

 

[Gavin Kistner]

--Apple-Mail-1--611786539
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed

I seem to recall there was some discussion here of
people paying small amounts for small pieces of code
(a la rentacoder). [...]
Does this concept seem interesting to anyone? Worth
discussing?

I've been wanting to do something like this on an IRC front for a
long time, but the issues of Trust have made it hard to figure out
the details.

It's an exchange of goods where neither person trusts the other, both
holding on to what they have while grabbing for the other person's
goods. When it's something physical, you don't let go of what you
have until you're sure that you have a firm grasp on what the other
person is offering.

But if it's information, I see two choices:

1) You let the person offering the bounty review the answer and
discover if it's valid. How then do you prevent that someone from
getting their answer and then saying "No no no, that wasn't what I
wanted at all. I'm keeping my money (and the information that's now
in my head)." ?

2) You force the person offering the bounty to pay up before seeing
the solution. What then do you do if the solution is "Ha ha, you
suck, I've got your money now!" ? (That case is easy to resolve by a
third party, but what if the solution is real code ... how much work
do you want to do diving into each solution and determining if it's a
'perfect' match?)

Hrm...what if the answer is precise specifications, in the form of
unit tests? What if the person offering the bounty is responsible for
providing a clear set of specifications AND unit tests for the
interface, and the System runs the unit tests against the solution to
automatically verify that it's valid.


With the IRC model I have been thinking about, you'd need to
bootstrap the system and get to a point where everyone involved had a
nice history of Trust rankings, based on grades of their solutions,
number of solutions, number of disputes, and so on. (You' d also have
those rankings distributed over a wide variety of information
topics.) But that's a general description of the end result, and
glosses over the details of how to get there (and assumes that such a
system makes 95% of the people using it happy).


--
"When I am working on a problem I never think about beauty. I only
think about how to solve the problem. But when I have finished, if
the solution is not beautiful, I know it is wrong."
- R. Buckminster Fuller


--Apple-Mail-1--611786539--

 

[Wayne Pierce]

With the IRC model I have been thinking about, you'd need to

bootstrap the system and get to a point where everyone involved had a
nice history of Trust rankings, based on grades of their solutions,
number of solutions, number of disputes, and so on. (You' d also have
those rankings distributed over a wide variety of information
topics.) But that's a general description of the end result, and
glosses over the details of how to get there (and assumes that such a
system makes 95% of the people using it happy).

The money goes into escrow at some point to ensure the programmer(s)
can get paid, the same might be done with the code. If the sponsor
wants to see the code in action to verify functionality it could be
placed on a trusted site for them to interact with, without seeing the
source.

Once they have "signed off" on the results their payment is sent, when
the payment is sent the login information is sent to the sponsor to
download the code. This may not work for all types of code, but the
general idea could probably be adapted.

Is anyone actually planning on building a market like this?

Wayne

 

[Bill Guindon]

I seem to recall there was some discussion here of
people paying small amounts for small pieces of code
(a la rentacoder). [...]
Does this concept seem interesting to anyone? Worth
discussing?

I've been wanting to do something like this on an IRC front for a
long time, but the issues of Trust have made it hard to figure out
the details.

It's an exchange of goods where neither person trusts the other, both
holding on to what they have while grabbing for the other person's
goods. When it's something physical, you don't let go of what you
have until you're sure that you have a firm grasp on what the other
person is offering.

But if it's information, I see two choices:

1) You let the person offering the bounty review the answer and
discover if it's valid. How then do you prevent that someone from
getting their answer and then saying "No no no, that wasn't what I
wanted at all. I'm keeping my money (and the information that's now
in my head)." ?

2) You force the person offering the bounty to pay up before seeing
the solution. What then do you do if the solution is "Ha ha, you
suck, I've got your money now!" ? (That case is easy to resolve by a
third party, but what if the solution is real code ... how much work
do you want to do diving into each solution and determining if it's a
'perfect' match?)

Hrm...what if the answer is precise specifications, in the form of
unit tests? What if the person offering the bounty is responsible for
providing a clear set of specifications AND unit tests for the
interface, and the System runs the unit tests against the solution to
automatically verify that it's valid.

With the IRC model I have been thinking about, you'd need to
bootstrap the system and get to a point where everyone involved had a
nice history of Trust rankings, based on grades of their solutions,
number of solutions, number of disputes, and so on. (You' d also have
those rankings distributed over a wide variety of information
topics.) But that's a general description of the end result, and
glosses over the details of how to get there (and assumes that such a
system makes 95% of the people using it happy).

Well, as was pointed out recently, the 'Peer Review' feature on
RubyForge is pretty much just sitting there at the moment. Seems a
logical place for eBay-like feedback. Of course, it's probably also
ripe for abuse. Maybe it could be tightened up somehow.

 

[Ara.T.Howard]

--Apple-Mail-1--611786539
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed

I seem to recall there was some discussion here of
people paying small amounts for small pieces of code
(a la rentacoder). [...]
Does this concept seem interesting to anyone? Worth
discussing?

I've been wanting to do something like this on an IRC front for a
long time, but the issues of Trust have made it hard to figure out
the details.

It's an exchange of goods where neither person trusts the other, both
holding on to what they have while grabbing for the other person's
goods. When it's something physical, you don't let go of what you
have until you're sure that you have a firm grasp on what the other
person is offering.

But if it's information, I see two choices:

1) You let the person offering the bounty review the answer and
discover if it's valid. How then do you prevent that someone from
getting their answer and then saying "No no no, that wasn't what I
wanted at all. I'm keeping my money (and the information that's now
in my head)." ?

2) You force the person offering the bounty to pay up before seeing
the solution. What then do you do if the solution is "Ha ha, you
suck, I've got your money now!" ? (That case is easy to resolve by a
third party, but what if the solution is real code ... how much work
do you want to do diving into each solution and determining if it's a
'perfect' match?)

Hrm...what if the answer is precise specifications, in the form of
unit tests? What if the person offering the bounty is responsible for
providing a clear set of specifications AND unit tests for the
interface, and the System runs the unit tests against the solution to
automatically verify that it's valid.


With the IRC model I have been thinking about, you'd need to bootstrap the
system and get to a point where everyone involved had a nice history of
Trust rankings, based on grades of their solutions, number of solutions,
number of disputes, and so on. (You' d also have those rankings distributed
over a wide variety of information topics.) But that's a general description
of the end result, and glosses over the details of how to get there (and
assumes that such a system makes 95% of the people using it happy).

if i were programming the service, IRC or http based, i'd make it invite only
too : you could 'vouch' for me and i'd be allowed in. once in, you can
invited others. one could also be ousted if > 50% of the members voted that
way. this is defintely clickish - but would help clients feel better about
someone without a track record since they could, at least, be highly
reccomened by someone with a good recorde. even if this wasn't mandatory it
might be a nice additional feature.

cheers.

-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| renunciation is not getting rid of the things of this world, but accepting
| that they pass away. --aitken roshi
===============================================================================

 

[Richard Lyman]

While all of these are 'nice' features - what you're really wanting is
only an advanced form of contract work. Why don't we just stick to
that model?

Steps:
1. Someone ("funder") wants to "develop ruby stuff"
2. "funder" starts really small - so small that losing the money won't
matter ("small project").
3. "funder" offers "small project" to a group preselected by resume -
resume defined the same way it always is: either a piece of paper, or
previous extablished work.
4. "small project", and associated terms, is accepted by "contractor".
5. "contractor" finishes "small project".
6. If "funder" is pleased then the two form a "relationship" that
moves on to bigger projects. If "funder" is not pleased, then no
bigger risk is taken either with the "contractor" or (worse yet) with
Ruby.

It's that simple.

(I know, I know - it sounds like I'm giving dating advice... lol...)

So. If someone wants something done - just start small and work your way up.

I imagine that if the "contractor"s "resume" was good enough the
"funder" could skip steps 1-5. Which would be ideal in my opinion...
and so very few have a "resume" that is _that_ good... but there are
some who do - and they _have_ skipped steps 1-5.

-Rich