MSc BA – Change Management
Master's Thesis BA Change Management (EBM724A20) Course year: 2014-2015
Semester: 2 Title:
A revelatory case study of knowledge creation in an open-source software development context
Words: 128031
Supervisor: Dr. C. Reezigt
Associate Professor at the University of Groningen Innovation Management & Strategy
Faculty of Economics and Business
Author:
Alexander Lenke (s1982915) Mobile: +49 173 8240904 Mail: lenke@student.rug.nl
Abstract: In times of an ‘information society’ or even knowledge economy, open innovation, especially in terms of open source software (OSS) innovation has gained rising prominence across companies, but also academics. This stresses the importance of knowledge management, respectively knowledge creation in organizations. The current longitudinal study aimed to further close the (scientific) gap and create consensus about the ways OSS development projects utilize information technologies in order to manage knowledge creation by applying the ‘Dynamic Theory of Organizational Knowledge Creation’ (Nonaka and Takeuchi, 1995). Furthermore, the research aimed to study the contribution of developers and user regarding knowledge creation, the types of information technology utilized within this process and specifically in which way individuals in these teams build on past knowledge in order to create future knowledge and thereby ensure the self-referential potential of knowledge. The study analyzed these aspects in three different periods across three years. It revealed the frequency OSS teams utilize the four different knowledge creation modes developed by Nonaka and Takeuchi (1995), validated and enriched a content analysis schema to analyze knowledge creation in an OSS context and further elucidated the (facilitating) role of information technologies. Finally, a framework has been developed as a first attempt to systematically analyze self-referenced knowledge creation processes in open innovation, OSS projects.
Table of Content
1. Introduction ... 5
2. Literature Review ... 10
a. The Concept of Knowledge ... 10
b. Open Innovation ... 11
c. Open Source Software ... 12
d. Knowledge Creation ... 14
i. Socialization ... 15
ii. Externalization ... 16
iii. Combination ... 16
iv. Internalization ... 17
e. Open Innovation and Knowledge Creation in OSS Development Projects ... 19
f. Self-Reference in Knowledge Creation ... 21
3. Methodology ... 22
a. Data Collection Methods ... 23
b. Data Analysis ... 27
c. Operationalization of ‘Self-Reference’ in Knowledge Creation... 28
d. Validity and Reliability ... 28
4. Results ... 30
a. Knowledge creation modes ... 30
b. Self-referenced knowledge creation... 32
c. Information Technologies Used to Facilitate Knowledge Creation ... 36
d. Contribution ratio between users and developers ... 37
5. Discussion and Conclusion ... 38
a. Theoretical Contributions ... 38
b. Practical Contributions ... 45
c. Directions for Future Research ... 46
List of Figures and Tables:
Figure 1: The New Focus on “Knowledge” as a Competitive Resource ... 6
Figure 2: Depiction of knowledge conversion modes ... 14
Figure 3: Distribution of knowledge creation modes ... 31
Figure 4: Distribution of knowledge creation across period ... 32
Figure 5: Identified patterns of self-referenced knowledge creation ... 34
Figure 6: Distribution of utilized Information Technologies ... 37
Table 1: Content Analysis Schema (Adapted from Eseryel, 2014) ... 19
Table 2: Sample descriptive: Proportion of crucial events within overall sample ... 25
Table 3: Detailed depiction of sample and data collection compilation ... 26
Table 4: Description of information sources ... 27
Table 5: Identified Knowledge Creation Modes and Identified Frequency ... 30
Table 6: Self-referencd knowledge creation steps ... 33
Table 7: Example Application of Schema ... 36
Table 8: Contribution of developers and users ... 37
Table 9: Comparison of Results regarding identified Knowledge Creation Modes ... 39
1. Introduction
In times when even the world’s biggest companies, such as the South Korean industrial group Samsung (Pfanner and Chen, 2013), rely on Open Innovation Center as a means to systematically encourage and exploit knowledge sources to accelerate innovation (Chesbrough, 2003; Conboy and Morgan, 2011), the increasing importance of open innovation processes become undeniable. This process, in the form of OSS development, has been identified as an institutional alternative to firm-based innovation (Tuomi, 2003; Ulhoi, 2004).
Acknowledging the importance of knowledge in our society, the ’Organisation for Economic Co-operation and Development’ (OECD) states “knowledge is now recognised as the driver of productivity and economic growth, leading to a new focus on the role of information, technology and learning in economic performance” (OECD, 1996). Therefore, it becomes pivotal to raise questions about the processes organizations utilize to manage knowledge and knowledge creation.
Figure 1: The New Focus on “Knowledge” as a Competitive Resource (Nonaka and Takeuchi, 1995:6)
Knowledge management (KM) has become a crucial factor for organizations in order to sustain or even create a competitive advantage as depicted in Figure 1 (Argote and Ingram, 2000; Buckley and Carter, 2000; Davenport et al., 2003; Evermann, 2005; Friedman, 2002; Grant, 1996; Hackney et al., 2004; Salazar et al., 2004). Creating and transferring knowledge has been found to contribute to organizational performance across industries (Baum and Ingram, 1998; Darr, Argote, and Epple, 1995; Epple, Argote, and Murphy, 1996; Galbraith, 1990). However, KM is seldom a coherent, unified, continuous and holistic strategy, but often characterized by a variety of different projects and directives, which are partly time- or location-bound (Fischer and Roeben, 2004). In this sense, today’s organizations may profit from open innovation or more specifically from OSS development by an enormous stock of highly motivated and capable developers and by making use of code patches developed within these open source projects. Software companies may build new, commercial software on OSS (i.e. Google’s mobile operating system ‘Android’ is based on an open source code of the Android Open Source Project) and thereby gain profit from open source projects.
For change managers, the significance of open innovation processes become evident when taking an open system perspective. The Open Systems school views organizations as being composed of a number of interconnected sub-systems, which entails that any change in the system will have an impact on other parts of the system (Burnes, 2004; Scott, 1987). Open innovation, as a process based on purposively managed knowledge flows across organizational boundaries (Chesbrough and Bogers, 2014) does also apply an open system perspective in which organizations are highly interconnected within and across the organizational boundaries. Therefore, any organization following an open innovation strategy will inevitably increase the influence and dependence on the external environment. Thus, change managers need to take into consideration that open innovation processes and the associated knowledge management across organizational boundaries increases the interdependence between an organization and its environment which further elucidates the sensitivity of organizations to environmental pressures. Nevertheless, open innovation strategies and open business models provide a
promising, sustainable way to grow and develop a business by incorporating collective intelligence and relying on external parties to co-create products and services (Chesbrough, 2003:22-23) which also highlights the rising prominence of open innovation for change managers as a potential change destination.
From a scientific perspective, researchers in the field of organization, strategy and management have been exploring knowledge creation within organizations for years (Argote et al. 2003; Grandori and Kogut, 2002; Hinings and Leblebici, 2003; Nonaka et al. 2006; Spender and Grant, 1996; Swan and Scarbrough, 2001). However, the process of knowledge creation within open innovation projects has not yet been sufficiently addressed by researchers, as well as practitioners (Enkel, et al., 2009; McEvily et al., 2004). There exists little systematic evidence on what actually promotes the effectiveness of knowledge transfer, respectively creation (Levin, 2002) and current studies call for extended research on open innovation (Spaeth et al., 2010; Vanhaverbeke, Chesbrough and West, 2014). Only a limited number of studies focus on knowledge creation and transfer within teams and even less studies focus on virtual teams within the information systems (IS) context (Argote, 2012; Zellmer-Bruhn, 2003). Additionally, Spaeth et al. (2010:418) ask for the development of a validated coding schema to analyze knowledge creation in an OSS context.
Next, IT regularly fails to deliver the anticipated value (Gill, 1995; Robey et al., 2000), which further stresses the importance to understand the processes and means in which IT can support and enable knowledge creation (Alavi and Leidner, 2001). It illustrates the gap between theory and practice in the field of KM (De Long and Fahey, 2000; Grover and Davenport, 2001; McInerney, 2002). Scholars increasingly ask for an alignment between investments in knowledge and change management (Babcock, 2004; Goldsmith et al., 2004) and reinforce that effective knowledge management does not only entail the introduction of technology, but also organizational and behavioral change management as critical success factors in the implementation of information systems (Alavi and Leidner, 1999; Alavi and Joachimsthaler, 1992).
hardware, software, and telecommunication networks that people build and use to collect, create, and distribute useful data, typically in organizational settings” (Valacich, Schneider and Jessup, 2014:8) with the purpose “to get the right information to the right people at the right time in the right amount and in the right format” (Rainer and Cegielski, 2010:10). Creativity and innovation are both strongly connected to the innovative use of technology (Wang et al., 2013).
This mixed methods research (Brewer and Hunter, 1989) is based on a longitudinal, revelatory case study on a highly innovative OSS development team within the Apache Software Foundation (ASF). OSS projects provide a novel way of organization and thereby eye-opening opportunities to analyze knowledge creation in this extraordinary context (von Krogh and von Hippel, 2006:979) “innovation processes in OSS significantly deviate from predictions made by existing innovation theory” (s.a. Lee and Cole, 2003; Lin, 2003; Lanzara and Morner, 2003; von Hippel, 2005; von Krogh et al. 2005).
research is needed in order “to reveal how exactly tools and conditions for stabilizing knowledge creation have to be shaped in order to be able to deal with the complexities, subtleties, and difficulties of knowledge creation”. Especially in OSS projects, the ‘connectivity of knowledge’ - which describes the inherent potential of knowledge to be perceived and succeeded by other knowledge – may be an important condition for knowledge creation. Past research has focused on the practice of knowledge reuse (Argote, 2012; Langlois, 1999; Majchrzak, Cooper and Neece, 2004; Zander and Kogut, 1995), but not sufficiently addressed the self-referential character of knowledge creation in the sense of Luhmann’s (1990) systems theory. Additionally, previous studies did not fully consider the evolutionary character of knowledge, which also calls for additional research (Coombs and Hull, 1998; Galende and de la Fuente, 2003; Huysman, 2000).
In order to address the before-mentioned research problem and objectives, the following research questions have been developed and will be answered by an analysis of the knowledge creation processes of a highly innovative OSS development project.
1. How does the degree of innovativeness, in terms of knowledge creation, of an OSS development project evolve in the long term?
2. What is the role of participants in an OSS development project regarding the contribution in knowledge creation processes?
3. How does information technology influence the knowledge creation processes in an OSS development project?
4. How do innovative OSS development projects contribute to the continuity of the self-referential, evolutionary process of knowledge creation?
These questions touch four sources of ambiguity and contention in the literature of knowledge creation in an OSS development context. Clarifying them may help to reduce the conceptual haze surrounding the concepts and thereby making it more amenable to study and normative intervention.
will conclude by presenting its implications for research and practice, its limitations, and future research directions.
2. Literature Review
The chapter aims to present the latest research developments in the field of (open) innovation and knowledge creation to provide a theoretical basis for the research problem (Eisenhardt, 1989). Therefore, a literature review has been conducted enabling the researcher to identify, evaluate and interpret relevant studies in a field (Kitchenham et al., 2010) and removing the subjectivity of data collection by employing predefined selection criteria2 (Crossan and Apaydan, 2010).
a. The Concept of Knowledge
“Concepts take different forms depending on the epistemology they are based on” (Venzin, von Krogh, and Roos, 1998) and therefore it is important to investigate the epistemological roots of knowledge (Christensen and Bang, 2003) in order to explicate the theoretical underpinnings of this study. The three most important epistemological stances in the field of knowledge creation are (1) cognitivistic, (2) connectionistic, and (3) autopoietic (Venzin et al., 1998). (1) The cognitivistic lens interprets knowledge as a “fixed and representable entity (data) universally stored in computers, databases, archives, and manuals” (Venzin et al., 1998). Knowledge is like data, which can be easily shared between different (organizational) entities and specific characteristics of the sender, receiver, or the knowledge itself do not play a role in the creation, transfer or sharing. (2) The connectionistic lens interprets knowledge to be contextual and accounts for the “local differences between the rules and stocks of knowledge” (Kogut and Zander, 1992). Therefore, knowledge creation and transfer is inherently sophisticated due to the contextualized nature of knowledge, and due to different factors, such as the need for shared understandings, and the nature of “connections” through social interactions, ties, or networks (Joshi et al., 2007). (3) Finally, the autopoietic perspective originated in the concept of autopoiesis (i.e., self-production) and refers to the concepts of autonomy, unity, and co-evolution. Knowledge is interpreted as history-dependent and believed to develop in an autonomous manner (Venzin et al., 1998). This perspective does not view knowledge as an abstract concept and therefore, it is not shareable, but always created (Krogh and Ross, 1995;
Nonaka and Takeuchi, 1995). Researchers taking this lens refer to knowledge “conversion” and not knowledge “transfer”. In this lens different strategies or modes of knowledge creation can be utilized, such as socialization, externalization, internalization, and combination, as methods for the conversion (or re-creation) of one type of knowledge to another.
Nevertheless, Venzin et al. (1998) conclude that none of the three epistemological perspectives is inherently superior to the others, but a specific epistemological perspective may be better suited to study a particular phenomenon. Researchers need to position themselves within the “epistemological continuum” and make their epistemological assumptions explicit (Venzin et al., 1995). Therefore, in line with Nonaka and Takeuchi (1995), this study takes an autopoietic perspective in the way that knowledge is not transferred, but created and in order to achieve this creation, different modes of knowledge conversion can be utilized.
b. Open Innovation
Innovation is a critical driver of change (Cawsey et al., 2011), competitiveness (Kim et al., 1999; Lee, 2008; Lertpachin et al., 2013; Filipescu, 2009), a value-adding process (Jacobs and Brand, 2007) and according to management scholars, the capability to innovate is the most important determinant of firm performance (Mone et al., 1998). It has been defined as an idea, practice, behavior or artifact, which is perceived to be new by the adopting unit (Daft, 1978; Damanpour, 1991; Tushman and Nadler, 1986; Zaltman, Duncan and Holbek, 1973). Innovation is the process of commercialization of a creative idea (Garcia and Calantone, 2002; Im, Montoya and Workman, 2013) and requires a substantial degree of learning (Bodewes and de Jong, 2003). In this sense, creativity, as the construction of novel, fruitful, and suitable new ideas or solutions (Amabili, 1996), is a well-known factor promoting innovation, since it deals with the actual implementation of creative ideas (DiLiello and Houghton, 2006).
Open innovation is “a distributed innovation process based on purposively managed knowledge flows across organizational boundaries, using pecuniary and non-pecuniary mechanisms in line with the organization’s business model” (Chesbrough and Bogers, 2014). In this sense, ‘open’ can be further defined as “the number of different sources of external knowledge that each firm draws upon in its innovative activities” (Conboy and Morgan, 2011:537). Thus, the concept of open innovation regards innovation activities rather as an open system and not as “the traditional (20th century) vertically integrated model” (West, Salter, Vanhaverbeke and Chesbrough, 2014:805).
Importantly, Chesbrough (2006) differentiates between open innovation and open source methodologies for software development. Although these two concepts share the increasing reliance on external information sources to create value, they differ in regard that “open innovation explicitly incorporates the business model as the source of both value creation and value capture” (Chesbrough, 2006:2). With reference to the ASF, it becomes obvious that this foundation is not a commercial, but a non-profit corporation and therefore lacks the idea of ‘value capture’.
Prior IS studies have mostly focused on three different aspects of open innovation in the last decade. First, on the means to create and capture value from open innovation processes (i.e. Chen et al., 2012; Feller et al., 2011; Füller et al., 2009; and Han et al., 2012). Next, on the technological (i.e. Redondo et al., 2009; Roberts and Grover, 2012) and/or sociological aspects when utilizing open innovation processes (i.e. Arakji and Lang, 2007; Redondo et al., 2009 and Jarvenpaa and Majchrzak, 2010). Finally, on crowdsourcing as a specific form of open innovation. Although being closely connected to the concept of open innovation, crowdsourcing is still a distinct strategy to take advantage of the knowledge of a larger community (i.e. Di Gangi et al., 2010; Leimeister et al., 2009; Schlagwein and Bjorn-Andersen, 2014). However, in sum, it has become obvious that research on open innovation has been mostly limited to the firm-level (Vanhaverbeke, Chesbrough and West, 2014).
c. Open Source Software
of license under which it is made available” (von Hippel and von Krogh, 2003:210). In a commercial project only ‘insiders’ can obtain enough information in order to possibly modify or improve the source code (Meyer and Lopez, 1995; Young et al., 1996; Conner and Prahalad, 1996). In contrast, the source code of OSS is freely accessible and anyone with the “proper programming skills and motivations can use and modify any OSS written by anyone” (von Hippel and von Krogh, 2003:211). This policy facilitates knowledge creation, since it increases the number of potential contributors, who might engage in the project and share their expertise. Ordinarily, in an OSS project, a number of highly skilled programmers and users jointly develop a software by utilizing the Internet in a decentralized, highly interactive, knowledge-intensive process (Lanzara and Morner, 2005; Raymond and Young, 2001; Lee and Cole, 2003; Iannacci, 2002). This process represents a knowledge creation process which is characterized by a large number of volunteers, who rarely or never meet face-to-face (Haefliger and von Krogh, 2008; Morner and von Krogh, 2009).
d. Knowledge Creation
Knowledge cannot be managed in the classical sense, but knowledge creation needs to be ‘enabled’ (Adler, 2001; Alvesson and Kaerremann, 2001; Nonaka and Konno, 2005; Tsoukas and Vladimirou, 2001; von Krogh, 1998).
In this sense, Nonaka (1994) proposed the ‘Dynamic Theory of Organizational Knowledge Creation’ postulating that organizational knowledge is created through a continuous dialogue between tacit (implicit) and explicit knowledge, which is in line with our autopoietic epistemological assumptions. Tacit knowledge describes knowledge, which is difficult to formalize and communicate due to its personal quality, which means that tacit knowledge is “deeply rooted in action, commitment and involvement in a specific context” (Nonaka, 1994:16). Tacit knowledge ‘indwells’ in a comprehensive cognizance of the human mind and body (Polanyi, 1966). Explicit or codified knowledge describes knowledge, which can be transmitted in formal, systematic language (Polanyi, 1966).
The SECI-model (Nonaka, 1994) is based on the belief that individuals are “the prime movers in the process of organizational knowledge creation” (Nonaka, 1994:17). There are four different patterns of interaction creating knowledge through a conversion between tacit and explicit knowledge: (1) from tacit knowledge to tacit knowledge; (2) from explicit knowledge to explicit knowledge, (3) from tacit knowledge to explicit knowledge and finally, (4) from explicit knowledge to tacit knowledge. The following figure visualizes these interactions patterns:
and Takeuchi’s (1995) knowledge creation modes. In the following, the definition of the four different modes and the operationalization developed by Eseryel (2014) for the OSS context will be presented:
i. Socialization
The first mode of knowledge conversion enables an individual to convert tacit knowledge through (a series of) interaction(s). An example of tacit knowledge conversion entails ‘on-the-job-training’, whereby individuals gain (tacit) knowledge by experiencing specific situations. In these situations the mere communication of information would not be appropriate in order to convert knowledge, because one aspect of tacit knowledge relates to the ‘thinking process’ which cannot be easily transferred from one individual to another by communication, but rather entails a process of shared experience in which an individual gains the knowledge by experiencing the new situation. Therefore, this mode describes a process in which an individual’s tacit knowledge becomes the tacit knowledge of another individual through (i.e.) sharing experiences (Durcheneaut, 2005:327). It is characterized by the belief that tacit knowledge can even be acquired without explicit communication, solely by observing, imitating and practicing a specific behavior.
Eseryel (2014:24) states that this mode can be identified in the open source context when user participate “in an apprenticeship by reporting bugs and submitting patches to fix these bugs, and the developers testing, (when needed) correcting, and committing these user patches” (s.a. Durcheneaut, 2005). Although the developers and users do – usually - not physically meet in an OSS project, IT serves as a substitute of these face-to-face meetings by enabling them to inspect the changes, which are made by the developers (Durcheneaut, 2005:324). Thus, a user who is reading and classifying the content of the process documentations (i.e. emails or software source codes) based on his existing knowledge creates new tacit knowledge by interpreting this knowledge in the light of his past experience and expertise (Morner and von Krogh, 2009). However, this interpretation (i.e. transfer of tacit knowledge) requires the individual to become intellectually engaged in the process. Therefore, just reading messages or new codes is far from being sufficient. Instead, the reader or observer needs to actively make sense of the observed behavior by (i.e.) questioning the actions or changes taken by the other user. In this way, the observer does not only aim to understand the changes, but also keep track of the sense-making process of the other user.
process tacit knowledge conversion occurs, when individuals inspect the patch and thereby possibly gain additional knowledge by backtracing the thought process and the way in which the individual developed the code patch. Additionally, the individual gains knowledge by the feedback s/he receives from the developer (i.e. the developer publishes an improved patch, which the user inspects and tests again and thereby absorbs the tacit knowledge of the developer).
ii. Externalization
The ‘externalization’ mode describes the conversion of tacit knowledge into explicit knowledge (Nonaka, 1994), since formerly uncoded, personalized knowledge will be converted into explicit, coded knowledge during this process. In the context of OSS development, the process of externalization is manifested in the problem resolution process where “individuals share the inner workings of the software as inputs to other people’s decision making” (Eseryel, 2014:28). Conceptualizing a problem and/or a new idea is one of the most important knowledge creation processes in an OSS context (Hemetsberger and Reinhardt, 2006). In this sense, members explain, evaluate, correct, reject or defend an opinion and create a shared understanding, dialogue and collective actions by explicating tacit knowledge (Nonaka, 1994).
Externalization occurs when developers face problems, which they cannot resolve themselves and therefore ask for support of the community (Eseryel, 2014). Specifically, it results in three types of knowledge conversion: (1) an initial problem description including relevant information (i.e. how a specific algorithm works) which depicts the explication of tacit knowledge embedded in the software code to enable other developers to solve the problem. (2) By troubleshooting the issue and making specific suggestions, other developers share their tacit knowledge on how to solve the issue. (3) Finally, by justifying and explaining their suggestions, these developers explain the “logic and thought processes thereby explicating their knowledge further” (Eseryel, 2014:28). Thus, in sum, the externalization process serves participants and observers, since both learn from each other’s explicated knowledge and thereby improve their ability and knowledge about how to deal with (software) problems and the functioning of the software itself.
iii. Combination
knowledge system. In the OSS context, this mode of knowledge conversion is mainly accomplished in two ways: First, individuals may refer to external sources of knowledge (i.e. other threads). Second, “the developers close the loop on previous discussions on an issue or a patch by communicating how an issue is resolved, and how a patch is committed including the description of the changes in the patch” (Eseryel, 2014:30).
iv. Internalization
Internalization describes the conversion of explicit into tacit knowledge and shares similarities with the traditional concept of ‘learning’, since an individual internalizes knowledge by learning (i.e.) a specific task. Internalization may be accomplished through “learning by doing” (Nonaka, 1994). Documentation may also be a means to accomplish ‘internalization’ of knowledge, since it includes the process of verbalizing and/or diagramming knowledge into written form and “helps individuals internalize what they experienced, thus enriching their tacit knowledge” (Nonaka and Takeuchi, 1995:69). Therefore, documentation enables an individual to think about the obtained knowledge and thereby organize and structure the knowledge, which includes also the acknowledgement of a possible lack of comprehension. In the OSS development context, this documentation may be even more prevalent, since users, as well as developers write down their ‘thoughts’ or knowledge at several instances, i.e. when experimenting with their code. Thus, “documentation brings about a deeper level of engagement with the subject matter that enables meaning-making, hence, the creation of tacit knowledge in the minds of the documenters” (Eseryel, 2014:31). Four specific types of ‘internalization’ can be identified in the context of software development, namely: (1) Writing documentation; (2) developing tests for the software, which may be used to understand and test the software; (3) developing web pages and finally, (4) developing wiki-pages for the software development project.
The following table provides a summary of the four knowledge creation modes and the developed operationalization by Eseryel (2010):
Knowledge Creation Mode
Knowledge Creation Behavior
Description
Socialization Report bugs or improvement needs
(Tacit to Tacit) Submit patch Describes submission of patches (fixes to the software to improve the software functionality or a bug).
Commit patches Describes the (final) commitment of patches. Externalization (Tacit to Explicit) Contribute to problem resolution by providing information
Describes instances in which individuals provide information in order to help developers/users to solve a problem they encounter during the software development, fixes or use. The information typically helps the individual to troubleshoot or resolve his or her own issue (i.e. information about the function of a software, etc.).
Make suggestions and troubleshoot for the developers and users
Relates to instances in which users or developers make suggestions or support the users by troubleshooting the source of their problems.
Explain logic behind suggestions
Describes instances in which a person provides extended explanations to justify their suggestions. It does also includes instances in which individuals utilize examples in order to explain their suggestion.
Ask questions related to someone’s suggestion
This code entails situations where an individual evaluates or probes someone’s suggestion to ensure that the original suggestion has been well-conceived and all relevant aspects thoroughly thought through.
Mentor and guide others Describes situations in which a person mentors others by teaching them the rules and norms of working in the team and the organization. Additionally, it includes situations in which new users are directed into the right mailing list or other communication source.
Combination (Explicit to Explicit)
Communicate issue resolution
Refers to cases in which individuals communicate that an issue is resolved. This provides closure to the issue to those who may not have tracked the progress directly.
Communicate patch commit
Refer the users to other knowledge sources
Describes cases where the developers share project-based knowledge with users. They may refer the users to earlier discussions, project web page, wiki, or external resources about the project.
Sharing information and/or knowledge
This code describes instances in which developers or user share or provide information or knowledge by (i.e.) sharing test results.
Internalization (Explicit to Tacit)
Document changes This code refers to instances in which the software has been changed and these changes documented via (i.e.) change logs.
Write tests Describes instance where tests are documented. Develop web pages Describes the documentation of changes of a websit. Contribute to wiki Describes the documentation of changes in the WIKI. Rephrasing This codes describes situations in which developers or
users rephrase specific information, knowledge or questions in order to absorb and understand its meaning. Self-referenced
knowledge creation
Make extended suggestions and troubleshoot
for the developers and users
Describes instances in which users/developers build new knowledge based on former suggestions and thereby promote the connectivity of past and future knowledge
Table 1: Content Analysis Schema (Adapted from Eseryel, 2014)
e. Open Innovation and Knowledge Creation in Open Source
Software Development Projects
on the projects Internet website and thereby made freely available to interested party. Additionally, a means to communicate possible improvements will also be installed, often in the form of a mailing list (Yamauchi et al., 2000). Now, in an optimal case, developers, as well as users ‘play’ with the code by using, adding and/or customizing the code and thereby create new, modified patches. They publish this updated code and thereby present it for discussion and possible implementation into the original source code. Importantly, only a limited number of developers (often the project ‘owners’) have the privilege to make additions or changes to the original, authorized source code.
In OSS projects each developer is free to work on any particular aspect of the program s/he is interested in (Kuawabara, 2000). Normally, his/her skills, experience and interests determine this choice. No formal membership is required, and normally – although ‘project owners’ may select the developed code for the official releases and make it available for distribution – a formal hierarchy does not exist (Asklund and Bendix, 2002; Kogut and Metiu, 2001; McGowan, 2001; von Krogh and von Hippel, 2006). Leadership and/or project ownership is based on expertise, experience and reputation (von Krogh et al., 2003).
There are two major inter-group processes, namely, (1) providing criticism and (2) correcting errors (Eseryel, 2014; Kogut, 2000; Lee and Cole; 2003). Users and developers in OSS projects review codes submitted by other team members/users and criticize, respectively improve/correct the code when necessary. This is assumed to be one major foundation of knowledge creation and will be further outlined during the course of the thesis.
However, in the light of OSS, these costs are rather low, since the participant develops a code for himself or his own requirements and simply shares it with others via the projects Internet website. Thus, the first costs are already incurred and the costs for publishing the code are low. On the other hand, sharing an innovation may be beneficial for the participants since it likely improves reputation, causes appreciation and reciprocity across the community (Lerner and Triole, 2002; von Krogh, 2002). Thomas and Hunt (2004:90) further specified the motivation of developers when stating that “a combination of need, pride, ambition, or community” drives the developers and users to take part in such a project. Nevertheless, this distribution ensures the diffusion of the innovation, respectively software code “by what the economist calls knowledge externalities or spillover” (Baldwin and Hanel, 2003:9).
f. Self-Reference in Knowledge Creation
Knowledge developed through ‘self-reference’ describes a process in which “new knowledge refers to past knowledge and to potential future knowledge” (Morner and von Krogh, 2009:436; Luhmann, 1990). The process entails that – in case the data is relevant and the information understood - one user or developer builds on the knowledge in one mail by referring to it in a subsequent mail and, thereby, aligns itself meaningfully in the communication process according to its particular context. This process is highly dynamic because it is based on ongoing interaction, but also highly fragile and prone to breakdown, because the process of connecting ‘new’ knowledge to ‘old’ knowledge “may not continue naturally, and the probability of an abrupt end remains high” (Morner and von Krogh, 2009:436). In this sense, approximately 50 percent of emails remain unanswered in OSS development projects, which illustrates the fragile character of self-referential knowledge creation (Lanzara and Morner, 2005).
The ‘connectivity of knowledge’ has been identified as being one critical factor contributing to ongoing (self-referential) knowledge creation (Morner and von Krogh, 2009:437). This concept describes the inherent potential of knowledge to be perceived and succeeded by other knowledge (Morner and von Krogh, 2009:437). According to Luhmann (2000: 56), who analogously speaks of ‘communication connectivity’, the connectivity of communication is one of the prerequisites for the survival of the ‘system’.
OSS development project with a specific focus on the self-referenced knowledge creation in the following chapters.
3. Methodology
This chapter will introduce the methodological approach, sample and data analysis strategy. Finally, the chapter concludes by addressing the reliability and validity of the instruments and approaches chosen.
The study entails mixed methods research (Brewer and Hunter, 1989) encompassing a quantitative theory testing and a qualitative theory development part. The first part of the study aims to test the SECI-model (Nonaka, 1994) and the developed content analysis schema for knowledge creation in an OSS context (Eseryel, 2014), whereas the second part aims to develop theory about the contribution of different groups of participants, the value of technology for knowledge creation and most importantly how OSS projects create knowledge and ensure that the self-referenced process of knowledge creation will be maintained. The second (main) part of this study can be characterized as a longitudinal, revelatory case study (Eisenhardt, 1989; Yin, 2014). Recognizing the paucity of in-depth (field) studies on IT-enabled knowledge creation in OSS development projects the strategy of this study was to focus on one relatively unexplored case in depth. Therefore, a qualitative research approach has been determined as being most appropriate (Myers, 2009; Ozcan and Eisenhardt, 2009).
The methodological stance of the study can be characterized as being ‘interpretive’, since the study made use of text (i.e. messages) of members within the Lucene open innovation project reflecting the individuals behavior in dealing with questions and problems in the development process of the software in order to develop a second-order theoretical understanding of the phenomenon (Lee, 1991; Sarker et al., 2006; Walsham, 1995). These messages have been coded by content analysis, a process of making inferences based on objective coding of archival records. Steps for content analysis include identifying relevant sources of archival data, sampling data from these records, and ultimately coding the contents of the records. Coding in content analysis involves a classification of events and behaviors based on the archival records into clearly defined categories and recording the amount of time or words devoted to events and behaviors (Shaughnessy and Zechmeister, 1985).
higher-level categories, and finally to identify potential linkages between these categories (Charmaz, 2000; Gioia et al., 2013; Sarker and Sahay, 2003). The study took precautions to corroborate the interpretations made (Miles and Huberman, 1994; Yin, 2014). Implicitly, the study made use of constant comparative processes involving data triangulation across different data sources, respondents and their role within the development team (Eisenhardt, 1989; Flick, 2004; Patton, 1990). Once empirical patterns seemed to emerge, these patterns have been placed in the context of the existing literature (Bryant and Charmaz, 2007; Eisenhardt, 1989).
a. Data Collection Methods
Sample: In line with recommendations of methodologists, the study sought to identify an organization, which could be a unique and exemplary source of insights on the topic of knowledge creation in an open innovation context (Guba and Lincoln, 1994; Patton, 1990). Therefore, an OSS development team has been selected to collect data and was identified within the American non-profit Apache Software Foundation, which is a decentralized community of (software-) developers.
The practices of OSS developers, projects and communities are of interest to scientists, since, first, OSS projects present a novel and successful alternative to the conventional models of innovation in the way of how innovations should be developed and how organizations should be formed and operated (von Hippel and von Krogh; 2003:212). Apache OSS development projects represent ideal research cases because these projects are examples of surprisingly successful and innovative software development initiatives according to the US National Science Foundation (Ghosh, 2002). Second, “by the very nature of the way these projects operate, detailed and time-stamped logs of most interactions among community members and of project outputs are automatically generated” (von Hippel and von Krogh, 2003:212) which offers a number of opportunities for a detailed analysis into their inner working processes and procedures. Thus, OSS development projects produce almost automatically an extensive documentation of the development steps and this documentation is publicly available which makes OSS development projects valuable as research sites for many types of studies.
Apache Lucene: The selected highly successful and innovative software development project manages the development of the Apache Lucene software. Lucene is a high-performance, full-featured text search engine library written in Java. According to the developers, Lucene is a technology suitable for nearly any application that requires a full-text search, especially cross-platform. The Lucene developer team consists of 52 listed committers. The organization of the team is in general agreement with the findings of several empirical studies which have detected that, in the majority of cases, a small core group is responsible for the major proportion of the work accomplished and a very large group of ‘peripheral participants’ is responsible for the remainder (Ghosh and Prakash, 2000; Maas, 2004). This is also applicable in the selected Lucene-team, since (i.e.) in the first period out of 2420 total messages, the group of (core-) developers (11 member) contributed 1700 messages, which is around 70 percent of the total activity.
The ASF, respectively Apache Lucene has been selected for a variety of reasons: (1) Apache is known for successful OSS development, which is also displayed in a large and active community of developers and various project teams. (2) Related to the research question(s), the goal of the study is to analyze the processes and mechanisms taking place at OSS development teams in order to create knowledge, therefore it is standing to reason to select a highly interactive team which enables a researcher to observe the knowledge creating and exchanging processes. (3) Finally, the ASF provides extensive documentation of the communication and development stages, which have taken place during the project enabling a researcher to track and reconstruct knowledge creation during these phases. Specifically, the Lucene project has been described by members of the ASF as being one of the best-documented OSS development projects.
Data collection: The study has collected primary data in the form of archival data in order to observe and analyze the knowledge creation behavior within the Lucene project. Archival data comprise the records or documents of the activities of individuals, groups, institutions, and governments (Shaughnessy and Zechmeister, 1995).
In total three different periods over three years have been analyzed in order to answer the research questions. Periods just before major releases have been selected, since these periods have been deemed to be characterized by a high degree of innovativeness and activity. In each of these periods a total of (around) 240 cases have been identified from four different sources of information. Being (1) Developers’ mailing list, (2) Users’ mailing list, (3) an ‘Issue tracker’ and finally, (4) a ‘Software version control system’.
The following table briefly visualizes the distribution of the identified threads across the different periods and sources. Furthermore, the right part of the table shows the threads, which have been deemed to be crucial events having a high degree of urgency to be solved.
Threads Crucial Event Threads
1.Period 2.Period 3.Period 1.Period 2.Period 3.Period
Developers’ Email List 60 63 62 20 5 13
Users’ Email List 60 60 60 7 6 4
JIRA 74 61 67 32 19 19
SVN 68 62 60 9 10 8
Total 262 246 249 68 39 41
Table 2: Sample descriptive: Proportion of crucial events within overall sample
Developers’ Email List Users’ Email List JIRA SVN Total 1.Period (15.05.09 – 04.11.09)
60 Threads 60 Threads 74 Threads 68 Threads 262 Threads 549 Messages 371 Messages 1439 Messages 61 Messages 2420 Messages 5493 (8004) Quotes 401 (673) Quotes 903 (1198) Quotes 111 (111) Quotes 1964 (2782) Quotes 2.Period (23.08.08 – 20.10.08)
63 Threads 60 Threads 61 Threads 62 Threads 246 Threads 349 Messages 300 Messages 763 Messages 60 Messages 1472 Messages 503 (586) Quotes 360 (504) Quotes 577 (714) Quotes 101 (101) Quotes 1541 (1905) Quotes 3.Period (04.06.07 – 29.06.07)
62 Threads 60 Threads 67 Threads 60 Threads 249 Threads 386 Messages 251 Messages 540 Messages 60 Messages 1237 Messages 523 (433) Quotes 279 (638) Quotes 487 (623) Quotes 93 (93) Quotes 1382 (1787) Quotes Table 3: Detailed depiction of sample and data collection compilation The following table describes the four different knowledge sources:
Information source:
Description:
Developers’ mailing list
This is the list where the participating developers of the Java Lucene project meet and discuss issues concerning (i.e.) Lucene internals, code changes/additions, etc. Beside discussions related to development issues, this list does also include general strategic discussions, which might affect the project.
Users’ mailing list
This list is for users of Java Lucene to ask (technical) questions, share knowledge, and discuss issues. This list enables users to communicate with developers, but also other users. It may also serve as a source for new ideas, code patches and to report (possible) bugs.
‘Issue tracker’ (JIRA)
JIRA is an issue track system, which basically aims to track software bugs and improvement plans. It is the main communication channel for developers with a specific relation to an issue. The system captures the following information: (1) The name and type of issue5 (i.e. bug, improvement, new feature, sub-task, task, test, wish), the priority6 (i.e.
blocker, critical, major, minor, trivial), a description of the issue, attachments (i.e. the patch itself), the documentation of activities (i.e. log of communication and changes), the people affected (i.e. reporter and assignee), the date of creation, update and resolution, a general status information (i.e. open, in progress, reopened, resolved, closed) and finally details about the affected version, components and labels.
‘Software
version control system’ (SVN)
This is an automated announcement only list where notifications about every Lucene commit are sent. This system tracks team members’ code contribution(s) and enables the members to clearly monitor any software code changes. Only a limited number of authorized developers are licensed to make commitments.
Table 4: Description of information sources
b. Data Analysis
The data was analyzed within the threads by means of deductive and inductive coding. First, based on the literature review and the pre-developed content analysis schema by Eseryel (2014:23) main deductive categories were set. Within these categories, in addition to the already developed codes, inductive codes were explored. In case a new code emerged, the previous threads were reconsidered to identify possible instances of the new code. After having coded one source of information (i.e. mailing list) and after each period, the assigned codes were explored and explained across the cases (i.e. cross-analysis (Yin, 2014)) to ensure a consistent application of the coding schema across knowledge source and period (Eisenhardt, 1989). The self-referenced knowledge creation framework has been developed by qualitatively analyzing the identified instances of self-referenced knowledge creation with a focus on (unique) reoccurring patterns of knowledge creation. In case new patterns emerged which add to the theory, additional 5 threads from the mailing lists and JIRA have been added and analyzed
5 A bug describes a problem which impairs or prevents the function of the software; an improvement relates to an enhancement of an existing feature or task. The other issue types are assumed to be self-explanatory.
until it was determined that theoretical saturation has been reached, since new threads did not contribute additional value to the framework (Eisenhardt, 1989). We analyzed the data through an inductive approach, moving from first-order to second-order analysis (Gioia, 2013). The first-order analysis had a clear focus on the data and emerging categories, whereas the second-order analysis moved towards a more theoretical level in second-order develop an explanatory framework allowing to answer the original research questions. Finally, the framework has been compared with existing literature in order to further validate its conclusions and identify differences.
c. Operationalization of ‘Self-Reference’ in Knowledge Creation
According to Luhmann’s theory of social systems (1990) the process of self-reference is based on permanently (re-) producing knowledge through interactive and situational knowledge creation processes. This creation involves a self-referential process in which newly created knowledge builds on existing knowledge (Morner and von Krogh, 2009: 432). Social systems may not exist without the before-defined autopoiesis, since they can only uphold themselves through interaction with their own state over time (Luhmann, 1990). In the case of OSS projects, e-mails and source codes represent a ‘priori data’ which may be eventually transformed into information if it gains relevance for the consuming individual (Morner and von Krogh, 2009). Only when information is ultimately integrated into a (fitting) context, it becomes knowledge (Willke, 2005:82). In case of OSS projects “self-reference in knowledge creation becomes evident in particular in programmers’ discussions on software development in the developers’ mailing lists” (Morner and von Krogh, 2009:432). In instances when the data is relevant and understood in a sense-making process, an individual may build on the knowledge of one mail in a subsequent mail and, thus, “aligns itself meaningfully in the communication process according to its particular context” (Morner and von Krogh, 2009:432). In case this process fails, the knowledge creation process is deemed to fail as well. Therefore, this study will operationalize this process by identifying instances in the archival data in which individuals make extended suggestions based on the knowledge of previous suggestions.d. Validity and Reliability
First, the study utilized a rather large sample of 759 threads, respectively (n=) 5129 messages in order to answer the presented research questions. Secondly, the study analyzed three different periods in a time frame of three years in order to uncover recurring patterns of participation. Thirdly, the study made use of a pre-developed content analysis schema, which has been deemed to be reliable by other researchers (Eseryel, 2014). This strategy aimed to not only increase the statistical credibility of the findings, but also to ensure that the findings of this study can be compared with prior studies.
Validity. Construct validity is the “degree to which a test measures what it claims to measure” (Brown, 1996). Although validity has earlier been separated into three different types, namely construct, content and criterion validity, the modern validity theory primarily deems construct validity to be of major concern and concludes that construct validity subsumes all of the three types. Nevertheless, due to its’ explorative nature, there were no conclusions drawn in the beginning of this study, which means that there are no serious concerns about construct validity. Furthermore, in line with Yin (2014) the study aimed to establish a chain of evidence (i.e. extensive documentation of all conducted research steps) to exhibit construct validity. Additionally, since the study does not aim to explain causal relationship, internal validity is also of no concern to this study due to its explorative nature (Yin, 2014). However, since the case has been selected on specific criteria and only one specific case has been explored, the results of this study have a limited generalizability (external validity), which is a common weakness of explorative studies (Eisenhardt, 1989).
4. Results
This section will provide the findings regarding the identified knowledge creation behaviors and self-referenced knowledge creation instances. Finally, the chapter will outline the usage frequency of the communication technologies and the contribution ratio between users and developers.
a. Knowledge creation modes
Overall, the coding process resulted in 5089 identified instances of knowledge creation behaviors in 5.129 messages, respectively 757 different threads. In line with the adapted coding schema, eighteen different types of knowledge creation behaviors have been identified and assigned to either one of the four different modes or to the process of self-referenced knowledge creation. The following table summarizes the main findings and presents the frequency (per period) in absolute and relative terms7:
Knowledge Creation Mode Frequency of Observation in the Archival Data
Frequency of All Observations
Period 1 Period 2 Period 3
Socialization 49% (410) 27% (225) 24% (206) 17% (841) Externalization 37% (1028) 33% (925) 30% (814) 57% (2767) Combination 40% (437) 32% (342) 28% (298) 22% (1077) Internalization 34% (69) 35% (71) 31% (62) 4% (202) Total 40% (1944) 32% (1563) 28% (1380) 100% (4887) Self-referenced knowledge creation 50% (102) 26% (52) 24% (48) 100% (202) Total 2046 1615 1428 5089
Table 5: Identified Knowledge Creation Modes and Identified Frequency
Comparison across modes: Externalization was the most frequently identified knowledge creation behavior (57%) and has mainly occurred through instances in which individuals have provided information (i.e. 1521 instances have been identified (accumulated) in all three periods) or made suggestions or provided (potential) solutions to a ‘problem’ (i.e. 748 instances in all three periods). Furthermore, the explanation of suggestions (247 instances in all three periods), the probing of suggestions
(177), instances of mentoring, and guiding (40) have been assigned to this mode. The second most frequently identified knowledge creation behavior is ‘combination’ (22%) describing instances in which participants have forwarded other individuals to knowledge sources, such as websites or a wiki (496 instances) or participants directly share information or knowledge (177). This may take the form of sharing test results or providing information about copyright policies or issues. Furthermore, it also included the communication that an issue at hand has been resolved (46) or a patch has been committed (152). The third most frequently identified knowledge creation mode is ‘socialization’ (17%), including instances in which participants submit patches (537), report bugs (183) or commit patches (121). Finally, the least frequently identified behavior ‘internalization’ (4%) has only been detected in a relatively small amount of cases (202). It includes instances in which individuals document their efforts, by recording changes in the software code (108), contributing to the wiki by writing guidelines (45) or developing web pages (28) or tests (5). Finally, internalization does also describe instances in which participants try to internalize information/knowledge by rephrasing (16) it in their own language and thereby making sense of it.
17% 57% 22% 4% Socialization Externalization Combination Internalization
Comparison across periods: The first period is characterized by the most identified knowledge creation behaviors (40%). The frequency of knowledge creation in the second (32%) and third (28%) period is almost on the same level. Interestingly, in line with Table 5, the distribution of the modes ‘combination’ and ‘externalization’ virtually matches the overall distribution, whereas the modes ‘internalization’ and ‘socialization’ deviate from the overall distribution up to 9% in the case of
socialization in the first period (i.e. overall frequency 40%, specific frequency in the first period 49%).
b. Self-referenced knowledge creation
Around 50% of the instances of self-referenced knowledge creation have been identified in the first period, whereas 26% of the instances have occurred in the second period and 24% in the third. In a second qualitative process-based step, reoccurring patterns of self-referenced knowledge creation within the identified instances have been analyzed (Gioia, 2013). This analysis resulted in the detection of different knowledge creation paths, which can be assigned to four structuring steps in the problem-solving process:
Step: Description:
(1) Initial problem definition:
Entails the description of a problem/bug or the formulation of a question regarding a specific issue. Beside the problem definition and/or question, it may also entail background information, such as test results or information, which enable other individuals to backtrace or reconstruct the issue.
(2) First problem-solving attempt:
Builds on the problem definition and provides a first suggestion/solution for the presented issue. This may take the form of specific solutions (i.e. patch), a reference to a potential knowledge source (i.e. JIRA issue, WIKI, etc.) or the provision of information regarding a potential thematic area which addresses the problem/question. Importantly this step may also include
1. Period; 40% 2. Period; 32% 3. Period; 28%
various parallel suggestions, which are either slightly related or even based on each other or not related at all (i.e. when two respondents reply at the almost same time).
(3) Evaluation Individuals, most often the one who has initially described the issue, evaluate the first problem-solving attempt. In case the provided suggestion solves the issue, this may just take the form of appreciation. However, in case the problem/question has not sufficiently been solved, it may take the form of providing further information or an explanation why the provided suggestion does not solve the problem/question.
(4) Extended problem-solving attempt:
Although the first problem-solving attempt may already have solved the issue, an extended attempt may aim to provide a more efficient suggestion. Likewise, in case the first problem-solving attempt has failed, the second attempt may build on the information provided by the author during the evaluation of the first suggestion and offer a second problem-solving attempt, which builds on the additional information and/or even the first attempt.
Table 6: Self-referencd knowledge creation steps
These four steps may be ‘interrupted’ or complemented by the provision of further information contributing to the problem-solving process. Additionally, these four steps may also be repeated several times (circular character) and (i.e.) after an initial evaluation of a first problem-solving attempt the process may return to a new, additional problem definition.
another patch which might more efficiently solve the issue), externalization (i.e. an (extended) suggestion), or combination (i.e. sharing information).
The following figure visualizes the overall patterns of knowledge creation in an OSS context. Specifically, the last step – the extended problems-solving attempt – relates to self-referenced knowledge creation, since this step is particularly based on previous knowledge by extending the knowledge base (i.e. offering a more efficient solution) or even providing a completely different second-problem solving attempt (i.e. in case the first problem-solving attempt failed):
Figure 5: Identified patterns of self-referenced knowledge creation
Furthermore, the following table presents an example application of this schema with quotes derived from instances identified in the Lucene OSS project to validate the presented schema:
Problem-solving process: Example:
1) Problem Definition
Problem “When building a CFS file, and also when
merging stored fields (and term vectors), we copy large blocks of bytes at once. We currently do this with an intermediate buffer.”
2) First
problem-Specific solution “But, nio.transferTo should be somewhat faster
solving attempt
“Attached patch. All tests pass.”
3) Evaluation Negative “… but, I don't think we should commit this. I ran
performance tests across several platforms. All times are best of 3 runs, indexing first 200K docs of Wikipedia. I used SerialMergeScheduler for these tests so I could more easily measure the impact on merging as well:”
“Bottom line is: FileChannel.transferTo is not always a win, and, can be a catastrophic loss.”
4) Extended problem-solving attempt Second problem-solving attempt
“Maybe we should commit this, but, leave the default copy method using intermediate buffer?
The patch adds set/getCopyMethod to
FSDirectory”
5) Evaluation Negative (User 1)
“Btw, the windows results are pretty... strange. […]”
Positive (User 2) "Isn't this still a nice little optimization for
compound copies? When not using Win server, its faster in general, and even when similar, you get the less CPU usage optimization.
At worst it seems we should enable for that case when detecting non windows?"
6) Extended problem-solving attempt Third problem-solving attempt
“We could even throw in a couple specific Windows versions we know work well”
7) Evaluation Positive (User 1) “The XP results I got were fantastic, and the ones
Mike got were not bad. Prob not necessary, as most deployments will prob be on server, but future versions might be better.”
Negative (User 2)
the win, but it performs nasty after other java io operations. Bummer.”
Table 7: Example Application of Schema
It becomes obvious that the process of self-referenced knowledge creation is not limited to the presented four steps, but may – as already indicated before - even repeat itself (i.e. in case the various problem-solving attempts do not provide a sufficient solution). Additionally, the different steps are not bound to specific messages or users, but one message might not only include a problem definition, but also a first specific solution and sometimes even an evaluation of this first specific solution. Furthermore, just like the presented example illustrates, different participants might evaluate a problem-solving attempt differently and participants might even provide problem-solving attempts parallel without building on each other’s knowledge and therefore neglecting the potential of self-referenced knowledge creation. Finally, these four different steps, or phases of self-referenced knowledge creation behaviors might be supported by an additional provision of information (i.e. test results) or questions regarding (i.e.) clarification. Further applications of the schema can be found in Appendix F.
c. Information Technologies Used to Facilitate Knowledge
Creation
The following paragraph aims to outline the distribution in regard of the technology utilized in the knowledge creation process. The knowledge creation in SVN occurs rather stable and evenly distributed across the three periods in a range from six percent in the first period to seven percent in the second and third period. A similar even distribution can be observed regarding the knowledge creation instances on the users’ mailing list. In the first and third period, a fifth (20%) of the knowledge creation instances took place on this list. In the second period, only a slightly larger proportion (23%) occurred on this mailing list.
However, regarding the knowledge creation in JIRA, it has been detected that this system accounted for almost half (46%) of the knowledge creation behavior in the first period. In the third period, JIRA accounted for almost a third (35%) and in the second only slightly more (37%). In line with Figure 6, across all three periods JIRA has been utilized most frequently to create knowledge (39%). The developers’ list was used in almost every third instance, an the users’ list in every fifth instance.
SVN has only been used in 7% of all instances to create knowledge. Appendix C provides a detailed tabulation of the relative frequencies of knowledge creation modes per period and technology.
d. Contribution ratio between user and developer
The following table compares the contribution rates between user and developer per period and per knowledge source:
Period Users’ List Developers’ List
JIRA SVN Total
Dev User Dev User Dev User Dev User Dev User
1. 31.6% 68.4% 71.4% 28.6% 82.1% 17.9% 97% 3% 71.4% 28.6% 2. 33.4% 66.6% 58% 42% 56.6% 43.4% 91.9% 8.1% 53.8% 46.1% 3. 33.3% 66.7% 70.9% 29.1% 80.3% 19.7% 68.3% 31.7% 68% 32% Total 32.6% 67.4% 67.6% 32.4% 75.1% 24.9% 86.2% 13.8% 64.4% 35.6%
Table 8: Contribution of developers and users
Comparing the distribution of user and developer contribution across the three periods and sources a relatively high degree of stability can be identified. However, the second period seems to be an outlier in regard to the contribution on the developers’ mailing list and JIRA. Whereas in the first and third period, the developers contributed the majority of messages on these sources (around 70%), in the second period the distribution between the contribution of
Dev' list; 33% Users' list; 21% JIRA; 39% SVN; 7%
developers and users seems to be more balanced (i.e. only around 57% of the messages have been composed by developers). Another striking result can be detected in the third period on SVN. Whereas in the first two periods, almost all messages have been contributed by the developers, in the third period only around seven out of ten messages have been written by developers.
In total, the contribution of developers’ in the first period accounts for 71.4% (accordingly the users contributed in this period the remaining messages, which results in 28.6%), in the second for 53.8% and in the third for 68%. Accumulated it results in an overall ratio of 64.4% of messages contributed by developers and 35.6% by users in all three periods.
Regarding the overall contribution on the different sources, it becomes obvious that users are the main contributors on the users’ mailing list (67%), whereas on the other sources the developers contribute the majority of messages (i.e. around 68% on the developers’ mailing list, 75% on JIRA and 86% on SVN).
5. Discussion and Conclusion
This chapter will interpret the findings of the study and discuss its relevance in light of extant literature and the research questions. Furthermore, theoretical and managerial implications, directions for future research and the limitations of the current study will be presented.
