Control, transparency, and customer contributions to open source
The more you seek to control a project, the less successful it will be in encouraging outside contributions, finds a new study
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.