Re: [pgsql-advocacy] Thought provoking piece on NetBSD - Mailing list pgsql-general

From Chris Travers
Subject Re: [pgsql-advocacy] Thought provoking piece on NetBSD
Date
Msg-id 44F9CD39.4060200@metatrontech.com
Whole thread Raw
In response to Re: [pgsql-advocacy] Thought provoking piece on NetBSD  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Tom Lane wrote:
> Josh Berkus <josh@agliodbs.com> writes:
>
>> In general, I think that people who harp on PostgreSQL's lack of a
>> benevolent dictator as an inhibitor to progress are people who are not
>> comfortable with democracy and are looking for excuses why company X needs
>> to "take over the project for its own good."
>>
>
> I don't recall having seen that idea being pushed for Postgres ... not
> seriously anyway.  However, it's certainly true that historically we've
> had effectively *no* project leadership, in the sense of anyone setting
> feature goals for releases or creating a long-term roadmap.  Would we
> be better off if we had done that?  I'm not sure.
>
I actually found the whole writeup thought provoking in one very
important way:
1)  Most of the issues cited in the article appear on the surface to
exist in our community but
2)  We are seemingly amazingly productive as a community.

I just want to share my thoughts on a few of these issues.

Strong leadership exists in the PostgreSQL community in terms of an
actual meritocracy.  There are people here who work hard, deliver
quality results, and are recognized as community leaders in various
roles.  Pretty much everyone on the core team fits that description.
However, this leadership is largely hands-off, more of a mentor in a
meritocracy than a project manager.  This works well in our community
because we have a lot of people who are take a huge professional
interest in pushing the project forward, and the core team does a good
job of encouraging people to take an active part.

As for locking, there are good and bad aspects.  Certainly, there are
times when locking is a Bad Thing(TM).  On the other hand, if a
developer knows that a competent developer is working on a problem, they
may be inclined to look for other areas where they can more efficiently
put in their time.  The general rule IMO is-- if you really need it, do
the work even if it is "locked."  If you can wait for a few versions and
don't really care, then find a place where you can better donate your
time.  We don't need to go to the extent of encouraging duplication of
effort.

In the end, many different leadership models may work, but the goal must
be the building of community and the recruiting of competent
developers.  These are the areas that I think PostgreSQL has done
particularly well and some other projects have failed at.

Best Wishes,
Chris Travers
Metatron Technology Consulting
> It's pointless to suppose that individual developers would really be
> answerable to any project-wide management, since that's not who they're
> paid by.  So I tend to think that a project roadmap would be more of an
> exercise in wishful thinking than a useful management tool.  OTOH it
> *could* be useful, if there are any developers out there wondering what
> they should work on next.  Are there any ... and would they listen to a
> roadmap if they had one, rather than scratching their own itches?
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>
>
>


Attachment

pgsql-general by date:

Previous
From: Steve Atkins
Date:
Subject: Re: database replication
Next
From: "Peter Bauer"
Date:
Subject: Severe problems with PostgreSQL 7.4.7 installation, please help!