Re: Companies Contributing to Open Source

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