Thread: Re: [HACKERS] Raising funds for PostgreSQL

The Hermit Hacker wrote:

> Hi Kyle...
>
>         Jeff is currently in the process of redoing the web site, and
> we're going to be working this 'bidding' system into the new site, but its
> going to take a litlte bit of time, since he would like to get it right
> and not have to do it again :)
>
>         Keep an eye on the sight and expect *a variant* on what you
> proposed to be in place around the first of the new year...but it will be
> implemented...
>

Sounds good.  I hope my input will prove helpful.

BTW, you don't have to wait for the web site to be working right to get me involved
(although I think that might help others to get more involved).

If you're interested in getting some money to help out with development now, this is
the list of things I have been hoping for.  I'm sure my modest contribution alone is
not enough to justify the work they will take, but its probably better than a kick in
the butt.

  - Allow a view of a union
  - Get rid of size restrictions on tuples (8K?)
  - Get rid of size restrictions on queries (16K)
  - Make sequences roll back on abort (at least optionally)
  - Resident functions that can execute with super-privileges
    This would mean that a PL function could execute as the user who created
    it (or perhaps some other user the database creater might specify).  This
    would allow certain information to come from a table that the calling user
    might not normally have access to (without having access to the whole table).
  - Support for outer (and other kinds of) joins
  - Column based permissions (I don't know if there are SQL standards for this)
  - Support for passwords in the TCL interface (is it there now?)
  - Could a subquery be included in the target list of a query
    select a,(select b from c) from d where e = f;
    (Not sure if this one is even standard SQL.)
  - Support for "alter table drop column"

Maybe some of the things have been done already.  Some have not.  The items are
roughly prioritized for our needs here at ATI.

If I knew that certain of these could be accomplished and for how much, that would
really help me move forward.

At 02:57 PM 12/6/99 -0700, Kyle Bateman wrote:

*>  - Allow a view of a union
*>  - Get rid of size restrictions on tuples (8K?)
*>  - Get rid of size restrictions on queries (16K)>  - Resident functions that can execute with super-privileges>
Thiswould mean that a PL function could execute as the user who created>    it (or perhaps some other user the database
creatermight specify).
 
This>    would allow certain information to come from a table that the calling
user>    might not normally have access to (without having access to the whole
table).
*>  - Support for outer (and other kinds of) joins>  - Column based permissions (I don't know if there are SQL
standardsfor
 
this)>  - Support for passwords in the TCL interface (is it there now?)
*> - Could a subquery be included in the target list of a query>    select a,(select b from c) from d where e = f;
>     (Not sure if this one is even standard SQL.)
*>  - Support for "alter table drop column"

While I don't have any money to offer, I just thought I'd point out
that each of the starred items are things that I've run into while
porting an application from Oracle in just the past three days.

The system builds and allows the editing of tables via a web
interface, and not being able to drop columns is a drag.  I'm
emulating it by renaming such columns to something invisible
(the user doesn't see the actual table, just what the application
thinks is in the table, so I just make it lie to the user after
the renaming), which for this particular application will be
acceptable for now.

Outer joins can be worked around, but at times it's painful,
though I'm finding that for this application at least at times
I can rewrite the query and make it more readable and efficient
without the outer join.  Apparently, outer joins are a temptation
for misuse.  But there are times when they're really helpful.

Allowing a view of a union can always be worked around in some
sort of brute-force manner but can require studying the
queries on it closely in order to properly rewrite them without
the view.

Tuple size restrictions coupled with the fact that LOBs aren't
dumped are also painful.  If 7.0 contains a "real" backup, will
it be able to backup LOBs?  That would help me in the port of
this application.

As the word gets out that Postgres has greatly improved in the
recent past, more and more folks will be looking to move stuff
over from commercial databases.  This is partly driven by the
web (entirely, in my case) where databases are extremely 
useful creatures, serving as the site's foundation in many
cases.  Oracle's pricing for web use is scandalous ($22K-ish
for a fully-paid up unsupported license on a PIII 500!) and
besides is overkill for all but the largest and busiest sites.
Postgres can fill a very important niche in this environment.
One that some folks think MySQL fills but, hey, I ain't trusting
any money transactions to a non-transactional database!

The focus on things like reliability and performance is 
extremely important, of course - MVCC in 6.5.*, a very
noticable decline in memory leaks ("drastic" is not too
strong a word), removing the uneccessary write to pg_log
after read-only selects were crucial for my own web-based
application.  WAL and a good backup facility are really
nice to think about for those of us who worry about our
hardware's reliability, and referential integrity constraints
for those of us who worry about our ability to write
bug-free code (I can't wait to play with Jan's new updates),
all very good things.

But Postgres is maturing to the point where users can point
to the reliability and performance aspects of the tool and
find little to complain about.  Now folks are going to start
concentrating on SQL language features more exclusively :)



- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.
 

Kyle Bateman <kyle@actarg.com> writes:
> [ wish list ]
>   - Get rid of size restrictions on queries (16K)
>   - Could a subquery be included in the target list of a query
>     select a,(select b from c) from d where e = f;
>     (Not sure if this one is even standard SQL.)

FWIW, the above two things are already done in current sources.
        regards, tom lane

Tom Lane wrote:

> Kyle Bateman <kyle@actarg.com> writes:
> > [ wish list ]
> >   - Get rid of size restrictions on queries (16K)
> >   - Could a subquery be included in the target list of a query
> >     select a,(select b from c) from d where e = f;
> >     (Not sure if this one is even standard SQL.)
>
> FWIW, the above two things are already done in current sources.

Uh,

    who did the latter one?

    Just  running  some  qry  through  psql  I  see that it works
    partially.  Especially I see a

        ExecSetParamPlan: more than one tuple returned by expression subselect

    So I assume it's not implemented in the form I outlined - the
    subselecting  range  table  entry. I'll take a look at it the
    next  days  and  maybe  complain  about  that  change  if  it
    interferes  with  the  needs  of  the  rule  system  to  make
    aggregate, distinct, group by, sort  by  and  all  the  other
    (long wanted) view stuff possible.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #

Here...
http://www.pgsql.com/features/

Have to get it format'd and need to build up the CGI, but this is what you
asking for? :)

On Mon, 6 Dec 1999, Kyle Bateman wrote:

> The Hermit Hacker wrote:
> 
> > Hi Kyle...
> >
> >         Jeff is currently in the process of redoing the web site, and
> > we're going to be working this 'bidding' system into the new site, but its
> > going to take a litlte bit of time, since he would like to get it right
> > and not have to do it again :)
> >
> >         Keep an eye on the sight and expect *a variant* on what you
> > proposed to be in place around the first of the new year...but it will be
> > implemented...
> >
> 
> Sounds good.  I hope my input will prove helpful.
> 
> BTW, you don't have to wait for the web site to be working right to get me involved
> (although I think that might help others to get more involved).
> 
> If you're interested in getting some money to help out with development now, this is
> the list of things I have been hoping for.  I'm sure my modest contribution alone is
> not enough to justify the work they will take, but its probably better than a kick in
> the butt.
> 
>   - Allow a view of a union
>   - Get rid of size restrictions on tuples (8K?)
>   - Get rid of size restrictions on queries (16K)
>   - Make sequences roll back on abort (at least optionally)
>   - Resident functions that can execute with super-privileges
>     This would mean that a PL function could execute as the user who created
>     it (or perhaps some other user the database creater might specify).  This
>     would allow certain information to come from a table that the calling user
>     might not normally have access to (without having access to the whole table).
>   - Support for outer (and other kinds of) joins
>   - Column based permissions (I don't know if there are SQL standards for this)
>   - Support for passwords in the TCL interface (is it there now?)
>   - Could a subquery be included in the target list of a query
>     select a,(select b from c) from d where e = f;
>     (Not sure if this one is even standard SQL.)
>   - Support for "alter table drop column"
> 
> Maybe some of the things have been done already.  Some have not.  The items are
> roughly prioritized for our needs here at ATI.
> 
> If I knew that certain of these could be accomplished and for how much, that would
> really help me move forward.
> 
> 
> 

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 

> Tom Lane wrote:
> 
> > Kyle Bateman <kyle@actarg.com> writes:
> > > [ wish list ]
> > >   - Get rid of size restrictions on queries (16K)
> > >   - Could a subquery be included in the target list of a query
> > >     select a,(select b from c) from d where e = f;
> > >     (Not sure if this one is even standard SQL.)
> >
> > FWIW, the above two things are already done in current sources.
> 
> Uh,
> 
>     who did the latter one?

Tom Lane.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 

wieck@debis.com (Jan Wieck) writes:
> Tom Lane wrote:
>>>> - Could a subquery be included in the target list of a query
>>>>   select a,(select b from c) from d where e = f;
>> [ is done ]

> Uh,
>     who did the latter one?

Me.

>     Just  running  some  qry  through  psql  I  see that it works
>     partially.  Especially I see a
>         ExecSetParamPlan: more than one tuple returned by expression subselect

Yes.  I allowed the existing kinds of subselect expressions in
targetlists (not only in qual clauses), and fixed things so that
a subselect yielding a single result can appear anywhere in an
expression, not only as the righthand-side argument of an operator.
Subselects yielding multiple rows are still valid only as the
righthand argument of an IN, quantified boolean operator
(such as = ANY or = ALL), or EXISTS.  It's a perfectly straightforward
generalization (and simplification!) of what we already had.

>     So I assume it's not implemented in the form I outlined - the
>     subselecting  range  table  entry. I'll take a look at it the
>     next  days  and  maybe  complain  about  that  change  if  it
>     interferes  with  the  needs  of  the  rule  system  to  make
>     aggregate, distinct, group by, sort  by  and  all  the  other
>     (long wanted) view stuff possible.

I don't believe this has anything to do with subselects as range
table entries.  That facility will be quite separate from subselects
in expressions, no?
        regards, tom lane

Tom Lane wrote:

> wieck@debis.com (Jan Wieck) writes:
>
> > Uh,
> >     who did the latter one?
>
> >     So I assume it's not implemented in the form I outlined - the
> >     subselecting  range  table  entry. I'll take a look at it the
> >     next  days  and  maybe  complain  about  that  change  if  it
> >     interferes  with  the  needs  of  the  rule  system  to  make
> >     aggregate, distinct, group by, sort  by  and  all  the  other
> >     (long wanted) view stuff possible.
>
> I don't believe this has anything to do with subselects as range
> table entries.  That facility will be quite separate from subselects
> in expressions, no?

Now that you say it...

    Yes, they are separate. They don't interfere.

    Thank's for the *slap* - sometimes I need that :-).


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #

The Hermit Hacker wrote:

> Here...
>
>         http://www.pgsql.com/features/
>
> Have to get it format'd and need to build up the CGI, but this is what you
> asking for? :)
>

That looks great.  You don't waste alot of time, do you...

For what its worth, here's the language I would suggest for the page:

"This page enables you to help the Postgresql project move along more quickly and at the
same time it will help you get the new features you want and need the most.  Below are a
list of enhancements under consideration by the development team.  However it is not known
when each will bubble up to the top of the priority list and actually get done.

If one of these features is important to you, you can pledge a certain amount of money
($100 minimum, please) toward that feature.  If you want to help build the pool, tell
others about this page and encourage them to pledge toward those features they feel are
needed the most.

When the accumulation of pledges on any feature reaches the level preset by the
development team, you will be contacted at the email address you supply.  You will then
have 2 weeks to actually send in your pledge.  If the pledges actually received are still
high enough to justify the project, your feature will be completed and you will be
notified of the next release which includes it.

If the development team does not successfully complete your feature, or if an insufficient
amount of the pledges are actually collected, you will be given the option of getting your
money back or applying the amount toward another feature.  If you make a pledge and then
do not honor it, you will not be eligible to make future pledges or for support through
PostgreSQL Inc.

Of the funds collected through this mechanism, 10% will be used for administrative
purposes.  The remaining 90% will go directly to the developer(s) working on your
enhancement.

To get an item added to this list, please send email to Jeff MacDonald. If the item is not
already on the TODO list, it will get brought up, discussed, and if entered onto the TODO
list, will also be entered here. You will then be contacted to let you know your entry has
been added, so that you can make your pledge.



Now again, these are just suggestions, but I think the following are good ideas:

1. Exclude items from the list which will be completed in the next 2-3 months anyway
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
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
6. Include a buffer (20%?) to allow for uncollectable pledges
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.
8. After a feature has been funded and completed, publish all the details (bids, pledge
amounts, who donated, who flaked on their pledges, etc.)
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.
10. Are you set up to take credit cards?  This would be nice but I think you can do
without it.
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.

Hope this is helpful.

Kyle

Kyle Bateman wrote:

> Now again, these are just suggestions, but I think the following are good ideas:
>
> 3. Do not disclose these bids to the public

> 4. Do not disclose the received pledges to date to the public

I'm curious about your rationale for 3 and 4.  Why not disclose bid amounts (not bidders) and
received pledge amounts (not pledgers) to the public prior to the work being completed?  What
do you think would happen?

Ed Loehr

Ed Loehr wrote:

> Kyle Bateman wrote:
>
> > Now again, these are just suggestions, but I think the following are good ideas:
> >
> > 3. Do not disclose these bids to the public
>
> > 4. Do not disclose the received pledges to date to the public
>
> I'm curious about your rationale for 3 and 4.  Why not disclose bid amounts (not bidders) and
> received pledge amounts (not pledgers) to the public prior to the work being completed?  What
> do you think would happen?
>
> Ed Loehr

I'm not really that strong on those issues.  I just think if I were setting it up that's
probably the way I would do it to try to maximize the amount of money actually raised and
perhaps keep things a bit more discrete for the developers.

I don't think anything really bad would happen if people know what the numbers are.  You could
in fact figure out about what the numbers were anyway by placing a pledge and watching the
change in the percentage.  That might be a good reason for hiding them right there... :)

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


On Tue, 7 Dec 1999, Kyle Bateman wrote:

> The Hermit Hacker wrote:
> 
> > Here...
> >
> >         http://www.pgsql.com/features/
> >
> > Have to get it format'd and need to build up the CGI, but this is what you
> > asking for? :)
> >
> 
> That looks great.  You don't waste alot of time, do you...
> 
> For what its worth, here's the language I would suggest for the page:
> 
> "This page enables you to help the Postgresql project move along more
> quickly and at the same time it will help you get the new features you
> want and need the most.  Below are a list of enhancements under
> consideration by the development team.  However it is not known when
> each will bubble up to the top of the priority list and actually get
> done.
> 
> If one of these features is important to you, you can pledge a certain
> amount of money ($100 minimum, please) toward that feature.  If you
> want to help build the pool, tell others about this page and encourage
> them to pledge toward those features they feel are needed the most.
> 
> When the accumulation of pledges on any feature reaches the level
> preset by the development team, you will be contacted at the email
> address you supply.  You will then have 2 weeks to actually send in
> your pledge.  If the pledges actually received are still high enough
> to justify the project, your feature will be completed and you will be
> notified of the next release which includes it.
> 
> If the development team does not successfully complete your feature,
> or if an insufficient amount of the pledges are actually collected,
> you will be given the option of getting your money back or applying
> the amount toward another feature.  If you make a pledge and then do
> not honor it, you will not be eligible to make future pledges or for
> support through PostgreSQL Inc.
> 
> Of the funds collected through this mechanism, 10% will be used for
> administrative purposes.  The remaining 90% will go directly to the
> developer(s) working on your enhancement.
> 
> To get an item added to this list, please send email to Jeff
> MacDonald. If the item is not already on the TODO list, it will get
> brought up, discussed, and if entered onto the TODO list, will also be
> entered here. You will then be contacted to let you know your entry
> has been added, so that you can make your pledge.

> 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? :)

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

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

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

> 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:
?from=canadian&to=us&value=###.##

then I wouldn't be adverse to adding that to the web page...anyone?

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 

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

Kyle Bateman wrote:

> The Hermit Hacker wrote:
> > 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.

    Maybe  we  have  to  make pools per feature. Requires IMHO to
    move features, where donations  can  be  thrown  on,  onto  a
    separate  DONOTODO  list.  Items  there  should have a clear,
    detailed  specification,  what  the  feature   finally   will
    implement   and  expected  implementation  time,  assuming  a
    developer can work at least X hours per week on it.

    Each of these DONOTODO items has  it's  own  account,  and  a
    donator  can send in cash for specific items. As soon, as the
    account balance raised high enough, someone will claim to  do
    it  -  sure. At this point, the item is locked and a deadline
    for finishing, depending on the estimated  efford  (from  the
    detailed feature spec) is set.

    Up  to the point, where an item get's locked, the donator can
    transfer any amount between item accounts and (of course) get
    back  his money.  After that point, only additional donations
    can be placed on the item to increase the efford to finish it
    in time.

    At  deadline  overruns,  donators can decide again what to do
    with their money. So the developers have some pressure in the
    neck to complete the items in time.

    In  the  backside,  we must coordinate if multiple developers
    need each other to do one item together. They have to  decide
    a  split  ratio  of  the  account  balance.  Should IMHO be a
    floating process and depending on  the  developers  involved,
    could be open until the end.

    Well,  there  must  be  a  steering commitee, controlling the
    DONOTODO items and the cash flow - PostgreSQL Inc.  would  be
    my first guess.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #

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

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.