Not Your Ordinary Communities and Contributions

Few terms are more central to the free and open source ("FOSS") movement than "community" and "contribution." The common definitions of these terms are:

Community: a unified body of individuals as - a state or commonwealth; the people with common interests living in a particular area; an interacting population of various kinds of individual in a common location; a group of people with a common characteristic or interest living together within a larger society; a group linked by common policy; a body of persons or nations having a common history or common social, economic, and political interests; a body of persons of common and especially professional interests scattered through a larger society.

Contribution: a payment (as a levy or tax) imposed by military, civil, or ecclesiastical authorities usually for a special or extraordinary purpose; the act of contributing; the thing contributed

But these terms mean so much more in the context of FOSS. Anyone who sponsors, participates in or contributes to a FOSS project needs to understand not only the importance of these terms, but also how their meaning has changed over time.

Starting Point
The community is the core of any FOSS project. Consistent with the common definition, a FOSS community has traditionally been a self-defining group of people and organizations that share the common value of exchanging ideas and intellectual property in the pursuit of creating the highest quality software using an open development model. Until recently, there has been little need to define the community in any greater detail because membership was open to all and carried no obligation to participate, which resulted in the attraction of like-minded participants.

FOSS contributions have traditionally come from individual developers and companies alike. They typically included any materials submitted to the project under a standard set of terms commonly accepted and understood by the community. Again, because the community traditionally shared common values, there has been little confusion as to what constitutes a contribution and what the receiving FOSS project could do with it.

Where Are We Now?
With the growth of the open source movement, the concept of free software has taken on competitive and commercial traits, which has impacted the meaning of "community" and "contribution." Those who sponsor or participate in FOSS projects need to take note of the changes.

In the case of communities, we can no longer assume that the FOSS project sponsor and participants share common values. At a minimum, sponsors and participants might be divided between those that advocate for pure free software principles, and those that use the community for purely strategic purposes in support of a commercial advantage.

The nature of contributions has also changed. Some FOSS project participants might contribute for the purpose of advertising an alternative product or fork, or to incorporate code allowing for easier integration with a commercial product. In addition, the traditional "anything submitted" contribution model, which promoted free exchange of ideas and is the most beneficial to the community as a whole, is less relevant. More recent contribution models include the option for contributors to declare which of their submitted materials are deemed not to be contributions. The legal terms that apply to contributions are sometimes also subject to the influence of commercialization by being narrowly focused on the sponsor's objectives to the detriment of the community's needs as a whole.

How Should FOSS Project Sponsors Respond?
FOSS project sponsors (whether non-commercial or commercial) should carefully consider how to respond to this evolution in the meanings of "community" and "contribution". They should spend more time defining their FOSS goals, more closely monitor FOSS activities and contributions, and implement measures that will further their goals and ensure that the appropriate elements of the community work in their favor.

Specific actions for consideration by FOSS project sponsors include:

• Posting a definition of goals for content, community and participation. This might include a statement of purpose for the project, a definition of community values, and a code of conduct for participants.
  

• Creating separate discussion boards and mail-lists for contributions in support of the project, general discussion about the project without contribution, and discussion of other projects or any other matters not related to the sponsored project.

• Monitoring contributions and discussions to ensure that they are posted to the proper boards and lists, and to ensure that contributions do not contradict the applicable participation model and community values.

• Avoiding alienation of participants even if they appear to contradict community values. For example, even when a project participant uses a project discussion board to promote its own commercial activity, the sponsor should first decide whether to object to that practice. If it chooses to object, it should do so in a way thatfosters inclusion and participation in a rational, pro-community manner, while minimizing the perception that the sponsor is hindering project discussion or participation.

• Treating conditional contributions (i.e., contributions made under terms other than the sponsor's standard terms) as invitations for negotiation to be handled in the same manner as other commercial inbound licenses. Sponsors should not grant exceptions to conditional contributions because that risks contradicting community expectations and undermining the purpose of the project.
  

• Weighing a number of factors when faced with a choice between accepting a conditional contribution or not obtaining any rights to the contribution at all. Specific considerations include: the value of the potential contribution; the scope of rights offered; consistency with the sponsor's commercial strategy; consistency with community values and expectations; perception in the community; and consistency with free software principles. An assessment of these factors could lead to a number of outcomes from a decision that the contribution will not be part of the project, to a decision by the sponsor and contributor to enter into a commercial relationship.

From User to Contributor

As open source software becomes more widely used, the flow of contributions back to open source projects become more important. Contributions back to an open source project are not only an indicator of the health of a particular project's community, but they are critical to ensure these projects are able to grow and realize the benefits of community involvement. Matt Asay noted in a recent Open Road Blog posting, a lack of contributions from enterprises "may have serious, negative consequences for the long-term health of the open-source ecosystem."

A recent article by Dan Woods in Forbes explains that this is the result of a gap between the "enlightened self-interest" of individuals who contribute for their own benefit, and institutional collaboration, which is "much lower than expected and hoped for, based on patterns of individual participation." While the Forbes article provides some excellent background on the problem and how we reached this point, I would like to dig a little deeper into the reasons why enterprises don't contribute, and what changes are needed to encourage more contribution.

Enterprises (primarily for-profit corporations, but also government entities and foundations) often have few incentives to contribute to open source projects, and many incentives to not contribute. At a fundamental level, the traditional thinking of enterprises has been that ownership of intellectual property is an important part of preserving corporate assets. Though the open source movement is changing these views, ownership and tight control has also traditionally been seen as crucial to preserving a competitive advantage. In addition, enterprises often suffer from the failings of bureaucratic organizational structures, which make the process of obtaining the multiple layers of necessary approvals for release of intellectual property rights difficult if not impossible. Finally, another basic concern of for-profit enterprises is that any time spent on open source projects is time taken away from core, for-profit activities.

No doubt the above described bias against open source contribution is the product of short-sighted thinking. While we should not expect that enterprises would change their position on openness in a short time frame, we can propose short-term, high-impact fixes that quickly and strongly demonstrate the benefits of open source and encourage more openness. Some specific examples include:

• Appeal to employees of enterprises to voice their desire to participate in open source projects, and use resulting the groundswell of employee requests as a way to incent enterprises to develop a well-reasoned participation policy rather than perpetuating ad-hoc or unknown participation.

• Create model policies that enterprises can easily adopt to permit employee participation and facilitate enterprise contribution, with an emphasis on the benefits of participation over the traditional focus on ownership and control of IP rights.
  

• Clearly demonstrate cases in which contributions create a win-win situation for enterprises and communities, possibly in a public white paper format.
  

• Begin with the low-hanging fruit: contributions related to internal IT infrastructure components rather than contributions that are perceived to compromise competitive advantage; tackle the issue of contributions related to competitive-advantage at a later time after the benefits of contribution are clear.

• Acknowledge that strategic and competitive situations might exist that warrant withholding or delaying making contributions, while emphasizing that it is a rare case when choosing not to contribute is the best course.

Some of these are aspirational, but the underlying themes are important: (1) Every technology company has a massive base of employees who are interested, if not heavily involved, in open source, and these employees can be the agents of change within enterprises. (2) Enterprises need to better understand the economic and other benefits of contribution, and the lessening importance of ownership and control of IP rights. (3) This movement should occur incrementally by starting with the types of projects that are least likely to encounter the traditional organizational resistance.

These changes will happen on their own over time, but we can establish an environment that encourages enterprises to speed progress. At stake is the ability for open source projects to survive and reach the critical mass necessary for all community members to realize significant benefits of the open source movement.