Tom Lane wrote:
> Kyle Bateman <kyle@actarg.com> writes:
> > [ lots of good thoughts snipped ]
>
> > 2. Take bids from the development team in advance on each feature. In
> > other words, how many dollars would they need to start on the
> > enhancement today.
> Before I comment too much on this topic I should probably mention that
> I have myself engaged in exactly this kind of transaction: a few months
> ago, someone who need not be named here sent me a couple hundred bucks
> in return for my dealing with a Postgres problem that they needed fixed
> pronto (ie, within a week or two). It was something I would have fixed
> anyway, eventually, but it was worth their cash to encourage me to deal
> with that issue sooner rather than later. So I've certainly got no
> moral objection to arrangements like this.
>
Tom, the more I hear, the more I'm beginning to think that maybe the best
mechanism is for the client to deal directly with one or two developers in
the way you did. Everything else we talk about begins to get rather
complicated in a hurry.
It would be relatively easy to open up a new discussion group for posting
offers (in either direction). Once a developer and a client got connected,
they could negotiate privately for the feature.
>
> But I do have a practical concern, which is that bidding like this might
> distort the development process, for example by tempting someone to put
> in a quick-and-dirty hack that would provide the requested feature and
> yet cause trouble down the line for future improvements. In the long
> run that's not good for the health of the project.
>
> I'm not sure how to answer that concern. One possible answer is to
> put a cap on the amounts bid --- a person's judgment is less likely
> to be swayed in the wrong direction by $$ than $$$$$$, no? But the
> cap would probably have to vary depending on the difficulty of the
> proposed feature. I don't think we want to get into spending a lot
> of effort on cost-estimating everything that's on the TODO list,
> so administering a bid cap might well be impractical.
>
I think the best answer to this is already in place. It seems to me the
developer pool as a whole watches additions very carefully. Someone who
puts in an ugly hack has to think about what the rest of the team will
think of it. If the problem were repeated, that developer would begin to
lose clout and eventually would not be allowed the same kind of access to
the source tree. I think you guys are pretty motivated to do your best
work on this project. If that were not so, we would not see the quality of
work we do.
None of the arrangements can be forced (because this is a volunteer
project) so things like caps will probably not work anyway. I think I'd
encourage the group to begin to experiment with the kind of transactions
you described and see if we run into any problems with it. If it begins to
cause problems, adjustments can always be made to compensate.