به اشتراک گذاری دانش در تیم های پروژه نرم افزار منبع باز : چشم انداز سیستم حافظه انتقالی

The extant studies have not empirically examined the possible team cognitive mechanisms that facilitate knowledge sharing in OSS teams, even though knowledge sharing is a cognitive task and an OSS team is a complex cognitive system. To fill this research gap, we adopt the perspective of transactive memory system (TMS) to explore the relationships among TMS, knowledge sharing, communication quality, and technical achievement of OSS teams. By analyzing data from 95 OSS projects with the partial least squares (PLS) method, our study demonstrates that several TMS dimensions have positive impacts on knowledge sharing behaviors and communication quality. Moreover, communication quality positively influences technical achievement of OSS teams. These findings provide useful implications for literature and practice.

Open source software (OSS) has generated much excitement in the software market. Companies have been considering OSS as a viable and economic substitution for proprietary software to support their business processes for quite some time (Andersen-Gott, Ghinea, & Bygstad, 2012). The New York Stock Exchange (NYSE) adopted Linux recently to support its electronic trading platform due to low cost, flexibility, and high level of security associated with Linux (Asay, 2008). Quite a few software producing firms, such as Red Hat, Geeknet, and Mozzilla, have centered their business models on OSS. Even Microsoft, the leading ideological opponent of the OSS community, launched its own OSS hosting site, CodePlex, in July 2006 (Voth, 2006). The OSS development differs significantly from the traditional in-house software development in three aspects: first, OSS is distributed under copy-left licenses, which guarantee that everyone has free and unrestrictive access to the source code of software (Colazo et al., 2005 and Waring and Maddocks, 2005). On the other hand, the traditional software is distributed under copyright licenses. Such licenses only grant the license holders the access to the source code, and others are only able to view the binary code. Therefore, the traditional software is often called closed source software (CSS). Second, whereas CSS is developed by organizational teams with commercial purposes, OSS is largely built and maintained by teams of voluntary developers. These developers are self-motivated by altruism, learning purpose, career advancement, and personal software need (Bonaccorsi and Rossi, 2003, Lerner and Tirole, 2002, Raymond, 2001 and Ye and Kishida, 2003). Third, OSS developers are geographically dispersed and rarely, if ever, meet face-to-face (Feller & Fitzgerald, 2002). They have to rely completely on Internet tools, such as mailing lists and concurrent version control systems, to communicate and collaborate with each other (Wayner, 2000). Therefore, an OSS team is viewed as a form of distributed teams with pure virtualness (Alborts et al., 2008 and Griffith et al., 2003), or pure virtual teams in Griffith et al.’s term. Although the developers of CSS teams may be also geographically distributed, the face-to-face communication is generally available at some points of the development cycle. Thus, CSS teams have far less degree of virtualness than OSS teams and may be best classified as hybrid teams (Griffith et al., 2003). In spite of significant differences in licensing schemes, motivations, and virtualness, one thing remains the same for both OSS and CSS teams; that is, the knowledge intensive nature of software development. Knowledge is the most important resource for software development (Robillard, 1999), which involves a wide range of specialized knowledge, such as system design, programming, and business rules (Rus & Lindvall, 2002). Software development essentially is a process in which developers purposely share and integrate their individually possessed specialized knowledge to design a software solution for an applied problem (Tiwana, 2004). Therefore, effective knowledge sharing is the key for the success of software development. This is true for both OSS and CSS teams. However, OSS teams face particular knowledge sharing challenges due to the highly distributed environment and self-directed workforce (Crowston, Wei, Howison, & Wiggins, 2012). The fact that hundreds of OSS with good quality has been successfully produced (Stamelos, Angelis, Oikonomou, & Bleris, 2002) suggests that some OSS teams cope with the challenges well. Consequently, a stream of research has emerged to examine the mechanisms that help overcome knowledge sharing barriers in OSS teams. For example, Ciborra and Andreu (2001) studied the case of the Linux community and found that four particular characteristics of the community contribute to the effectiveness of knowledge sharing: first, the final product (i.e., the Linux kernel program) is a piece of codified, explicit knowledge, thus well suited to knowledge transfer; second, the coordination needed in the development process is pre-specified by the software structure; third, the Internet and associated tools help avoid communication bottlenecks; lastly, the OSS culture promotes openness and sharing. Lanzara and Morner (2004) paid particular attention to digital communications in the Linux community. They argued that electronic communication artifacts, such as mailing lists, provide a virtual work environment, where knowledge is exchanged, discussed, and evolved. From the perspective of strategic interaction, Kuk (2006) investigated knowledge sharing in the KDE project (i.e., the graphic user interface for UNIX stations). He reported that strategic interaction has a positive impact on knowledge sharing. However, extreme interaction concentration leads to underutilizing knowledge resources. Sowe, Stamelos, and Angelis (2008) analyzed conversations on the mailing list of the Debian project and revealed that knowledge sharing activities might be best explained in terms of fractal cubic distributions. Gächter, von Krogh, and Haefliger (2010) applied the game theory perspective to research why OSS developers initiate knowledge sharing. They found that economic incentives and social preference might play important roles. Despite valuable insights into knowledge sharing behaviors of OSS developers, the extant studies are largely focused on a few successful cases, such as Linux, KDE, and Debian. It is questionable whether their findings are generalizable to the large population of OSS projects. More importantly, knowledge sharing is a cognitive task and an OSS team is a complex cognitive system (Sowe, Stamelos, & Angelis, 2006), but existing studies have not empirically examined the possible team cognitive mechanisms that facilitate knowledge sharing in OSS teams. Team cognition literature suggests that transactive memory system (TMS), as a team cognitive mechanism, is especially useful in highly distributed teams because it synchronizes members’ communication “based on unspoken assumptions about what others in the group are likely to do” (Wittenbaum & Stasser, 1996, p. 3). TMS refers to a team-level knowledge-holding structure, where various knowledge possessed by individual team members is stored and connected through the shared awareness about who-knows-what within the team (Wegner, 1987). Previous studies reported that TMS helps: (1) allocate knowledge responsibilities among the members, so that the group's cognitive resource is better utilized (Hollingshead, 1998a and Hollingshead, 1998b); (2) identify the location of knowledge within the group, thus the members have timely and accommodated access to the knowledge needed (Lewis, 2004); and (3) reasonably anticipate one another's knowledge needs and plan knowledge sharing behaviors accordingly (Moreland, 1999 and Moreland et al., 1996). Hence, TMS is a useful team cognitive mechanism that may explain the effectiveness of knowledge sharing in distributed team in general and OSS teams in specific. Several researchers suggested the working of such mechanism in their case studies of OSS projects (e.g., Gutwin et al., 2004 and Hemetsberger and Reinhardt, 2006). Therefore, we aim to fill the research gap by applying the perspective of TMS to explore knowledge sharing behaviors in a large number of OSS teams. The rest of the paper is organized as follows. We will first review the theory of TMS and develop the hypotheses. We will then describe the research methodology and present the results. At the end, we will discuss the theoretical and pragmatic implications of the findings, the limitations of the research, and suggest future research directions.

We explore the impacts of TMS on knowledge sharing and communication quality, which in turn are hypothesized to influence technical performance of OSS teams. Our findings provide implications for literature and practice, which are discussed below. 6.1. Discussion and contributions to literature Most of the prior research bundled the dimensions of TMS together and studied it as a single second-order construct, under the assumption that different TMS dimensions affect team behaviors in a homogenous fashion. However, we followed the recommendation from Kanawattanachai and Yoo (2007) and separately examined the dimensions. The results demonstrate that the “homogeneity” assumption is questionable, at least in the OSS setting. The four TMS dimensions exhibit very different modes in terms of impacts on team behaviors: knowledge differentiation has no impact on either communication quality or knowledge sharing. Knowledge location and the usage of the mailing list are positively related to communication quality. Knowledge credibility has positive impacts on both knowledge sharing and communication quality. The lack of impact of knowledge differentiation on either knowledge sharing or communication quality might be explained by the fact that many OSS projects include modularity within their software architectures (Osterloh & Rota, 2007). A modular project consists of several relatively independent components or modules (Narduzzo & Rossi, 2003). Interfaces between modules are well-defined, and thus coordination and integration among developers are reduced to the minimal level (Sanchez & Mahoney, 1996). von Krogh et al. (2003) reported that the majority of OSS developers tend to focus on one or two specific modules, that is, specializing in certain modules. The modularized software architecture therefore minimizes the need for communication and knowledge sharing between developers from different modules (Osterloh & Rota, 2007). This may be why the relationships between knowledge differentiation and communication quality and knowledge sharing are not statistically significant. Knowledge location and the usage of the mailing list do not directly affect knowledge sharing in OSS teams. Instead, these two dimensions might exert their influences indirectly through communication quality; that is, knowledge location and the usage of the mailing list promote quality communication between OSS developers, which, in turn, facilitates knowledge sharing. Knowledge credibility has positive impacts on both communication quality and knowledge sharing between OSS developers. This finding is consistent with the argument (Lewis, 2004 and Moreland, 1999) that trust among group members enables them to engage open communication and also reduces unnecessary communication overhead (e.g., justifying why information provided is accurate). In summary, the above results indicate that the impacts of the TMS dimensions on team behaviors can be indeed “heterogeneous,” and confirm the necessity of studying the TMS dimensions individually. Furthermore, the results demonstrate the plausibility of TMS in the OSS team context. Although several researchers suggested the working of TMS in OSS teams (e.g., Gutwin et al., 2004 and Hemetsberger and Reinhardt, 2006), their studies were qualitative and focused on one or two TMS dimensions. Our study provides a more comprehensive discussion about the TMS dimensions, which are supported with empirical data. Our study also shows that communication quality plays important roles in OSS teams because it has positive influences on knowledge sharing and technical performance of the team. These results are expected because the developers are geographically dispersed and communication channels are limited to asynchronous, text-based lean media. Timely communication can cultivate a sense of closeness (Moorman & Blakely, 1993), and focused, clearly articulated communication can reduce misunderstanding and enables the developers to make informed design decisions and amass necessary information to solve emerging task issues. Previous research reported that OSS developers take advantage of Internet tools to overcome challenges caused by geographic distance (e.g., Ciborra and Andreu, 2001 and Lanzara and Morner, 2004). Our study, on the other hand, suggests that improving communication quality might be another important means employed by OSS developers to countervail the virtualness. The most surprising result of our study is the absence of impact of knowledge sharing on technical performance of the team. Knowledge management literature generally agrees that effective knowledge sharing contributes to the performance of teams (e.g., Faraj and Sproull, 2000 and Kanawattanachai and Yoo, 2007). The inconsistent finding might be explained by the trade-off between cost and benefit associated with knowledge sharing in the context of OSS teams. When an OSS team consists of few experienced developers but many naive developers, knowledge sharing largely involves knowledge transfer from experienced developers to naive ones. The naive developers, as knowledge recipients, can benefit much from the activity, such as learning best practices and possible solutions for problems on hand. However, the experienced developers, as knowledge sources, incur the opportunity costs of the effort and time expended in sharing knowledge (Haas & Hansen, 2005). They could have spent time and effort on project development issues, such as, fixing a bug, devising a new feature, or coding a patch. Therefore, the team, as a whole, might not benefit from knowledge sharing if opportunity costs cancel out learning benefits. Even worse, the team might perform poorer if opportunity costs exceed learning benefits. 6.2. Contributions to practice Our study can offer practical suggestions to OSS project administrators in the following aspects. Project administrators can improve communication quality among developers by helping them become familiar with each other's expertise. This can be done by implementing a knowledge map or directory on the project website, indicating each member's areas of expertise. Organizations, such as IBM, have used such a directory in its internal knowledge portal, serving as a way to help knowledge workers familiarize themselves with their colleagues (Mack, Ravin, & Byrd, 2001). Another means of improving communication quality is to purposely promote the usage of the developer mailing list. Although there are alternative communication channels available, such as online chat room and private email, the public nature of the mailing list forces the developers reflect more carefully before posting. Project administrators should also attempt to raise the level of confidence that developers have in their team members’ expertise because it can facilitate knowledge sharing and contribute to communication quality. In addition, the results of this study have implications for organizations experimenting with the open source mode of software development. A number of commercial companies have been doing so. Examples include Microsoft's CodePlex, Sun Microsystems’ OpenOffice, and Google's Google code. This study suggests that the companies wishing to leverage OSS project teams should focus their resources on facilitating the TMS development within the teams, especially knowledge location, the usage of the developer mailing list, and knowledge credibility. This is because these dimensions are reported to have positive effects on communication quality, which, in turn, improves team performance. 6.3. Limitations and directions for future research Our study bears several limitations. First, we asked project administrators to assess their project teams’ TMS, knowledge sharing, and communication quality. This key informant approach is a common practice for studying team phenomenon (Sparrowe et al., 2001) and has been specifically recommended to study OSS teams (Stewart & Gosain, 2006). Since the majority of OSS projects in our sample were small and medium size teams, we believe that the administrators were able to develop fairly reliable impressions of their members’ behaviors or attitudes as they interacted intensively with each other on the project issues. However, there were also three large project teams with more than 68 developers. The evaluation of these teams by the administrators might not be as reliable as that of small and medium size teams. Therefore, future research might adopt alternative approaches, such as aggregation of individual assessments and group-level consensus (e.g., Fuller et al., 2007 and Hardin et al., 2006), to survey other team members rather than just project administrators and re-examine the research model proposed in this study. The results derived from different measurement approaches might then be compared and contrasted. Second, we used the number of postings in the developer mailing list to measure the usage of the list. This measurement reflects the quantity of the usage, but not the quality. This is because the postings vary in terms of length, relevance, and information intensity. Future research should develop additional measurement to tap the quality of the usage of the developer mailing list. Third, several prior studies (e.g., Faraj and Sproull, 2000 and Tiwana, 2004) have established a positive relationship between knowledge sharing and team performance. However, the results of this study show that knowledge sharing between OSS developers does not necessarily lead to improved team performance. This may partially be due to possible opportunity costs (Haas & Hansen, 2005). Therefore, future research should pay attention to the costs associated with knowledge sharing rather than just benefits. Fourth, we chose to adopt the perspective of TMS. However, there are other team cognitive mechanisms, which might promote knowledge sharing in virtual teams. For example, Steinfield, Jang, and Pfaff (1999) suggested the importance of team awareness (i.e., up-to-minute knowledge about what is happening in the team) in virtual collaboration. Espinosa, Slaughter, Kraut, and Herbsleb (2007) proposed that shared knowledge about task-work (i.e., activities necessary to carry out the task) and team-work (i.e., activities necessary to work with each other) might play influential roles in virtual teams. Future research should certainly explore these alternative theoretical perspectives. Lastly, our sample was exclusively drawn from two project categories on the Sourceforge website: Networking and Development, which limits the generalizability of the study's findings. Thus, another direction for future research is to replicate our study in other project categories of Sourceforge.