Forks in Open Source Software Projects

Transcription

1 Forks in Open Source Software Projects Abstract University of Oulu Department of Information Processing Science Henri Kuusirati Janne Seppänen

2 Forking in open source software projects means the copying of a codebase with or without telling the original developers, as it does not need any permission from the original developers, and developing it towards a different set of goals. In this paper we intend to study and present reasons and motivations behind OSS forking based on a literature review. We have divided the motivations into five categories: technical motivations, continuation of an abandoned project, disagreements in governance, cultural and localization issues, and licensing and trademark issues. We also try to gain further understanding about how forking impacts the original forked project and give some real-life examples of current high profile open source projects that either started from a fork or are common targets for forking. We will conclude the paper by summarizing and discussing the studied papers and talk about the need for further research.

3 Table of contents 1. Introduction 2. Reasons and motivations behind forking 2.1 Technical issues 2.2 Continuation of an abandoned project 2.3 Disagreements in governance 2.4 Cultural issues and localization 2.5 Licensing and trademark issues 3. Impact of forking on the original project 4. Examples of forked projects 4.1 Linux distributions 4.2 LibreOffice 5. Discussion 6. Conclusions References

4 1. Introduction Forking in open source development means the copying of a code base from another OSS project and developing it towards a different set of goals. The reasons behind forking are varied and can for example stem from disagreements between developers on the direction of the OSS project. A project branch is different than forking. Branches are made inside a project to enable parallel development. Rather than all developers working on the same code, a new branch can be made for certain type of development, like developing experimental features or bug fixing. After the features developed in a branch are completed and working, it can be merged back into the main project. In the case of a fork, merging happens rarely. A fork is usually made to take the project into a new direction, whereas a branch is just parallel work towards the same direction. (Fogel, 2010) Karl Fogel (2010) states that forks happen due to irreconcilable disagreements, technical disagreements or interpersonal conflicts and is something developers should be afraid of and try to avoid it in any way. Nyman and Mikkonen (2011) on the other hand state that the reasons for forking aren t always disagreements with other developers. A fork can be also made to develop stable and development versions of the software, so forking can happen also inside the project. In general, forking is made by new developers rather than the original team splitting into two projects. (Nyman & Mikkonen, 2011) Notable OSS projects that started from forking are, for example: The Document Foundation s LibreOffice which for forked from OpenOffice and Canonical s Ubuntu which was initially forked from Debian. We will present these cases in more detail in chapter 4. Earlier research on OSS forking is fairly recent and not at all extensive but we intend to study these sources to gain a better understanding on the different aspects of OSS forking. The goal of our paper is to shed light on the reasons and motivations behind OSS forking, which include, for example, different technical motivations, continuation of an abandoned project, disagreements in governance, cultural and localization issues, and licensing and trademark issues. We will also study the impact of forking on the original OSS project. We will be studying and presenting previously written articles that cover these issues in chapter 2 and 3 of the paper and show some real-world examples of forking in chapter 4. In chapter 5 we will discuss about the common elements found in the articles studied in chapters 2, 3 ja 4. In chapter 6 we will summarize the paper and talk about need for future research.

5 2. Reasons and motivations behind forking In this chapter we will present previous works concerning the reasons and motivations behind OSS forking which include technical motivations, continuation of an abandoned project, disagreements in governance and cultural issues and localization. At the end of the chapter we will also take a look at the licensing and trademark issues in forking. Nyman and Mikkonen (2011) searched through the SourceForge.net source code repository and were able to find 381 forks that happened between 1999 and 2010 which stated their original motivation for forking. Nyman and Mikkonen (2011) categorized these motivations into different groups which include content modification, technical modifications, reviving an abandoned project, licensing/fos-related issues, language and/or country-specific modifications, experimentations and various other reasons. The largest groups found were content modification which accounts for 46 percent of the studied forks and technical modifications at 26 percent. (Nyman et al., 2011). Figure 1. Fork motivations in SourceForge projects. Nyman et al., In a similar study, Viseur (2012) studied 26 forks to find the motivations behind their existence. The forks were selected from popular open source projects. Viseur divided the motivations into six groups: end of the original project, technical motivations (divergent technical views or different technical objectives), license change, conflict over brand ownership, problems of project governance, cultural differences and searches for new innovation directions. Technical motivations accounted for 42 percent of the studied forks while problems of project governance accounted for 38 percent. The end of the original project was the motivation 19 percent of studied forks. (Viseur, 2012).

6 Figure 2. Motivations to fork. Viseur (2012). Both Viseur (2012) and Nyman et al. (2011) recognize licensing issues and continuation of an abandoned project as separate groups of motivations behind forking. In addition to those motivations, Viseur (2012) found issues related to governance, cultural differences and conflicts about trademark. In a recent study similar to Viseur s (2012) and Nyman et al s (2011), Fung, Aurum and Tang (2012) studied nine JavaScript development communities in GitHub with the highest amount of forks to identify the relationships within them and study how forks are used to facilitate OSS development. During their analysis almost 7000 developers made approximately 8000 forks in the different communities. Some of the most active developers made contributions to multiple studied communities. Their research indicates that forks are actively used by the development community to fix defects and to experiment with new features. According to Fung, Aurum and Tang (2012), what separates these forks from normal branching is that the changes don t necessarily need to be promoted to the original project and can live in a separate fork that can still take any changes and improvements from the original project as updates. What separates a fork from a branch even more is that a fork can originate from either a subset of the forked predecessor s artefacts or from multiple predecessors artefacts. A branch in turn is a copy of all the predecessor s artefacts (Fung et al., 2012). In the next few chapters we will go deeper into the issues identified by Viseur (2012) and Nyman and Mikkonen (2011). We will focus on technical issues, continuation of an abandoned project, disagreement in governance, cultural and localization issues, licensing and trademark issues, and various other miscellaneous reasons for forking.

7 2.1 Technical issues Forking allows the developers to start from a ready code base and turn the project into their own directions with their own requirements, features etc. It has it s own difficulties. Are any developers interested in the fork? Are the changes so small, that they could be just implemented as a new feature to the old project. Is the forked project interesting enough for developers that they keep developing it? (Ernst, Easterbrook & Mylopoulos, 2010) Technical reasons for forking are typically tasks like porting it into a new hardware or software or just improving the original software. Porting is done to make the software run natively on a different platform, usually GNU/Linux or Mac OS X. Some ports are aimed to make the software more free, so it doesn t have as many dependencies to other libraries or software. If some of the depended software is no longer developed, your own software could go down as well. Improving the software is not so common than porting but it still occurs. The improvements contain bug fixes, optimizations or other improvements. The fork can also be made to test new features without breaking the original development cycle with experiments. If the tested features turn out working, they can be merged into the original software. (Nyman & Mikkonen, 2011) Nyman and Mikkonen (2011) found that almost half of the studied forks had some kind of content modification as the motivation for forking. Content was either added or focused. Adding content is exactly how it sounds like. It could be new features or better documentation. Developers didn t specify the added content, it was usually called just more features. Content focusing is making the software work better for a specific user group. The forked software could be specialized to a certain business area, like radio, catering etc. A more technical reason is to make the software run on a specific platform, like some specific intranet portal or a new resolution. The main goal in content focusing is to make the software lighter and faster. 2.2 Continuation of an abandoned project A common reason for forking is making an abandoned project alive again. New developers do a fork on a project which was considered abandoned or not developed for a long time. The original developers are usually credited (if they can be found). This could also encourage the original developer to continue working on the project again when it has some interest among others. (Nyman et al., 2011) Viseur (2012) grouped 19 percent of the found forks under the label end of the original project (figure 2). Nyman and Mikkonen did not present any reasons for forking an abandoned project, rather than continuing on the old project. We think that the reason could be simply that the new developers don t have access or commit privileges to the old project s repositories,

8 especially if the original developers could not be found or contacted. On the other hand it could also be good to start developing with a clean start, making a new project with a new name. Users might think that the old project is still abandoned, thus the new project could attract a bigger audience. 2.3 Disagreements in governance According to Karl Fogel (2010) forks can damage open source projects by splitting the user base and developers into two camps. According to Fogel (2010), forkability of a project or the possibility of a fork can motivate the project members to work together and try to solve any disagreements by making concessions to other developers and contributors. However sometimes the differences in opinion between the developers might be so severe that forking is the only option. Viseur (2012) identified disagreements in governance as the second most common motivation for a fork with 38 percent (Figure 2). Viseur finds that these problems arise mainly from lack of openness in the project, as in slowness from the main developers part to take into account what collaborating developers want to contribute. Viseur also suggests that lack of communication between core developers and contributors can be a driving factor in leading to a fork. Surprisingly Nyman and Mikkonen (2011) only found four out of the 381 forks to fall under disagreements in governance which they grouped together in the motivation group other in figure 1. Viseur talks about Nyman et al. s article in his paper and suggests that the different results are due to the different nature of their studied forks; Viseur s material being from high profile and mature open source projects with active communities behind them and Nyman et al. s being from small Sourceforge projects. 2.4 Cultural issues and localization Six percent of Nyman and Mikkonen s (2011) forking motivations were identified as cultural issues. In most of these forks, new content was added to the original project to make it more culturally relevant to some specific country. Nyman and Mikkonen (2011) list as an example, making the forked program support right-to-left layout of text used in some languages like Hebrew. Some of these forks just focused on translating the original project to a new language. These forks could also be put into the adding content category but as the content is in these cases based only on cultural and language issues, they should fall under their own group. Out of the 26 forks Viseur (2012) studied, cultural differences amounted to 8 percent. Viseur does not explain in any more detail, what exactly does he count as a cultural motive for forks.

9 2.5 Licensing and trademark issues Open source licenses make forking possible. You don t need a permission from the original author of the software. Some examples of forks are presented in chapter 2.2. Companies sometimes try to privatize their code. A fork from the last open version can prevent the code from being unavailable due to privatization and the open source community can keep developing the code. See chapter 2.2 for an example of a license change. (Ernst et al., 2010). Some companies use dual licensing business models in which the same core software is available with an open source license and a proprietary license. MySQL for example offers a free version of the product as well as with a commercial license. Dual licensing does not allow forking easily because the company has the copyright and control of the source code. This is considered as a threat against open source software development because pure open source licenses don t require a permission from the original authors. (Dahlander & Magnusson, 2008). The original code base can contain parts which are proprietary. This can motivate a fork which removes the proprietary code and replaces it with an open source alternative, either from an existing open source project or by writing a new open source solution. (Nyman et al., 2011). There are basically two kinds of open source licenses; academic and copyleft licenses. Academic licenses allow the developer to license the forked project with any license, even proprietary so the academic license, for example BSD is considered unrestrictive (Lerner & Tirole, 2005). If copyleft licensed software is forked, the new project must be licensed with the same license. It also limits the financial incentives because the source code cannot be made closed. The chosen license has an impact on code exchange. With a copyleft license, the code can be exchanged within the project because they use the same license. If the fork is licensed with a more limiting license, the exchange becomes one-way or impossible, depending on the license, i.e the forked project can have code from the original project but not vice versa. (Viseur, 2012). Copyleft licenses can be split into two parts, restrictive and highly restrictive. A restrictive license can for example be LGPL, which allows you to use another license on your software, if you don t modify the original code. This license is usually used on software libraries and components. A highly restrictive license doesn t allow you to use any other license than the original, this the case with, for example, GPL. Whether or not you make changes to the code, your software has to be licensed under the same license as the original software. (Lerner & Tirole, 2005)

10 3. Impact of forking on the original project Viseur presents impacts on forking open source software projects. Forking could weaken the original projects development because there is a competing project going on and some developers could change sides. On the other hand, forking can make the original project stronger. Forking is often seen as a risk. It causes confusion in the community, not everyone can see the difference between the softwares. Fork impacts are presented in figure 3. Wheeler presents four possible consequences to a fork; disappearing, diverging, merging and disappearance of the original project: 1. If the forked project does not convince the community, it quietly disappears, for example glibc/libc. Developers thought that the original glibc wasn t developing fast enough so they forked it. However, the original GNU project surpassed the forked library over time. (Wheeler, 2007) 2. Both projects can also gather enough developers so they both will carry on their chosen paths. GNU emacs and and xemacs are an example of this case. Emacs was forked into xemacs. Both projects have their supporters and they both live on. (Wheeler, 2007) 3. If a fork is made as a result of an argument, the projects can merge after some time if both parties agree that both made good efforts on the project. Community was not happy with slow evolution of the popular c-compiler GCC. Free Software Foundation (FSF) was very slow in accepting changes into the code. The compiler was forked into EGCS which had a faster development cycle. It soon surpassed GCC, then the FSF agreed to use the code from EGCS so the fork was no longer needed and the projects merged. (Wheeler, 2007) 4. Sometimes the fork becomes more popular than the original project. In this case the original project dies and the fork keeps going. The most famous example of this is XFree86 which was forked into X.org. XFree86 changed it s license to be non-gpl-compatible. This caused a big argument but they refused to keep the license GPL-compatible. It was then forked into X.org. Big communities (SuSE, Red Hat, Debian, Mandrake, OpenBSD, Gentoo) endorsed the X.org project instead of XFree86. Soon all the developers had abandoned XFree86. This is however uncommon, 81% of studied forks did not cause the death of the original project. (Wheeler, 2007) Too many forks can also be confusing. Bob Young, the founder of Red Hat, states that too many UNIX forks existing is one of the main reasons why it doesn t have a bigger market share compared to Windows. Bob Young states the following in his essay Giving it away : If one Linux supplier adopts an innovation that becomes popular in the market, the other Linux vendors will immediately adopt that innovation. This is because they have access to the source code of that innovation and it comes under a license that allows them to use it. On closed source software new innovations cannot be copied immediately. They are usually patented and the technical specifications are not public.

11 Figure 3. Forks impact on original projects. Viseur (2012).

12 4. Examples of forked projects In this chapter we will take a look at two real-world examples of forking: LibreOffice, which started as a forked project from OpenOffice, and different Linux distributions which are common targets for forking. First we will take a look at the forks of Linux distributions. Then we will take a look at the forking that started LibreOffice. 4.1 Linux distributions GNU/Linux Distribution Timeline (GLDT) -project keeps track of Linux distributions. Earliest distributions on the timeline are from They provide a cladogram that visualises the GNU/Linux distribution forks on a timeline. The most forked distributions are Debian, Slackware and Red Hat. All of these distributions are still alive and very popular. The best known forked Linux distribution is Ubuntu Linux. The first version of Ubuntu was released by the UK-based company Canonical in 2004 and it s now probably the best known Linuxdistribution in the world. Ubuntu has also been forked numerous of times. Kubuntu is a well known Ubuntu fork, which has also been forked a few times. Total number of GNU/Linux distributions according to GLDT version is 480 distributions. The data is based on community reports, so there are most likely many more forks which have not been reported to GLDT. 4.2 LibreOffice LibreOffice was forked from OpenOffice.org-project, which was already owned by Sun Microsystems. OpenOffice was based on Sun s SunOffice s opened source code. When Sun was acquired by Oracle, the developers feared that it would discontinue the OpenOffice.org project or put restrictions on it. The fear was justified because Oracle had already put restrictions on Sun s OpenSolaris. (Clarke, 2010) Group of OpenOffice.org developers founded The Document Foundation. They then forked OpenOffice.org into LibreOffice in response of Oracle s acquisition of Sun Microsystems. Oracle was invited to join LibreOffice s development. The Document Foundation was hoping that Oracle would give the name OpenOffice to the foundation but they rejected. (OpenOffice.org Community announces The Document Foundation, 2010) Oracle announced in 2011 that they will abandon commercial OpenOffice.org development. Since then many companies have replaced OpenOffice.org with LibreOffice. Ubuntu and other popular Linux distributions were also changed to ship with LibreOffice instead of OpenOffice.org. (Paul, 2011)

13 5. Discussion There are multiple reasons for forking an open source software project. Most developers want to change the content of the original project in some way, adding or modifying it. Sometimes the original development team makes a fork just to test new features, which might break the main development branch. If changes prove successful, projects will be merged. Usually just another development branch in the repository would be enough, but some forks were explained by testing new features. This topic is somewhat under-researched and new so many studies don t exist at least yet. Nyman & Mikkonen (2011) and Viseur (2008) were the most valuable papers for our study, because they both searched for reasons and impacts for forking by doing empirical research on public source code repositories and examining multiple open source projects. Nyman and Mikkonen studied 381 open source software projects from SourceForge. Viseur studied only 26 popular open source software projects. The reasons and motivations for forking were similar whether or not the forked project was popular. Both papers are quite recent so little to no further research exists at this moment. We would have wanted to learn more about abandoned projects. The developers only mentioned that fork is based on some abandoned project. The interesting point is, why they didn t just restart the developing of the old project but fork it into a new one. This topic is quite new and open source software research altogether is a new research area. Forking would be an interesting topic for researchers to study more deeply.

14 6. Conclusions The goal of our paper was to study the reasons and motivations behind OSS forking and the technical and licensing aspects of it. We also wanted to examine the impact of OSS forking on the original project and show some current high profile open source projects that either started from a fork or are a common target for forks. There aren t many studies about forking yet. We found four articles that were based on open source project forks. The topic is interesting so we hope researchers are interested and make more studies about this. Forking is often considered to be a negative action, something that developers should fear and try to avoid as long as possible. Forking can be used as a weapon or a threat, if you don t do as I want, I will fork this project!. It is highly uncommon for a forked project to become more popular than the original but that has also happened. Forking can also conciliate the arguments between parties, when both see that the made changes were actually good. Reasons for forking vary, they can be technical: new features are wanted or old ones are modified. Reasons can relate to cultural or localization issues: the software is wanted in another language or culture. Licensing can also be a factor: software company could try to close the source code, forking can prevent that. Trademark issues are usually connected to the licensing issues. Restarting an abandoned project is another common reason for a fork: old, dead projects are forked and the development continues in a new project. Forking usually has four kinds of impacts on the original project. Either the forked or the original project will carry on and the other one dies. On some cases both of them gather their audience and they both keep on going. The forked and the original project can also merge after some time as we saw with the GCC/EGCS example. This happens usually when the forking is made after some kind of an argument. After both parties agree that they both did good efforts on the project, they will merge. Forking remains as a fascinating subject because of its varied uses. Forking can be used for both good as a tool but can also be the product of a disagreement that can potentially lead to the detriment of all parties involved. Hopefully future research will provide more insight into the subject as open source software development is only going to get more popular and the issue of forking will be relevant as long as OSS remains open.

15 References Dahlander, L. & Magnusson, M. (2008) How do Firms Make Use of Open Source Communities? Long Range Planning, vol. 41, n 6, Ernst, N., Easterbrook, S., and Mylopoulos, J. (2010) Code forking in open-source software: a requirements perspective. CoRR abs/ Fogel, K. (2010). Producing open source software. index.html, visited Fung, K., Aurum, A. and Tang, D. (2012) Social Forking in Open Source Software: An Empirical Study. CAiSE Forum 2012, Kogut, B., & Metiu, A. (2001). Open source software development and distributed innovation. Oxford Review of Economic Policy, 17(2), Lerner, J. & Tirole, J. (2005). The Scope of Open Source Licensing. Journal of Law, Economics, and Organization, vol. 21, issue 1, Nyman, L., and Mikkonen T. (2011). To Fork or Not to Fork: Fork Motivations in SourceForge Projects. IFIP Advances in Information and Communication Technology, 2011, Volume 365, Open Source Systems: Grounding Research, Viseur, R. (2012). Forks impacts and motivations in free and open source projects. International Journal of Advanced Computer Science and Applications, 3(2). Wheeler, D.A. (2007). Why Open Source Software / Free Software (OSS/ FS, FLOSS, or FOSS)? Look at the Numbers!. oss_fs_why.html, visited Young, R. (1999). Giving it Away: How Red Hat Software Stumbled Across a New Economic Model and Helped Improve an Industry text-idx?c=jep;view=text;rgn=main;idno= , visited GLDT - GNU/Linux Distribution Timeline. (2012). visited

16 Paul, R. (2011). Oracle gives up on OpenOffice after community forks the project. visited OpenOffice.org Community announces The Document Foundation. (2010). contact/tdf_release.html, visited Clarke, G. (2010). OpenOffice files Oracle divorce papers. visited