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

Abstract

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.

Exploiting and Defending Open Digital Platforms with Boundary Resources: Android’s Five Platform Forks

“…Whereas Baldwin and Clark (2000) concentrate on economizing designs within vertical organizations by using modular operators, platform forking and the exploitative bundling of platform modules can be seen as an extension of the set of modular operators that operationalize the platform composition logics of ODPs and their ecosystems. Furthermore, our study extends past research on forking that has focused on processes of software forking (Robles and González-Barahona 2012) and their outcomes, such as fragmentation challenges (Parker and Van Alstyne 2009). Our study exposes, for the first time (to our knowledge), platform forking as an exploitative platform-level strategy, where a competing, hostile organization creates a forked alternative version of the entire platform.…”

“…Software forking (Robles and González-Barahona 2012) becomes a threat for an ODP if its core resources Technically, a fork is defined as an independent line of development (Robles and González-Barahona 2012) or as a separate pathway that "might remain similar in the code but under control by different programming groups" (Vetter 2016, p. 175). A wealth of economics literature views forking negatively, as it leads to incompatible code bases (Barnett 2011, Lerner and Tirole 2002, Simcoe and Watson 2016, Yoo 2016 and fragments the platform (Parker and Van Alstyne 2009).…”

A Screening Test for Disclosed Vulnerabilities in FOSS Components

“…During our study in [13], we also had informal interviews with software developers and maintenance experts of our industrial partner in order to better understand how the maintenance decisions about vulnerable FOSS components are typically made. As a result, we understood that such decisions are usually taken on ad-hoc, componentby-component basis: a component may be forked due to porting or changes to a subset of features; custom fixes for security bugs can be implemented and other technical modifications can be performed, if necessary [43], [44], [45].…”

How to Avoid Fork

“…Research on avoiding the fork has heretofore focused on developer motivation, licenses, and project governance (Ernst, Easterbrook, & Mylopoulos, 2010;Neville-Neil, 2011;Nyman & Mikkonen, 2011;Robles & Gonzalez-Barahona, 2012;Viseur, 2012). However, forking is a phenomenon not limited to OSS, and examples can be seen in Unix as well (Takahashi & Takamatsu, 2002.…”