Re: [HACKERS] Raising funds for PostgreSQL
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Raising funds for PostgreSQL |
Дата | |
Msg-id | 25958.944641432@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Raising funds for PostgreSQL (Kyle Bateman <kyle@actarg.com>) |
Список | pgsql-hackers |
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. I don't think that's very practical; the "bids" will be changing constantly. For one thing, many user-level features will change in difficulty depending on what other things have been completed. For another, a developer might unexpectedly find himself with spare time on his hands ... or a sudden need for cash ;-) ... which might induce him to pick up some feature request that he hadn't been excited about doing before. In the terms you're using that'd correspond to an unpredictable drop in the bid price. 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. 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. Maybe there's a better answer. No good ideas at the moment... regards, tom lane
В списке pgsql-hackers по дате отправления: