Kevin Grittner wrote: > >>> On Tue, Dec 19, 2006 at 6:13 PM, in message > <[EMAIL PROTECTED]>, Bruce Momjian > <[EMAIL PROTECTED]> 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.
Yes, the statement relates mostly to companies that sell/support/enhance open source software, rather than users who are using the software in their businesses. And that text isn't in the article, it was just in an email to make a distinction. I think I have improved the slant of the article. Let me know if it needs further improvement. Thanks. --------------------------------------------------------------------------- > > 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 > -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
