>>> On Tue, Dec 19, 2006 at 6:13 PM, in message
<200612200013(dot)kBK0Dui20431(at)momjian(dot)us>, Bruce Momjian
<bruce(at)momjian(dot)us> wrote:
> if the company dies, the community keeps going (as it did after
Great
> Bridge, without a hickup), but if the community dies, the company
dies
> too.
This statement seems to ignore organizations for which PostgreSQL is an
implementation detail in their current environment. While we appreciate
PostgreSQL and are likely to try to make an occasional contribution,
where it seems to be mutually beneficial, the Wisconsin State Courts
would survive the collapse of the PostgreSQL community.
While I can only guess at the reasons you may have put the slant you
did on the document, I think it really should reflect the patient
assistance the community provides to those who read the developers FAQ
and make a good faith effort to comply with what is outlined there. The
cooperative, professional, and helpful demeanor of the members of this
community is something which should balanced against the community's
need to act as a gatekeeper on submissions.
I have recent experience as a first time employee contributor. When we
hit a bump in our initial use of PostgreSQL because of the non-standard
character string literals, you were gracious in accepting our quick
patch as being possibly of some value in the implementation of the
related TODO item. You were then helpful in our effort to do a proper
implementation of the TODO item which fixes it. I see that the patch I
submitted was improved by someone before it made the release, which is
great.
This illustrates how the process can work. I informed management of
the problem, and presented the options -- we could do our own little
hack that we then had to maintain and apply as the versions moved along,
or we could try to do fix which the community would accept and have that
feature "just work" for us for all subsequent releases. The latter was
a little more time up front, but resulted in a better quality product
for us, and less work in the long term. It was also presumably of some
benefit to the community, which has indirect benefit to our
organization. Nobody here wants to switch database products again soon,
so if we can solve our problem in a way that helps the product gain
momentum, all the better.
I ran a consulting business for decades, and I know that there is a
great variation in the attitudes among managers. Many are quite
reasonable. I'm reminded of a meeting early in my career with a
businessman who owned and operated half a dozen successful businesses in
a variety of areas. He proposed a deal that I was on the verge of
accepting, albeit somewhat reluctantly. He stopped me and told me that
he hoped to continue to do business with me, so any deal we made had to
benefit and work for both of us or it was no good at all; if I was
uncomfortable with something in the proposal, we should talk it out.
That's the core of what we're trying to say in this document, isn't it?
The rest is an executive overview of the developer FAQ? I can't help
feeling that even with the revisions so far it could have a more
positive "spin".
-Kevin