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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
