1 INTRODUCTION
3.3 The inclusion of firms, public sector organizations and end-users
This section deals with some empirically based critique that has been leveraged in relation to the bazaar-model presented earlier. It explores the bazaar model in the light of hybrid open source and end-user organizations.
Firstly, the bazaar model as an ideal and idealized democratic type of gover-nance and organization does not acknowledge the existence of power relations in technology development. Raymond’s rather romantic view portrays open source communities as devoid of hierarchies and centralized mechanisms of power (Ducheneaut, 2005, p. 324; see also Bezroukov, 1999a, 1999b; Fitzge-rald, 2006), and thus fails to address difficulties, failures and aborted projects26. Research has shown that even the Linux project has a hierarchical structure:
Linus Torvalds and his trusted hackers had the power to decide which patch contributions to accept and which to reject from the large pool of peripheral user-developers (Moon & Sproull, 2002; Tuomi, 2004). Furthermore, a small group of contributors are responsible for the largest amount of contributed code, while a large pool of peripheral contributors develops the smaller portion (e.g.
Prakash, 2000). Krishnamurthy (2002) states that FLOSS projects are not typi-cally team-based at all. Of the 100 projects on SourceForge that he studied, he found a large number of one-developer projects and small developer teams.
Moon & Sproull (2002, p. 383) have underlined that Linus Torvalds's manage-ment decisions and skills were just as important as his technical competence in the development of the Linux community.
O'Mahony & Ferraro (2007) examined the relationship between meritocracy and bureaucracy in the Debian community by analysing how the community created a shared basis of authority and governance over a 13-year period. In the beginning developer-users valued technical contributions. As the project ma-tured, they increasingly valued organization-building contributors. O’Mahony
& Ferraro (2007, p. 1083) argue that meritocracy and bureaucracy are not mutually exclusive when understood from a change perspective and suggest an emergent and context-dependent notion of meritocracy, underlining that demo-cratic mechanism can serve an important adaptive function in new organization-al forms. As Weber (2004, p. 259) has aptly noted, open source communities unquestionably have hierarchical elements but they are not based on an authori-tative command structure as in bureaucratic organizations. In this sense they differ from traditional organizations.
The second critique is historically grounded. Due to the shift from hacker projects to hybrid firm-community projects, the ideal Linux bazaar model no
26 Chapter 6 examines a failed OpenOffice.org sub-project.
27 longer seems an adequate explanation. As a result, different attempts to charac-terize firm-community relationships have emerged. Dahlander & Magnusson (2005) studied four different cases in order to understand how different firms approached the company-community relationship. They found three distinct approaches: 1) symbiotic, in which both the firm and the community gain from collaboration; 2) commensaltistic, in which the firm gains and the community is indifferent; and 3) parasitic, in which the firm gains and the community loses (p. 487). Managerial challenges in such community-related activities had to do with norms and values, handling the different licenses required, attracting not only customers but also developers, allocating resources for community devel-opment, aligning different interests about the nature of the work, resolving ambiguity about control and ownership and avoiding conflicts (p. 489–490).
Dahlander, Fredriksen & Rullani (2008, p. 117) argue that firms often partici-pate in online communities as the protagonist of a single community.
The third critique is related to taking the core-periphery structure of Linux as the starting point for understanding the organization and division of labour of open source projects (e.g. Crowston, 2005; Crowston, Wei & Howison, 2007, Berdou, 2007). The open source development community has been characte-rized as having a hierarchical or multi-layered onion-like structure (Crowston &
Howison, 2005). Instead of the core-periphery distinction, Crowston & Howi-son (2005) found four layers. At the centre of the onion are the core developers, who contribute most of the code and oversee the design and evolution of the project. The next layer comprises the co–developers, who submit patches that are reviewed and checked in by the core developers. Further out are the active users, who do not contribute code but provide use-cases and bug-reports as well as testing new releases (Freeman, 2007; Berdou, 2007). Further out still, and with a virtually unknowable boundary, are the passive users of the software, who do not speak on the project’s lists or forums. (Crowston & Howison, 2005). Berdou (2007) on the other hand, studied a community-driven hybrid open source project, “Gnome”,27 and found that peripheral non-coding contribu-tors (translacontribu-tors, document writers etc.) formed a kind of “autonomous peri-phery” marked by different aims, priorities and rhythms of participation than those of the code developers.
Hence, hybrid projects complicate the division of labour and the core-periphery divisions by bringing into play new members (Freeman, 2007; Siltala
& al., 2007). Hence, in addition to redefining the notions of core and periphery, the boundaries of firm and community also need to be re-examined. As we will see, the core-periphery, as well as the developer-user distinction, can prove even more complex and more power-led in commercially driven hybrid projects like
27 My colleague Juha Siltala also studies the Gnome project in his doctoral dissertation.
28
OpenOffice.org (see Freeman, 2005; 2007, forthcoming). What also seems to be missing from the corpus of hybrid open source studies is the question of inclu-sion in and excluinclu-sion from the community. How do the volunteers articulate community boundaries, and how does the paid OpenOffice.org management strategically construct the “community”. The forthcoming analyses will also show how community membership and community membership categories change over time and are closely connected to the transformation of open source on the societal level.
When we move closer to actual end-user organizations, the core-periphery relation gets even more complicated. A central question is how the visions of democracy, user freedom, and transparency by means of open code, are realized in organizations producing and using open source? While I acknowledge that most end-users will not need to access source code, it is essential that users have the freedom to choose their own software tools. Research on open source and the public sector has focused on IT managers’ attitudes towards the (possible) adoption of open source mostly by means of surveys (e.g., Berry & Moss, 2006;
Glott & Ghosh, 2005; Varian & Shapiro, 2003; Välimäki, Oksanen & Laine, 2005; West & Dedrick, 2005). A potential shortcoming is that these studies tend to exclude from their analysis the power relations between the actors involved.
Those who have addressed the implications of open source use for the realiza-tion of democracy and extended public participarealiza-tion (e.g., Berry & Moss, 2007;
Ghosh at al., 2007; Perry & Fitzgerald, 2005) have taken a somewhat uncritical pro- open source stance. Since many researchers have suggested that technology is inherently political (e.g. Winner, 1985; Berry & Moss, 2007; Van den Boo-men & Schäfer, 2005), studying the power struggles involved in open source adoption would seem a valuable exercise if its empowering possibilities were to be understood.
While technologies enable and open up possibilities, they also establish boundaries and constrain our actions (Winner, 1985; 2009). In other words, the
“same” technology can have very different consequences for different people.
For instance, for one person it can mean more freedom at the expense of others’
freedom. As I will show in the forthcoming analyses, freedom and control in technology development and use are two sides of the same coin. Wherever there are people involved, there are also bound to be power struggles and opposing interests. Chapter 8 clarifies the relation between public sector end user organi-zations and the wider open source “community”.
29