Re: [HACKERS] Decision Process WAS: Increased company involvement

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
> Sent: Monday, May 02, 2005 1:50 PM
> To: josh(at)agliodbs(dot)com
> Cc: Bruce Momjian; Marc G. Fournier; PostgreSQL advocacy; Dave Held;
> PostgreSQL-development
> Subject: Re: [pgsql-advocacy] [HACKERS] Decision Process WAS:
> Increased
> company involvement
>
>
> [...]
> Our process is not "democratic" in the sense of any random
> subscriber to the mailing lists having the same vote as a
> core member --- and I'll bet Boost doesn't run things that
> way either.

Actually, it does, but it can afford to for very special reasons.
Because Boost is not about a single problem domain, there is no
real "core" of developers. There are some who have contributed
more libraries, or larger libraries; but at the end of the day,
each review and submission is judged on its own merits. Often,
the person submitting a new library for review is a domain expert
for that library; and people reviewing a library are also often
domain experts, even if they are a first-time reviewer. So the
very nature of Boost allows it to be more democratic. Because
Postgres is about a single problem domain, and because each
submission must work in concert with an extant whole, it has
totally different needs and a totally different type of community.
And because a database isn't exactly a modular beast like, say,
a web server, that limits the openness of the community further.
That is to say, there is a barrier to entry, but it isn't
capriciously imposed by the community members. It's just a
necessary outcome of the nature of the project. People who
want to contribute should understand this barrier and how it
works before they start writing code.

> What we have is pretty informal but I think it effectively
> gives more weight to the opinions of those more involved in
> the project; which seems a good way to operate.

For Postgres, I agree.

> But there isn't anyone here who has an absolute veto, nor
> contrarily anyone who can force things in unilaterally over
> strong objections.

Nor would one expect such a thing in a project that claims to
be OSS. But ultimately persuasion is as much a part of
consensus as merit, and people should recognize that fact
when contributing to the project.

__
David B. Held
Software Engineer/Array Services Group
200 14th Ave. East, Sartell, MN 56377
320.534.3637 320.253.7800 800.752.8129