Re: Usability, MySQL, Postgresql.org, gborg, contrib, etc.

Just a reflection from someone who has not been following PostgreSQL that
long...

I think you provide excellent leadership and keep a firm grip on the core
PostgreSQL server. Moving stuff out to Gborg and the discussion regarding
contrib tells me that you want to keep it that way. As I'm a firm beliver in
separation of concern and modularization, I really like that move. The
server group must concentrate on the server.

PosgreSQL is much more than just a server though. Something can be done that
would bring order to the current chaos and make the fragementation a
positive thing. What I think is needed is an architecture that goes beyond
the server. An architecture endorsed by the PostgreSQL. It would of course
include the semantics needed to create and link a plugin but it wouldn't
stop there. A very important feature would be packaging and deployment
(installers etc.). Another would be administration.

The architecture I have in mind *must* be endorsed and controlled by
PostgreSQL. It cannot be delivered by a freestanding group. Still, it's not
core server stuff. This is the means by which PostgreSQL would (re)gain
leadership of the whole thing. You don't need managers, you need a broader
component architecure.

My perception is that you need to somehow fork your efforts and look beyond
the core server horizon. A don't think it's too late. I'm convinced that
everyone that creates products that integrates with PostgreSQL would be more
than happy to comply (and make additions to) a common architecture if it
would help PostgreSQL to get a wider acceptance.

In short,
You have a great leverage. It's just a matter of using it the right way.

Kind regards,

Thomas Hallgren

"Peter Eisentraut" <peter_e(at)gmx(dot)net> wrote in message
news:200404262146(dot)54078(dot)peter_e(at)gmx(dot)net(dot)(dot)(dot)
> pgsql(at)mohawksoft(dot)com wrote:
> > If we want to make PostgreSQL a wildly popular product, there will be
> > some pain. There should be a "Product Management" group. The
> > leader(s) of this group should be chosen carefully, as he (they) must
> > be free to define what PostgreSQL is. They must have a good feel for
> > product development and understanding of the underlying technology,
> > but not be so techie that we don't address the issues intended. They
> > must be able to rally the troops and direct development efforts.
> > Lastly, he (they) must have the confidence of the core hackers, as it
> > is likely that there will be disagreements with the direction of
> > PostgreSQL, and it wouldn't work if "Product Management" couldn't
> > actually manage what the product was because nobody listened.
>
> I agree with this, more or less. The lack of leadership that
> coordinates all activities actively is really missing. Unfortunately,
> I believe we are already in a state of fragmentation where setting up
> something like this is no longer possible. What the end user sees as a
> PostgreSQL system is brought to them by nearly a dozen different groups
> nowadays. And the server group can no longer count on having a
> stronger position to pull them all together. The only option to
> achieve what you want soon is to market your own product.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>