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: