Sulayman K Sowe
email: sowe@ias.unu.edu

Maurice Mcnaughton
email: maurice.mcnaughton@uwimona.edu.jm

Using Multiple Case Studies to Analyse Open Source Software Business Sustainability in Sub-Saharan Africa

Amidst the debate about what sort of technology is appropriate for achieving sustainable development, Free and Open Source Software (FOSS) offers some solutions to today's technology problems for many developing countries. However, there is a paucity of empirical evidence to help us understand the potentials FOSS technologies have for small businesses in Sub-Saharan Africa. This research utilizes nine case studies data from seven African countries to find out how entrepreneurs are leveraging FOSS to help them create sustainable business based on openness. The findings show increasing awareness of the business potential of FOSS, and a business model incorporating both FOSS and proprietary software is needed to run a sustainable IT business in these countries. However, the lack of skilled FOSS developer base, the absence of appropriate policies, and poor payment habits by clients are just some of the factors affecting businesses. Other problems encountered, possible solutions to those problems and lessons to be learnt from each case study are also discussed. The research offers entrepreneurs, ICT practitioners, and policy makers the platform to understand the Why and How FOSS technologies are impacting the traditional way of doing business in Sub-Saharan Africa.

Introduction

The plethora of Free and Open Source Software (FOSS) applications available throughout the internet in projects and forges are not only having huge socioeconomic impact in many sectors in many different parts of the world, but are continuously redefining the way businesses (small and big) operate. The past few years have witnessed growing research interest in FOSS and its adoption and utilization in the business sector [START_REF] Gurbani | A case study of a corporate open source development model[END_REF][START_REF] Morgan | Open innovation in secondary software firms: an exploration of managers' perceptions of open source software[END_REF][START_REF] Watson | The Business of OPEN SOURCE:Tracking the changing competitive conditions of the software industry[END_REF]. However, research results (e.g. [START_REF] Ajila | Empirical study of the effects of open source adoption on software development economics[END_REF][START_REF] Samuelson | IBM's pragmatic embrace of open source[END_REF]) posit that in most businesses, FOSS solutions will not operate in isolation but will exist side by side with their commercial counterparts. In fact, [START_REF] Sulayman | Free and Open Source Software in Business: Implications for Policy Efficiency[END_REF] has conceptualized the "AIM Postulate", which advocates an emerging business posture towards software co-existence by moving away from (Fear, Uncertainty and Doubt/Distrust) FUD to collaborative ecosystems. The AIM postulate is grounded in the empirical observation of an emerging trend where businesses are more inclined to determine: "Where in my business operation do I need FOSS?" "How best can I leverage FOSS projects and communities to support my business?" According to AIM, software co-existence is all about i. Applying best practices (closed or open) to software process, products, and services. ii. Integrating with existing knowledge, experience, IT infrastructure, and iii. Maximizing business value and organizational learning opportunities.

However, in many companies top level management still expressed some concerns towards full-scale FOSS adoption or the integration of FOSS technologies as a key business strategy [START_REF] Goode | Something for nothing: management rejection of open source software in Australia's top firms[END_REF]. Some of the concerns are associated with the difficulty of finding the right staff and developing the competencies necessary to work with FOSS [START_REF] Morgan | Open Innovation in Secondary Software Firms: An Exploration of Managers' Perceptions of Open Source Software[END_REF]. Software support [START_REF] Van Reijswoud | Free and Open Source Software for Development: exploring expectations, achievements and future[END_REF]9], quality [START_REF] Stamelos | Code quality analysis in open source software development[END_REF], security, and the ability to integrate FOSS with existing infrastructure are also major concerns for many FOSS entrepreneurs.

The trend in the adoption and utilization of FOSS has remained, to a large extent, a phenomenon for the developed economies. For example, a series of case studies conducted by [START_REF]The Open Source Observatory and Repository for European public administrations[END_REF] shows that many regional municipalities in Europe are using FOSS. The Gartner study [START_REF]User Survey Analysis: Open-Source Software[END_REF] reported that 85% (N=274) of enterprises in Asia Pacific, Europe and North America are using FOSS. Furthermore, the study projected that, by 2012, at least 80% of all commercial software solutions will include substantive FOSS components. These findings are consistent with similar studies carried out by Actuate [START_REF]The Acutate Annual Open Source Survey[END_REF][START_REF]The 2009 Actuate Annual Open Source Survey[END_REF], using data obtained from surveys conducted with about 1,000 businesses in North America, UK, Germany and France. In general, the economic impact of FOSS for Europe and the rest of the developed world are well documented in the FLOSS Impact report [START_REF] Ghosh | Economic Impact of FLOSS on Innovation and Competitiveness of the EU ICT Sector[END_REF]. Research evidence on the adoption and utilization of FOSS in business environments tends to concentrate on big businesses from North America, Europe [START_REF]The Acutate Annual Open Source Survey[END_REF][START_REF]The 2009 Actuate Annual Open Source Survey[END_REF], China [START_REF]The 2009 Actuate Annual Open Source Survey[END_REF], and Australia [START_REF] Goode | Something for nothing: management rejection of open source software in Australia's top firms[END_REF]. Furthermore, FOSS business models adopted by Europe SMEs have extensively been discussed by [START_REF] Daffara | FLOSS Guide for SMEs[END_REF].

Research Contribution and Questions

According to the FOSSDeva survey [START_REF] Fossdeva | FOSS for Sustainable Development in Africa (FOSSDeva) Survey[END_REF], many people (65.91%) strongly agree that FOSS is the way forward for developing countries; 51.14% see FOSS as a means to stimulate indigenous software industries, create local jobs, and lower technology acquisition costs. Over 60% believe that governments FOSS policy can help the spread and adoption of FOSS. Furthermore, [START_REF] Imed | Open Source Ecosystem in Tunisia: An Empirical Study[END_REF] conducted an empirical study to investigate the main facilitators and inhibitors of FOSS adoption in the Tunisian software business sector. In another study, [START_REF] Maurice | Adoption and Diffusion patterns of FOSS in Jamaican SMEs: A Study of Perceptions, Attitudes and Barriers[END_REF] discussed the perceptions, attitudes, and barriers to FOSS adoption and diffusion patterns in Jamaican SMEs. While, [START_REF] Li | Leveraging the Open Source Software Movement for Development of China's Software Industry[END_REF] discussed how the Chinese software industry can leverage the FOSS movement for its own development. Although these studies focus on FOSS adoption and diffusion in SMEs in developing countries, there exist diminutive research literature on FOSS business activities that can help us understand how small-and medium-sized enterprises (SMEs) in Sub-Saharan African are leveraging FOSS to either start their business ventures or enhance their existing business practices. The contribution of this research to the FOSS body of knowledge aims to fill this gap in the literature by offering answers to the following research question: this part of Africa? An empirical analysis of case studies data obtained from nine ICT-based SMEs from Uganda, Ethiopia, South Africa, Kenya, Tanzania, Nigeria, and Mozambique is used to show how the SMEs in these countries are leveraging benefits inherent in FOSS to create sustainable businesses. Business benefits include low business startup and technology acquisition costs [START_REF] Li | Leveraging the Open Source Software Movement for Development of China's Software Industry[END_REF][START_REF] Imed | Open Source Ecosystem in Tunisia: An Empirical Study[END_REF][START_REF] Maurice | Adoption and Diffusion patterns of FOSS in Jamaican SMEs: A Study of Perceptions, Attitudes and Barriers[END_REF], free access to source code and software, low total cost of ownership (TCO), availability of community support, and ability to customize the software to meet local business needs. A case study research strategy or approach advanced by [START_REF] Yin | Case Study Research[END_REF] is used to gather the information needed to profile the companies, analyse their revenue generation models, capture their motivation for engaging in FOSS business, and list down some lessons that can be learnt from the way the companies operate.

This kind of research is important in a number of ways: increase our understanding of the FOSS business landscape in Sub-Saharan Africa, provide business opportunities by helping African entrepreneurs understand how to leverage the benefits inherent in FOSS, find possible ways of integrating FOSS into the African research and development agenda, provide guidelines for regional FOSS cooperation projects, integrate FOSS education into existing engineering curricular, and increase FOSS awareness on the continent. It is also hoped that this kind of research may act as an eye-opener for ICT businesses already investing or planning to do business in this region of the world. Furthermore, the findings from these case studies may provide guidelines for policymakers in the region to implement a "new" kind of ICT governance framework based on openness.

The rest of the paper is organized as follows. Section two presents background and related work on the impact and socioeconomic status of FOSS in the global and African context. The research methodology, presented in section three, demonstrates the use of a case study approach to investigate FOSS business sustainability. This is followed by section four where we present our analysis and discussion of the case studies results, as well as the validity threats and future work. Concluding remarks are presented in section five.

Background and Related Work

A multitude of interrelated factors are contributing to the upward trend in global adoption and utilization of FOSS. Some of these factors include: global acceptance that FOSS can stand at par and, even in some instances, perform better than its commercial proprietary counterparts [START_REF] Pfaff | Society and open source. Why open source software is better for society than proprietary closed source software[END_REF][START_REF] Gross | Productive Anarchy? Networks of Open Source Software Development[END_REF]; continued improvement in the quality of FOSS [START_REF] Stamelos | Code quality analysis in open source software development[END_REF]; an alternative Bazaar style of developing software [START_REF] Raymond | The Cathedral and the Bazaar. Musings on Linux and Open Source by an Accidental Revolutionary[END_REF][START_REF]Emerging Free and Open Source Software Practices[END_REF]. The Bazaar as opposed to the Cathedral style of developing FOSS [START_REF] Raymond | The Cathedral and the Bazaar. Musings on Linux and Open Source by an Accidental Revolutionary[END_REF] harnesses diverse talents of globally distributed teams of software developers who, for the most part, freely volunteer their time and efforts to develop and maintain the software. The development model promises faster and cost effective software development cycle. Compared to proprietary software, FOSS is also said to have lower total cost of ownership. Entrepreneurs have hybrid business models opportunities [START_REF] Munga | The Adoption of Open Source Software in Business Models: A Red Hat and IBM Case study[END_REF][START_REF] Daffara | FLOSS Guide for SMEs[END_REF], customers are free from vendor lock-ins, users have greater learning and knowledge sharing prospects [START_REF] Sowe | Understanding Knowledge Sharing Activities in Free/Open Source Software Projects: An Empirical Study[END_REF], and regions or countries can support technology independence [START_REF]Catalysing Access to ICTs in Africa (CATIA) programme, Free/open source software (FOSS) policy in Africa: A toolkit for policymakers and practitioners, bridges.org and the Collaboration on International ICT Policy for East and Southern Africa (CIPESA)[END_REF][START_REF] Dwomoh-Tweneboah | Information Technology for Africa, iBiz2008 Workshop for Net Business Ethics[END_REF][START_REF] Jabu | An investigation into the implementation of open source software within the SA government: an emerging expansion model[END_REF] by adopting and encouraging the use of FOSS.

The economic impact of FOSS is highlighted by many studies. For example, the IDC study [START_REF] Michael | Worldwide Open Software Forecast[END_REF] predicts that FOSS will grow at a 22.4% rate to reach US$8.1 billion by 2013. The growth rate is mainly due to increased enterprise adoption from major firms such as IBM [START_REF] Samuelson | IBM's pragmatic embrace of open source[END_REF][START_REF] Pfaff | Society and open source. Why open source software is better for society than proprietary closed source software[END_REF], or Hewlett Packard. The study also found out that hybrid business models are taking more permanence in modern software business. That is, many proprietary software businesses or vendors are also involved in the development, deployment, support and maintenance, and even consultancy of FOSS solutions. These findings are consistent with a study carried out with U.S. companies and government institutions' usage of FOSS [START_REF] Stephen | The Growth of Open Source Software in Organizations[END_REF]. The authors found out that, motivated by reduce IT costs, faster systems delivery, and making systems more secure, 87% of the companies (N = 512) surveyed are using FOSS, and bigger companies with at least US$50 million annual revenue are more likely to use FOSS than smaller companies. This trend is in sharp contrast with what is observed in Europe, where small firms are the lead adopters of FOSS [START_REF]Preparing Europe's digital future. i2020 Mid-Term Review[END_REF].

Thus, it can be argued that FOSS is really in vogue; the technology is having a real impact and redefining the software industry. There is gradual shift in focus from protecting software knowledge to maximizing gain from FOSS development, use, and distribution. As the FOSS development paradigm grants "free" access to the source code, software companies are not obligated to pay software licenses fees. If a company has staff with the technical knowledge, they can download and compile the source code, customize the software to suit the company's customer's needs, or even localize the software to suit a particular business market. However, if a company is not endowed with such technical savvies, it can leverage assistance available 24/7 in fo rums a nd ma il i ng l is t o r c o nt rac t a v e ndo r o r a de v e lo pe r to c arry o ut the modifications needed by the customer. Notwithstanding the availability of these community support options, it is more likely that the typical small business will be constrained by limited ICT literacy, and the lack of the business analytic skills, and absorptive capacity to effectively identify and deploy appropriate FOSS solutions to support their business. Hence intermediaries will play a crucial role in the adoption of complex ICT applications by SMEs, and strategically placed community intermediaries within local and regional and national business ecosystems will be essential to the effective adoption and diffusion of FOSS by SMEs [START_REF] Brown | Potential of critical e-applications for engaging SMEs in e-business: A provider perspective[END_REF] This provides new business models for ICT services SMEs in developing countries, where FOSS becomes both a compelling alternative to propriety software and an option to help them support a sustainable business. Another compelling reason, argued [START_REF] Maurice | Adoption and Diffusion patterns of FOSS in Jamaican SMEs: A Study of Perceptions, Attitudes and Barriers[END_REF] is that the FOSS domain offers an increasingly mature portfolio of business applications that represents viable alternative solutions to meet customers' expectations.

Furthermore, FOSS can, arguably, bring about new business opportunities for small businesses in developing countries [START_REF]Catalysing Access to ICTs in Africa (CATIA) programme, Free/open source software (FOSS) policy in Africa: A toolkit for policymakers and practitioners, bridges.org and the Collaboration on International ICT Policy for East and Southern Africa (CIPESA)[END_REF][START_REF] Van Reijswoud | Free and Open Source Software for Development: exploring expectations, achievements and future[END_REF][START_REF] Watson | The Business of OPEN SOURCE:Tracking the changing competitive conditions of the software industry[END_REF][START_REF]Free and Open-Source: Implications for ICT Policy and Development[END_REF]. For established SMEs, FOSS enables them to move from product-based to service-based (software hosting, support, consulting, training, integration, or customization) activities [START_REF] Imed | Open Source Ecosystem in Tunisia: An Empirical Study[END_REF]. Generally, FOSS is increasingly being recognized by many governments, regional municipalities, and businesses as the means by which developing countries can expand their use of ICTs without the need for huge capital expenditure.

Research Methodology

The methodology employed in this research aims to investigate FOSS business sustainability in the African context. The methodology employs case studies to find out how and why FOSS is being used by ICT-based SMEs to support and sustain their business ventures. The reason for choosing case studies as research instruments is grounded on Yin's [START_REF] Yin | Case Study Research[END_REF] argument that a case study design should be considered when "the focus of the study is to answer how and why questions" and when the researcher wants to "cover contextual conditions" which are believed to be relevant to the phenomenon under study. Thus, a case study approach is considered appropriate technique for this research since it can add value [START_REF] Pamela | Qualitative Case Study Methodology: Study Design and Implementation for Novice researchers[END_REF] and contribute to the body of knowledge by helping researchers and practitioners in the domain to better understand FOSS business sustainability in Sub-Saharan Africa. The methodology employed in this research is schematically shown in figure 1, with the key steps marked in circles and are numbered from 1-7. In the first instance, an FOSS Interview Script, shown in box 1,was developed and used to collect the case studies data from the SMEs. The script consists of a set of case study research questions (Step 1), which are grouped into three main areas; Company profile, motivation for engaging in FOSS business, revenue generation or company's main source of income, and an experience report section. The script, which also has an online version, concludes with a case study feedback section where subjects as asked to indicate (Yes/No) whether they would like to receive further information about the case study they submitted and would like to be contacted for further clarification. Subsequently, case study participants were given a choice to record their case study using either the Interview Script (emailed to them as attachment) or by completing the case study form online (Step 5). With the former choice, participants were asked if one week is sufficient to collect the FOSS interview script responses (Step 6). After five days, a reminder was sent asking if the interviewee is on course and will be able to submit responses. In some cases the responses collected generated more questions or more clarifications on some of the responses given was needed. Where this was the case, the interviewee was contacted again (using emails, phone calls, and Skype chats) and asked to provide more clarification before analyzing the case studies (Step 7).

Qualitative content analysis was used to describe each case study. Content analysis can be defined as "the study of recorded human communications" [START_REF] Babbie | The practice of social research[END_REF]. As a process, content analysis is the transformation of raw text data into a standardized, orderly form. In analyzing the case studies, three aspects of content analysis proposed by [START_REF] Kohlbacher | The Use of Qualitative Content Analysis in Case Study Research[END_REF] were adopted:

• Summary: in summarizing the responses received from the case studies, attempts were made to preserve the essential content but still trying to capture the main ideas submitted by the interviewees. • Explication: this process of re-examination and reading between the lines involves explaining, clarifying and annotating the responses supplied via the FOSS interview script or online case study form. • Structuring: responses received from the companies follow the designed pattern of the FOSS Interview Script. The main aim of the structuring process is to filter out a structure from the responses provided and apply that structure in the analysis of the case studies. The outcome of the structuring process is what is used to profile each case study, as shown in table 3. The methodology also shows an alternative research route. This "direct or indirect contact with company representatives" can act as a possible means of recruiting more case studies and bypassing the online search paths in Steps 2 -4. This can take many forms; such as meeting company representatives face-to-face in workshops, seminars, conferences or through a friend of a friend, through participation in mailing lists, forums, social media where company representatives may be subscribed to; a phenomenon referred to in this research as "e-cohabitation".

Case Studies Data

Table 1 shows the major characteristics of the case studies, including the case study code, the geographical distribution of the companies studied, the year founded, and the staff strength of each company as of January 2012. As shown, the companies are relatively young and have been in existence, on the average, for 7.66 years. Furthermore, considering the European Commission's definition of SMEs [START_REF]T H E N e w S M E D e f i n i t i o n . U s e r Guide and Model Declaration[END_REF], which considered a company to be an SME in terms of the number of employees and either turnover or balance sheet total, we can conclude that most or seven of the companies studied are micro-(ET01, KE01, NG01, SA02, SA03, TZ01, UG01). These SMEs have ten or less employees and are considered as the main forces in economic growth and job creation, not only in developed economies, but also in emerging economies or economies in transition [START_REF] Maurice | Adoption and Diffusion patterns of FOSS in Jamaican SMEs: A Study of Perceptions, Attitudes and Barriers[END_REF]. MZ01 and SA01 can be described as small-since they have employees numbering more than ten and less than fifty employees. However, since this research was not able to register either the turnover or balance sheet totals of the companies, the term enterprise may be most appropriate to use to refer to the companies as entities engaged in an economic activity. They are, in effect characterized as "self-employed, family firms, partnerships and associations regularly engaged in an economic activity" [START_REF]T H E N e w S M E D e f i n i t i o n . U s e r Guide and Model Declaration[END_REF].

Results and Discussions

Table 2 shows the FOSS related business activities captured for each of the case studies. It is interesting to note that all the enterprises are engaged in developing and customizing FOSS solutions as part of their business activity. However, a conversation with the director of SA01 revealed that by FOSS development, most of the enterprises mean customizing the GUI and adding functionalities. Thus, it was not clear as to whether the enterprises are actually coding or developing FOSS solutions or just customizing existing FOSS. This might explain why in all the case studies, we have "Yes" for both software development and software customization. Nevertheless, this underscores one of the key, often understated attributes of FOSS, which is the considerable degree of flexibility and adaptability relative to proprietary software, which makes it possible to customize ICT solutions to fit business needs and operating processes of smaller organisations. All the enterprises are also involved in providing FOSS maintenance and support. With the exception of SA02, all the enterprises employ 'mixed' business activities involving both FOSS and proprietary software. For example, SA02 provides both FOSS and proprietary Geographical Information Systems (GIS) software solutions and services in the areas of system design and implementation, GIS consulting services such as Information Management Policies and GIS strategies. One explanation for this general trend is because, as noted in SA03 and KE01, clients request services on both FOSS and proprietary software. Most customers are just interested in whatever solution they can use to accomplish their objectives (UG01). This finding is in support of the AIM postulate [START_REF] Sulayman | Free and Open Source Software in Business: Implications for Policy Efficiency[END_REF] discussed earlier, which highlighted the increasing integration and coexistence in mainstream business computing ecosystems. There is also great consistency across the business cases relating to FOSS consultancy services, and the development and hosting of web services such as websites. Training is the only service that exhibited significant variation with half the respondents offering training services. Results of the qualitative content analysis of the case studies are summarized in table 3. In the summary each SME or enterprise is profiled according to FOSS business motivation, services offered and method of revenue generation, problems the company encounters in doing FOSS business and possible solutions, and lessons learnt about the unique way the company does business. Some consistent themes and patterns of business practice were identified in the case responses. As distinct from the early years of the FOSS revolution, advocacy is a much less prevalent business motivation. Only one case [UG01] mentioned "encouraging FOSS adoption" as a motivation. Otherwise the range of business motivations were all anchored on the perceived value proposition of FOSS, including: a) the use of FOSS as a low-cost tool in software/web development; b) providing customizable FOSS business solutions; and c) Using FOSS expertise as a service differentiator.

Case study code

Country

Y Y Y N Y Y Y KE01 OpenWorld Y Y Y Y Y Y Y MZ01 SENFOSS Y Y Y Y Y Y Y NG01 Future Software Resources N Y Y N Y Y Y SA01 GIS Global Image Y Y Y Y Y Y Y SA02 Ntinga Information Systems Y Y Y N Y Y N SA03 Linux Holding Y Y Y Y Y Y Y TZ01 Zalongwa Technologies Y Y N N Y Y Y UG01 Linux Solution Y Y Y Y Y N Y Dev. =
As reflected earlier in Table 2, there is a degree of consistency in the business models based on FOSS, with almost all of the cases offering a similar portfolio of services i.e. Consultancy, Software development & Customization, Software Maintenance and Support, Web based service development and hosting, and generally supporting mixed computing environments with both FOSS and proprietary software. The business models resonate with the OSS2.0 archetypes suggested by [START_REF] Fitzgerald | The Transformation of Open Source[END_REF] which suggested the emergence of small service centric software companies that thrive by providing training, technical support, and consultancy for local organizations that deploy open source products Problems encountered, specific to FOSS, also fell generally into two categories; a) managing and changing client perceptions of FOSS as a legitimate business computing solution; and b) acquiring and maintaining the requisite level of resident FOSS expertise.

With increased FOSS adoption and use by SMEs within local, regional and national business ecosystems the latter challenge of maintaining the requisite level of resident, highly technical FOSS expertise is likely to manifest as a recurrent problem for service providers. This identifies a critical role for strategically placed community intermediaries as suggested by [START_REF] Brown | Potential of critical e-applications for engaging SMEs in e-business: a provider perspective[END_REF] that can provide aggregated technical services that are important to clusters of SMEs to facilitate the adoption of complex ICT applications. These challenges also suggest opportunities for Policy interventions at the state or national level that will endorse and encourage the legitimacy and use of FOSS, as a means of stimulating the indigenous software industry, creating local jobs and entrepreneurial opportunities. -Expansion in the region because of language barrier (all our activities are conducted in Portuguese).

-Prompt payment from our major customers, especially government ministries.

-We're gradually developing and customizing applications in English and French to help us reach other markets in Africa.

-mostly take bank loans to cover some operational costs.

-Language is an essential business enable. It can be a plus because CENFOSS in MZ01 is the only Portuguese company in the Eastern Africa region, but it can also be disadvantageous because MZ01 finds it difficult to expand beyond Mozambique.

NG01

-Keep costs at a minimum by reusing FOSS components and outsourcing essential development activities.

-Reduce the main start-up costs by using FOSS to building and market websites.

-Web site design and hosting, software

-Company registration procedures.

-Finding skilled work force that is willing to work for a low salary.

Outsource -Poor payment habits from clients -establish a firm policy on getting paid before delivering services or before students register and complete their courses.

-get a good and well experience account.

-educate your customers.

- -Ease software development by adopting ready and mature FOSS.

-Less cost in terms of money and time.

-benefit and learn from large community of developers and users -Sustain the company's flagship FOSS product (SARIS) .

-

Validity threats

While this research may have provided some insight into the business potential for ICT-based enterprises in Sub-Saharan Africa, we have only introduced nine case studies from seven out of possible fifty-four African countries. Given the increasing prominence of FOSS on the continent, we posit that there are many more enterprises leveraging FOSS for business purpose. There might even be variations in FOSS business practices by enterprises within the same country or region. Furthermore, since our case studies are just from English speaking Africa, language may even be a factor that can bias our sample. Thus, there is danger in generalizing the results presented here to the entire African FOSS business ecosystem. However, as [START_REF] Mockus | Two case studies of open source software development: Apache and Mozilla[END_REF] found out in their study of the Apache web server, the analysis of sometimes few cases or even a single case can provide important insights and ground for future research in this area. Therefore, we hope that the methodology and analytical framework provided in this paper can form the groundwork for further research work to investigate FOSS business sustainability and innovation in Sub-Saharan Africa.

Future work

The research presented in this paper has opened avenues for future work which may provide supplementary information to help researchers further understand FOSS business sustainability and innovation in Sub-Saharan Africa. As a follow-up to this research an online "FOSS Case Studies for African ICT Companies1 " is being launched to provide more case studies for this kind of research. More case studies data will help ICT4D, entrepreneurs, and Information Systems researchers better understand the trend in FOSS business innovation activities over time and the factors influencing them.

Conclusion

This research presented and discussed how small businesses in Sub-Saharan Africa are leveraging the benefits inherent in FOSS to create sustainable businesses. The literature review highlighted the global trend, economic impact, and sustainability as pe c ts of F O S S and ho w all t he s e f ac to rs c o me into play to pro v ide unique technology opportunities for Sub-Saharan Africa. A methodology was presented to show that a case study research approach can be a possible means of investigating how ICT businesses are using and benefiting from FOSS. In the analysis, each case study was presented showing the profile, FOSS business motivation, and the services offered. Problems encountered and solutions adopted in operating a mix FOSSproprietary software business in the particular country, as well as lessons to be learnt from the way the companies do business was also presented.

The case studies showed that FOSS provides an alternative business model option for ICT firms in Sub-Saharan Africa. However, operating solely on FOSS solutions and services is not a sustainable business option. Rather, companies operate a form of quasi-business; taking advantage of the low cost and ability opportunities to customize FOSS solutions, and at the same time selling and doing maintenance of proprietary software. Furthermore, the companies' main motivation for engaging in FOSS business is driven by reduction in the cost of software development and deployment. For most of the companies, the software they needed to start a business (e.g. building websites, deploying and maintain a learning management system) was readily available as FOSS. This helped them avoid problems, such as purchasing and paying high licenses cost, associated with associated with starting a business with proprietary software.

The qualitative nature of the study, provides insights into the emerging FOSS business models in sub-Saharan Africa, problems encountered by businesses and lessons to be learnt from the case studies individually and collectively. It provides a basis for replication in other developing contexts, as well more extensive quantitative studies, based on the trends and factors highlighted. In conclusion, similar to the advice given to China's software industry by [START_REF] Li | Leveraging the Open Source Software Movement for Development of China's Software Industry[END_REF], this research ascertains that there is substantial evidence from these case studies to suggest that Africa should focus on its domestic software market as a starting point and develop a more comprehensive strategy for the long term. The study highlights opportunities for Policy interventions that can help to stimulate the growth and development of entrepreneurs and existing businesses that base their business model on FOSS. Such interventions could seek to endorse the legitimacy of FOSS, and demonstrate by example through Government's own adoption and use of FOSS. Such initiatives could help to deflect the level of uncertainty or distrust that may continue to persist among prospective FOSS business clients and could also help to stimulate greater investment in FOSS training and expertise in the sector, two of the challenges cited by respondents in the case study.

Fig. 1 .

 1 Fig. 1. Case Studies Methodology to Study FOSS Business Sustainability.

  Software development, Cus. = Customization, Con. = Consultancy, Tra. = Training, MaS = Maintenance and Support, Web = Web base service development and hosting, Mix = both FOSS and proprietary software, Y = Yes, N = No

  Part of business is to enjoy what you do and you are passionate about. -A proper strategic plan (3-5yrs) in place which has the capacity to expand and accommodate unexpected changes in market conditions. -Look at what your potential competitors are doing and learn from them. Think of what sort of services the market needs. -Be knowledgeable in the industry you are going to do business in and know the laws and policies governing business in the country. TZ01 -Distinguish the company from other established proprietary IT companies.

How are small businesses in Sub-Saharan Africa leveraging benefits inherent in FOSS to create sustainable businesses?

  By addressing this question the research hopes to offer insight into other questions which may arise, such as (i) how are Africa SMEs leveraging FOSS to support their business practices? (ii) what are the FOSS business benefits for SMEs? (iii) what problems or difficulties do they encounter and what are the possible solutions to those problems? (iv) what lessons can we learn about the unique way of doing FOSS business in

Box 1: FOSS Interview Script for African ICT-based companies

  Who are your most prolific customers and the types of services they request most? …… Q6. What are some of the strategies you use to market your products and services? Q7. What are some of the difficulties, if any, you face in getting paid for the services you offer? …… Q8. Please describe whether you are developing new products or customizing existing FOSS solutions (bespoke software) to fit your customers' needs? …… Q9. Are you localizing (translating into local languages) some of your products? …… Experience Report: Q1. Looking at other companies (in and outside your country) who may be offering similar services as you do, what would you say works well for your company? …… Q2. What is your advice for someone starting FOSS business in Africa in general and your country in particular? …… Q3. Please describe three key problems you have encountered in running this kind of business and your solutions to those problems? …… Q4. What are some of your business plans which will ensure the viability and

	……
	Revenue generation or source of income:
	Q1. Which services (e.g. ICT Training, Web Hosting, Software Development,
	Consultancy, etc.) are you offering? ……
	Q2. If you are offering "FOSS/IT Outsourcing" as a service. Which of the following
	describes your outsourcing strategy? ……
	a) Offshore outsourcing (e.g. to other countries outside Africa)
	b) Onshore outsourcing (e.g. to other countries within Africa)
	c) Both offshore and onshore outsourcing
	Q3. Which service in Q1 is generating more income for your company? ……
	Q4. What is your company's annual turnover (in USD)? ……
	Q5.
	Case Study Code:…
	(e.g. SA01 meaning the 1 st case study from South Africa, country prefix SA)
	Company profile:
	Q1. Name/email of contact person: ……
	Q2. Country of residence: ……
	Q3. Name of the city/town where the company is located: ……
	Q4. Registered full name and acronym of the company: ……
	Q5. Company's web presence (if any) : ……
	Q6. When was the company established? ……
	Q7. How many people are employed in this company? ……
	Motivation for engaging in FOSS business:
	Q1. Please describe your motivation for using Open Source in your business

sustainability of the business in the long run? …… Case studies feedback: Would you like to receive frequent updates about the status of the Case Study information you supplied (Yes/No)?

Table 1 :

 1 Major Characteristics of the Case Studies

Table 3 :

 3 Profile of the Case Studies

	Case study	FOSS Business Motivation	Services and revenue generation	Problems encountered and possible solutions	Lessons learnt
	code
	ET01	Not "re-inventing the wheel" -tools the founders needed for software and website	Software development and web hosting (domain name	-Lack of skill labour or getting staff who are experts in GNU/Linux and FOSS	-Train your staff locally and make sure they stay with the company after training. Make	-Boldly participate in public bids for projects. -Make products and services affordable by reducing costs.
		development are freely available	registration), networking,	-Building a client base who	them feel as if they are part	-Involve customer in FOSS customization
			maintenance, consulting,	are comfortable with FOSS	of the company and decision
			outsourcing, technical support.		making process.
	KE01	-Use and customize freely available FOSS solutions. -Keep costs down.	Consultancy, Training, Product development and Support.	-Building a client base who trust FOSS solutions. -Getting necessary	-Educate customers about FOSS capabilities.	Trying the untested, and always be ready to do things differently in terms of responding to
		-Interact with a larger software developer and		registration and company	-Go to the customer instead	client requests.
		user communities.		documents	of waiting for customers to
		-Use the latest, cutting-edge, technologies to		-Hiring employees with	come to you
		satisfy customers' needs.		experience in FOSS
	MZ01	-To carve out a niche in the ICT market.	-FOSS training, consultancy,
		-Turn FOSS experience into profitable	application development, server
		business activity to earn a living.	(mail and web) installation and
			maintenance with key ministries,
			banks, and telecoms.

http://servnet.ias.unu.edu/limesurvey/index.php?sid=67749&lang=en, Last accessed, May 15,

Acknowledgment

The first author wishes acknowledge the Japan Society for the Promotion of Science (JSPS) for funding this research under the Grant-in-Aid number: P10807. The authors wish to extend sincere gratitude and thanks to the companies for providing the case studies data. We are greatly indebted to the three anonymous reviewers for their constructive comments and suggestions which helped us improve the quality of the original manuscript submission.


Gregorio Robles
email: gregorio.robles@urjc.es

Jesús M González-Barahona
email: jesus.gonzalez.barahona@urjc.es

Gsyc / Libresoft

A Comprehensive Study of Software Forks: Dates, Reasons and Outcomes

Keywords: free software, open source, forks, forking, social, legal, sustainability, software evolution

In general it is assumed that a software product evolves within the authoring company or group of developers that develop the project. However, in some cases different groups of developers make the software evolve in different directions, a situation which is commonly known as a fork. In the case of free software, although forking is a practice that is considered as a last resort, it is inherent to the four freedoms. This paper tries to shed some light on the practice of forking. Therefore, we have identified significant forks, several hundreds in total, and have studied them in depth. Among the issues that have been analyzed for each fork is the date when the forking occurred, the reason of the fork, and the outcome of the fork, i.e., if the original or the forking project are still developed. Our investigation shows, among other results, that forks occur in every software domain, that they have become more frequent in recent years, and that very few forks merge with the original project.

Introduction

Issues related to the sustainability of software projects have historically been studied in software engineering in the field of software evolution. However, research on software evolution has always implicitly assumed that development and maintenance of a software is performed by the same organization or group of developers. It is a task of the creators of the software to make it evolve [START_REF] Lehman | Program evolution: Processes of software change[END_REF].

But in some cases a software project evolves in parallel, lead by different development teams. This is known as "forking". The term fork is derived from the POSIX standard for operating systems: the system call used so that a process generates a copy of itself is called fork(). As a consequence, there exist two copies of the process that run independently and may perform different tasks. In analogy to this situation, a software fork happens when there exist two independent software projects, deriving both from the same software source code base.

Forking may happen in proprietary environments, but it is natural in free software as the freedom to modify a software and redistribute modifications is part of the freedoms that it grants. However, the free software movement has traditionally seen forking as something to avoid: forks split the community, introduce duplication of effort, reduce communication and may produce incompatibilities.

To the knowledge of the authors, no complete and homogeneous research on forking has been done by the software engineering research community. This paper has as main goal to raise a point of attention on this issue. The contributions of the paper can be summarized as follows: first, it offers a wide perspective of forking, identifying all significant forks. Second, it enters into detail in the reasons given for forking, presenting and classifying them. Third, it provides information on the outcome of the forks, in order to see if forking undermines the sustainability of the projects.

The structure of the paper is as follows: next, we will propose some definitions of forking and related concepts. Section 3 contains the related literature on software forking. Then, we introduce with detail the research questions that we target in this paper. Section 5 describes the methodology used for the identification and the study of forks. Results are shown in Section 6. Finally, conclusions are drawn and further research possibilities are offered.

Definitions

In this section we define a series of concepts used in this paper.

Clone

Cloning is the action of creating a software system designed to mimic another system. This can be done by reverse engineering or completely reimplementing from documentation or source code, or by the observation of the behavior and appearance of a software. Cloning is a common practice in free software [START_REF] Capiluppi | Successful reuse of software components: A report from the open source perspective[END_REF].

Branch

Branching refers to the duplication of source code in a version management system. When branching occurs, parallel threads of development will take place. It is a common practice in free software projects to have branches. Software projects use branching for instance when developers do not want new features to be included in the stable branch. The popular GitHub service, which uses the git distributed versioning system, refers to branching as forking.

Fork

Forking occurs when a part of a development community (or a third party not related to the project) starts a completely independent line of development based on the source code basis of the project. To be considered as a fork, a project should have:

1. A new project name. 2. A branch of the software. 3. A parallel infrastructure (web site, versioning system, mailing lists, etc.). 4. And a new developer community (disjoint with the original).

Derivation

A derivation is the process of forming a new software system on the basis of an existing one, but ensuring compatibility between both systems. Derivations are common among Linux-based distributions1 ; new systems assemble software software programs and libraries that can and will be used in the other distributions without problems.

Mod

A mod is an enhancement made by enthusiasts to existing software. Mods are not standalone programs and require the user to have the original release in order to run it. They are specially popular in personal computer games. Scacchi has studied the culture of mods [START_REF] Scacchi | Computer game mods, modders, modding, and the mod scene[END_REF].

3 Related literature

Software engineering related research

The software engineering research literature on forking is, to the knowledge of the authors, very scarce. We have only found a technical report by Ernst et al. that looks specifically at forking [START_REF] Ernst | Code forking in open-source software: a requirements perspective[END_REF]. They analyze a case study of a project forked because different requirements wanted to be met.

If we focus on software evolution articles, we find some related research. For instance, Xie et al. talk about parallel evolution of some free software projects in [START_REF] Xie | Towards a better understanding of software evolution: An empirical study on open source software[END_REF]. While analyzing the validity of Lehman's laws of software evolution on several free software projects, they discover that projects tend to have several branches (although the authors use the term fork ) of the source code tree, one that is used for the correction of errors and another one for the inclusion of new features.

Although forks have not been specifically the matter of research per se, there have been some publications where notorious forks have been used as case studies for software evolution studies. In this sense, Fischer et al. studied the evolution of what they call a product family, three variants of the BSD kernel [START_REF] Fischer | Mining evolution data of a product family[END_REF]. The BSDs are studied as well by Yamamoto et al. to measure the similarity of the source code [START_REF] Yamamoto | Measuring similarity of large software systems based on source code correspondence[END_REF], and by Yu et al. to analyze their maintainability [START_REF] Yu | Maintainability of the kernels of open-source operating systems: A comparison of Linux with FreeBSD, NetBSD, and OpenBSD[END_REF].

There have been some efforts to study copying of source code in free software projects. Mockus performed a massive survey of free software code and found that many projects shared files [START_REF] Mockus | Amassing and indexing a large sample of version control systems: Towards the census of public source code history[END_REF]. Germán et al. analyzed the legal consequences and issues that code being copied (reused ) raises [START_REF] Daniel | Code siblings: Technical and legal implications of copying code between applications[END_REF].

Related free software literature

Forking has been widely discussed outside the research literature in the free software community. In Raymond's Hacker Dictionary we can find that "[f]orking is considered a Bad Thing not merely because it implies a lot of wasted effort in the future, but because forks tend to be accompanied by a great deal of strife and acrimony between the successor groups over issues of legitimacy, succession, and design direction. There is serious social pressure against forking. As a result, major forks (such as the Gnu-Emacs/XEmacs split, the fissionings of the 386BSD group into three daughter projects, and the short-lived GCC/EGCS split) are rare enough that they are remembered individually in hacker folklore." [START_REF] Raymond | The New Hacker's Dictionary[END_REF].

Di Bona mentions the possibility of forking as a fear of losing control of individuals and especially companies [START_REF] Dibona | Introduction[END_REF]. Eric Raymond argues in [START_REF] Raymond | editor, The Cathedral and the Bazaar[END_REF] that the free software movement has an elaborate but largely unadmitted set of ownership customs that include the possibility, but mainly avoidance of forking. As Feller et al. put it, "[t]here is a strong taboo against forking" [START_REF] Feller | A Framework Analysis of the Open Source Software Development Paradigm[END_REF]. Neville-Neil agrees with this position and recommends to think before you fork [START_REF] George | Think before you fork[END_REF]. He notes that only abandoned projects should be forked as developers who fork may be taken as a petulant and spoiled child who wants to take your toys and go home. Bezroukov indicates that ego-related issues can lead to forking, and that forking can cause the death of both initial and forked projects [START_REF] Bezroukov | A second look at the Cathedral and The Bazar[END_REF]. In Fogel's "Producing OSS" book [START_REF] Fogel | Producing Open Source Software -How to run a successful free software project[END_REF], the topic is handled in detail. First, some sections are devoted to the consequences of forkability, what the author calls the mere possibility of doing a fork. Then, in a very practical way, he discusses how to manage a fork when it occurs.

Related research from other areas of knowledge

There are other areas of research beyond software engineering that have put some attention on forking. So, from the economics literature, Lerner and Tirole [START_REF] Lerner | Some simple economics of open source[END_REF] identified as one of the four main roles of a leader in an FOSS project to keep the project together and prevent forking (also pointed out by Germán [START_REF] Daniel | The GNOME project: a case study of open source, global software development[END_REF]), Weber et al. analyze forking from the software business perspective [START_REF] Weber | The Success of Open Source[END_REF], Kogut et al. look it from the point of view of distributed innovation [START_REF] Kogut | Open-source software development and distributed innovation[END_REF], and Karpf et al. have had some thoughts on governance, although they discuss them not using a software project but Wikipedia [START_REF] Karpf | What Can Wikipedia Tell Us about Open Source Politics[END_REF].

Research questions

In this study, we have targeted following research questions:

How many (significant) forks exist?

The aim of this question is to obtain the number of significant forks. When we started with this study, we had the impression that forking -being discouraged by the community-is seldom performed, but the exact number of projects that had been forked was unknown.

To answer this question we will have to identify all significant forks that have occurred in the history of free software. When identifying the forked projects, we will record the software domain in order to determine if forking is more common in certain types of software projects. Our initial (probably naive) assumption was that forking is more frequent in some domains.

Is forking becoming more frequent?

With this question we want to verify if the number of forks per year has been growing. Our initial (again naive) assumption is that forking is becoming more frequent in the last years. The first reason for assuming this is that nowadays more companies are leading free software projects; in such cases, organizational and strategic tensions between the goals of the company and the rest of the community may appear. If members of the community think that the company does not take their contributions and requirements into consideration, a fork may happen. The second reason is that the number of projects has grown exponentially [START_REF] Deshpande | The Total Growth of Open Source[END_REF], so we assume that the probability of having forks increases.

What are the main reasons for forking?

When reading the literature, and especially if we have in mind the recommendations given by the free software community, forking is a very sensitive topic. Those who create a fork have to argue that forking was a last resort [START_REF] Fogel | Producing Open Source Software -How to run a successful free software project[END_REF]. With this question we want to know which are the most frequent circumstances for forking. We part from the following classification of reasons, that is derived from our knowledge of very known forks:

• Technical (addition of functionality): Some developers want to include new functionalities into the project, but the main developer(s) do not accept it. As an example of this type of fork we have xpdf and Poppler.

• More community-driven development: This occurs when the original leaders, whether a company, an institution or an independent group of developers, does not take into account the community. • Legal issues: Legal aspects such as disagreements on the license, trademarks or changes to conform laws (encryption) are included here. An example of such a fork is X.Org, that originated from XFree.

• Differences among developer team: The developer team disagrees on fundamental issues (beyond mere technical matters) related to the software development and the project. The OpenBSD fork from NetBSD is an example of such a type of fork.

What is the outcome of forking?

David A. Wheeler notes that there are four possible outcomes of a fork2 :

1. The discontinuation of the fork. 2. A re-merging of the fork.

3. The discontinuation of the original. 4. and successful branching, typically with differentiation.

Wheeler provides an example for each of the cases, and adds that in his opinion, the discontinuation of the fork is the most common case as it is easy to declare a fork, but continuation requires considerable effort.

To Wheeler's classification we will add the situation where the original and the forked software projects have both been discontinued.

Methodology

Our intention is to document all significant forks. At first, we started performing Google searches for the term software fork, but the number of responses (in the range of 45,000,000) showed that this would be not embraceable.

However, one of the first terms appearing in the Google search was a page with a list of software forks in the English Wikipedia3 . The web page contained around 30 software forks.

In addition, we have searched for software fork using the English Wikipedia search box. As of August 2011, the result offers 1500 Wikipedia pages. After manually inspecting all these pages, a list of 235 potential forks was obtained.

So, for the purpose of our paper, we assume that a fork is significant if a reference to it appears in the English Wikipedia. We have partially tested this assumption by looking at the 300 top-positioned results of searching for software fork in Google, and have not found forks we did not already have on our list.

The analysis procedure we used for each potential fork was following:

1. Locate the main website of the original software.

2. Locate the main website of the forking software.

3. Identify the software domain of the project. This information can be obtained by using the software classification of the Wikipedia, SourceForge or Free(Code). 4. Identify the reason of the fork. We inspect the website of the forking software for any information on this. In general, in its main page or in an "About" or "History" section an explanation can be found. If not, we analyze the original software web page and the Wikipedia pages of the projects for any reference. If none of the previous is successful, we perform a Google search. 5. Identify the date of the fork. Usually a date can be found together with the reason. In some cases the registration date in a software forge, the first release or the first commit in the versioning system of the forking project has been considered. The error of the dates obtained may be in the range of months, although for our purposes this is assumable. 6. Identify the outcome of the fork, including dates. Usually we have looked for the last release or the last activity on the versioning system. If there has been no activity since mid-2010, we have labeled the project as discontinued.

All this information, including any other extra relevant facts that help understanding the reason of the fork, has been written down in a log file (our research script). The research script is publicly available for replicability purposes, and for further analysis and research 4 . We have tried to indicate always the original URL where the information has been taken from. Our intention, as well, has been to use primary sources, avoiding thus Wikipedia pages, although this has not always been possible.

During August 2011 we obtained the list of significant forks. We analyzed the forks on an individual basis during a two-week period in August, and a final set of projects during one week in March5 . The analysis was performed at a pace of 5 to 8 forks per hour.

Results

Number of forks

The total number of forks we have been able to identify is 220, as from the total number of potential forks (235) some of them were clones, branches or derivations. For instance, Wireshark appears as a fork of Ethereal. However, investigating this case, we found that what happened was a renaming due to trademark problems with the Ethereal name; it was the same community that was developing the software under a different name. Another example is Gereqi, a multimedia program that is considered in Wikipedia as a fork of Amarok. In its main web page, the author of Gereqi states that the software does not contain a single line of Amarok, and demonstrates it with the fact that Gereqi has been implemented using a different programming language.

While inspecting the list of forks, we have found projects where forking is common (e.g., MySQL6 , Tux Racer, DC++, WakkaWiki, L2J...). It seems that once a fork has occurred, more forks are cheaper, in the sense that minor reasons have to be provided to start a new fork.

Table 1 provides information of the software domains where forks have occurred. Our initial assumption was that forking was more specific to certain domains. Our results shows that this is not true, and that we have found projects forked from operating system kernels to end-user software.

We have not studied in detail if these results are proportional to the share of free software projects, for instance in Debian, Free(Code) or SourceForge. But a fast inspection of the most prominent tags at Free(Code)7 reveals that the most popular software domains are Internet, software development, web, and multimedia, in line with our results.

Observation #1: We have found 220 significant software forks. Forking occurs in every software domain.

Temporal evolution of forks

From the 220 forks, we have only identified the forking date for 210 of them.

For 10 of the forks we could not obtain the date when the fork occurred, while for another 28 projects we could only find the year of forking, not the month.

For the year 2011 we have only partial data, as our list of forks had been obtained August 2011. The result of the temporal evolution of forks is shown in a histogram in Fig. 1. Prior to 1998, the number of forks is testimonial (13 in total), while the number increases in recent years, with around 20 forks per year since 2003. Interestingly enough, the number of forks does not follow the exponential growth path described by Deshpande and Riehle [START_REF] Deshpande | The Total Growth of Open Source[END_REF], so the total number of free software projects seems not to be related with the amount of forks. Maybe a proportionality is given with company-led free software projects, although this is something that we cannot state from our study and is left for further research.

Observation #2: Forks have become more frequent in recent years, but the number of forks does not grow proportionally with the number of free software projects.

Reasons for forking

The free software community is sensible about the problem of forking, as it can be seen from the fact that we have been able to find a reason for the fork for 9 out of 10 forks.

While inspecting the forks and assigning them to the categories of reasons, we included a new category -experimental forks-which might be seen as a subcategory of technical reasons. These type of forks occur when some of the developers -usually a minority-want to introduce major changes into the project, while many others prefer a more conservative approach. In this cases, instead of just opening a branch that would have it very difficult to become the future main branch, a fork is created. These types of forks could be labeled as friendly forks, as many of them come with the approval of the original community. Table 2 shows the result of classifying the main reason given for the forks. We had problems to discriminate among some categories, especially between "technical", "differences among the developer team" and "more communitydriven development". This is because in many of the forks two of the reasons, or even the three of them appeared in some way. So for instance, Carrier (formerly Funpidgin) was set up because the main developers of the Pidgin instant messaging client refused to introduce a functionality that allowed to manually resize the text input area. Although this has been sorted as a technical reason, a closer inspection showed that the argumentation had a more profound basis.

All in all, as observed from Table 2 although the major force for forking is of technical nature (27.3%), the main reason to fork is very distributed among the various categories under consideration.

Observation #3: For most of the forks it is possible to find the reason of forking.

Resolution of forks

We have inspected the outcome of all forks following Wheeler's (augmented) classification. The results are shown visually in Fig. 2. Wheeler hypothesized that most forks do not survive their original projects. Our results throw the contrary situation: the percentage of discontinued original projects doubles the discontinued forked projects.

The results may change radically if we consider apart those forks that are a continuation of a discontinued original project. This is for instance the case for the Apache fork of the NCSA HTTPd server or the RedDwarf fork of the Project Darkstar. In both cases, the institutions behind the original projects (the NCSA and Sun, recently taken over by Oracle) ceased development and support, and a fork was created. 44 forks are a continuation forks (see Table 3).

These numbers show that the amount of original projects and forked projects that are discontinued is similar, being the discontinuation of the forking project slightly more frequent than the one of original projects. Nevertheless the difference is not important enough to meet Wheeler's hypothesis. We interpret this as a consequence of developers being aware of the implications of forking, including the disadvantages of competing with the original project (the need for making the fork reasonable to the community, the use of a new name for the forked software project, etc.). Only if they consider that they have enough reasons and good changes of success, a fork is done.

From Table 3, we can also interpret that when forking occurs the sustainability of the software is ensured. Our argument to sustain such a claim is that forked projects survives for long time -whether original or as the fork. The number of projects where both, original and forked, projects are discontinued is very low compared to the usual numbers of abandoned projects in free software [START_REF] Charles M Schweik | Success and Abandonment in Open Source Commons: Selected Findings from an Empirical Study of Sourceforge.net Projects[END_REF].

The number of forks that merge with the original project is very low. In addition, merging often happens by dismissing one of the projects as developers report that integrating changes is not a simple task. In the case of GCC and EGCS, the technical superiority of the fork made it become the official compiler of the GNU project, discontinuing the GCC source code base. The opposite happened with the libc Linux fork from GNU libc; with a new, enhanced version of GNU libc, Linux stopped using its own libc. The authors report that "changes that had been made in Linux libc could not be merged back into glibc because the authorship status of that code was unclear and the GNU project is quite strict about recording copyright" 8 .

Observation #4: Most of the forks evolve in parallel to the original project. The chance of discontinuation of a fork is almost the same as the original, even if they have a disadvantageous starting situation. Software that forks ensures sustainability. Few forks re-merge, and when this happens, fewer integrate source code.

Conclusions and further research

In this paper we have presented to the knowledge of the authors the first comprehensive study on software forks. We have provided some insight into the temporal patterns of software forks, the reasons for forking and what the outcome of the forking has been for the original and forking project.

In the opinion of the authors, forking is going to be a more relevant and frequent situation in the next future. Free software is nowadays already the root of many other software project which build on top of it (for instance Android); the disparity in goals among the root project and others building on top of it will produce more forks.

On the other hand, technology is lowering the technical barrier of creating a fork. For instance, distributed versioning systems such as git are more suitable to forking, as they provide a copy of the complete history of the project; not only a branch can be built, but a complete copy of the infrastructure is provided. However this is still not the case for bug-tracking systems and mailing lists, which are not distributed and difficult to fork. In our opinion, technology should make forks easier; the convenience of forking should just be a strategic matter that allows to maintain balances among the stakeholders of a project. On the other hand, lowering the technological barrier to fork may increase the number of friendly experimental forks that boost innovation.

There are several topics related to forking that further research should target. First, it would be interesting to find out how much original and forking projects collaborate, even in an involuntary way, by exchanging code, bug reports and fixes. Second, parallel software development should be devoted a closer look; technology and processes should facilitate integration. Third, further research should focus on understanding how the community moves when a fork occurs. This would include among others answering questions such as where the key developers go, how many of the developers are active both in the original and forking projects, or if there is any correlation between a positive resolution of the fork and who pushed for it. Fourth, we think that it would be valuable to focus on how the socioeconomic and technical context may influence the probability and the type of a fork. So, for instance, if project maturity boosts forking or not. And fifth, we think that a study on forking in projects led by software companies could answer many interesting questions that have not been addressed in our work.

Fig. 1 .

 1 Fig. 1. Number of forks per year.

Fig. 2 .

 2 Fig. 2. Outcome of the forks.

  Then developers seeking for more open and public development practices create a fork. Examples of this type are following well-known forks: EGCS from GCC, and XEmacs from GNU Emacs. • Discontinuation of the original project: The original project is unmaintained and a new developer community takes it over. The Apache web server project would be such a fork. • Commercial strategy forks: This type of forks happens when a company forks an existing project to meet some commercial strategy. Commercial strategy forks include those where a software is released as free software by the company, or when the company creates a proprietary version of a free software. Examples of this type are OpenOffice.org from StarOffice, and Webkit from KHTML. In the opposite situation, when the community has concerns about the commercial strategy of a company, the fork belongs to the More community-driven development category; the LibreOffice fork from OpenOffice.org when Oracle took over Sun would be such a fork.

Table 1 .

 1 Forks by software domain.

	Software category	Frequency
	Networking (servers, clients, p2p...)	52 (23.6%)
	Web applications (CMS, LMS, blogs, wikis...)	34 (15.5%)
	Development (IDEs, libraries...)	29 (13.2%)
	Multimedia (audio, video...)	18 (8.2%)
	Games/Entertainment	18 (8.2%)
	System (kernel, file systems...)	17 (7.8%)
	Desktop	16 (7.3%)
	Utilities	12 (5.5%)
	Graphics	7 (3.2%)
	Databases	6 (2.7%)
	Business (ERP, CRM...)	5 (2.3%)
	Security	3 (1.4%)
	Package Management	3 (1.4%)

Table 2 .

 2 Main reasons for forking.

	Reason

Table 3 .

 3 Outcome of forks, considering if the cause of the fork is the possible or actual discontinuation of the original project.

	Outcome

A complete graph on the various families of Linux-based derivations can be found

http://www.dwheeler.com/oss_fs_why.html#forking

http://en.wikipedia.org/wiki/List_of_software_forks

http://gsyc.urjc.es/ ~grex/oss2012forking

The research script includes the dates when the forks were analyzed.

See "A look at the MySQL forks", http://lwn.net/Articles/329626/

http://freecode.com/tags

Acknowledgements

The work of G. Robles and J.M. González-Barahona has been funded in part by the European Commission under project ALERT (FP7-IST-25809) and by the Spanish Gov. under project SobreSale (TIN2011-28110). We would like to thank the anonymous reviewers for their insightful comments.