Thread: Companies Contributing to Open Source

I have written an article about the complexities of companies
contributing to open source projects:
http://momjian.us/main/writings/pgsql/company_contributions/

If you have any suggestions, please let me know.  I am going to add a
link to this from the developer's FAQ.

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

On Tue, 2006-12-19 at 12:11 -0500, Bruce Momjian wrote:
> I have written an article about the complexities of companies
> contributing to open source projects:
> 
>     http://momjian.us/main/writings/pgsql/company_contributions/
> 
> If you have any suggestions, please let me know.  I am going to add a
> link to this from the developer's FAQ.

This is certainly interesting. Is there a possibility of being able to
read it as a single page? I would like to comment on it but it is hard
to cross reference specific points (at least to me) with the small
sections.

Sincerely,

Joshua D. Drake


> 
-- 
     === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997            http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Joshua D. Drake wrote:
> On Tue, 2006-12-19 at 12:11 -0500, Bruce Momjian wrote:
> > I have written an article about the complexities of companies
> > contributing to open source projects:
> > 
> >     http://momjian.us/main/writings/pgsql/company_contributions/
> > 
> > If you have any suggestions, please let me know.  I am going to add a
> > link to this from the developer's FAQ.
> 
> This is certainly interesting. Is there a possibility of being able to
> read it as a single page? I would like to comment on it but it is hard
> to cross reference specific points (at least to me) with the small
> sections.

Thanks for the feedback, sectioning fixed.

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

On Tue, 2006-12-19 at 13:38 -0500, Bruce Momjian wrote:
> Joshua D. Drake wrote:
> > On Tue, 2006-12-19 at 12:11 -0500, Bruce Momjian wrote:
> > > I have written an article about the complexities of companies
> > > contributing to open source projects:
> > > 
> > >     http://momjian.us/main/writings/pgsql/company_contributions/
> > > 
> > > If you have any suggestions, please let me know.  I am going to add a
> > > link to this from the developer's FAQ.
> > 
> > This is certainly interesting. Is there a possibility of being able to
> > read it as a single page? I would like to comment on it but it is hard
> > to cross reference specific points (at least to me) with the small
> > sections.
> 
> Thanks for the feedback, sectioning fixed.

Much better, thanks. I will comment shortly.

Sincerely,

Joshua D. Drake

> 
-- 
     === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997            http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Fixed, thanks.

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

Gurjeet Singh wrote:
> On 12/20/06, Bruce Momjian <bruce@momjian.us> wrote:
> >
> > Thanks for the feedback, sectioning fixed.
> >
> 
> Spelling mistake:
> 
> because they have gone though a company process
> 
> to
> 
> because they have gone *through* a company process
> 
> Regards,
> 
> -- 
> gurjeet[.singh]@EnterpriseDB.com
> singh.gurjeet@{ gmail | hotmail | yahoo }.com

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

Gurjeet Singh wrote:
> On 12/20/06, Bruce Momjian <bruce@momjian.us> wrote:
> 
> > Fixed, thanks.
> >
> 
> Follwing statement seems to be a bit mangled:
> 
> then when company('s?) needs diverge, going *it*(?) alone, then returning to
> the community process at some later time.

Thanks, clarified.

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

Hi,

I think another point you need to bring out more clearily is that the 
community is also often "miffed" if they feel they have been left out of 
the design and testing phases. This is sometimes just a reflex that is 
not always based on technical reasoning. Its just that as you correctly 
point out are worried of being "high-jacked" by companies.

regards,
Lukas

Hello,

O.k. below are some comments. Your article although well written has a
distinct, from the community perspective ;) and I think there are some
points from the business side that are missed.

---
Employees working in open source communities have two bosses -- the
companies that employ them, and the open source community, which must
review their proposals and patches. Ideally, both groups would want the
same thing, but often companies have different priorities in terms of
deadlines, time investment, and implementation details. And,
unfortunately for companies, open source communities rarely adjust their
requirements to match company needs. They would often rather "do
without" than tie their needs to those of a company.
---

Employees don't have two bosses at least not in the presentation above.
In the community the employee may choose to do it the communities way or
not. That choice is much more defined within a Boss purview. 

A companies priorities have a priority that is very powerful that the
community does not and I believe should be reflected in a document such
as this. To actually feed the employee. There is a tendency for the
community to forget that every minute spent on community work is a
direct neglect to the immediate (note that I say immediate) bottom line.
That means that priorities must be balanced so that profit can be made,
employees can get bonuses and god forbid a steady paycheck.

---
This makes the employee's job difficult. When working with the
community, it can be difficult to meet company demands. If the company
doesn't understand how the community works, the employee can be seen as
defiant, when in fact the employee has no choice but to work in the
community process and within the community timetable.

By serving two masters, employees often exhibit various behaviors that
make their community involvement ineffective. Below I outline the steps
involved in open source development, and highlight the differences
experienced by employees involved in such activities.
---

The first paragraph seems to need some qualification. An employee is
hired to work at the best interests of the company, not the community.
Those two things may overlap, but that is subject to the companies
declaration. If the employee is not doing the task as delegated that is
defiant.

I am suspecting that your clarification would be something to the effect
of:

When a company sets forth to donate resources to the community, it can
make an employee's job difficult. It is important for the company to
understand exactly what it is giving and the process that gift entails.

Or something like that.

I take subject to the term serving two masters, I am certainly not the
master of my team but that may just be me.

---
Employees usually circulate their proposal inside their companies first
before sharing it with the community. Unfortunately, many employees
never take the additional step of sharing the proposal with the
community. This means the employee is not benefitting from community
oversight and suggestions, often leading to a major rewrite when a patch
is submitted to the community.
---

I think the above is not quite accurate. I see few proposals actually
come across to the community either and those that do seem to get bogged
down instead of progress being made.

The most successful topics I have seen are those that usually have some
footing behind them *before* they bring it to the community.

---
For employees, patch review often happens in the company first. Only
when the company is satisfied is the patch submitted to the community.
This is often done because of the perception that poor patches reflect
badly on the company. The problem with this patch pre-screening is that
it prevents parallel review, where the company and community are both
reviewing the patch. Parallel review speeds completion and avoids
unnecessary refactoring.
---

It does effect the perception of the company. Maybe not to the community
but as someone who reads comments on the patches that comes through... I
do not look forward to the day when I have a customer that says, didn't
you submit that patch that was torn apart by...

---
As you can see, community involvement has unique challenges for company
employees. There are often many mismatches between company needs and
community needs, and the company must decide if it is worth honoring the
community needs or going it alone, without community involvement.
---

Hmmm... That seems a bit unfair don't you think? The people within the
company are likely members of the community. It seems that it makes
sense for the community to actually work with the company as well. 

I am not suggesting that the community develop code to the needs of a
company. I am suggesting that perhaps the community needs and the
company needs often overlap but both sides tend to ignore the overlap
and point at each other instead.

---
Company involvement in the community process usually has unforseen
benefits, but also unexpected burdens and restrictions. The bottom line
is that company and community priorities often diverge. If companies
want community feedback, they should plan for such divergence and decide
how hard they are willing to work to maintain community cooperation. If
a company is not willing to adjust to community needs, often it is wise
to avoid the community process.
---

O.k. in all Bruce I like your article but I must admit it seems to take
a "The community is god" perspective and that we must all bend to the
will of said community.

The community could learn a great deal from adopting some of the more
common business practices when it comes to development as well.

In short, I guess I think it is important to recognize that both are
partners in the open source world and that to ignore one over the other
is destined to fail.

Sincerely,

Joshua D. Drake
















-- 
     === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997            http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Joshua D. Drake wrote:

> O.k. in all Bruce I like your article but I must admit it seems to take
> a "The community is god" perspective and that we must all bend to the
> will of said community.
> 
> The community could learn a great deal from adopting some of the more
> common business practices when it comes to development as well.
> 
> In short, I guess I think it is important to recognize that both are
> partners in the open source world and that to ignore one over the other
> is destined to fail.

I think Bruce article is about painting a realistic picture for 
companies who want to get involved. And the reality is that people tend 
to be worried about company influence quite often and they do expect a 
higher standard for patches coming from a (big) company. For individuals 
they are more forgiving, but if an IBM engineer does a little mistake it 
will produce a few (not necessarily open) snickers.

regards,
Lukas

On 12/20/06, Joshua D. Drake <jd@commandprompt.com> wrote:

> O.k. in all Bruce I like your article but I must admit it seems to take
> a "The community is god" perspective and that we must all bend to the
> will of said community.
I'm not really in a position to judge how a company thinks about
"donating  resources" to a project, but I certainly think that Bruce'
standpoint is correct, and that the community is *indeed* the driver of
a project;  if a company doesn't like how the community deals with
their requirements/needs they can just maintain their own branch.


> The community could learn a great deal from adopting some of the more
> common business practices when it comes to development as well.
>
> In short, I guess I think it is important to recognize that both are
> partners in the open source world and that to ignore one over the other
> is destined to fail.
Do you have any statistical data to back that hypothesis?

> Sincerely,
>
> Joshua D. Drake
Cheers,
Andrej

On Wed, 2006-12-20 at 09:51 +1300, Andrej Ricnik-Bay wrote:
> On 12/20/06, Joshua D. Drake <jd@commandprompt.com> wrote:
> 
> > O.k. in all Bruce I like your article but I must admit it seems to take
> > a "The community is god" perspective and that we must all bend to the
> > will of said community.
> I'm not really in a position to judge how a company thinks about
> "donating  resources" to a project, but I certainly think that Bruce'
> standpoint is correct, and that the community is *indeed* the driver of
> a project;  if a company doesn't like how the community deals with
> their requirements/needs they can just maintain their own branch.

It is definitely a tough distinction. My first thought on reply was that
well a companies employees become members of the community but that
reinforces what you say above.

I think my overall thought is the tone seems a bit non-gracious to
companies, when IMO the community should be actively courting companies
to give resources. If companies feel unwelcome, they won't give.

> 
> 
> > The community could learn a great deal from adopting some of the more
> > common business practices when it comes to development as well.
> >
> > In short, I guess I think it is important to recognize that both are
> > partners in the open source world and that to ignore one over the other
> > is destined to fail.
> Do you have any statistical data to back that hypothesis?

Of which, the community learning or my take that if we ignore one over
the other it is destined to fail?

I don't really want to bring up the first point as it has been hashed
over and over. It lends to the project management, todo list, milestone
debacle :)

The second point is that if the community ignores the company trying to
give resources, the company is likely to ignore the community and thus
we both fail (and vice versa).

Sincerely,

Joshua D. Drkae



> 
> > Sincerely,
> >
> > Joshua D. Drake
> Cheers,
> Andrej
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
> 
-- 
     === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997            http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

On 12/20/06, Joshua D. Drake <jd@commandprompt.com> wrote:

> I think my overall thought is the tone seems a bit non-gracious to
> companies, when IMO the community should be actively courting companies
> to give resources. If companies feel unwelcome, they won't give.
I appreciate that, but then Bruce' aim was (or at least that's how I
interpreted it) to point out difficulties that he as a long time member of
the postgres hacker community sees;  it would be a bit weird to expect
him to write something from the perspective of a company (even though
he conceivably could as an employee of enterprisedb).

> Of which, the community learning or my take that if we ignore one over
> the other it is destined to fail?
I meant the failure bit, sorry for the poor quoting.


> I don't really want to bring up the first point as it has been hashed
> over and over. It lends to the project management, todo list, milestone
> debacle :)
Amen

> The second point is that if the community ignores the company trying to
> give resources, the company is likely to ignore the community and thus
> we both fail (and vice versa).
I guess it depends on how you define "fail" for a group that hasn't
set its mind on making profit.


> Sincerely,
>
> Joshua D. Drkae
Cheers,
Andrej

Joshua D. Drake wrote:
>
> I think my overall thought is the tone seems a bit non-gracious to
> companies, when IMO the community should be actively courting companies
> to give resources. If companies feel unwelcome, they won't give.
>
>   

I have not been following closely. But IMNSHO we should be stressing the 
synergy involved in companies contributing to us. They benefit and we 
benefit. Yes there can be conflicts, but these are less likely to occur 
if communication stays open. Doing things behind closed doors is a 
recipe for disaster whether you are a contributing company or 
individual. Example: if I had developed notification payloads without 
getting Tom's redirection, I would have come up with a patch that would 
have been rejected, pissing me off and wasting my company's time. Now I 
feel I can come up with something acceptable.

cheers

andrew

On Wed, 2006-12-20 at 10:27 +1300, Andrej Ricnik-Bay wrote:
> On 12/20/06, Joshua D. Drake <jd@commandprompt.com> wrote:
> 
> > I think my overall thought is the tone seems a bit non-gracious to
> > companies, when IMO the community should be actively courting companies
> > to give resources. If companies feel unwelcome, they won't give.
> I appreciate that, but then Bruce' aim was (or at least that's how I
> interpreted it) to point out difficulties that he as a long time member of
> the postgres hacker community sees;  it would be a bit weird to expect
> him to write something from the perspective of a company (even though
> he conceivably could as an employee of enterprisedb).

Well of course :), that is why I offered some feedback.


> 
> > The second point is that if the community ignores the company trying to
> > give resources, the company is likely to ignore the community and thus
> > we both fail (and vice versa).
> I guess it depends on how you define "fail" for a group that hasn't
> set its mind on making profit.
> 

I am not speaking to profit or loss or money at all. I believe that just
the relationship not being productive between the community and the
company could be considered failing.

Sincerely,

Joshua D. Drake


-- 
     === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997            http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

On Tue, 2006-12-19 at 16:30 -0500, Andrew Dunstan wrote:
> Joshua D. Drake wrote:
> >
> > I think my overall thought is the tone seems a bit non-gracious to
> > companies, when IMO the community should be actively courting companies
> > to give resources. If companies feel unwelcome, they won't give.
> >
> >   
> 
> I have not been following closely. But IMNSHO we should be stressing the 
> synergy involved in companies contributing to us. They benefit and we 
> benefit. Yes there can be conflicts, but these are less likely to occur 
> if communication stays open. Doing things behind closed doors is a 
> recipe for disaster whether you are a contributing company or 
> individual. Example: if I had developed notification payloads without 
> getting Tom's redirection, I would have come up with a patch that would 
> have been rejected, pissing me off and wasting my company's time. Now I 
> feel I can come up with something acceptable.

+1

Sincerely,

Joshua D. Drake

> 
> cheers
> 
> andrew
> 
-- 
     === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997            http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Lukas Kahwe Smith wrote:
> Hi,
> 
> I think another point you need to bring out more clearily is that the 
> community is also often "miffed" if they feel they have been left out of 
> the design and testing phases. This is sometimes just a reflex that is 
> not always based on technical reasoning. Its just that as you correctly 
> point out are worried of being "high-jacked" by companies.

I hate to mention an emotional community reaction in this document. We
normally just highlight the inefficiency of a company doing things on
their own, and the wasted effort of them having to make adjustments.

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

Joshua D. Drake wrote:
> On Wed, 2006-12-20 at 09:51 +1300, Andrej Ricnik-Bay wrote:
> > On 12/20/06, Joshua D. Drake <jd@commandprompt.com> wrote:
> > 
> > > O.k. in all Bruce I like your article but I must admit it seems to take
> > > a "The community is god" perspective and that we must all bend to the
> > > will of said community.
> > I'm not really in a position to judge how a company thinks about
> > "donating  resources" to a project, but I certainly think that Bruce'
> > standpoint is correct, and that the community is *indeed* the driver of
> > a project;  if a company doesn't like how the community deals with
> > their requirements/needs they can just maintain their own branch.
> 
> It is definitely a tough distinction. My first thought on reply was that
> well a companies employees become members of the community but that
> reinforces what you say above.
> 
> I think my overall thought is the tone seems a bit non-gracious to
> companies, when IMO the community should be actively courting companies
> to give resources. If companies feel unwelcome, they won't give.
> 
> > 
> > 
> > > The community could learn a great deal from adopting some of the more
> > > common business practices when it comes to development as well.
> > >
> > > In short, I guess I think it is important to recognize that both are
> > > partners in the open source world and that to ignore one over the other
> > > is destined to fail.
> > Do you have any statistical data to back that hypothesis?
> 
> Of which, the community learning or my take that if we ignore one over
> the other it is destined to fail?

This actually brings up an important distinction.  Joshua is saying that
the community is painted as "god" in the article, and I agree there is a
basis for that, but I don't think you can consider the community and
company as equals either.  I remember the president of Great Bridge
saying that the company needs the community, but not visa-vera --- 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.  Also, the community is developing the software at a rate that
almost no other company can match, so again the company is kind of in
toe if they are working with the community process.  For example, the
community is not submitting patches for the company to approve.

I do think I need to add a more generous outreach to companies in the
article, explaining how valuable they are to the community, so let me
work on that and I will post when I have an update.

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

> > > > The community could learn a great deal from adopting some of the more
> > > > common business practices when it comes to development as well.
> > > >
> > > > In short, I guess I think it is important to recognize that both are
> > > > partners in the open source world and that to ignore one over the other
> > > > is destined to fail.
> > > Do you have any statistical data to back that hypothesis?
> > 
> > Of which, the community learning or my take that if we ignore one over
> > the other it is destined to fail?
> 
> This actually brings up an important distinction.  Joshua is saying that
> the community is painted as "god" in the article, and I agree there is a
> basis for that, but I don't think you can consider the community and
> company as equals either. 

I can agree with that.

>  I remember the president of Great Bridge
> saying that the company needs the community, but not visa-vera --- 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. 

I 95% agree here. If EDB or CMD were go to down in flames, it could hurt
the community quite a bit. It isn't that the community wouldn't go on,
but that it would definitely negatively affect the productivity of the
community for "n" amount of time.

>  Also, the community is developing the software at a rate that
> almost no other company can match, so again the company is kind of in
> toe if they are working with the community process.  For example, the
> community is not submitting patches for the company to approve.

Agreed.

> 
> I do think I need to add a more generous outreach to companies in the
> article, explaining how valuable they are to the community, so let me
> work on that and I will post when I have an update.

Cool, that is what I was really looking for.

Sincerely,

Joshua D. Drake



> 
-- 
     === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997            http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

On 12/19/06, Bruce Momjian <bruce@momjian.us> wrote:
> This actually brings up an important distinction.  Joshua is saying that
> the community is painted as "god" in the article, and I agree there is a
> basis for that, but I don't think you can consider the community and
> company as equals either.

Of course, this seems only true to PostgreSQL, FreeBSD, and very few
others... not the other 99% of open source communities which are open
sourced around a commercial product or consist of a handful of people.The title of the document is generalized to "Open
Source
Communities", and most of the items here just don't represent the
majority of open source communities whether we'd like it to or not.

> 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.

In my opinion, if a PostgreSQL company dies, there will be a
ripple-effect felt in the community depending on the size of the
company, development/support sponsored, monetary contribution, etc.
If a company buys up (or buys off) the experienced major developers
for an open source project, it could easily spell disaster for the
project.

However, in regard to a dying community killing a company, I disagree
completely.  Commercial software companies most certainly do not rely
on outside contribution to survive.  And, like it or not, any company
could run with PostgreSQL as a normal software company exactly the
same way as they can with code they wrote from scratch.  Many open
source people forget there is a commercial software industry that not
only predates them, but will most likely continue on far into the
future.

> Also, the community is developing the software at a rate that
> almost no other company can match, so again the company is kind of in
> toe if they are working with the community process.

Again, this thinking may apply only to a few projects with a
PostgreSQL-like model.  The reference to, "the community" seems
directly linked to PostgreSQL.  I can name many communities that could
never compete on a development rate with their commercial
sponsors/counterparts.

Commercial companies (100+ names left out) can develop way more
features than most open source communities in the same span of time or
faster.  And, going back to the article being open-source in general,
most other open source communities don't actually contribute a ton of
code back to the project's parent software base; certainly not more
than the company writes itself.

As this document is supposed to be factual, I'd really like not to get
into a war over lines-of-code development rates vs. bugs, quality (or
lack thereof), etc.  The *fact* is, some commercial software companies
could easily churn out more, better quality code, if they chose to
hire the right people and put enough money and thought into it.

> I do think I need to add a more generous outreach to companies in the
> article, explaining how valuable they are to the community, so let me
> work on that and I will post when I have an update.

The title of the document, "How Companies Can Effectively Contribute
To Open Source Communities" doesn't seem to fit the content.  I would
consider something more along the lines of, "Enterprise Open Source:
Effectively Contributing Commercial Support to Open Source
Communities", or, "What to Expect when Contributing to Open Source
Projects".  More specifically, I'd restrict the document to PostgreSQL
because it really doesn't represent the majority of open source
software communities which tend to be commercially-driven.

If this document is meant to help companies help open source and/or
PostgreSQL, I think that's a good idea.  This document doesn't seem to
be written in the way a company, looking to help fund or contribute to
an open source project, would respond favorably to.  It seems more or
less from a community view as to, "if you want to help us, this is
what we expect from you"; which may be the desired intent.?.

I read it over twice and that was my impression.  While I'm a big fan
of open source, prefer it to *most* commercial software, and think
it's a great thing all around, I'm a realist and am not going to turn
a blind eye to the enormously successful and profitable arena of
commercial software.

You and I have discussed these items before privately and, while we
always seem to disagree, I just figured I'd post them (for better or
worse) on-list.  For both sides of the discussion, I'm sure there are
others who think the same thing but remain silent :)


-- 
Jonah H. Harris, Software Architect | phone: 732.331.1324
EnterpriseDB Corporation            | fax: 732.331.1301
33 Wood Ave S, 3rd Floor            | jharris@enterprisedb.com
Iselin, New Jersey 08830            | http://www.enterprisedb.com/

"Joshua D. Drake" <jd@commandprompt.com> writes:
>> I remember the president of Great Bridge
>> saying that the company needs the community, but not visa-vera --- 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. 

> I 95% agree here. If EDB or CMD were go to down in flames, it could hurt
> the community quite a bit.

Josh, I hate to burst your bubble, but Great Bridge employed a much
larger fraction of the hacker-community-at-the-time than either EDB or
CMD do today.  We survived that, and if EDB or CMD or Greenplum or the
entire lot went down tomorrow, we'd survive that too.
        regards, tom lane

On Tue, 2006-12-19 at 22:04 -0500, Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
> >> I remember the president of Great Bridge
> >> saying that the company needs the community, but not visa-vera --- 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. 
> 
> > I 95% agree here. If EDB or CMD were go to down in flames, it could hurt
> > the community quite a bit.
> 
> Josh, I hate to burst your bubble, but Great Bridge employed a much
> larger fraction of the hacker-community-at-the-time than either EDB or
> CMD do today.  We survived that, and if EDB or CMD or Greenplum or the
> entire lot went down tomorrow, we'd survive that too.

I never once suggested that the community would not survive. I said it
would hurt productivity for "n" amount of time.

Let's just be realistic here:

In one fails swoop:

Devrim, Alvaro, Darcy, Heikki, Bruce, Simon, Greg, Dave, Marc and I are
all suddenly looking for employment...

You don't think there would be an issue that could cause some grief to
the community? Is it surmountable? Of course, that isn't the point. The
point is that it is not painless. 


Sincerely,

Joshua D. Drake


> 
>             regards, tom lane
> 
-- 
     === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997            http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Joshua D. Drake wrote:
> >  I remember the president of Great Bridge
> > saying that the company needs the community, but not visa-vera --- 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. 
> 
> I 95% agree here. If EDB or CMD were go to down in flames, it could hurt
> the community quite a bit. It isn't that the community wouldn't go on,
> but that it would definitely negatively affect the productivity of the
> community for "n" amount of time.

The assumption is that other companies would jump in to support the paid
individuals affected by the company closings.  If that didn't happen,
there would be an effect, yes.

> >  Also, the community is developing the software at a rate that
> > almost no other company can match, so again the company is kind of in
> > toe if they are working with the community process.  For example, the
> > community is not submitting patches for the company to approve.
> 
> Agreed.
> 
> > 
> > I do think I need to add a more generous outreach to companies in the
> > article, explaining how valuable they are to the community, so let me
> > work on that and I will post when I have an update.
> 
> Cool, that is what I was really looking for.

Yes, the original was pretty negative, and the end of it was very
negative, I felt.

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

> In one fails swoop:

Sorry a beer and email just doesn't mix. The above should be one fell
swoop.

> 
> Devrim, Alvaro, Darcy, Heikki, Bruce, Simon, Greg, Dave, Marc and I are
> all suddenly looking for employment...
> 
> You don't think there would be an issue that could cause some grief to
> the community? Is it surmountable? Of course, that isn't the point. The
> point is that it is not painless. 
> 
> 
> Sincerely,
> 
> Joshua D. Drake
> 
> 
> > 
> >             regards, tom lane
> > 
-- 
     === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997            http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Joshua D. Drake wrote:

>
> In one fails swoop:
>

ITYM "fell swoop". see http://www.worldwidewords.org/qa/qa-fel1.htm

cheers

a

Jonah H. Harris wrote:
>
> 
> As this document is supposed to be factual, I'd really like not to get
> into a war over lines-of-code development rates vs. bugs, quality (or
> lack thereof), etc.  The *fact* is, some commercial software companies
> could easily churn out more, better quality code, if they chose to
> hire the right people and put enough money and thought into it.
> 

Ahem - not wanting a war either, but what you have stated is not really 
a fact at all - as it is full of hypothetical 'if's!

> 
> The title of the document, "How Companies Can Effectively Contribute
> To Open Source Communities" doesn't seem to fit the content. 
> 

This makes sense - since Bruce is primarily writing about the 
*Postgresql* community, maybe putting that in the title might be good!

Cheers

Mark

> > > 
> > > I do think I need to add a more generous outreach to companies in the
> > > article, explaining how valuable they are to the community, so let me
> > > work on that and I will post when I have an update.
> > 
> > Cool, that is what I was really looking for.
> 
> Yes, the original was pretty negative, and the end of it was very
> negative, I felt.

Great I look forward to seeing a revised version.

Sincerely,

Joshua D. Drake


> 
-- 
     === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997            http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

The article assumes healthy open source communities, not open source
communities that are offshoots or parasites of commercial companies.

The article title, "How Companies Can Effectively Contribute To Open
Source Communities" itself assumes that because the company is
contributing to the community, not the reverse.

As for your other points, I don't think they reflect the general feeling
of the PostgreSQL community.

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

Jonah H. Harris wrote:
> On 12/19/06, Bruce Momjian <bruce@momjian.us> wrote:
> > This actually brings up an important distinction.  Joshua is saying that
> > the community is painted as "god" in the article, and I agree there is a
> > basis for that, but I don't think you can consider the community and
> > company as equals either.
> 
> Of course, this seems only true to PostgreSQL, FreeBSD, and very few
> others... not the other 99% of open source communities which are open
> sourced around a commercial product or consist of a handful of people.
>  The title of the document is generalized to "Open Source
> Communities", and most of the items here just don't represent the
> majority of open source communities whether we'd like it to or not.
> 
> > 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.
> 
> In my opinion, if a PostgreSQL company dies, there will be a
> ripple-effect felt in the community depending on the size of the
> company, development/support sponsored, monetary contribution, etc.
> If a company buys up (or buys off) the experienced major developers
> for an open source project, it could easily spell disaster for the
> project.
> 
> However, in regard to a dying community killing a company, I disagree
> completely.  Commercial software companies most certainly do not rely
> on outside contribution to survive.  And, like it or not, any company
> could run with PostgreSQL as a normal software company exactly the
> same way as they can with code they wrote from scratch.  Many open
> source people forget there is a commercial software industry that not
> only predates them, but will most likely continue on far into the
> future.
> 
> > Also, the community is developing the software at a rate that
> > almost no other company can match, so again the company is kind of in
> > toe if they are working with the community process.
> 
> Again, this thinking may apply only to a few projects with a
> PostgreSQL-like model.  The reference to, "the community" seems
> directly linked to PostgreSQL.  I can name many communities that could
> never compete on a development rate with their commercial
> sponsors/counterparts.
> 
> Commercial companies (100+ names left out) can develop way more
> features than most open source communities in the same span of time or
> faster.  And, going back to the article being open-source in general,
> most other open source communities don't actually contribute a ton of
> code back to the project's parent software base; certainly not more
> than the company writes itself.
> 
> As this document is supposed to be factual, I'd really like not to get
> into a war over lines-of-code development rates vs. bugs, quality (or
> lack thereof), etc.  The *fact* is, some commercial software companies
> could easily churn out more, better quality code, if they chose to
> hire the right people and put enough money and thought into it.
> 
> > I do think I need to add a more generous outreach to companies in the
> > article, explaining how valuable they are to the community, so let me
> > work on that and I will post when I have an update.
> 
> The title of the document, "How Companies Can Effectively Contribute
> To Open Source Communities" doesn't seem to fit the content.  I would
> consider something more along the lines of, "Enterprise Open Source:
> Effectively Contributing Commercial Support to Open Source
> Communities", or, "What to Expect when Contributing to Open Source
> Projects".  More specifically, I'd restrict the document to PostgreSQL
> because it really doesn't represent the majority of open source
> software communities which tend to be commercially-driven.
> 
> If this document is meant to help companies help open source and/or
> PostgreSQL, I think that's a good idea.  This document doesn't seem to
> be written in the way a company, looking to help fund or contribute to
> an open source project, would respond favorably to.  It seems more or
> less from a community view as to, "if you want to help us, this is
> what we expect from you"; which may be the desired intent.?.
> 
> I read it over twice and that was my impression.  While I'm a big fan
> of open source, prefer it to *most* commercial software, and think
> it's a great thing all around, I'm a realist and am not going to turn
> a blind eye to the enormously successful and profitable arena of
> commercial software.
> 
> You and I have discussed these items before privately and, while we
> always seem to disagree, I just figured I'd post them (for better or
> worse) on-list.  For both sides of the discussion, I'm sure there are
> others who think the same thing but remain silent :)
> 
> 
> -- 
> Jonah H. Harris, Software Architect | phone: 732.331.1324
> EnterpriseDB Corporation            | fax: 732.331.1301
> 33 Wood Ave S, 3rd Floor            | jharris@enterprisedb.com
> Iselin, New Jersey 08830            | http://www.enterprisedb.com/
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at
> 
>                 http://www.postgresql.org/about/donate

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

"Jonah H. Harris" <jonah.harris@gmail.com> writes:
> On 12/19/06, 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.

> However, in regard to a dying community killing a company, I disagree
> completely.  Commercial software companies most certainly do not rely
> on outside contribution to survive.

So, I suppose you can give us ten examples of thriving companies based
on private forks of dead open-source projects?
        regards, tom lane

Jonah H. Harris wrote:

> The title of the document, "How Companies Can Effectively Contribute
> To Open Source Communities" doesn't seem to fit the content.  I would
> consider something more along the lines of, "Enterprise Open Source:
> Effectively Contributing Commercial Support to Open Source
> Communities", or, "What to Expect when Contributing to Open Source
> Projects".  More specifically, I'd restrict the document to PostgreSQL
> because it really doesn't represent the majority of open source
> software communities which tend to be commercially-driven.

I agree that there are a lot of open source "communities" which are
setup in the other way you describe, the non-PostgreSQL way.  However I
wouldn't go as far as saying that the 99% of the OSS projects are.
Linux (the kernel), Gnome, KDE are counterexamples -- no single company
could ever dream of improving their products at the rate those projects
do.  I think the element in common in all these projects is that there
are multiple companies cooperating to see them progress; cooperating
with each other, and with individual developers.  As the project
matures, more developers join, the companies hires some of them and let
them work on the project, and more companies join.  If a single company
leaves it may hinder development but it's not the doom of the project.
This is in stark contrast with one-manned projects or single-company
projects.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

On Tue, 2006-12-19 at 22:54 -0500, Tom Lane wrote:
> "Jonah H. Harris" <jonah.harris@gmail.com> writes:
> > On 12/19/06, 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.
> 
> > However, in regard to a dying community killing a company, I disagree
> > completely.  Commercial software companies most certainly do not rely
> > on outside contribution to survive.
> 
> So, I suppose you can give us ten examples of thriving companies based
> on private forks of dead open-source projects?

MySQL? (sorry couldn't resist).

> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
> 
-- 
     === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997            http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Joshua D. Drake wrote:
> On Tue, 2006-12-19 at 22:04 -0500, Tom Lane wrote:
> > "Joshua D. Drake" <jd@commandprompt.com> writes:
> > >> I remember the president of Great Bridge
> > >> saying that the company needs the community, but not visa-vera --- 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. 
> > 
> > > I 95% agree here. If EDB or CMD were go to down in flames, it could hurt
> > > the community quite a bit.
> > 
> > Josh, I hate to burst your bubble, but Great Bridge employed a much
> > larger fraction of the hacker-community-at-the-time than either EDB or
> > CMD do today.  We survived that, and if EDB or CMD or Greenplum or the
> > entire lot went down tomorrow, we'd survive that too.
> 
> I never once suggested that the community would not survive. I said it
> would hurt productivity for "n" amount of time.
> 
> Let's just be realistic here:
> 
> In one fails swoop:
> 
> Devrim, Alvaro, Darcy, Heikki, Bruce, Simon, Greg, Dave, Marc and I are
> all suddenly looking for employment...
> 
> You don't think there would be an issue that could cause some grief to
> the community? Is it surmountable? Of course, that isn't the point. The
> point is that it is not painless. 

Yes, that does seem painful.  I would hope than any vibrant open source
community would have other companies who would have new jobs for many of
these individuals, but I also hope some could continue as volunteers if
they don't get sponsored jobs.  

I know when Great Bridge closed, most of the community people had new
jobs almost immediately.

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

"Joshua D. Drake" <jd@commandprompt.com> writes:
> On Tue, 2006-12-19 at 22:54 -0500, Tom Lane wrote:
>> So, I suppose you can give us ten examples of thriving companies based
>> on private forks of dead open-source projects?

> MySQL? (sorry couldn't resist).

Uh, no, because that was never a genuine open-source (as in
community-owned, community-driven) project --- MySQL AB has always
owned it --- lock, stock, barrel and every single major developer.
Plastering a GPL license on the top of the code tree doesn't
make it into a community project.

Illustra/Ingres would be a valid counterexample in our own historical
tradition, except that they've thrown in the towel recently IIRC?

I'm not aware of too many more.  Like I said, if you want to establish
this as the typical case, name ten examples.
        regards, tom lane

On Tue, 2006-12-19 at 23:17 -0500, Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
> > On Tue, 2006-12-19 at 22:54 -0500, Tom Lane wrote:
> >> So, I suppose you can give us ten examples of thriving companies based
> >> on private forks of dead open-source projects?
> 
> > MySQL? (sorry couldn't resist).
> 
> Uh, no, because that was never a genuine open-source (as in
> community-owned, community-driven) project --- MySQL AB has always
> owned it --- lock, stock, barrel and every single major developer.
> Plastering a GPL license on the top of the code tree doesn't
> make it into a community project.
> 
> Illustra/Ingres would be a valid counterexample in our own historical
> tradition, except that they've thrown in the towel recently IIRC?

Ingres is opensource again yes. http://www.ingres.com/ .

Joshua D. Drake


> 
> I'm not aware of too many more.  Like I said, if you want to establish
> this as the typical case, name ten examples.
> 
>             regards, tom lane
> 
-- 
     === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997            http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

On 12/19/06, Joshua D. Drake <jd@commandprompt.com> wrote:
> Ingres is opensource again yes. http://www.ingres.com/ .

Yep.

> > I'm not aware of too many more.  Like I said, if you want to establish
> > this as the typical case, name ten examples.

We could also mention all the Ingres-based offshoots that were
commercial.  Let me think of some other examples... but there may not
be that many seeing as there aren't really that many PostgreSQL-like
communities.  I guess I could mention more if I had a clear
understanding of what we mean when we say, "community".

/me will think of some forked projects that are successful, I'm sure
there's quite a few out there.

Many university projects which are fairly community-based go
commercial and the community fades away.  Sometimes a community will
be created around once open source, gone commercial, back to open
source projects like *BSD, POSTGRES, and INGRES.

In my opinion, should a company base it's product on open source,
their first responsibility as a business should be to plan a
continuity strategy around near-catastrophic changes to the project
their basing themselves on.  Lack of doing so would most certainly
make the case that they would fail if the community failed... but then
again, that's just poor business planning at fault and has nothing to
do with the open source community.

-- 
Jonah H. Harris, Software Architect | phone: 732.331.1324
EnterpriseDB Corporation            | fax: 732.331.1301
33 Wood Ave S, 3rd Floor            | jharris@enterprisedb.com
Iselin, New Jersey 08830            | http://www.enterprisedb.com/

On 12/19/06, Bruce Momjian <bruce@momjian.us> wrote:
> The article assumes healthy open source communities, not open source
> communities that are offshoots or parasites of commercial companies.

Assumptions are many times incorrect.  Similarly, I wouldn't disregard
an open source community just because it may be based on an open
source variant of a commercial software version.

> The article title, "How Companies Can Effectively Contribute To Open
> Source Communities" itself assumes that because the company is
> contributing to the community, not the reverse.

Which other thriving communities have been consulted?  If all
assumptions in the document are based solely on experiences in the
PostgreSQL community, then is it not, "How Companies Can Effectively
Contribute To PostgreSQL"?

> As for your other points, I don't think they reflect the general feeling
> of the PostgreSQL community.

Perhaps not.

-- 
Jonah H. Harris, Software Architect | phone: 732.331.1324
EnterpriseDB Corporation            | fax: 732.331.1301
33 Wood Ave S, 3rd Floor            | jharris@enterprisedb.com
Iselin, New Jersey 08830            | http://www.enterprisedb.com/

On Tue, Dec 19, 2006 at 07:17:13PM -0800, Joshua D. Drake wrote:
> On Tue, 2006-12-19 at 22:04 -0500, Tom Lane wrote:
> > "Joshua D. Drake" <jd@commandprompt.com> writes:
> > >> I remember the president of Great Bridge
> > >> saying that the company needs the community, but not visa-vera --- 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. 
> > 
> > > I 95% agree here. If EDB or CMD were go to down in flames, it could hurt
> > > the community quite a bit.
> > 
> > Josh, I hate to burst your bubble, but Great Bridge employed a much
> > larger fraction of the hacker-community-at-the-time than either EDB or
> > CMD do today.  We survived that, and if EDB or CMD or Greenplum or the
> > entire lot went down tomorrow, we'd survive that too.
> 
> I never once suggested that the community would not survive. I said it
> would hurt productivity for "n" amount of time.
> 
> Let's just be realistic here:
> 
> In one fails swoop:
> 
> Devrim, Alvaro, Darcy, Heikki, Bruce, Simon, Greg, Dave, Marc and I are
> all suddenly looking for employment...

and by Friday, all are working again, unless they want to take a few
weeks off. :)

> You don't think there would be an issue that could cause some grief to
> the community?

Not really.  It might cause some personal grief to each, which might
cause some temporary loss of productivity.  Then again, it might be a
stimulating shakeup, or "creative destruction," to borrow a phrase.

> Is it surmountable?  Of course, that isn't the point.  The point is
> that it is not painless. 

Nothing is painless.

Cheers,
D
-- 
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778        AIM: dfetter666                             Skype: davidfetter

Remember to vote!

On Tue, Dec 19, 2006 at 05:40:12PM -0500, Bruce Momjian wrote:
> Lukas Kahwe Smith wrote:
> > Hi,
> > 
> > I think another point you need to bring out more clearily is that
> > the community is also often "miffed" if they feel they have been
> > left out of the design and testing phases. This is sometimes just
> > a reflex that is not always based on technical reasoning. Its just
> > that as you correctly point out are worried of being "high-jacked"
> > by companies.
> 
> I hate to mention an emotional community reaction in this document.

You don't have to name it that if you don't want to, although respect
(or at least a good simulation of it) is crucial when dealing with any
person or group.  Handing the community a /fait accompli/ is a great
way to convey disrespect, no matter how well-meaning the process
originally was.

> We normally just highlight the inefficiency of a company doing
> things on their own, and the wasted effort of them having to make
> adjustments.

Would it really hurt to touch on some of the "whys" of this?

Cheers,
D
-- 
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778        AIM: dfetter666                             Skype: davidfetter

Remember to vote!

<p><font size="2">Jonah Harris wrote:<br /> > We could also mention all the Ingres-based offshoots that were<br />
>commercial.  Let me think of some other examples... but there may not<br /> > be that many seeing as there
aren'treally that many PostgreSQL-like<br /> > communities.  I guess I could mention more if I had a clear<br />
>understanding of what we mean when we say, "community".<br /><br /> That's something that bothers me as well: The
articleand the discussions talks about the community, but what's The Community? There really isn't any clear
definition,the closest thing is the list of committers or core members, but I don't think anyone considers The
Communityto be just the committers, though that's the group of people whose opinions matter the most when trying to get
apatch accepted. I don't think it's fruitful to spend time on a precise definition, but it's important to realize that
thereisn't one and that the community consists of individuals with different priorities, opinions and points of view.
Thereforeit's a bit meaningless to say that The Community thinks this or The Community says that. On one topic, some
peoplemight have a very strong opinion one way, and others might just not care at all. On some topics, everyone agrees.
Andon some topics, people strongly disagree. And that's ok. Respecting all the different viewpoints leads to a
well-balancedproduct.<br /><br /> How does that affect a company trying to get a patch accepted? First, do no harm. If
you'reproposing something that for example brakes someone else's application, your proposal is likely to be rejected.
Orif you're proposing a patch that increases the performance of something, at a very high cost on some other things,
yourpatch is likely to be rejected. Another kind of harm that many people miss is the maintainability of the codebase.
Addingcomplexity for little gain is likely to be rejected, just because it'll make the code harder to read.<br /><br />
Secondly,getting a large feature accepted is easier if you're not just dumping a large patch to pgsql-patches, but
you'recommitted to maintainting it and developing it further. Remember, some  things you might have ignored as not
importantmight be crucial to other people.<br /><br /> Also, a note to all Members of The Community: people like to
workin different ways. Some might want to seek acceptance and commitment to a feature from others before starting
development.Some might want to write a large up-front design document before proposing something. Some might want to
writean experimental patch with a lot of quick hacks and no comments, and refine that according to feedback. And we,
TheMembers of The Community, if I may count myself as one, don't get to choose how others prefer to work.<br /><br />
--<br/>  Heikki Linnakangas<br />  EnterpriseDB   <a
href="http://www.enterprisedb.com">http://www.enterprisedb.com</a><br/></font> 

David Fetter wrote:
> On Tue, Dec 19, 2006 at 05:40:12PM -0500, Bruce Momjian wrote:
> > Lukas Kahwe Smith wrote:
> > > Hi,
> > > 
> > > I think another point you need to bring out more clearily is that
> > > the community is also often "miffed" if they feel they have been
> > > left out of the design and testing phases. This is sometimes just
> > > a reflex that is not always based on technical reasoning. Its just
> > > that as you correctly point out are worried of being "high-jacked"
> > > by companies.
> > 
> > I hate to mention an emotional community reaction in this document.
> 
> You don't have to name it that if you don't want to, although respect
> (or at least a good simulation of it) is crucial when dealing with any
> person or group.  Handing the community a /fait accompli/ is a great
> way to convey disrespect, no matter how well-meaning the process
> originally was.
> 
> > We normally just highlight the inefficiency of a company doing
> > things on their own, and the wasted effort of them having to make
> > adjustments.
> 
> Would it really hurt to touch on some of the "whys" of this?

Sure, I mention that once they deal with the community, it might
requires extensive rewriting:
This means the employee is not benefitting from community oversightand suggestions, often leading to a major rewrite
whena patch issubmitted to the community.
 

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

Heikki Linnakangas wrote:
> Jonah Harris wrote:
> > We could also mention all the Ingres-based offshoots that were
> > commercial.  Let me think of some other examples... but there may not
> > be that many seeing as there aren't really that many PostgreSQL-like
> > communities.  I guess I could mention more if I had a clear
> > understanding of what we mean when we say, "community".
> 
> That's something that bothers me as well: The article and the
> discussions talks about the community, but what's The Community? There
> really isn't any clear definition, the closest thing is the list of
> committers or core members, but I don't think anyone considers The
> Community to be just the committers, though that's the group of people
> whose opinions matter the most when trying to get a patch accepted. I

Not really.  The committers/core just weigh in on the patch, but it is
the general discussion that determines if a patch gets in.  Now, if all
committers don't want a patch, it is unlikely it will be applied, but in
most cases some committers want something, and some don't, and the
discussion determines if it gets in or not, perhaps with modification so
all community members are happy.

The remainder of this email talks about general principles for all
developers, not just for company employees.  If we need more text in
this area, it should be added to the developer's FAQ.  Feel free to
suggest additions to that.

I am kind of stumped that we have so much text in the developer's FAQ,
but it seems many people don't know what is in there.  The Developer's
FAQ is referenced in the main FAQ, and on the web site.  I am inclinded
to think that developers know the contents of the developer's FAQ, but
think they know better, and go ahead and do what they want anyway.  I
have no idea how to fix that.  :-(

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

> don't think it's fruitful to spend time on a precise definition, but
> it's important to realize that there isn't one and that the community
> consists of individuals with different priorities, opinions and points
> of view. Therefore it's a bit meaningless to say that The Community
> thinks this or The Community says that. On one topic, some people might
> have a very strong opinion one way, and others might just not care at
> all. On some topics, everyone agrees. And on some topics, people
> strongly disagree. And that's ok. Respecting all the different
> viewpoints leads to a well-balanced product.
> 
> How does that affect a company trying to get a patch accepted? First,
> do no harm. If you're proposing something that for example brakes
> someone else's application, your proposal is likely to be rejected. Or
> if you're proposing a patch that increases the performance of something,
> at a very high cost on some other things, your patch is likely to be
> rejected. Another kind of harm that many people miss is the
> maintainability of the codebase. Adding complexity for little gain is
> likely to be rejected, just because it'll make the code harder to read.
> 
> Secondly, getting a large feature accepted is easier if you're not just
> dumping a large patch to pgsql-patches, but you're committed to
> maintainting it and developing it further. Remember, some  things you
> might have ignored as not important might be crucial to other people.
> 
> Also, a note to all Members of The Community: people like to work in
> different ways. Some might want to seek acceptance and commitment to
> a feature from others before starting development. Some might want to
> write a large up-front design document before proposing something. Some
> might want to write an experimental patch with a lot of quick hacks
> and no comments, and refine that according to feedback. And we, The
> Members of The Community, if I may count myself as one, don't get to
> choose how others prefer to work.
> 
> --
>  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com

-- Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

> The remainder of this email talks about general principles for all
> developers, not just for company employees.  If we need more text in
> this area, it should be added to the developer's FAQ.  Feel free to
> suggest additions to that.
> 
> I am kind of stumped that we have so much text in the developer's FAQ,
> but it seems many people don't know what is in there.  The Developer's
> FAQ is referenced in the main FAQ, and on the web site.  I am inclinded
> to think that developers know the contents of the developer's FAQ, but
> think they know better, and go ahead and do what they want anyway.  I
> have no idea how to fix that.  :-(

We don't accept patches from anyone who doesn't follow the developer FAQ
rules. Which means of course, that I need to go read it ;)

Sincerely,

Joshua D. Drake




-- 
     === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997            http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

The paper is a good one, from my perspective. It does address important
issues and maybe we don't all agree on the exact places lines have been
drawn, but I think we probably do agree that these things need to be
said. Now that they have been said, we must allow reasonable time for
the understanding to percolate and for appropriate changes of direction
to take place. We can't undo the past, but we can change the future.

On Tue, 2006-12-19 at 19:13 -0500, Bruce Momjian wrote:
> This actually brings up an important distinction.  Joshua is saying
> that
> the community is painted as "god" in the article, and I agree there is
> a
> basis for that, but I don't think you can consider the community and
> company as equals either.  

>  Also, the community is developing the software at a rate that
> almost no other company can match, so again the company is kind of in
> toe if they are working with the community process.  For example, the
> community is not submitting patches for the company to approve.

The community is developing software quickly because there are some/many
full-time paid staff assigned to the project. We (the Community) need to
recognise that the Community is *all* of us and that includes various
Companies i.e. Companies aren't distinct from the Community. In that
sense, I would agree that The Community is "above" Companies.

We must be appreciative of contributions made in imperfect conditions.
Frequently changes are made behind closed doors and then approval is
given to release the software, sometimes after extensive lobbying. We
shouldn't shun those contributions, even while advising those companies
that we'd prefer it if they didn't do it that way next time. We should
assume that all development is done with the best intentions, even if
things don't follow the FAQ. Now that we have some clear policy on this,
I look forward to people being able to say "best not do it that way, the
Community has a clear policy against that", that Teodor, myself and
others can advise sponsors about.

BTW, the phrase "Companies" must also include any external Enterprise,
since many good things come our way from Universities and Colleges. We
should also recognise that many enterprises are in fact non-profit, or
simply local/national government/administrative organisations. Profit
per se is not the only thing that drives requirements.

--  Simon Riggs              EnterpriseDB   http://www.enterprisedb.com

>>> 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

<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

On Wed, 2006-12-20 at 00:29 -0800, David Fetter wrote:
> On Tue, Dec 19, 2006 at 05:40:12PM -0500, Bruce Momjian wrote:
> > Lukas Kahwe Smith wrote:
> > > I think another point you need to bring out more clearily is that
> > > the community is also often "miffed" if they feel they have been
> > > left out of the design and testing phases. This is sometimes just
> > > a reflex that is not always based on technical reasoning. Its just
> > > that as you correctly point out are worried of being "high-jacked"
> > > by companies.
> > 
> > I hate to mention an emotional community reaction in this document.
> 
> You don't have to name it that if you don't want to, although respect
> (or at least a good simulation of it) is crucial when dealing with any
> person or group. 

I'm very interested in this, because it does seem to me that there is an
emotional reaction to many things.

>  Handing the community a /fait accompli/ is a great
> way to convey disrespect, no matter how well-meaning the process
> originally was.

In a humble, non-confrontational tone: Why/How does a patch imply a fait
accompli, or show any disrespect?

My own reaction to Teodor's recent submission, or Kai-Uwe Sattler's
recent contributions has been: great news, patches need some work, but
thanks.

Please explain on, or off, list to help me understand.

--  Simon Riggs              EnterpriseDB   http://www.enterprisedb.com

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.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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

"Simon Riggs" <simon@2ndquadrant.com> writes:

> In a humble, non-confrontational tone: Why/How does a patch imply a fait
> accompli, or show any disrespect?

Well depending on the circumstances it could show the poster isn't interested
in the judgement of the existing code authors. It can be hard to tell someone
that their last 6 months of work was all in a direction that other developers
would rather Postgres not head.

However I think people are over-generalising if they think this is always
true. 

Patches are often submitted by people who invite comment and are open to new
ideas and reworking their approach. Whether the submission is as a fait
accompli or as the beginning of a dialogue (imho a more productive dialogue
than the usual hand-waving on -hackers) is determined more by the attitude of
the presenter and willingness to take criticisms and make changes than it is
by the mere fact that they've written code without prior approval.

The flip side of all of this is that "the community" doesn't always engage
when people do ask for feedback. I asked for comments on how best to proceed
getting info down to the Sort node from a higher Limit node to implement the
limit-sort optimization and didn't get any guidance. As a result I'm kind of
stuck. I can proceed without feedback but I fear I would be, in fact,
presenting the result as a fait accompli which would end up getting rejected
if others were less comfortable with breaking the planner and executor
abstractions (or if I choose not to do so and they decide the necessary
abstractions are needless complexity).

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com

OK, based on this feedback and others, I have made a new version of the
article:
http://momjian.us/main/writings/pgsql/company_contributions/

There are no new concepts, just a more balance article with some of the
awkward wording improved.  I also added a link to the article from the
developer's FAQ.

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

Joshua D. Drake wrote:
> Hello,
> 
> O.k. below are some comments. Your article although well written has a
> distinct, from the community perspective ;) and I think there are some
> points from the business side that are missed.
> 
> ---
> Employees working in open source communities have two bosses -- the
> companies that employ them, and the open source community, which must
> review their proposals and patches. Ideally, both groups would want the
> same thing, but often companies have different priorities in terms of
> deadlines, time investment, and implementation details. And,
> unfortunately for companies, open source communities rarely adjust their
> requirements to match company needs. They would often rather "do
> without" than tie their needs to those of a company.
> ---
> 
> Employees don't have two bosses at least not in the presentation above.
> In the community the employee may choose to do it the communities way or
> not. That choice is much more defined within a Boss purview. 
> 
> A companies priorities have a priority that is very powerful that the
> community does not and I believe should be reflected in a document such
> as this. To actually feed the employee. There is a tendency for the
> community to forget that every minute spent on community work is a
> direct neglect to the immediate (note that I say immediate) bottom line.
> That means that priorities must be balanced so that profit can be made,
> employees can get bonuses and god forbid a steady paycheck.
> 
> ---
> This makes the employee's job difficult. When working with the
> community, it can be difficult to meet company demands. If the company
> doesn't understand how the community works, the employee can be seen as
> defiant, when in fact the employee has no choice but to work in the
> community process and within the community timetable.
> 
> By serving two masters, employees often exhibit various behaviors that
> make their community involvement ineffective. Below I outline the steps
> involved in open source development, and highlight the differences
> experienced by employees involved in such activities.
> ---
> 
> The first paragraph seems to need some qualification. An employee is
> hired to work at the best interests of the company, not the community.
> Those two things may overlap, but that is subject to the companies
> declaration. If the employee is not doing the task as delegated that is
> defiant.
> 
> I am suspecting that your clarification would be something to the effect
> of:
> 
> When a company sets forth to donate resources to the community, it can
> make an employee's job difficult. It is important for the company to
> understand exactly what it is giving and the process that gift entails.
> 
> Or something like that.
> 
> I take subject to the term serving two masters, I am certainly not the
> master of my team but that may just be me.
> 
> ---
> Employees usually circulate their proposal inside their companies first
> before sharing it with the community. Unfortunately, many employees
> never take the additional step of sharing the proposal with the
> community. This means the employee is not benefitting from community
> oversight and suggestions, often leading to a major rewrite when a patch
> is submitted to the community.
> ---
> 
> I think the above is not quite accurate. I see few proposals actually
> come across to the community either and those that do seem to get bogged
> down instead of progress being made.
> 
> The most successful topics I have seen are those that usually have some
> footing behind them *before* they bring it to the community.
> 
> ---
> For employees, patch review often happens in the company first. Only
> when the company is satisfied is the patch submitted to the community.
> This is often done because of the perception that poor patches reflect
> badly on the company. The problem with this patch pre-screening is that
> it prevents parallel review, where the company and community are both
> reviewing the patch. Parallel review speeds completion and avoids
> unnecessary refactoring.
> ---
> 
> It does effect the perception of the company. Maybe not to the community
> but as someone who reads comments on the patches that comes through... I
> do not look forward to the day when I have a customer that says, didn't
> you submit that patch that was torn apart by...
> 
> ---
> As you can see, community involvement has unique challenges for company
> employees. There are often many mismatches between company needs and
> community needs, and the company must decide if it is worth honoring the
> community needs or going it alone, without community involvement.
> ---
> 
> Hmmm... That seems a bit unfair don't you think? The people within the
> company are likely members of the community. It seems that it makes
> sense for the community to actually work with the company as well. 
> 
> I am not suggesting that the community develop code to the needs of a
> company. I am suggesting that perhaps the community needs and the
> company needs often overlap but both sides tend to ignore the overlap
> and point at each other instead.
> 
> ---
> Company involvement in the community process usually has unforseen
> benefits, but also unexpected burdens and restrictions. The bottom line
> is that company and community priorities often diverge. If companies
> want community feedback, they should plan for such divergence and decide
> how hard they are willing to work to maintain community cooperation. If
> a company is not willing to adjust to community needs, often it is wise
> to avoid the community process.
> ---
> 
> O.k. in all Bruce I like your article but I must admit it seems to take
> a "The community is god" perspective and that we must all bend to the
> will of said community.
> 
> The community could learn a great deal from adopting some of the more
> common business practices when it comes to development as well.
> 
> In short, I guess I think it is important to recognize that both are
> partners in the open source world and that to ignore one over the other
> is destined to fail.
> 
> Sincerely,
> 
> Joshua D. Drake
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
>       === The PostgreSQL Company: Command Prompt, Inc. ===
> Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
> Providing the most comprehensive  PostgreSQL solutions since 1997
>              http://www.commandprompt.com/
> 
> Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +

Kevin Grittner 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.

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   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +