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.

Relationships Matter

After a couple of postings focused on the state of the open source business, I would like to pick up the theme of earlier postings concerning fundamental legal considerations for open source businesses.

Good businesses are built on good relationships ... relationships with customers, partners, and employees. Open source companies have another important relationship to consider ... the community. In the spirit of the old adage "good fences make good neighbors," contracts, instead of wood or brick, help keep good relationships from going bad. While contracts are well accepted in customer, partner and employee relationships, they are not as effective in a community relationship. Whether through contracts or other means, open source companies must address the unique demands they face in balancing their profit motives with open source ideals.

The most fundamental of all business relationships is between vendor and customer, and standardized contracts are a well-accepted means of describing the expectations of these parties. While the commercial contracts of open source companies are generally the same as for proprietary companies, certain virtues of the open source development model allow open source companies to sidestep or minimize the many traditional commercial software contract clauses. For example, the availability of free software before purchase often makes customers less worried about issues like evaluation licenses, performance and ownership warranties, broad indemnification rights, and licensor liability obligations.

Partner relationships of all sorts (marketing, distribution, inbound licensing, joint development, etc.) also are commonplace in the open source business and typically addressed through standardized contracts. Because partners, like customers, can get the value of open source software without paying for it, open source companies must present additional value (such as marketing or referral benefits) compelling enough to entice partners to enter into agreements that provide adequate protection. Specific clauses might include prohibitions on forking the code or creating an unauthorized solution, or an obligation that a partner's solution must always be available under an open source license.

Employees are the most important assets of any technology business. As a result, employment agreements, related agreements governing ownership of inventions created by employees, and confidentiality agreements are regularly used. The traditional templates for these types of agreements are, however, at odds with the open source ideals of community participation because employees of open source companies are also members of the community. As a result, open source companies must challenge themselves to rethink the traditional scope of employer ownership rights and level of oversight in employee participation in outside projects and implement appropriate legal agreements and company policies. This type of flexible approach also has the benefit of being a great tool for recruiting potential employees from the community.

A community relationship is different than the other relationships above in that an open source company can't rely on a contract to set expectations ... the community has no single point of contact that can enter into contracts, and the relationship is based on a constantly evolving application of open source principles as well as trust established over time. However, a company's contributor agreement, the one important community-oriented legal agreement, should reflect community ideals such as by granting contributors joint ownership or broad usage right in contributed code. The community also looks to a company's position on patents as an indication of open source friendliness so a carefully considered patent policy is important see my previous post on patents for more on that). In general, open source companies need to establish a clear business strategy that incorporates open source principles, and be able to clearly and tactfully articulate why the community should accept a particular business decision even when it might conflict with open source ideals. Decisions as to when and how to enforce violations of open source licenses, or when to introduce closed source code into an open source solution are among of the most difficult for the community to accept, but a strong community relationship will help.

Each of these 4 relationships are vital to the success of an open source business. While contracts can play a primary role in open source companies and their customers, partners and employees being "good neighbors," the community relationship, by its very nature, is less predictable and requires trust along with the proper balance between sincerity in honoring open source principles and conviction on business strategies that might be seen as contradicting open source values.

Commercial vs. Free: Not a Zero Sum Game

Think back to 1991 and the release of GPLv2 ... the open source software community was abuzz with great anticipation that the goals of the "free software" movement would soon be achieved. Now fast forward to present day ... the open source software business is potentially worth as much as $60 billion, a small Linux provider named RedHat has grown into a successful public company, and an open source database company named MySQL has been purchased by Sun Microsystems for $1 billion. Does this prove the success of the commercial open source movement? Of the failure of the free software movement?

If the recent firestorm in the community over Sun's proposal to sell closed-source add-ons for the open source MySQL database is any example, then the open source community appears to have concluded that the success of one is only at the expense of the other. (In the interest of full disclosure, I am a MySQL/Sun employee, and these opinions are mine alone.) The community would rather punish MySQL, one of the pillars of open source movement, than applaud the prominence it has helped bring to open source through its innovative open source and business strategies.

This "zero-sum" attitude is not only wrong, but also harmful to the open source industry. Instead, the open source industry must accept that both open source purists and commercial opportunists can co-exist in the same environment without forcing an absolute choice between them. Though it appears more open source "rationalists" are reaching this conclusion, the community needs to start acting based on what is good for open source as a whole, not just the purist forms of open source.

The viability of this type of co-existence is well proven in other contexts. Take the example of environmentalism and the "greening" of the business world. Groups like the not-for-profit Sierra Club operate on the same playing field (though at the opposite end) as companies that use the "green" label as an insincere marketing ploy (I won't point any fingers). The business world accommodates this range of diversity allowing groups interested in societal change to organize as not-for-profit entities, which allows them to focus on their chosen area of social good without being subject to income tax. Entities like the Apache Foundation, Linux Foundation and Free Software Foundation play this role in the open source world by focusing on open source for the public good (and get a tax relief too).

At the same time, though commercial entities are primarily motivated by profits, the community pushes them to be "good citizens". We see the pressure the community puts on companies these days to pursue environmentally friendly policies in spite of (or sometimes in support of) their profit motives. Similarly, commercial open source companies perform good citizenship by acting in support of open source ideals, which not only builds community goodwill but also allows them cash in someday.

To make this drive to good citizenship most effective, communities need a way to differentiate commercial entities by evaluating them both their effectiveness and sincerity in pursuing. Many environmental groups act as watchdogs and standard setters for their commercial counterparts. Similarly, the open source community has taken a new focus on improving upon the traditional benchmarks of open source (choice of an OSI approved license and release of copyrighted code) with proposals to include patent and trademarks as well as business and development models in the standard definition of "open source". Another proposal is the creation of an independent body that would objectively grade companies on their "openness". While these are great solutions, they are not likely to reach their potential for effectiveness until we all recognize the importance of co-existence.

Just as we don't hold commercial entities to the same standard of environmental purity as we do the Sierra Club, the open source community must strike the right balance between pursuing its passion and pushing commercial open source companies to act in "acceptable" ways. It must not forget that open source advocates, and good ideas that can further the open source movement, can come from virtually anywhere in the open source spectrum. While it's useful to distinguish between commercial open source companies based on openness, the community must begin acting as if we are all in this together. If we don't learn to co-exists, we risk an irreparable fracture in the movement that we all support.