# Longitudinal Analysis of the Run-up to a Decision to Break-up (Fork) in a Community

Amirhosein “emerson” Azarbakht, Carlos Jensen

► To cite this version:

Amirhosein “emerson” Azarbakht, Carlos Jensen. Longitudinal Analysis of the Run-up to a Decision to Break-up (Fork) in a Community. 13th IFIP International Conference on Open Source Systems (OSS), May 2017, Buenos Aires, Argentina. pp.204-217, 10.1007/978-3-319-57735-7_19. hal-01776294

HAL Id: hal-01776294

https://inria.hal.science/hal-01776294

Submitted on 24 Apr 2018

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Longitudinal Analysis of the Run-up to a Decision to Break-Up (Fork) in a Community

Amirhosein “Emerson” Azarbakht, Carlos Jensen

Oregon State University, School of Electrical Engineering & Computer Science
1148 Kelley Engineering Center, Corvallis OR 97331, USA
{azarbaka,carlos.jensen}@oregonstate.edu

**Abstract.** In this paper, we use a developer-oriented statistical approach to understand what causes people in complex software development networks to decide to fork (break away), and what changes a community goes through in the run-up to a decision to break-up. Developing complex software systems is complex. Software developers interact. They may have the same or different goals, communication styles, or values. Interactions can be healthy or troubled. Troubled interactions cause troubled communities, that face failure. Some of these failures manifest themselves as a community split (known as forking). These failures affect many people; developers and users. Can we save troubled projects? We statistically model the longitudinal socio-grams of software developers and present early indicators and warning signs that can be used to predict an imminent break-up decision.

## 1 Introduction

Social networks are a ubiquitous part of our social lives, and the creation of online social communities has been a natural extension of this phenomena. Social media plays an important role in software engineering, as software developers use them to communicate, learn, collaborate and coordinate with others [32]. Free and Open Source Software (FOSS) development efforts are prime examples of how community can be leveraged in software development, where groups are formed around shared interest, and depend on continued interest and involvement to stay alive [25].

Community splits in free and open source software development are referred to as forks, and are relatively common [28]. Robles et al. [28] define forking as “when a part of a development community (or a third party not related to the project) starts a completely independent line of development based on the source code basis of the project.”

Although the bulk of collaboration and communication in FOSS communities occurs online and is publicly accessible for researchers, there are still many open questions about the social dynamics in FOSS communities. Projects may go through a metamorphosis when faced with an influx of new developers or the involvement of an outside organization. Conflicts between developers' divergent
visions about the future of the project may lead to forking of the project and dilution of the community. Forking, either as an acrimonious split when there is a conflict, or as a friendly divide when new features are experimentally added, affect the community [8].

Previous research on forking ranges from the study by Robles et al. [28] that identified 220 significant FOSS projects that have forked over the past three decades, and compiled a comprehensive list of the dates and reasons for forking to the study by Baishakhi et al. [7] on post-forking porting of new features or bug fixes from peer projects. It encompasses works of Nyman on developers' opinions about forking [27], developers motivations for performing forks [24], the necessity of code forking as tool for sustainability [26], and Syeed's work on sociotechnical dependencies in the BSD projects family [33].

Most existing research on forking, however, is post-hoc. It looks at the forking events in retrospect and tries to find the outcome of the fork; what happened after the fork happened. The run-up to the forking events are seldom studied. This leaves several questions unanswered: Was it a long-term trend? Was the community polarized, before forking happened? Was there a shift of influence? Did the center of gravity of the community change? What was the tipping point? Was it predictable? Is it ever predictable? We are missing that context.

Additionally, studies of FOSS communities tend to suffer from an important limitation. They treat community as a static structure rather than a dynamic process. Longitudinal studies on open source forking are rare. To better understand and measure the evolution, social dynamics of forked FOSS projects, and integral components to understanding their evolution and direction, we need new and better tools. Before making such new tools, we need to gain a better understanding of the context. With this knowledge and these tools, we could help projects reflect on their actions, and help community leaders make informed decisions about possible changes or interventions. It will also help potential sponsors make informed decisions when investing in a project, and throughout their involvement to ensure a sustainable engagement.

We use an actor-oriented longitudinal statistical model [30] to study the evolution and social dynamics of FOSS communities, and to investigate the driving forces in formation and dissolution of communities. This paper is a part of a larger study aiming to identify better measures for influence, shifts of influence, measures associated with unhealthy group dynamics, for example a simmering conflict, in addition to early indicators of major events in the lifespan of a community. One set of dynamics we are especially interested in, are those that lead FOSS projects to fork.

## 2 Related Work

The free and open source software development communities have been studied extensively. Researchers have studied the social structure and dynamics of team communications [9][16][17][18][23], identifying knowledge brokers and associated
activities [31], project sustainability [23][26], forking [25][3][4][5], requirement
satisfaction [13], their topology [9], their demographic diversity [20], gender
differences in the process of joining them [19], and the role of age and the core
team in their communities [1][2][6][12][35]. Most of these studies have tended
to look at community as a static structure rather than a dynamic process [11].
This makes it hard to determine cause and effect, or the exact impact of social
changes.

Post-forking porting of new features or bug fixes from peer projects happens
among forked projects [7]. A case study of the BSD family (i.e., FreeBSD,
OpenBSD, and NetBSD, which evolved from the same code base) found that
10-15% of lines in BSD release patches consist of ported edits, and on average
26-58% of active developers take part in porting per release. Additionally, They
found that over 50% of ported changes propagate to other projects within three
releases [7]. This shows the amount of redundant work developers need to do
to synchronize and keep up with development in parallel projects.

Visual exploration of the collaboration networks in FOSS communities was
the focus of a study that aimed to observe how key events in the mobile-device
industry affected the WebKit collaboration network over its lifetime. [34] They
found that *coopetition* (both competition and collaboration) exists in the open
source community; moreover, they observed that the “firms that played a more
central role in the WebKit project such as Google, Apple and Samsung were by
2013 the leaders of the mobile-devices industry. Whereas more peripheral firms
such as RIM and Nokia lost market-share” [34].

The study of communities has grown in popularity in part thanks to ad-
vances in social network analysis. From the earliest works by Zachary [36] to
the more recent works of Leskovec et al. [21][22], there is a growing body of
quantitative research on online communities. The earliest works on commu-
nities was done with a focus on information diffusion in a community [36].
The study by Zachary investigated the fission of a community; the process of
communities splitting into two or more parts. They found that fission could be
predicted by applying the Ford-Fulkerson min-cut algorithm [14] on the group's
communication graph; “the unequal flow of sentiments across the ties” and dis-
criminatory sharing of information lead to subcommunities with more internal
stability than the community as a whole.[36]

3 Research Goals

Social interactions reflect the changes the community goes through, and so, it
can be used to describe the context surrounding a forking event. Social inter-
actions in FOSS can happen, for example, in the form of mailing list email
correspondence, bug report issue follow-ups, and source code contributions and
co-authoring. We consider some forking decisions [28] to be socially related,
such that, they should have left traces in the developers' interactions data. Such
traces may be identified using longitudinal modeling of the interactions, without
digging into the contents of the communications. These three reasons are (1) Personal differences among developer team, (2) The need for more community-driven development, and (3) Technical differences for addition of functionality. In this study, we analyzed, quantified and visualized how a community is structured, how it evolves, and the degree to which community involvement changes over time. Our over-arching research objective was to identify these traces/social patterns associated with different types of undesirable forking

**R.G. 1:** Do forks leave traces in the collaboration artifacts of open source projects in the period leading up to the fork? To study the properties of possible social patterns, we need to verify their existence. More specifically, we need to check whether the possible social patterns are manifested in the collaboration artifacts of open source projects, e.g., mailing list data, issue tracking systems data, source code data. This is accomplished by statistical modeling of developer interactions as explained in more detail in section 4.

**R.G. 2:** What are the traces that can explain longitudinal changes in sociograms in run-up to a forking event? What quantitative measure(s) can be used as an early warning sign of an inflection point (fork)? Are there metrics that can be used to monitor the odds of change, (e.g. forking-related patterns) ahead of time? This will be accomplished by statistical modeling of developer interactions as explained in more detail in section 4.

# 4 Methodology

Detecting change patterns, requires gathering relevant data, cleaning it, and analyzing it. In the following subsections, we describe the proposed process in detail. Figure 1 shows the overview of our methodology.

## 4.1 Data Collection

The data collected were developer mailing lists, where developers' interact by sending and receiving emails, and source-code repository contribution logs, where developers interact by modifying the code. The sociograms were formed based on interactions among developers in these settings. For the purpose of our larger study, not included in this paper, we gathered data for 13 projects, in three categories of forking, plus a control group. We have included the data for a project that forked in 2010. The name is left out for anonymity, to prevent defaming a project, and to prevent individuals from becoming target of blame, in case our findings may be misused. Mailing list data was cleaned such that the sender and receiver email ID case-sensitivity differences would be taken into account, to prevent duplicity. The Source Code repository version control logs were used to capture the source code activity levels of the developers who had contributed more than a few commits. The set of the developers who had both mailing list activity and source code repository activity formed the basis of the
<figure><img src="image_2.png" /><figcaption>Fig. 1: The methodology in a glance</figcaption></figure>

socio-grams we used in our analysis. The time period for which data was col-
lected is one year leading to when the decision to break-up (fork) happened.
This should capture the social context of the run-up to the forking event.

Social connections and non-connections can be represented as graphs, in which the nodes represent actors (developers) and the edges represent the interaction(s) between actors or lack thereof. Such graphs can be a snapshot of a network – a static sociogram – or a changing network, also called a dynamic sociogram. In this phase, we process interactions data to form a communication sociogram of the community. Two types of analysis can be done on sociograms: Either a *cross-sectional* study, in which only one snapshot of the network is looked at and analyzed; or a *longitudinal* study, in which several consecutive snapshots of the network are looked at and studied. We are interested in patterns in the run-up to forks, therefore, unlike most existing research on forking, we did a longitudinal study. We formed 10 equispaced consecutive time-window snapshots of the socio-grams for the community, using the mailing list interaction data and the source code repository commit activity data. These socio-grams were used to find a well-fitting statistical model that would explain how they changed from time-window $t_1$ through time-window $t_{10}$.
## 4.2 The Statistical Model

Longitudinal evolution of a network data is the result of many small atomic changes occurring between the consecutively observed networks. In our case, software developers are the actors in the networks, and they can form a connection with another developer, break off an existing connection, or maintain their status quo. These are the four possibilities of atomic change within our evolving networks: (1) forming a new tie; (2) breaking off an existing tie; (3) maintaining a non-connection; and (4) maintaining a connection. We assume a continuous-time network evolution, even though our observations are made at two or more discrete time points.

The state-of-the-art in studying longitudinal social networks, is the idea of *actor-oriented models* [30], based on a model of developers changing their outgoing ties as a consequence of a stochastic optimization of an *objective function*. This framework assumes that the observed networks at discrete times, are outcomes of a continuous-time Markov process. In the case of open source developers, the actor-oriented model, can be informally described as OpenSourceDeveloper-oriented model, in which, it is assumed that developers are in charge of their communication and collaboration choices. They choose to have interactions with certain other developers and/or they choose to stop having interactions with another developer. In short, they have autonomy in choosing their connections.

Let the data for our statistical developer-oriented model be *M* repeated observations on a network with *g* developers. The *M* observed networks (at least two) are represented as directed graphs with adjacency matrices *X*(*t*<sub>m</sub>) = (*X*<sub>*ij*</sub>(*t*<sub>m</sub>)) for *m* = 1, ..., *M*, where *i* and *j* range from a to *g*. The variable *X*<sub>*ij*</sub> shows whether at time *t* there exists a tie from *i* to *j* (value 1) or not (value 0). Be definition, ∀*i*, *X*<sub>*ii*</sub> = 0 (i.e. the diagonal of the adjacency matrices).

In order to model the network evolution from *X*(*t*<sub>1</sub>) to *X*(*t*<sub>2</sub>), and so on, it is natural to treat the network dynamics as the result of a series of small atomic changes, and not bound to the observation moment, but rather as a more of less continuous process. In this way, the current network structure is a determinant of the likelihood of the changes that might happen next [10].

For each change, the model focuses on the developer whose tie is changing. We assume that developer *i* has control over the set of outgoing tie variables (*X*<sub>*i*1</sub>, ..., *X*<sub>*ig*</sub>) (i.e. the *i*th row of the adjacency matrix). The network changes one tie at a time. We call such an atomic change a *ministep*. The moment at which developer *i* changes one of his ties, and the kind of change that he makes, can depend on attributes represented by observed covariates, and the network structure. The moment is stochastically determined by the *rate function*, and the particular change to make, is determined by the *objective function* and the *gratification function*. We cannot calculate this complex model exactly. Rather than calculating exactly, we estimate it using a Monte Carlo Markov Chain method. The estimated model is used to test hypotheses about the forked FOSS
communities. These above three functions and their definitions taken from [29] are explained in detail the following subsections.

**4.2.1 Rate Function** The *rate function* $\lambda_i(x)$ for developer $i$ is the rate at which developer $i$'s outgoing connections changes occur. It models how frequently the developers make ministeps. The rate function is formally defined [29] by

$$ \lambda_i(x) = \lim_{dt \to 0} \frac{1}{dt} P(X_{ij}(t+dt) \neq X_{ij}(t) \text{ for some } j \in \{i, \dots, g\} | X(t) = x). \quad (1) $$

The simplest specification of the rate of change is that all developers have the same rate of change of their ties.

**4.2.2 Objective Function** The *objective function* $f_i(s)$ for developer $i$ is the value attached to the network configuration $x$. The idea is that, given the opportunity to make a change in his outgoing tie variables ($X_{i1}, \dots, X_{ig}$), developer $i$ selects the change that gives the greatest increase in the objective function. We assume that if there is difference between developers in their objective functions, these differences can be represented based on the model covariates [29]. For more details, please refer to [29]. The following weighted sum represents the objective function (2):

$$ f_i(\beta, x) = \sum_{k=1}^{L} \beta_k s_{ik}(x) \quad (2) $$

Parameters $\beta = (\beta_1, \dots, \beta_L)$ is to be estimated. Functions $s_{ik}(x)$ can be the following [29]:

**4.2.2.1 Structural Effects** For the structural effects, the following were used in the objective function.

1. The reciprocity effect, which reflects the tendency toward reciprocation of connections. A high value for its model parameter will indicate a high tendency of developers for reciprocated interactions.

2. The closure effects (e.g. in friendship networks, it means, friends of friends tend to become friends) In our case, Transitive triplets effect, which models the tendency toward network closure. It reflects the preference of developers to be connected to developers with similar outgoing ties.

3. Three-cycles, may be interpreted as the tendency toward local hierarchy. It is similar to reciprocity defined for three developers, and is the opposite of hierarchy.

4. Activity, which reflects the tendency of developers with high in-degree/out-degrees to send out more outgoing connections because of their current high in-degree/out-degree.
5. Covariate effects: Developers' covariates may influence the formation or termination of ties. For example: (a) Covariate V-related activity, which reflects the developer i's out-degree multiplied by his covariate V value. (b) Covariate V-related dissimilarity, which reflects the sum of differences in covariate V values' between developer i and all developers to whom developer i is connected. We use the following developer attributes as covariates:

- (Covariate V1) Developer's level of activity (i.e. mailing list posts per month)

- (Covariate V1) Developer's level of contribution (i.e. code commits per month) as shown in Table 2.

- (Covariate V4) Developer's seniority as a development community member (i.e. how many total contributions they have had in the lifetime of the project)

6. out-out degree assortativity, which reflects which reflects the tendency of developers with high out-degree to be connected to other developers with high out-degrees

**4.2.3 Markov Chain Transition Rate Matrix** The components of the developers-oriented model, described above, define a continuous-time Markov chain on the space $\chi$ of all directed graphs on this set of $g$ developers. This Markov chain is used to estimate the model parameters stochastically, instead of calculating them exactly, which is not possible for us. This Markov chain has a transition rate matrix. The transition rate matrix (also called intensity matrix), for this model is given by expression (3):

$$ q_{ij}(x) = \lim_{dt \to 0} \frac{1}{dt} P(X(t+dt) = X(i \mapsto j) | X(t) = x) = \lambda_i(x)p_{ij}(x) \quad (3) $$

Expression (3) shows the rate at which developer $i$ makes ministeps, multiplied by the probability that he changes the arc variable $X_{ij}$, if he makes a ministep. Our Markov chain can be simulated by following the steps explained in [29].

**4.2.4 Markov Chain Monte Carlo (MCMC) Estimation** The described statistical model for longitudinal analysis of open source software development communities is a complex model and cannot be exactly calculated, but it can be stochastically estimated. We can simulate the longitudinal evolution, and estimate the model based on the simulations. Then we can choose an estimated model that has a good fit to the network data. For details of the simulation and estimation procedures please refer to [29]. The desirable outcome for the estimation is the vector parameter $\hat{\beta}$ for which the expected and the observed vectors are the same.
<table><caption>Table 1: Parameter estimates</caption><thead><tr><th>Effect</th><th>par. (s.e.)</th></tr></thead><tbody><tr><td>Rate 1</td><td>1.419 (0.402)</td></tr><tr><td>Rate 2</td><td>2.633 (0.919)</td></tr><tr><td>Rate 3</td><td>3.231 (1.222)</td></tr><tr><td>Rate 4</td><td>11.656 (7.158)</td></tr><tr><td>Rate 5</td><td>5.238 (1.871)</td></tr><tr><td>Rate 6</td><td>5.431 (1.901)</td></tr><tr><td>Rate 7</td><td>1.863 (0.520)</td></tr><tr><td>Rate 8</td><td>0.791 (0.258)</td></tr><tr><td>Rate 9</td><td>0.671 (0.206)</td></tr><tr><td>outdegree (density)*</td><td>-5.389 (0.300)</td></tr><tr><td>reciprocity</td><td>-6.448 (31.754)</td></tr><tr><td>transitive triplets</td><td>-0.582 (0.875)</td></tr><tr><td>3-cycles</td><td>-2.680 (8.084)</td></tr><tr><td>out-out degree(1/2) assortativity*</td><td>1.123 (0.291)</td></tr><tr><td>devScAct alter*</td><td>-0.021 (0.009)</td></tr><tr><td>devScAct ego*</td><td>0.011 (0.003)</td></tr><tr><td>devScAct ego x devScAct alter</td><td>-0.000 (0.000)</td></tr><tr><td>devMIAct alter</td><td>0.141 (0.010)</td></tr><tr><td>devMIAct ego</td><td>-0.037 (0.051)</td></tr><tr><td>devMIAct ego x devMIAct alter</td><td>0.002 (0.003)</td></tr><tr><td>int. devMIAct ego x devScAct ego*</td><td>0.003 (0.002)</td></tr></tbody></table>

# 5 Results

The results of parameter estimation are listed in Table 1. The parameter estimates that are statistically significant are marked with an asterisk (*) in Table 1. Recall that the weighted sum in expression (2) represents our objective function, and the effects listed in Table 1 are the parameter estimates of $\beta_k$'s in expression (2).

The rate parameters represent the rate of change for the period between $t_1$ to $t_2$ for developers (i.e. how likely developers were to change ties in that time period). There's a clear trend in the rates 1-9, with a peak of 11.65 for the $t_4$ to $t_5$ time period. This suggests a significantly higher “preference” by developers for (a) forming new ties and interacting with previously non-connected developers and (b) terminating a previously connected tie. This peak value dies down as to less than 1, for the $t_8$ to $t_9$ time period at 0.79 which can be used as an early warning sign of an imminent change decision.

# 6 Conclusion

In this study, we used a developer-oriented approach to statistically model the changes a FOSS community goes through in the run-up to a fork. The model represented tie formation, breakage, and maintenance between developers. We use 10 snapshots of the graph as observed data to estimate the influence of several effects on formation of the observed networks. We used a stochastic estimation method to estimate several model parameters of the model and used
a Wald-type t-test to estimate the significance of these parameters on this lon-
gitudinal change.

The results show that the out-out degree assortativity and the outdegree (density) effects are statistically significant, which can be interpreted that developers maintained a “preference” for interacting with developers who had similar outdegree levels. For example, core developers with high levels of mailing list activity responding to messages, were more likely to be connected to other similarly behaving high-outdegree developers. Also, that top answerer/repliers on the mailing list were more likely to contact other top developers, and the community shows a preference for inter-stratum ties.

The developers’ source code repository contribution level (devScAct ego) was also statistically significant, which implies developers with higher levels of source code contributions increase their outdegree more rapidly. The developers’ source code repository contribution level (devScAct alter) is also statistically significant, which implies developers with higher levels of source code contributions increase their indegree more rapidly.

Perhaps, an interesting observation is the existence of significance for high activity/contribution to the source code repository, however, in contrast, there's a lack of significance for high activity on the mailing list. In summary, high levels of contribution to the source code brings you connections more rapidly, while high levels of contributions to the mailing list is not suggestive of this. This can be interpreted as a sign of meritocracy based on code, rather than talk, which captures a healthy dynamic in this project, that was forked because of addition of functionality, and was classified as a healthy fork.

7 Threats to Validity

The study findings may not be generalized. First, one reason is that the projects
is this research study were selected from a pool of candidate projects, based on
a filtering criteria that included availability of their data. Given access, a larger
number of projects as the sample size could result in a more robust investigation.

Second, we used data from online communications. The assumption that all
the communication can be captured by mining repositories is intuitively imper-
fect, but inevitable. Third, social interactions data is noisy, and our statistical
approach might be affected because of this.

Third, the statistical model we use to model the longitudinal evolution of
collaboration networks is estimated stochastically, rather than being calculated
exactly. The stochastic process might not always arrive at the same results. To
counter this issue, we run the algorithm several times to double-check for such
irregularities.
References

1. Azarbakht, A. and C. Jensen, "Drawing the Big Picture: Temporal Visualization of Dynamic Collaboration Graphs of OSS Software Forks," Proc. 10th Int'l. Conf. Open Source Systems, 2014.

2. Azarbakht, A. and C. Jensen, "Temporal Visualization of Dynamic Collaboration Graphs of OSS Software Forks," Proc. Int'l. Network for Social Network Analysis Sunbelt XXXIV Conf., 2014.

3. Azarbakht, A., "Drawing the Big Picture: Analyzing FLOSS Collaboration with Temporal Social Network Analysis," Proc. 9th Int'l. Symp. Open Collaboration, ACM, 2013.

4. Azarbakht, A. and C. Jensen, "Analyzing FOSS Collaboration & Social Dynamics with Temporal Social Networks," Proc. 9th Int'l. Conf. Open Source Systems Doct. Cons., 2013.

5. Azarbakht, A., "Temporal Visualization of Collaborative Software Development in FOSS Forks," Proc. IEEE Symp. Visual Languages and Human-Centric Computing, 2014.

6. Azarbakht, E. A., "Longitudinal Analysis of Collaboration Graphs of Forked Open Source Software Development Projects Using An Actor-oriented Social Network Analysis," Proc. Int'l. Network for Social Network Analysis Sunbelt conf., 2016.

7. Baishakhi R., C. Wiley, and M. Kim, "REPERTOIRE: a cross-system porting analysis tool for forked software projects," Proc. ACM SIGSOFT 20th Int'l. Symp. Foundations of Software Engineering, ACM, 2012.

8. Bezrukova, K., C. S. Spell, J. L. Perry, "Violent Splits Or Healthy Divides? Coping With Injustice Through Faultlines," Personnel Psychology, Vol 63, Issue 3. 2010.

9. Bird, C., D. Pattison, R. D'Souza, V. Filkov, and P. Devanbu, "Latent social structure in open source projects," Proc. 16th ACM SIGSOFT Int'l. Symposium on Foundations of software engineering, ACM, 2008.

10. Coleman, J.S. "Introduction to Mathematical Sociology," New York etc.: The Free Press of Glencoe. 1964.

11. Crowston, K., K. Wei, J. Howison, and A. Wiggins. "Free/Libre open-source software development: What we know and what we do not know," ACM Computing Surveys, 44, 2, Article 7, 2012.

12. Davidson, J., R. Naik, A. Mannan, A. Azarbakht, C. Jensen, "On older adults in free/open source software: reflections of contributors and community leaders," Proc. IEEE Symp. Visual Languages and Human-Centric Computing, 2014.

13. Ernst, N., S. Easterbrook, and J. Mylopoulos, "Code forking in open-source software: a requirements perspective," arXiv preprint arXiv:1004.2889, 2010.

14. Ford, L. R. and D. R. Folkerson, "A simple algorithm for finding maximal network flows and an application to the Hitchcock problem," Canadian Journal of Mathematics, vol. 9, pp. 210-218, 1957.

15. Forrest, D., C. Jensen, N. Mohan, and J. Davidson, "Exploring the Role of Outside Organizations in Free/ Open Source Software Projects," Proc. 8th Int'l. Conf. Open Source Systems, 2012.

16. Guzzi, A., A. Bacchelli, M. Lanza, M. Pinzger, and A. van Deursen, "Communication in open source software development mailing lists," Proc. 10th Conf. on Mining Software Repositories, IEEE Press, 2013.

17. Howison, J., K. Inoue, and K. Crowston, "Social dynamics of free and open source team communications," Proc. Int'l. Conf. Open Source Systems, 2006.
18. Howison, J., M. Conklin, and K. Crowston, "FLOSSmole: A collaborative repository for FLOSS research data and analyses," Int'l. Journal of Information Technology and Web Engineering, 1(3), 17-26. 2006.

19. Kuechler, V., C. Gilbertson, and C. Jensen, "Gender Differences in Early Free and Open Source Software Joining Process," Open Source Systems: Long-Term Sustainability, 2012.

20. Kunegis, J., S. Sizov, F. Schwagereit, and D. Fay, "Diversity dynamics in online networks," Proc. 23rd ACM Conf. on Hypertext and Social Media, 2012.

21. Leskovec, J., Kleinberg, J., and Faloutsos, C.: "Graphs over time: densification laws, shrinking diameters and possible explanations," Proc. SIGKDD Int'l. Conf. Knowledge Discovery and data Mining, 2005.

22. Leskovec, J., K. J. Lang, A. Dasgupta, and M. W. Mahoney, "Statistical properties of community structure in large social and information networks," Proc. 17th Int'l. Conf. World Wide Web, ACM, 2008.

23. Nakakoji, K., Y. Yamamoto, Y. Nishinaka, K. Kishida, and Y. Ye. "Evolution patterns of open-source software systems and communities," Proc. Int'l. Workshop Principles of Software Evolution, ACM, 2002.

24. Mikkonen, T., L. Nyman, "To Fork or Not to Fork: Fork Motivations in Source-Forge Projects," Int'l. J. Open Source Softw. Process. 3, 3. July, 2011.

25. Nyman, L., "Understanding code forking in open source software," Proc. 7th Int'l. Conf. Open Source Systems Doct. Cons., 2011.

26. Nyman, L., T. Mikkonen, J. Lindman, and M. Fougère, "Forking: the invisible hand of sustainability in open source software," Proc. SOS 2011: Towards Sustainable Open Source, 2011.

27. Nyman, L., "Hackers on Forking," Proc. Int'l. Symp. on Open Collaboration, 2014.

28. Robles, G. and J. M. Gonzalez-Barahona, "A comprehensive study of software forks: Dates, reasons and outcomes," Proc. 8th Int'l. Conf. Open Source Systems, 2012.

29. Snijders, Tom AB. "Models for longitudinal network data," Models and methods in social network analysis 1: 215-247. 2005.

30. Snijders, Tom AB., GG Van de Bunt, CEG Steglich, "Introduction to stochastic actor-based models for network dynamics," Social networks 32 (1), 44-60. 2010.

31. Sowe, S., L. Stamelos, and L. Angelis, "Identifying knowledge brokers that yield software engineering knowledge in OSS projects," Information and Software Technology, vol. 48, pp. 1025-1033, Nov 2006.

32. Storey, M., L. Singer, B. Cleary, F. Figueira Filho, and A. Zagalsky, "The (R) Evolution of social media in software engineering," Proc. Future of Software Engineering, ACM, 2014.

33. Syeed, M. M., "Socio-Technical Dependencies in Forked OSS Projects: Evidence from the BSD Family," Journal of Software 9.11 (2014): 2895-2909. 2014.

34. Teixeira, J., and T. Lin, "Collaboration in the open-source arena: the webkit case," Proc. 52nd ACM conf. Computers and people research (SIGSIM-CPR '14). ACM, 2014.

35. Torres, M. R. M., S. L. Toral, M. Perales, and F. Barrero, "Analysis of the Core Team Role in Open Source Communities," Int. Conf. on Complex, Intelligent and Software Intensive Systems, IEEE, 2011.

36. Zachary, W., "An information flow model for conflict and fission in small groups," Journal of Anthropological Research, vol. 33, no. 4, pp. 452-473, 1977.
<table><caption>Table 2: The list of developers source code contributions in the 10 months run-up to the forking event, sorted by total number of commits.</caption><thead><tr><th>Developer</th><th>t1</th><th>t2</th><th>t3</th><th>t4</th><th>t5</th><th>t6</th><th>t7</th><th>t8</th><th>t9</th><th>t10</th><th>Sum t1..t10</th></tr></thead><tbody><tr><td>1 Anonymized Developer #1</td><td>17</td><td>54</td><td>48</td><td>22</td><td>86</td><td>298</td><td>238</td><td>154</td><td>136</td><td>210</td><td>1263</td></tr><tr><td>2 Anonymized Developer #2</td><td>55</td><td>100</td><td>42</td><td>58</td><td>74</td><td>156</td><td>120</td><td>16</td><td>44</td><td>4</td><td>669</td></tr><tr><td>3 Anonymized Developer #3</td><td>7</td><td>34</td><td>12</td><td>70</td><td>64</td><td>70</td><td>8</td><td>38</td><td>146</td><td>118</td><td>567</td></tr><tr><td>4 Anonymized Developer #4</td><td>21</td><td>163</td><td>54</td><td>138</td><td>64</td><td>46</td><td>38</td><td>36</td><td>0</td><td>4</td><td>564</td></tr><tr><td>5 Anonymized Developer #5</td><td>38</td><td>190</td><td>6</td><td>26</td><td>40</td><td>14</td><td>10</td><td>30</td><td>34</td><td>36</td><td>424</td></tr><tr><td>6 Anonymized Developer #6</td><td>21</td><td>0</td><td>20</td><td>58</td><td>59</td><td>35</td><td>48</td><td>41</td><td>24</td><td>80</td><td>386</td></tr><tr><td>7 Anonymized Developer #7</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>36</td><td>42</td><td>47</td><td>143</td><td>15</td><td>283</td></tr><tr><td>8 Anonymized Developer #8</td><td>23</td><td>22</td><td>9</td><td>87</td><td>72</td><td>1</td><td>1</td><td>0</td><td>0</td><td>0</td><td>215</td></tr><tr><td>9 Anonymized Developer #9</td><td>8</td><td>60</td><td>53</td><td>55</td><td>3</td><td>1</td><td>0</td><td>0</td><td>12</td><td>0</td><td>192</td></tr><tr><td>10 Anonymized Developer #10</td><td>0</td><td>0</td><td>3</td><td>81</td><td>39</td><td>12</td><td>4</td><td>8</td><td>2</td><td>4</td><td>153</td></tr><tr><td>11 Anonymized Developer #11</td><td>0</td><td>0</td><td>0</td><td>0</td><td>8</td><td>60</td><td>1</td><td>6</td><td>14</td><td>23</td><td>112</td></tr><tr><td>12 Anonymized Developer #12</td><td>2</td><td>47</td><td>30</td><td>1</td><td>7</td><td>2</td><td>0</td><td>8</td><td>0</td><td>0</td><td>97</td></tr><tr><td>13 Anonymized Developer #13</td><td>0</td><td>0</td><td>3</td><td>0</td><td>0</td><td>0</td><td>11</td><td>13</td><td>1</td><td>63</td><td>91</td></tr><tr><td>14 Anonymized Developer #14</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>8</td><td>38</td><td>40</td><td>86</td></tr><tr><td>15 Anonymized Developer #15</td><td>3</td><td>35</td><td>33</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>72</td></tr><tr><td>16 Anonymized Developer #16</td><td>3</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>4</td><td>17</td><td>46</td><td>0</td><td>70</td></tr><tr><td>17 Anonymized Developer #17</td><td>0</td><td>3</td><td>0</td><td>25</td><td>40</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>68</td></tr><tr><td>18 Anonymized Developer #18</td><td>0</td><td>0</td><td>0</td><td>55</td><td>0</td><td>9</td><td>0</td><td>1</td><td>0</td><td>1</td><td>66</td></tr><tr><td>19 Anonymized Developer #19</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>4</td><td>21</td><td>17</td><td>23</td><td>65</td></tr><tr><td>20 Anonymized Developer #20</td><td>0</td><td>0</td><td>0</td><td>9</td><td>15</td><td>14</td><td>11</td><td>2</td><td>6</td><td>0</td><td>57</td></tr><tr><td>21 Anonymized Developer #21</td><td>13</td><td>1</td><td>3</td><td>3</td><td>0</td><td>12</td><td>17</td><td>2</td><td>0</td><td>0</td><td>51</td></tr><tr><td>22 Anonymized Developer #22</td><td>8</td><td>18</td><td>12</td><td>0</td><td>0</td><td>0</td><td>0</td><td>3</td><td>4</td><td>0</td><td>45</td></tr><tr><td>23 Anonymized Developer #23</td><td>0</td><td>0</td><td>9</td><td>6</td><td>0</td><td>0</td><td>1</td><td>3</td><td>1</td><td>24</td><td>44</td></tr><tr><td>24 Anonymized Developer #24</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>13</td><td>16</td><td>3</td><td>4</td><td>36</td></tr><tr><td>25 Anonymized Developer #25</td><td>5</td><td>20</td><td>10</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>35</td></tr><tr><td>26 Anonymized Developer #26</td><td>1</td><td>0</td><td>11</td><td>2</td><td>14</td><td>7</td><td>0</td><td>0</td><td>0</td><td>0</td><td>35</td></tr><tr><td>27 Anonymized Developer #27</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>4</td><td>14</td><td>3</td><td>13</td><td>34</td></tr><tr><td>28 Anonymized Developer #28</td><td>3</td><td>12</td><td>4</td><td>1</td><td>5</td><td>0</td><td>0</td><td>1</td><td>1</td><td>4</td><td>31</td></tr><tr><td>29 Anonymized Developer #29</td><td>0</td><td>0</td><td>0</td><td>26</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>27</td></tr><tr><td>30 Anonymized Developer #30</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>26</td><td>26</td></tr><tr><td>31 Anonymized Developer #31</td><td>0</td><td>0</td><td>0</td><td>0</td><td>3</td><td>8</td><td>7</td><td>0</td><td>0</td><td>8</td><td>26</td></tr><tr><td>32 Anonymized Developer #32</td><td>0</td><td>0</td><td>0</td><td>0</td><td>10</td><td>13</td><td>0</td><td>1</td><td>0</td><td>0</td><td>24</td></tr><tr><td>33 Anonymized Developer #33</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>19</td><td>2</td><td>2</td><td>0</td><td>23</td></tr><tr><td>34 Anonymized Developer #34</td><td>0</td><td>0</td><td>0</td><td>16</td><td>7</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>23</td></tr><tr><td>35 Anonymized Developer #35</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>2</td><td>19</td><td>0</td><td>0</td><td>21</td></tr><tr><td>36 Anonymized Developer #36</td><td>0</td><td>8</td><td>11</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>19</td></tr><tr><td>37 Anonymized Developer #37</td><td>0</td><td>0</td><td>0</td><td>18</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>18</td></tr><tr><td>38 Anonymized Developer #38</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>17</td><td>0</td><td>0</td><td>0</td><td>17</td></tr><tr><td>39 Anonymized Developer #39</td><td>0</td><td>0</td><td>0</td><td>11</td><td>6</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>17</td></tr><tr><td>40 Anonymized Developer #40</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>2</td><td>0</td><td>12</td><td>14</td></tr><tr><td>41 Anonymized Developer #41</td><td>3</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>9</td><td>13</td></tr><tr><td>42 Anonymized Developer #42</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>7</td><td>2</td><td>2</td><td>2</td><td>13</td></tr><tr><td>43 Anonymized Developer #43</td><td>2</td><td>0</td><td>0</td><td>3</td><td>0</td><td>1</td><td>1</td><td>0</td><td>1</td><td>5</td><td>13</td></tr><tr><td>44 Anonymized Developer #44</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>8</td><td>5</td><td>0</td><td>13</td></tr><tr><td>45 Anonymized Developer #45</td><td>1</td><td>2</td><td>0</td><td>5</td><td>1</td><td>0</td><td>0</td><td>1</td><td>3</td><td>0</td><td>13</td></tr><tr><td>46 Anonymized Developer #46</td><td>0</td><td>0</td><td>0</td><td>0</td><td>4</td><td>5</td><td>3</td><td>0</td><td>1</td><td>0</td><td>13</td></tr><tr><td>47 Anonymized Developer #47</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>3</td><td>9</td><td>0</td><td>12</td></tr><tr><td>48 Anonymized Developer #48</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>10</td><td>1</td><td>0</td><td>0</td><td>11</td></tr><tr><td>49 Anonymized Developer #49</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>1</td><td>10</td><td>0</td><td>0</td><td>11</td></tr><tr><td>50 Anonymized Developer #50</td><td>0</td><td>6</td><td>5</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>11</td></tr><tr><td>51 Anonymized Developer #51</td><td>0</td><td>0</td><td>2</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>8</td><td>11</td></tr><tr><td>52 Anonymized Developer #52</td><td>0</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>6</td><td>2</td><td>0</td><td>0</td><td>9</td></tr><tr><td>53 Anonymized Developer #53</td><td>0</td><td>0</td><td>0</td><td>4</td><td>4</td><td>0</td><td>0</td><td>0</td><td>0</td><td>1</td><td>9</td></tr><tr><td>54 Anonymized Developer #54</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>9</td><td>9</td></tr><tr><td>55 Anonymized Developer #55</td><td>1</td><td>0</td><td>0</td><td>0</td><td>1</td><td>6</td><td>0</td><td>0</td><td>0</td><td>0</td><td>8</td></tr><tr><td>56 Anonymized Developer #56</td><td>1</td><td>6</td><td>1</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>8</td></tr><tr><td>57 Anonymized Developer #57</td><td>1</td><td>7</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>8</td></tr><tr><td>58 Anonymized Developer #58</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>8</td><td>8</td></tr><tr><td>59 Anonymized Developer #59</td><td>0</td><td>0</td><td>0</td><td>2</td><td>4</td><td>0</td><td>0</td><td>0</td><td>0</td><td>0</td><td>6</td></tr></tbody></table>