Companies Contributing to Open Source

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

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

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

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.

--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | yahoo }.com

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