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 involvement.
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 community.
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 unnecessary refactoring.
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 the community.
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, "donated" 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.
https://momjian.us/presentations Creative Commons Attribution License