Can You Trust Someone You Do Not See? The Case ...

2 downloads 0 Views 2MB Size Report
teaching, research, or library reserve. ..... of complementary elements allows for collective learning (the “making ...... A Second Look at the Cathedral and.
ISSN: 1286-4892 Editors: Martin Evans, U. of Toronto Bernard Forgues, U. of Lille I

Thomas Loilier and Albéric Tellier 2004 Can You Trust Someone You Do Not See? The Case of Open Source Software Development Translated from:

Comment peut-on se faire confiance sans se voir ? Le cas du développement des logiciels libres M@n@gement, 7: 3, 275-306.

M@n@gement is a double-blind reviewed journal where articles are published in their original language as soon as they have been accepted. Copies of this article can be made free of charge and without securing permission, for purposes of teaching, research, or library reserve. Consent to other kinds of copying, such as that for creating new works, or for resale, must be obtained from both the journal editor(s) and the author(s). For a free subscription to M@n@gement, and more information: http://www.dmsp.dauphine.fr/Management/ © 2005 M@n@gement and the author(s).

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

Can You Trust Someone You Do Not See? The Case of Open Source Software Development Thomas Loilier . Albéric Tellier

Université de Caen Basse-Normandie Institut d’Administration des Entreprises eMail: [email protected] Université de Caen Basse-Normandie Institut d’Administration des Entreprises eMail: [email protected]

The subject of this research is collaboration within virtual innovation networks. These project-teams are made up of geographically dispersed individuals who are temporarily brought together, and make use of information and communication technology to support communication and the realisation of the project. Existing literature on the relationships between members of a group accords trust the central coordinating role. However, it seems acknowledged that this confidence relies essentially on personal or face-to-face knowledge of the other individuals. Our aim is to study the conditions in which trust can be a method of coordination when there is no direct and immediate interaction between the principles of the innovation project. In order to reply to this question, we will analyse the functioning of open-source software development teams associated with the Linux project. It appears that the absence of simultaneous direct interaction significantly limits interpersonal trust. This lack of trust is compensated for in part by a high level of institutional trust, but also by a formalised control mechanism, the combination of these assuring a high level of performance. We have also distanced ourselves from methodologies that give particular importance to trust as an alternative to control, in preference for an integrated perspective. In particular, control sanctions can be used without de-motivating the Linux community members because it complements a global control system similar to that of social control.

INTRODUCTION For several years, we have witnessed a proliferation of studies on the ability of information and communication technologies (ICT) to permit new configurations of virtual innovation networks (e.g., Howells, 1995). Today, various tools allow asynchronous exchanges (e-mail, FAQ) and synchronous exchanges (Chat), as well as synchronous visual communications (video-conferencing, 3D modelling labs, etc.). Thus it has become possible for geographically dispersed individuals to coordinate through a process of mutual adaptation without passing through a preparatory phase of codification1 (Rallet, 1997; Gallié, 2003). Variously described as e-networks (Loilier and Tellier, 2003), virtual teams (Lipnack and Stamps, 1997; Potter, 2000) or even virtual global networks (Jarvenpaa and Leidner, 1999), these project-teams are made up of geographically dispersed individuals, sometimes from disparate organisations and cultures, who are brought together temporarily (for the duration of the project). They

Editors’ note. This article is a translation from the French of an article published in M@n@gement in the 2004 special issue on Practicing Collaboration [Loilier, Thomas, and Albéric Tellier (2004), Comment peut-on se faire confiance sans se voir ? Le cas du développement des logiciels libres, M@n@gement, 7(3): 275-306.] To bring this paper to a wider audience, the authors, together with Alexandra Wade, have provided this translation. 1. The individuals settle for writing, speaking or designing.

1

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

Thomas Loilier . Albéric Tellier

primarily use ICT to maintain communications and to implement the global project. Our aim is to offer a better understanding of the ways in which members of virtual innovation networks coordinate their efforts. The literature devoted to the interrelation of economic participants, and more particularly to networks, posits trust as the principle method of coordination within hybrid forms (Powell, 1987). However, it seems largely accepted that the trust at work in networks relies at least in part on face-to-face interaction and a personal knowledge of other individuals. Thus our goal is to understand how such trust develops in dispersed organisations, given that such organisations can rely only rarely on geographical proximity—particularly face-to-face interaction—unlike traditional project-teams. In recent years, many studies have been undertaken on the development and maintenance of trust in geographically dispersed projectteams (O’Hara-Devereaux and Johansen, 1994; Iacono and Weisband, 1997; Lipnack and Stamps, 1997; Crisp and Jarvenpaa, 2000; Maznevski and Chudoba, 2000; Bos, Gergle, Olson and Olson, 2001; Kanawattanachai and Yoo, 2002). These studies aim to test Handy’s central hypothesis, according to which trust requires contact between individuals. Since then, authors have concentrated on trust between individuals as the key factor determining a successful working relationship within these teams (Kanawattanachai and Yoo, 2002: 189). Despite the undeniable contributions made, two specific points within these studies need further elaboration: the scope of the trust being studied, and the recognition of a possible intertwining of coordination mechanisms. Firstly, if trust can be born out of relationships between individuals, it can equally evolve at higher levels, most notably at the level of organised communities, and can depend on technical competencies or ethical reputation. Secondly, it is a delicate issue to analyse the role trust plays in this type of team without incorporating other types of coordination, notably control mechanisms that can mitigate the difficulties of dispersed collaborative work. This article is constructed around the question of the creation of trust: under what conditions can trust be a method of coordination when there is no direct local interaction between the members of a virtual innovation network? In order to answer this question, we analyse the functioning of opensource software development teams, particularly those associated with the Linux project. The designing of such open-source software, the success of which is now incontestable, depends on a community of geographically dispersed developers who are not, by and large, financially motivated. In summary, this software has been developed by a network of developers who trust one another without seeing, or personally knowing, one another, and who primarily use ITC as their means of communication. The open-source community is not a virtual global team in the strict sense of the term, but rather a group of virtual teams (a network of teams), each working on distinct projects within the context of a shared objective: the construction of a free integrated IT offering (software, servers, operating systems etc.), as an alternative to the proprietary model developed most notably by Microsoft. 2

Can You Trust Someone You Do Not See? The Case of Open-Source Software Development

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

The level of analysis in this study is thus the project-team consisting of individuals who are, a priori, geographically separated. Within these teams, face-to-face interactions are almost non-existent, the participants knowing one another only by their reputation within the community (“egoboo”), their activity within the discussion forums and from mailing lists. Thus it presents an extreme case, in the sense given by Eisenhardt (1989), meriting an in-depth study of the creation of trust within it. The first part of the article gives an opportunity to reconsider the concept of trust and to broach the particularities of the functioning of virtual innovation networks that induce a vision of intertwined coordination mechanisms. The second part presents the chosen case study and the applied methodology. Finally, the third part looks at the conditions necessary for the creation of trust within these teams, and discusses the results evinced.

COLLABORATIVE INNOVATION, DISPERSED ORGANISATIONS AND TRUST A RECONSIDERATION OF THE NATURE OF TRUST What is trust? The question is simple, the answer all the more difficult for the fact that the concept «is subtle, diffuse and elusive» (Nooteboom, 1996: 990). Within anglo-saxon studies, this complexity translates most notably into a great semantic diversity which does not simplify the challenge of grasping this concept (notably Fukuyama, 1995; Mayer, David and Schoorman, 1995). Many writers have sought to impose semantic conventions, beyond the distinction between trust and confidence now broadly discussed, in order to combat this complexity. Nooteboom (2002) argues, for example, for a distinction between trust in the broad sense (reliability) and trust that is closely bound up with an calculation of personal interest (“real” trust). The subtlety of the idea of trust is found again, most logically, in the study of that which trust is not: what trust isn’t. Contrary to received opinion, Lewicki, McAllister and Bies (1998) demonstrate that trust and its distrust are not opposed but rather unrelated. Put another way, within a single relationship, the two attitudes can easily co-exist. Thus trust is an idea with many facets, one that is difficult to reduce to a simple definition. Trust may be defined as «as the expectation that an exchange partner will not engage in opportunistic behaviour, even in the face of countervailing short-term incentives and uncertainty about long-term benefits.» (Chiles and McMackin, 1996: 85). However this analysis gives an economic perspective on trust. Recourse to this method of coordination, as a supplement those of authority and hierarchy, is guided by motives of efficacy (achieving the objects of the network) and efficiency (at the lowest cost). This approach proves primordial but not unique: trust is not simply economic but also sociological and psychological. Rooks, Raub, Selten and Tazelaar (2000) have demonstrated that the 3

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

2. Mayer et al. (1995) differentiated between three dimensions: capability, goodwill and integrity. The first deals with the aptitudes and competences of the parties present; the second with their demonstration of a positive attitude, and the last with the qualities of character (honesty, loyalty, openness of spirit, etc.) However, the closeness in accepted meaning of the last two is such as to invite their drawing together.

3. We do nothing more here than adopt the argument developed by Williamson (1993) on the uselessness of the concept of calculating trust which is only ever an extension of opportunism.

4. Also known as interactive trust.

4

Thomas Loilier . Albéric Tellier

intrinsic characteristics of a transaction (specific investment, magnitude and uncertainty) do not suffice to explain efforts at management and the trust accorded by each party in a transaction. In order to understand these, one must take into account the social context of the transaction, within its temporal dimension (frequency of past exchanges), its reticular dimension (intricacy: relation with a third party and/or other firms) and its institutional dimension (the existence of social institutions which take into account credible conventions and commitments). One of the most common distinctions then deals with the level of trust. The distinction allows one, following Luhmann (1979) and Giddens (1990), to dissociate interpersonal trust (personal trust) from systemic trust (system trust). The first characterises that trust placed in individuals, the second that relating to a system as a whole (e.g., the banking system). The latter transcends personal experience or face-to-face relations and does not imply a belief that any individual or group of individuals merit trust. If one refines the analysis, personal trust can be broken down into two dimensions: intentional and that relating to competence (Sako, 1991)2. The first is concerned with the belief that an individual will respect his obligations without demonstrating any opportunism; the second that he possesses the necessary competencies, particularly in terms of training and professional experience. It is common to contrast two forms of personal trust: one based on norms and the other on calculation and self-interest. The first associates trust with a reliability of behaviour (the trusting individual thinks the other will respect the norms). Calculating trust boils down to giving trust a rational dimension, each therefore seeking to maximised the desired utility. We have already noted that this purely economic approach appears to us reductive. Furthermore, it adds nothing to the classic analysis of decision-making in economics3. Finally, several significant distinctions emerge from the various studies, which encourage one to use the plural: for trust, it becomes judicious to speak of trusts. However, it appears that the nature and characteristics of the trust in question depend upon its modes of construction (Mangematin, 1999: 31). In certain cases, the mode will allow the emergence of a trust shared by the whole of a community. In other situations, the trust is limited to interpersonal relationships. Subsequently, the nature of the trust produced by the mode of construction will influence the coordination of activities. In other words, the role played by trust in the coordination of innovating activities depends upon its nature and therefore upon the conditions in which it is produced. Thus an analysis of its efficacy in virtual innovation networks cannot be effectuated without reference to its modes of production (Mangematin, 1999: 32). If one chooses to concentrate one’s attention on the different mechanisms for producing trust, the distinction used by Zucker (1986) then proves central. It distinguishes three forms of trust, according to their method of production: intuitu personae trust (characteristic-based trust); relational trust4 (process-based trust) and institutional trust (institutional-based trust), as detailed in Table 1.

Can You Trust Someone You Do Not See? The Case of Open-Source Software Development

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

Intuitu personae trust springs from individual personal characteristics. These can, for example, belong to a single ethnic group, a family or even a religion. These characteristics, which cannot be produced at will, are exogenous to the relationship between the participants. Relational trust, however, is inseparable from the relationship itself. It is, in the final analysis, the product of the knowledge that one may have of another through his repeated actions (past loyalty, determinant logic of voluntary exchanges, etc.) or information, from a third party, regarding one’s reliability (e.g., reputation). These two forms of trust are above all interpersonal. Institutional trust is of an entirely different nature. Being systemic, it can exist between individuals without their knowing each other or having any direct interaction. This institutional trust characterises the trust we place in formal institutions such as the law. According to Zucker (1986), it is the reconstruction of the trust produced locally by the participants that is exterior to the context of the exchange. It can take two forms: a group of signals (e.g., a brand, a diploma, the ISO standard, etc.) given off by one of the protagonists that reduces the range of his possible behaviour or the intrusion into the relationship of a third party who can, for example, reassure the participants as to the outcome of this relationship (e.g. an insurance company). Over and above these different method of construction, trust is a method of coordination which, when used within innovation networks, presents pronounced characteristics.

MODALITIES OF PARTICIPANT COORDINATIONS WITHIN VIRTUAL INNOVATION NETWORKS The virtual innovation network can be defined as a coordinated group of heterogeneous participants (private or public laboratories, businesses, clients, suppliers, financing entities etc.) who actively, and collectively, participate in the conception, elaboration, construction and diffusion of an innovation (Maillat, 1996: 84). One of the primary characteristics of the network is that no participant who forms a part of it has, a priori, all of the assets essential to the project, each therefore seeking to acquire complementary assets (Teece, 1987). Over and above this now well-known major characteristic, virtual innovation net-

Table 1. The different modes of trust production* Methods of production/ Mechanism of trust

Foundation of trust

Examples

Intuitu personae trust

Personal characteristics of the individual (thus here trust is attached to a person) Passed or anticipated exchanges, reputation, dyadic giving (gift/counter-gift) Formal social structure guaranteeing the attributes of an individual or of an organisation

Family, community, ethnicity, culture, religion Loyalty, commitment Rules, ethical codes, professional standards, norms, brands

Relational trust Institutional trust *: Adapted from Zucker (1986).

5

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

5. Certain human competencies (individual or organisational routines) or physical competencies (new procedures, machines, products etc.) will evolve during the furtherance of the innovation process, which must therefore be considered as arising from the cooperative work.

6

Thomas Loilier . Albéric Tellier

works present specific characteristics which induce confidence and which lead to the introduction of original methods of coordination. In the case of the process of innovation, a certain number of specific assets do not pre-exist the decision to be involved in the project. These so-called endogenous specific assets (Boissin, 1999) establish themselves during the process of innovation5. This co-construction is most often observable within virtual innovation networks where the pooling of complementary elements allows for collective learning (the “making do”) that gradually becomes a specific asset of prime importance. The most radical example is incontestably that in which the emergent characteristic (Mintzbert and Waters, 1985) of the innovation project is at such an early stage that the innovation community cannot know ex ante what will be the specific assets that it will develop. This can cause modifications in the configuration of the network as the project takes shape (e.g., the enrolling of a new partner). To accept to take part in such a network is to commit oneself to a process of which one cannot a priori evaluate the potential costs and benefits for each of the participants because it is difficult to imagine clearly the results of the collaborative work. Thus Planque (1991) and Maillat (1998) noted that the participants in an innovation network are drawn to invest in the project even before being certain of success and they proceed thereafter by trial-and-error and successive reorientations. Thus it is crucial to be able to involve oneself with trustworthy partners who will do their best to achieve results. The logic of the exchange between the participants in an innovation network is that of dyadic giving (gift/counter-gift): that which each participant gives to the rest of the community (technical skills, reputation, strategic information etc.) is not in return for immediate compensation but for deferred compensation, the nature of which is not defined at the moment of the exchange (Ferrary, 2002). This system allows the development of trust if the exchanges are equitable, that is to say if they «consist of helping the partner when he so expresses the need and, conversely, that he will do likewise when the occasion arises» (Bouty, 1999: 10). The uncertainty that weighs upon the outcome of innovation projects leads the participants to mobiles network partners through very informal agreements. However, in order to limit unilateral appropriation risk, more broadly speaking opportunistic behaviour, the network participants must socialise their exchanges, that is to say, register them within a social group with its own rules, its own customs and rite, etc. Firstly, this socialisation increases the cost of betrayal by adding to the economic cost (exclusion from future projects) symbolic and social costs (exclusion from events specific to a social group); secondly, it assures an optimal regulation of the gift exchange because opportunistic behaviour will be sanctioned even if there is no formal contract. The sanction is in this case social rather than legal: information regarding opportunistic behaviour will be distributed through the network and will encourage each member to refuse any further collaboration with the cheater (Ferrary, 2002). Thus, if trust is a possible method of network coordination, it is nonetheless necessary to have all the tools for conflict resolution,

Can You Trust Someone You Do Not See? The Case of Open-Source Software Development

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

sanction mechanisms, defined terms of engagement etc. Even if the network uses reciprocal conventions (the dyadic gifting logic) and the effects of reputation, it also makes use of contract and routine. In effect, none of these coordination mechanisms are exclusive. In other words, a form of governance (the network, the market and the hierarchy) uses a combination of intertwined coordination tools most of the time (Bradach and Eccles, 1989). This mingling of coordination mechanisms is found in the studies that have highlighted the limits of trust as a sole method of coordination. In virtual teams, the trust created is generally considered very fragile (Crisp and Jarvenpaa, 2000) and control mechanisms, even if simplified, are indispensable in order to avoid unpleasant surprises. Brulhart and Favoreu (2003: 10) noted that the weakness or absence of control generates uncertainties that translate, for the participants, into a loss of any benchmark, and a rise in deviant behaviour. Thus it is essential to put in place contractual safeguards that reassure each of the parties that each network member will adopt cooperative behaviour (Poppo and Zenger, 2002). Even if each participant works on the hypothesis that the other members have a sincere wish to cooperate and thus that opportunistic behaviour will be almost non-existent, it is imperative to have a rule of reciprocity which assures the equity of transactions (Josserand, 2001: 19). In the case of virtual innovation networks, this rule is that which excludes individuals who prove not to be trustworthy. The existence of this rule, which serves as a guide rail, reassures the participants, and encourages cooperative behaviour (e.g., the transmission of information) which in turn fuels the existence of trust within the network. Thus, not only are control and trust complementary methods of coordination but they are also mutual influencing (Goold and Campbell, 1987). In addition to trust and control, two other methods of coordination can be used within the context of intertwining: the contract and the type of technology, particularly through the concept of modularity. Contract and trust must be understood as complementary methods of coordination (Brousseau, 2001): trust allowing the management of the relationship on a daily basis and the mitigation of the incompleteness of the said contract. This complementarity is deepened within the context of innovation activities where initiative, difficult to take into account a priori in a contractual commitment, is a key success factor. Trust thus allows one to manage efficiently and at the lowest cost, the contractualisation. In return, the contracts can be generators of trust thanks to their content (creation of credible guarantees) but also as a process. The process of contractualisation proves in effect to be a generator of trust because of its symbolic value and the cooperative signals generated which initiate and maintain the «fragile assumptions of trust» (Brousseau, 2001: 77). As a result of its characteristics, technology can equally be assimilated into a method of coordination. Notably Mangematin (1996) demonstrates how technology can exercise an influence on the method of division of labour. The idea of modularity is central to this. A technology is described as modular when it allows the integration of different 7

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

Thomas Loilier . Albéric Tellier

sub-systems (the modules) into various combinations without changing the global architecture of the system (Langlois and Robertson, 1992). The modularity of the system allows teams a real autonomy and the possibility of rapid testing of alternative solutions, favouring a trialand-error style of learning. In terms of coordination, the network of teams is weakly coupled, each team able to work in an independent fashion (need for adaptation between partners is limited) by concentrating its attention on particular components or modules. Moreover, if the developed technologies are complementary, the value of the technology in its entirety is greater than the sum of the value of the individual modules, this particularity creating an intrinsic spur to innovation (Mangematin, 1996).

THE CREATION OF TRUST IN VIRTUAL INNOVATION NETWORKS The trust acts within the networks take the form of commits which, in the innovation projects, come together in a dialectic of dyadic giving. The dialectic introduces reciprocity into the exchange already analysed, that exists in the relationship between participants of innovation in general (Bouty, 1999; Ferrary, 2002) and those of open source software in particular (Loilier, 2002). The gift mechanism, notably analysed by Mauss (1950) in anthropology, and later by Perroux (1960) in economics, breaks down into three steps: giving, receiving and then giving back. It suits the innovation act because it is itself a bet: one does not assume an assured recompense. He who receives the gift can chose to accept or reject it. If he accepts it, he will, in his turn, give, in order to rebalance the relationship: he gives back. After evaluation of this return gift, a new cycle can then be set in motion. We watch, then, a progressive process of engagement that builds confidence, as shown by Gomez, Korine and Masclef (2003) in the case of the Renault-Nissan alliance. The rationality of the gift is therefore ambivalent insofar as: — any gift assumes trust because the giver finds it impossible to evaluate a priori the value of the eventual counter-gift. To make a gift is thus an uncertain act that is far removed from strict economic rationality; — the gift is not disinterested, insofar as it assumes a counter-gift. The gift «gives individuals a personal motivation that permits the contribution of everyone in the correct unfolding of exchanges at the collective level» (Douglas, 1989: 111). Furthermore, Perroux (1960) has demonstrated that, under certain conditions, gift logic can certainly reinforce the mercantile order. The problem posed by the distance between the participants of the innovation lies in the difficulty in meeting face-to-face or, more generally, in meeting one another personally. How can one speak of the value of the counter-gift when one does not know the other party? Even if ICT have proved themselves powerful means of communication, it is largely accepted that the construction of personal trust comes about primarily through face-to-face interaction and direct exchanges 8

Can You Trust Someone You Do Not See? The Case of Open-Source Software Development

between participants. Thus this form of trust is less developed in virtual networks. These networks call more upon system trust and, more particularly, upon institutional trust in order to mitigate the anonymity of the participants. As shown by Zucker (1986), the latter in effect allows the protagonists to separate themselves while guaranteeing either the identity and quality of the intermediary or respect and quality through shared norms. It is important to note here that this higher-level trust does not replace personal trust (because in the final analysis it is indeed individuals who make the exchanges) but enables its generation by socialising the exchange. This is not done outside the existing context but rather becomes embedded in the context, and it is this embedding which produces the trust. If the participants cannot be close through personal acquaintance, they will become so through mutual knowledge of a third party or institution (a rule, a norm, etc.) which will recreate a social connection and thus proximity. It should be understood that this proximity is all the more efficient for everyone knowing the institution and conforming with its norms (Mangematin, 2003)6. How does one manage to create a favourable context for these acts of trust? Analysing the works that have sought to describe the necessary conditions for the production of trust within virtual organisations (Handy, 1995), technological cooperation (Rallet and Torre, 2001; Ingham and Mothe, 2003), virtual global teams (Jarvenpaa and Leidner, 1999; Lurey and Raisinghani, 2001), virtual R&D teams (Duarte and Snyder, 1999; Maznevski and Chudoba, 2000; Nemiro, 2000; Letaief and Favier, 2003) or, more broadly speaking, in hybrid forms (Nohria and Eccles, 1992; Mangematin, 1999; Moon and Sproull, 2000), it is possible to highlight nine conditions for trust creation. Table 2 lays out these conditions. This discussion will be followed by a study of the workings of projectteams in the open-source software community, most particularly those dedicated to the Linux project. Our objective is to confirm the presence or absence of the conditions enumerated in order to analyse the methods of creating (Table 1) trust between “stranger” participants.

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

6. Cook and Luo (2003), following on particularly from Ho and Weigelt (2001), show how norms can be used as a force for trust in the context of on-line purchases. In this case, norms permit a transfer of trust from a third-party (the organisation that guarantees the transaction) to an unknown entity (in this case, the seller). This transfer process is only possible if the buyer is able to identify a verified origin for such trust and to establish the existence of a trust connection between the origin of trust and the unknown partner.

CASE OUTLINE AND RESEARCH METHODOLOGY The second part offers an opportunity to review the history of opensource software and to present a mechanism for the selection and categorisation for secondary data.

CASE OUTLINE: OPEN-SOURCE SOFTWARE DEVELOPMENT AND THE LINUX PROJECT Appearing in the middle of the 1980s, open-source software today marshals several thousand independent programmers. The study of the relationships uniting these geographically dispersed IT specialists has led to the adoption of the term “community” or “network communi9

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

7. It is the reason why a number of versions of Unix exist, which are not always compatible, and why the history of this operating system is rather complicated. The interested reader can refer to Logerot’s work (2003).

Thomas Loilier . Albéric Tellier

ty” to characterise this innovative model which intrigues observers and researchers. The history of open-source software is in fact inseparable from that of Unix, the operating system developed since the end of the 1960s in the laboratories of Bell, the subsidiary of AT&T (Logerot, 2003). Holding a monopolistic position within the telecommunications sector, AT&T undertook, at the behest of the US federal government, not to expand into the IT sector (hardware and software). It is for this reason that, from 1975 onwards, the company offered universities and research centres free access to the Unix source code. One of the major consequences of this availability is that Unix development was largely the product of its initial users, who put forward a significant number of versions7. However, the dismantling of AT&T into eight distinct companies allowed the company, in 1984, to commercialise Unix System V and to put an end to free access to the source code. In the same year, Richard Stallman, a former researcher at the Massachusetts Institute of Technology (MIT) artificial intelligence laboratory, decided to develop a completely free operating system that would be compatible with Unix. He christened the project “GNU” for “Gnu is not Unix”. In 1985, Stallman created the Free Software Foundation, in order to, firstly, raise funds for the GNU project and, secondly, to commercialise copies of the open-source software bundled with a group of related offerings such as hard copies of the user manuals, technical support, CD installation, etc.

Table 2. Conditions for producing trust in distant networks Conditions

Main arguments put forward

1. Clear composition and identification of the work group around a common object 2. Definition of objectives and time-scales

The team members can only trust the individuals that they know, whom they see working. This condition tends to limit the size of innovation teams. Trust requires that the work be limited in terms of time and/or a clear objective (Jarvenpaa and Leidner, 1999). “Unlimited” trust is unrealistic (Handy, 1995). Moreover, the clarification of objectives increases the efficacy and creativity of virtual teams (Lurey and Raisinghani, 2001; Nemiro, 2001). Globally, the less the project is structured, the more difficult is remote cooperation. The sense of trust is closely related to the ability to learn from others in a work exchange carried out within the collective project (Handy, 1995; Ingham and Mothe, 2003). Throughout the project, it must be possible for members to meet one another (Handy, 1995), to interact (Jarvenpaa and Leidner, 1999; Nohria and Eccles, 1992). In addition, these interpersonal bonds help creativity (Nemiro, 2001; Letaief and Favier 2003). Planning meeting opportunities increases the efficacy of the work accomplished (Maznevski and Chudoba, 2000). The participants tend to trust partners with whom they used to working. “Organisational” proximity (Rallet and Torre, 2001), that is to say previous relationships based on professional connections, generates trust. Each project member must know the commitments and obligations of his partners (Handy, 1995). When a network participant does not produce that for which he was brought into the team, either through guile or because of a lack of skill, it must be possible to supplant him (Handy, 1995). The network can function with a single leader or a group of leaders. In the latter case, the skill sets must be clearly defined (Handy, 1995).

3. Establishment of learning mechanisms 4. Establishment of the possibility of contact between members

5. Previous relationships based on professional connections 6. Definition of commitments and obligations for each member 7. Establishment of sanction and eviction procedures 8. Definition of project leader groups who have authority over the rest of the network 9. Creation of routines common to community members

10

The routines remind one of certain givens (background expectations), mark out the range of possibilities (common vision) and the interpretation of the actions of other members.

Can You Trust Someone You Do Not See? The Case of Open-Source Software Development

Stallman’s aim was to offer an alternative to the proprietary logic that was then in the process of establishing itself in the IT world. He defined a new type of licence, the GNU General Public Licence (GNU-GPL), under which the source code owner gave users the right to copy, distribute and modify it. In order to guarantee this level of freedom, the software was protected by copyleft (the opposite of copyright) which forbade the concealing of the software source code as well as all derivatives thereof. Thus, within a global rationale of value creation, each user could improve the software he received (freely or otherwise) and so give back to the community that which it had given him8. Gradually a certain number of so-called open source projects, and sites dedicated to the GNU community, began to develop. Their goal was to create complementary programmes and to enable the transfer of each user’s experience. In the same way, different open source licences were put forward (Lesser General Public Licence—LGPL, Berkeley Software Design—BSD etc), even if the GNU-GPL remained by far the most widely used (Mangolte, 2003: 2). By 1990, a significant number of Stallman’s operating system’s constituent elements had been created. However, delays had been encountered in the conception of the system’s kernel. However, in 1991, Linus Torvalds, a Finnish student at the University of Helsinki, modified the Unix system in order that it might work on micro-computers. As soon as the lines of code were distributed on the Internet, he quickly began to receive improvements from surfer-programmers that he integrated into the operating system, which he christened Linux (the X is a reference to Unix). In particular, by combining Linux with GNU elements, the programmers managed to create a completely free system which could function on any computer9. In March 1994, Torvalds published version 1.0 of the core Linux (Linux Kernel) with on-line support, which was soon followed by other, increasingly refined versions, including greater and greater functionality. Today Linux is an operating system made up of elements with diverse origins, most notably developed by the open source community. The system kernel is a file that is loaded in memory during the boot process. It contains the drivers necessary for the interfacing between the user application and the computer. The kernel is constantly available in two versions: one so-called production version (for use) and another, so-called development, version which is designed to be improved upon. Linus Torvalds is the only person permitted to approve modifications to the kernel programme. The nerve centre of the Linux community is the Internet site http://www.kernel.org (Logerot, 2003: 27-31). In July 2002, Linux Kernel (version 2.5.25) represented over three million lines of code and 2,263 contributors were named (Ghosh and David, 2003). In 2003, Linux was the operating system on 13.7% of the world’s IT servers (Ferrary and Vidal, 2004: 2). The second wave of development of the Linux environment consisted of offering a catalogue of products relating to quality. The range of open source software is today quite well rounded: graphical interface, word processing, spread-sheets, image processing, graphics treatment, database management, etc. However it would erroneous to think

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

8. Any user of an open source software has the possibility of freely acquiring it (the gift), but he is also invited to provide a “counter-gift” which can take three forms: contributing to the durability of the product by mechanically increasing its number of followers; testing the product and thus enabling the whole community of users to benefit from its testing; and creating open source programmes based on copyleft, which will strengthen the open source offering (Loilier, 2002).

9. Thus Linux is the equivalent of a modified version of the GNU operating system through a substitution of one kernel for another. There it would be more accurate to speak of the GNU/Linux operating system, as demanded by Stallman.

11

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

Thomas Loilier . Albéric Tellier

that the philosophy behind the GNU/Linux project is purely philanthropic and community-focused: it is similar to a hybrid rationale, linking philanthropic acts with mercantile services. Around the open source software community gravitate a range of companies with a commercial focus. After the arrival of many IT players such as IBM, Intel, Dell, HP and specialist distributors, IT service consultancies have also taken the step. By proposing tailor-made offerings, they have facilitated a huge expansion of the market. Linux, the open source software inspired by community spirit, has started to become a truly economic concern. Today, several distinct sub-communities exist that are inseparable from some very clearly identified, and sometimes competing, projects: the OpenOffice project (to develop a suite of office tools to compete with Microsoft Office), the Apache project (free web server), Sendmail (messaging tool), etc. There were more than 72,000 open source software projects referenced on Sourceforge.net in December 2003. The size and life-span of the project-teams that make up the open-source community vary greatly because most of them disappear when the objectives of the project have been achieved. Within this community, the sources used permit us to analyse more precisely the functioning of the teams dedicated to the Linux operating system, its kernel, and the Freenet project (peer-to-peer network software).

METHODOLOGY FOR THE COLLECTION AND ANALYSIS OF DATA Our observation relies upon a reinterpretation of studies carried out on the open source community. It seems by now largely accepted to produce research based exclusively on secondary data. Weick’s article (1993) on the Mann Gulch fire, which relies exclusively on Maclean’s work, Young Men and Fire, is a flagrant example. The researcher’s work then becomes an exercise in reinterpretation of empirical materials produced by others. The elaboration that follows is in part aimed at justifying recourse to such materials and to outline the way in which the data has been selected, and in part to clarify the process of categorisation and codification by which we analyse the data and order the lessons provided by the case.

10. This significant volume of data is without doubt also a result of the goodwill of the participants themselves, who consider transparency central to their activity and who demonstrate great interest in the analysis of social sciences researchers. One must also identify here an illustration of the composition of this community: it is above all fuelled by researchers from university computer sciences research centres that willing welcome the “scientific intrusions” of their social sciences colleagues.

12

CHOICE OF METHODOLOGY AND SELECTION OF DATA The choice of reinterpretation can be justified at two levels: the object studied and the variety of data available. The case of open source software (and particularly that of the Linux project) is the subject of sustained attention on the part of researchers into organisation. This attention has translated in recent years into a significant amount of collected data10, notably in special editions of academic journals (particularly that of Research Policy in 2003), in regular articles in these same journals and other dedicated journals (particularly First Monday—Peer-reviewed Journal on the Internet). The quantity of this

Can You Trust Someone You Do Not See? The Case of Open-Source Software Development

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

empirical material encourages a reuse of it and a reworking of its interpretation. Furthermore, it is instructive to note that the large number of empirical studies is matched by a wide variety of research objectives, of modes of data production and of data type. This variety ensures a relatively reliable global view of the open source software network space and enables the use of triangulation techniques when necessary to assure the robustness of the interpretative element of the research. In concrete terms, four principle data sources have been favoured: the FLOSS project (2002); the analysis of Ghosh and David (2003), Krishnamurthy’s empirical study (2002) and single-case analysis of von Krogh, Spaeth and Lakhani (2003). These are presented in detail in the Appendix notes and have been buttressed from time to time by other academic works on the open source universe, which are systemically noted in the sub-section dedicated to the results of the analysis. Furthermore, different open source community sites, press articles and mass-market general publications have occasionally been used. The use of secondary data does, however, entail a strict selection procedure for the empirical material. It is undoubtedly true that the quality of the data used is the best indicator of the quality of the reinterpretation advanced. Stewart (1984) suggests a six-point systematic evaluation framework for secondary data sources. It then becomes a question of the researcher-user being capable of replying without significant difficulty to the six questions detailed in Table 3, this ease of response being an indicator of the quality of the data under consideration. The Appendix shows clearly that the four principal secondary data sources used permitted clear and concise responses to at least five of the six questions posed by Stewart (1984) and therefore demonstrates the high quality of the data sources.

DATA CATEGORISATION AND CODIFICATION The aim of the research is to understand how project-teams made up of geographically dispersed individuals manage to create and maintain a sense of trust between the members. The conditions enumerated above (Table 2) have been used as categories that are, a priori (Huberman and Miles, 1991), sufficiently precise not to require further redefinition (Lincoln and Guba, 1985) and have been presented as themes. The choice of theme as an extension of a category relates to the method used for the case study (comparison of secondary data) and the materials used (research articles with diverse objectives) (Allard-Poesi, Druker-Godard and Ehlinger, 2003: 461). The content of the different texts used has then been segmented into analysis units, which have then been classified into the defined categories. The chosen analysis units are parts of sentences, whole sentences and even groups of sentences with a bearing on the same theme. Thus it is a question of groups of meaning (Allard-Poesi, 2003), the use of which is consistent with the research goal, which is to 13

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

Thomas Loilier . Albéric Tellier

describe, understand and analyse the functioning of virtual projectteams. The size of the analysis units has been validated by the two criteria proposed by Lincoln and Guba (1985: 345); the selected analysis unit must help develop an understanding of, to make sense of the research questions posed; furthermore, the unit must be open to interpretation even in the absence of additional information. The inference presumed to link the selected units to the respective categories is one of inclusion (X unit is an example of Y category). The process of attribution of an analysis unit to a category takes place without interpretation. It is therefore an open (Strauss and Corbin, 1990) or descriptive (Huberman and Miles, 1991) code system. Finally, the selected documents have been subjected to «qualitative thematic analysis» (Bardin, 1993: 148), designed to confirm the presence or absence of the categories by taking into consideration the context in which the text was written (notably, the aims of the article and any editorial constraints) (Allard-Poesi, Druker-Godard and Ehlinger, 2003: 460-463). The empirical material has been processed and synthesised by means of a non-ordered matrix (Huberman and Miles, 1991). The protocol has been tested by a process of double-coding (Weber, 1990). This consists of confirming the definition of the analysis units and their classification into categories (inter-coder reliability) and dealing with any divergences. The result of this descriptive codification and its analysis are presented below.

TRUST IN THE OPEN SOURCE COMMUNITY: RESULTS AND DISCUSSION In this third part, the results of the categorisation of selected data are first presented. These then form the basis of a discussion that offers an opportunity to consider the initial question and to assess the external validity of the case.

CONDITIONS FOR THE CREATION OF TRUST IN THE OPEN SOURCE COMMUNITY: RESULTS In order to structure our analysis, we have distinguished between the conditions giving rise to the emergence of cooperative behaviour (con-

Table 3. Matrix for the systematic evaluation of secondary data* 1. 2. 3. 4. 5. 6.

What was the purpose of the study? Who was responsible for the data collection? What information has been gathered? When was the information gathered? How was the information obtained? How consistent is the information with other information?

*: Stewart (1984).

14

Can You Trust Someone You Do Not See? The Case of Open-Source Software Development

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

ditions 1 to 5), and those control and guidance mechanisms that allow for sanctions and facilitate the functioning of the community (conditions 6 to 9). DEVELOPMENT OF TRUST WITHIN THE COMMUNITY The first two conditions [1; 2]11 underline the need to structure virtual innovation projects. On this point, the analysis of the workings of the Linux community demonstrates firstly that the size of developer teams is rather small [1]. In version 1.0 of the Linux Kernel, 76.6% of the modules were developed by teams of less than 10 people (Ghosh and David, 2003). This multiplicity of small teams is made possible by the high level of modularity within the project, which facilitates specialisation and development without the constraints of coordination (Moon and Sproull, 2000), because it is the general architecture of the system that ensures overall coherence. Moreover, the number of developers working on several modules is very low. In all the version of the Linux Kernel, more than 70% of code authors worked only on one module (Ghosh and David, 2003). More generally, only 5% of open source programme developers are involved in six projects or more simultaneously, 56% working only on one or two projects (Ghosh, Glott, Krieger and Robles, 2002). If the primary aim of the mailing lists is to inform members on technical questions, they also play a prominent role in the organisation of projects and the distribution of tasks [2]. The mailing list for the core Kernel includes more than 3,500 recipients and the lists dedicated to particular elements of the Kernel (subsystems) are evolving (Hertel, Nierder and Herrmann, 2003). On top of this, some sites centralise projects and class them in terms of their relative stages of development. For example, Sourceforge.net is a platform that was created with the aim of referencing the open source projects and of facilitating collaboration between developers, in particular offering development tools and managing discussion forums (Garcia and Steinmueller, 2003: 10). The next three conditions [3; 4; 5] relate to the nature of the relationships between the members. The use of standards of communications (netiquette, guidelines), the systematic publication of studies, the archiving of questions asked (FAQ) and problem-solving pages, facilitate access to information and constitute real, and very broadly used, learning mechanisms [3]: each open source software project has on average two dedicated discussion forums and two mailing lists (Krishnamurthy, 2002). However, it must be stressed that the modularity considerably reduces the need for communication in development work. According Ghosh and David (2003), it is false to believe that the development, within the Linux project, (and more broadly within open source projects), is truly collaborative. Most of the modules are created by only one or two developers. And yet, the code writers do increase the amount of electronic contact with community members [4]. In version 2.0.30 of the Linux Kernel, 75% of code writers exchanged information with more than 50 community members; 30% having more than 150 interlocutors (Ghosh and David, 2003). In other words, the technical work does not require frequent exchanges and yet these exchanges

11. The numbers in square brackets refer to the coding of the categories found in Table 2.

15

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

12. Edwards (2001) thus differentiates between learners, new entrants who wish to join the community and insiders, members who actively participate in projects and enjoy a technical reputation.

Thomas Loilier . Albéric Tellier

take place. This need to communicate with community members, which is not necessitated by the technical requirements of the development, supports the theory that the participants actively seek to socialise these exchanges. The particularity of the Linux case comes rather from the way in which these exchange are effectuated [4]. Even though meetings are organised throughout the world to allow community members to meet in person, the participants prefer electronic means of communication. Given that the teams are completely dispersed, and the team sizes and number of projects joined by developers are limited, the participants seem not to exploit professional connections in the construction of the team. This does not however suggest the absence of an evaluation of the competencies of members, or of the hierarchy. Firstly, each writer whose contribution is integrated into the source code can give his name, electronic address and any organisation that supports him. This system of citation permits the acknowledgement by one’s peers of any technical expertise, enhances the reputation of the author and facilitates his integration into other projects [5] (Harhoff, Henkel and Von Hippel, 2003). 94% of open source software developers say they put their name to their contributions (Ghosh, Glott, Krieger and Robles, 2002). In certain projects (e.g., Debian) the person given the responsibility for a module is given the privilege of having an official electronic address (i.e., [email protected]) in order to signal his status to the rest of the community and to enhance his reputation (Ferrary and Vidal, 2004: 13). Secondly, observation of the working of discussion forums and mailing lists (von Krogh, Spaeth and Lakhani, 2003) shows that new entrants are monitored for several weeks, even several months, before being truly integrated into the discussions. During this evaluation stage, a genuine process of “signing-up” (joining script) to the community’s values and habits (Garcia and Steinmueller, 2003), the new participants must demonstrate their skill by making a significant contribution, that is to say by giving to the community before being permitted to take from it12. In the case of the Apache project, even if all the developers can contribute freely to the project, only those who have demonstrated specific skills are given specific responsibilities, based on a vote by the project founders (Markus, Manville and Agres, 2000: 21). The five conditions relating to the development of trust are ultimately well demonstrated in the Linux community, even if the contacts between the individual members are essentially via ICT. Thereafter, it is important to examine the tools of trust management that can act as control and piloting mechanisms (Table 2, conditions 6 to 9). CONTROL AND LEADERSHIP OF OPEN SOURCE PROJECTS One of the particularities of the open source software community comes from the systematic communication via internet of obligations, rules and other norms of conduct to which the members must adhere [6] (Hertel, Nierder and Herrmann, 2003). First it must be stressed that, during the community’s early years, the founders made efforts to define members’ rights and obligations. It was first necessary to define

16

Can You Trust Someone You Do Not See? The Case of Open-Source Software Development

the conditions to be fulfilled in order that the software might qualify as open source. The Open Source Definition specifies “9 commandments of open source that must be respected in all projects” (Müller, Yamagata, Wall and Dougherty, 2001). The opportunities offered to the users of open source software was also defined13. In short, behaviour required within discussions forums, and more specifically when asking questions, is controlled. These rules of conduct are drawn together in the document “How to ask questions intelligently” that is available on various sites (e.g., the French Linux site). Certain forums have pages dedicated to the obligations of their members (guidelines). The community spirit that reigns inside these networks is not sufficient to avoid opportunistic behaviour and disagreements over the orientation of development to be favoured. Opportunism is controlled by a technology infrastructure that can rapidly alert members to the noncompliance to the community rules by particular members [7]. The network’s success will in part be linked to the way in which information exchange practices have been encouraged and the withholding of information penalised (Moon and Sproull, 2000). The penalties target reputation. Three levels of penalties exist: 1/ “Read the F… Manual: the individual is invited to reread documentary resources; 2/ “Death Penalty”: the individual is considered undesirable and is ignored, at least for a while, in the discussion forums; 3/ “Reputation die and grow hard”: the undesirable person is referenced on sites accessible via search engines. It then becomes very difficult for him to join new teams or discussion forums (Tayon, 2002). Here it can be added that Stallman’s proposed mission probably encouraged cultural integration. Indeed, the open source software community is built around the aim of offering an alternative model to that of proprietary software publishers (particularly Microsoft). This aim and the presence of a clearly identified adversary tend to reinforce cohesion. Moreover, studies carried out on the motivation of open source project members have underlined the stated wish to take part in the battle against proprietary software and the political dimension of the community (Bezroukov, 1999 ; Ghosh et al., 2002 ; Hertel et al., 2003). Disagreements are frequent within the network and often relate to preferred technical options (Garcia and Steinmueller, 2003). Even if the Linux community has been categorised as a “bazaar” model (Raymond, 1998), the analysis of its workings show the existence of leader groups that have authority over the rest of the network [8]. First of all, the community is organised into a hierarchy with a strategic core (Lorenzoni and Baden-Fuller, 1995), the Free Software Foundation, which plays a coordinating role, and from which originate more than 17% of all the projects developed by the community (Ghosh and Prakash, 2000). This foundation also plays a controlling role because it insures respect of the GNU licence (particularly of copyleft), encourages members to inform it of any violation of this licence and undertakes any legal action (O’Mahony, 2003: 1187-1188). Next, the projects are generally led by a limited number of administrators (in fact, maintainers) who control development and decide whether or not to integrate new contributions. The development cycle of an open source

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

13. From this derives four levels of freedom: 0/ the execution of the software is free, whatever its usage; 1/ the study of the workings of the software is free and therefore adaptable to the needs of each individual; 2/ the distribution of the software is free; 3/ the improvement, modification and communication of the software is free.

17

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

14. In effect, the open source projects respect the rule of forking: any individual who disagrees with the decisions taken by the administrator may create a new project to exploit other technical choices. Raymond (1999) notes however that this possibility is almost never exploited by members, who consider that to do so may weaken the community.

Thomas Loilier . Albéric Tellier

software general involves the following steps (Edwards, 2001): 1/ a leader suggests a version 0 of a programme, detailing his objectives and providing the source code; 2/ contributors freely decide whether to join the project (the creation of a virtual team), download the elements and identify problems and possible improvements; 3/ suggestions are sent to the leader and the virtual team via a dedicated mailing list; 4/ corrections are discussed, and sometimes evaluated by means of an on-line vote; 5/ the leader incorporates the validated solutions and presents a downloadable version 1, etc. Krishnamurthy’s study (2002) on one hundred open source projects showed that there were on average two administrators per project (the modal average being 1). For example, Linus Torvalds, who describes himself as a “benevolent dictator” (Hertel, Nierder and Herrmann, 2003: 1161), is the only person who can accept the integration of new elements (patches) into the Kernel module. Thus the Linux community is lead by various central groups that originate the projects and of which the technical expertise is recognised. These units define the basic rules controlling the relationships between members, direct the tasks carried out on the periphery of the unit and facilitate distribution over the network, acting as the nexus between participants and information distributors. Garcia and Steinmueller (2003) speak in relation to this of distributed authority within the community. In certain cases, a project founder delegates part of his authority to different administrators who are responsible for the development of the related modules. It is thus that Linus Torvalds surrounded himself with trusted lieutenants to create different patches and to be responsible for selecting community member proposals (Markus, Manville and Agres, 2000: 22). We have then here a group of leaders with clearly defined skill sets [8]. However the authority is only legitimate and not statutory because, officially, each individual is free to join or leave a development team14. Finally, the initial formalisation of members’ rights and obligations, the use of communication standards, the communication of reprehensible practices and the control asserted by the leader groups go to create shared routines [9] and, furthermore, allow the Linux network to be seen as a community of practice (Wenger, 1998; Loilier, 2002), given structure by a historic project (the GNU project), a shared commitment (copyleft and the four levels of community freedom) and a shared repertoire (tangible resources: prototypes, mock-ups etc; or intangible resources: routines, procedures, symbols, etc). The nine conditions outlined in this text (Table 2) have thus been updated in the case study. They are now the focus of a discussion that allows us to analyse the nature of the resulting trust.

THE NATURE AND ROLE OF TRUST IN THE LINUX COMMUNITY: DISCUSSION THE CONTRIBUTION OF THE RESEARCH The elements laid out below offer a very analytical perspective on the process of trust within the open source software community. The first contribution of this research is by way of an explicit return to the found18

Can You Trust Someone You Do Not See? The Case of Open-Source Software Development

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

ing question of our consideration of this subject: in what conditions can trust be a method of coordination when there is no direct and local interaction between the participants? Our response, in the light of the analysis of the case of open source software, is as follows: the logic of dyadic giving that governs the innovation teams and the reputation from which certain members can benefit demonstrate that a relational trust can exist within a team. Nevertheless, this trust proves insufficient to create an effective method of coordination. This method relies upon institutional trust resulting from the signals given out by the organisation (here principally the rules and ethical codes) that are complemented by control procedures. Thus, trust can exist without face-toface contact given the double condition of the existence of a high level of institutional trust and the presence of a sanctioning control mechanism. The developments that follow return to this double condition and to the nature of the relationship between personal trust and institutional trust. It seems to us that the geographic dispersal of the participants in the open source software projects limits the personal trust that develops with the relationship. The result goes against the findings of Jarvenpaa and Leidner (1999) who have shown that personal trust can be maintained and developed within virtual teams through use of ICT. However, the projects studied by these authors meaningfully differ from those analysed in this work. Firstly, the objective and the timescales are defined right away and do not require the co-creation of specific elements. Secondly, the created teams are similar to convergent networks, in the sense given by Callon, Laredo, Rabeharisoa, Gonard and Leray (1992). In this type of situation, each participant has a clear understanding of the team composition, and knows of the possibility of contacting all the members. Thus, the density of the relational network is maximal because all the elements are directly interconnected (Aldrich and Zimmer, 1986). By contrast, in the open source community, the modularity of projects, the tasks carried out by the leaders, the enormous use of asynchronous communication methods and the geographical dispersion does not allow each individual clearly to know the make-up of the team dedicated to the project, or to generate contacts with each of its members. In other words, the density of the relational network is notably less. However, the two major drivers (moral or technical) of trust are certainly present in the community. They take the form of an institutional trust (Zucker, 1986; Mangematin, 1999), otherwise known as system trust (Brousseau, Geoffron and Weinstein, 1997). This trust can be qualified as contextual: one does not place confidence in another person but rather in the complete context within which the relationship evolves. This confidence rests on the conviction that the partner will respect the copyleft (and, more generally, the social rules and norms in effect) and no longer on the personality of the co-operators of the system. The trust placed in one of the community members is no longer distinguishable from that inspired by the system. Is this system trust enough? In other words, are the forms of trust (personal and institutional) interchangeable? Zucker (1986) and, later, 19

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

Thomas Loilier . Albéric Tellier

Greenwald and Stiglitz (1992) tended towards an affirmative to this question. Zucker (1986) demonstrated that the disappearance of personal trust is mitigated by the production of institutional trust, but that the inverse was not true. However, our results seem rather to argue in favour of the existence of a complementarity between the two forms of trust, in line with Mangematin’s thinking (1996). Mangematin clearly demonstrates that institutional research cooperation produces personal trust, with researchers and engineers often developing valued personal bonds that rely on the dyadic giving logic. We subscribe to this complementarist line of thought: neither of the two forms of trust is, in itself, enough; the absence of one or other needing to be mitigated by additional explicate or implicate mechanisms. Our analysis gives a clear example of this type of mechanism. The absence (or nearly) of direct and simultaneous (face-to-face or realtime) interactions considerably limits personal trust. This absence is certainly compensated for by a high level of institutional trust but also (and above all) by a formalised control mechanism. It is this combination of institutional trust and control that enables the existence of a high level of performance in the virtual network. Furthermore, we have distanced ourselves from the approaches that favour trust as an alternative to control in preference for an integrationist view. In increasingly disrupted environments, trust can be advantageously supplemented by formal mechanisms (Goold and Campbell, 1987). Sitkin (1995) sets out in particular the importance of formal rules and standardised procedures in the institutionalisation of trust. Brulhart and Favoreu (2003) update the positive influence of controls upon trust in 219 logistical partnerships in the land management and food production sector. In this case, the control comprises two dimensions: monitoring and evaluation (formalisation of procedure), and the formalisation of agreements (use of contracts). Our research thus allows us to extend this result to the sample case of the development of product innovation in the hi-tech sector of information technology. Our research also enables an extension of the results emanating from the integrative school of thought. Implicitly, the participants concentrate more on the control systems that produce information and understanding than on a control system seen as a system of surveillance and sanction. This so-called rational control carries negative connotations. The formal control mechanisms are often seen by those subject to them as a lack of trust on the part of the partner. Conversely, the participants subject to these controls themselves place less confidence in their partner (Argyris, 1952). In their acerbic critique of transaction cost economics, Goshal and Moran (1996) present a damning assessment of rational control. Relying on a review of existing literature, they particularly note: — that rational control engenders a sense of defiance towards the controllers by the controlled; — that it threatens the motivation and engagement of the controlled; — that it damages the image the controllers have of themselves. However our results show that this sanction control can be used without de-motivating the Linux community members. A sanction and evic20

Can You Trust Someone You Do Not See? The Case of Open-Source Software Development

tion procedure clearly exists (Reputation die and grow hard) that enables a limiting of the risk that an undesirable personal may manage to join new teams and/or discussion forums15. This ex post control is however only effective because it complements a global system of control similar to a social control (Ouchi, 1979). Efficient in clans, this form of control aims to create a normative integration that spurs individuals to internalise the values and goals of the organisation. Our analysis seems to show that, in virtual team networks, sanction control can be effectively applied if it is coupled with social control mechanisms. The trust/control complementarity can thus be extended to sanction control. This gives an original result insofar as, up until now, this form of control and trust have been considered antinomic. It seems to us that one can postulate the hypothesis that this sanction control is one of the production conditions of personal trust within the teams studied. When an opportunistic or incompetent individual is detected, he is ejected thanks to the sanction mechanism. Thus it proves possible to trust an individual based on his reputation because this reputation depends upon the sanction mechanisms (Orléan, 1994: 18). THE EXTERNAL VALIDITITY OF THE CASE STUDY The second part of this discussion of the results explores the validity of the research beyond the case study. Can this capacity to generate trust without face-to-face contact within an innovation context be replicated and reused in other contexts? If the answer is yes, what are the necessary conditions? Here three strong characteristics of the open source development model must be emphasised: the lower level of implied knowledge within the computer sciences; the systematisation of experimental learning, and the particular organisation of projectteams. It is now accepted that innovation creation relies on putting to work knowledge that is at once both tacit and formalised. The formalised knowledge (explicit, objective) is of a “non-sticky” type16 (von Hippel, 1994) because it can be transmitted and codified without any loss of integrity. Tacit knowledge, conversely, is a form of knowledge that is very difficult to communicate in written form. In fact, formalised knowledge is essentially scientific and can move away from the person who possesses it, while tacit knowledge is intimately tied to its possessor (Reix, 1995). The physical proximity of participants is generally considered a means of spreading the uncodifiable part of knowledge and of limiting the cost of information (e.g. Belis-Bergouignan, 1997). Two characteristics explain at least in part the freeing from geographical constraints. Firstly, information technology, and particularly software development, is a sector in which the tacit knowledge element is considered to be very small. Secondly, the participants are able to exploit three elements necessary for codification (Cowan and Foray, 1997): a communally accepted grammar (rules system); a shared vocabulary, and a repertoire of sentences constructed from the first two elements. These three elements are, in effect, explicitly present within the open source community with, respectively, a common programming language (the C language); algorithm-building skills shared by all the participants17, and the

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

15. In practice, this person is referenced on Internet sites that can be reached via search engines.

16. The stickiness of information takes into account its cost of acquisition, transfer and use by other participants of the network. This stickiness is a function of three variables: the nature of the information itself, the quantity of information to be exchanged and the intellectual capabilities of the participants concerned.

17. The study carried out within the FLOSS projected showed that 70% of developers hold a university degree and that 44.5% are programmers and analyst programmers (Ghosh et al., 2002).

21

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

18. See in particular the early works of von Hippel (1986) on lead users.

19. In 1997, teams made up of 2 to 5 developers were responsible for 40% of all of the community’s projects, to which one should add 5% of projects that were managed by a single individual. In July 2002, projects handled by a maximum of 5 people represented more than 31% of the total number of projects developed. Moreover, it is important to note that this massive use of small teams (made up of a maximum of 5 participants) was even more significant in the early days of the community: in March 1994 (first version of Linux), these teams made up more than 65% of the projects developed (Ghosh and David, 2003).

22

Thomas Loilier . Albéric Tellier

core Kernel written by Linus Torvalds (Cohendet, Créplet and Dupouët, 2003). Thus one can easily understand that technical trust does not require face-to-face contact to exist within the community insofar as the vast majority of necessary skills for the effective realisation of the project are accessible remotely via Internet. Next, the huge use of ICT in the innovation process has permitted the development of learning between community members, particularly through the construction of problem-solving sites and archives of questions asked (FAQ). However, it is without doubt experimental learning (Lundvall, 2000) that is at the heart of the development process. If this ability deliberately to test out innovation with users during the production process is not new18, with open source software it has reached a very high level of intensity. This capacity is linked to the fact that, from the project’s inception, the developers have also been the users of the applications produced and have thus been able simultaneously to identify problems and to suggest solutions. This lack of separation between innovators and users (Dan-Nguyen and Pénard, 1999; Loilier, 2002) has made experimental learning particularly efficient thanks to the communications support system provided by ITC, and this despite the absence of face-to-face contact. Finally, the organisation of open source community projects is very particular. Two related characteristics are essential to an understanding of the working of virtual teams in general and the creation of trust in particular: the size of the teams and the modularity of the projects. The very detailed analysis of Ghosh and David (2003) on the community of developers for the Linux Kernel underlined the smallness of developer teams for these projects. In large part, the teams are not made up of more than five developers, a significant number of modules being the work of only one developer19. Furthermore, more than 70% of developers only take part in one development project within the community. This innovation process, which mobilises a large number of small teams, is only possible because the Linux project is modular. The modularity is a direct result of the initial objectives of Stallman’s project, which was to come up with a multi-task system (allowing the simultaneous launching of several applications) (Mangolte, 2003: 4). This aim required a strict separation of the Kernel, which manages the access to the computer, from the user applications, which do not access the computer resources directly (Logerot, 2003: 31). Firstly, the programmes can thus be developed independently of one another. Secondly, efforts were necessary to standardise the links (the interface) between the applications and the computer. It is, in the end, this standardised interface that ensures the coherence of the whole, allows for the independence of teams, and, more broadly speaking, for a development of the Linux project without any real task planning. In the case of open source software, one rediscovers a phenomenon already observed in other branches of the computer sciences, particularly that of hardware (Baldwin and Clark, 1997; Langlois, 2002): the modularity offers the module designer great freedom of design because he does not have to communicate his decisions to the designers of other modules or to the system architect. However, the presence of a leader, who

Can You Trust Someone You Do Not See? The Case of Open-Source Software Development

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

has a monopoly over the changes to the Kernel and who adds modules incrementally, enables the embedding of the cooperation rational into the technology. The module designer must in effect conform to the norms of the community and must earn the trust of that community in order to see his work included. Finally, the organisation of projects, the limited team size and the modularity explain why there is relatively little need for coordination within a project. As a result, the need for personal trust (understood as a coordination tool) is also relatively low. In other words, if the open source community has evolved without any real need for face-to-face contacts, it is at least in part because the need for coordination within each project is itself low.

CONCLUSION In concluding this article, it appears that the trust at work within the virtual innovation networks of the open source software community is based not on the development of interpersonal relationships between individuals but depends on a higher level of trust: system or institutional trust. This does not mean that interpersonal trust (notably in its relational form) does not exist (the exchange dialectic is indeed central to the functioning of the teams studied) but its use as a coordination tool relies upon the development of institutional trust. Nevertheless, within this virtual network, institutional trust is not sufficient to create personal trust. It must be complemented by more traditional control mechanisms that combine social and rational controls. The organisational model of open source software, often presented as revolutionary and anarchic, is thus not as disordered as that. Even if one finds oneself presented with a networked organisation, hierarchical bonds still exist, and hence the possibility of giving orders and influencing the behaviour of other members (Josserand, 2001: 18). The trust at work within these terms is not naïve. Control mechanisms are indeed present within this community, effected through social control but also, in a surprising way, through rational control that depends particularly upon very well defined sanction procedures. It is thus possible, for the sake of innovation, to trust one another without face-to-face contacts, by developing an iron-clad system trust which is complemented by a rigorous control system. These results can be likened to works that discuss a trust solution that simultaneously facilitates coordination, co-construction of the intended goal and socialisation of exchanges (reducing the uncertainty regarding participant behaviour during the innovation process). Within the traditional project-team, the comparison of view-points, the disclosure of information strategies and, more broadly, the frequent face-to-face interactions facilitate the creation of interpersonal trust and without doubt constitute informal means of controlling real intentions and partner skill-sets. In other words, trust and informal control evolve within the team. The face-to-face relations provide individuals with opportunities to demonstrate their skills and their capacity to give as much information as they receive, and to deepen their respective knowledge. 23

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

Thomas Loilier . Albéric Tellier

However, in the case of a virtual network, it is not possible to use geographic proximity to generate trust between the partners. Thus, if ICT allows the development of virtual innovation networks, it equally leads to the introduction of totally new organising and regulating modalities, particularly because the iterations, negotiations and compromises between the participants, that are in all innovation projects, are significantly modified. Notably, trust is born outside the team, at a higher level, by reference to practices and norms that are shared by a community, and which include formal sanction procedures. It would however by very bold to attempt to draw a generalisation from this work, for at least two reasons. The first relates to the marked peculiarities of open source software. Firstly, computer science is a sector in which the role of tacit knowledge is considered to be small (which limits the need to resort to face-to-face interactions). Furthermore, the virtual teams dedicated to open source projects can make extensive use of experimental learning because ICT constitutes simultaneously a means (an asset available for purpose of attaining the project objective) and the final product (an asset co-constructed over time) for the user-producers of the projects. Finally, within these small projectteams, the need for coordination is rather limited because of the significant modularity of the projects. The second reason results from the methodological choice made in this research. In effect, the decision principally to direct its focus towards the development of the Linux operating system, an undeniable success, may constitute a major bias. Many other projects are developed within the open source community and not all manage to secure a broad circulation. It is necessary to bear in mind that this community also includes teams that have failed, and has produced software that will never be used. Besides, many projects will not benefit from as much media attention as Linux, in part because of the history and personality of Linus Torvalds, and in part because of the existence for Linux of a clearly identified adversary. In effect, the aim of offering an alternative operating system to that proposed by Microsoft has without doubt reinforced the cohesion of IT developers committed from that moment on to a real mission. This work needs therefore to be enhanced by future research into a sample of projects that are more representative of the open source community. It would be particularly interesting to use sites that reference the projects, like Sourceforge.net, which enable one to make use of primary data such as: start date; project duration; developer numbers, profiles and contact details, etc. There is, without doubt, subject matter for further profitable research, in the bonds that unite the members in this most particular of networks.

Note. The authors would like to thank the three reviewers for the quality of their observations and comments, as well as Gérard Koenig for his most stimulating advice, comments and encouragement.

24

Can You Trust Someone You Do Not See? The Case of Open-Source Software Development

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

Thomas Loilier is an assistant professor at the University of Caen Lower-Normandy (Institut d’Administration des Entreprises). Within CIME (Caen-Innovation-MarchéEntreprise), his field of research is strategic management. In particular, his research concentrates on the management of innovation, as much in its organisational aspects (project-team management) as its strategic ones (the cooperative principle in innovating businesses).

Albéric Tellier is an assistant professor at the University of Caen Lower-Normandy (Institut d’Administration des Entreprises). His field of research within the IAE research centre (CIME) is the management of innovation. His works have focused most notably on the configuration and workings of innovation networks, situations of technological competition and collective strategies for innovation.

REFERENCES Q Aldrich, H. E., and C. Zimmer 1986 Entrepreneurship through Social Networks, in D. L. Sexton and R. W. Smiler (Eds.), The Art of Science of Entrepre-neurship, New York: Ballinger, 3-23.

Q Allard-Poesi, F. 2003 Coder les données, in Y. Giordano (Ed.), Conduire un projet de recherche : une perspective qualitative, Colombelles : EMS, 245-290.

Q Allard-Poesi, F., C. DruckerGodard et S. Ehlinger 2003 Analyses de représentations et de discours, in R. A. Thiétart (Ed.), Méthodes de recherche en management, 2ème édition, Paris : Dunod, 449-475.

Q Belis-Bergouignan, M. C. 1997 Coopérations inter-firmes en R&D et contrainte de proximité : le cas de l’industrie pharmaceutique, Revue d’Economie Industrielle, 81: 3, 59-76.

Q Brousseau, E. 2001

A Second Look at the Cathedral and the Bazaar, First Monday, 4: 12.

Confiance ou contrat, confiance et contrat, in F. Aubert et J.-P. Sylvestre (Eds.), Confiance et rationalité, Versailles : INRA Editions, Les Colloques, 97, 65-80.

Q Boissin, O. 1999 La construction des actifs spécifiques : une analyse critique de la théorie des coûts de transaction, Revue d’Economie Industrielle, 90: 4, 7-24.

Q Bos, N., D. Gergle, J. S. Olson and G. M. Olson 2001

Q Argyris, C. 1952 The Impact of Budgets on People, New-York: Controllership Foundation.

Q Bouty, I. 1999

Managing in an Age of Modularity, Harvard Business Review, 75: 5, 84-93.

Q Bardin, L. 1993

Markets versus Hierarchies: from Ideal Types to Plural Forms, Annual Review of Sociology, 15, 97-118.

Q Bezroukov, N. 1999

Being There versus Seeing There: Trust via Video, Working Paper, CREW, Ann Arbor: University of Michigan, School of Information.

Q Baldwin, C. Y., and K. B. Clark 1997

Q Bradach, J., and R. Eccles 1989

Décision individuelle d’échange au sein des réseaux informels : entreprise, chercheurs et communauté technologique, Actes de la VIIIème Conférence de l’AIMS, ECP, Chatenay-Malabry, 2628 mai.

Q Brousseau, E., P. Geoffron et O. Weinstein 1997 Confiance, connaissances et relations inter-firmes, in B. Guilhon, P. Huard, M. Orillard et J.-B. Zimmermann (Eds.), Economie de la connaissance et organisations : Entreprises, territoires, réseaux, Paris : L’Harmattan, 402-433.

Q Brulhart, F., et C. Favoreu 2003 Les modes de coordination et d’organisation des partenariats inter firmes: exploration du rôle et de l’impact respectifs du contrôle et de la confiance au travers du courant intégratif, XIIème Conférence de l’AIMS, Tunis, Les Côtes de Carthage, 4-6 juin.

L’analyse de contenu, Paris : PUF.

25

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

Q Callon, M., P. Laredo, V. Rabeharisoa, T. Gonard and T. Leray 1992 The Management and Evaluation of Technological Programs and the Dynamics of Techno-economic Networks: The Case of the AFME, Research Policy, 21: 3, 215-236.

Q Chanal, V. 2000 La structuration d’un projet d’innovation par la communication électronique, Actes de la IXème Conférence de l’AIMS, Montpellier, 24-26 mai.

Q Chiles, T. H., and J. F. McMackin 1996 Integrating Variable Risk Preferences, Trust and Transaction Cost Economics, Academy of Management Review, 21: 1, 73-99.

Q Cohendet, P., F. Créplet et O. Dupouët 2003 Innovation organisationnelle, communautés de pratique et communautés épistémiques : le cas de Linux, Revue Française de Gestion, 29: 146, 99-121.

Q Cook, P. C., and W. Luo 2003 The Role of Third-Party Seals in Building Trust Online, e-Service Journal, 2: 3, 71-84.

Q Cowan, R., and D. Foray 1997 The Economics of Codification and the Diffusion of Knowledge, Industrial and Corporate Change, 6: 3, 594-622.

Q Crisp, C. B., and S. L. Jarvenpaa 2000 Trust over Time in Global Virtual Teams, Annual Academy of Management Meeting, Toronto, ON, August 49.

Q Dang-Nguyen, G., et T. Pénard 1999 Don et coopération dans Internet : une nouvelle organisation économique ?, Terminal, 80/81, 95-116.

Q Douglas, M. 1989 Il n’y a pas de don gratuit : Introduction à l’édition anglaise de l’Essai sur le don de M. Mauss, Revue trimestrielle du Mauss, 4: 2, 99-115.

26

Thomas Loilier . Albéric Tellier

Q Duarte, D. L., and N. T. Snyder 1999

Q Ghosh, R. A., and V. V. Prakash 2000

Mastering Virtual Teams: Strategies, Tools, and Techniques That Succeed, San Francisco, CA: Jossey-Bass.

Orbiten Free Software Survey, First Monday, 5: 7.

Q Edwards, K. 2001

Q Ghosh, R. A., R. Glott, B. Krieger and G. Robles 2002

Epistemic Communities, Situated Learning and Open Source Software Development, Working Paper for Epistemic Cultures and the Practice of Interdisciplinarity Workshop, Trondheim: Norges Teknisk- Naturvitenskapelige Universitet.

Free/Libre and Open Source Software: Survey and Study – Part 4: Survey of Developers, FLOSS Final Report, Maastricht : University of Maastricht, International Institute of Infonomics, http://www.infonomics.nl/FLOSS/report/

Q Eisenhardt, K. 1989

Q Giddens, A. 1990

Building Theories from Case Study Research, Academy of Management Review, 14: 4, 532-550.

The Consequences of Modernity, Cambridge, MA: Polity Press.

Q Ferrary, M. 2002

Q Gomez, P.-Y., H. Korine et O. Masclef 2003

Pour une théorie de l’échange dans les réseaux sociaux, un essai sur le don dans les réseaux industriels de la Silicon Valley, in I. Huault (Ed.), La construction sociale de l’entreprise : autour des travaux de Mark Granovetter, Colombelles : EMS, 61-86.

Alliance stratégique et construction de la confiance : le cas Renault-Nissan, in V. Mangematin et C. Thuderoz (Eds.), Des mondes de confiance, Paris : CNRS Editions, 203-218.

Q Ferrary, M., et P. Vidal 2004

Strategies and Styles: the Role of the Center in Managing Diversified Corporations, New-York: Blackwell.

Les leçons de management de la communauté Linux, XIIIème Conférence de l’AIMS, Le Havre, 1-4 juin.

Q Fukuyama, F. 1995 Trust: The social Virtues and the Creation of Prosperity, New York: Free Press.

Q Gallié, E. P. 2003 Une grille d’analyse de l’usage des TIC dans les différentes étapes de la coopération technologique, Sciences de la Société, 59, 118-134.

Q Garcia, J. M., and W. E. Steinmueller 2003 The Open Source Way of Working: a New Paradigm for the Division of Labour in Software Development ?, INK Research Working Paper, SPRU, 1, Brighton: University of Sussex.

Q Goold, M., and A. Campbell 1987

Q Goshal, S., and P. Moran 1996 Bad for Practice: a Critique of the Transaction Cost Theory, Academy of Management Review, 21: 1, 13-47.

Q Greenwald, B., and J. E. Stiglitz 1992 Information, Finance and Markets: the Architecture of Allocative Mechanisms, in V. Zamagni (Ed.), Finance and the Enterprise, London: Academic Press.

Q Handy, C. 1995 Trust and the Virtual Organization, Harvard Business Review, 73: 3, 4050.

Q Ghosh, R. A., and P. A. David 2003

Q Harhoff, D., J. Henkel and E. von Hippel 2003

The Nature and Composition of the Linux Kernel Developer Community: a Dynamic Analysis, Working Paper, NSF Open Source Software Project, Stanford, CA: Stanford Institute for Economic Policy Research.

Profiting from Voluntary Information Spillovers: how Users Benefit by Freely Revealing their Innovations, Research Policy, 32: 10, 1753-1769.

Can You Trust Someone You Do Not See? The Case of Open-Source Software Development

Q Hertel, G., S. Nierder and S. Herrmann 2003 Motivation of Software Developers in Open Source Projects: an Internet-Based Survey of Contributors to the Linux Kernel, Research Policy, 32: 7, 1159-1177.

Q Ho, T. H., and K. Weigelt 2001 Trust Building Among Strangers, Working Paper, 99-008, Philadelphia, PA: University of Pennsylvania, Wharton Marketing Department.

Q Howells, J. 1995 Going Global: the Use of ICT Networks in Research and Development, Research Policy, 24: 2, 169-184.

Q Huberman, A. M. et M. B. Miles 1991 Analyse des données qualitatives, recueil de nouvelles méthodes, Bruxelles : De Boeck Université.

Q Iacono, C. S., and S. Weisband 1997 Developing Trust in Virtual Teams, in . F. Nunamaker, Jr., and R. H. Sprague, Jr. (Eds.), Proceeding of the 30th Hawaii International Conference on System Sciences, Vol. 2, Piscataway, NJ: IEEE, 412-420.

Q Ingham, M., et C. Mothe 2003 Confiance et apprentissages au sein d’une alliance technologique, Revue Française de Gestion, 29: 143, 111-128.

Q Jarvenpaa, S. L., and D. E. Leidner 1999 Communication and Trust in Global Virtual Teams, Organization Science, 10: 6, 791-815.

Q Josserand, E. 2001 L’entreprise en réseau, Paris : Vuibert.

Q Kanawattanachai, P., and Y. Yoo 2002 Dynamic Nature of Trust in Virtual Teams, Journal of Strategic Information Systems, 11, 187-213.

Q Krishnamurthy, S. 2002 Cave or Community? An Empirical Examination of 100 Mature Open Source Projects, First Monday, 7: 6.

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

Q Langlois, R. N. 2002

Q Lundvall, B.-Å. 2000

Modularity in Technology and Organization, Journal of Economic Behavior and Organization, 49: 1, 19-37.

Understanding the Role of Education in the Learning Economy: The Contribution of Economics, in OECD-CERI, Knowledge Management in the Learning Society, Paris, OECD, 11-35.

Q Langlois, R. N., and P. L. Robertson 1992 Networks and Innovation in a Modular System: Lessons from the Microcomputer and Stereo Component Industries, Research Policy, 21: 4, 297-313.

Q Letaief, R., et M. Favier 2003 Vers une meilleure compréhension de la créativité au sein des équipes virtuelles globales, GRH et TIC, Journée d’étude et de recherche, Laboratoire CREPA, Université de Paris Dauphine, mai.

Q Lewicki, R. J., D. J. McAllister and R. J. Bies 1998 Trust and Distrust: New Relationships and Realities, Academy of Management Review, 23: 4, 438-458.

Q Lincoln, Y. S., and E. G. Guba 1985 Naturalistic Inquiry, London: Sage.

Q Lurey, J. S., and M. S. Raisinghani 2001 An Empirical Study of Best Practices in Virtual Teams, Information and Management, 38: 8, 523-544.

Q Maillat, D. 1996 Systèmes territoriaux de production et milieux innovateurs, in OCDE Réseaux d’entreprises et développement local, Paris : Les Editions de l’OCDE, 75-90.

Q Maillat, D. 1998 Organisations productives territorialisées et milieu innovateur, in G. Loinger et J.-C. Némery (Eds.), Recomposition et développement des territoires, Paris : L’Harmattan, 47-68.

Q Mangematin, V. 1996

Virtual Teams: Reaching across Space, Time and Organizations with Technology, New York: Wiley.

The Simultaneous Shaping of Organization and Technology within Co-operative Agreements, in R. Coombs, P. Saviotti, A. Richards et V. Walsh (Eds), Networks and Technology Collaboration, London: Elgar, 119-141.

Q Logerot, P. 2003

Q Mangematin, V. 1999

Linux ou Windows ?, Paris : Dunod.

Gestion de l’innovation : quels enseignements tirer du cas des logiciels libres ?, Finance-Contrôle-Stratégie, 5: 3, 141-168.

La confiance : un mode de coordination dont l’utilisation dépend de ses conditions de production, in C. Thuredoz, V. Mangematin et D. Harrisson (Eds.), La confiance, approches économiques et sociologiques, Paris : Gaëtan Morin, 31-56.

Q Loilier, T., et A. Tellier 2003

Q Mangematin, V. 2003

Quelles configurations pour les réseaux innovateurs ?, in H. Laroche, P. Joffre et F. Fréry (Eds.), Perspectives en management stratégique, Tome 9, Colombelles : EMS, 159-183.

Cléopâtre et son goûteur, in V. Mangematin et C. Thuderoz (Eds.), Des mondes de confiance, Paris : CNRS Editions, 121-126.

Q Lipnack, J., and J. Stamps 1997

Q Loilier, T. 2002

Q Lorenzoni, G., and C. Baden-Fuller 1995 Creating a Strategic Center to Manage a Web of Partners, California Management Review, 37: 3, 146-163.

Q Luhmann, N. 1979 Trust and Power, London: Wiley.

Q Mangolte, P. A. 2003 Le chaudron magique et l’invention collective, Cahier de recherche, CEPN (IIDE), Villetaneuse : Université Paris-Nord.

Q Markus, M. L., Manville B. and C. E. Agres 2000 What Makes a Virtual Organization Work?, Sloan Management Review, 42: 1, 13-26.

27

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

Q Mauss, M. 1950 Essai sur le don : Forme et raison de l’échange dans les sociétés archaïques, in Sociologie et anthropologie, Paris : PUF, 143-279.

Q Mayer, R., J. H. Davis and F. D. Schoorman 1995 An Integrative Model of Organizational Trust, Academy of Management Review, 20: 3, 709-734.

Q Maznevski, M., and K. M. Chudoba 2000 Bridging Space over Time: Global Virtual Team Dynamics and Effectiveness, Organization Science, 11: 5, 473-492.

Thomas Loilier . Albéric Tellier

Q O’Hara-Devereaux, M., and R. Johansen 1994

Guarding the Commons: How Community Managed Software Projects Protect their Work, Research Policy, 32: 7, 1179-1198.

Les technologies de l’information et de la communication et la coordination à distance dans les activités de recherche d’innovation, in A. Torre, A. Rallet et Y. Lung (Eds.), Organisation spatiale et coordination des activités d’innovation des entreprises, Rapport pour le Commissariat Général au Plan. Pessac : IERSO Université Bordeaux IV, 77-96.

Q Orléan, A. 1994

Q Rallet, A., et A. Torre 2001

Sur le rôle respectif de la confiance et de l’intérêt dans la constitution de l’ordre marchand, Cahier de recherche, CREA n°9403A, Paris : Ecole Polytechnique.

Proximité géographique ou proximité organisationnelle ? Une analyse spatiale des coopérations technologiques dans les réseaux localisés d’innovation, Economie appliquée, 54: 1, 147171.

Global Work: Bridging Distance, Culture and Time, San Francisco, CA: Jossey-Bass.

Q O’Mahony, S. 2003

Q Minzberg, H., and J. A. Waters 1985

Q Ouchi, W. 1979

Of Strategies, Deliberate and Emergent, Strategic Management Journal, 6: 3, 257-272.

Markets, Bureaucracies and Clans, Administrative Science Quarterly, 25: 3, 129-141.

Q Moon, J. Y., and L. Sproull 2000

Q Panteli, N. 2003

Essence of Distributed Work: the Case of the Linux Kernel, First Monday, 5: 11.

Q Rallet, A. 1997

Situating Trust Within Virtual Teams, Working Paper, n°20, Bath: University of Bath, School of Management.

Q Raymond, E. S. 1998 The Cathedral and the Bazaar, The First Monday Journal of the Internet, 3: 3, 1-24.

Q Raymond, E. S. 1999

Q Perroux, F. 1960

The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary, Sebastopol: O’Reilly.

Le logiciel libre, Paris : O’Reilly.

Economie et société : Contrainte, échange, don, Paris : PUF.

Q Reix, R. 1995

Q Nemiro, J.E. 2001

Q Planque, B. 1991

Assessing the Climate for Creativity in Virtual Teams, in M. Beyerlein, D. Johnson and S. Beyerlein (Eds.), Virtual Teams, Advances in Interdisciplinary Studies of Work Teams, Greenwich, CT: JAI Press, 59-84.

Note sur la notion de réseau d’innovation : réseaux contractuels et réseaux conventionnels, Revue d’Economie Régionale et Urbaine, 34, 295-320.

Q Müller, M., H. Yamagata, L. Wall and D. Dougherty 2001

Q Nohria, N., and R. G. Eccles 1992 Face-to-face: Making Network Organizations Work, in N. Nohria and R. G. Eccles (Eds.), Networks and Organizations: Structure, Form and Action, Boston, MA: Harvard Business School Press, 288-308.

Q Nooteboom, B. 1996 Trust, Opportunism and Governance: a Process and Control Model, Organization Studies, 17: 6, 985-1010.

Q Nooteboom, B. 2002 Trust: Forms, Foundations, Functions, Failures and Figures, Cheltenham : Elgar.

28

Q Poppo, L., and T. Zenger 2002 Do Formal Contracts and Relational Governance Function as Substitutes or Complements?, Strategic Management Journal, 23: 8, 707-725.

Q Potter, R. E. 2000 Virtual Team Interaction: Assessment, Consequences and Management, Team Performance Management, 6: 78, 131-149.

Q Powell, W. W. 1987 Hybrid Organizational Arrangements: New Form or Transitional Development?, California Management Review, 30: 1, 67-87.

Savoir tacite et savoir formalisé dans l’entreprise, Revue Française de Gestion, 21: 105, 17-28.

Q Rooks, G., W. Raub, R. Selten and F. Tazelaar 2000 How Inter-Firm Co-operation Depends on Social Embeddedness: A Vignette Study, Acta Sociologica, 43: 2, 123137.

Q Sako, M. 1991 The Role of Trust in Japanese BuyerSupplier Relationships, Ricerche Economiche, 155: 2-3, 375-399.

Q Sitkin, S. B. 1995 On the Positive Effect of Legalization on Trust, Research on Negotiation in Organizations, Vol. 5, Greenwich, CT: JAI Press, 185-217.

Q Stewart, D. 1984 Secondary Research: Information Sources and Methods, Newbury Park, CA: Sage.

Can You Trust Someone You Do Not See? The Case of Open-Source Software Development

Q Strauss, A. L., and J. Corbin 1990 Basics of Qualitative Research: Grounded Theory Procedures and Techniques, Thousand Oaks, CA: Sage.

Q Tayon, J. 2002 Le projet Linux est-il un modèle possible d’entreprise innovante?, Cahier de recherche, v. 1.20, CNAM, Chaire de développement des systèmes d’organisation.

Q Teece, D. J. 1987 Profiting from Technological Innovation: Implications for Integration, Collaboration, Licensing and Public Policy, in D. J. Teece (Ed.), The Competitive Challenge, New York: Harper & Row, 185219.

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

Q von Hippel, E. 1994

Q Wenger, E. 1998

Sticky Information and the Locus of Problem Solving: Implications for Innovation, Management Science, 40: 4, 429-439.

Communities of Practice: Learning, Meaning and Identity, Cambridge: Cambridge University Press.

Q von Krogh, G., S. Spaeth and K. R. Lakhani 2003

Q Williamson, O. E. 1993

Community, Joining, and Specialization in Open Source Software Innovation: a Case Study, Research Policy, 32: 7, 1217-1241.

Q Wayner, P. 2000 Free For All: How Linux and the Free Software Movement Undercuts the High-Tech Titans, New York: HarperBusiness.

Calculativeness, Trust and Economic Organization, Journal of Law and Economics, 36: 1, 453-500.

Q Zucker, L. 1986 Production of Trust: Institutional Sources of Economic Structure: 18401920, in B. Staw and L. Cummings (Eds.) Research in Organizational Behavior, Vol. 8, Greenwich, CT: JAI Press, 53-111.

Q Weber, R. P. 1990 Basic Content Analysis, Newbury Park, CA: Sage.

Q von Hippel, E. 1986

Q Weick, K. E. 1993

Lead User: a Source of Novel Products Concepts, Management Science, 32: 7, 791-805.

The Collapse of Sensemaking in Organizations: the Mann Gulch Disaster, Administrative Science Quarterly, 38: 4, 628-652.

29

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

Thomas Loilier . Albéric Tellier

APPENDIX: METHODOLOGY DETAILS

This appendix has two objectives: to give a summary of the 4 main sources, while emphasising the method of data production and brief evaluation of each source using Stewart’s grid (1984).

The FLOSS project (Ghosh et al., 2002) Led by Ghosh and his team, this project is based on an online study of 2784 developers of the open source community. Financed by the International Institute of Infonomics of the University of Maastricht, this study is considered a reference, because of its results as well as the way they were obtained. The collection of data through a questionnaire was dealt with directly by the community itself, which resulted in a large and diversified sample. In addition, a sub-sample of 500 developers was used to validate the results.

Table A1. FLOSS project evaluation (Ghosh et al., 2002) using Stewart’s grid (1984) Source

Ghosh, R. A., R. Glott, B. Krieger, and G. Robles (2002), Free/Libre and Open Source Software: Survey and Study – Part 4: Survey of Developers, FLOSS Final Report, Maastricht: University of Maastricht, International Institute of Infonomics, disponible sur http://www.infonomics.nl/FLOSS/report/.

Aim of the data collection

Discover developer motivation Discover methods of organization of the Open Source community Discover individual characteristics (age, experience, salary, motivations…) of the members of the community

Responsibility of collection

At first, the researchers. Then, in snowball effect, the members of the community themselves (self-administered questionnaire)

Nature of collected data

A mix of quantitative and qualitative data on the three themes mentioned previously (motivations, organization methods and individual characteristics)

Collection timeframe

February 2002 to April 2002

Production method

Online questionnaire

Data corroboration

Yes, WIDI survey & Hacker Survey of BCG

Table A1 shows that Stewart’s requirements are easily fulfilled, particularly given a clear desire to corroborate the results obtained with two other major studies. For further information on the project, the reader may want to look at the following website http://www.infonomics.nl/FLOSS/report/.

The LICKS project (Ghosh and David, 2003) Jointly led by the International Institute of Infonomics of Maastricht and the Internet Institute of Standford University, this NSF-funded project aims to supplement the FLOSS project by studying the evolution of the community focusing exclusively on the part of that community that deals with the development of the Linux kernel. The authors chose to use comparative statistics in analyzing the development characteristics of three versions of this kernel: Linux 1.0 (march 1994), Linux 2.0.30 (april 1997) and Linux 2.5.25 (july 2002). The data collection technique and, more generally, the methodology used are described in detail in Ghosh (2002, available at http://dxm.org/papers/toulouse2/). As in the previous case, one can notice that all 6 of Stewart’s requirements are fulfilled.

Table A2. LICKS project evaluation (Ghosh and David, 2003) using Stewart’s grid (1984) Source

Ghosh, R. A., and P. A. David (2003), The Nature and Composition of the Linux Kernel Developer Community: a Dynamic Analysis, Working Paper, NSF Open Source Software Project, Stanford, CA: Stanford Institute for Economic Policy Research

Aim of the data collection

Analyze the evolution of the Linux Kernel developer community through the evolution of the distribution of code contribution by a developer

Responsibility of collection

R. A. Ghosh

Nature of collected data

Qualitative data: team size, total number of developers, number of identified sub-projects, number of interproject collaborations, share of anonymous code

Collection timeframe

2002

Production method

Automatic extraction of data by ad hoc automatic software tools designed by Ghosh and Prakash; implemented by Prakash

Data corroboration

Yes, Orbiten survey (Ghosh and Prakash) – Floss project

30

Can You Trust Someone You Do Not See? The Case of Open-Source Software Development

M@n@gement, Translated from Vol. 7, No. 3, 2004, 275-306 Special Issue: Practicing Collaboration

Research by von Krogh, Spaeth and Lakhani (2003) The originality of this research is that it that it focuses on a particular project (the Freenet project) and not on a sizeable sample of projects as the three other sources did. This research variation proved very fruitful. One can also notice the authors’ with for precision, as they used 4 complementary data collection methods, in order to carry out the triangulations themselves. Here to, the data source meets Stewart’s six criteria.

Table A3. Von Krogh et al. (2003) research evaluation using Stewart’s grid (1984) Source

von Krogh, G., S. Spaeth, and K. R. Lakhani (2003), Community, Joining, and Specialization in Open Source Software Innovation: A Case Study, Research Policy, 32: 7, 1217-1241

Aim of the data collection

Understand how a new developer joins the existing community Understand how he/she contributes to the development of new software

Responsibility of collection

G. von Krogh, S.Spaeth, K. R.Lakhan, later joined by E. von Hippel

Nature of collected data

Qualitative data: individual developer characteristics and of studied project as well as behaviour and motivation of protagonists Quantitative data: number of developers and of emails exchanged during the course of the project.

Collection timeframe

January 2001 – May 2001

Production method

Four distinct methods: 1/ Semi-directed phone interviews; 2/ Content of emails exchanged within the project’s mailing list; 3/ Data extraction software allowing the analysis of the project’s progress (through the modifications of the Freenet source code); 4/ Additional documents (web pages, FAQ, etc.).

Data corroboration

Yes, especially with the other articles of the special issue of Research Policy, von Hippel and von Krogh (2003), Wayner (2000) and Raymond (1999)

Research by Krishnamurthy (2002) This last source of data is certainly less ambitious than the other three, but is useful because of the originality of its aims, and therefore of the collected data especially concerning the size of the teams of developers. One can see that the last of Stewart’s criteria is not fully met. However, we corroborated data relating to team sizes with data from the LICKS project ourselves. On the other hand, it was not possible to corroborate the data relating to the nature of the top hundred contributors to the community.

Table A4. Evaluation of the research by Krishnamurthy (2002) using Stewart’s grid (1984) Source

Krishnamurthy, S. (2002), Cave or Community? An Empirical Examination of 100 Mature Open Source Projects, First Monday, 7: 6

Aim of the data collection

Analyze the production method of Open Source Software Show that this method is more strongly linked to solitary individuals (lone production model) than to a community working together on common projects (community production model)

Responsibility of collection

S. Krishnamurthy

Nature of collected data

Qualitative data: nature of the top 100 contributors (university, individuals, private companies…) Quantitative data: size of developer teams.

Collection timeframe

April 23rd 2003 – May 1st 2003

Production method

Manual compilation of data related to one hundred projects available on sourceforge.net

Data corroboration

Partial, through the Licks project (2003)

31