Re: Re: [HACKERS] My new job - Mailing list pgsql-general

From Tom Lane
Subject Re: Re: [HACKERS] My new job
Date
Msg-id 25510.971335915@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: [HACKERS] My new job  ("Matthew N. Dodd" <winter@jurai.net>)
List pgsql-general
"Matthew N. Dodd" <winter@jurai.net> writes:
> The one place where GB can get burned is if they spend lots of time/money
> implementing a feature and then attempt to recoup their investment by
> holding said feature back from the PGSQL source tree.

I can say with a good deal of confidence that this is not part of GB's
vision of how to play the game.  (Can't speak for pgsql.com or any other
potential commercial players, however.)  GB is building their company on
the assumption that open source is the best way to develop software, so
it makes no sense to do any proprietary-style development.

I am more concerned about conflicts like "well, today I could work on
feature-or-bug-fix A that some paying customer of GB's is requesting,
or I could work on feature-or-bug-fix B that IMHO would be of wider
interest --- but isn't currently being requested by a paying customer".
Or worse, "paying customer FOO wants some feature that I think would
be actively bad for most people".  To the extent that paying customers
are representative of the whole community, this shouldn't be a huge
problem, but I'm sure that it will come up.

> The real question is this:  At some point in the future the PostgreSQL
> project may have to delay integrating a feature in order to play nicely
> with the commercial ventures working with them.  Will this cause problems?

Hm, I'm having a hard time visualizing why this might happen.  Could you
provide an example?

            regards, tom lane

pgsql-general by date:

Previous
From: "Matthew N. Dodd"
Date:
Subject: Re: Re: [HACKERS] My new job
Next
From: Peter Mount
Date:
Subject: RE: R: PostgreSQL book