Master Thesis
The influence of social network structure on the chance of success of Open Source software project communities
Name Bart Vreugdenhil
Email [email protected]
University RSM Erasmus University, Rotterdam, the Netherlands MSc Program Business Information Management,
Business Administration
Coach Drs. R. Smit
Department of Decision and Information Sciences Co-reader Prof.dr.ir. J. Dul
Department of Management of Technology and Innovation
Version 1.01 Final - March 31, 2009
2 Preface
The author declares that the text and work presented in this Master thesis is original and that no other sources than those mentioned in the text and its references have been used in creating the Master thesis.
The copyright of the Master thesis rests with the author. The author is responsible for its contents. RSM Erasmus University is only responsible for the educational coaching and beyond that cannot be held responsible for the content.
3 Acknowledgments
Hereby, I wish to thank, in random order, all people who in one way or another supported and guided me through my Master Thesis research project.
First, I want to thank David Hinds, and his Major Professor Ronald M. Lee, for the inspiring dissertation which I used as a guideline for conducting research and writing my Thesis. Their work provided me with a stable fundament necessary to fulfill my research project. I want to thank them as well for answering several questions I proposed during this project.
Next, I want to thank the University of the Notre Dame and all the people working on the SourceForge Research Data Archive. Especially, I want to thank Greg Madey who permitted me access to these vast Open Source databases.
Thirdly, I would like to thank all the scientists I have referred to in my Thesis. I literally spent hours and hours reading and studying these sources. They supported me with well-funded theories and useful insights.
Fourthly, I am very grateful to my Master Thesis coach Ruud Smit and my co-reader Jan Dul who coached and guided me during my Thesis project. Without their endless supports and thoughts I could not have successfully completed the final phase of my Master degree project.
I thank all professors and employees of the RSM Erasmus University Rotterdam of the last few years for their education and support activities.
Finally, I am grateful to my parents, my family and my close friends. Without their support, and their love, I would not be able to complete this project.
4 Executive summary
The internet technology have caused a huge impact on the way people can communicate and exchange information. New forms of collective action and collaboration have arisen. One of these new forms is the development and organization of Open Source software. Open Source software is software which is freely redistributable and can be adapted to individual needs. Businesses, institutions and individuals all have recognized the potential of Open Source software, and each type of people may contribute to these projects for various reasons.
Not much is known about the conditions which lead to success of Open Source software projects (OSSPs). Current research is of exploratory or descriptive nature and generally has focused on large projects. However, it appears most Open Source software is created by individuals and small teams.
Here, an attempt is done to find out why some Open Source projects succeed while others fail. As the internet technology provides the infrastructure for project members to connect with each other, here is focused on the (pattern of) interactions between the individuals of a project community. Based on social network theory three constructs representing this community structure of Open Source software projects is investigated by using social network analysis. Closure represents the density of the relationships in a project community, bridging represents the degree of relationships of a community to other communities, and centrality of the project takes the effect of project leaders on the community into account.
Surprisingly, the social network structure of an Open Source software project community has no significant relationship with community success. Therefore, various factors are proposed which may both affect success and the structural properties of Open Source software projects. Closure and success of an Open Source project community may be affected by the choice of software design, the use of software documentation and the existing etiquette, called netiquette. Bridging and success may be affected by the set of marketing activities and stakeholder management, where centrality and success may be affected by the adoption of accepted standards and tools, the very own Open Source culture including skilled developers and the fact these developers are often users of their software as well.
Due to the exploratory and limited research scope it is plausible a measuring problem exists, which implies Open Source project communities may use substitutes to communicate and exchange information and knowledge. Or, the relationships between project members are of indirect nature and therefore information and knowledge are (temporary) stored, 'embedded', in the network, thus are difficult to measure.
5 Four main conclusions can be drawn based on the unexpected research findings. First, although here the social network structure of an Open Source software project community has no significant relationship with community success, it does not necessarily mean it is not of importance. Apparently, social network analysis cannot solely explain factors affecting the chance on success of an OSSP community. Though, relationships between OSSP members are important, the individuals (and their characteristics) establishing these relationships need to be taken into account as well.
Secondly, the Open Source software project community is a new kind of social entity, because current theory of virtual communities and traditional teams and groups creating information and knowledge products cannot explain the exceptional performance levels OSSPs can achieve. Here, the premature theory of smart business networks is presented as linking-pin to further explore these kind of social entities.
Thirdly, although a premature theory is supplied to further describe the Open Source phenomenon, it cannot explain the difference in research findings between large and small OSSP communities. Here, an attempt is done to explain this difference. Where small OSSP communities can be conceived of as operating similar to traditional groups and teams, though their mode of communication is electronic, large OSSP communities can be conceived of as virtual communities. However, it is also generally noted large OSSP communities have onion-like structures including a core of developers and are surrounded by a crowd of interested people. Thus, the difference between small and large OSSP communities is this crowd. Apparently, large OSSP communities are able to deal with this crowd, without the disadvantages related to the management and organization of (growth of) traditional teams and groups. By using the 'Long Tail', a popular description of the impact of the internet's infrastructure and technology on business models, is tried to explain the difference in the basic principles of small and large OSSPs. Where large OSSPs, due to their popularity, are positioned in the hit market and are generally focused on community outcome by trying to optimally incorporate the 'wisdom of the crowds-effect' to improve their software product, small OSSPs operate in niche markets and are generally focused on individual outcome.
Lastly, although researchers have not reached consensus on how to measure success of OSSP communities, here is concluded the current set of indicators for measuring the success of OSSP communities are focused on the hit markets in which large OSSPs operate, and are not suitable for the endless variety of niche markets in which small OSSPs. A new approach is needed, in which success factors for hit markets may be focused on the level of community success, and success factors for niche markets may be focused on the level of individual success of project members.
6 Table of contents 1. INTRODUCTION ... 10 1.1. RESEARCH APPROACH ... 11 1.2. RESEARCH QUESTION ... 12 1.3. DEFINITIONS ... 13
1.4. MASTER THESIS STRUCTURE ... 14
2. LITERATURE ... 16
2.1. SOCIAL NETWORKS ... 16
2.1.1. New media and the network model ... 16
2.1.2. Social network analysis ... 17
2.1.3. Social network theory ... 18
2.1.4. Social capital theory ... 18
2.2. OPEN SOURCE SOFTWARE ... 19
2.2.1. Open Source as a form of software distribution ... 19
2.2.2. Open Source software project contributors ... 20
2.2.3. Open Source Software project communities ... 20
2.2.4. The organization of Open Source software projects ... 21
2.2.5. Success studies ... 22
2.2.6. Social network perspectives ... 23
2.3. GROUP PROCESSES AND WORK TEAMS ... 24
2.3.1. Organization of groups and work teams ... 24
2.3.2. Teams ... 25
2.3.3. Virtual teams ... 26
2.3.4. Success of groups and teams ... 26
2.3.5. Social network perspectives ... 26
2.4. VIRTUAL COMMUNITIES ... 27
2.4.1. Success of virtual communities ... 28
2.4.2. Social network perspectives ... 28
3. CONCEPTUAL MODEL AND PROPOSITIONS ... 29
3.1. CONCEPTUAL MODEL ... 29 3.2. RESEARCH CONSTRUCTS ... 31 3.2.1. Subgroups ... 32 3.2.2. Closure ... 33 3.2.3. Bridging ... 35 3.2.4. Leader Centrality ... 36 3.2.5. Constructs overview ... 36
3.3. SOCIAL NETWORK MODEL AND PROPOSITIONS ... 37
3.3.1. Group closure ... 37
3.3.2. Core closure ... 38
3.3.3. Peripheral two-mode closure ... 38
3.3.4. Core bridging ... 38 3.3.5. Administrator bridging ... 39 3.3.6. Administrator centrality ... 39 4. RESEARCH METHODOLOGY ... 40 4.1. STUDY DESIGN ... 40 4.1.1. Unit of analysis ... 40 4.1.2. Study population ... 40 4.1.3. Research method ... 40 4.2. RESEARCH SETTING ... 41 4.2.1. Data sources ... 41 4.3. VARIABLES ... 43
4.3.1. Dependent and control variables ... 43
7
4.3.3. Controls ... 45
4.3.4. Social network definitions ... 46
4.3.5. Subgroups ... 47
4.3.6. Social network variables ... 47
4.4. SOURCEFORGE.NET POPULATION ... 49
4.5. SOURCEFORGE.NET SAMPLE STRATEGY ... 51
4.5.1. SourceForge sample selection procedure ... 52
4.5.2. Overview of sample selection criteria ... 54
4.5.3. Data compilation ... 54
5. DATA ANALYSIS AND RESULTS ... 55
5.1. FINDINGS OF KRISHNAMURTHY ... 55
5.2. PRELIMINARY ANALYSES ... 58
5.2.1. Transformation of variables ... 58
5.2.2. Outlier assessment ... 61
5.2.3. Reduction of variables ... 61
5.3. DESCRIPTIVE AND CORRELATION STATISTICS ... 63
5.4. HYPOTHESES TESTING ... 65 5.4.1. Research hypotheses ... 65 5.4.2. Regression methods ... 66 5.5. TESTING RESULTS ... 67 5.5.1. Group Density ... 67 5.5.2. Core Density ... 68
5.5.3. Peripheral Two-Mode Density ... 68
5.5.4. Core Membership Degree ... 69
5.5.5. Administrator Membership Degree ... 69
5.5.6. Administrator Class Centrality ... 70
5.5.7. Project Rank ... 70 6. DISCUSSION ... 72 6.1. SUMMARY OF FINDINGS ... 72 6.1.1. Closure ... 72 6.1.2. Bridging ... 74 6.1.3. Leader Centrality ... 75 6.1.4. Project Rank ... 76 6.1.5. Abstract of findings ... 76 6.2. SUGGESTIONS ... 77
6.3. THE POSSIBILITY OF A MEASURING PROBLEM ... 85
7. CONCLUSIONS ... 87 7.1. RESEARCH CONCLUSIONS ... 87 7.2. STRATEGIC CONCLUSIONS ... 94 7.3. LIMITATIONS ... 96 7.4. RESEARCH FLAWS ... 97 7.5. RECOMMENDATIONS ... 98 8. REFERENCES ... 100 8.1. LITERATURE REFERENCES ... 100 8.2. TEXTUAL ANNOTATIONS ... 107 8.3. LIST OF FIGURES ... 107 8.4. TABLES ... 108 9. APPENDICES ... 109
8 THIS PAGE INTENTIONALLY LEFT BLANK
9 Master Thesis
The influence of social network structure on the chance of success of Open Source software project communities
10 1. Introduction
Technology and the ubiquity of the internet have caused a huge impact on the way people can communicate and exchange information. The internet has reduced the high transactions costs connected with traditional communication, transportation and organization to a bare minimum. As a result, the internet has enabled new forms of collective action and collaboration.
One of these new forms is the development and organization of Open Source software. Open Source software is software which is freely redistributable and can readily be evolved and modified to fit changing needs (Raymond, 1998). Characteristically, Open Source software is developed by volunteers, and by employees of companies working on a non-profit base, operating from all around the world, working at their own pace, at their own project tasks. Simultaneously with the rise of the Internet for the general public, in the last half of the 1990s, Open Source software projects gained a lot of momentum. In those days, as a reaction against dissatisfaction associated with proprietary software, Open Source software projects flourished. The public sharing of the creation, ownership, and benefits of the Open Source software model is the antithesis of the Microsoft model (Perens, 2005). Since then, Open Source software projects (OSSPs) and their communities have achieved enormous success. Popular examples are Linux, the operating system of Linus Torvalds, and Apache, web server software, both known for successfully competing against Microsoft's closed source software equivalents. Other examples are MySQL, a relational database management system with over 11 million installations, Python, a high-level programming language, and TYPO3, a wide spread enterprise-level content management system.
Giants of industry do not exactly know how to respond to this Open Source movement but some of them including Sun Microsystems, IBM, Cisco, and Hewlett-Packard have identified the potential of Open Source software and are sponsoring these projects by donating money and resources, or by allowing employees to contribute to these projects during work time. Also, previously held closed source software have been made open. Software projects as Mozilla, an Internet browser, and Open Office, an alternative for Microsoft Office have seen their success rising by the shift from a closed form of software distribution to Open Source software. Governments and organizations all over the world including USA, Germany and China are actively supporting Open Source software and Open Standards (publicly available communication protocols), to maintain their neutrality and independency to not be solely dependent on proprietary, commercial software contributions.
Others have identified the benefits of Open Source software as well. Civilians, such as students, may opt for Open Source software to reduce their costs significantly. Currently, a simple computer system for basic usage as typewriting, internet surfing, listening music and watching videos, solely equipped with Open Source software is not surpassed by a system equipped with proprietary
11 software. Companies do not want to be completely depended on a few software suppliers and instead choose for Open Source software to be more agile and flexible. As well, it may reduce initial costs, and can be adapted to specific needs immediately. Institutions and researchers may choose for Open Source software because of the neutrality to all stakeholders they need to satisfy. In general, Open Source solutions for security issues are perceived as more secure than closed software solutions. Due to the fact the source code is publicly available flaws can easily be detected.
It becomes clear Open Source projects not only may have a huge economic impact, the impact on the development of software, and even the impact of organization and innovation can be distinguished. However, currently not much is known about the conditions which lead to success of Open Source software projects. Most research on Open Source software, as with all relatively new phenomena, has been of exploratory or descriptive nature. Even now researchers have not reached consensus on how to define and measure the success of OSSPs and are unable to answer the question why do some OSSPs succeed while others fail (Crowston et al., 2006).
Most Open Source related research has focused on well-known, well-established Open Source examples which have large communities. However, most Open Source software is created by individuals and small teams (Krishnamurthy, 2002). In addition, Capiluppi et al. (2003) noted most Open Source software projects hosted on the SourceForge platform were inactive, and the pool of developers is a scarce resource that concentrates on very few projects, of which just an even smaller few will make it into a success. Finally, Capiluppi et al. (2003) concluded very successful Open Source projects such as Linux and Apache are probably not the 'average' Open Source project.
To address the knowledge gap associated with the succeeding of Open Source software projects, here two research directions are further explored. On the one hand is focused on small Open Source software projects. Although the majority of projects can be remarked as 'being small', most research has ignored this kind of projects. On the other hand, various measures are explored to investigate success of Open Source software projects, as researchers still not have achieved consensus on this topic.
1.1. Research approach
There are two main reasons which make the investigation of Open Source software projects difficult. First, the Open Source phenomenon is relatively new, and thus its research. And, the agile and complex behavior of Open Source project communities does not make it easy to investigate and measure these entities. To overcome these difficulties a suitable research approach is essential, therefore a social network perspective is chosen. A social network perspective focuses on the structure of relationships between social entities, and the nature of that structure, rather than the attributes of
12 these entities themselves (Wasserman and Faust, 1994). Stated otherwise, this research focuses on the relationships of, and between, developers within these OSSPs, rather than focusing on specific characteristics of these individuals.
Not many social network research have been conducted related to Open Source software projects. Healy and Schussman (2003) proposed researchers should attend more closely to the social structure of the Open Source software community as they stated the huge cap between successful and unsuccessful projects is 'a real puzzle'. Hinds (2008) chose a social network perspective to further investigate the conditions which are associated with success in Open Source software project communities. A major advantage of this perspective is that it can be used as a research framework, or lead for other perspectives and research areas. Also, the social network perspective enables the precise definition of research constructs and success factors which are necessary to overcome current research issues necessary to solve, before more detailed in-depth research can take place.
The author of this research agrees with Hinds (2008) about the importance of the Open Source movement, its complex behavior and its influence on society. Therefore, the research (in progress) of Hinds (2008), and the proceedings of this research (Hinds and Lee, 2008) are used as a guideline for this Master Thesis research. The research of Hinds (2008) is currently not only the most recent research on Open Source software development project which takes a social network perspective into account, it is also properly set out and clear, well founded and usable for further research, next to be of an interesting and refreshing nature.
1.2. Research question
The main underlying research question is: 'Why do some Open Source project communities succeed while others fail?'. Taking a social network perspective into account to investigate the structure of these communities the research question can be formulated as:
'What is, if any, the influence of social network structure on the chance of success of Open Source software project communities?'
By using this question a fundamental contribution to the insight in the structure and management and organization of OSSP communities and its innovative development processes can be made. In practice, software development communities, individuals, organizations, businesses and governments can use the knowledge of the research findings to learn and improve the organization and strategy of (developmental) projects. The knowledge of the social structure of a network can be used in many disciplines of scientific research, business models and social and political fields, since this 'network model' is an organizational form which is used in many areas. Previously, economics have written about business modularity, biologists and mathematicians about swarm intelligence,
13 computer experts about the semantic web, and etcetera. All with the 'network model' as a conceptual fundament.
1.3. Definitions
Before discussing the research-related conceptual foundations and literature, first of all three main constructs are briefly set out to put the research scope.
(1) Open Source software project community
Open Source software is defined by Raymond (1998) as software which is freely redistributable and can readily be evolved and modified to fit changing needs. In addition, an Open Source software project is the total amount of activities needed to develop a particular piece of Open Source software. The Open Source software project community is the community of the Open Source project which consists of the population of individuals who contribute to the project. These individuals are called project community 'members', but are also referred to as developers, participants or actors. Open Source (OS) software is sometimes referred to as FOSS, F/OSS or FLOSS, which stands for Free / Libre and Open Source Software. When is referred to an Open Source software project community, the community is limited to the individuals contributing to a particular project, and not to all Open Source developers in general, which can be seen as a community on its own as well. An Open Source software project community is sometimes referred to as an Open Source software community or Open source software development community.
(2) Social network structure
The social network structure refers to the structure of an Open Source software project community and includes (the pattern of) all interactions between the individuals of the community. These interactions, sometimes referred to as relationships or ties, are the ingroup ties. To a limited extent outgroup ties are being research as well. Outgroup ties include all interaction between individuals of a community and other individuals (of other Open Source software project communities) outside the community. This is discussed in a later stadium.
The social network perspective does not take individual characteristics of the community members into account. To distinguish some characteristics of these individuals 'subgroups' are introduced, which is discussed in a later stadium as well.
14 (3) Community success
Community success refers to the success of an Open Source software project community. Currently researchers are arguing on how to measure success of Open Source software project communities. Success can be conceived in many ways, and therefore it is difficult to define success.
As a project refers to the amount of activities needed to develop a particular piece of Open Source software, here success can be measured by means of two dimensions. First dimension is 'success as activity' which is associated with the level of activity of a particular OSSP community. The second dimension is 'success as output' which is associated with the amount of software produced. Other measures of community success, including the impact on society, the economic value or 'good will' of a project community are not part of the research scope.
1.4. Master Thesis structure
This chapter introduced the unique character of Open Source software development and its impact on society. In succession, the social network research approach and research question were proposed. Then, three definitions of main research constructs were briefly introduced. Here, the outstanding chapter are briefly expounded.
Chapter 2
A literature review is provided to set out the main research elements. A clear picture is rendered of the research topic and its theoretical fundaments.
Chapter 3
Here, first the conceptual research model is introduced and its belonging research constructs. Then, on the basis of six research constructs propositions are made.
Chapter 4
First, the study design is presented, where after the research setting is discussed. Secondly, the research variables are set out. Then, a closer look is taken at the research population, where after the sample strategy is proposed.
Chapter 5
This chapter includes the data analysis and its results. First, a closer look is taken at the sample descriptive statistics. Then, the preliminary analysis includes a transformation of variables, an outlier assessment, and a reduction of variables. Several descriptive statistics of are discussed as well.
15 Finally, the hypotheses are tested and the testing results are presented on the basis of the research constructs.
Chapter 6
First, the research findings are briefly summarized, where after a discussion of these findings is started.
Chapter 7
In this final chapter first research conclusions are drawn related to theoretical implications. Next, strategic conclusions are drawn related to practical implications. Finally, the research limitations and flaws are discussed, and recommendations for future research are proposed.
16 2. Literature
This chapter is segmented up into four subchapter in which the literature review is presented. First, theory related to social networks is discussed, where after the topic of Open Source software is set out. Then is dealt with group processes and work teams, to come to an end with a discussion about virtual communities.
2.1. Social networks
This subchapter deals with theory related to social networks. First, the social shaping of new media and the network model and their current importance are taken into account. Then, social network analysis and the social network perspective are introduced. Briefly, social network theory and its most important field social capital theory are introduced as well.
2.1.1. New media and the network model
Lievrouw and Livingstone (2006) noted the social shaping and social consequences of information and communication technology of new media. New media, thus new tools used to store and deliver data and information, have become everyday technologies, thoroughly embedded and routinized in the societies where they are most widely used. The most important example is the rise of the internet. The infrastructure and the technology of the internet have created endless new possibilities as transactions costs for communication, organization and information transportation, etcetera, are reduced to a minimum.
Two main forms of social shaping new media can be identified. First, recombination is the continuous hybridization of both existing technologies and innovations in interconnected technical and institutional networks (Lievrouw and Livingstone, 2006). The second form of social shaping is described as the network metaphor.
‘…the point-to-point network has become … the archetypal form of contemporary social and technical organization … [it] denotes a broad, multiplex interconnection in which many points or nodes (persons, groups, machines, collections of information, organizations) are embedded. Links among nodes may be created or abandoned on an as-needed basis at any location in the system, and any node can be either a sender or a receiver of messages – or both.’ (Lievrouw and Livingstone, 2006)
The internet is becoming ubiquitous. It is a global network where everybody and everything can interact quickly and instantly with each other, twenty-four-seven. Even if you are not an internet user it effects your life, as others surrounding you are affected by the internet. In fact, the internet is a huge social network. As Wellman (1996) states 'when a computer network connects people, it is a
17 social network. Just as a computer network is a set of machines connected by a set of cables, a social network is a set of people (or organizations or other social entities) connected by a set of socially-meaningful relationships.'
The crowd involved in these social computer networks are often referred to as being a virtual community. Hinds and Lee (2008) offer a simple, and suitable definition of a virtual community. A virtual community is a community in which the primary mode of interaction is electronic (online/virtual) and not face-to-face. These virtual communities have important social and technological implications. To investigate the structural properties of these virtual communities further, a social network perspective is taken into account and social network analysis is applied to conduct research.
2.1.2. Social network analysis
Social network analysis is a set of methods and applications suitable for analyzing network data. Social network analysis is commonly used in a variety of scientific areas such as studies of social and behavioral nature, but also in fields as marketing or economics. The social network perspective focuses on the structure of relationships between social entities, and the nature of that structure, rather than the attributes of these entities themselves (Wasserman and Faust, 1994). In this case the research focuses on the relationships of individuals in Open Source software projects, and of relationships of individuals between OSSPs, rather than focusing on specific characteristics and behavior of these individuals.
Although researchers reached consensus on central principles of social network analysis, alternatives do exist. Here, the book of Wasserman and Faust (1994) called 'Social network analysis: methods and applications' is used as a reference guide. This book is well received among researchers conducting social network analysis in the Open Source area. In addition, Hinds (2008) refers several times to this book. And, the book is edited by Mark Granovetter who is well respected for his important and insightful research in the area of social networks.
Social network analysis is a distinct research perspective within the social and behavioral sciences, as the social network perspective is based on the assumption of the importance on relational concepts or processes between individuals. Wasserman and Faust (1994) noted four characterizing principles of social network analysis.
(1) Actors and their actions are viewed as interdependent rather than independent, autonomous
units
(2) Relational ties (linkages) between actors are channels for transfer or 'flow' of resources
(either material or nonmaterial)
(3) Network models focusing on individuals view the network structural environment as providing
18
(4) Network models conceptualize structure (social, economic, political, and so forth) as lasting
patterns of relations among actors
Social network analysis not uses the individual as main unit of analysis, but an entity consisting of a collection of individuals and the ties between these individuals. Thus, the difference between a social network and a non-network explanation of a process is the encapsulation of concepts and information on relationships among the studied individuals.
2.1.3. Social network theory
Social network analysis is a product of social network theory. Social network theory has a long tradition and rich history, and its usage is popular to researchers working across a broad range of disciplines. Social network theory finds its roots in social sciences, with influences of mathematical, statistical and computing methodology. The last decade a 'new' science of social networks has risen. It is noted in many real-world networks the number of network neighbors is identified by a power-law distribution. Typically, the degree distribution is right-skewed with a 'heavy tail', meaning that a majority of nodes have less-than-average degree and a small fraction of hubs are many times better connected than average (Watts, 2004). Thus a small percent of the network hubs is responsible for the majority of the activity in a network. These networks are called small-world networks, and their distinguished by the fact they are scale-free.
In a popular way Chris Anderson (2006) described the economic and social impact of the near-limited possibilities of the ubiquity of the internet, which he calls 'the long tail' effect. Now, niche markets can create big opportunities as the costs of search and distribution via the internet are reduced to a minimum.
2.1.4. Social capital theory
Probably the largest domain of social network theory is called social capital theory. The main principle of social capital theory is social networks represent value. The social ties in networks can be conceived as pipelines for the flow of data, information and knowledge, and other resources. The structure of networks, thus the allocation of the social ties, is of importance for the value of the network.
A wide variety of constructs exist to define and measure the value of social networks. Here, three basic constructs are used, which are further discussed in the next chapter. Closure represents the allocation of ties within a social network, bridging represents the allocation of network ties to other social networks, and centrality represents the influence of the social network initiators.
19 2.2. Open Source software
This subchapter deals with the Open Source phenomenon. Open Source can be perceived as a form of software distribution. First, its history is set out, where after Open Source software project contributors are mapped out. In respect to the organization of Open Source software projects, their communities are described, and used organizational metaphors are set out. Next, success studies and studies using social network perspective are discussed.
2.2.1. Open Source as a form of software distribution
Although Open Source software just became popular in the last half of the 90s, simultaneously with the rise of the Internet, this type of software has a long history. Strictly, Open Source (OS) software is software released under a license conforming to the Open Source Definition. The Open Source Definition is derived from the Debian Free Software Guidelines and was composed by Bruce Perens for the purposes of the Open Source Initiative which he co-founded with Eric Raymond in 1998.
Already taken first preparations in 1983, in 1985 Richard Stallman published the GNU Manifesto to announce the development of a free Operating System called GNU ('GNU's Not Unix')(GNU, 2009). Not late after the publication of the GNU Manifesto Stallman started the Free Software Foundation, which is a non-profit organization for the purposes of spreading the free software philosophy. By this Foundation Stallman could employ free software developers and provide a legal infrastructure for its activities. The free software philosophy was based on the essence of the hacker culture. Despite of the current negative context in the newspapers, a hacker is actually a programmer enabling the computer to do what he wants, not to question if the computer wants to or not (Paul Graham, 2004). It was a common use for the earliest programmers to share any software that was developed. Everything was new, and programmers needed to learn a lot to improve their creations and gain knowledge. When hardware vendors began to dominate the software market it became the norm to distribute proprietary software in binary code at a significant cost. The free software philosophy was a reaction to this domination.
One of the first licensing terms was the concept of copyleft. Stallman made this form of licensing popular in 1985. In 1989, the Free Software Foundation introduced the GNU General Public License (GPL) which is based on a number of implemented copylefts and other free licenses. The GPL was the first program-independent license, and therefore could be used in many ways.
As of today, there are many Open Source licenses around, for example the MIT-license of the Massachusetts Institute of Technology, or the Acadamic Free License (AFL). Still, the GNU license, currently in its third version, is the most popular license used. The Open Source Initiative has
20 summarized the Open Source Definition into ten points which need to be satisfied to let software be marked as Open Source (OSD, 2009)
2.2.2. Open Source software project contributors
Previously, Open Source was perceived as a gift economy (Raymond, 2000). In a gift economy volunteers contribute to an Open Source project without monetary benefits. Software developers use their spare time to participate in Open Source projects which are not related to their daily work. This way, their benefits are of intangible nature, as it helps them to do more creative and artistic work. However, the gift economy does not answer the question why large corporations and businesses are actively supporting Open Source software projects by contributing resources and programmers. Perens (2005) made an overview of common contributors to Open Source software projects. Hars and Ou (2001) have identified incentives of why developers participate in Open Source software projects. Appendix B provides a detailed overview of types of project contributors and their incentives to create Open Source software.
2.2.3. Open Source Software project communities
Raymond (2000) describes the start and growth of an Open Source software project community. An individual, or a small group of individuals, create an initial functioning prototype of the software and put this in the public domain as Open Source software. Then, people gather around this prototype, all with their own reasons and goals, and work together to continue developing the software. Next, as the software becomes more usable, more people are attracted to the community and start developing as well. Now, a growth cycle has started which feeds both the community and the development of the software. Due to the growth of the community, it becomes more divers and sustainable, and so does the value of its software.
In general, the development and communications structure of an Open Source software project is provided by a hosting platform. For example a hosting platform as SourceForge or Open Source Flash has an extensive set of tools which enables the hosting and management of Open Source software projects. A wide variety of Open Source software projects is hosted on these platforms.
Various researchers have suggested a typology of projects to map out differences between these Open Source software projects. For example, from a software architectural perspective Raymond (2000) proposed a typology including three types of software, namely infrastructural software, middleware and application software. Another interesting perspective is taken into account by Ye et al. (2005) who propose a project typology based on the goals of the software developers and include (1) exploration-oriented projects, which attempt to create leading edge solutions which involve innovative approaches, (2) utility-oriented projects, which are directed towards filling a void
21 in functionality, and (3) services-oriented projects, which are geared to maintaining stable code and providing ongoing services to large group of stakeholders.
Similar, typologies have been proposed to differentiate between stages of development of Open Source software projects. Based on software writing Rothfuss (2002) identifies six categories of development statuses. This development lifecycle includes (1) planning, (2) pre-alpha, (3) alpha, (4) beta, (5) production/stable, and (6) mature. In practice, the SourceForge platform identifies an extra category for (0) inactive projects. Krishnamurthy (2002) and Capiluppi et al. (2003) found evidence the majority of projects hosted on the SourceForge platform are inactive, or never get through the initial development lifecycle stages.
2.2.4. The organization of Open Source software projects
Various researchers and Open Source practitioners including Crowston and Howison (2004), Raymond (1998) and Almarzouq et al. (2005) have identified the community structure of an Open Source software project as an onion-like structure that is based on the level of contribution. The core of the group, in general the smallest subgroup of the community, is responsible for the majority of the code development and effort contribution (Krishnamurthy, 2002)(Crowston and Howison, 2006). The core is surrounded by co-developers, which, on occasion, modify or review code or fix bugs. The majority of the community is formed by users, who either can be active or passive users. Where passive users are only software users, and thus contribute nothing directly to the project, active users usually contribute ideas, suggestions and bug reports.
These passive users are often referred to as free-riders (Crowston and Howison, 2004) or lurkers or leechers. In other types of virtual communities, such as electronic communities of practice (Wasko and Faraj, 2000), sharing and distributing platforms (Nonnecke and Preece, 2001) this is considered to be a problem, as it negatively affects the outcome of a group. However, Perens (2005) states all Open Source users start out as free-riders. They download and try the software, and do not generally consider contributing to the software development. But, when the time comes they gain interest in the project or desire an additional feature, they might implement it themselves, and are not longer free-riders. Here, the negative effect is not a burden for the project community.
Not much is known about leadership within Open Source software project communities. Open Source software projects are generally perceived as democratically operating entities. However, it is generally noted project leadership is important to achieve success. (Raymond, 2000)
Metaphors have been used to provide insight in the organization of Open Source projects. Open Source initiator Raymond (1998) noticed Open Source software Projects can be perceived as communities of developers and introduced the concept of cathedrals and bazaars. Most proprietary,
22 commercial software is made in similar to how people build a cathedral. Designed by smart individuals (architects) or small isolated groups, with no beta releases in between. Open Source software is made similar to how bazaars work. Mixed approaches and agendas of many different people resulting in a coherent and stable system, with a lot of beta releases and testing in between.
Cox (1998) added two organizational metaphors, namely the town council and the clique. A clique is just like a ‘failing’ bazaar. What supposed to be functioning as a bazaar, ends up in a clique. Here, a lot of ‘wannabe’ programmers are polluting the transparency of the project and ideas of the core group by giving their opinions, instead of producing real code. As Cox says "They knew enough to know how it should be written but most of them couldn’t write 'hello world' in C."
The town council is an organizational metaphor with a better ratio of ‘wannabe’ programmers versus real programmers. The core design is strictly kept in hands of the real programmers where the ‘wannabe’ programmers can be of use to lesser important project tasks. When a wannabe programmer becomes stuck, the chance is high some of the other wannabe programmers know how to solve this problem. Functioning as a safety buffer, the noise in the project is turned into productivity.
2.2.5. Success studies
Various researchers have identified factors affecting the success of Open Source software projects. However, no one has addressed the question of success factors for specific projects in systematic way (Hinds, 2008).
Despite Open Source has commonly been regarded as work produced by a community of developers, several studies conducted on the SourceForge platform indicated otherwise. Based on a study of 100 mature Open Source software products Krishnamurthy (2002) found most programs were developed by individuals, rather than communities. Next, most programs did not generate a lot of discussion on their projects' public forums. Products with more developers tend to be viewed and downloaded more often, and the number of developers associated with a project is unrelated to the age of the project. Finally, Krishnamurthy found the larger the size of a project, the smaller the percent of administrators.
In a similar way, Healy and Schussman (2003) found power-law distributions for Open Source software project activity measures, such as for the number of developers, number of downloads and number of site views. Also they found different types of projects dominated different types of these measures. Healy and Schussman concluded there is a real gap between the current state of theory and data, and cannot answer the question of project success affection.
23 Stewart and Ammeter (2002) conducted an exploratory study considering factors influencing the level of vitality and popularity of Open Source projects. Here, vitality is an indicator of how much developer effort and attention is expended on a project, and popularity is an indicator of how much user attention is focused on a project. Surprisingly, they concluded the vitality of an Open Source software project is not affected by development status, sponsorship, and type of project (project category and target audience).
Crowston and Howison (2004), Howison and Conklin (2005) and Crowston et al. (2006) noted in information systems research success is one of the most used dependent variables, however Open Source related research often fails to conceptualize this important concept. Crowston et al. (2006) provide a detailed overview of success measures used in recent Open Source related research. They distinguish four types of success measures, namely (1) system creation, (2) system quality, (3) system use and (4) system consequences, and opt for a portfolio approach of success measurement in respect to Open Source software projects.
2.2.6. Social network perspectives
Just a few studies have used social network analysis to conduct research related to Open Source software projects and their communities. Even fewer studies have used a social network perspective as a framework for theory building, since most studies are of descriptive and exploratory nature.
Madey et al. (2002) use social network analysis to explore the Open Source software development phenomenon. 39,000 projects, involving 33,000 developers, hosted on the SourceForge platform were investigated. By structurally mapping out relationships between software developers, the presence of power-law distributions was found for project sizes, cluster sizes of connected developers, and the number of projects joined by developers. Madey et al. (2002) conclude Open Source software development can be modeled as self-organizing, collaboration, social networks.
Gao et al. (2003) explored the statistics and topological information of the Open Source software developers collaboration network further by extracting project evolution parameters, by inspecting the network over a time period of two years. 50,000 projects involving 80,000 developers were investigated. Again, power-law distributions were found for the cluster distribution and degree distribution, which is the amount of ties within a network. Also they found during this time frame the average degree of projects on SourceForge slightly increased, though the network diameter slightly decreased.
Xu et al. (2005) investigated the composition of the Open Source software community on the SourceForge platform and its collaboration mechanisms as well. Again power-law distribution were
24 found for social network properties and indicators of small-world networks and scale free behaviors were found. They also concluded weakly associated, but contributing, co-developers and active users may be an important success factor in respect to the development of Open Source software.
Crowston and Howison (2004) investigated the structure of 120 Open Source software projects hosted on SourceForge by measuring the interactions in the bug tracking systems of these projects. They found Open Source projects widely vary in their communications centralization, and suggested the onion-structures may be representative for the development structure of Open Source software projects, but are not representative for the communication structure.
2.3. Group processes and work teams
This subchapter deals with the theory of group processes and work teams, in social science often referred to as group dynamics. Group dynamics focuses on the nature of groups - the variables governing their information and development, their structure, and their interrelationships with individuals, other groups, and the organizations within they exist (Greenberg and Baron, 2003). Here is focused on the effectiveness of groups, as the point of interest is on how groups may become successful. First the organization of group and work teams is set out. A team can be noted as a special type of group. After the discussion of virtual teams, research related to the success of groups and teams and research using a social network perspective is shown.
2.3.1. Organization of groups and work teams
Much has been written about teams and work groups in an organizational setting. Social scientists have formally defined the definition of a group as collection of two or more interacting individuals with a stable pattern of relationships between them who share common goals and who perceive themselves as being a group (Greenberg and Baron, 2003). There is a wide variety of groups, and people can join groups for different reasons. Greenberg and Baron (2003) distinguish several basic types of groups. First, groups can be formal or informal. Formal groups include command and task groups, where informal groups include interest groups and friendship groups. Based on Maslow's need hierarchy, they distinguish four main reasons why people join groups, namely (1) to satisfy mutual interests, (2) to achieve security, (3) to fill social needs, and (4) to fill need for self-esteem.
Tuckman and Jensen (1977) have identified five stages that small groups go through during their development. These stages are (1) forming, (2) storming, (3) norming, (4) performing and (5) adjourning.
Greenberg and Baron (2003) provide an overview of four primary structural elements of groups, namely roles, norms, status and cohesiveness. Group members tend to play one, or more, specific roles in group interaction. A role is defined as the typical behaviors that characterize a person
25 in social context. Next, to properly function as a group, norms exist. Norms may be defined as generally agree upon informal rules that guide group members' behavior. Status is the relative social position or rank given to groups or group members by others. Finally, cohesiveness is the strength of group members' desires to remain part of their groups.
One of the major problems which may occur in groups is called social loafing, which is often referred to as 'free riding' of individuals. Group tasks, which involves the coordinated effort of multiple people, may be negatively affected by free riders. As the size of the group increases, group members may have the tendency to put less individual effort in the group task.
2.3.2. Teams
Although sometimes used interchangeably in research, a team can be noted as a special kind of group. Greenberg and Baron (2003) use the definition of a team of Katzenbach and Smith (original 1993) who state a team is a group whose members have complementary skills and are committed to a common purpose or set of performance goals for which they hold themselves mutually accountable. The difference between groups and teams in respect to their performance can be summarized into four points.
(1) Performance of groups depends on individual contributions, where the performance of teams
depends on individual contributions and collective work products.
(2) Accountability for group outcomes rests on individual outcomes, where accountability for
team outcomes rests on mutual outcomes.
(3) Group members are interest in common goals, where team members are interested in common
goals and commitment to purpose.
(4) Groups are responsive to demands of management, where teams are responsive to
self-imposed demands.
Tuckman and Jensen (1977) have categorized teams along five dimensions. The first dimension is called purpose or mission. Work teams are concerned with products or services, where improvement teams are concerned with improving the effectiveness of processes. The second dimension is time. Where temporary teams exist for a finite period, permanent teams remain intact as long as the organization is in existence. Third dimension is the degree of autonomy. Where in work groups leaders make decisions for group members, in self-managed work teams the team members are free to make their own decisions. The fourth dimension is authority structure. Where intact teams work within their own specialty area, cross-functional teams consists of members from different specialties. The final dimension is physical presence. Members of physical teams are physically present, where members of virtual teams meet via electronic means.
26 Hackman (1987) identified four stages which work teams go through when they develop, namely (1) prework, (2) creating performance conditions, (3) forming and building the team, and (4) providing ongoing assistance.
2.3.3. Virtual teams
Information technology is providing the infrastructure necessary to support the development of new organization forms, including those of virtual teams. Scientists have defined virtual teams as groups of geographically, organizationally and/or time dispersed workers brought together by information and telecommunication technologies to accomplish one or more organizational tasks (Powell et al., 2004).
Strader et al. (1998) have identified four phases virtual organizations go through during their development. These four phases are (1) identification, (2) formation, (3) operation and (4) termination.
2.3.4. Success of groups and teams
Much research about the effectiveness of groups and teams in social, behavioral and economical sciences do exist. Cohen and Bailey (1997) conducted a literature study of six years of research on teams and groups in organizational settings. As a result they made a general distinction between three dimensions of team effectiveness, thus success measures and indicators, namely (1) performance effectiveness assessed in terms of quantity and quality of outputs, (2) member attitudes, and (3) behavioral outcomes.
2.3.5. Social network perspectives
Taken social network theory into account the organizational network structure affects team viability and team task performance (Balkundi and Harrison, 2006). Team viability involves the committed of team members to stay together, where team task performance involves attaining the goals of a team. Team viability and team task performance can be conceived as success measures of teams. Balkundi and Harrison (2006) noted although these two dimensions of success are conceptually distinct, in reality there is a close connection and cross-correlation between team task performance and team viability. In addition they found teams with central leaders, and teams central in a network full of other teams, tend to be better performers.
Carley (1995) compared hierarchies and centralized structures with democratic team or decentralized structures. She found hierarchies and centralized structures tend to exhibit lower performance than democratic or decentralized structures. Information loss, uncertainty absorption and information distortion are important causes. And, the more levels in the hierarchy the greater level of
27 information loss and distortion. However, Carley (1995) states for simple tasks simple structures as decentralized and team-like structures perform better. And, for more complex tasks, hierarchical and centralized structures perform better in the long run, although their response may be slower.
In respect to the organization of teams during information system (or software) development Yang and Tang (2004) researched 25 teams in a system analysis and design course. Four findings could be derived. (1) Group cohesion was positively related to overall performance, (2) group conflict indexes were not significantly correlated with overall performance, (3) group characteristics such as cohesion and conflict fluctuated in different team stages, though in later stages much less cohesion occurred and the advice network seemed to be very important. Finally, Yang and Tang concluded (4) that group structures seemed to be a critical factor for good performance.
2.4. Virtual communities
Open Source related research and Open Source initiators have often described the individuals participating in Open Source software projects as members of online, or virtual, communities. Hummel and Lechner (2002) state the definition of a virtual community of Rheingold is probably best known. Rheingold (original 1993) defined virtual communities as social aggregations that emerge from the Net when enough people carry on those public discussion long enough, with sufficient human feeling, to form webs of personal relationships in cyberspace. From the view of computer-mediated communication, the most important elements of a virtual community are shared resources, common values and reciprocal behavior (Hummel and Lechner, 2002). Current research describe that virtual communities are in many respects similar to traditional, offline, communities.
Bughin and Hagel (2000) note that virtual communities are not simply communities, but are (becoming) a prominent business model of the world wide web, as these virtual communities can combine reach and selectivity based on user needs. In addition, they note virtual communities do not only fill a strategic niche, virtual communities also tend to have stronger operational performance than other business (to consumers) models. In respect to work teams De Souza and Preece (2004) identified several distinguishing characteristics of online communities.
- Many online communities exist mainly for social action as well as or rather than work.
- Online communities can involve large groups.
- Many online communities develop in an ad hoc way.
- Schedules and timeliness tend not to be a focal issue for most online communities.
- Participants in online communities are often widely distributed and may cross cultural and geographical divides.
- Many online communities exist on the internet and are open to a wide variety of people.
- The skills and knowledge of members may be very broad in some online communities.
28 communities of practice and communities of interest. Where communities of interest serve the purpose to inform interested people, communities of practice serve the purpose to create, expand and exchange knowledge between people, based on expertise or passion for the topic of interest. Fischer (2001) adds communities of interest bring together stakeholders from different communities of practice. Wasko and Faraj (2000) propose knowledge can be considered as a public good, owned and maintained by a community. When knowledge is considered a public good, knowledge exchange is motivated by moral obligation and community interest rather than by narrow self-interest.
Wenger (1998) identified five stages of development of communities of practices, namely (1) the potential stage, (2) the coalescing stage, (3) the active stage, (4) the dispersed stage, and (5) the memorable stage.
2.4.1. Success of virtual communities
In general, only a few studies have focused on the success of virtual communities. Success of virtual communities can be defined in many ways. Leimeister et al. (2004) observe the differences between the definitions of success for stakeholder groups of virtual communities. Sangwan (2005) observes from ‘a uses and gratifications’ perspective, i.e. she uses member need satisfaction as a proxy measure for virtual community success. And, Lin et al. (2007) propose a research model which investigates sociability and usability factors to community success.
Crowston et al. (2004 and 2006) present an extensive set of measures that could be used to research the success of Open Source software projects. Hinds and Lee (2008) state it is plausible that success conditions are related to the community type of a virtual community and therefore can differ from each other.
2.4.2. Social network perspectives
Very limited research related to virtual communities have taken a social network perspective into account. However, several social network theory related research and articles of communities of practice are published by Teigland, Schenkel and Wasko. For example, Schenkel et al. (2000) have defined five structural properties which characterize communities of practice.
(1) connectedness In a community of practice, every member is connected, directly or
indirectly, to every other member
(2) graph-theoretic distance Relative to organizational networks in general, communities of practice have shorter graph-theoretic distances between all pairs of members
(3) density Relative to organizational networks in general, communities of practice
have a greater density of ties
(4) core/periphery structure Communities of practice have core/periphery structures rather than clique structures
(5) coreness The greater an individual's participation in a community of practice, the
3. Conceptual model and propositions
This chapter deals with the conceptual model and propositions. First the conceptual model is presented, where after the research constructs are briefly set out. Finally, the social network model and the propositions are discussed.
3.1. Conceptual model
The conceptual model proposed is adapted from Hinds (2008) and is discussed below. Each part of the conceptual model is briefly explained.
Figure 1 - Conceptual model
Source: adapted from Hinds (2008)
Figure 1 shows the adapted conceptual model in which community social network structure may affect community success. Various factors may moderate this relationship. Next, community success may have an effect on community impact. And, external market factors may affect community impact. Though, community impact and market factors are beyond the research scope. Here, each box of the conceptual research model is further set out.
Community social network structure
Community social network structure is made up out of three constructs adapted from social network theory, respectively bridging, closure and leader centrality, as proposed in Chapter 2, and further set out in the next subchapter.
30 Community success
Success can be measured in various ways, and in the area of Open Source software projects it is not clear how to measure success exactly. However, Grewal et al. (2003) noted the criteria for success of Open Source software projects should encompass both the technical achievements of a project, as well as indicators of market or commercial success, to be in line with information systems literature and R&D product development literature. Hinds (2008) sets out the concept of community success as a model consisting of two dimensions, namely success as output, and success as activity. Where success as output can be perceived as the quantity of produced software, success as activity can be perceived as the quantity of participation of community members. Thus, community success can be reflected as the effort of, and the performance of, an Open Source software project group. The effort of project members is reflected in success as output, and the performance of a group is reflected as success as activity.
As shown in Figure 1 the reciprocal relationship between success as output and success as activity is based on the assumption that producing more software will lead to greater community participation. And, increased community participation will tend to attract even more developers to produce more software. Another assumption is community activity can be representative for software product quality, since it is plausible software of high quality can generate a higher level of community activity than software of low quality.
Due to the fact, this research works with total numbers of success, these success factors need to be controlled for various other factors. E.g. it is plausible the age of a project may affect the amount of output of a project, simply because of the age, and not due to its project structure. Therefore, this factor needs to be controlled. In the next chapter is further explained how success factors and their control mechanisms are applied to this research.
Moderating factors
Hinds (2008) recognizes various factors which may mediate the relationship between social network structure and its success, including project type, project maturity, process/task structure, community norms, and organizational environment, among others. This research recognizes these factors in well. However, here is suggested these factors are moderating factors, rather than mediating factors. According to Baron and Kenny (1986) a moderating variable is one that influences the strength of a relationship between two other variables, whereas a mediating variable is a variable that explains the relationship between two other variables.
Due to a wide variety of Open Source software projects, it is impossible to take each moderating factor in account. Here, several plausible moderating factors are recognized. In
31 succession, these factors are filtered from the research sample, by selecting on various characteristics, to attempt to obtain a homogenous sample of Open Source software projects. Therefore the moderating factors are beyond the scope of the research in the conceptual research model. In the next chapter is discussed in which way these moderating factors are further taken into account.
Community impact and market factors
Community success is not only affected by community output and community activity, community impact and market factors can influence community success as well. An example of an influencing market factor could be the bankruptcy of a competitor. As a result users could eventually switch to your products. Market factors, as the incorporation of your product intro a broader infrastructure, for example providing the option to automatically install Open Office, when installing the Sun Solaris Operation System. These factors are beyond the scope of this research and therefore not included.
3.2. Research constructs
The introduced social network concepts are further set out as six social network constructs, namely group closure, core closure, peripheral two-mode closure, core bridging and administrator bridging, and administrator centrality, which are briefly discussed here. The 'group' concept is constructed via three subgroups, namely the administrator subgroup, core subgroup and the peripheral subgroup. Each subgroup represents a type of developer which can be distinguished in an Open Source software development community. But, first Hinds' (2008) development framework for the social network constructs is given, where after the subgroup and research constructs are discussed.
Figure 2 - Development framework for social network constructs
Source: Hinds (2008)
The development framework for social network constructs (Figure 2) provides an overview of the involved subgroups for each social network construct.
3.2.1. Subgroups
In studies of communities in general and Open Source software project communities as well, subgroups can be distinguished. Here, three important subgroups are identified. Contradicting to teams, Open Source communities do have cores and peripheries. In general, leaders and high-active members form the core, and ordinary members form the periphery. For example, in online gaming communities such as World of Warcraft guilds exist. A guild is a group of gamers who organize parties with each other to explore dungeons and other areas of this virtual world. The people of these guilds can generally be divided into three types of gamers. There is a guild leader, who is the (democratic) leader. High active members are called officers, and are responsible for daily management, organizing parties and recruiting new members. Ordinary members, contribute less,
33 though they participate in parties and gather materials such as food and potions to play the game party-wise.
Below, each subgroup is described. Administrators
Administrators are project leaders and take responsibility for monitoring and guiding the progress of the project, and who are recognized as such by group members.
Core developers
Core developers are lead developers who take responsibility for developing the project, and who are recognized as such by group members. Core tasks includes functional and technical spec(ifications) writing, programming and testing. Thus, this type of developers has a significant influence in the development process of the Open Source software. Administrators, by definition, can be noted as core developers as well. Sometimes, the administrator subgroup and the core subgroup are taken together and referred to as the 'core group'.
Peripheral developers
All other individuals who are somehow involved in the project and who either contributed source code or have posted on the project forum or are actively involved in making bug reports, alpha and beta testing, posting requests, contribution of source code, etcetera, are referred to as peripheral developers. Although, in general peripheral developers are less involved in the project, their contribution may not be underestimated.
In chapter 4 is further explained in which way these subgroups are applied to this research.
3.2.2. Closure
Closure, also sometimes called coreness, is the extent to which the individuals in a project community are connected with each other. High closure, a tight set of relationships, within a community will improve the utilization of resources, and will create cohesive (sub)groups and support shared norms and trust (Burt, 2000). On the contrary, high closure can result in group thinking. During decision making processes group members are trying to minimize conflict and reaching consensus without critically testing, analyzing and evaluating ideas. A classic example of group thinking is the Challenger space shuttle launch decision, which tragically exploded after 73 seconds after launch of its tenth mission (Weick, 1997). Although, the computer systems knew the Challenger should not be launched under conditions far about outside the experience base, NASA still launched.
