Re: [HACKERS] Raising funds for PostgreSQL - Mailing list pgsql-hackers

The Hermit Hacker wrote:

> I like most of the wording, but the idea behind a pledge is to provide a
> pool of money, dedicated towards a particular feature, that we have
> reserved, on hand, to be able to contract out.  If a "feature" gets $100
> in pledges and someone pops up, says I'll do it, pledging for that feature
> will freeze at that point, and the programmer will get paid after his code
> has been submitted, approved and entered into the repository...
>
> A pledge is record/valid when, and only when, the pledge has been
> received...
>

What can we do to assure a donor that his feature will actually get completed as a result
of his donation?  It seems to me this will be most people's hesitation (mine, at least)
is sending money in without any kind of mechanism to control how it is spent.

>
>
> > 1. Exclude items from the list which will be completed in the next 2-3 months anyway
>
> why?  if someone feels that WAL is important, and wants to pledge towards
> getting that completed, so be it...most of the TODO list is currently
> under someone's responsibility (WAL == Vadim)...if ppl want to pledge
> $100+ for Vadim to work on this, so be it...when its released, we send
> Vadim a cheque for $100+ - 10% ... I don't think he'd refuse, now, do
> you? :)
>

I guess my thought here was if an item was already being worked on, it would be difficult
(impossible) to determine a target value (the amount of money needed before work would
begin).  The target value is inherently 0 once the work has already begun.  I think the
goal is to give donors positive feedback i.e. "I pledged, I paid, the feature got done.
Without me, it probably wouldn't have happened (so soon)."  Once they have that cycle
happen, they'll be back to do it again because it will feel good.


>
> > 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.
> > 3. Do not disclose these bids to the public
> > 4. Do not disclose the received pledges to date to the public
>
> I don't like this ...

Understood.  I think this part can be done in a number of ways.  But let me explain what
this does.

By setting a bid from the development team, that tells the donor that you are serious
about using his money for its intended purpose.  The team is committed to that feature,
they're just waiting for the pool to build up to the target value.  A donor will want to
know that his cash is not just going to be sucked into whatever cash flow needs are
urgent that week--he'll know exactly what he needs to do to make the enhancement a
reality.  And the rules won't change on him after he sends his check in.

>
>
> > 5. Show on the page how much has been pledged toward the feature only
> >    as a percentage of the amount needed to start the work
>
> The pledges are, IMHO, an incentive for a developer to develop that
> feature...if 10 ppl pledge $100 for WAL (sorry, so much talk about it
> recently its what first comes to mind), and the 11th person feels its
> worth another $100 to get done, why put a cap?  Or, if feature X is
> something that none of the developers really care about, but 15 admins do,
> the higher the pledges go, the more incentive there is for it to get
> done...I think its up to those doing the pledges to determine what they
> thing a feature is worth in the scheme of things...if the pledges to get
> $1000 for a feature, and none of the developers feels up to doing it,
> should we cap it?

I don't consider it a cap.  If you get more money than the feature needs, it would be
great to have the right to throw the excess off into a second feature.  That would
accelerate the development even more.

>
>
> > 6. Include a buffer (20%?) to allow for uncollectable pledges
>
> As mentioned above...a pledge isn't listed if not-collected...
>
> > 7. When the pledge is made, bring up a page with an electronic
> > contract with Accept and Decline buttons.  This contract should
> > contain language which is legally binding and which would hold up in a
> > small claims court.  That way if someone makes a pledge and you
> > complete the feature, you could actually collect your money from them
> > if you wanted to.  I can probably help with the language of this if
> > you want.
>
> More headaches then its worth, really...see above...

I think the key here is no matter what we do, if no one sends in the $, its not going to
work.  It has to be something enticing enough that people will actually pay.

>
>
> > 8. After a feature has been funded and completed, publish all the
> > details (bids, pledge amounts, who donated, who flaked on their
> > pledges, etc.)
>
> Not in my life time...what are we trying for, guilt trips? :(
>
> > 9. Include prominent information about how to participate in this
> > program on all the web page headers/footers and in the distribution
> > README's.  A catchy link might be "How to get your favorite feature
> > added into PostgreSQL"  You should probably throw something into these
> > mailing lists from time to time too.
>
> Agreed...
>
> > 10. Are you set up to take credit cards?  This would be nice but I
> > think you can do without it.
>
> Definitely...
>
> > 11. You probably should probably choose US Dollars as the standard
> > interchange format. However, this should appeal to an international
> > market.  If you get set up with a web credit card vendor, they can
> > probably handle exchange issues for you automatically.
>
> We do all our values in Canadian, actually...with a link to one of the
> online Exchanges for translating values...if I can somehow figure out how
> to tie into one of those, where I pass it something like:
>