Folks,
> (And how do we decide what's the best interest of the project as a
> whole, anyway? Well, community consensus is the only way that I can
> see. Again, the critical factor is that no one voice drown out the
> rest.)
Well, a lot of it has been about the core committee and trust. The rest of
us trust the core committee to promote what they think is best for
PostgreSQL, and not what their employers think, unless the two are compatible
(for example, I don't think anyone objects to SRA's pushing Windows ... ).
Plus most of the core committee is very active on the mailing lists and
actively fields user requests and answers user opinions.
So if one of us gets mad that a feature or patch was turned down, nobody is
left with the opinion that it's becuase the core committee wasn't paying
attention or is speaking for their employers. Nor would any every expect
that we would see a feature that had been rejected for the TODO list suddenly
appear in the source tree. If private companies using their own money want
to change the *priorities* on the TODO list, that's fine -- and no different
from volunteer programmers with an itch to scratch, except maybe in scale.
Besides, I think most of us active participants have some business related to
Postgres. I'm a consultant, for example, and I freely admit that I pushed
for not waiting for Win32 and PITR for 7.4 because some of my clients want to
use 7.4 now and not later, with or without those features.
Sometimes the process breaks down a bit ... I can think of a few features
which were discussed and accepted on the Hackers list and then rejected when
they reached Patches ... but the vast majority of the time it works better
than the projects I know with a larger community and a more formal governance
structure.
If it ain't broke, don't fix it.
--
Josh Berkus
Aglio Database Solutions
San Francisco
