Summary. To fork a project is to copy the existing code base and move in a direction different than that of the erstwhile project leadership. Forking provides a rapid way to address new requirements by adapting an existing solution. However, it can also create a plethora of similar tools, and fragment the developer community. Hence, it is not always clear whether forking is the right strategy. In this paper, we describe a mixed-methods exploratory case study that investigated the process of forking a project. The study concerned the forking of an open-source tool for managing software projects, Trac. Trac was forked to address differing requirements in an academic setting. The paper makes two contributions to our understanding of code forking. First, our exploratory study generated several theories about code forking in open source projects, for further research. Second, we investigated one of these theories in depth, via a quantitative study. We conjectured that the features of the OSS forking process would allow new requirements to be addressed. We show that the forking process in this case was successful at fulfilling the new projects requirements. Traditionally, requirements analysis constitutes the initial phase of a software development project, and implementation the last. But what happens when a codebase already exists and serves as the starting point of software development? We study this question in the context of open source software. Open-source software (OSS) has proved its worth. OSS runs some of the largest web sites in the world (Apache), complex corporate servers (Linux/BSD), and is comparable to proprietary desktop application suites (OpenOffice) [1] . However, there remains a perception that OSS is not high-quality, and adoption of OSS in corporate IT environments is still low. Goode [2] , in his survey of Australian corporations, discusses several reasons for this. They include a perceived lack of support, hidden installation costs, and finally, a belief that corporate IT requirements are not met by any existing OSS tools. To fork a project is to copy the existing code base and move in a direction different than that of the erstwhile project leadership. Forking the codebase allows developers to leverage existing functionality while also addressing new requirements. Although flexible, forking has inherent difficulties, such as maintenance, evolution, and social factors concerning the development community. This paper looks at the form these take. To study the problem and evaluate potential solutions we focus on a software project management tool, Trac. Inasmuch as Trac had an original target audience, it was intended for developers in a corporate environment, then released more widely. In 2005 the tool was forked to support the development of a project that targeted undergraduate programming projects. This process, and its implications, are the subject of this research. We followed a two-phase, mixed-methods sequential approach [3] examining the interaction of forking and requirements. In the exploratory phase (Section 1.4.2), we qualitatively examined the nature of OSS, requirements, and forking by conducting surveys and interviews of participants from arXiv:1004.2889v1 [cs.SE] 16 Apr 2010 both the original and the forked project. Using grounded theory [4] methodology, we generated several theories about the problem. We then selected one theory and applied confirmatory analysis in the second phase. In this primarily quantitative segment, the theory we tested was whether some of the different requirements that motivated the fork were met. We analyzed this using two non-functional requirements. We first used a variety of code metrics of the two codebases (Section 1.5) to assess maintainability. Secondly, we used qualitative usability analyses to assess interface complexity, or usability. We designed this study as an exploratory one since there was a lack of detailed research regarding the forking of OSS to meet differing requirements. This way we generate some suitable research hypotheses for further testing. The second, more quantitative portion of the research examines whether code forking can successfully address certain new requirements. In some respects, we argue in Section 1.6, many of the theories we initially generated are best suited to qualitative or case study analysis. Our contribution is two-fold. One, we describe some of the process issues that arise when forking OSS. We provide theory patterns derived from the data that are a step towards more comprehensive theories about this process. Two, we describe a case study on a product of a fork, DrProject. In this case study we examined how well the forked tool could be adapted to meet new requirements, that didn't exist in the original. We begin with a brief introduction to the tools involved. To provide context, we then briefly review the literature. This research adds to the existing literature because few people have looked at opensource software from a requirements perspective (requirements are rarely mentioned in OSS; often a project is initiated due to perceived need). As well, there has been little work on the process of forking. The context of this study is the evolution of a software project management tool named Trac 1 . Trac is currently (as of January 2006) in version 0.9.3 and supports, among other things, Subversion repository integration, Wiki-enabled web pages, tickets and bug filing (a ticket is a to-do item assignable to project members). Trac is developed as an open-source project, under the leadership of two developers at Edgewall Software. In January of 2005 two faculty members at the University of Toronto (not involved in conducting this research) decided to fork Trac in order to support undergraduate programming. Trac was chosen, according to interviews with the proponents, for three reasons: 1) it was written in a familiar language (Python); 2) it had simple technology (CGI); 3) it had a small codebase and clean UI. The result of the fork, DrProject 2 , is the latest in a series of attempts to develop software to support student programming projects at the undergraduate level. Educators at the University of Toronto believed graduating students were leaving unaware of the importance of bug reports and version control. They determined that a tool should be developed to expand that pedagogical objective (notwithstanding reports that a large number of corporate software developers were equally unfamiliar with the tools). There have been a a number of previous attempts to develop such a tool at the University of Toronto (refer to Fig. 1.1 ). This latest iteration has been the most successful, with adoption by two separate courses, a self-hosted development project, and interest from academic research labs in the Department. We elicited the key requirements through interviews with the proponents. Functional 1 http://projects.edgewall.com/trac 2 http://pyre.third-bit.com/drproject requirements include, in addition to what Trac offers, multiple project support, test suite integration, and mailing list management. Non-functional requirements are for a codebase that is maintainable by students, and an interface that contains just those features that are necessary for short-duration software projects. These 'early' requirements are presented in the goal graph of Fig. 1.2 .  Research into the nature of open-source software has spawned a large degree of interest from a variety of disciplines, including economics, management, sociology, and software engineering [1, 6] . Source code accessibility opened the door to rich stores of data on software evolution, development styles, and community building, e.g., [7, 8] . There seems to be scant empirical work on the nature of forking in OSS, beyond discussions of psychological and sociological issues at play (for example, motivations for contributing to an OSS project). Most literature mentions forking as a pitfall, or something to be avoided e.g. [9] . There is mention of the process in several books, but it is mostly conjecture or anecdotal in nature, e.g., [10] . One useful distinction, albeit conjectured, is presented by Fogel [11]. He distinguishes between forks that happen due to fundamental differences in project goals (as is the case here), and those which are custody battles over the existing project. In this paper, we use the term to refer to situations where code from one project is duplicated in a different repository, and significant new requirements are added to the new project. This requirements-centric definition excludes downloaded code that receives minor alterations (e.g., a research tool for gene expression data). We are most interested in code that is altered to address new requirements. That is clearly the case in this project. There has been some research on requirements in OSS. Scacchi [12] looks at how requirements are handled in different OSS projects and provides a good look at differences between OSS communities and other models. For example, he makes the observation that in OSS, requirements are tightly integrated with tool design and implementation. Scacchi et al. [13] expand on the earlier paper with an ethnographic analysis of the requirements process in the NetBeans product. Our work differs in its focus on adapting existing tools to new requirements, rather than creating new tools based on (possibly emergent) requirements. Regarding the question of adapting OSS for corporate requirements, Bonaccorsi and Rossi [14] present a survey that suggests most corporate users of OSS adapt the tool to meet customer requirements without returning their contributions to the original project. Adams et al. [15] take a similar tack, but they describe how they adapt a tool using a plugin architecture, rather than working at the internal level of design, as was the case here. Finally, similar themes appear in fairly extensive research into COTS integration with project requirements, for example, [16, 17] . The main difference with OSS seems to be ability to a) leverage an existing community of enthusiasts, and b) gain full access to the codebase. Forking is relatively uncommon in open-source projects, perceptions notwithstanding. Two primary reasons are the open, accessible nature of OSS licences, and the social cost in splitting from an existing project. An example illustrates the first reason [18] . The gcc compiler team had decided not to support particular optimizations; another team forked the codebase, then went ahead and implemented the optimizations. This alternative proved popular, and the resulting project, egcs, was eventually merged back into the gcc tree. The second reason, social support, detailed in Raymond ([10], p. 84-87), is more common. Once a community has developed around a tool, it is difficult to create a variant of that tool and maintain the critical mass needed to keep the quality high. These concerns also appear in the qualitative studies we conducted.
Ernst et al. REF study forking of open source projects, which can be seen as a special form of inter-organizational cloning by putting whole codebases under another leadership.
Code forking in open-source software: a requirements perspective
ArXiv
ArXiv
Computer Science