The Janus Face of Commercial Open Source Software Communities

An investigation into institutional (non)work by interacting institutional actors

ANN WESTENHOLZ (EDITOR)

Copenhagen Business School Press

The Janus Face of Commercial Open Source Software Communities

An investigation into institutional (non)work by interacting institutional actors

Ann Westenholz (eds.)

© Copenhagen Business School Press 2012

Typeset and ebook production by Narayana Press

Cover design by Klahr | Graphic Design

1st printed edition 2012

1st e-edition 2012

eISBN: 978-87-630-9937-0

Copenhagen Business School Press

Rosenoerns Allé 9

DK-1970 Frederiksberg C

Denmark

Tlf: + 45 38 15 38 80

Fax: + 45 35 35 78 22

slforlagene@samfundslitteratur.dk

www.cbspress.dk

All rights reserved. No part of this publication may be reproduced or used in any form or by any means – graphic, electronic or mechanical including photocopying, recording, taping or information storage or retrieval system – without permission in writing from the publisher.

Contents

Cover

Title

Colophon

Foreword

1. Introduction

Ann Westenholz

1.1 A sociological approach

1.2 The structure of the book

Notes

2. Companies’ Involvement in Open Source Software Communities

Ann Westenholz

2.1 Historical development of software

2.2 Literature on companies’ involvement in open source software communities

2.2.1 Summary and reflections on the literature

2.3 Commercialization of open source software in Denmark

2.3.1 ‘Institutional entrepreneurs’ and the development of commercial open source companies in Denmark

2.3.2 Companies that are members of the Association of Open Source Suppliers in Denmark

2.3.3 The Association of Open Source Suppliers in Denmark

2.3.4 The software developer

2.4 Conclusion and reflection

Notes

3. TYPO3 – A Commercial Open Source Software Community

Ann Westenholz, Benedikte Brincker and Peter Gundelach

3.1 Introduction

Ann Westenholz

3.2 TYPO3 as an à la carte community

Benedikte Brincker and Peter Gundelach

3.2.1 The concept of community

3.2.2 Interaction and values in the TYPO3 community

3.2.3 An à la carte community

3.2.4 Summary and reflection

3.3 TYPO3 as a Community of Commercial Actors

Ann Westenholz

3.3.1 Summary and reflection

3.4 Institutional Work in the Development of the TYPO3 Community

Ann Westenholz

3.4.1 Interaction between a commercial actor and voluntary open source developers negotiating stories about ‘the customer-driven market’ or ‘the evil market’

3.4.2 Interaction between community members and commercial companies negotiating stories about ‘sharing knowledge’ or ‘not-sharing knowledge’

3.4.3 Interaction between TYPO3 companies and their customers negotiating stories about ‘reliable open source software’ or ‘unreliable open source software’

3.4.4 Summary and reflection

3.5 Institutional Non-work in the Development of the TYPO3 Community

Ann Westenholz

3.5.1 Clarifying the concept of ‘disordering coordination’

3.5.2 Disordering coordination within the TYPO3 community

3.5.3 Summary and reflection

3.6 Conclusion and Reflection on the Janus Face of the TYPO3 Community

Ann Westenholz

Notes

4. Nokia’s Involvement in Two Types of Open Source Software Communities

Malgorzata Ciesielska

4.1 The background and Nokia’s open source software strategy

4.2 The Maemo.org case: Nokia sponsoring a dependent open source software community

4.3 The GNOME case: Nokia’s involvement in an upstream open source software project

4.4 Conclusions and reflection on the Janus face of Nokia’s involvement in Open Source Software Communities

Notes

5. Conclusion and Reflection

Ann Westenholz

5.1 Companies’ involvement in open source software communities

5.2 Theoretical discussions within institutional organizational theory

5.2.1 Organizational responses to multi-institutional logics

5.2.2 Beyond micro/macro and actor/structure dimensions

5.3 The Janus face of commercial open source software communities

Notes

Appendix
Methods

Ann Westenholz, Benedikte Brincker, Peter Gundelach and Malgorzata Ciesielska

1. Commercialization of open source software in Denmark

2. TYPO3 – A commercial open source software community

3. NOKIA’s involvement in two different open source software communities: Maemo and GNOME

List of Concepts

List of References

About the Contributors

Foreword

In 2002, I visited a small IT company located in a private apartment in the Copenhagen area in Denmark. Four programmers were crammed into the apartment’s living room. I was going to interview one of them about his work as a temporary worker and they invited me to sit down in the middle of the room. The interview soon evolved into a common conversation about how the programmers developed their sophisticated software. They estimated that it would take a ‘normal company’ around one hundred employees to develop such software. They were only four people and they told me a story about how they did it by cooperating together with hundreds of voluntary or commercial programmers around the world, who were working with similar products. If they had a problem, they asked for help on the Internet and most often they got a constructive answer within 24 hours. If somebody asked them about a problem, they often helped them. This was a fascinating story about an open way of innovating commercial software, and I decided that my next research project should investigate how commercial open source software emerged and how it worked.

The opportunity came in 2005 and since then the research featured in this book has been conducted in collaboration between four researchers working at the Department of Organization, Copenhagen Business School (CBS) and the Sociological Department, University of Copenhagen. Our work would not have been possible without the support from our universities and the funding from the Danish Council for Independent Research, and we are very grateful for this support. We also appreciate very much all comments from many colleagues around the world, who took the time to discuss the analyses with us. We also want to thank Fiona Tod who proofread our texts. And most of all, we would like to thank all the people within the TYPO3 community and within the Nokia-related communities who so generously and trustfully let us into their worlds.

Analyzing the cooperation between commercial companies and open source communities within a sociological approach may be useful material for different readers. First, scholars and practitioners may be interested in understanding that the move towards commercial open source software development is not purely a rational choice, which can be calculated and anticipated. It requires a lot of institutional work by many interacting actors who have the awareness, skill, and reflexivity of dealing with multi-institutional logics in their working environment. These institutional actors are not only creating new institutions, they are also maintaining them. Second, scholars and practitioners interested in new open innovation models where companies only imitate ideas from open source communities, but do not cooperate with the communities, may reflect upon whether the disengagement is a sensible strategic choice or not. Could their resistance towards cooperation be a sociological resistance to ‘strange’ way of doing things? Third, the idea of commercial open source is not exclusively developed within software products. It is also discussed within other creative product development such as music and film, and the idea of transgressing institutional logics doing institutional work may also be applied on these areas. Fourth, scholars interested in theories of institutional actors engaged in institutional work may be interested in reading this book, as it unfolds and investigates the theoretical concepts in empirical settings. Fifth, scholars and practitioners interested in organizational responses to multi-institutional settings may find useful inspiration from the analyses in the book. Examples could be hospitals and universities changing from being embedded in professional logics, to being pressured to inculcate an instrumental logic of efficiency. Or it could be companies embedded in a logic of capitalism being pressured to inculcate a social responsibility embedded in logic of state democracy.

January, 2012

Ann Westenholz

1. Introduction

Ann Westenholz

What happens when commercial software companies begin to cooperate with voluntary members of open source software communities, and how does it happen? Finding answers to these two questions is at the head of this book.

To understand why this is an interesting issue to deal with we have to go back in time to the period where software development began. To cut a long story short, the development started in the U.S.A. in the 1950s, and over the following decades a global organizational field emerged: a community of organizations and individuals that subscribes to a common meaning system in which participants interact with one another more often and more faithfully than with actors external to the field (Scott 1994: 207/8). The field came to consist of a meaning system that perceived software as a technical device. To them, it was natural that software development took place within open innovative communities, in which professional developers and users shared knowledge about software products across private and public organizational boundaries. In the 1970s, private companies began to stage a different meaning system, which resulted in viewing software development as a commodity subject to proprietary rights. Within these two organizational fields – systems of meaning – different software products were developed. These two fields engaged in fierce political debates over how knowledge should be shared and money earned within software (Weber 2004): on one hand there was an organizational field that believed that software development should take place within open communities focusing very little (or not at all) on earnings; and on the other, an organizational field that considered it natural to commercialize and patent software. In popular terms, the two original fields may be called the ‘copyleft’ and the ‘copyright’ fields.1 In the 1990s, a third organizational field emerged supplementing and transgressing the meaning systems of the two original organizational fields. This third organizational field saw it as natural both to commercialize and to develop software in open source communities together with voluntary developers.

In figure 1.1 a timeline illustrates the development of these organizational fields.

Figure 1.1: The temporal development of three organizational fields within global software development

Weber (2004: 5) describes some core elements in the cooperation between companies and open source software communities, following the definition by Open Source Initiative2:

Source code must be distributed with the software, or otherwise made available for no more that the cost of distribution.

Anyone may redistribute the software for free, without royalties or licensing fees to the author.

Anyone may modify the software or derive other software from it, and then distribute the modified software under the same terms.

There are, however, many different open source software licenses and it is relevant to make a distinction between them: in some licenses you must make the source code available to anyone; in others you do not need to make a source code available to others if you only use it for internal organizational use; and in other licenses you can commercialize without releasing the source code.

From a sociological perspective, the development raises the interesting question of how people from the two original organizational fields began working together, when they viewed software development so differently: one arguing for a closed innovation business system as the appropriate way of developing software (the copyright field), and the other arguing for an open innovation community system (the copyleft field). As companies have got involved in open source software communities in varying degrees, the ‘how’ question is especially interesting when looking at companies who more or less integrate themselves as members on equal terms with voluntary developers in an open source software community. In this book, we analyze such a commercial open source community (the TYPO3 case).

Open source software communities used to be populated primarily with voluntary software developers, who were not working on the software in their role as employed developers in a company. Many studies have been conducted on the impact of these voluntary communities: how they are organized, and why a person would choose to contribute voluntarily to the production of a piece of software if the person instead could either earn money for the same piece of work or live as a free-rider in the community (for example, Bergquist & Ljungberg 2001; Bonaccorsi & Rossi 2003; DiBona, Ockman & Stone 1999; Edwards 2003; Feller et al. 2005; Hertel, Niedner & Hermann 2003; Koch 2005; Koch & Schneider 2002; von Krog & von Hippel 2003; Lakhani & von Hippel 2003; Raymond 1999; Weber 2004). In this book, we are not specifically dealing with these types of issues within voluntary open source software communities, but focusing on how and what happens when commercial actors get involved in open source software communities and cooperate with non-commercial voluntary software developers.

1.1 A sociological approach

Most studies of commercial companies’ involvement in open source software communities have dealt with the type of strategies applied by companies and their motivations for getting in closer contact with non-profit communities. These studies ask why companies get themselves engaged with open source software, and the scholars look for the different ways companies are making profit when engaging with open source communities. The studies often apply economic and technological theories to understand the development of why companies get involved, and a dominant assumption is that companies – at least in the long run – are making choices by means of logic of consequentiality (March & Olsen 1989: 23). These choices are assumed to be associated with anticipatory action, where companies know their values, investigate what the consequences of different alternatives are for their values – and then they choose the alternative that has the best consequences for their values.

In this book, we call upon an alternative and sociological approach to understand the development of cooperation between commercial companies and open source software communities. We do so as we assume that processes, in which actors are transgressing organizational fields and institutional logics or worlds, are characterized by a high degree of ambiguity where interests, motives, and strategies are not fixed. They are not calculative and they are not following patterns of action, which can be anticipated before they happen. Instead interests, motives, strategies, and worldviews are emerging. We are therefore calling upon studies that apply a social constructivist paradigm, in which people become situated within multi-institutional logics or worlds at the same time as they are striving to make sense of this multiplicity of institutional logics in their daily work life. This requires institutional work done by different types of interacting institutional actors. These concepts will be central to the book, highlighting that institutions are constituted in more or less conscious action of interacting with individual and collective actors.

In this sociological theoretical context, the title of the book ‘The Janus Face of Commercial Open Source Software Communities’ has a triple meaning. First, it refers to the fact that companies getting involved with open source software communities are embedded in different and often contrasting institutional logics: an institutional logic of capitalism and an institutional logic of technology. Second, it refers to the high degree of ambiguity the companies and communities are facing while dealing with these often contradictory institutional logics. Sometimes they blend different institutional logics and create hybrid material and symbolic practices (creating inter-logics practices) while, at other times, the institutional logics are kept separate resulting in different material and symbolic practices (creating multi-logics practices). Third, the theoretical analysis is pointing towards institutional theory as well as an (inter)actor-oriented theory, arguing that institutions are not ‘dead’ structures but inhabited by institutional actors doing institutional work while they interact with each other.

1.2 The structure of the book

The book is structured in such a way that theoretical reflections are merged with the empirical analyses in each chapter.

Companies’ involvement in open source software communities is discussed in chapter two. The analysis shows how commercial companies’ involvement in open source communities emerged from two contradictory institutional logics: the institutional logic of technology and the institutional logic of capitalism. Literature shows that the commercialization of open source software has emerged as a global phenomenon during the last 10-15 years, and that it comes in many variations and degrees: from companies only imitating and translating ideas from open source software communities to their own local contexts in the companies – to becoming full members of open source communities and participating in the development together with voluntary developers. Much of the literature has dealt with the type of strategies applied by companies and their motivations for getting in closer contact with non-profit communities, and these scholars try to figure out how companies may become a success as an open source software company. After the literature review, an empirical analysis of Danish commercial open source companies is conducted, which shows how many different institutional entrepreneurs are engaged in institutional work and in creating this new cooperation between companies and open source software developers. The end of the chapter discusses these results in relation to theoretical literature on institutional entrepreneurs.

In chapter three, a commercial open source software community – TYPO3 – is analyzed. TYPO3 is a unique example of the highest degree of company involvement in open source software communities, in the sense that companies today have become even more dedicated members of the community, compared to its many voluntary software developers. The companies’ involvement within the community is like a Janus face, which is nicely captured by Brincker & Gundelach in section 3.2 when they characterize TYPO3 as an ‘à la carte community’. One side of TYPO3’s Janus face is described by Westenholz in section 3.3, where it is shown that companies within the community share common stories about the TYPO3 community as a hybridization of the two institutional logics of technology and capitalism. This development is explained by the combination of different elements: it did not happen due to external pressure but due to inspiration from an external institutional entrepreneur – and captured by internal community actors defining themselves as the institutional audience relating to this institutional entrepreneur. Within the community, an institutional leader emerged theorizing change, following a script of appropriateness and identity construction within the community, and it may have influenced the process in such a way that practices become hybridized. If a script of consequentiality had been applied to the community, it would not have supported hybridizing practices since such a script defines the world in a rather one-dimensional way. In section 3.4, another side of TYPO3’s Janus face is revealed. On this side, companies get involved in the TYPO3 community without any shared common understanding of what the TYPO3 community is about. This happens when their activities are coordinated through: a) similar actions without reference to a common world or a common compromise, b) sequential attention to different worlds or logics, and c) loose couplings within the community where the members relate to the product but do it in different ways. It is suggested that both sides of the Janus face may be important for the survival of the community and that institutional leaders may have to engage in institutional work (creating common hybrid stories) as well as institutional non-work (leaving some contradictions untouched).

In chapter four, Ciesielska describes and discusses Nokia’s involvement with two different types of open source software communities. Nokia was a closed-innovation company for many years, but in the middle of the last decade a smaller part of Nokia got involved in an open source software community called GNOME. The community and its software are supported by many larger and smaller companies, such as: Red Hat, Google, IBM, and Oracle. Nokia used the GNOME software, adapting it to Nokia’s owns needs and, if it was necessary for Nokia, they gave the source back to the community to be maintained and developed. So on a small scale, Nokia contributed to the community, but due to internal policies not all of Nokia’s patches were returned. This means that the process was quasi-public and it created distrust between the community and Nokia. Unlike some of the other companies involved in GNOME, Nokia was viewed by the community as a unilateral instrumental company not immersed in the ideological part which resulted in the community source drying up. Within GNOME, Nokia was involved with other relatively independent participants. To create a more dependent community, Nokia founded its own community ‘Maemo.org’ in the middle of the last decade. Its aim was to attract external developers who could produce a set of free applications for Nokia’s devices. Nokia’s contribution was mainly financial and Nokia employees rarely got involved in the projects. At the same time, the community only attracted ‘the cloud of not so serious developers’, and the community played only a minor role in the development process.

Chapter five is divided into three sections. In the first section, a distinction is made between six degrees of companies’ involvement in open source software communities. I argue that the three empirical cases described in the book represent the three highest degrees of companies’ involvement. The Maemo.org case is an example of the fourth degree of involvement where Nokia founded its own open source community. The GNOME case is an example of the fifth degree of involvement, where Nokia and other companies participate in open source software projects lead by a community. The TYPO3 case is an example of the sixth and highest degree of involvement where companies participate as members of an open source community lead by the community. I compare the three cases and reflect on practical implications of how companies get involved in open source communities. In the second section, I reflect on two major discussions within institutional organizational theory. First, I discuss how organizations respond to multi-institutional logics in their environment and I identify five responses: resistance; replacement; competition; co-existence; and hybridization of material practices and symbolic constructions. Drawing on the empirical cases presented in the book, I argue that organizations sometimes respond in several ways and I discuss how that happens. Second, I discuss the micro/macro and actor/structure debates within institutional organizational theory, and suggest that we go beyond these distinctions and connect institutional organizational theory and symbolic institutionalism. It is suggested that we further develop new theoretical concepts such as: inhabited institutions, embedded actors, institutional work, and widespread institutional logics and ground them in a relational paradigm. In the third section, I briefly reflect on my use of the Janus face metaphor in the analysis.

In a final appendix, the authors describe the different data gathering methods used in the analyses. At the beginning of each chapter/section, we have put a footnote explaining the specific data used in the individual chapter/section. In so doing, we hope to avoid duplication of method descriptions.

At the end of the book, you find a list of concepts applied in the analysis.

Notes

1 The first legal ‘copyleft’ is attributed to the founder of the Free Software Foundation, Richard Stallman, in his drafting of the GPL license. In 1985, he got a new phrase incorporated: Copyleft-all rights reversed (Wikipedia on Richard Stallman).

2 www.opensource.org

2. Companies’ Involvement in Open Source Software Communities

Ann Westenholz

2.1 Historical development of software3

As indicated in the introduction, software development has mainly developed within two organizational fields from the 1950s to the mid-1990s: an organizational field of open source software and an organizational field of commercial proprietary software (Berners-Lee 2000; DiBona, Ockman & Stone 1999; Dr. K 2004; Feller et al. 2005; Fogel 2005; Himanen 2001; Levy 2001; Moody 2001; Pavlicek 2000; Raymond 1999; Rosen 2005; Salus 1995; St. Laurent 2004; Wark 2004; Weber 2004).

The organizational field around open source software emerged in the 1950s. Until the end of the 1960s, employees in private companies (e.g., AT&T) and university researchers participated together in, among other things, the development of a UNIX system. At that time, this system was considered to be a technical device and not a commodity. Technologically, this stage was characterized by the fact that everyone was able to see the source codes, though they were not immediately able to use the software, which was huge and complex. By the early 1970s, a new way of thinking about software emerged (software tools) making it possible for a much larger group of people to use and co-develop software. In the early 1980s, the private companies that used to participate in the development process stopped working with the developers and users in the open communities and tried to transform open source software, designed by developers in the open source communities, into proprietary software. As a response, the Free Software Foundation was established around a license regulation. The implication was that not only should source codes be open, accessible, and applicable to everyone, but also the software should remain so and should not be combined with proprietary software. This manifests itself in the development of the GPL license (General Public License – a so-called ‘copyleft’ license) and a new software system called GNU. Other programmers, however, advocated open and usable source codes to everyone, but were more pragmatic toward whether or not to combine open source software with proprietary software. The developers holding this attitude often used a version of a BSD license (Berkley Software Development). The latter group often worked as programmers in companies where they used but did not develop open software. However, in their spare time, they developed open software both for fun and as a prelude to what they were doing during working hours. In the early 1990s, the Free Software Foundation deflated some, and the groups around the BSD license branched out into three software products. Seen from the perspective of the year 1990, the influence of the open source field on future software development was dubious, but in the early 1990s the Linux system was developed under a GPL license. This created technological momentum in the field leading to the establishment of a wide range of user groups that could easily communicate with one another, facilitated by the introduction of the Internet.

The second organizational field is made up of companies developing commercial proprietary software. This field emerged later than the open software field; that is, in the mid-1970s when companies developing closed software were established. AT&T, which participated in the development of software in the open source field during the early stage, ‘immigrated’ to the proprietary field in the early 1980s. Microsoft became the predominant actor in this field, holding 90 % of the software market including a wide range of customers in private organizations, in public institutions, and among individuals.

Table 2.1 summarizes the characteristics of the institutional logics in the two organizational fields. Institutional logic is defined in the vein of Friedland & Alford (1991: 248) as material practices and symbolic constructions that constitute the principle of organizing. The concept of institutional logic is thus not the same as that of the organizational field but rather constitutes the organizing principle of the field.

Dimensions in institutional logics

The organizational field of open source software

The organizational field of commercial proprietary software

Software viewed as

Technical device

Commodity

Developers

Volunteers and professional university employees

Company employees

(professionals)

Users

Developers and end-users

Customers

Key actors in the organizational field

Developers and end-users

Companies, employees and customers

Interaction form

Community

Market

Regulative license

GPL and BSD

(copyleft)

Intellectual property rights

(copyright)

Innovation model

Open exchange of knowledge with user groups

Closed exchange of knowledge within the company

Table 2.1: Institutional logics in two organizational software fields

In the field of open source software, which was the first one to emerge, software is seen as a technical device. Developers are primarily volunteers or university employees who are not driven by the ambition of making money on software; and the potential users of the software are either developers themselves or end users. Key actors in the field are developers and end users who relate to one another through communities exemplified by Internet-based user groups. Formally, two primary types of licenses, BPL and BSD, regulate the exchange of knowledge. The latter is positive toward combining open and proprietary software whereas the former refuses. The innovation model can be characterized as open.

In the field of commercial proprietary software that subsequently emerged, software is seen as a commodity developed by employees and sold to customers. Key actors are companies, their employees, and customers that buy the software from the software companies. The actors relate to one another through the market. Intellectual property rights tied to the individual company are connected to the software and the innovation model is closed around the company.

The symbolic meaning ascribed to software differs significantly from the identities involved in developing and using software. There are also opposite understandings of the regulative systems used to develop the software deriving from the way of interacting and of generating knowledge. Two different institutional logics are involved. Actors operating within the one logic interact more often with one another than with actors representing the other logic, that is, up to the mid-1990s, software development took place within two organizational fields. This does not imply that we cannot identify some kind of interaction among actors from the two fields. First, certain developers in the area near Berkley Software Development work as programmers at companies where they use but do not develop open software. And, as such, they identify themselves as end-users when they work within the proprietary field and as developers when working within the open source field. Second, in certain periods, actors in the two fields fought over the right to the software as proprietary/open source software, respectively (e.g., in the beginning of the 1980s). Such interactions among actors from the two fields are not, however, as intense as in-field interaction. Therefore, the two organizational fields emerged in the period.

In the mid-1990s, a new development gradually emerged as commercial companies in collaboration with voluntary developers/users began to use open software. In 1998, this development became formalized in the definition of Open Source Software; that is, software for which everyone has access to the source text and is free to distribute either as it is or in combination with software from other sources – free or at a price. This is a radical institutional transgression of activities that has so far taken place in the organizational field of commercial proprietary software. Certain actors within this field, headed by Microsoft, fight its development, while others such as Netscape and IBM actively participate in the development process. Some actors in the organizational field of open software also find the development unacceptable and are outright opposed to combining open software and proprietary software. This applies to programmers within free software while other programmers, such as those associated with the environment around BSD licenses, are less radical, having never been opposed to combining open and closed software. By the end of the 1990s, we witnessed the establishment of many meaning arenas in which actors from both the commercial proprietary and the open source fields participate. In the years that follow, different ways of combining business and open source software community projects are created and companies are making money in different ways by (Krishnamurty 2005; Weber 2004):

providing and selling the open source software on CD;

providing services and upgraded services to private and public organizations by implementing an open source software product; or

selling a combination of open and closed proprietary software (without disclosure of the source code), if the open source software license allows it.

I will now turn to studies dealing with companies’ involvement in open source software communities.

2.2 Literature on companies’ involvement in open source software communities

Some literature on companies’ involvement in open source software communities are accounts told by participants in the field, or studies which primarily have a normative aim of informing that it may be a good business strategy to develop open source software, and how it may be done (Behlendorf 1999; Fink 2003; Hang, et al. 2005; Tiemann 1999; Woods & Guliani 2005; Young 1999). Although this literature provides interesting stories from the field and points at best practices, the literature lacks an analytical foundation and will not be part of the following literature review.

Some studies primarily analyze the strategies used by companies dealing with open source software. Lerner and Tirole (2002) describe that since the turn of the century numerous major corporations, including Hewlett Packard, IBM, and SUN have launched projects to develop and use open source software. Other companies such as Red Hat and VA Linux have specialized in commercializing Linux, and yet another group of open source software companies have received venture capital financing. They argue that companies may employ two different strategies dealing with the interface between open (copyleft) and closed (copyright) source software development: either they imitate some incentive aspects of open source processer, or they mix an open and closed process. If companies follow the first strategy they do not get involved with open source software communities, as they will not allow users to modify their code. But these companies may, to some extent, duplicate the incentive by letting core developers build reputation connecting to specific proprietary software as with open source software development. Alternatively, companies may imitate the idea of open source code sharing within the company. I am not following this line of development in this book, neither am I investigating the literature on how a company may involve their users/customers in the development of their product (Langdon & Hars 2007). I am interested in studying companies’ involvement with open source software communities, which is in accordance with the second strategy that companies may use. In the second strategy, companies get involved with open source software communities in various ways. They may choose a rather reactive relationship with open source communities by allocating programmers to an open source software project. Or they may choose a more proactive strategy by releasing codes and creating some governance structure for the resulting open source process.

Capra et al. (2009) substantiate the second strategy defined by Lerner and Tirole in a survey on companies’ participation in open source community projects. Capra et al. argue that a distinction should be made between a) open source projects, which are led entirely by a company, and b) open source projects, which are led by community members. The researchers are primarily interested in the latter situation where companies get involved in a community project. They argue that companies are profit-oriented agents and that the primary goal is to get tangible benefits from the participation in the open source project. Companies may follow different models of participation in open source communities:

They may participate in creating codes.

They may support the project that creates codes in other ways, e.g. they may provide financial and logistical support.

They may get engaged in administrative or managerial work within the project in order to drive the product in a competitive way for the company.

The researchers investigated 1,302 projects from the SourceForge.net repository, as this is commonly associated to be on the most open side of the continuum between open and closed software development model approaches. Their survey shows that companies are involved in about one third of the open source projects, which are commonly believed to be mostly based on work of voluntary developers and users. On average, two companies participated in each project. In 68 % of cases, companies supported the project; in 30 %, they contributed codes; and in 9 %, they performed management activities. The results highlight that companies are not just ‘takers’ by downloading open source code, but some of them are also ‘givers’.

Grand et al. (2004) further investigate the question of how companies engage in the creation of open source software, and they develop a four-level model of companies’ resource allocation. At level 1, companies primarily use rather than develop the software. However, it is not completely without cost, as companies need technological expertise for installation and integration into the existing IT environment. Hoppenbrouwers (2007) mentions, that these companies – which he calls ‘community customers’ – sometimes become engaged with the open source software communities by donating efforts around the product to the community. At level 2, companies like IBM and Sun Microsystems sell their products with open source software as a complementary asset. This may require major investment, as development may be needed to adapt code developed for other purposes. At level 3, open source software becomes a design choice for the way the companies develop specific new software. At level 4, open source software moves from being the design choice for a specific project to the design choice for the companies’ overall business model. The researchers argue that the four levels are dynamic and have a cumulative logic of gift economy; the greater the benefits, the greater the resource investment managers have to make.

In another study conducted by Rolandsson, Bergquist and Ljungberg (2011) the researchers focus on how programmers cope with the co-existence of contradictions in proprietary companies that have gradually incorporated open source software, and in small and medium sized companies that entirely are build around open source software concepts. The researchers argue that from the programmers’ perspective, ‘open source is a possibility, but not without constrains. It has to be nurtured by the organization and actively handled by the programmers to become the innovative force it is claimed to be.’ They investigate how programmers develop strategies to handle the tensions that arise from contradictions between the different logics and they identify four strategies: programmers utilizing open source as engineers and instrumentally focusing on formal hierarchic conditions and opportunities to experiment with in-house projects; they look upon open source as something that can be utilized to tailor software according to customers’ demands; they cultivate a community consortium by involving users as exclusive business partners paying a membership fee; and finally they constantly persuade customers to conform to the joint expertise of their community.

Another question, which has attracted significant interest, is why companies are getting involved in open source software. Feller & Fitzgerald (2002) distinguish between economic, technological and social motivations and they argue that companies are driven primarily by technological factors to gain economic benefits. Bonaccorsi & Rossi (2004) investigate this question further in a survey of 146 Italian companies. Their findings show that individuals often have social motivation for participating, and companies more often emphasize economic and technological reasons for their involvement. This is consistent with the findings by Feller & Fitzgerald. Participating in open source software development allows small companies to become innovative; communities contribute toward improving the software by fixing bugs; and open source software is considered to be reliable and of a high quality. Bonaccorsi & Rossi (2006) go on to enhance their analysis using the same sample of 146 Italian companies. Their findings show that companies’ profit-oriented incentives are coupled with community-based motivations. However, the community-based motivations are not put into practice by companies, and the two researchers argue that companies’ declaration of community-based motivations may simply serve the purpose of winning the trust of the individual developers for receiving contributions and support from the community. Stam & de Joode (2007) partly contradict these results in their 2005 survey of 90 Dutch companies selling open source software-related products and services. They make a distinction between companies’ social participation (including organizing conferences and events related to the community), and technical participation (where the companies contribute to the community by sharing codes and other types of knowhow). They show that the two types of participation are positively correlated. Their results also show that companies’ participation in open source software development is supplemented by company-internal development, and that the external and internal processes possibly reinforce each other.

Some studies have focused on how companies create and/or maintain the relationship with open source communities. In a case-based study, Dahlander & Magnusson (2006) show that companies’ relationships with open source software communities have an impact on their behavior. Some companies create strong relationships, while others move away from the communities. In both cases, the company gives up some ambition to control its development in order to gain a degree of freedom. If a company builds a strong relationship, it needs to respect the norms in the community, and that may limit its room for maneuver. On the other hand, the company will get the benefits of support and innovation from the community. If a company moves away from the community, it may be easier to make a profit, however it will not get the support from the community. The two researchers argue that delving further into mechanism and processes through which the relationships emerge is an interesting theme for future research.

Kilamo et al. (2011) conducted such a study in which they provide some insights into how companies create and maintain open source communities in an effort to use the communities as cornerstones for their future ecosystem. They argue that there are three phases to developing an open source ecosystem. In the first ‘pre-bazaar’ phase, the company needs to identify possible bottlenecks, prepare the software for release, and ensure the software continues to be supported in the open source ecosystem. In the second phase, the company focuses on eliminating the problems identified in the first phase. In the third phase, the community has been ‘born’ and needs to be nurtured, and monitored by a ‘community watchdog’. This model is applied to the empirical case of ‘Gurux’. The researchers conclude that ‘going open source’ has not been an easy task for the company and it has taken longer than expected, but it helped to view the software platform and ecosystem strategically. Other organizations are no longer viewed simply as clients, but as co-developers and business partners, which may help to maintain the platform. Although the researchers do not draw on social construction identity theories, this last remark points to an identity creation taking place in these processes.

2.2.1 Summary and reflections on the literature

Literature on companies’ contact with open source software communities shows a great variation in companies’ involvement, and in figure 2.1 I systemize the degree of this involvement. The table describes six steps from the lowest to the highest degree of involvement. Companies may combine some of the steps and further empirical research will show how this is done.

Low degree

High degree

1.

Companies imitating and translating ideas from open source communities (duplicating incentives, knowledge-sharing within the firm, user-involvment).

2.

Companies as: ’community customers’ using the open source software and sometimes also supporting the community with money.

3.

Companies combining proprietary software with open source software.

4

Companies leading open source software projects (managing the project, creating codes, supporting the project).

5.

Companies participating in open source software projects led by a community (creating codes, supporting the project).

6.

Companies becoming members of open source software communities (creating codes, supporting the community, co-managing the community).

Figure 2.1: Companies’ Involvement in Open Source Software Communities

The lowest degree of contact is where companies imitate/translate ideas from the open source software field (duplicate incentives, knowledge-sharing within the firm, user-involvement), but are not directly involved with the communities. There is a vast amount of literature dealing with this issue, often under the name of ‘open innovation models’. The next step sees companies becoming ‘community customers’ as they use the open source software and sometimes support the community financially. We are not focusing on these two types of situations as our interest is in studying companies getting involved in the development of open source software. This happens in the third step, where companies sell their combination of proprietary software and open source software. In the fourth step, companies release codes and try to build an open source software community around the project. The Nokia Maemo case discussed in chapter 4 is such an example. The fifth step is characterized by companies participating in open source software developments lead by a community. The last step, which illustrates the highest degree of involvement, is characterized by companies becoming members of open source software communities where they create codes, support the community and participate in its management. This last step is not well described or analyzed in the literature, but we will explore an example of this step in chapter 3.

Much of the literature has dealt with why companies get involved in open source software despite the fact that this involvement will not protect the software from being copied. Why do for-profit companies do that? There are three potential motivators behind this: technological, economic, and social – and the connection between them, which is not yet clarified. Some argue that companies are mainly motivated by technological issues and that these are positively connected to economic benefits, but are not connected to social motives. Others argue that the three motives are positively connected. It is not possible on the basis of these studies to explain the different results. One assumption may be that the companies that are leading open source projects tend to be hypocritical by talking about community-based motivations, but not acting in a community-based way. Companies participating in community-driven open source projects, however, to a greater extent combine a community-based motivation with a community-based action. I comment on this assumption in the final chapter.

With the exception of a few examples, most studies are quantitative. Only a few case studies have been conducted following processes where the commercial world and the voluntary community world meet, interact and sometimes become merged. I would like to argue that we are in need of more process-oriented case studies – as a supplement to quantitative studies – if we want to understand how commercial open source software communities emerge. We learn something about the development from static surveys, but we do not get a deeper understanding of how people, who are embedded in mature organizational fields, change their world views and their motivations to take alternative ways and transgress contradictory organizational fields. Instead these static survey studies often – but not necessarily – explain the development of commercial open source software drawing on what March & Olsen (1989) call, “a logic of consequentiality”. People and companies, who are assumed to following such logic, are perceived as actors with exogenous, stable and clear interests and motivations – and they make their choices according to the consequences in relationship to the interests. They are able to do so as the links between interests and consequences are rather unambiguous, which makes it possible to follow a rational process. In my understanding, transgressing different institutional orders are highly ambiguous, meaning that interests cannot be brought to bear in any easy way. As a result, the process does not follow the rational logic of consequentiality, which is the (implicit) position of many of the authors. In my view, actors and interests are constructed simultaneously through a process of practical logic and action. Choices are made through processes of practical logic, or in March and Olsen’s term: a logic of appropriateness. Actors are understood through their socially constructed identities, which involve “fulfilling the obligations of a role in a situation” (March and Olsen 1989: 160). Decision making is understood as a matching of identities with situations. Choices are made through a process of practical logic by which actors come to grips with their identity and bring it to bear in situations where choices are made. Actors will take their identity and the situation (asking what kind of person am I and what kind of situation this is) and then take a course of action, which matches this perception. March and Olsen (1996: 252), however, point out that considerable uncertainty may be involved in establishing role identities as well as identifying situations of action. The contribution to this discussion is to help specify the means by which identities and situations are created and understood in the processes where commercial open source communities are created. We will explore such process-oriented case studies in chapters 3 and 4. I will now present an analysis of commercialization of open source in Denmark – by building on a survey.

2.3 Commercialization of open source software in Denmark

The analysis in this section is primarily based on a survey from 2006 in which 35 company representatives participated (see Appendix: Methods). The companies are all members or supportive members of the Association for Open Source Suppliers in Denmark. Figure 2.2 shows that a few of the 35 company representatives took part in commercializing open source software right from the beginning by established new IT companies based on open source, and by introducing open source as a business concept in existing IT companies during the years 1990-97. This development continues at an increasing rate until 2002, by which time the establishment of new open source companies starts to decline while the introduction of open source in existing IT companies seems to continue at the same rate. Participation in the public debate begins a little later and seems to peak in 2003-04.

Figure 2.2: Temporal development of involvement in open source commercialization

The quotation below from a manager, whose new Danish IT company in 2001 introduced open source as a business concept, illustrates that the development in Denmark is inspired by global development:

From 1997 onwards, I worked as a project manager for Digital Equipment Corporation4 and later for Compaq in Madrid. This was about the time when I got seriously interested in open source… Denmark was lagging far behind… We say that one of the main reasons why Linux and open source are facing such difficulties in Denmark, compared to other countries, is that we have too much money. We can afford to buy licenses. It is a question of comfort, combined with the fact that you are not fired for buying something known. I realized that it was a question of time until Linux would gain some kind of foothold in Denmark because of the advantages it offers. I also analyzed the environment in Denmark. The environment of open source enthusiasts was huge, one of the biggest in the world – quite a lot of smart people. In principle, they were volunteers – joined in an association (SSLUG). But no companies marketed the product. Even though the environment of open source and Linux counted a lot of freelancers and SMEs, they did not, at that time, make up a credible partner for a larger Danish company, municipality or the like… It was at that time that I decided to act. A reliable supplier in Denmark was needed to make this grow. And I decided to start up such a company from scratch in 2001.

One could immediately be led to believe that companies become involved in open software for purely commercial reasons. Taking a closer look, however, their reasons for getting involved reflects a mixture of pragmatic and moral reflections tied to the development of both the company and the open source communities. The pragmatic arguments are that by participating in the communities, the company gets access to more valuable information and the employees gain greater competence in task performance. Simultaneously the continued development of the communities is dependent on the companies’ involvement in the communities. But many people also find that the company is ideologically and morally committed to involvement in the open source communities. By and large, all company representatives stated that companies to a high or to some degree have a long-time interest in being involved in open source communities, and the majority of these companies want to contribute to the market for software development using open source. Around two thirds think that the company wants to be among the best suppliers of open source software and that it wants to be able to influence the development of open source software. These findings support the results from the study by Stam & de Joode (2007).

As the above demonstrates, the companies’ reasons for getting involved go beyond mere commercial interests. This issue was followed up by asking what makes working with open source software so interesting: technical and/or sales aspects. The question was formulated in a way that made it possible to respond to both aspects independently. By and large everybody fully agrees/agrees that open source is interesting because it implies developing technical solutions, while fewer respondents – but still many (three quarters) – stress the sales aspect. So there is every probability that a vast majority states both reasons, but since they are company representatives, it is interesting that a quarter disagree/completely disagree with the sales argument.

The company representatives were also asked about what motivates the individual programmer to participate in open source projects. Here too the respondents were not limited to opt for just one answer. Nearly all agreed to the importance of other programmers’ recognition, personal desires and having fun at work – in the mentioned order. Furthermore, over three quarters agree to the importance of self-promotion and of ideological/moral aspects, and more than half agree on the importance of social interaction, the artistic expression and the voluntary aspect of work. The study also shows that salary does not play any significant role as a motivational factor. More than half even disagree to it playing any role at all! The fact that salary seems to be of less importance may not be so surprising as this also seems to be the case with other employees in the public and private sectors in Denmark. However, the open source programmers’ toning down of the importance of salary seems more pronounced compared to other employees in the public and private sectors.

Based on a series of questions about organizational and managerial issues concerning the companies’ involvement in open source projects, I have tried to form an opinion of whether the companies are assessed to believe as they are expected to as ‘companies’, or whether they have started to imitate the behavior of communities. In Table 2.2, the company representatives are categorized according to whether they represent a model of community, of a company, or neither.

1

Community

model

2

Company

model

3

Neither community- nor company model

1. Who should play a significant role in managing open source projects?

Users

32

Companies

45

Core developers

47

2. How should companies share their knowledge about open source projects?

As fast as possible

35

Companies decide if they release the knowledge or not

– 5

Companies release the knowledge – when appropriate

30

3. Who should be involved in working with open source?

Everybody who wants to participate

30

Companies decide

– 32

Everybody as users, but restrictions on who develop

21

4. Is it necessary to raise economic resources for the development of open source software?

No financial support is needed as users do the work

– 24

Companies need to financially support

37

Economic donations are necessary

37

To understand the idea of the table let us, as an example, take the first question: Who should play an important role in managing open source projects? Respondents could choose among ‘users’, ‘companies’ and ‘core developers’, and for each category respondents have been able to respond on a scale from ‘quite agree’, ‘agree’, ‘disagree’, and ‘totally disagree’. In the table the response ‘quite agree’ equals 2; ‘agree’ equals 1; ‘disagree’ equals -1; ‘totally disagree’ equals -2; ‘don’t know/haven’t responded’ equals 0. The largest figure could be 70 and the smallest one -70.

Table 2.2: Three models: A community model, a company model, and a model which is neither (70 points is max. of agreement and -70 points is max. of disagreement)

community model company modelthird model

2.3.1 ‘Institutional entrepreneurs’ and the development of commercial open source companies in Denmark

It appeared from above that commercialization of open source is a phenomenon that has made its entry into Denmark in recent years. In this section we shall explore how different actors in Denmark have acted as institutional entrepreneurs enabling this development by combining two basically opposing social worlds: the commercial world and the world of communities. By institutional entrepreneurs I am referring to actors (individuals or organizations), who have the skill and reflexivity to work with institutional orders. My argument is that institutional entrepreneurs have played a role in many different contexts in Danish society. In the following I shall offer three examples of how they have done this.