Skip site navigation (1) Skip section navigation (2)

Re: Companies Contributing to Open Source

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Guido Barosio <gbarosio(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Companies Contributing to Open Source
Date: 2006-12-22 17:56:30
Message-ID: 200612221756.kBMHuUG28938@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Guido Barosio wrote:
> <quote>
> "Companies often bring fresh prespective, ideas, and testing
> infrastucture to a project."
> </quote>
> 
>  "prespective" || "perspective" ?

Thanks, fixed.

---------------------------------------------------------------------------


> 
> g.-
> 
> 
> On 12/21/06, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> > >>> 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
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: don't forget to increase your free space map settings
> >
> 
> 
> -- 
> Guido Barosio
> -----------------------
> http://www.globant.com
> guido(dot)barosio(at)globant(dot)com
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

-- 
  Bruce Momjian   bruce(at)momjian(dot)us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-12-22 18:06:57
Subject: Re: Operator class group proposal
Previous:From: Jeremy DrakeDate: 2006-12-22 17:46:35
Subject: recent --with-libxml support

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group