I spent a few years writing down my thoughts about how one should approach problems. If you're looking for a how-to guide, a cookbook, or a reference this book is not for you. If you want to learn by challenging the way you think, pick up a copy.
I just attended the Keynote by Joshua Drake from Command Prompt. There are a lot of good movements on the operational organization of the PostgreSQL community. I think his vision of the community is more aggressive and structured than many are prepared for, but in a community as large as the PostgreSQL community it is very good to have someone pushing the envelope and attempting to apply a vision. I don't want to go as far as Josh wants to do, but we'll wind up part of the way there and that "just perfect."
He used a lot of geek marketing terms going so far as to use the term "Db 2.0." I'll add a few comments and marketing terms to my commentary. Josh said we need to stop following and start leading; stop looking at features in Oracle as a future feature map. What Josh means here is that we need to be disruptive. We need to implement things no one else has. I think we need both.
Josh said he wanted everyone using PostgreSQL and not "the Dolphin." I have to say that I think his statement was too strong to match my opinion. I like PostgreSQL. I believe it is the right tool for the job more often than not. However, there is a "not." In fact, there are a lot of "not"s. There are many requirements that, when explored, map better to the offerings of an Oracle, a DB2, or, dare I say, even a MySQL. MySQL is the "right tool for the job" for many requirements. There is room for more than one database. In fact, there is room for all databases. Good business and engineering practices should always define the process of evaluating technology appropriateness. One good business practice is placing only technology that can be well supported by your existing (or easily accessible) engineering talent. This practice should never be confused with evangelism and zeal -- we all have these character traits, but good engineers and managers shouldn't use them as a part of defining the appropriateness of a solution.
Josh's primary goal seems to be to grow the community which will better legitimizes PostgreSQL. The one thing I took away from this is that I should make sure PostgreSQL is a more common topic of discussion. I think we should start a Baltimore/Washington PostgreSQL User Group; OmniTI will provide facilities, coordination and even food and drink as long as it is under thirty people.
I'm sitting at PostgreSQL Conference. I have a snazzy slide set. I have forgotten my Mac 15" VGA adapter. @#$^ *@#$*%! I'm sure I'll be able to borrow an adapter from someone, but I must note that this conference has a much smaller Mac to PC laptop ratio than any other other conference I've been to in the last two years. (a.k.a. a large group in denial).