Re: Time to scale up?

Thomas,

> A direct consequence of todays organization is that very useful
> functionality is scattered in several places with a significant level of
> uncertainty as to what is released and stable and what is just a
> prototype. PostgreSQL takes a beating in database comparisons and the
> community must time after another correct journalists that tend to
> "forget" the plethora of add-on modules that exists. Another consequence
> is that when using PostgreSQL, you are encouraged to use stored
> procedure languages that can be implemented with a few lines of code and
> in pure C. A user would probably rather see criterion's like feature
> richness and standards conformant. These problems persist although a
> number of actors bundle PostgreSQL with various modules today.

What you're talking about is creating a "distribution" of PostgreSQL in
the same way that there are distributions of Linux. Traditionally,
we've left this to commercial distributors, and OS packagers of
PostgreSQL to do this. Other people have explained this strategy on
this thread.

> A resolution to the problem would be to allow the core team to scale up.
> More people are needed to support a more comprehensive set of features.
> So why not create specialized teams that are part of the
> core-development trust? Teams that specialize in replication, in Java,
> and in other areas where the core team feel that their knowledge and/or
> resources are too limited.

I don't see that this is the role of the Core team -- Core takes care of
releasing the PostgreSQL "kernel" and one of the ways we've kept
PostgreSQL "good" is by minimizing the amount of central, inalienable
code. I don't think it's a coincidence that we have both less lines of
code than MySQL and significantly less bugs.

I *can* see the value in someone putting together an official "community
package" of PostgreSQL plus add-ons. We've talked about this before as
the "kitchen sink" PostgreSQL (KSPG). However, I think you need to be
realistic about the amount of work this would involve:

1) Assembling a trusted, qualified "jury" of PostgreSQL community
members to vote on the list of add-ons to be included.

2) Crafting a fair and public review process for "mature" PostgreSQL
add-ins.

3) Developing a build system which can handle add-ins with external
dependencies.

4) Working out the multiple different licenses which add-ins are under
and informing the users of which parts of the KSPG are differently
licensed, as well as deciding which licenses may prohibit add-ins from
being included.

All of the above is worthwhile, but we're talking a *lot* of work. Note
that (3) would be worthwhile on its own, and if the build system were
interactive/online, a lot of the necessity for a KSPG would be erased
since people could easily roll their own.

--Josh