Control, transparency, and customer contributions to open source

Joel West, professor at San Jose State University College of Business, and Siobh?n O'Mahony, professor at UC Davis Graduate School of Management, have produced some insightful research over the years. However, I particularly like a new academic study the two recently released: "The Role of Participation Architecture in Growing Sponsored Open Source Communities." It studies why developers contribute to certain open-source projects and don't contribute to others.

The key? If you want outside participation, you need to deliver more than mere transparency: Developers need to be able to change the direction of the project to make it worthwhile to stick around. (For a quick example of how too much control can stifle a community, take a look at Sun and OpenOffice.)

This is not surprising, but the research is helpful in detailing why this is so, and how firms cope with it. While most open-source projects attract little to no outside developer interest, corporate-sponsored open-source projects start with an implicit handicap by demanding control of the destinies of their projects:

By comparing the participation architectures that resulted from sponsors' design decisions, we identified two types of openness: transparency and accessibility ["Accessibility allows external participants to directly influence the direction of the community to meet their specific wants and needs"].

While transparency offered potential contributors the ability to follow and understand a community's production efforts, accessibility determined the degree to which external contributors could influence that production. In designing a community, sponsors were more likely to offer transparency than they were to offer accessibility to external community members.

We found that sponsors faced a control vs. growth tension. To leverage the ability of communities to contribute to their firm's bottom line, sponsors sought to maintain control over the community's strategic direction. However, sponsors soon discovered that by restricting access to community processes, they limited their community's ability to attract new members and grow.

In Cheers, "you want to go where everybody knows your name." In open source, developers want to go where they can exercise control over their code. Commercial/corporate open-source projects offer less of this opportunity unless you represent a customer-developer. The real question for commercial open-source projects for me is whether commercially involved participants - e.g., customers and partners - can be motivated to contribute code.

Red Hat CEO Jim Whitehurst has called for more enterprise (read: customer) participation in open-source communities, and I think he's dead-on. This is the untapped market for contributions to commercial open-source projects. Not only are enterprise customers using open source in ever-increasing amounts, but they also may well prefer the control (and legal cover) of a commercial open-source project.

The next question is how to structure code contribution policies to favor this class of developer. Given the relative dearth of organic code contributions in any commercial open-source project, even when doing everything right to encourage contributions, we should be willing to experiment with new models. The old models that follow Apache, Linux, and other community-driven open-source projects have not worked for commercial open-source projects. Let's figure out new ones.

[jrepenning]

Unfortunately, this study only goes so far as to interview community leaders as to why they made the decisions they did. As the study itself concludes, it would be interesting to see if these decisions actually produced the expected results. There are hints here that they do not. For example, it's common belief that the right to contribute code (what this study calls "accessibility") helps to grow the community. But the study points out that MySQL involves very little accessibility (more because a production-grade relational database server is HARD than any explicit policy), yet the MySQL community is extremely active (judged from mail list activity), both in user and developer areas. Explore at http://mysql.markmail.org/

[joelwest3]

Matt,

Thanks of course for the mention.

As for enterprise participation in OSS, I agree in principle but I wouldn't hold my breath. Kai Jakobs of RTW Aachen has been studying firm participation in standards for 15+ years and nothing changes: users rarely invest the time and the vendors don't want to share power with them anyway.

JRE, the academic lead time for publishing is long -- this project started in 2004 and much of the data compilation ended a couple of years ago. So my interview with MySQL did not emphasize outside contribution. Thanks for the pointer to the discussion groups because at least patch activity seems relatively high on these sites.

Joel West
www.joelwest.org