G R Gangadharan
email: grgangadharan@idrbt.ac.in

Martin Butler
email: martin.butler@usb.ac.za

Free and Open Source Software Adoption in Emerging Markets: An Empirical Study in the Education Sector

The adoption of Free and Open Source Software (FOSS) in the education sector in emerging markets holds much promise, but should be accompanied by a wellinformed decision to ensure that the potential value is realized. The research conducted provides insight into the pragmatic factors driving the adoption of FOSS in the education environment, as well as those aspects inhibiting adoption. This study indicates an increasing readiness to accept FOSS in the education sector, where the more successful organizations show a readiness to adopt a comprehensive decision model to ensure the installation of appropriate ICT infrastructure, including FOSS, for the future.

Introduction

One of the business sectors that could benefit considerably from Free and Open Source Software (FOSS) is the education sector [START_REF] Huett | What's all the FOSS? : How Freedom and Openness Are Changing the Face of Our Educational Landscape[END_REF], in particular educational institutions within the developing world. This is mainly due to the fact that education systems around the world are experiencing a range of drivers for fundamental change, including (but not limited to) globalization, changing concepts around the role of knowledge, knowledge workers, knowledge citizens, innovation systems and learning organizations, the widespread need for quality life-long learning, and the relentless emergence of new information and communication technologies coupled with their growing penetration of, and impact on, all sectors of society, including the most disadvantaged [START_REF] Naci | Free/Libre and Open Source Software and Open Standards in South Africa -A Critical Issue for Addressing the Digital Divide[END_REF].

The study by Satyarajan and Akre [START_REF] Satyarajan | Open Source Software Adoption: An Academic Perspective[END_REF] analyzes the differences between the implementation of FOSS and proprietary software in educational institutions. According to them there are two distinct views on the academic acceptance of FOSS. One view favors the use of FOSS, while the other shows hesitancy about FOSS, suggesting that it could suppress the creativity of individuals.The study by Lakhan and Jhunjhunwala [START_REF] Lakhan | Open Source Software in Education[END_REF] focuses on open educational resources and open source learning management systems. They argue that, despite continuing technical challenges, FOSS offers an approach to addressing the technical problems by providing optimal delivery of online learning.

However, the factors influencing and inhibiting FOSS adoption in the education sector in the emerging markets has received significantly less academic attention. To the best knowledge of the authors of this paper, no published research exists in the context of FOSS adoption in the education sector of emerging markets. It therefore focuses primarily on the pragmatic reasons for adopting FOSS.

The paper is organized as follows: The research methodology adopted in this paper is described in Section 2. Section 3 elucidates the factors that influence the adoption of FOSS in the education sector of emerging markets. Section 4 presents the set of factors that inhibit the adoption of FOSS in the education sector of emerging markets, followed by concluding remarks in Section 5.

Research Methodology

A flexible research design was developed for this study with the purpose of exploring FOSS adoption in the education sector of emerging markets.

The research was completed in two phases. During the first phase, existing literature on FOSS adoption was reviewed and a set of structured questions was designed based on adoption factors identified during the literature review. The validity of the questions that emerged from the literature review was tested by conducting preliminary interviews with knowledgeable individuals in the areas of information and communication technology and FOSS. In the second phase, the questionnaire was emailed to the representatives of 40 universities and higher education institutions in emerging markets, including India, Brazil, Russia, South Africa, and China.

Queries from interviewees arising from the e-mail interviews were handled by the authors: respondents were contacted by telephone to discuss any points requiring clarification.

The small sample size of this study presents limitations in generalizing the results to all educational institutions in emerging countries. In addition, the authors recognize that different factors could prevail when considering the adoption of different types of FOSS and that these differences were not addressed in this study. Finally the impact of FOSS on the education process and the pedagogical considerations that should be brought into reckoning when doing an in-depth analysis of FOSS adoption did not form part of this research.

Factors Favoring the Adoption of FOSS

Several factors that favor the adoption of FOSS in education institutions of emerging countries were identified in the survey. Here follow summaries of responses favoring adoption, with accompanying discussions.

Software Code Access

Access to source code is an important adoption factor identified from the research. Users value the ability to change the source code. However, in general, educational institutions do not change the source code unless they want to become part of the FOSS development community. It is interesting to note that the majority of respondents do not want to become part of the FOSS community. None the less, they state access to source code as an important motivating factor. There are limited instances where access to source code is seen as an opportunity to extend and develop software to suit an organization's particular needs. One example is the facility to customize software in local languages, although well-designed proprietary software provides the same facility.

Software Costs

The lower cost associated with adopting FOSS is the most common factor in favor of FOSS adoption, according to this research. The initial acquisition cost of FOSS is negligible and it is usually possible to download FOSS without any application cost, except the cost to download the data. Another cost benefit cited by respondents is that FOSS adheres to open standards and can be run on different platforms, thus reducing the reliance on a single vendor. This increases competition and further reduces adoption costs. The reduced cost of FOSS remains a contentious issue. There are immediate cost benefits in the adoption of FOSS. Educational institutions would be wise to obtain a fully inclusive view of the costs debate, since this complex issue remains at the forefront of the motivations.

Technological Factors

Technological factors relevant to FOSS adoption in the education sector identified from the research include software maturity, performance, stability, usability, security and availability. Respondents' opinions were divided on whether access to source code improves or degrades the security of FOSS. The usability of FOSS is generally considered by respondents to be either better or worse than proprietary software, again depending on the application.

Support Factors

The availability of support is an important factor in all technology adoption decisions. The responses indicated that educational institutions with a strong ICT capability were able to use FOSS without external support.Where they did not have the capabilities to support the FOSS themselves, institutions that adopted vendorbased FOSS obtained support similar to proprietary software solutions. Institutions with the appropriate skills and resources have taken the responsibilities of the software vendor upon themselves.

Human Factors (Supporting)

An important supporting factor is that a great deal of innovation traditionally originates from universities. In academic environments, where FOSS had its beginnings and where interested engagement with this technology is more likely, staff and students can tinker and experiment with, and participate in, its continued development. The return of FOSS to its original crucible for growth may eventually lead to further innovative solutions.

Factors Inhibiting the Adoption of FOSS

Several factors that inhibit the adoption of FOSS in education institutions of emerging countries were identified in the survey. The opinions of respondents, given in answer to the questionnaire, are summarized below.

Migration and Operation Cost

Although FOSS has a significant upfront cost advantage and in certain instances an operational cost advantage, the costs of migrating from proprietary software to FOSS could be substantial. It is especially the unknown, or hidden, costs within this transition that are cited as an inhibitor of FOSS adoption. Indeed, this study has revealed that institutions that have migrated to FOSS for the purpose of cost-efficacy have experienced the cost of migration and maintenance operation to often exceed expectations. The fact is, deep-rooted educational systems, sometimes rife with selfinterested reasons to maintain the status quo, are difficult to replace.

Lack of Resources

It is widely believed that FOSS has vast market potential in emerging countries. However, very few FOSS programmers are present in these countries. According to this study, the lack of adequately skilled FOSS resources in emerging countries hinders the implementing of FOSS. A few major vendors dominate the higher education domain [START_REF] Courant | Software and Collaboration in Higher Education: A Study of Open Source Software[END_REF][START_REF] Wheeler | Open Source 2010: Reflections on 2007[END_REF]. This creates the risk of monopoly in the future. Transitions are thus rendered even more difficult as the skills in these vendors dominate the market, and will continue to do so.

Satisfaction with Existing Software Products

Many of the educational institutions responding to the questionnaire stated that they were satisfied with existing non-open source or proprietary software products. Hence, they claimed to have no reason to migrate to FOSS. In addition, the challenges presently faced by these institutions are centered around servicing the growing and diverse needs of a technologically illiterate constituency. Institutions, with their limited resources and budgets, can ill afford to spend time and resources on new, unproven products to replace that which is currently meeting their requirements.

Human Factors (Inhibiting)

The foremost human barrier to any technology adoption is resistance to change, a concept very well researched in the ICT sphere. Different models of technology adoption are widely used by practitioners. Skeptical users remain a significant barrier to FOSS adoption, especially in large scale migrations [START_REF] Holck | Open Source Software Acquisition: Beyond the Business Case[END_REF]. This factor is confirmed by the respondents in this study and remains a stumbling block for FOSS adoption. Unfortunately, it seems from the responses obtained by this research that certain top managers within the academic environment refuse to acknowledge that the learning landscape has been fundamentally altered (by the advent of FOSS).

Other Factors (Inhibiting)

Some additional factors were listed by respondents as barriers to FOSS adoption, but not with the same frequency or level of importance as those highlighted above. These include the following: • Poor integration with other software (software incompatibility) • Incompatibility with different hardware platforms (hardware incompatibility) • A lack of information on FOSS products • A lack of case studies of successful FOSS adoption by similar organizations • Bureaucracy in ICT decision-making

Concluding Remarks

Given the complexity of the arguments presented, it is highly unlikely that a wide adoption of FOSS to replace incumbent systems will sweep through educational institutions in emerging markets. What is more likely is that new ICT initiatives will give advocates of FOSS an equal voice at the table. Just as FOSS has matured over the past decade, so will those making decisions about new ICT adoptions -they will become more sensitive to the value contribution and challenges associated with FOSS, since this innovation has the potential to deliver considerable benefits for educational institutions in emerging markets.


Swanand J Deodhar

Kulbhushan C Saxena

Mikko Ruohonen

Hybrid Business Models in Software Product Industry: Patterns and Challanges

Operating in software product industry is becoming an increasingly risky proposition. Compressed timeline for product development combined with need to reduce cost has compelled organizations to look at new ways of doing business. One such avenue is combining the erstwhile conflicting practices of open source and closed source software. This industry paper highlights common patterns and challenges encountered in operationalizing such business models. The findings are based on a larger multiple case study research involving six such software products.

Introduction

Software product industry represents organizations that develop software products and build business models around these products. These business models are influenced by two dominant and contrasting licensing regimes, namely proprietary and open source licensing. These two approaches have spawned diverse mechanisms for software development and distribution.

Although the two approaches are highly contrasting, they have an ironic capability of complimenting each other's weaknesses. In proprietary approach, vendors are in control of development and distribution and therefore vendors have to bear the cost for the same. In return vendors are assured of larger chunk of economic rents as only they can sell software licenses. On the other hand, open source approach allows for faster development and distribution channel as large pool of voluntary developers would contribute the software code and place the same in public domain thus removing any practical chance of selling licenses. Clearly, if a proprietary software vendor can benefit from development and distribution practices of FOSS and vice versa.

Such attempts are increasingly becoming necessary with organizations' survival in software industry becoming increasingly uncertain. Established software product vendors are threatened by reduced barriers to entry. With software product innovations happening rapidly [START_REF] Li | Why Do Software Firms Fail? Capabilities, Competitive Actions, and Firm Survival in the Software Industry from 1995 to 2007[END_REF] and leadership positions in software product industry becoming fragile [START_REF] Schmalensee | Antitrust Issues in Schumpeterian Industries[END_REF], software product industry is increasingly becoming a risky proposition with firms ending up in bankruptcy in a short span of time. For example, from 1995 to 2007, exit rate in software product industry was three times that of pharmaceutical industry and two times that of hardware industry [START_REF] Li | Why Do Software Firms Fail? Capabilities, Competitive Actions, and Firm Survival in the Software Industry from 1995 to 2007[END_REF].

Hybrid business models provide one form of innovation adopted by organizations to survive in such troubled environment [START_REF] Campbell-Kelly | The Move to the Middle: Convergence of the Open-Source and Proprietary Software Industries[END_REF]. Such merging represents number of challenges. How can organizations combine two approaches that were designed to be incommensurable? And are there any common patterns in such hybridization? These questions were the starting point of the study

Hybrid Business Models

Before we explain challenges in operationalizing hybrid business models, it is important to elaborate on notion of hybrid business models. Hybrid business models form a special class of business models. Software product business models are often divided into four categories: product development, product distribution, revenue model, and maintenance [START_REF] Rajala | A Framework for Analyzing Software Business Models[END_REF]. A business model hence can be treated hybrid if one or more its dimensions combines practices from both open source and proprietary software ecosystems.

Commonly reported example is dual licensing model where software is released under multiple editions with each edition governed by different licensing norms [START_REF] Välimäki | Dual Licensing in Open Source Software Industry Systemes d´Information et Management[END_REF]. However we observed that most organizations adopted a single licensing approach. The generic form of such business model can be described as follows.

The software was available under multiple editions, each edition governed by the same licensing norms but different in functionality and support. The low-cost edition (often termed as community edition) was available for free and provided what one respondent called commodity functionality. The professional edition on the other hand extended such commodity functionality through extensions and contractual agreements for service provision. Most organizations studied had developed partner networks for providing services. Partners also participated in developing specific e x t e n s i o n s w h i c h w e r e a l s o p a c k a g e d w i t h p r o f e s s i o n a l e d i t i o n s o r c o u l d b e purchased separately. The professional edition could be bundled with such partnerdeveloped and at time proprietary editions owing to the terms of the customized permissive licensing. Users could avail professional edition on the basis of subscription. In the next two sections, we describe common patterns and challenges in operationalizing such business models.

Research Methodology

Owing to the contextual adherence of the phenomenon, we chose case study as the research methodology. Case study was adopted as research methodology. In disciplines such as medicine and law, case study research has been the most favored mode of investigation while organizational and social sciences, case study research is gaining acceptance [START_REF] Lee | A Scientific Methodology for MIS Case Studies[END_REF][START_REF] Eisenhardt | Building Theories from Case Study Research[END_REF][START_REF] Yin | Case Study Research: Design and Methods[END_REF]. The increasing importance of case study research as methodology is rooted in its potential to expose phenomenon and researcher to each other in myriad of empirical avenues that otherwise are not possible through positivistic paradigm.

Case study research is suitable under certain conditions only. According to [START_REF] Yin | Case Study Research: Design and Methods[END_REF], case study research is appropriate to investigate a phenomenon within its real-life context, when the investigator has little control over the events. As the goal of the study was to expose trends and challenges experienced by organizations in operationalizing hybrid business model, it was hence imperative to examine hybrid business model in its context. Therefore, a case study method was chosen as the most appropriate approach for this research.

Before any case study endeavor is undertaken, important considerations have to be handled. In the subsequent sections, treatment of these considerations in the context of the study is explained. First issue is about the number of cases. As outlined by [START_REF] Yin | Case Study Research: Design and Methods[END_REF], multiple case study approach is suitable for a theory development exercise where each case is a separate experiment in itself. Each case compares the theoretical understanding and the new empirical evidences. On the other hand, single case study is suitable when phenomenon requires studying a unique, critical or revelatory case. Because we were interested in pattern identification, multiple case study approach was considered as the ideal choice. The cases were chosen as per replication logic (all cases having a hybrid business model), to improve on external validity of the findings.

Second consideration in case-based research pertains to the case selection criteria. Explicit mention of case selection criteria is key indicator of rigor in case research [START_REF] Yin | Case Study Research: Design and Methods[END_REF]. Overarching selection criteria for this study were presence of a hybrid business model associated with a software product. The idea was to ensure the fit of the case with the research questions at hand.

Thirdly, case study protocol was used to guide data collection. We wanted to capture data on operationalization of hybrid business model. Hence the protocol was developed accordingly with most questions began with 'how' and 'why'. We used interviews as the primary data collection vehicle. It is considered particularly suitable for the interpretive case studies [START_REF] Walsham | Interpretive case studies in IS research: nature and method[END_REF]. Due to geographical limitations, interviews were conducted and recorded through video conferencing. Later these interviews were transcribed. We also used data from the published news articles and social media platforms.

We began the analysis process with open coding. The interview transcripts were coded for either operational practice of hybrid business model or an indicator of challenge in doing so. Once the open coding was done, we tried to examine the linkage across codes to identify axial linkages across coded excerpts. The exercise ended up with a set of operational practices and challenges related to hybrid business models.

Summary of the Cases

A total of six cases were studied. The cases belonged to four different product categories. One of the cases was an enterprise resource planning software. Three belonged to the content management system product category. One belonged to the business process management system while the last one was a customer relationship management system. The organizations were geographically diverse as well. Two cases were from mainland Europe, one was located in Scandinavian Europe, one was from South American continent, and two were headquartered in USA.

In all the cases, one of the top members of top management (preferably CEO) was interviewed. The idea was to get an overall description of the business model. To understand the operationalization, personnel from business development, and product engineering were also interviewed. As external resources such as community members play a key role in open source approach, personnel from community management were also interviewed. Lastly, to understand the distribution management, personnel responsible for managing partner network was interviewed.

In some cases, single person represented more than one functions. So he/she was contacted for collection data on all relevant dimensions. A total of 23 full-length interviews were conducted across 6 cases. The primary data was substantiated with secondary collected through secondary sources such as forum interactions between different stakeholders, product roadmap document, and release policy document.

Hybrid Business Models: Patterns

OSS is largely governed by two forms of licensing: permission and restrictive [START_REF] Lerner | The Scope of Open Source Licensing[END_REF] [START_REF] Lerner | The Scope of Open Source Licensing[END_REF]. In all the cases, we observed adoption of customized permissive licensing. Such licensing allowed community members freedom to choose licensing of their respective contributions. As one of the respondents stated it acts as an incentive for commercial organizations participating in the community. The licenses however were customized to provide legal protection to the brand name of the product. Common permissive licenses that were used as basis included Mozilla Public License and Lesser GNU Public License.

Secondly, we observed community to be made up of multiple segments. Unlike the traditional notion of community as a uniform social collection of developers, hybrid business model fostered communities made up of business partners, customers of professional edition, customers of free edition, and partners of free edition. Each segment participated in development of product with distinct motivations.

Technological proximity to open source was another pattern observed. Most organizations studied did not start out with hybrid business model. It emerged later as suitable way of doing business. However, organizations already were technologically closer to open source than proprietary with software product being created using open source technologies. As stated by most of the interview respondents, migration to hybrid model was therefore a natural choice.

Phased release was another common feature. Organizations would often release their community edition before corresponding release of professional edition. This allowed the organizations to capture the user-feedback (for example, bug reports and feature requests) which was often incorporated for the professional edition, along with few more extensions.

Finally, most organizations were attempting to create ecosystem around their products. Towards this, they had developed a customized development and distribution platform. These platforms provided infrastructure for developing and hosting extensions for sales. Customers could search specific extensions through enhanced search functionality. In other words, entire ecosystem of the product could be developed around such platforms.

Hybrid Business Models: Challenges

Operationalization of such business models however involved certain challenges. Owing to the dichotomy of mixing open source with proprietary, most of these challenges were dichotomous.

Software products were released in multiple editions. Some of these editions were freely available while others came at a cost. Intended purpose of each edition was defined. The community edition was meant to achieve a faster rate of diffusion and to gather customer's feedback before releasing the professional editions. Usually community editions were not meant to be used in mission critical applications. Accordingly, organizations had to devise functional coverage of each edition. This functional differentiation across editions had to be wide enough for community edition users to perceive professional edition as valuable and upgrade. On the other hand, it also had to be narrow enough for community edition to qualify as a usable piece of software. Naturally, a community edition that did not have critical pieces of functionality would not allow for intended faster rate of diffusion. We observed that attempts to resolve this challenge led to differences of opinions between community members and the organization. We term this challenge as an extends the concept of selective revealing [START_REF] Henkel | Selective Revealing in Open Innovation Processes: The Case of Embedded Linux[END_REF].

We have already posited segmented structure of community as a outcome of hybrid business models. In such segmented communities, different segments participated for different motivations. The challenge was to coordinate product development and distribution across these segments. For example, partners with interests in community edition only could package the edition and under certain licensing terms could also release the same as their own product. As one of the respondents stated, this led to a fractured user-base where multiple versions of the same editions were floating around in the market. One may be tempted to install strong appropriation regimes and take control of the product development and distribution. However, this would significantly take away benefits of hybrid business model. We term this challenge as segmented meshing where different community segments need to be meshed into a single entity. We observed adoption of a customized permissive license as a common approach to tackle this situation. Such a license provided intellectual property protection for the brand of the software product but still allowed community members to add proprietary functionality.

Conclusion

The paper focuses on emergence of hybrid business model in software product industry. It also provides some patterns and challenges in operationalizing such business models. The findings are based on data collected for a larger empirical study carried out as first author's doctoral work. Authors hope that reported findings would act as quick-start guidelines for software product organizations to looking to adopt hybrid business models.


de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Development Style of Open Source and Econmies of Connection

Keisuke TANIHANA 1 , and Tetsuo NODA 1 1 Faculty of Law and Literature, Shimane University, Matsue, Japan {keisuke_tanihana, nodat}@soc.shimane-u.ac.jp

Recently, Open Source Software (OSS) becomes indispensable resource in the information service industry. Moreover, OSS development also consists of the contribution and participation by information service enterprises. While the development of OSS style has spread, participation of information service enterprises toward OSS has also increased. In our research, we will consider the relation between OSS use and its effect in terms of economic theory.

As is noted in [START_REF] Coase | The Nature of the Firm[END_REF], when enterprises trade through a market, it is necessary to collect the information about goods, search a partner, etc. In other word, uncertainty which arises from trade through a market will cost enterprises. This is known as "Transaction Cost". We think that computerization decreases their transaction cost. As a result, computerization will cause enterprise's business strategy from closed style toward open one. The change of business strategy, economies of scale is the strategy of pursuing economy of scale. This strategy will have closed and independent management style. On the other hand, as is noted in [START_REF] Miyazawa | The distribution system in a highly informative society[END_REF], "Economies of Connection" is the viewpoint that many companies cooperate and consider the synergistic effect of technology or know-how as important. The computerization, such as the Internet, serves as this background.

In "Bazaar Model", a develop participant is not limited but a development process is exhibited generally. The developer can be connected by the Internet worldwide. Computerization such as the Internet enables source code to spread worldwide. Therefore these "Bazaar Model" will suggest "the economies of connection".

Under open strategy, technology and know-how will combine with each other beyond boundary of each enterprise. Chesbrough (2003) has been considered this open strategy as "Open Innovation" in terms of R&D activity. OSS is developed in community which is an organization outside an enterprise. Since OSS is released free, it is a kind of public goods. Under "Open Innovation", it is important for an enterprise to combine own development project with OSS in order to create new value and to enhance its competitiveness. "Open Innovation", needless to say it is equivalent to the "Bazaar Model". We think that the business model which uses OSS is based on "Open Innovation". This process enables enterprise to decrease its development cost by replacing own resources and OSS, or "connecting" both.


FLOSS Education: Long-Term Sustainability Gregorio Robles, Jesús M. González-Barahona, Wouter Tebbens To cite this version: Gregorio Robles, Jesús M. González-Barahona, Wouter Tebbens. FLOSS Education: Long-Term Sustainability. 8th International Conference on Open Source Systems (OSS), Sep 2012, Hammamet, Tunisia. pp.400-400, 10.1007/978-3-642-33442-9_46. hal-01519069

FLOSS Education: Long-term sustainability

Gregorio Robles 1 , Jesús M. González-Barahona 1 , and Wouter Tebbens 2 1 GSyC/LibreSoft, Universidad Rey Juan Carlos {grex,jgb}@libresoft.es 2 Free Knowledge Institute wouter@fki.org

Summary

Learning in any environment has undergone major changes in recent times. Many of these changes are closely related or are similar to processes or solutions found traditionally in Free/Libre and Open Source (FLOSS) environments: peer to peer relationships, telematic support, use of new technologies, etc. [START_REF] Weller | The Digital Scholar: How Technology Is Transforming Scholarly Practice[END_REF] The purpose of this workshop is to bring together free software experts to discuss challenges that we face in the educational world at present and and that we will face in the future and how they can be undertaken from a FLOSS perspective. A public call for papers has been made resulting in various contributions, as follows: Based on this contributions and on the over 20 registered participants, a series of topics will be discussed, and conclusions and remarks will be collected and published. The contributions to and outputs of the workshop can be downloaded at the workshop website at http://libresoft.es/flossedu. This workshop is supported by the eMadrid network of Excellence (S2009 TIC-1650) and by the Free Knowledge Initiative.


Michael Adeyeye

Oluyomi Kabiawu

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

1 http://www.ngportal.com/micadeyeye/index.php/2009/09/13/projects-videos/

Open Source Software in Research and Development (Guidelines for Postgraduate Students)

Michael Adeyeye 1 , Oluyomi Kabia 2 1 Cape Peninsula University of Technology, South Africa 2 University of Cape Town, South Africa adeyeyem@cput.ac.za , oluyomi.kabiawu@uct.ac.za Two case studies were used in our study; they were two postgraduate projects that exploited FoSS but lacked proofs of concept. In addition, a survey was also conducted to investigate the level of usage of OSS in research. The sample population was quite small; hence, there should be some level of caution in generalizing the knowledge level of students as represented by the survey. 39 respondents out of the total 65 respondents said their works require prototype development; 26 respondents needed to develop their works ground-up, while 39 respondents needed to modify existing projects/codebases; 52 respondents leverage OSSD in their works, while 13 respondents do not; 40 respondents have access to sample/similar projects on the Internet, while 25 respondents do not; 35 respondents consider themselves proficient with the tools they use, while others are not. Lastly, the numbers of respondents that chose conceptualization, identification of tools, implementation and evaluation of a research work as the most challenging aspect of the research were 8,16,15,26, respectively.

In the two case studies, the researchers were required to present a proof of concept and access to the source code of their works. However, the researchers could not meet up with the requirements. In addition, they could hardly pitch their contributions to the existing body of knowledge and evaluate their works using comparisons. An exemplary OSS project that followed the core principles required in using OSS in a research is TransferHTTP+CAS. The work claimed that content sharing, session handoff and their control services in the Webbrowsing context can encourage collaboration and interaction among the Internet users. The work contributed to the state-of-the-art in its domain by comparing the implemented prototypes 1 with emerging industry works, such as WebRTC, Google Wave, and Open APIs.

The OS project components that a researcher should be aware of include: the project community, its developers, source code and license(s). The first author considered all the components during his work to produce the artefacts and show a proof of concept. As a result, this paper proposes the following guidelines for using open source in research: visiting related project and wiki websites for information, joining their communities of developers; providing access to one's source code so that different individuals can contribute in different ways to the cohesive whole; and taking cognisance of the license used by the software that is being extended.


Victor Kuechler
email: kuechlej@onid.orst.edu

Claire Gilbertson
email: claire.gilbertson@gmail.com

Carlos Jensen
email: jenseca@eecs.orst.edu

Gender Differences in Early Free and Open Source Software Joining Process

Keywords: joining process, diversity, mailing lists

With the growth of free and open source software (FOSS) and the adoption of FOSS solutions in business and everyday life, it is important that projects serve their growingly diverse user base. The sustainability of FOSS projects relies on a constant influx of new contributors. Several large demographic surveys found that FOSS communities are very homogenous, dominated by young men, similar to the bias existing in the rest of the IT workforce. Building on previous research, we examine mailing list subscriptions and posting statistics of female FOSS participants. New participants often experience their first interaction on a FOSS project's mailing list. We explored six FOSS projects -Buildroot, Busybox, Jaws, Parrot, uClibc, and Yum. We found a declining rate of female participation from the 8.27% of subscribers, to 6.63% of posters, and finally the often reported code contributor rate of 1.5%. We found a disproportionate attrition rate among women along every step of the FOSS joining process.

Introduction

Although a similar percentage of men and women receive bachelor's degrees today [START_REF]The Condition of Education 2011[END_REF], there is a significant difference in the percentage for computer science and engineering. Only 25% of IT workers are women [START_REF]About:Fact Sheet[END_REF], and women earn around 18% of IT-related bachelor's degrees [START_REF]Women, Minorities, and Persons with Disabilities in Science and Engineering[END_REF]. A smaller percentage of women actively participate in FOSS, less than 2% [START_REF] David | The Free/Libre/Open Source Software Survey for 2003[END_REF][START_REF] Ghosh | Free/Libre and Open Source Software: Survey and Study, Part 4: Survey of Developers[END_REF][START_REF] Lakhani | The Boston Consulting Group Hacker Survey[END_REF][START_REF] Nafus | Deliverable D16: Gender: Integrated Report of Findings[END_REF][START_REF] Robles | Who Is Doing It? A research on Libre Software developers[END_REF]. Why do so few women participate in FOSS, and what can attribute to these differences? FOSS projects need to attract and maintain active users. The volunteer nature of FOSS and the general lack of financial incentives to participate lead to high turnover, and the need for a continuous influx of developers [START_REF] Ye | Toward an Understanding of the Motivation Open Source Software Developers[END_REF]. The transition from user to contributor begins on a mailing list. Mailing lists are at the heart of all communication and discussion in FOSS projects, and therefore at the heart of all FOSS projects. Its archival nature also preserves past, present and future design and implementation decisions, as well as the project's evolving culture.

Joining a FOSS project often begins with lurking or silently observing the community by subscribing to its mailing list. Since the majority of communication occurs on mailing lists, we need to understand how this first step affects newcomers' motivations and future behavior.

A previous study found that almost 80% of newbies received a positive reply to their first post, and those who received a timely response were more likely to contin-

Related Work

The influence of FOSS has grown over the last decades and shows that FOSS software can be more reliable and perform better than proprietary software [START_REF] Wheeler | Why Open Source Software/Free Software (OSS/FS, FOSS, or FLOSS)? Look at the Numbers![END_REF]. FOSS encompasses a great variety in projects, from the highly technical Linux Kernel, supporting operating systems like Ubuntu, Fedora and Debian, to end-user applications like Android, Wikipedia, and business solutions like Open Office and the GIMP.

FOSS is a volunteer-driven development paradigm that brings together developers and contributors from around the world. Only 30% of developers are paid [START_REF] David | The Free/Libre/Open Source Software Survey for 2003[END_REF][START_REF] Lakhani | The Boston Consulting Group Hacker Survey[END_REF] and what motivates contributors can be both intrinsic and extrinsic [START_REF] Bitzer | Intrinsic Motivation in Open Source Software Development[END_REF][START_REF] Lakhani | The Boston Consulting Group Hacker Survey[END_REF]; a majority of FOSS developer surveys find that contributors are motivated by the opportunity to improve their programming skills [START_REF] David | The Free/Libre/Open Source Software Survey for 2003[END_REF][START_REF] Lakhani | The Boston Consulting Group Hacker Survey[END_REF][START_REF] Robles | Who Is Doing It? A research on Libre Software developers[END_REF]. Working on FOSS allows users of any age, education, or experience level to gain valuable skills. One study shows that a significant number of people "wished to improve software products for other developers," [START_REF] Ghosh | Free/Libre and Open Source Software: Survey and Study, Part 4: Survey of Developers[END_REF] and another finds that 77% of respondents thought giving back to the community is very important [START_REF] Lakhani | The Boston Consulting Group Hacker Survey[END_REF]. A passionate user may also start their own project because he or she has an unaddressed interest or need that could be met by a FOSS solution [START_REF] Raymond | The Cathedral & the Bazaar: Musings on Linux Open Source by an Accidental Revolutionary[END_REF]. FOSS projects are also expanding to address humanitarian needs, which attract a different kind of developer [START_REF]The Humanitarian FOSS Project[END_REF].

Surveys of FOSS developer demographics, although outdated, show that FOSS communities are 98% male [START_REF] David | The Free/Libre/Open Source Software Survey for 2003[END_REF][START_REF] Ghosh | Free/Libre and Open Source Software: Survey and Study, Part 4: Survey of Developers[END_REF][START_REF] Lakhani | The Boston Consulting Group Hacker Survey[END_REF][START_REF] Nafus | Deliverable D16: Gender: Integrated Report of Findings[END_REF][START_REF] Robles | Who Is Doing It? A research on Libre Software developers[END_REF] with an average age of 27 [START_REF] David | The Free/Libre/Open Source Software Survey for 2003[END_REF][START_REF] Ghosh | Free/Libre and Open Source Software: Survey and Study, Part 4: Survey of Developers[END_REF][START_REF] Lakhani | The Boston Consulting Group Hacker Survey[END_REF][START_REF] Robles | Who Is Doing It? A research on Libre Software developers[END_REF]. On average, FOSS developers are highly educated with 30% having at least a bachelor's degree and 10.6% a graduate degree. Most contributions are from Western Eu-rope and the United States. Many FOSS communities have taken steps to address inequalities by starting different programs aimed at recruiting and retaining underrepresented groups. While some projects acknowledge the importance of different types of diversity, most focus on recruiting and retaining female contributors.

There are several text-based forms of communication used in FOSS projects to maintain project awareness. Internet Relay Chat (IRC) is used for real-time communication. Asynchronous communication in the form of blogs, wikis, forums, and bugtracking systems archive project discussions, documentation and project news. These channels tend to augment mailing lists, the primary medium used for interaction in FOSS communities [START_REF] Gutwin | Group Awareness in Distributed Software Development[END_REF]. This tool allows everyone to participate asynchronously, keep up-to-date with new developments, bounce ideas back and forth, and encourage discussions about the project. Gutwin et al. not that "there is a strong culture of 'making it public ' [in FOSS] where developers are willing to answer questions, discuss their plans, report on their actions, and argue design details, all on the mailing list" [START_REF] Gutwin | Group Awareness in Distributed Software Development[END_REF].

Several studies focus on mailing list activity and its influence on future participation. Lampe and Johnston examine the Slashdot community over a one-month period and found that more than 55% of newcomers made only one comment and those that received no feedback were less likely to continue to comment [START_REF] Lampe | Follow the (Slash) dot: Effects of Feedback on New Members in an Online Community[END_REF]. Krogh et al. studied Freenet's developer list for one year and find that of successful joiners, over three-quarters started a new thread, and that the 10% of participants who never received replies dropped out [START_REF] Krogh | Community, joining, and specialization in open source software innovation: a case study[END_REF].

Jensen et al. focus on new users instead of developers [START_REF] Jensen | Joining Free/Open Source Software Communities: An Analysis of Newbies' First Interactions on Project Mailing Lists[END_REF]. They observe the first posts made by new users and how existing members greeted them. After examining the newbie's tone, nationality, and gender they find that newbies received equally prompt replies, but flaming or aggressive replies were not uncommon. They also argue that because this behavior is public it could have far-reaching effects: "Thus, while OSS participants were generally polite to newbies, it is possible that newbie expectations and perceptions of politeness could be colored by how the regulars engage with each other" [START_REF] Jensen | Joining Free/Open Source Software Communities: An Analysis of Newbies' First Interactions on Project Mailing Lists[END_REF]. In other words, lurkers may be pushed away based solely on observed negative behavior on mailing lists.

Mailing lists keep an exact record of public discussions. "Mailing lists allow people to find out who the experts are, simply by initiating a discussion: because the messages go to the entire group, the 'right people' will identify themselves by joining the conversation." [START_REF] Gutwin | Group Awareness in Distributed Software Development[END_REF]. This makes mailing lists a great source of information, and subscription logs let us see not only who uses the list, but also who is lurking to test the waters.

FOSS communities are hierarchical in nature and the Onion Model in Figure 1, developed by Ye and Kishida [START_REF] Ye | Toward an Understanding of the Motivation Open Source Software Developers[END_REF], shows a very simplistic hierarchy of roles in FOSS communities. Newcomers often begin at the outer layers as passive users who may have subscribed to a mailing list or IRC channel. It is difficult to understand lurker behavior, in part due to the difficulty determining who is a lurker. Nonnecke and Preece examined lurking as a transitional phase needed in order for users to feel comfortable contributing to a technical discussion. They find that the transition could last anywhere from weeks to months, but they did not examine the effects of gender on this process [START_REF] Nonnecke | Lurker Demographics: Counting the Silent[END_REF]. Other studies, mostly of discussion forums and mailing lists, show lurkers make up from 50% [START_REF] Nonnecke | Lurker Demographics: Counting the Silent[END_REF][START_REF] Soroka | We can see you: a study of the community's invisible people through ReachOut[END_REF] to 90% [START_REF] Katz | Luring the Lurkers[END_REF][START_REF] Mason | Issues in virtual ethnography[END_REF] of an online community. Lurking is recommended to newcomers in FOSS communities as a method to learn the current state of the project, who to talk to, what channels of communication to use, and project culture.

Methodology

Data Collection

The Oregon State University Open Source Lab (OSL) hosts over 150 projects and "distribute software to millions of users globally" [START_REF]About OSUOSL[END_REF]. The OSL acted as agents in gaining access to mailing list data and user subscription logs, with projects' consent.

We selected active projects with many users and high traffic.

We also asked numerous other communities (not hosted at the OSL) for access to their data, with mixed results; some communities were willing to share their data but did neither use mailing lists nor keep subscription logs. Some were wary about sharing user's information, seeing potential privacy issues. Without a complete set of message files and corresponding logs, we could not use these projects for comparison.

The data we collected was all from mature, highly technical projects. These data sets spanned at least 500 days and have between 73 and 944 subscribers per mailing list.

3.1.1

Project Descriptions We used data from six FOSS projects: Buildroot, Busybox, Jaws, uClibc, Yum and Parrot. From these we selected eleven mailing lists: Buildroot, Busybox, Jaws, Jaws-announces, Jaws-bugs, Jaws-commits, Jaws-developers, Jaws-general, uClibc, Yum, Yum-devel, and Parrot. Table 1 shows the time coverage of each mailing list.

Buildroot is a technical project that helps users install Linux on embedded systems [6]. Buildroot has one mailing list and a very active community that communicates about commits, questions, bug reports, and patches.

Busybox is a highly technical project that merges numerous UNIX utilities commonly found in GNU fileutils, shellutils and others [START_REF]About OSUOSL[END_REF], specifically for embedded systems [START_REF] Andersen | BusyBox[END_REF]. This project has one mailing list, busybox, which is the main source of communication and the suggested medium for communicating with the community.

Jaws is a technical framework and content management system (CMS) that encourages users to develop their own modules. We included this project because it was smaller than others and appeared to cater to a broader user base (anyone with web authoring skills). This project contained multiple mailing lists, which we combined to more effectively compare with the others. We analyzed at Jaws, Jawsannounces, Jaws-bugs, Jaws-commits, Jaws-developers, and Jaws-general.

Parrot is designed to compile byte code for dynamic languages. Parrot's website directs users to the parrot-dev mailing list for development and discussion. Other documentation sends new users to parrot-users, which is practically unused [START_REF]Users & Documentation[END_REF].

uClibc or the "microcontroller C library" [START_REF] Andersen | UClibc[END_REF] is a smaller alternative to the GNU C Library, and almost all applications supported by glibc are compatible. uClibc has two mailing lists-one for discussion and development (uClibc) and another for source commits (uClibc-cvs), which was dedicated to different files for bug patches and other code changes. We chose to examine the list for discussion and development since this is where new users are most likely to interact with the community.

Yum or "yellowdog updater modified" is a package management system that provided tools to automate software installation, upgrading, configuring and uninstallation [START_REF]Yum Package Manager[END_REF]. Yum works with RPM-based Linux distributions. This project had four mailing lists: rpm-metadata, yum, yum-commits, and yum-devel. We chose to examine yum-devel and yum since these mailing lists were more active and included a variety of users, including newcomers. The commits list mostly included code modifications and updates with few questions or other communication. The rpmmetadata list was not available at the time.

Error! No text of specified style in document.

Table 1. Time period of each mailing list subscription log per project

Data Parsing

Using documentation from QMAIL [START_REF]Qmail Mirror Selection[END_REF], we created a Java program to parse the MBOX files and subscription logs to extract the following data (when available):

 The program iterated over users in the subscription logs for each MBOX file and counted the number of posts made by that person. When the users signed up for the list they could choose to add a first and/or last name in addition to the required email address. We used this information to determine the gender of the subscriber. When available we parsed this information from the logs. When this was not available, we attempted to extract a name from the email address. We used pattern matching to find possible names using the following patterns: First.last@... First_last@... First-last@... If these schemes did not offer a match, we added the entire username portion of the email to the first name field.

Projects

We recorded users' mailing list subscribe and unsubscribe dates; some users subscribed and unsubscribed multiple times. In these cases, we treated the first subscription as the join date and the last un-subscription as the unsubscribe date. Some users did not have a subscription or unsubscribe date in the logs. Since we only had data for approximately two years for each list, some long-time subscribers did not join or leave during that time period. For these we assigned a join and leave date based on their earliest and latest activity. For this study, we focused on newcomer behavior and lurking, so these experienced subscribers were less of an interest. We calculated the total hours spent on the list for each subscriber.

For each user, we counted how many posts, if any, he or she contributed. We did not thread the posts or group them in any way; each post whether a reply or a new topic was counted. For each poster, we recorded the date of their first and last post. From these data points, we determined the amount of time they lurked before posting and their posting frequency.

Using data from the U.S. Census, we matched names to lists of the most common female and male names. We identified 666 users using this process. Some common names are used for both women and men, for instance Alex, Robin, or Morgan. In these cases, we looked at the frequency of use for each gender for each name. If there was a disproportionate use in one gender, we assigned all users with that name to that gender. For example, Alex is ranked as the 63 rd most common name for males in the United States, and 990 th for females. Therefore, all Alex's were assumed to be male. In cases where the rankings were close, we put the user in an "unknown" category.

Next, we manually filtered obvious "non-names" such as thepirate@yahoo.com and identified possible names that did not make it on the list of common U.S. names, or names that did not follow the aforementioned patterns. These names were then shown to other researchers and international students via a web application. These "reviewers" could assign a gender, mark the email address as "not a name," label it as an "unknown" for ambiguous names, or skip the name. We asked reviewers to only assign a sex where they were 100% certain. In the end, we identified 1594 users as either male or female, and were left with 975 unidentified users. Grouping unknown and "not a name" together, 41.66% of subscribers were unidentifiable. While this is unfortunate, we believe this represents a good effort and the users identified were a significant and representative sample of the overall community.

Within this dataset were many extreme values; many users contributed little, and a few users contributed a lot. To normalize the data we arranged the users in each mailing list by the number of posts. If we found a jump of more than an order of magnitude between a user and the next highest contributor, we set this as a cutoff point and excluded the user from our set. We did this to prevent a handful of very frequent posters skewing our statistics. Table 2 shows the number of users excluded from each mailing list.

In addition to treating each list separately, we combined all in order to compare data across FOSS mailing lists. As some of the projects are commonly used jointly Error! No text of specified style in document.

(Busybox, Buildroot, and uClibc) and projects have multiple lists (e.g., Yum and Yum-devel) it is possible that users were counted multiple times in these comparisons.

Results

This section explores our finding and relates them to our research questions. First, we begin by looking at the gender of the subscribers. Secondly, we examine the time subscribers spend lurking before their first post. Next, we present the posting frequency by gender of subscribers and lastly, inspect the amount of time users subscribe to the mailing lists.

R1: Gender of Subscribers and Posters

Given that women participate at a disproportionately low rate, even by IT standards, can we determine how early in the FOSS joining process these differences emerge?

We know from the work of Jensen et al. that by the time a user posts, only 3% of posters are women [START_REF] Jensen | Joining Free/Open Source Software Communities: An Analysis of Newbies' First Interactions on Project Mailing Lists[END_REF].

In order to answer this question, we counted the number of women and men who subscribed to each mailing list; we found 1769 men and 162 women. 91.73% of all subscribers were male and 8.27% were female. This was more than a 50% decrease when compared to the 20% rate of women in IT, but still much higher than the population of women who contributed code to FOSS projects. Table 3 shows a breakdown of our findings. Are women as likely to participate (post) as men once subscribed? Table 4 contains an overview of the data. The percentage of female posters ranged from 0 to 10.58% of the total number of subscribers, with an average of 6.63%. This was a statistically significant decrease from the expected value of 8.37% of subscribers (χ2=5.30, p= 0.0213). 110, or 67.90% of women never post after joining a mailing list. In comparison, 1065, or 59.30 % of men never posted after they joined a mailing list.

Posting Frequency

Do women post as frequently as men on these lists? In order to determine the number of hours between posts, we examined the time between a user's first and last post and divided this number by the number of posts for that particular user, see Equation 1.

We looked at 563 users who posted at least twice. Table 5 shows the average posting frequency for each list, and for the combined data set.

Table 5. Average posting frequency of men, women, and unknown per mailing list

(1)

Equation. 1. Equation used to calculate the average number of hours between posts

The majority of our lists (excluding Jaws and Yum) showed that men and women posted equally as often. Statistically we did not find any significant difference be- tween men and women here. We broke separated this set of data into more categories by looking at users who posted at least once, more than once, more than twice, etc.

Lists

Fig. 2. Posting frequency by hours between posts

We also observed that as we look at the "stickiness" of the community, which is measured by continued participation on the mailing list, the participation of women decreased. Women make up about 6% of posters who submitted between 1 and 3 posts, about 4% of those who submitted between 4 and 8 times, about 2% of those who submitted 9 or 10 times, and 1% submitted more than 10 times. It is interesting to see a near linear trend in the data. Statistical tests show that the proportion of women posters decreased over time (χ2 = 30.346, p= 0.0107). This shows that over time women posted less often, which demonstrates that somewhere along the line women are discouraged from continued participation.

Lurking Habits

The time spent observing a group before contributing is a formative experience that can encourage or discourage users. In most cases, women lurk less than men (note, no female posters were found in the Jaws data set and so it was excluded from the study).

The Parrot mailing list turned out to be an extreme outlier; women lurked 2,235.00 hours, which was more than 50% longer than men who lurked 1,406.47 hours. The data from this Parrot (for both men and women) was an extreme outlier, with averages more than 2 standard deviations from that of the other lists. Parrot was therefore excluded from the analysis. A t-test analysis of the two populations (excluding Jaws and Parrot) showed no statistically significant differences in the mean lurking times (p-value=1.72).

Error! No text of specified style in document.

Subscription Length

Do men and women participate (stay subscribed) for similar lengths of time? Interestingly, women and men subscribed for a similar length of time (except in Yum-devel and Parrot), and there were no statistically significant differences. Jensen et al. [START_REF] Jensen | Joining Free/Open Source Software Communities: An Analysis of Newbies' First Interactions on Project Mailing Lists[END_REF] found that about 3% of posters in their sample were women. However they focused on a variety of attributes, and gender was not the primary focus. As a consequence, their data had a much larger number of unknown participants, which may have skewed their data. We spent more time manually identifying users as male, female or unknown. We believe our results are in line with other studies that found between 1.5% and 2% of code-contributors are female [START_REF] David | The Free/Libre/Open Source Software Survey for 2003[END_REF][START_REF] Ghosh | Free/Libre and Open Source Software: Survey and Study, Part 4: Survey of Developers[END_REF][START_REF] Lakhani | The Boston Consulting Group Hacker Survey[END_REF][START_REF] Nafus | Deliverable D16: Gender: Integrated Report of Findings[END_REF][START_REF] Robles | Who Is Doing It? A research on Libre Software developers[END_REF]. We know that the FOSS joining process is complex and the commitment time needed to move into a developer role often excludes newbies with family or social commitments, something that may disproportionately affect women. Building upon the findings in Jensen et al. [START_REF] Jensen | Joining Free/Open Source Software Communities: An Analysis of Newbies' First Interactions on Project Mailing Lists[END_REF], we found that 8.39% of the FOSS mailing list subscribers were women. This was significantly lower than the 20% of women in IT. In fact, we discovered an attrition rate throughout the joining and lurking process. Figure 6 shows the decreasing participation of women in FOSS communities.

Fig. 6. Women in IT and FOSS

Where and why do gender differences emerge? Joining a mailing list is the first step and location in the FOSS joining process that we can collect data. There are however, other non-documented steps: exploring a project's website, scanning documentation, downloading source code, chatting on IRC, or exploring forums, messages boards or wikis. This leaves a variety of interactions prior to, or in parallel with, the mailing Error! No text of specified style in document. lists that may also influence women to turn away from FOSS projects. Of those who subscribe to a mailing list, 67.90% of women and 59.30% of men never post, and in our sample only 6.63% of posters were identifiable as women. We found that the number of women sequentially decreases to just over 1% as the number of posts grow to 10, which is in the range of what has been found by other studies.

Over the last ten years, there has been a push to increase the amount of contributor diversity in FOSS. FOSS projects like Dreamwidth have also appeared and managed to attract a 75% female contributor base [START_REF] Robert | Standing out in a Crowd[END_REF]. However, from our data we cannot see that these efforts are having a strong global effect. More data is needed to determine this however, since the last major FOSS developer survey was performed in 2006 [START_REF] Nafus | Deliverable D16: Gender: Integrated Report of Findings[END_REF].

On average, men posted every 341.70 hours and women 306.90 hours. This shows us that although there is a high attrition rate among women, they are not being excluded from the FOSS conversation. That is not to say there are not many situations in FOSS where women have felt uncomfortable, excluded or specifically targeted in a demeaning way [START_REF] Fisher | Unlocking the Clubhouse: the Carnegie Mellon Experience[END_REF]. However, if all women were being forced away, we would expect women to post less frequently than males. What is interesting is that along every step of the joining process, we lose a disproportionate number of women. However, given the small sample of women and our choice of projects, it is difficult to draw statistical conclusions about the causes.

The all subscription logs varied in duration. In particular, Jaws and Parrot covered about 1,000 days, and we found that, on average, users from these two lists subscribed longer than users on other mailing lists, which covered less than 700 days. On nearly all of the lists, women subscribed for slightly less time than males, however we did not find any statistically significant correlation between gender and duration of subscription.

After examining posting statistics, we found that the only statistically significant differences between men and women were the average number of posts and the number of women who kept posting declined more sharply than men. We did not examine the type of messages posted, and it is possible that many users were not interested in joining the project, but rather asked one-time questions. It is unclear why women would be more likely to fall into this category than men. Adding a message-type category to this line of investigation would be beneficial. In addition, the projects we chose are highly technical and therefore comparing them with less technical projects may yield other results.

What drives women away from FOSS in disproportionate numbers? After disproving a number of hypotheses, we are left with two likely factors: women are driven by different sets of motivations and cost-benefit tradeoffs than men or, the social dynamics in projects are more unappealing or hostile to women. As documented by Jensen et al. [START_REF] Jensen | Joining Free/Open Source Software Communities: An Analysis of Newbies' First Interactions on Project Mailing Lists[END_REF] this may not be blatant or intentional, but the kind of public flaming and aggression documented could be enough to distort participation among a small minority, such as women who may already be hesitant about how they will be received. This does not apply to all women and all projects, since there are many examples of individual success.

Most importantly, what our study shows is that this problem is likely not technical, because most women drop out of FOSS early in their project membership. Efforts to address diversity in FOSS should therefore focus on the first social experiences through programs such as mentorships and making sure novices find the help and support they need.

In the future it would be interesting to evaluate consumer or corporate-oriented projects hosted from a variety of locations. This study used data from very technical projects, which were all hosted in the same location. Also these projects had a similar number of users contributing, and incorporating smaller and larger projects may yield different and possible more representative results. A system to categorize posts from newbies might add insight about a user's intention to join a FOSS community or otherwise.

Limitations

This study used data from very technical projects of similar size, all hosted in the same location (osuosl.org). Our results may have been different if we had sampled less technical, or smaller or larger projects. Lastly, naming conventions, and the subjective nature of matching name and gender could have introduced errors. We did, however, ask reviewers to only assign a gender if they were 100% certain. Studies have shown that women are more likely to try to obscure their gender online, so our analysis may have been skewed.

Conclusions

Understanding the reasons behind the gender struggle in FOSS will lead to policies and strategies that encourage greater diversity in FOSS communities. As more companies adopt FOSS software, and FOSS projects diversify to serve a broader population, supporting community infrastructure will be a vital in addressing the issues related to the lack of women in FOSS. We studied eleven mailing lists and corresponding subscription logs from six FOSS projects, with a combined 3,310 users, of which 1,769 were males, 162 females and 1,379 unknown. We found 8.39% of subscribers were women, which is less than half of the expected 20% population of women in IT. Only 6.63% of posters were women, and the only significant difference we found, in terms of behaviors of men and women, was the average number of posts. Another important finding was the proportion of women who made frequent posts. The percentage of women who posted at least 10 times decreased to about 1%.

On average, males lurked slightly longer (390.44 hours) than females (233.12 hours) before posting to the mailing list for the first time. Also, males subscribed about 270 hours longer than women (less than 5% difference). However, we did not find any statistically significant values in these averages.

Fig. 1 .

 1 Fig.1. Onion Model of FLOSS joining process[START_REF] Ye | Toward an Understanding of the Motivation Open Source Software Developers[END_REF]

Fig. 3 .

 3 Fig. 3. Posting frequency by hours between posts

Fig. 4 .

 4 Fig. 4. Posting frequency by hours between posts

Fig. 5 .

 5 Fig. 5. Subscription length by hours on list

Table 2 .

 2 Number of outliers excluded from each data set

	Project	Buildroot Busybox Jaws Parrot uClibc Yum	Yum-	All
								devel	Lists
	Male	0	0	2	0	0	0	0	2
	Female	1	0	0	1	1	0	0	3
	Unknown	0	0	2	0	0	4	4	10
	Total	1	0	4	1	1	4	4	15

Table 3 .

 3 Number of men, women, and unknown subscribed to each mailing list

	Project	Buildroot	Busybox	Jaws Parrot	uClibc Yum	Yum-devel
	Male	556	423	48	289	218	177	58
	Female	52	29	3	27	30	17	4
	Unknown	336	243	22	382	180	166	50
	Total	944	695	73	698	428	360	112

Table 4 .

 4 Number of men, women, and unknown posters to each mailing list

	Project	Buildroot Busybox Jaws Parrot uClibc Yum	Yum-	All Lists
								devel
	Male	254	208	9	58	93	80	29	731
	Female	21	8	0	4	11	6	2	52
	Unknown	157	115	1	47	83	73	23	499
	Total	432	331	10	109	187	159	54	1282

text of specified style in document.

	Error! No
		Male	Female	Unknown	Δ	Average
		(hours/post)	(hours/post)	(hours/post	M-F	(hours/post)
	Buildroot	289.96	304.29	320.73	-14.32	301.03
	Busybox	326.31	246.67	321.74	79.64	322.76
	Jaws	168.67	N/A	N/A	N/A	168.67
	Parrot	525.33	527.50	490.61	-2.17	512.47
	uClibc	393.24	409.63	825.59	-16.39	565.80
	Yum	399.26	115.20	749.36	284.06	541.60
	Yum-devel	202.10	133.00	722.53	69.10	419.83
	All combined	341.70	306.90	495.17	34.81	395.91

adfa, p. 7, 2011. © Springer-Verlag Berlin Heidelberg 2011

Acknowledgements

Thanks are due to the HCI group at Oregon State University, OSU's Open Source Lab, and the project leaders of Buildroot, Busybox, Jaws, Parrot, uClibc, and Yum, for their willingness to participate in this study.