How to Avoid Fork

Abstract

Abstract: In terms of software, continuous of the software is the best quality assurance. Continuous development requires either the original developer to continue development, or the next generation of developers to take over the development. It has been noted that when the original developer has used a development paradigm in which the source code is kept open to all, highly motivated and competent developers will participate in development. This makes it easier for a project to survive. However, at the same time, when the source code is opened to a broad audience a in the source code tends to occur. When this happens, those with a high level of competence and motivation abandon the development and go their separate ways. In such a situation, it is difficult for a project to survive. In the case of Denshin 8 go, a guardian for the source code was appointed, and the original developer and the guardians avoided this dilemma. Richard Stallman of the GNU project and Linus Torvalds of Linux project act as legitimate guardians to avoid fork.Keywords: software development, open source, fork, buried source code, legitimate guardian, Denshin 8 goIntroductionFor software, continuous of the software is the best quality assurance (Ikuine 8s Fujita, 2013). Continuous development requires either the original developer to continue development or others to take over (Fujita 8s Ikuine, 2013b). When other developers take over, the original developer must share the source code with others. Open Source is a paradigm wherein the source code is shared and made broadly available to others. It has been noted that the project adopting open source can attract competent and highly motivated developers. Thus, some claim that developers can readily ensure the survival of software development projects when the source code is open.However, opening the source code to a broad audience can cause heterogeneity in the source code, even when people continue the development based on the original source code, a phenomenon known as fork (forking). In the case of open source software (hereinafter, OSS), literally anyone can obtain the source code and modify it to develop new software and start up new projects. Therefore, forks often occur in the OSS project, and the impact of forking has been studied for very long (Dibona, Ockman, 8s Stone, 1999; Kogut 8s Metiu, 2001; Nyman 8s Lindman, 2013; Nyman, Mikkonen, Lindman, 8s Fougere, 2012; Raymond, 1997, 1999). Moreover, some studies have focused on how to maintain forked projects, under the assumption that forking will inevitably occur (Gamalielesson 8s Lundell, 2013; Ray 8s Kim, 2012; Ray, Wiley, Kim, 2012).When forking does occur, competent and motivated developers start to abandon the project and go their separate ways, which may affect the survival of these projects. In other words, sharing the source code comes with a dilemma. If one loosens restrictions and shares the source code broadly, that project may survive; however, if the project is forked, competent successors with strong skills and desires will end up working on their own, or perhaps inter-project competition may lead to vying for competent successors. On the other hand, while establishing strict conditions and sharing the source code only with a select few may make the source code easy to control and reduce the possibility of forking, it may become more difficult to find competent successors willing to participate under those conditions. This puts the survival of the project at risk. Ensuring the survival of a project requires that one avoid this dilemma of source code sharing.Research on avoiding the has heretofore focused on developer motivation, licenses, and project governance (Ernst, Easterbrook, 8s Mylopoulos, 2010; Neville-Neil, 2011; Nyman 8s Mikkonen, 2011; Robles 8s Gonzalez-Barahona, 2012; Viseur, 2012). However, forking is a phenomenon not limited to OSS, and examples can be seen in Unix as well (Takahashi 8s Takamatsu, 2002, 2013). …