Forking is the creation of a new software project by making a copy of artefacts from another project. Forking is gaining traction in industry because of the maturity of distributed version control systems and the abundance of open source software (OSS) and hosting platforms that support forking. However, forking in OSS is a poorly understood practice in research, often assumed to be damaging to the open source community. This research aims to explore social forking. It uses a conceptual model for forking centring on three key concepts forks (i.e. created projects), communities (i.e. groups of forks) and contributions (i.e. changes contributed from a forked project to the project from which its artefacts were copied) - to empirically analyse nine public domain JavaScript development communities in GitHub, a web site for hosting social coding. The analysis examined the relationships of these communities, the nature of forking, and the way in which forking and contributions were used in a social setting.
The open source software (OSS) initiative has provided an invaluable source of
learning for the software industry, running counter to many existing theories and
explanations [
Distributed revision control systems (DRCS) [
We do believe that forking has its importance and practicality in OSS
development. It, however, has received mixed reception in the literature and which is often
contingent on anecdotes and conjecture [
How is forking utilised to facilitate OSS development?
This research serves as a first step towards improving the understanding of forking in OSS and hopefully fuelling research in this direction for the benefit of OSS development by online communities. This paper is organised as follows. A review of the literature is given in Section 2. In Section 3, we describe our proposed conceptual model for social forking as a way to explain its key concepts. Section 4 presents our research methodology to empirically examine a web site that facilitates forking and OSS development, using our conceptual model as a guide. Section 5 provides our results and Section 6 presents our conclusions and a discussion of future work. 2
Forking is the creation of a new software project from the same code base as another
[
It has been claimed there is a strong taboo against forking [
Forking is seen to distance developers of an OSS community from the original
project from which forks were created (i.e. the forking project) and make them lose
interest in the project [
Forking has been touted as a danger to OSS development and its adoption [
On the positive side, forking permits specialisation of OSS for different needs [
In an OSS development environment, an individual has some freedom to fork a
project and choose to work on whatever part of the OSS suits his/her interest, agendas
and approaches [
To facilitate our investigation, we firstly define a conceptual model for social forking and its terminology. Forking is the task of creating a new software project from existing artefacts of another software project. Artefacts are not limited to source code. They can be anything related to the software that a project aims to develop, such as documentation, examples, test harnesses and third party libraries. The forked project (or simply the fork) can be used for enhancement, bug fixes, innovation and so on. A fork and the one from which it is forked forms a successor-predecessor relationship. A developer of a fork has a vested interest in the original project from which it was forked but the owner of the original project may not necessarily be aware of the forks created and their development activities.
When changes are made to the original project, the underlying DRCS notifies
coders of its forked projects about the changes. They may then review the changes and
incorporate them as an update to their forks as at their own pace, without any
involvement of the owner of the original project. The social aspect of forking comes
into play when social interaction occurs in order for a successor fork to make
contributions [
Forking is utilised at two layers of abstraction: endogenous and exogenous. Endogenous forking occurs within a community of social developers who work on forks for the same software product line. For instance, one creates a fork to enhance an existing feature of a software product. A fork tree for forks in a community can be represented as a tree structure. At the top of the tree is the master fork of the community from which all forks are created. Primary forks are those directly created from the master fork. Likewise, secondary forks are those created for primary forks.
Exogenous forking refers to the creation of forks across communities of social developers. Through exogenous forking, import and export relationships are established across community borders. In the former, a copy of a master fork in one community is imported into a master fork in another community. It can be used for bringing a copy of a third-party library into another project for creating a new software product. This import operation decouples activities of coders in one community from the other. The coders in the new community work with a baseline version or snapshot of the master fork, while those in the original community continue to evolve its master fork. Note also that the import operation only brings in whatever artefacts are required for the importing community. A more complex form of exogenous forking is to import forks from multiple communities into another community.
In an export relationship, artefacts in community B are purported to be an add-on or plug-in feature to artefacts in community A. Artefacts in B are essentially decoupled from those in B; the runtime code produced from artefacts in B can be run independently of those produced from A and vice versa. This independence also distinguishes between export and import relationships.
A fork is to a fork tree what a branch is to a version tree for version control
systems in which branches are created for auxiliary tasks to be carried out [
A three-step empirical study was carried out to examine the phenomenon of social forking using our conceptual model as an analysis framework. In step 1, we chose and examined Github (https://github.com/) since it is one of the top websites based on the number of OSS development projects hosted1. We started our search for communities (i.e. software repositories in Github) using JavaScript programming language since JavaScript was the most popular in GitHub (20%) and it might also increase our chance of finding exogenous forking. We then narrowed our selection to those with the highest number of forks which was indicative of a high level of social activities and a rich source of forking data. In step 2, we developed and ran a tool against each of the software repositories identified to extract data from them via GitHub’s public APIs (which are RESTful Web Services); to transform extracted data into a format based on our conceptual model; and to load the transformed data into a relational database. In step 3, the empirical data loaded in the database were explored to identify patterns of social forking. Our analysis of the results is presented next. 5
The top nine JavaScript development communities hosted by Github having the highest numbers of forks were selected and used in our empirical analysis in November 2011. We investigated the relationships of the communities by examining their documentation and the files in their repositories. The communities exhibit import and export relationships and there are two variants in the former. In one case a full copy of the artefacts from community A is imported into community B whereas in the other case only a subset of the artefacts from A were imported into B. Fig. 1 depicts the analysed communities and their relationships. The number labelled alongside each relationship instance represents the number of integration contributions made to a community as a result of maintaining the import/export relationships. This is further elaborated, together with the analysis of results for contributions, in Section 5.1. 5.1
All the communities we investigated had forks created at the primary and secondary levels, with two having forks at the tertiary level. Of the (7789) primary forks examined, 3.2% of them were used to create secondary forks and about the same ratio were used for the secondary forks. These figures are indicative that sub-communities were formed within the communities, which means developers participated in developing 1 http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities features in the primary forks through their secondary forks. We observed that some primary forks were created to develop brand new innovations in the community based on their respective master forks, but were not necessarily intended to be incorporated into their masters. For instance, “nodejsjp/node” is a primary fork for “joyent/node” for the purpose of developing a Japanese version of “joyent/node”. Indeed, these forks in conjunction with their successor forks formed sub-communities.
Of all the primary forks created, only 14% offered contributions to their respective master forks (11% for secondary to primary forks). A possible explanation for the high ratio of non-contributing forks (86% for primary and 89% for secondary) is that their developers were using forks to learn or experiment with the OSS’s features only. ajaxorg/ace joyent/node 2 Legend A A
B B
B imports A B exports to A madrobby/ scripta culous documentcl
oud/ backbone 7 1 jquery/ jquery jquery/ jquery-ui 10 0 26 h5bp/ html5boilerplate twitter/ bootstrap jquery/ jquerymobile The kinds of contributions made to each fork in the fork tree can be seen as a reflection of the ways in which their successor forks were used in each community. We analysed the titles and descriptions of over two thousand contributions and identified keywords which we subsequently used to categorise the contributions as defect fixes(43%), code enhancement(12%), documentation(7%), integration(2%), example enhancement(2%) and changes to test code and documentation(1%). The rest could not be categorised because of insufficient information. The integration category is triggered by the import relationship between two communities. For instance, when new features are added to artefacts in one community, they may also require import to the community that imported the original version of these artefacts. The artefacts in the latter community may also require changes to its artefacts in order to utilise the new features imported from the former community.
Of the contributions analysed from over one thousand contributing forks, the contribution rates (i.e. number of contributions divided by number of contributing forks) were 2.3 and 2.5 for contributing primary and secondary forks respectively. Note that contributions have the potential to be propagated further up the fork tree. This was evident from one case found during our examination of the contribution logs. A secondary fork (“flavaflav/jquery-mobile”) produced a contribution to its primary fork (“arsduo/jquery-mobile”) and the changes associated with that contribution were packaged as yet another contribution which was subsequently incorporated into the master fork (“jquery/jquery-mobile”). 5.3
Close to seven thousand developers created about eight thousand forks in the OSS communities analysed. We discovered some interesting behaviour of forking. In an extreme case one developer created forks in eight out of the nine communities analysed (i.e. working on projects in multi-communities). Six developers individually created more than one fork in the same community. This could be because each of these developers was using several forks to work on different parts of an OSS. 16% of developers made contributions to their OSS communities and from which we also identified some interesting behaviour of contribution. 5% of these developers made contributions to more than one community, with the top eight having made contributions to three communities. The most active developer made one hundred and fortythree contributions! The OSS community most attracted to contributions was jquery/jquery in which each developer created 3.3 contributions on average. 6
There has been a lack of critical studies into forking in OSS. In the literature there is a debate about whether or not forking should be used; some contend it as damaging to OSS development whilst some advocate its benefits to OSS communities and the OSS developed. To improve on this lack of knowledge about forking, we empirically investigated nine OSS communities from GitHub to gain an initial understanding of how it was used to facilitate OSS development in a social setting. It shows that forking was actively used by community participants for tasks such as fixing defects and creating innovations. “Forks of forks” were also utilised to form sub-communities within which specific aspects of an OSS product line were nurtured.
Since our study is in its infancy, we limited our analysis to one OSS hosting website, one programming language and nine communities, which poses validity threats to our findings. We thus plan to expand our study with additional web sites hosting OSS development (e.g. SourceForge, BitBucket, Gitorious) and interviews with OSS communities’ members to gain better understanding of their perspectives on social forking. The excitement around social forking combined with our research to date will hopefully invigorate future research in this area and increase its uptake in practice.