Dan Gowin <DGowin@avantec.net> writes:
> What does all of this mean. Well, Oracle (Commercial)
> database packages have some of these same problems that plague
> PostgreSQL. The only difference is they are less frequent and
> are generally tied to the development cycle. I tend to think
> of this as a evolution cycle and Postgres's cycle is on
> steroids.
That it is.
I think most people see rapid release cycles as part of the success
story for open-source software, so I'm not eager to try to slow down
the cycle. But we do need to consider that many users of Postgres
will be more concerned about stability and reliability than having
the latest whizzy features. Making a commitment to maintain the
prior major release as well as the current one seems like a good
answer.
I see a number of different specific issues that are getting lumped
together under the notion of "commercial support":
1. Personal attention to a particular installation, guaranteed
response to a problem, etc. These are things that can and should
be handled by a distributed network of support consultants as Terry
was suggesting.
2. Bug fixing and feature additions in the supported product. (This
is different from "support" in the sense of correcting an admin's
mistake, figuring out a workaround, or otherwise supporting a specific
installation. I'm thinking about changes that require developer-grade
understanding of the code.) I don't really think we need to do
anything differently here, other than have a higher level of effort on
back-patching prior releases. Like most open-source projects we are
far *better* than commercial practice in this area.
3. Commercial guarantees/warrantees/indemnifications, ie, someone pays
you money if the thing doesn't work for you. I don't think this is
going to happen, at least not for the core Postgres development. Who
in their right mind would warrantee something they didn't have 100%
control over? If there's really a demand for it then probably
companies will offer packages based on back-rev Postgres releases that
they have tested like mad and hired a few programmers specifically to
fix bugs in. (They'd probably want to put it on a back-rev OS,
too...)
We should try to encourage qualified people to become support
consultants to deal with point #1. I don't think this group can
or should do anything about #3 though --- that looks like a splinter
project to me. I don't mind someone else taking it up, but it would
be a distraction from the core development project for us.
regards, tom lane