Co-opetition in the Open Source World

Can there be a happy marriage between for-profit Information Technology companies and volunteer developers? Consider the following situations that occurred over the past few years and the questions they raised:


Can there be a happy marriage between for-profit Information Technology companies and volunteer developers? Consider the following situations that occurred over the past few years and the questions they raised:

  • Netscape released the source code for the Communicator browser and initiated a new style of open source project — one sponsored and supported by a for-profit corporation. Was this truly an open source project or just a way for Netscape to take advantage of volunteer labor?
  • IBM decided to replace its internally-developed Web server technology with the Apache Web server, basing its future Web application products on Apache and seeking to have its corporate developers join the Apache project. Does IBM want to work with the Apache project or exercise power over it?
  • Many key developers in the GNOME project quit working as volunteers and joined (or even founded) for-profit companies creating products and services related to GNOME. The project then issued joint press releases with Sun and other major IT vendors. Were GNOME developers still working for a non-corporate project or had GNOME essentially become a vendor consortium that promoted the interests of its corporate participants?

These are just three examples that illustrate the perceived conflicts of interest that can result when the two worlds of for-profit IT vendors and volunteer open source developers increasingly intermingle.

In some people’s eyes this is a simple “community vs. corporation” battle — how the “community” balances spreading the ideals of open source and free software while avoiding a “sellout” to the corporations it is trying to evangelize. In reality, this is not a battle situation at all, but instead a classic example of “co-opetition,” where companies that compete for business cooperate on mutually beneficial projects and activities.

“Co-opetition” Grows Up

This concept has become more complex and more interesting in the realm of open source software development, which can include individual developers and non-profit players like the Free Software Foundation (FSF). This can lead to the alliances among commercial firms and non-commercial development communities. To further cloud the issue, these development communities might include, or even be led by, employees of the commercial firms.

Thus, in the GNOME project, traditional IT vendors (Sun, HP, and IBM), newer “open source vendors” (Red Hat, Eazel, and Helix Code), individual GNOME hackers, and the FSF are working together in an effort to more quickly extend Linux to the desktop.

This new world of “co-opetition” raises a few important questions:

* How can companies sponsoring open source projects work with individual volunteer developers and not leave them feeling exploited?

Netscape pursued two parallel strategies. First, it tried to deliberately distance the open source project from the corporate development effort (e.g., by giving it a separate name, Mozilla, and a dedicated team of supporters, mozilla.org); in this way, participants could feel they were working for the project and not specifically for Netscape.

At the same time, Netscape gave Mozilla contributors access to information and other aspects of the project previously reserved only for employees. Netscape recognized that contributors and employees would not be satisfied without having some measure of control over variables that affected their work. While there is still some tension between the Mozilla project and Netscape’s commercial product development efforts, many open source developers have chosen to contribute to Mozilla development and perceive themselves as having a stake in the project’s success.

* How can a corporation partner with, and have some influence over, an existing open source project?

IBM’s first, and perhaps most important, step was to understand that the Apache project should be thought of as a potential business partner — one to be wooed and negotiated with, not simply a collection of developers to which IBM would add its own people. The result was a set of terms and conditions under which IBM could join the Apache project, with individual IBM developers being “invited in” as they proved their competence and dedication to the project’s goals. By forgoing an attempt at short-term dominance within the Apache project, IBM was able to acquire a substantial measure of long-term influence.

* What issues arise when an all-volunteer project goes “pro”?

As more and more key GNOME developers aligned themselves with commercial GNOME-related ventures (Helix Code, etc.), the GNOME project might have become a battleground for competing corporate interests. This shift might have threatened GNOME’s status as an independent project, in perception if not reality.

By initiating formation of a formal GNOME Foundation last August, the GNOME hackers helped ensure that the project would continue as an effort independent of any company or group of companies. Project leaders strengthened the legitimacy of their position by submitting to democratic elections open to all GNOME contributors. Finally, by limiting the formal power of GNOME Foundation “corporate partners” to simply providing advice, the GNOME community helped ensure that corporate influence over GNOME would be mediated through individuals deemed worthy.

* What will happen next in the ongoing dance of co-opetition among open source projects and commercial companies?

One emerging trend is particularly intriguing; despite business’ perceived role as the driving force in the “new economy,” corporations and individuals involved in open source development seem to be rediscovering some traditional functions of politics and government: managing conflict among multiple parties of different interests and beliefs, serving as a counterweight to raw economic power, and increasing the perceived legitimacy of those with authority to make decisions that are binding to everyone.

There are tradeoffs as well as checks and balances in this new order. By adopting open source licensing, corporations give up some control over distribution and use of their software. They trade this for the benefits of wider adoption and free enhancements of their software. Similarly, by encouraging the formation of separate “.org” bodies for the open source software they release, and by encouraging their developers to work within the rules set by such organizations, corporations are ceding some power over their own development projects. Simultaneously, individual developers may find that working within a formal structure provides their actions with legitimacy as representatives of their employers.

Some may object that democracy has no place in software development projects, stating they should instead be run as pure meritocracies. However, the power to vote within these projects is not necessarily open to everyone; typically, only those who can claim a significant investment in and contribution to the project carry power. In any case, the heterogeneous nature of the community means that different projects will be free to experiment with different models of organization, just as different states and countries have different governments and constitutions; some projects will have elaborate, formal models of authority, and others will have simple, informal ones. Each project will adapt to its own local conditions and requirements.

Co-opetition: The Next Step in an Ongoing Evolution

This is simply another step in the ongoing evolution of the open source community. Although people worry about the dangers of the open source community being “corporatized,” the open source movement has been corporatized since Netscape’s original announcement and business’ subsequent enthusiasm for Linux, GNU, and other software. People also worry about the danger of open source being politicized, but political differences have existed since the days of the “GNU Manifesto.” Politics, in one form or another, will continue to play a role in the open source community as long as there are competing interests and disparities in relative power within projects.

We can’t go back to some remembered time of innocence; we need to instead move forward and find ways in which individuals and organizations (both for-profit and non-profit) can work together for mutual benefit. Different parties will not always agree and will certainly not always get what they want. However, collaboration is the key to the long-term goal of the open source model prevailing over the proprietary software model, truly changing the way software is developed.

Frank Hecker is Leading Licensing Expert at CollabNet and a mozilla.org member. He can be reached at frank@collab.net.

Comments are closed.