- Email: [email protected]
Participation in online interaction spaces: Design-use mediation in an Open Source Software community
International Journal of Industrial Ergonomics 39 (2009) 533–540
Contents lists available at ScienceDirect
International Journal of Industrial Ergonomics journal homepage: www.elsevier.com/locate/ergon
Participation in online interaction spaces: Design-use mediation in an Open Source Software community Flore Barcellini a, d, *, Françoise De´tienne b, d, Jean-Marie Burkhardt c a
Cnam, Ergonomics Laboratory, Research Center on Work and Development, Case 210, 41 rue Gay-Lussac, 75005 Paris, France LTCI- UMR 5141dCNRS, Telecom Paris Tech, 46 rue Barrault, 75634 Paris Cedex 13, France c ErgonomicsdBehaviour and Interactions Laboratory, Universite´ Paris 5, 45 rue des Saints-Pe´res, 75006 Paris, France d INRIA, France b
a r t i c l e i n f o
a b s t r a c t
Article history: Received 21 December 2007 Received in revised form 15 July 2008 Accepted 16 October 2008 Available online 6 December 2008
This research aims at characterizing emerging roles fostering design-use mediation during the Open Source Software (OSS) design process through the analysis of participation. Studying OSS is of particular interest: (1) to investigate socio-technical settings supporting user participation to the design process, which is considered to be the major strength of OSS design; (2) to gain insights into supporting the changing nature of the software industry, which is becoming more and more distributed and global, and which is thus increasingly making use of OSS design tools and methods. In this research, we characterized effective roles of participants, i.e. participation, on the basis of activities analysis in three online interaction spaces (discussion, documentation and implementation) during a continuous ‘‘pushed-byusers’’ design process of the Python project. Participation is targeted through a methodology articulating: (1) structural analyses (organization of the discussions, regularity and involvement of participants, quotes-based social network) in usage-oriented and development-oriented mailing lists of the projects’ discussion space; (2) actions to the code and documentation made by participants in the implementation and documentation spaces. Besides the importance of the users’ contribution to the process, OSS design is fostered by some key-participants, the cross-participants, who act as boundary spanners between the developers and the users, helping them to go beyond some barriers to participation. These findings can be reinforced developing software to automate the structural analysis of discussions and actions to the code and documentation. Ó 2008 Elsevier B.V. All rights reserved.
Keywords: Design-use mediation Open source software Online community Distributed participatory design
1. Introduction Open Source Software (OSS) is software that can be run, distributed, studied, changed and improved by its users. The OSS design process is characterized by a communitarian and highly mediated design process. This new way of designing is becoming more and more important since there are thousands of OSS (famous examples are the Linux operating system or the Firefox internet browser) and millions of users of them. Mainly mediated by Internet tools, OSS design is distributed among three interaction spaces on the web (Sack et al., 2006): a discussion space (mailing lists, forums etc.), a documentation space (project-related documents archived on the net) and an implementation space (different versions of the software source code). Thus, it is a paradigmatic case of distant and asynchronous
* Corresponding author. E-mail addresses: fl[email protected] (F. Barcellini), francoise.detienne@tele com-paristech.fr (F. De´tienne), [email protected] (J.-M. Burkhardt). 0169-8141/$ – see front matter Ó 2008 Elsevier B.V. All rights reserved. doi:10.1016/j.ergon.2008.10.013
collaborative design, which has been less investigated, so far, than distant and synchronous (Olson and Olson, 2000; De´tienne et al., 2004), or co-located collaborative design (Olson et al., 1992; Stempfle and Badke-Schaub, 2002; De´tienne et al., 2005). Studying OSS is also of particular interest to gain insights into supporting the changing nature of the software industry, which is increasingly making use of OSS design tools and methods as it becomes more and more distributed and global (Gutwin et al., 2004). OSS design can also be considered as a continuous form of design: new functionalities can always be proposed and discussed at any step in the project (Gasser et al., 2003), forms of participation in OSS projects are supposed to be ‘‘open’’ in time and for different kinds of participants whatever their stake in the project (developers or users of the OSS). Thus, participants in OSS design can potentially be involved in all the phases of the design process (elicitation of needs and requirements, design and implementation), at least if they have the skills to do so. This is often the case as, in OSS, users can be highly skilled in computer science (Ducheneaut, 2005), as well as in particular application domains (e.g., education, biology, scientific computing, etc). Moreover, the
534
F. Barcellini et al. / International Journal of Industrial Ergonomics 39 (2009) 533–540
participation of users is considered to be the major strength of the OSS design process compared to proprietary ones: most bugs are detected and fixed because ‘‘there are many eyeballs looking at the problem’’ (Raymond, 1999). In this paper, we are interested in characterizing participation of various stakeholders engaged in a ‘‘pushed-by-users’’ continuous design process, in the interaction spaces of the Python programming language community. We assume that participation can be captured through the analysis of different activities performed in the three interaction spaces (discussion, documentation, implementation). This characterization will help us in addressing the main goal of our research: investigating forms of participations and effective roles emergence in OSS design process that may enhance mediation between users and developers. After highlighting some features of participation and its measure, as well as the design-use mediation process, we present our research questions and strategy. We then present an analysis of participation in the three interaction spaces that outlines key forms of participation enhancing the design-use mediation process in OSS communities. 2. Participation and design-use mediation process 2.1. Status and participation of users in OSS communities OSS projects have been characterized as online epistemic communities (Cohendet et al., 2000; Preece, 2000). Their members form a group of people connecting together on the Internet with a common goal: to develop software and to produce knowledge about the artifact they develop. Different statuses are outlined in OSS communities, related to the right and power to modify the source code. Some participants can modify directly the source code, they participate to the design process and to the decisions: (1) the project leader (generally the creator of the project as in Python); (2) the core team or administrators, who have to maintain the code base and the documentation; (3) the developers who participate to the evolution of the OSS and maintain some of its parts. Other participants are called ‘‘users’’. In an OSS context, users can be highly skilled in Computer Science, being far away of the classical notion of ‘‘end-users’’. They are called active users if they participate in mailing lists discussions as informants for newcomers, by reporting or correcting bugs with patches, and by proposing new modules. Other users are called passive users as they only use the software or lurk on the discussions and documentation spaces of the project. Despite this hierarchical view, it is possible to evolve in the community. Organization of the design process and roles effectively performed by participants can emerge from interactions rather than prescribed and formalized a priori. This emergence process is framed by implicit and explicit rules: volunteer participation, evaluation of work by a peer-review mechanism of works (e.g. Raymond, 1999); as well as norms: meritocracy. Thus, it is possible to evolve in the community proving ones value to ones peer and roles effectively performed by participants may not always correspond to their status. In this direction, the goal of this research is to characterize the forms of participations and the roles of participants with respect to activities performed in three interaction spaces (implementation, documentation and discussion) (Sack et al., 2006). The literature on OSS clearly identifies that active users take part in the evaluation phase of design (bug reporting and patching, e.g. Ripoche and Sansonnet, 2006) and that the project leader, administrators and developers participate in the design process itself, i.e. generating and evaluating solutions and taking decisions (Barcellini
et al., 2008a). Open issues are still to characterize the role of all active participants (project leader, administrators, developers and active users) regarding the design process itself and during the elicitation of the needs and requirements phase. In particular, we will focus on the design-use mediation process: how use and design are articulated when new functionalities are proposed, solutions are generated and evaluated; and what the links are between users and developers in OSS communities. 2.2. Design-use mediation process through boundary spanners roles We defined the role of boundary spanners on the basis of ‘‘communication or behavior among two or more networks or groups’’ (Sonnenwald, 1996). Boundary spanners span the gap among different teams, moving among them and transferring information about the state of the project. Boundary spanners appear to be of particular importance in collaborative design situations and they tend to produce innovative solutions to design problems (Sonnenwald, 1996). They are also key participants who can enhance coordination through informal communications (Krasner et al., 1987; Grinter, 1999). They reduce the amount of information lost or miscommunicated among different phases of design development and different development teams. They also foster the mutual learning process occurring through perspectives confrontation in the design process (e.g. Be´guin, 2003). Thus, boundary spanners can help technology-use mediation in the design situation (Bansler and Havn, 2006). In non-design situations, it has been described that they can also protect their organization against external pressure or can represent their organization (Sarant, 2004) and that boundary spanning is a way to develop a horizontal expertise and collective concept formation (Engestro¨m et al., 1995). This role is similar to the role of brokers that foster learning process in community of practices (Wenger, 1998). The role of boundary spanners is not a formal one but rather a role emerging from interactions and practices. Becoming boundary spanners requires to have developed skills and competencies in the different fields that are spanned, to be aware of all practices and to gain in legitimacy and credibility in the domains they span. 3. Research question and research strategy 3.1. Research question In this research, we will consider the specific role of boundary spanners as mediators between users and developers in the OSS design process. Our hypothesis is that successful design-use mediation may be supported by boundary spanner roles emerging from interactions between users and developers. As far as we know, in OSS design, and more generally in mediated, asynchronous and distant design situations, the role of boundary spanners has not been investigated yet. In this direction, we have developed a methodology to characterize participation in the three interaction spaces (discussion, documentation and implementation) of an OSS design project, Python, into a specific ‘‘pushed-by-users’’ process. This research strategy is presented in the section below. 3.2. Research strategy 3.2.1. Approaches to identify boundary spanning activities We investigate boundary spanners activities with a cognitive ergonomics approach, by a specific focus on participants’ activity, reflecting their roleddistinct from statusdin the design process
F. Barcellini et al. / International Journal of Industrial Ergonomics 39 (2009) 533–540
(Baker et al., 2003). Although the role is dependent upon status of the participant in the community, i.e. the power he/she has on the artifact being designed, it is also contingent upon the participants’ activities in the design process (Sonnenwald, 1996; Mahendran, 2002). Various characterizations of activities in online communities and also in global design have been developed within the social network analysis (SNA) approach (e.g. Madey et al., 2002; Gonzalez-Barahona et al., 2004): for instance measures such as betweenness, centrality, or closeness among participants. Such measures may serve various research issues related to collective design. Among these issues, one question concerns coordination with respect to actor centrality measures in the social network and also to task interdependencies (e.g.de Souza et al., 2005; Hossain et al., 2006). Another issue concerns the evolution of people in the OSS communitydfor instance progressive integrationdas seen by temporal evolution from a peripheral position to a more central position into the socio-technical network (e.g. Ducheneaut, 2005). One question of special interest for this paper concerns key participants establishing links among groups, in particular between developers and users communities. In this direction, one recent study (Sowe et al., 2006) has identified OSS project participants, referred to as knowledge brokers, who bridge the gap among expert software developers and users communities in the Debian OSS project. Based on SNA, they identified boundary spanners as actors who participated across three mailing lists of the project. Several limitations of this work can be pointed out. Firstly, the analysis is done on all posts in the mailing lists during a given period of time and does not distinguish posts with respect to the design process. Our position is that participation across boundaries should be assessed in the context of a particular design objective. Thus, we examine participation and evolution of participation in the context of a particular OSS design process, identified as ‘‘pushed-by-users’’. Secondly, the participants ‘‘across lists’’, which we will call common participants in our study, may post in various periods of time and on various topics. Our position is that this measure is not strict enough to select knowledge brokers as posts may refer to completely different topics and to different steps in the design process. We propose to measure cross-participation in mailing lists, as a better indicator for identifying boundary spanners; crossparticipants being those who post across mailing lists in parallel same topic discussions. Thus cross-participants form a subset of common participants and their participation is contextualized in the evolution of a design process. Finally, SNA studies usually focus on one interaction space, e.g. the discussion space for Sowe et al. (2006), or the implementation space for de Souza (2005). Our position is that one needs to examine participation and activities in the three interaction spaces (discussion, documentation and implementation), in order to have a broader view of participation. We assume that the role of boundary spanners must be investigated according to three dimensions: a discursive one and social one mostly performed in the discussion space, but also a technical one, mostly performed in the documentation and implementation spaces. Moreover, activities (or roles) of boundary spanners may not be equally distributed in these spaces. In a previous paper (Barcellini et al., 2008b) we outlined, through a message content analysis (activities and references/ knowledge sharing) that cross-participants provide knowledge about both the usage-oriented application domain and the development-oriented programming domain (computer-science) during the final part of the ‘‘pushed-by-users’’ design process, i.e. the successful part of the process which leads to the implementation of the initial needs of users. This way, they cross the boundaries between users and developers communities acting as boundary spanners. In this paper, we will characterize participants’ activities on the basis of structural analyses of participation in the three
535
interaction spaces of an OSS project (discussion, documentation and implementation) to investigate more deeply identified keyparticipants roles in the three spaces. Furthermore, we will consider the whole design process, taking into account previous unsuccessful design proposals. 3.2.2. Python community and interaction spaces This research is focused on a major OSS project called Python, which is a programming language. This project has a large community of users in various application domains and a stable core group of developers who are designing the Python Core language and its standard library (Fig. 1). In this research, we try to understand how needs from application domains may impact and enhance the design of the Python core language (symbolized by arrows in Fig. 1). As already stated, OSS design is distributed among three online interaction spaces (Sack et al., 2006): the discussion, documentation and implementation spaces. The major part of OSS design occurs in the discussion space composed of different mailing lists or newsgroups (Mockus et al., 2002; Barcellini et al., 2005). As all discussions are publicly available and archived online, they constitute rich traces of the OSS design process. In the Python project there are two main mailing lists: A usage-oriented mailing list, the python-list, is about general discussions and questions about Python. Posting to this mailing list is the main means for an active user to participate to the Python project. Most discussions on python-list are about developing with Python, not about development of the Python language itself. A development-oriented mailing list, the python-dev, is for work on developing Python (fixing bugs and adding new features to the Python language). This is the heart of Python’s development. Anyone can subscribe to python-dev, though his/her subscription will have to be approved. The list address accepts e-mail from non-members, and the python-dev archives are public. The documentation space is composed by all documents, websites and wikis relative to the project. For instance, the Python community has set up a process to propose and document the introduction of new feature into the language the Python Enhancement Proposal (PEP). Thus, the documentation space contains all PEP documents and their versions. Finally, the implementation space contains the proper code of Python: the standard library and its modules their versions and the traces of their revisions.
Fig. 1. The Python galaxy (modified from Barcellini et al., 2008a).
536
F. Barcellini et al. / International Journal of Industrial Ergonomics 39 (2009) 533–540
3.2.3. Focus on a continuous ‘‘pushed-by-users’’ design process The work presented here focuses on a ‘‘pushed-by-users’’ design process, seen as a continuous design process. During this process, various stakeholders (users or developers) can participate in different steps of the process (proposition of new functionality, elaboration of needs, elaboration of specifications, implementation, etc.). The process studied concerns the introduction of a decimal type in Python and its related decimal.py module. There have been several unsuccessful proposals, i.e. not scored by an accepted PEP and its implementation, to introduce a decimal type in Python. A first decimal.py module was also proposed but was still to be implemented. Then, a successful proposal was initiated by a user of Python, whom we will refer to as the user-champion, who is a developer of a project in the financial application domain of Python (http://sourceforge.net/projects/sigefi). The first need of the user-champion was for a money type, but it appeared that before introducing a money type, work had to be done in the decimal type in Python. The user-champion formalized this proposal through a PEP document that became an accepted PEP (PEP 327). For a more detailed description of the PEP 327 design process, one can refer to our previous publication (Barcellini et al., 2006).
4. Method 4.1. Data collection In the discussion space, all discussions are available online (http://mail.python.org/pipermail/python-list/ or /python-dev/). The data were gathered by searching, by hand, from the python-list (usage-oriented mailing list) and the python-dev mailing list (development-oriented mailing list) for the keywords contained in the subject header of all messages: decimal, money, currency, fixed-point (old solution to resolve decimal problems) and the name of the user-champion. The search was performed from the first formalization to introduce a decimal module in May 2001 to May 2006 (when we began this study). Each message, which was gathered, required reading by the first author of this paper to ensure it was indeed a message dealing with the design issue. If a discussion took place in another thread we collected this motherthread. The data collected are split in two corpora on the basis of the formalization of the proposal through an accepted pre-PEP (Table 1). The first one is related to discussions, which did not lead to official formalization of the proposals into a pre-PEP. This corpus is called unsuccessful decimal proposals (from the first formalization of a decimal module in May 2001 to October 2003, the day before the first post of the user-champion). The second one is related to the discussions, which lead to the formalization of the first proposal into a pre-PEP followed by an accepted pre-PEP. This corpus is called successful decimal proposal corpus (from the first post of the user-champion in October 2003 to May 2006). Table 1 Description of the two corpora.
Nb Discussions Nb Participants Nb Messages
Unsuccessful decimal proposals
Successful decimal proposal
Py-list
Py-dev
Py-list
Py-dev
10 66 192
6 22 122
22 95 340
29 48 406
In the documentation and implementation spaces, Python code, pre-PEP and PEP document revisions (modifications) are also archived and available online (http://svn.python.org/view/). We searched in the various folders for the decimal.py module and the PEP 327 modifications. It concerned only the successful proposal corpus as: none PEP dealing with decimal were accepted before PEP 327; and because the first version of decimal module, announced in May 2001, was in the ‘‘sandbox’’ of the project, i.e. as to be done. Concerning the decimal.py module; we collected 44 revisions from 1 July 2004 (first revision) to 11 May 2006 (end of the collected data). Concerning the PEP 327 document, we collected nine revisions from 29 June 2005 (last archived revisions).
4.2. Data analysis In the discussion space, we will analyze discussions related to the design process in both the usage-oriented mailing list (pythonlist) and the development-oriented mailing list (python-dev). We will investigate the temporal organization of the design process and the dimension of participation according to this organization (regularity of the participation, presence of common participants and cross-participants between the usage-oriented and the development-oriented mailing lists). In the documentation and implementation spaces we will analyze participation via the modifications’ actions and who made them. The different versions of the PEP related to the successful design process we study (PEP 327) in the documentation space and the different versions of the decimal.py module related to the design proposal we study (which is the live implementation of the PEP 327) in the implementation space. 4.2.1. Temporal and design-related organizations of discussions We characterize the organizations of discussions, according to several dimensions: the global organization of discussions, the design-step organization, the temporal delay among discussions, the presence of same-topic parallel discussions. This organization helps us in positioning participation into design process steps. The global organization of discussions in parallel in the two mailing lists and for the two corpora. For each discussion of the two corpora, we identify by hand the first and the last messages and extract the corresponding dates, and the subject-header of the discussions. We then position each discussion along a timeline. The design-step organization of discussions according to time, i.e. group of discussions dealing with same online design steps: elicitation of needs, proposals, pre-PEP, PEP design, refinements, valorization of the implemented module, tutorials, debug and evolution. These groups are constituted according to their subject-header and a rapid content overview. The temporal delay among discussions’ opening within each mailing list in each corpus. This is an indicator of the follow-up of the proposals’ discussions. It corresponds to the means of the delay among the beginning’s date of each discussion. The presence of parallel same-topic discussions in the two mailing lists, as an indicator of the thematic coherence between the usage-oriented and the development-oriented mailing lists. They are same-subjects discussions occurring in the two mailing lists, that overlap in time. To identify them, we compare subjects and dates of discussions in the two mailing lists.
F. Barcellini et al. / International Journal of Industrial Ergonomics 39 (2009) 533–540
4.2.2. Characterization of participation in the three interaction spaces 4.2.2.1. In the discussion space. In the discussion space, to highlight the participation we identify different dimensions of participation that can reveal some key-participation: regularity of participation, presence of common and cross-participants and involvement of participants. The regularity of participation, for each mailing list within each corpus is measured according to the number of discussions in which participants are involved in a particular mailing list. Regular participants are those who participate in more than, or equal to, the third quartile value of the number of discussions in which participants are involved (with Q3 ¼ 2 in the unsuccessful proposals corpus, 1 in python-list and 2 in python-dev for the successful proposal corpus). Others are called occasional participants. The presence of common participants within the two mailing lists in a same corpus, who are those present, at least once, in both python-dev and python-list. To identify these participants we compare among the mailing lists, the name of posters for each discussion of the corpora. A subcategory of common participants is cross-participants between the users and the developers’ mailing lists in the two corpora. We define cross-participants (an extended notion of crossposters, Kollock and Smith, 1996) as persons who participate at parallel same-topic discussions, occurring in the two mailing lists. To identify the cross-participants, we compare the name of the posters in the same-topic parallel discussions. We also verify that this cross-participation is not simple cross-posting, i.e. messages sent by cross-participants always were different in the two mailing lists except for one message. The involvement of participants in each mailing list and in each corpus is characterized by the number of messages posted by each category of participants (Project Leader, Regular only, Occasional only, Common and Cross-participants). Finally, we investigate the social network in which identified key-participants are involved. This is done on the basis of the quotation patterns among messages posters: i.e. who is quoting whom, to highlight interactions among participants. Quotation, i.e. the integration of a part of a previous message(s) in another one is a compensatory linking strategy used by participants to maintain the context in online discussions (Herring, 1999). In a previous paper (Barcellini et al., 2005), we have shown that the organization of messages according to the quoting link is relevant to reconstruct the thematic coherence of online discussions and to understand the interactions among participants in terms of verbal turns. Blocks of
537
quotation are identified in each message by the greater than symbol ‘‘>’’. Then, we search manually in the corpus from which message and which author each quote comes from to obtain a table of ‘‘who is quoting whom’’. 4.2.2.2. In the documentation and implementation spaces. In the documentation and implementation spaces, we collect the names of the participants who proposed revisions in the PEP 327 document and the decimal.py revisions and explicit references to other participants’ works in the content of the revision. Indeed as some rights control the CVS access, developers may modify the code on behalf of other ones. In this situation, the social rules of OSS communities fix to acknowledge other works. This structural analysis has been complemented by e-mail interviews with the user-champion and one of the crossparticipants. 5. Results 5.1. Temporal and design-related organization of discussions We constructed temporal views of the unsuccessful and the successful design proposals (Figs. 2 and 3 respectively). Each action in one of the three interaction spaces (discussion in python-dev and python-list for the discussion space; modification of PEP document for the documentation space; modification of version of code for the implemented space) is represented, in parallel, along the timeline by a circle. In the discussion space, they are labeled using the subject of the discussions or their corresponding design-step for groups of discussions (black circle). In the unsuccessful decimal proposals (Fig. 2), we identify three attempts to propose a decimal type, in python-dev (Pep adding a decimal type to Python in July 2001; Proposal: add basic money type in March 2002 and a Add decimal (aka fixed point) to Python in December 2002). They are not followed by same-topic discussions either in python-dev or in python-list. Two design-step-related groups of discussions emerge (Proposal for a decimal type and Elicitation of needs for monetary and decimal arithmetic) but there are local and are not followed by other steps of a design process (Pre-PEP or PEP) as they are not accepted. Consequently, there is no action in the documentation and implementation spaces. In the successful decimal proposal (Fig. 3), there are more structured discussions: the first discussion Elicitation for a Money DT is followed by groups of discussions dealing with the designsteps. Indeed, the mean temporal delay among following
Fig. 2. Representation of actions regarding the unsuccessful decimal proposal corpus in the three interaction spaces.
538
F. Barcellini et al. / International Journal of Industrial Ergonomics 39 (2009) 533–540
Fig. 3. Representation of actions regarding the successful decimal proposal corpus in the three interaction spaces.
discussions is about 30 days in the successful proposal corpus and 63 in the unsuccessful one. This means that there is more follow-up of discussions in the successful proposal than in the unsuccessful ones. In the documentation space, one can see the creation of the PEP document as soon as the PEP is declared accepted in the discussion space. The implementation began, few months later after design discussions occur in python-dev. This implementation corresponds also to the champion vacations, where he had some time to begin the work, as he declared during an interview. Moreover, there are five parallel same-topic discussions (labeled using vertical ached lanes) in the successful proposal corpus whereas there are none in the unsuccessful one. These temporal analyses of the discussions allow us to outline two main specificities of the successful design process: (1) there are parallel same topic discussions in the two mailing lists; (2) we can form design-steps-related group of discussions highlighting the design continuity of discussions in mailing lists. 5.2. Participation to the discussion space 5.2.1. Distribution of participation Table 2 describes the participation for each mailing list in each of the two corpora. The distribution of participation is different between the two corpora (Fisher’s Exact Probability Test ¼ 0.016). Globally, it outlines that they are more participants involved in the successful proposal in both the mailing-list. Most of the participants are occasional ones in both mailing lists and corpora. This result highlights a turnover of participants in the mailing lists, in particular in the python-list. Relative deviation (V2 Cramer ¼ 0.04)1 indicates that regular participants tend to participate more in the python-list for the unsuccessful corpora. This result suggests that the presence of regular participants in discussions does not guarantee the design proposal to be successful. Concerning common and cross-participants, in the unsuccessful proposals discussions, we identify out of the 84 different participants:
1
There is a positive association between two variables (an attraction), when Relative Deviaton (RD) is positive; and, repulsion when it is negative. The coefficient V2 Cramer gives the global association between the two variables; it is a synthesis of all the local RDs. The association is insignificant for 0 < V2 < 0.04; intermediary if 0.04 < V2 < 0.16; and, strong otherwise. Even if the global association is insignificant, local RDs can highlight some interesting associations.
Four common participants (6%): two users, one administrator who is known as a specialist of the decimal domain and who provided the previous solution (fixed-point) to cope with the lack of decimal module in Python, and one developer who proposed the first decimal module (version 0). The two last ones are regular participants in both corpora. As there are no same-topic parallel discussions in the unsuccessful decimal proposals corpus, there are no cross-participants between the two mailing lists, for this corpus. In the successful proposal corpus, we identify out of the 130 different participants: Thirteen common participants (10%): two administrators, five developers, and six users. Seven are occasional participants in both mailing lists and six are regular ones: four of the crossparticipants described below, two developers and a user. Five cross-participants (4%), among the 13 common participants: the user-champion (he was not formally defined as a developer at the beginning of the process and was the project leader of a financial project), an administrator and a developer (also identified as common participants in the unsuccessful corpus), another developer and one user. All, except the user, are regular participants in the corpus, In the successful proposal corpus, there are proportionally more common participants than in the unsuccessful proposals. Moreover, the successful proposal is characterized by cross-participants who appear to be mostly regular in their participation.
Table 2 Distribution of participation in each corpus and for each mailing list (number of participants). Unsuccessful proposals
Project leader Regular participants Occasional participants Common participants Cross-participants Total
Successful proposal
Py-list
Py-dev
Py-list
Py-dev
0 16 45 4 0 65
1 2 10 4 0 17
0 19 63 8 5 95
1 5 29 8 5 48
(25%) (69%) (6%) (100%)
(6%) (12%) (59%) (23%) (100%)
(20%) (66%) (9%) (5%) (100%)
(2%) (10%) (61%) (17%) (10%) (100%)
F. Barcellini et al. / International Journal of Industrial Ergonomics 39 (2009) 533–540 Table 3 Involvement of participants in each corpus and for each mailing list (number of posted messages).
Project leader Regular participants Occasional participants Common participants Cross-participants Total
Unsuccessful proposals
Successful proposal
Py-list
Py-dev
Py-list
Py-dev
0 108 62 22 0 192
24 30 15 31 0 100
0 120 73 9 138 340
19 67 76 58 186 406
(56%) (32%) (11%) (100%)
(24%) (30%) (15%) (31%) (100%)
(35%) (21%) (3%) (41%) (100%)
(5%) (17%) (19%) (14%) (46%) (100%)
5.2.2. Involvement Table 3 clarifies the involvement of participants for each mailing list and each corpus. The distribution is different between the two corpora (c2 ¼ 386, d.f. ¼ 12; p < 0.0001). All common participants appear to be more involved, especially in python-dev, where they posted 60% (234/406) of all messages. The major involvement is from the cross-participants and the Project Leader but only in python-dev. Moreover, the involvement of the Project Leader is stronger in the unsuccessful proposals corpus than in the successful one. It may outline the different position of the project leader in the unsuccessful vs. successful corpora. In the first case, he was more framing the proposal as he was the unique guarantor of the design process, whereas in the successful proposal this role may be distributed among the cross-participants. This result highlights that the cross-participants seem to be keyparticipants fostering the design process in the successful attempt, being the most involved and guarantying the follow-up of the design process. Moreover, as two cross-participants were already present (common participants) in the unsuccessful proposals corpus, we can argue that the ‘‘memory’’ they have about the design history and rationale may help to foster the design process. In the following, we investigate more deeply the role of the cross-participants in the three interaction spaces. 5.3. Roles of the cross-participants in the successful proposal 5.3.1. Cross-participants acting as boundary spanners between users and developers in the discussion space For the discussion space, the attraction graph in Fig. 4 represents who tends to quote whom in both python-list and python-dev, and in which mailing list. This graph is based on the relative deviation analysis that measures the association between two nominal variables. It outlines that cross-participants tend to be the link between the users’ community (U) and the developers’ community (A-D and PL) with a specific position for the user-champion (U-C, who is also a CP) who quotes and is quoted more by the project leader (PL) and the administrators–developers (A-D), i.e. the developers’ community. The user championing the PEP is a key cross-participant enhancing harmonious social relationships referring to other persons’ works, and a coordination agent doing synthesis and posting news about the design process in mailing lists (Barcellini et al., 2008b). Moreover, we outlined that he received a social and discursive support from other cross-participants.
Fig. 4. Attractions graph of who tends to quote whom (Barcellini et al., 2008b).
539
5.3.2. Low contributions of the cross-participants in the implementation and documentation spaces In the documentation space, common participants who are not cross-participants made all the revisions. One unique administrator made five (out of nine) revisions. The four other revisions were made by a specific developerdthe PEP editor, who is in charge of the PEP management. In all these four revisions he specified that it was the user-champion contribution. In the implementation space, all the revisions were made by common participants, except one from the project leader: 77% (34/ 44) of revisions were made by the same administrator than in the documentation space, 9% by the user-champion (4/44 from which one effective and three by being referenced), two by the crossparticipant specialist of decimals (the specialist of decimal). However, this low contribution of cross-participants, in the implementation and documentation spaces, should be nuanced on the basis of our interview with the user-champion. Indeed, he declared that the three other cross-participants (i.e. except himself and the other user) ‘‘helped a lot’’, such as the administrator strongly present in the implementation space. This technical support could be performed through the embodiment of code in messages or through private exchanges. 6. Discussion and perspectives Our work provides a new way of measuring participation in OSS design, alternative to the methods proposed in SNA analysis (e.g. Sowe et al., 2006). We propose a methodology that leads to assessment of participation in the three interaction spaces (discussion, documentation and discussion) through the activities effectively performed by various stakeholders in a continuous ‘‘pushed-by-users’’ design process, leading to formalized specifications (a PEP documenting the new functionality) and implementation (the implemented module of this functionality). In the discussion space, we outline that common participation in several mailing lists is not a sufficient indicator to identify boundary spanning roles. We show that cross-participants, participating to same-topic discussions in a specific design process, do act as boundary spanners relaying and supporting user participation, fostering this way the design-process and guarantying the followup of the process. We also show that various roles are performed in the three interaction spaces: boundary spanners being more active in the discussion space than in the documentation and implementation spaces. We plan to extend this work performing interviews with cross-participants and some users involved in this design process to contextualize our data and highlight how their participation is articulated with their activities and needs. We also plan to highlight other conditions, and perhaps barriers, i.e. skills needed, to users’ participation in OSS communities. The contribution of our work is also methodological. Indeed, it confirms that participation must be investigated in the three interaction spaces in order to gain a broader view of the design-use mediation process. Considering the large quantity of data in OSS communities it is tempting, and it is often the case, to use only structural analyses such as social network analysis to characterize OSS design process. We have attempted to illustrate that the combination of structural analyses in the three interaction spaces in which participants are involved is essential to capture the richness and the complexity of the OSS design process. To enrich our findings, this method could be automated (structural analysis) or semiautomated (content analysis). The automation of the method can be useful for the researchers but also the participants in OSS design. Indeed, a tool enabling various stakeholders in a design process to visualize who is participating, at which step of the design process, in which context and which mailing-list, could support mutual awareness of the
540
F. Barcellini et al. / International Journal of Industrial Ergonomics 39 (2009) 533–540
design process (Carroll et al., 2006) or regulation of the design process. These structural functionalities (temporal organization, identification of regular/occasional, common and cross-participants) may complement discussion visualization tools as discussed in previous research (Barcellini et al., 2008a). Acknowledgments This research is funded, through a Ph.D., by the Cnam, INRIA, and the French Research department. References Baker, F., De´tienne, F., Lund, K., Se´journe´, A., 2003. Articulation entre e´laboration de solutions et argumentation polyphonique. In: Bastien, J.C. (Ed.), EPIQUE ’03. INRIA, Rocquencourt (France), pp. 235–240. Bansler, J.P., Havn, E., 2006. Sensemaking in technology-use mediation: adapting groupware technology in organizations. JCSCW 15 (1), 55–91. Barcellini, F., De´tienne, F., Burkhardt, J.M., 2006. Users’ participation to the design process in a free open source software online community. In: Romero, P., Good, J., Bryant, S.A, Chapparo, E. (Eds.), Proceedings of PPIG ’06, pp. 99–114. Barcellini, F., De´tienne, F., Burkhardt, J.M., Sack, W., 2008a. A socio-cognitive analysis of online design discussions in an Open Source Software community. Interacting with Computers 20, 141–165. Barcellini, F., De´tienne, F., Burkhardt, J.M., 2008b. Users and developers mediation in an Open Source Software Community: boundary spanning through cross participation in online discussions. International Journal of Human Computer Studies 66 (7), 558–570. Barcellini, F., De´tienne, F., Burkhardt, J.M., Sack, W., 2005. Thematic coherence and quotation practices in OSS design-oriented online discussions. In: Schmidt, K., Pendergast, M., Ackerman, M., Mark, G. (Eds), GROUP 2005 Conference, pp.177–186. Be´guin, P., 2003. Design as a mutual learning process between users and designers. Interacting with Computers 15, 709–730. Carroll, J.M., Rosson, M.B., Convertino, G., Ganoe, C.H., 2006. Awareness and teamwork in computer-supported collaborations. Interacting with Computers 18, 21–46. Cohendet, P., Creplet, F., Dupoue¨t, O., 2000. Organisational innovation, communities of practice and epistemic communities: the case of Linux. In: Kirman, A., Zimmermann, J.B. (Eds.), Economics with Heterogeneous Interacting Agents. Springer, The Netherlands. De´tienne, F., Boujut, J.-F., Hohmann, B., 2004. Characterization of collaborative design and interaction management activities in a distant engineering design situation. In: Darses, F., Dieng, R., Simone, C., Zaklad, M. (Eds.), Cooperative Systems Design. IOS Press, pp. 83–98. De´tienne, F., Martin, G., Lavigne, E., 2005. Viewpoints in co-design: A field study in concurrent engineering. Design Studies 26 (3), 215–241. Ducheneaut, N., 2005. Socialization in an open source software community: a sociotechnical analysis. JCSCW 14, 323–368. Engestro¨m, Y., Engestro¨m, R., Ka¨rkka¨inen, M., 1995. Polycontextuality and boundary crossing in expert cognition: learning and problem solving in complex work activities. Learning and Instruction 5, 319–336. Gasser, L., Scacchi, W., Ripoche, G., Penne, B., 2003. Understanding Continuous Design in F/OSS Project. ICSSEA-03, Paris, France. Grinter, R., 1999. SystemsArchitecture: Product Designing and Social Engineering, San Francisco, CA, USA.
Gonzalez-Barahona, J.M., Lopez, L., Robles, G., 2004. Community structure of modules in the Apache Project. In: Proceedings of the 4h International Workshop on Open Source Software Engineering. Edinburgh, Scotland, pp. 44–48. Gutwin, C., Penner, R., Schneider, K., 2004. Group awareness in distributed software development. In: Proceedings of CSCW 2004. ACM Press, New York, USA, pp 72–81. Herring, S., 1999. Interactional coherence in CMC. In: Proceedings of the 32nd Hawaii Conference on System Sciences, Maui Island, HI, USA, 5–8 January, p. 13. Hossain, L., Wu. A., Chung, K., 2006. Actor centrality correlates to project based coordination. In: Hinds, P., Martin, D. (Eds), Proceedings of the CSCW ’06 Conference, pp. 363–372. Banff, Canada, Nivember 4–8. Kollock, P., Smith, M., 1996. Managing the virtual commons. In: Herring, S. (Ed.), Computer-Mediated Communication: Linguistic, Social, and Cross-Cultural Perspectives. John Benjamins, Amsterdam, The Netherlands, pp. 109–128. Krasner, H., Curtis, B., Iscoe, N., 1987. Communication breakdowns and boundary spanning activities on large programming projects. In: Olson, G. (Ed.), Empirical Studies of Programmers. Ablex, pp. 47–64. Madey, G., Freeh, V., Tynan, R., 2002. The open source software development phenomenon: an analysis based on social network theory. In: Proceedings of the Americas Conference on Information Systems (AMCIS2002), Dallas, TX, pp. 1806–1813. Mahendran, D., 2002. Serpents and Primitives: An ethnographic excursion into an Open Source community. Master’s Thesis, School of Information Management and Systems, University of California at Berkeley. Mockus, A., Fielding, R.T., Herbsleb, J., 2002. Two Case studies of open source software development: Apache and Mozilla. ACM TSEM 11 (3), 309–346. Olson, G.M., Olson, J.S., Carter, M.R., Storrosten, M., 1992. Small group design meetings: an analysis of collaboration. Human-Computer Interaction 7, 347–374. Olson, G.M., Olson, J.S., 2000. Distance matters. Human-Computer Interaction 15, 139–178. Preece, J., 2000. Online Communities: Designing Usability and Supporting Sociability. John Wiley and Sons, New York, USA. Raymond, E.S., 1999. The cathedral and the bazaar. http://www.tuxedo.org/esr/ writings/cathedral-bazaar/ [20 June 2005]. Ripoche, G., Sansonnet, J.-P., 2006. Experiences in automating the analysis of linguistic interactions for the study of distributed collectives. JCSCW 15 (2–3), 149–183. Sack, W., De´tienne, F., Ducheneaut, N., Burkhardt, J.-M., Mahendran, D., Barcellini, F., 2006. A methodological framework for socio-cognitive analyses of collaborative design of open source software. JCSCW 15 (2–3), 229–250. Sarant, S.A., 2004. The role of organizational boundary spanners in industry/ university collaborative relationship. Doctor of Philosophy in Psychology Dissertation Thesis. North Carolina State University, 2004. Sonnenwald, D.H., 1996. Communication role that support collaboration during the design process. Design Studies 17, 277–301. de Souza, C., Froelich, J., Dourish, P., 2005. Seeking the source: software source code as a social and technical artifact. In: Schmidt, K., Pendergast, M., Ackerman, M., Mark, G. (Eds), Proceedings of the GROUP ’05 Conference. ACM Press, New York, USA, pp. 197–206. Sowe, S., Stamelos, I., Angelis, L., 2006. Identifying knowledge brokers that yield software engineering knowledge in OSS projects. Information and Software Technology 48, 1025–1033. Stempfle, J., Badke-Schaub, P., 2002. Thinking in design teamsdan analysis of team communication. Design Studies 23, 473–496. Wenger, E., 1998. Communities of Practice: Learning, Meaning and Identity. Cambridge University Press, New York, USA.
Contents lists available at ScienceDirect
International Journal of Industrial Ergonomics journal homepage: www.elsevier.com/locate/ergon
Participation in online interaction spaces: Design-use mediation in an Open Source Software community Flore Barcellini a, d, *, Françoise De´tienne b, d, Jean-Marie Burkhardt c a
Cnam, Ergonomics Laboratory, Research Center on Work and Development, Case 210, 41 rue Gay-Lussac, 75005 Paris, France LTCI- UMR 5141dCNRS, Telecom Paris Tech, 46 rue Barrault, 75634 Paris Cedex 13, France c ErgonomicsdBehaviour and Interactions Laboratory, Universite´ Paris 5, 45 rue des Saints-Pe´res, 75006 Paris, France d INRIA, France b
a r t i c l e i n f o
a b s t r a c t
Article history: Received 21 December 2007 Received in revised form 15 July 2008 Accepted 16 October 2008 Available online 6 December 2008
This research aims at characterizing emerging roles fostering design-use mediation during the Open Source Software (OSS) design process through the analysis of participation. Studying OSS is of particular interest: (1) to investigate socio-technical settings supporting user participation to the design process, which is considered to be the major strength of OSS design; (2) to gain insights into supporting the changing nature of the software industry, which is becoming more and more distributed and global, and which is thus increasingly making use of OSS design tools and methods. In this research, we characterized effective roles of participants, i.e. participation, on the basis of activities analysis in three online interaction spaces (discussion, documentation and implementation) during a continuous ‘‘pushed-byusers’’ design process of the Python project. Participation is targeted through a methodology articulating: (1) structural analyses (organization of the discussions, regularity and involvement of participants, quotes-based social network) in usage-oriented and development-oriented mailing lists of the projects’ discussion space; (2) actions to the code and documentation made by participants in the implementation and documentation spaces. Besides the importance of the users’ contribution to the process, OSS design is fostered by some key-participants, the cross-participants, who act as boundary spanners between the developers and the users, helping them to go beyond some barriers to participation. These findings can be reinforced developing software to automate the structural analysis of discussions and actions to the code and documentation. Ó 2008 Elsevier B.V. All rights reserved.
Keywords: Design-use mediation Open source software Online community Distributed participatory design
1. Introduction Open Source Software (OSS) is software that can be run, distributed, studied, changed and improved by its users. The OSS design process is characterized by a communitarian and highly mediated design process. This new way of designing is becoming more and more important since there are thousands of OSS (famous examples are the Linux operating system or the Firefox internet browser) and millions of users of them. Mainly mediated by Internet tools, OSS design is distributed among three interaction spaces on the web (Sack et al., 2006): a discussion space (mailing lists, forums etc.), a documentation space (project-related documents archived on the net) and an implementation space (different versions of the software source code). Thus, it is a paradigmatic case of distant and asynchronous
* Corresponding author. E-mail addresses: fl[email protected] (F. Barcellini), francoise.detienne@tele com-paristech.fr (F. De´tienne), [email protected] (J.-M. Burkhardt). 0169-8141/$ – see front matter Ó 2008 Elsevier B.V. All rights reserved. doi:10.1016/j.ergon.2008.10.013
collaborative design, which has been less investigated, so far, than distant and synchronous (Olson and Olson, 2000; De´tienne et al., 2004), or co-located collaborative design (Olson et al., 1992; Stempfle and Badke-Schaub, 2002; De´tienne et al., 2005). Studying OSS is also of particular interest to gain insights into supporting the changing nature of the software industry, which is increasingly making use of OSS design tools and methods as it becomes more and more distributed and global (Gutwin et al., 2004). OSS design can also be considered as a continuous form of design: new functionalities can always be proposed and discussed at any step in the project (Gasser et al., 2003), forms of participation in OSS projects are supposed to be ‘‘open’’ in time and for different kinds of participants whatever their stake in the project (developers or users of the OSS). Thus, participants in OSS design can potentially be involved in all the phases of the design process (elicitation of needs and requirements, design and implementation), at least if they have the skills to do so. This is often the case as, in OSS, users can be highly skilled in computer science (Ducheneaut, 2005), as well as in particular application domains (e.g., education, biology, scientific computing, etc). Moreover, the
534
F. Barcellini et al. / International Journal of Industrial Ergonomics 39 (2009) 533–540
participation of users is considered to be the major strength of the OSS design process compared to proprietary ones: most bugs are detected and fixed because ‘‘there are many eyeballs looking at the problem’’ (Raymond, 1999). In this paper, we are interested in characterizing participation of various stakeholders engaged in a ‘‘pushed-by-users’’ continuous design process, in the interaction spaces of the Python programming language community. We assume that participation can be captured through the analysis of different activities performed in the three interaction spaces (discussion, documentation, implementation). This characterization will help us in addressing the main goal of our research: investigating forms of participations and effective roles emergence in OSS design process that may enhance mediation between users and developers. After highlighting some features of participation and its measure, as well as the design-use mediation process, we present our research questions and strategy. We then present an analysis of participation in the three interaction spaces that outlines key forms of participation enhancing the design-use mediation process in OSS communities. 2. Participation and design-use mediation process 2.1. Status and participation of users in OSS communities OSS projects have been characterized as online epistemic communities (Cohendet et al., 2000; Preece, 2000). Their members form a group of people connecting together on the Internet with a common goal: to develop software and to produce knowledge about the artifact they develop. Different statuses are outlined in OSS communities, related to the right and power to modify the source code. Some participants can modify directly the source code, they participate to the design process and to the decisions: (1) the project leader (generally the creator of the project as in Python); (2) the core team or administrators, who have to maintain the code base and the documentation; (3) the developers who participate to the evolution of the OSS and maintain some of its parts. Other participants are called ‘‘users’’. In an OSS context, users can be highly skilled in Computer Science, being far away of the classical notion of ‘‘end-users’’. They are called active users if they participate in mailing lists discussions as informants for newcomers, by reporting or correcting bugs with patches, and by proposing new modules. Other users are called passive users as they only use the software or lurk on the discussions and documentation spaces of the project. Despite this hierarchical view, it is possible to evolve in the community. Organization of the design process and roles effectively performed by participants can emerge from interactions rather than prescribed and formalized a priori. This emergence process is framed by implicit and explicit rules: volunteer participation, evaluation of work by a peer-review mechanism of works (e.g. Raymond, 1999); as well as norms: meritocracy. Thus, it is possible to evolve in the community proving ones value to ones peer and roles effectively performed by participants may not always correspond to their status. In this direction, the goal of this research is to characterize the forms of participations and the roles of participants with respect to activities performed in three interaction spaces (implementation, documentation and discussion) (Sack et al., 2006). The literature on OSS clearly identifies that active users take part in the evaluation phase of design (bug reporting and patching, e.g. Ripoche and Sansonnet, 2006) and that the project leader, administrators and developers participate in the design process itself, i.e. generating and evaluating solutions and taking decisions (Barcellini
et al., 2008a). Open issues are still to characterize the role of all active participants (project leader, administrators, developers and active users) regarding the design process itself and during the elicitation of the needs and requirements phase. In particular, we will focus on the design-use mediation process: how use and design are articulated when new functionalities are proposed, solutions are generated and evaluated; and what the links are between users and developers in OSS communities. 2.2. Design-use mediation process through boundary spanners roles We defined the role of boundary spanners on the basis of ‘‘communication or behavior among two or more networks or groups’’ (Sonnenwald, 1996). Boundary spanners span the gap among different teams, moving among them and transferring information about the state of the project. Boundary spanners appear to be of particular importance in collaborative design situations and they tend to produce innovative solutions to design problems (Sonnenwald, 1996). They are also key participants who can enhance coordination through informal communications (Krasner et al., 1987; Grinter, 1999). They reduce the amount of information lost or miscommunicated among different phases of design development and different development teams. They also foster the mutual learning process occurring through perspectives confrontation in the design process (e.g. Be´guin, 2003). Thus, boundary spanners can help technology-use mediation in the design situation (Bansler and Havn, 2006). In non-design situations, it has been described that they can also protect their organization against external pressure or can represent their organization (Sarant, 2004) and that boundary spanning is a way to develop a horizontal expertise and collective concept formation (Engestro¨m et al., 1995). This role is similar to the role of brokers that foster learning process in community of practices (Wenger, 1998). The role of boundary spanners is not a formal one but rather a role emerging from interactions and practices. Becoming boundary spanners requires to have developed skills and competencies in the different fields that are spanned, to be aware of all practices and to gain in legitimacy and credibility in the domains they span. 3. Research question and research strategy 3.1. Research question In this research, we will consider the specific role of boundary spanners as mediators between users and developers in the OSS design process. Our hypothesis is that successful design-use mediation may be supported by boundary spanner roles emerging from interactions between users and developers. As far as we know, in OSS design, and more generally in mediated, asynchronous and distant design situations, the role of boundary spanners has not been investigated yet. In this direction, we have developed a methodology to characterize participation in the three interaction spaces (discussion, documentation and implementation) of an OSS design project, Python, into a specific ‘‘pushed-by-users’’ process. This research strategy is presented in the section below. 3.2. Research strategy 3.2.1. Approaches to identify boundary spanning activities We investigate boundary spanners activities with a cognitive ergonomics approach, by a specific focus on participants’ activity, reflecting their roleddistinct from statusdin the design process
F. Barcellini et al. / International Journal of Industrial Ergonomics 39 (2009) 533–540
(Baker et al., 2003). Although the role is dependent upon status of the participant in the community, i.e. the power he/she has on the artifact being designed, it is also contingent upon the participants’ activities in the design process (Sonnenwald, 1996; Mahendran, 2002). Various characterizations of activities in online communities and also in global design have been developed within the social network analysis (SNA) approach (e.g. Madey et al., 2002; Gonzalez-Barahona et al., 2004): for instance measures such as betweenness, centrality, or closeness among participants. Such measures may serve various research issues related to collective design. Among these issues, one question concerns coordination with respect to actor centrality measures in the social network and also to task interdependencies (e.g.de Souza et al., 2005; Hossain et al., 2006). Another issue concerns the evolution of people in the OSS communitydfor instance progressive integrationdas seen by temporal evolution from a peripheral position to a more central position into the socio-technical network (e.g. Ducheneaut, 2005). One question of special interest for this paper concerns key participants establishing links among groups, in particular between developers and users communities. In this direction, one recent study (Sowe et al., 2006) has identified OSS project participants, referred to as knowledge brokers, who bridge the gap among expert software developers and users communities in the Debian OSS project. Based on SNA, they identified boundary spanners as actors who participated across three mailing lists of the project. Several limitations of this work can be pointed out. Firstly, the analysis is done on all posts in the mailing lists during a given period of time and does not distinguish posts with respect to the design process. Our position is that participation across boundaries should be assessed in the context of a particular design objective. Thus, we examine participation and evolution of participation in the context of a particular OSS design process, identified as ‘‘pushed-by-users’’. Secondly, the participants ‘‘across lists’’, which we will call common participants in our study, may post in various periods of time and on various topics. Our position is that this measure is not strict enough to select knowledge brokers as posts may refer to completely different topics and to different steps in the design process. We propose to measure cross-participation in mailing lists, as a better indicator for identifying boundary spanners; crossparticipants being those who post across mailing lists in parallel same topic discussions. Thus cross-participants form a subset of common participants and their participation is contextualized in the evolution of a design process. Finally, SNA studies usually focus on one interaction space, e.g. the discussion space for Sowe et al. (2006), or the implementation space for de Souza (2005). Our position is that one needs to examine participation and activities in the three interaction spaces (discussion, documentation and implementation), in order to have a broader view of participation. We assume that the role of boundary spanners must be investigated according to three dimensions: a discursive one and social one mostly performed in the discussion space, but also a technical one, mostly performed in the documentation and implementation spaces. Moreover, activities (or roles) of boundary spanners may not be equally distributed in these spaces. In a previous paper (Barcellini et al., 2008b) we outlined, through a message content analysis (activities and references/ knowledge sharing) that cross-participants provide knowledge about both the usage-oriented application domain and the development-oriented programming domain (computer-science) during the final part of the ‘‘pushed-by-users’’ design process, i.e. the successful part of the process which leads to the implementation of the initial needs of users. This way, they cross the boundaries between users and developers communities acting as boundary spanners. In this paper, we will characterize participants’ activities on the basis of structural analyses of participation in the three
535
interaction spaces of an OSS project (discussion, documentation and implementation) to investigate more deeply identified keyparticipants roles in the three spaces. Furthermore, we will consider the whole design process, taking into account previous unsuccessful design proposals. 3.2.2. Python community and interaction spaces This research is focused on a major OSS project called Python, which is a programming language. This project has a large community of users in various application domains and a stable core group of developers who are designing the Python Core language and its standard library (Fig. 1). In this research, we try to understand how needs from application domains may impact and enhance the design of the Python core language (symbolized by arrows in Fig. 1). As already stated, OSS design is distributed among three online interaction spaces (Sack et al., 2006): the discussion, documentation and implementation spaces. The major part of OSS design occurs in the discussion space composed of different mailing lists or newsgroups (Mockus et al., 2002; Barcellini et al., 2005). As all discussions are publicly available and archived online, they constitute rich traces of the OSS design process. In the Python project there are two main mailing lists: A usage-oriented mailing list, the python-list, is about general discussions and questions about Python. Posting to this mailing list is the main means for an active user to participate to the Python project. Most discussions on python-list are about developing with Python, not about development of the Python language itself. A development-oriented mailing list, the python-dev, is for work on developing Python (fixing bugs and adding new features to the Python language). This is the heart of Python’s development. Anyone can subscribe to python-dev, though his/her subscription will have to be approved. The list address accepts e-mail from non-members, and the python-dev archives are public. The documentation space is composed by all documents, websites and wikis relative to the project. For instance, the Python community has set up a process to propose and document the introduction of new feature into the language the Python Enhancement Proposal (PEP). Thus, the documentation space contains all PEP documents and their versions. Finally, the implementation space contains the proper code of Python: the standard library and its modules their versions and the traces of their revisions.
Fig. 1. The Python galaxy (modified from Barcellini et al., 2008a).
536
F. Barcellini et al. / International Journal of Industrial Ergonomics 39 (2009) 533–540
3.2.3. Focus on a continuous ‘‘pushed-by-users’’ design process The work presented here focuses on a ‘‘pushed-by-users’’ design process, seen as a continuous design process. During this process, various stakeholders (users or developers) can participate in different steps of the process (proposition of new functionality, elaboration of needs, elaboration of specifications, implementation, etc.). The process studied concerns the introduction of a decimal type in Python and its related decimal.py module. There have been several unsuccessful proposals, i.e. not scored by an accepted PEP and its implementation, to introduce a decimal type in Python. A first decimal.py module was also proposed but was still to be implemented. Then, a successful proposal was initiated by a user of Python, whom we will refer to as the user-champion, who is a developer of a project in the financial application domain of Python (http://sourceforge.net/projects/sigefi). The first need of the user-champion was for a money type, but it appeared that before introducing a money type, work had to be done in the decimal type in Python. The user-champion formalized this proposal through a PEP document that became an accepted PEP (PEP 327). For a more detailed description of the PEP 327 design process, one can refer to our previous publication (Barcellini et al., 2006).
4. Method 4.1. Data collection In the discussion space, all discussions are available online (http://mail.python.org/pipermail/python-list/ or /python-dev/). The data were gathered by searching, by hand, from the python-list (usage-oriented mailing list) and the python-dev mailing list (development-oriented mailing list) for the keywords contained in the subject header of all messages: decimal, money, currency, fixed-point (old solution to resolve decimal problems) and the name of the user-champion. The search was performed from the first formalization to introduce a decimal module in May 2001 to May 2006 (when we began this study). Each message, which was gathered, required reading by the first author of this paper to ensure it was indeed a message dealing with the design issue. If a discussion took place in another thread we collected this motherthread. The data collected are split in two corpora on the basis of the formalization of the proposal through an accepted pre-PEP (Table 1). The first one is related to discussions, which did not lead to official formalization of the proposals into a pre-PEP. This corpus is called unsuccessful decimal proposals (from the first formalization of a decimal module in May 2001 to October 2003, the day before the first post of the user-champion). The second one is related to the discussions, which lead to the formalization of the first proposal into a pre-PEP followed by an accepted pre-PEP. This corpus is called successful decimal proposal corpus (from the first post of the user-champion in October 2003 to May 2006). Table 1 Description of the two corpora.
Nb Discussions Nb Participants Nb Messages
Unsuccessful decimal proposals
Successful decimal proposal
Py-list
Py-dev
Py-list
Py-dev
10 66 192
6 22 122
22 95 340
29 48 406
In the documentation and implementation spaces, Python code, pre-PEP and PEP document revisions (modifications) are also archived and available online (http://svn.python.org/view/). We searched in the various folders for the decimal.py module and the PEP 327 modifications. It concerned only the successful proposal corpus as: none PEP dealing with decimal were accepted before PEP 327; and because the first version of decimal module, announced in May 2001, was in the ‘‘sandbox’’ of the project, i.e. as to be done. Concerning the decimal.py module; we collected 44 revisions from 1 July 2004 (first revision) to 11 May 2006 (end of the collected data). Concerning the PEP 327 document, we collected nine revisions from 29 June 2005 (last archived revisions).
4.2. Data analysis In the discussion space, we will analyze discussions related to the design process in both the usage-oriented mailing list (pythonlist) and the development-oriented mailing list (python-dev). We will investigate the temporal organization of the design process and the dimension of participation according to this organization (regularity of the participation, presence of common participants and cross-participants between the usage-oriented and the development-oriented mailing lists). In the documentation and implementation spaces we will analyze participation via the modifications’ actions and who made them. The different versions of the PEP related to the successful design process we study (PEP 327) in the documentation space and the different versions of the decimal.py module related to the design proposal we study (which is the live implementation of the PEP 327) in the implementation space. 4.2.1. Temporal and design-related organizations of discussions We characterize the organizations of discussions, according to several dimensions: the global organization of discussions, the design-step organization, the temporal delay among discussions, the presence of same-topic parallel discussions. This organization helps us in positioning participation into design process steps. The global organization of discussions in parallel in the two mailing lists and for the two corpora. For each discussion of the two corpora, we identify by hand the first and the last messages and extract the corresponding dates, and the subject-header of the discussions. We then position each discussion along a timeline. The design-step organization of discussions according to time, i.e. group of discussions dealing with same online design steps: elicitation of needs, proposals, pre-PEP, PEP design, refinements, valorization of the implemented module, tutorials, debug and evolution. These groups are constituted according to their subject-header and a rapid content overview. The temporal delay among discussions’ opening within each mailing list in each corpus. This is an indicator of the follow-up of the proposals’ discussions. It corresponds to the means of the delay among the beginning’s date of each discussion. The presence of parallel same-topic discussions in the two mailing lists, as an indicator of the thematic coherence between the usage-oriented and the development-oriented mailing lists. They are same-subjects discussions occurring in the two mailing lists, that overlap in time. To identify them, we compare subjects and dates of discussions in the two mailing lists.
F. Barcellini et al. / International Journal of Industrial Ergonomics 39 (2009) 533–540
4.2.2. Characterization of participation in the three interaction spaces 4.2.2.1. In the discussion space. In the discussion space, to highlight the participation we identify different dimensions of participation that can reveal some key-participation: regularity of participation, presence of common and cross-participants and involvement of participants. The regularity of participation, for each mailing list within each corpus is measured according to the number of discussions in which participants are involved in a particular mailing list. Regular participants are those who participate in more than, or equal to, the third quartile value of the number of discussions in which participants are involved (with Q3 ¼ 2 in the unsuccessful proposals corpus, 1 in python-list and 2 in python-dev for the successful proposal corpus). Others are called occasional participants. The presence of common participants within the two mailing lists in a same corpus, who are those present, at least once, in both python-dev and python-list. To identify these participants we compare among the mailing lists, the name of posters for each discussion of the corpora. A subcategory of common participants is cross-participants between the users and the developers’ mailing lists in the two corpora. We define cross-participants (an extended notion of crossposters, Kollock and Smith, 1996) as persons who participate at parallel same-topic discussions, occurring in the two mailing lists. To identify the cross-participants, we compare the name of the posters in the same-topic parallel discussions. We also verify that this cross-participation is not simple cross-posting, i.e. messages sent by cross-participants always were different in the two mailing lists except for one message. The involvement of participants in each mailing list and in each corpus is characterized by the number of messages posted by each category of participants (Project Leader, Regular only, Occasional only, Common and Cross-participants). Finally, we investigate the social network in which identified key-participants are involved. This is done on the basis of the quotation patterns among messages posters: i.e. who is quoting whom, to highlight interactions among participants. Quotation, i.e. the integration of a part of a previous message(s) in another one is a compensatory linking strategy used by participants to maintain the context in online discussions (Herring, 1999). In a previous paper (Barcellini et al., 2005), we have shown that the organization of messages according to the quoting link is relevant to reconstruct the thematic coherence of online discussions and to understand the interactions among participants in terms of verbal turns. Blocks of
537
quotation are identified in each message by the greater than symbol ‘‘>’’. Then, we search manually in the corpus from which message and which author each quote comes from to obtain a table of ‘‘who is quoting whom’’. 4.2.2.2. In the documentation and implementation spaces. In the documentation and implementation spaces, we collect the names of the participants who proposed revisions in the PEP 327 document and the decimal.py revisions and explicit references to other participants’ works in the content of the revision. Indeed as some rights control the CVS access, developers may modify the code on behalf of other ones. In this situation, the social rules of OSS communities fix to acknowledge other works. This structural analysis has been complemented by e-mail interviews with the user-champion and one of the crossparticipants. 5. Results 5.1. Temporal and design-related organization of discussions We constructed temporal views of the unsuccessful and the successful design proposals (Figs. 2 and 3 respectively). Each action in one of the three interaction spaces (discussion in python-dev and python-list for the discussion space; modification of PEP document for the documentation space; modification of version of code for the implemented space) is represented, in parallel, along the timeline by a circle. In the discussion space, they are labeled using the subject of the discussions or their corresponding design-step for groups of discussions (black circle). In the unsuccessful decimal proposals (Fig. 2), we identify three attempts to propose a decimal type, in python-dev (Pep adding a decimal type to Python in July 2001; Proposal: add basic money type in March 2002 and a Add decimal (aka fixed point) to Python in December 2002). They are not followed by same-topic discussions either in python-dev or in python-list. Two design-step-related groups of discussions emerge (Proposal for a decimal type and Elicitation of needs for monetary and decimal arithmetic) but there are local and are not followed by other steps of a design process (Pre-PEP or PEP) as they are not accepted. Consequently, there is no action in the documentation and implementation spaces. In the successful decimal proposal (Fig. 3), there are more structured discussions: the first discussion Elicitation for a Money DT is followed by groups of discussions dealing with the designsteps. Indeed, the mean temporal delay among following
Fig. 2. Representation of actions regarding the unsuccessful decimal proposal corpus in the three interaction spaces.
538
F. Barcellini et al. / International Journal of Industrial Ergonomics 39 (2009) 533–540
Fig. 3. Representation of actions regarding the successful decimal proposal corpus in the three interaction spaces.
discussions is about 30 days in the successful proposal corpus and 63 in the unsuccessful one. This means that there is more follow-up of discussions in the successful proposal than in the unsuccessful ones. In the documentation space, one can see the creation of the PEP document as soon as the PEP is declared accepted in the discussion space. The implementation began, few months later after design discussions occur in python-dev. This implementation corresponds also to the champion vacations, where he had some time to begin the work, as he declared during an interview. Moreover, there are five parallel same-topic discussions (labeled using vertical ached lanes) in the successful proposal corpus whereas there are none in the unsuccessful one. These temporal analyses of the discussions allow us to outline two main specificities of the successful design process: (1) there are parallel same topic discussions in the two mailing lists; (2) we can form design-steps-related group of discussions highlighting the design continuity of discussions in mailing lists. 5.2. Participation to the discussion space 5.2.1. Distribution of participation Table 2 describes the participation for each mailing list in each of the two corpora. The distribution of participation is different between the two corpora (Fisher’s Exact Probability Test ¼ 0.016). Globally, it outlines that they are more participants involved in the successful proposal in both the mailing-list. Most of the participants are occasional ones in both mailing lists and corpora. This result highlights a turnover of participants in the mailing lists, in particular in the python-list. Relative deviation (V2 Cramer ¼ 0.04)1 indicates that regular participants tend to participate more in the python-list for the unsuccessful corpora. This result suggests that the presence of regular participants in discussions does not guarantee the design proposal to be successful. Concerning common and cross-participants, in the unsuccessful proposals discussions, we identify out of the 84 different participants:
1
There is a positive association between two variables (an attraction), when Relative Deviaton (RD) is positive; and, repulsion when it is negative. The coefficient V2 Cramer gives the global association between the two variables; it is a synthesis of all the local RDs. The association is insignificant for 0 < V2 < 0.04; intermediary if 0.04 < V2 < 0.16; and, strong otherwise. Even if the global association is insignificant, local RDs can highlight some interesting associations.
Four common participants (6%): two users, one administrator who is known as a specialist of the decimal domain and who provided the previous solution (fixed-point) to cope with the lack of decimal module in Python, and one developer who proposed the first decimal module (version 0). The two last ones are regular participants in both corpora. As there are no same-topic parallel discussions in the unsuccessful decimal proposals corpus, there are no cross-participants between the two mailing lists, for this corpus. In the successful proposal corpus, we identify out of the 130 different participants: Thirteen common participants (10%): two administrators, five developers, and six users. Seven are occasional participants in both mailing lists and six are regular ones: four of the crossparticipants described below, two developers and a user. Five cross-participants (4%), among the 13 common participants: the user-champion (he was not formally defined as a developer at the beginning of the process and was the project leader of a financial project), an administrator and a developer (also identified as common participants in the unsuccessful corpus), another developer and one user. All, except the user, are regular participants in the corpus, In the successful proposal corpus, there are proportionally more common participants than in the unsuccessful proposals. Moreover, the successful proposal is characterized by cross-participants who appear to be mostly regular in their participation.
Table 2 Distribution of participation in each corpus and for each mailing list (number of participants). Unsuccessful proposals
Project leader Regular participants Occasional participants Common participants Cross-participants Total
Successful proposal
Py-list
Py-dev
Py-list
Py-dev
0 16 45 4 0 65
1 2 10 4 0 17
0 19 63 8 5 95
1 5 29 8 5 48
(25%) (69%) (6%) (100%)
(6%) (12%) (59%) (23%) (100%)
(20%) (66%) (9%) (5%) (100%)
(2%) (10%) (61%) (17%) (10%) (100%)
F. Barcellini et al. / International Journal of Industrial Ergonomics 39 (2009) 533–540 Table 3 Involvement of participants in each corpus and for each mailing list (number of posted messages).
Project leader Regular participants Occasional participants Common participants Cross-participants Total
Unsuccessful proposals
Successful proposal
Py-list
Py-dev
Py-list
Py-dev
0 108 62 22 0 192
24 30 15 31 0 100
0 120 73 9 138 340
19 67 76 58 186 406
(56%) (32%) (11%) (100%)
(24%) (30%) (15%) (31%) (100%)
(35%) (21%) (3%) (41%) (100%)
(5%) (17%) (19%) (14%) (46%) (100%)
5.2.2. Involvement Table 3 clarifies the involvement of participants for each mailing list and each corpus. The distribution is different between the two corpora (c2 ¼ 386, d.f. ¼ 12; p < 0.0001). All common participants appear to be more involved, especially in python-dev, where they posted 60% (234/406) of all messages. The major involvement is from the cross-participants and the Project Leader but only in python-dev. Moreover, the involvement of the Project Leader is stronger in the unsuccessful proposals corpus than in the successful one. It may outline the different position of the project leader in the unsuccessful vs. successful corpora. In the first case, he was more framing the proposal as he was the unique guarantor of the design process, whereas in the successful proposal this role may be distributed among the cross-participants. This result highlights that the cross-participants seem to be keyparticipants fostering the design process in the successful attempt, being the most involved and guarantying the follow-up of the design process. Moreover, as two cross-participants were already present (common participants) in the unsuccessful proposals corpus, we can argue that the ‘‘memory’’ they have about the design history and rationale may help to foster the design process. In the following, we investigate more deeply the role of the cross-participants in the three interaction spaces. 5.3. Roles of the cross-participants in the successful proposal 5.3.1. Cross-participants acting as boundary spanners between users and developers in the discussion space For the discussion space, the attraction graph in Fig. 4 represents who tends to quote whom in both python-list and python-dev, and in which mailing list. This graph is based on the relative deviation analysis that measures the association between two nominal variables. It outlines that cross-participants tend to be the link between the users’ community (U) and the developers’ community (A-D and PL) with a specific position for the user-champion (U-C, who is also a CP) who quotes and is quoted more by the project leader (PL) and the administrators–developers (A-D), i.e. the developers’ community. The user championing the PEP is a key cross-participant enhancing harmonious social relationships referring to other persons’ works, and a coordination agent doing synthesis and posting news about the design process in mailing lists (Barcellini et al., 2008b). Moreover, we outlined that he received a social and discursive support from other cross-participants.
Fig. 4. Attractions graph of who tends to quote whom (Barcellini et al., 2008b).
539
5.3.2. Low contributions of the cross-participants in the implementation and documentation spaces In the documentation space, common participants who are not cross-participants made all the revisions. One unique administrator made five (out of nine) revisions. The four other revisions were made by a specific developerdthe PEP editor, who is in charge of the PEP management. In all these four revisions he specified that it was the user-champion contribution. In the implementation space, all the revisions were made by common participants, except one from the project leader: 77% (34/ 44) of revisions were made by the same administrator than in the documentation space, 9% by the user-champion (4/44 from which one effective and three by being referenced), two by the crossparticipant specialist of decimals (the specialist of decimal). However, this low contribution of cross-participants, in the implementation and documentation spaces, should be nuanced on the basis of our interview with the user-champion. Indeed, he declared that the three other cross-participants (i.e. except himself and the other user) ‘‘helped a lot’’, such as the administrator strongly present in the implementation space. This technical support could be performed through the embodiment of code in messages or through private exchanges. 6. Discussion and perspectives Our work provides a new way of measuring participation in OSS design, alternative to the methods proposed in SNA analysis (e.g. Sowe et al., 2006). We propose a methodology that leads to assessment of participation in the three interaction spaces (discussion, documentation and discussion) through the activities effectively performed by various stakeholders in a continuous ‘‘pushed-by-users’’ design process, leading to formalized specifications (a PEP documenting the new functionality) and implementation (the implemented module of this functionality). In the discussion space, we outline that common participation in several mailing lists is not a sufficient indicator to identify boundary spanning roles. We show that cross-participants, participating to same-topic discussions in a specific design process, do act as boundary spanners relaying and supporting user participation, fostering this way the design-process and guarantying the followup of the process. We also show that various roles are performed in the three interaction spaces: boundary spanners being more active in the discussion space than in the documentation and implementation spaces. We plan to extend this work performing interviews with cross-participants and some users involved in this design process to contextualize our data and highlight how their participation is articulated with their activities and needs. We also plan to highlight other conditions, and perhaps barriers, i.e. skills needed, to users’ participation in OSS communities. The contribution of our work is also methodological. Indeed, it confirms that participation must be investigated in the three interaction spaces in order to gain a broader view of the design-use mediation process. Considering the large quantity of data in OSS communities it is tempting, and it is often the case, to use only structural analyses such as social network analysis to characterize OSS design process. We have attempted to illustrate that the combination of structural analyses in the three interaction spaces in which participants are involved is essential to capture the richness and the complexity of the OSS design process. To enrich our findings, this method could be automated (structural analysis) or semiautomated (content analysis). The automation of the method can be useful for the researchers but also the participants in OSS design. Indeed, a tool enabling various stakeholders in a design process to visualize who is participating, at which step of the design process, in which context and which mailing-list, could support mutual awareness of the
540
F. Barcellini et al. / International Journal of Industrial Ergonomics 39 (2009) 533–540
design process (Carroll et al., 2006) or regulation of the design process. These structural functionalities (temporal organization, identification of regular/occasional, common and cross-participants) may complement discussion visualization tools as discussed in previous research (Barcellini et al., 2008a). Acknowledgments This research is funded, through a Ph.D., by the Cnam, INRIA, and the French Research department. References Baker, F., De´tienne, F., Lund, K., Se´journe´, A., 2003. Articulation entre e´laboration de solutions et argumentation polyphonique. In: Bastien, J.C. (Ed.), EPIQUE ’03. INRIA, Rocquencourt (France), pp. 235–240. Bansler, J.P., Havn, E., 2006. Sensemaking in technology-use mediation: adapting groupware technology in organizations. JCSCW 15 (1), 55–91. Barcellini, F., De´tienne, F., Burkhardt, J.M., 2006. Users’ participation to the design process in a free open source software online community. In: Romero, P., Good, J., Bryant, S.A, Chapparo, E. (Eds.), Proceedings of PPIG ’06, pp. 99–114. Barcellini, F., De´tienne, F., Burkhardt, J.M., Sack, W., 2008a. A socio-cognitive analysis of online design discussions in an Open Source Software community. Interacting with Computers 20, 141–165. Barcellini, F., De´tienne, F., Burkhardt, J.M., 2008b. Users and developers mediation in an Open Source Software Community: boundary spanning through cross participation in online discussions. International Journal of Human Computer Studies 66 (7), 558–570. Barcellini, F., De´tienne, F., Burkhardt, J.M., Sack, W., 2005. Thematic coherence and quotation practices in OSS design-oriented online discussions. In: Schmidt, K., Pendergast, M., Ackerman, M., Mark, G. (Eds), GROUP 2005 Conference, pp.177–186. Be´guin, P., 2003. Design as a mutual learning process between users and designers. Interacting with Computers 15, 709–730. Carroll, J.M., Rosson, M.B., Convertino, G., Ganoe, C.H., 2006. Awareness and teamwork in computer-supported collaborations. Interacting with Computers 18, 21–46. Cohendet, P., Creplet, F., Dupoue¨t, O., 2000. Organisational innovation, communities of practice and epistemic communities: the case of Linux. In: Kirman, A., Zimmermann, J.B. (Eds.), Economics with Heterogeneous Interacting Agents. Springer, The Netherlands. De´tienne, F., Boujut, J.-F., Hohmann, B., 2004. Characterization of collaborative design and interaction management activities in a distant engineering design situation. In: Darses, F., Dieng, R., Simone, C., Zaklad, M. (Eds.), Cooperative Systems Design. IOS Press, pp. 83–98. De´tienne, F., Martin, G., Lavigne, E., 2005. Viewpoints in co-design: A field study in concurrent engineering. Design Studies 26 (3), 215–241. Ducheneaut, N., 2005. Socialization in an open source software community: a sociotechnical analysis. JCSCW 14, 323–368. Engestro¨m, Y., Engestro¨m, R., Ka¨rkka¨inen, M., 1995. Polycontextuality and boundary crossing in expert cognition: learning and problem solving in complex work activities. Learning and Instruction 5, 319–336. Gasser, L., Scacchi, W., Ripoche, G., Penne, B., 2003. Understanding Continuous Design in F/OSS Project. ICSSEA-03, Paris, France. Grinter, R., 1999. SystemsArchitecture: Product Designing and Social Engineering, San Francisco, CA, USA.
Gonzalez-Barahona, J.M., Lopez, L., Robles, G., 2004. Community structure of modules in the Apache Project. In: Proceedings of the 4h International Workshop on Open Source Software Engineering. Edinburgh, Scotland, pp. 44–48. Gutwin, C., Penner, R., Schneider, K., 2004. Group awareness in distributed software development. In: Proceedings of CSCW 2004. ACM Press, New York, USA, pp 72–81. Herring, S., 1999. Interactional coherence in CMC. In: Proceedings of the 32nd Hawaii Conference on System Sciences, Maui Island, HI, USA, 5–8 January, p. 13. Hossain, L., Wu. A., Chung, K., 2006. Actor centrality correlates to project based coordination. In: Hinds, P., Martin, D. (Eds), Proceedings of the CSCW ’06 Conference, pp. 363–372. Banff, Canada, Nivember 4–8. Kollock, P., Smith, M., 1996. Managing the virtual commons. In: Herring, S. (Ed.), Computer-Mediated Communication: Linguistic, Social, and Cross-Cultural Perspectives. John Benjamins, Amsterdam, The Netherlands, pp. 109–128. Krasner, H., Curtis, B., Iscoe, N., 1987. Communication breakdowns and boundary spanning activities on large programming projects. In: Olson, G. (Ed.), Empirical Studies of Programmers. Ablex, pp. 47–64. Madey, G., Freeh, V., Tynan, R., 2002. The open source software development phenomenon: an analysis based on social network theory. In: Proceedings of the Americas Conference on Information Systems (AMCIS2002), Dallas, TX, pp. 1806–1813. Mahendran, D., 2002. Serpents and Primitives: An ethnographic excursion into an Open Source community. Master’s Thesis, School of Information Management and Systems, University of California at Berkeley. Mockus, A., Fielding, R.T., Herbsleb, J., 2002. Two Case studies of open source software development: Apache and Mozilla. ACM TSEM 11 (3), 309–346. Olson, G.M., Olson, J.S., Carter, M.R., Storrosten, M., 1992. Small group design meetings: an analysis of collaboration. Human-Computer Interaction 7, 347–374. Olson, G.M., Olson, J.S., 2000. Distance matters. Human-Computer Interaction 15, 139–178. Preece, J., 2000. Online Communities: Designing Usability and Supporting Sociability. John Wiley and Sons, New York, USA. Raymond, E.S., 1999. The cathedral and the bazaar. http://www.tuxedo.org/esr/ writings/cathedral-bazaar/ [20 June 2005]. Ripoche, G., Sansonnet, J.-P., 2006. Experiences in automating the analysis of linguistic interactions for the study of distributed collectives. JCSCW 15 (2–3), 149–183. Sack, W., De´tienne, F., Ducheneaut, N., Burkhardt, J.-M., Mahendran, D., Barcellini, F., 2006. A methodological framework for socio-cognitive analyses of collaborative design of open source software. JCSCW 15 (2–3), 229–250. Sarant, S.A., 2004. The role of organizational boundary spanners in industry/ university collaborative relationship. Doctor of Philosophy in Psychology Dissertation Thesis. North Carolina State University, 2004. Sonnenwald, D.H., 1996. Communication role that support collaboration during the design process. Design Studies 17, 277–301. de Souza, C., Froelich, J., Dourish, P., 2005. Seeking the source: software source code as a social and technical artifact. In: Schmidt, K., Pendergast, M., Ackerman, M., Mark, G. (Eds), Proceedings of the GROUP ’05 Conference. ACM Press, New York, USA, pp. 197–206. Sowe, S., Stamelos, I., Angelis, L., 2006. Identifying knowledge brokers that yield software engineering knowledge in OSS projects. Information and Software Technology 48, 1025–1033. Stempfle, J., Badke-Schaub, P., 2002. Thinking in design teamsdan analysis of team communication. Design Studies 23, 473–496. Wenger, E., 1998. Communities of Practice: Learning, Meaning and Identity. Cambridge University Press, New York, USA.