Re: Companies Contributing to Open Source - Mailing list pgsql-hackers

<quote>
"Companies often bring fresh prespective, ideas, and testing
infrastucture to a project."
</quote>
"prespective" || "perspective" ?

g.-


On 12/21/06, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote:
> >>> On Tue, Dec 19, 2006 at  6:13 PM, in message
> <200612200013.kBK0Dui20431@momjian.us>, Bruce Momjian
> <bruce@momjian.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.barosio@globant.com