titleHow Companies Can Effectively Contribute To Open Source Communities
While open source communities are primarily made up of volunteer contributors,
company involvement is always welcome. Companies often bring a fresh
perspective, new ideas, and a testing infrastructure to a project.
Companies can also fund large new features that require more time
than a single volunteer can contribute. However, companies must adapt
to a new approach to development because they have to work in a larger
community environment. This article outlines this new development
approach and ways of maximizing the effectiveness of company contributions
to open source projects.
lyxframeendsection*How Are Company-Sponsored Developers Different?
Volunteers give of their free time to help open source projects. Company-sponsored
developers work in a more complex environment because they have two
bosses -- the company, which employs them, and the open source community,
which must review their proposals and patches. Ideally, both groups
would always be in agreement, but sometimes companies and communities
have different priorities in terms of deadlines, time investment,
and implementation details. And when conflicts occur, companies usually
have to adjust their approach to meet the broader community goals.
This makes the employee's job difficult. When working with the community,
it can be difficult to always meet company demands. If the company
does not understand how the community works, the employee can be seen
as inflexible, when in fact the employee has no choice but to work
in the community process and adjust to community priorities. 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.
Volunteers usually select a development item because of interest in
the particular item. For employees, the item is usually selected by
the company. This can lead an employee to work in an unfamiliar area
of the code, or with concepts that might be too complex. Ideally companies
can assign tasks to developers with a natural aptitude.
Also, sometimes what the company wants and what the community wants
are different. Often the community wants a more sophisticated implementation
that requires extra work from employees, or the company wants a feature
that the community does not. In these cases, either the company has
to adjust to the needs of the community or develop without community
Employees usually circulate their proposals inside their companies
first before sharing it with the community, or don't share it with
the community at all. By not showing the community the proposal, the
employee is not benefitting from community oversight and suggestions,
often leading to a major rewrite when a patch is submitted to the
Another problem with proposals is that because they have gone through
a company process first, they are often long and complex. When submitted
to the community, developers often forget how difficult it is for
new people to understand the proposal. Without summary material, people
who have not been dealing with this proposal for months cannot easily
understand its concepts. While the community is a wealth of knowledge,
proposals must be simple and clear, starting with general concepts.
Most community members do not have the time to wade through a long
proposal unless they can understand its major concepts quickly.
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 pre-screening patches is that
it prevents parallel review, where the company and community are both
reviewing the patch. Parallel review speeds completion and avoids
Once a patch has been committed, it has passed full community review
and is being tested by the entire development community. At this point,
the patch is likely correct and can be included in proprietary software
with minimal risk. The patch will also be maintained by the community
from release to release.
As you can see, community involvement has unique challenges for company
employees. There are often 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.
A typical case is a project that starts as community driven, but because
the community requires additional changes for acceptance, or because
the company needs the functionality sooner than can be accomplished
using the community process, the company decides to develop on their
own, with the intention to return later to the community process.
The switching in and out of the community process can make development
decision-making very difficult. Once outside the community process,
development can stray farther and farther from community standards,
making it impossible to re-enter the community process without major
refactoring. The community might also develop similar functionality,
making it difficult for the company-specific functionality and the
community functionality to co-exist in the same code base. Consider
these risks when deciding if development is to be done with or without
Company and community priorities can diverge, so companies should
expect to do some additional work to meet the broader goals of the
community. The good news is that this extra work often yields major
benefits. An open source community is made up of a world-wide pool
of talented developers. The group is so large and communicates so
effectively that a company would be hard-pressed to duplicate the
efficiency of such a community. For these reasons, even though the
community process can seem complicated and rigorous, it usually does
yield superior code to that developed inside a company. Hopefully
this will benefit the company, and will justify the additional work
required to work within the community process.
Open source communities succeed because developers are willing to
share their hard work with others. While volunteers dominate most
open source projects, companies also have to work like volunteers,
doing extra work beyond their immediate company needs. That extra
effort, textquotedbldonatedtextquotedbl to the community, benefits
all users, and makes the software more useful. Companies effectively
working with open source communities understand this dynamic and find
developing with the community to be a rewarding endeavor.
textitsmall Creative Commons Attribution Licensehfillhttp://momjian.us/presentations