Organic vs Synthetic Open Source Communities

From P2P Foundation
Jump to navigation Jump to search

Description

West and O’Mahony:

“West and O’Mahony (2005) distinguished between individually-founded and organizationally-founded open source communities, designating the former as “organic” and the latter as “synthetic”. These distinctions emphasized the different character of these two types of community founders and their prospective growth strategies. While organic projects are founded by individuals and grow through grass roots communications, synthetic communities are founded by corporations and grow with more strategic direction. Since communities can evolve along different trajectories after their founding, in this paper, we refer to autonomous and sponsored communities to focus on their current governance structure (cf. Markus, 2007; O’Mahony, 2007) as opposed to their founding state. For example, a synthetic community could begin as a sponsored community, but evolve to become fully autonomous – as was the case with Netscape’s release of Mozilla and its subsequent transition to independence. By using the categories of autonomous and sponsored, our aim is to provide a more precise categorization to help scholars examine open source communities over their lifecycle.”

(http://www.joelwest.org/Papers/WestOMahony2008-WP.pdf)


Discussion

Why is the distinction important

Why is the distinction organic / non-organic so important?

" at the end of the day, the most crucial issue is the development community. It is the strength and the diversity of the development community which is the best indicator for the health and the well-being of an Open Source project.

But what about end-users, I hear people cry? End users are important, to the extent that they provide ego-strokes to the developers, and to the extent that they provide testing and bug reports to the developers, and to the extent that they provide an economic justification to companies who employ open source developers to continue to do so. But ultimately, the effects of end-users on an open source project is only in a very indirect way.

Moreover, if you ask commercial end users what they value about Open Source, a survey by Computer Economics indicated that the number one reason why customers valued open source was “reduced dependence on software vendors”, which end users valued 2 to 1 over “lower total cost of ownership”. What’s important to commercial end users is that they be able to avoid the effects of vendor lock-in, which implies that if all of the developers are employed by one vendor, it doesn’t provide the value the end users were looking for.

This is why whether a project’s developers are dominated by employees from a single company is so important. The license under which the code is released is merely just the outward trappings of an open source project. What’s really critical is the extent to which the development costs are shared across a vast global community of developers who have many different means of support. This saves costs to the companies who are using a product being developed in such a fashion; it gives choice to customers about whether they can get their support from company A or company B; programmers who don’t like the way things are going at one company have an easier time changing jobs while still working on the same project; it’s a win-win-win scenario.

In contrast, if a project decides to release its code under an open source license, but nearly all the developers remain employed by a single company, it doesn’t really change the dynamic compared to when the project was previously under a closed-source license. It is a necessary but not sufficient step towards attracting outside contributors, and eventually migrating towards having a true open source development community. But if those further steps are not taken, the hopes that users will think that some project is “cool” because it is under an open-source license will ultimately be in vain. The “Generation Y”/Millennial Generation in particular are very sensitive indeed to Astroturfing-style marketing tactics." (http://thunk.org/tytso/blog/2008/04/26/organic-vs-non-organic-open-source-revisited/)


Autonomous vs. Sponsored

West and O’Mahony:

“We define an autonomous open source community as one that is presently independent of any one firm and community managed (cf. O’Mahony, 2007). A community-managed governance system operates outside the reach of authority embedded in employment relations. Contributors to an open source project may be volunteers or may be paid by their employers to work on the project, but decision-making on the project takes place independently from the employment structure that guides the workplace. These projects may be supported by a non-profit foundation created specifically to support the project, but such foundations have little authority over their members (O’Mahony, 2005).

A sponsored open source community is one where one (or more) corporate entities control the community’s short- or long-term activities. To refine these distinctions, in thus study, we examine how sponsors approached the task of building an open source community and how these communities differed from their autonomous counterparts.” (http://www.joelwest.org/Papers/WestOMahony2008-WP.pdf)

See also: Autonomous vs Sponsored Open Source Community

Source

Article: The Role of Participation Architecture in Growing Sponsored Open Source Communities. By Joel West (San Jose State University College of Business) and Siobhán O’Mahony (UC Davis Graduate School of Management) February 6, 2008 preprint version of Industry and Innovation, Special Issue on “Managing Open Innovation Through Online Communities”

URL = http://www.joelwest.org/Papers/WestOMahony2008-WP.pdf