# Quantitative Analysis of Community Evolution in Developer Social Networks
Around Open Source Software Projects

Liang Wang, Ying Li, Jierui Zhang, Xianping Tao  State Key Laboratory for
Novel Software TechnologyNanjing University, NanjingChina<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
###### Abstract.

Understanding the evolution of communities in developer social networks (DSNs)
around open source software (OSS) projects can provide valuable insights about
the socio-technical process of OSS development. Existing studies show the
evolutionary behaviors of social communities can effectively be described
using patterns including split, shrink, merge, expand, emerge, and extinct.
However, existing pattern-based approaches are limited in supporting
quantitative analysis, and are potentially problematic for using the patterns
in a mutually exclusive manner when describing community evolution. In this
work, we propose that different patterns can occur simultaneously between
every pair of communities during the evolution, just in different degrees.
Four entropy-based indices are devised to measure the degree of community
split, shrink, merge, and expand, respectively, which can provide a
comprehensive and quantitative measure of community evolution in DSNs. The
indices have properties desirable to quantify community evolution including
monotonicity, and bounded maximum and minimum values that correspond to
meaningful cases. They can also be combined to describe more patterns such as
community emerge and extinct. We conduct experiments with real-world OSS
projects to evaluate the validity of the proposed indices. The results suggest
the proposed indices can effectively capture community evolution, and are
consistent with existing approaches in detecting evolution patterns in DSNs
with an accuracy of 94.1%. The results also show that the indices are useful
in predicting OSS team productivity with an accuracy of 0.718. In summary, the
proposed approach is among the first to quantify the degree of community
evolution with respect to different patterns, which is promising in supporting
future research and applications about DSNs and OSS development.

Developer Social Networks, Community Evolution Patterns, Entropy-Bases
Indices, Open Source Software, Mining Software Repositories

††ccs: Software and its engineering Programming teams††ccs: Software and its
engineering Open source model††ccs: General and reference Metrics

##  1\. Introduction

Building and maintaining healthy communities around open source software (OSS)
projects is crucial because of the socio-technical nature of OSS development
(Catolino et al., 2019; Ducheneaut, 2005; Weiss et al., 2006; Nakakoji et al.,
2002; Panichella et al., 2014b; Hannemann and Klamma, 2013; Tsay et al.,
2014a). Cross-disciplinary research on developer social networks (DSNs) that
emerge from the developers’ communication and cooperation activities in OSS
repositories has been conducted by scholars from various fields ever since the
early days of the OSS movement (O’Reilly, 1999; Madey et al., 2002). Supported
by rich empirical evidences, it is now widely accepted that the social aspects
of OSS communities have a strong correlation with, and are important
indicators of OSS projects’ productivity (Wang et al., 2007), success (Van
Antwerp and Madey, 2010), and survivability (Wang, 2012; Ngamkajornwiwat et
al., 2008; Pinzger et al., 2008).

While a number of research is about the statistics and patterns of static DSNs
snapshots (Bird et al., 2006; Crowston and Howison, 2005; Xu et al., 2005;
Jensen et al., 2011; Tamburri et al., 2019), there is a series of work that
pay special attentions to the evolution of DSNs around OSS projects over time
(Weiss et al., 2006; Hannemann and Klamma, 2013; Bock et al., 2021). By
understanding the evolution of DSNs, we can not only retrospectively reveal
the status of a DSN in a given snapshot, but also predict the future trends of
a DSN based on a comprehensive view of its evolution history (Panichella et
al., 2014b; Hannemann and Klamma, 2013; Bock et al., 2021). Given the
importance of social aspects in OSS development as discussed above, and
because OSS development is a “nature product of evolution” (Nakakoji et al.,
2002; O’Reilly, 1999), in this work, we study the problem of _measuring the
evolution of social communities around OSS projects quantitatively_ to support
in-depth understanding of the socio-technical aspects of OSS development.

Existing approaches to study community and network evolution can be
categorized into two classes which we refer to as network-level statistics and
community-level patterns. The first class of work uses sequences of
statistical metrics over series of temporally-aligned snapshots of social
networks to quantify their evolution. Frequently adopted metrics include
network diameter, shortest path between nodes, node betweenness, modularity,
hierarchy, centrality, and etc (Hannemann and Klamma, 2013; Huang et al.,
2011; Aljemabi and Wang, 2018; Joblin, 2017; Pinzger et al., 2008; Schreiber
and Zylka, 2020). While most of the above metrics measure properties of social
networks on a gross level, a natural phenomenon in social networks is that
interacting individuals form complex structures organized in communities111For
the rest of the paper, a _community_ inside a social network refers to a group
of interconnected members of the network if not specified otherwise. Refer to
Sec. 2.1 for details about the terms used in this paper. (Palla et al., 2007;
Bird et al., 2008). Understanding the communities inside DSNs can provide
valuable insights about software development. For instance, the Conway’s law
suggests that a system’s architecture reflects the communication structure of
the organization designs it (Betz et al., 2013; Conway, 1968). Although some
metrics such as clustering coefficient (Hannemann and Klamma, 2013), group
degree centrality (Ngamkajornwiwat et al., 2008), group betweenness centrality
(Ngamkajornwiwat et al., 2008), and etc, are related to measuring
substructures or communities (Chakraborty et al., 2017) in social networks,
these network-level statistics are less expressive in revealing the structure
and evolution of communities in DSNs.

Different from the above work, the second class of approaches take the
community perspective (Aljemabi and Wang, 2018) to uncover the evolution
patterns of social networks. Six patterns, including _growth_ (_expand_),
_contraction_ (_shrink_), _merge_ , _split_ , _birth_ (_emerge_), and _death_
(_extinct_) are used to describe the evolutionary behaviors of communities
inside social networks (Hong et al., 2011; Palla et al., 2007; Lin et al.,
2007; Asur et al., 2009; Bródka et al., 2013; Greene et al., 2010; Aljemabi
and Wang, 2018). These patterns are promising in bringing insights about OSS
development for corresponding to the evolution of OSS projects and members’
activities (Hong et al., 2011). However, the existing pattern-based approaches
often assign a single pattern to describe the evolution of a community, which
are limited for several reasons. First, the evolution of a community can
hardly be described by a single pattern. For example, a community can expand
and merge simultaneously with new members and members from other communities
joining it. Choosing either pattern can lead to information loss in the above
case. In addition, matching communities detected in different time steps to
identify them as a single, evolving community before pattern assignment is not
a trivial task (Palla et al., 2007). Second, the nominal patterns are
promising in describing community evolution qualitatively, but are limited in
supporting quantitative analysis. Third, these patterns are restricted to
describe the evolution of a single community. It is difficult to extend the
concepts to the network level, which is often desirable to gain a
comprehensive understanding of the evolution of DSNs.

Our idea to tackle the above limitations can be described as: _the community
evolution patterns can happen simultaneously between all pairs of communities
in consecutive time steps, only in different degrees._ Following this idea, we
propose in this paper to quantify community evolutionary behaviors
comprehensively by calculating _how much_ the communities expand, shrink,
merge, and split simultaneously. As introduced in Sec. 4, the calculation is
done by first building a community member migration matrix which captures the
dynamics of communities detected in Sec. 3. Based on the matrix, we devise
indices based on information entropy to measure the degree of community
evolution with respect to the four patterns above. Community extinct and
emerge are represented by special combinations of the indices. With this
approach, the evolution of a community is described by four indices in each
step, which addresses the challenge of finding a unique, most appropriate
pattern for community evolution. It is worth noting that our approach is
compatible with existing work (Hong et al., 2011) for being capable of finding
the most appropriate evolution pattern with a simple set of rules as
introduced later. We present the properties of the indices, including the
monotonicity, and the upper- and lower-bounds, to show that the indices can
correctly reveal complex, real-world community evolutionary behaviors
quantitatively. We also aggregate the community-level indices to describe the
overall evolutionary behaviors of communities at the network level, which can
support quantitative analysis of community evolution at various scales.

We conduct empirical studies using real-world data collected from thirty-two
projects hosted on GitHub to evaluate the validity and usefulness of the
proposed community evolution indices. More specifically, we validate the
construct validity of the proposed indices in terms of concurrent and
discriminant validity criteria (Kanika et al., 2015). The results for
concurrent validity suggest that the community evolution patterns detected
with the proposed indices is consistent with the ones detected following an
exiting approach (Hong et al., 2011), with an accuracy of 94%. By analyzing
the properties of the indices, and by calculating the Spearman’s Correlation
Coefficients of the indices, we find that the indices are capable in measuring
different aspects of community evolution. We further demonstrate the
usefulness of the proposed indices by study the correlation between the
measured community evolution with OSS project team productivity measured by
the count of commits (Catolino et al., 2019; Vasilescu et al., 2015). The
results obtained from regression analysis with linear mixed-effects models
suggest that the indices are good predictors of team productivity with an
accuracy of 0.718 after log transformation.

The main contributions of this paper are as follows. First, we bridge the gap
between nominal, community evolution patterns and quantitative measures with a
set of entropy-based indices to support quantitative analysis for community
evolution. Second, we demonstrate versatile ways of using the indices, e.g.,
aggregating community-level indices to generate network-level quantities, and
finding the most appropriate pattern from the indices, which can support
various tasks. Finally, we conduct empirical studies with data from real-world
OSS projects to validate the proposed indices, and demonstrate the usefulness
of the indices in predicting OSS team productivity.

Figure 1. An overview of the proposed approach.

An overview of the proposed approach.

##  2\. Overview of the Proposed Approach

This section presents an overview of the proposed approach.

###  2.1. Terminology

We first introduce the concepts and terms used in this paper.

An _OSS project_ or _repository_ refers to a single repository hosted on OSS
platforms such as Github, e.g., _tensorflow/tensorflow_
222https://github.com/tensorflow/tensorflow. In comparison, large projects,
e.g., the Mozilla or GNOME projects that include multiple sub-projects
developed together (Hong et al., 2011; Mens and Goeminne, 2011), are
considered as _ecosystems_ or _super-repositories_ following (Mens and
Goeminne, 2011; Lungu et al., 2010). In this work, we focus on community
evolution on the _project_ level.

A _developer social network_ (DSN) around an OSS project include the
participants of the project and their relationships, which is typically
modeled using a graph model (Hong et al., 2011; Aljemabi and Wang, 2018)
extracted from various sources such as mailing lists (Bird et al., 2006; Weiss
et al., 2006; Mens and Goeminne, 2011; Panichella et al., 2014b), version
repositories (Mens and Goeminne, 2011), issue and bug-tracking systems
(Panichella et al., 2014b; Aljemabi and Wang, 2018), and etc.

A _community_ inside a DSN means a group of members in the DSN with strongly
interconnected links (Palla et al., 2007), or share similar features and
actions (Nakakoji et al., 2002; Rossetti and Cazabet, 2018), which is also
termed as a _cluster_ (Hannemann and Klamma, 2013; Rossetti and Cazabet,
2018), a _clique_ (Palla et al., 2007; Schreiber and Zylka, 2020), an
_emerging team_ (Panichella et al., 2014b), or a _social group_ (Palla et al.,
2007) in the literature. We do not use the term to refer to OSS communities in
the broad sense (Singh, 2010), e.g., the Apache community studied in (Weiss et
al., 2006).

The _evolutionary behaviors_ of communities studied in this paper correspond
to the six community evolution patterns studied in (Palla et al., 2007; Hong
et al., 2011; Lin et al., 2007; Aljemabi and Wang, 2018), which is different
from the general concept of ‘patterns of community evolution’ used in (Weiss
et al., 2006; Nakakoji et al., 2002).

###  2.2. Overview

As shown in Fig. 1, the processing pipeline proposed in this work involves
three steps. First, as shown in Fig. 1(a) and as introduced in Sec. 3 and Sec.
5, given an OSS repository, we retrieve data about the conversations that take
place in issues and pull-requests from the GHTorrent data set (Gousios and
Spinellis, 2012) and the GitHub GraphQL
API333https://docs.github.com/en/graphql. Participants of the conversations
are recorded to extract the joint discussion relationships between them. The
records are used to build DSNs and to perform community evolution analysis in
the subsequent steps. Next, as shown in Fig. 1(b) and presented in Sec. 3, we
segment the records with a siding-window, and build snapshots of DSNs from the
segments using weighted, undirected graphs. Community detection is then
performed by applying an extension of the Clauset-Newman-Moore (CNM) algorithm
for weighted graphs to the snapshots. Finally, correspond to Fig. 1(c), we
measure the evolutionary behaviors, including the _split_ , _shrink_ , _merge_
, and _expand_ , of the communities detected in consecutive steps with the
information entropy-based indices proposed in Sec. 4. The index values are
aggregated to quantify community evolution at the network level before we
performing analysis in Sec. 5.

##  3\. DSN and Community Detection

In this work, we use a weighted, undirected graph $G=\langle V,E,U,W\rangle$
to model the structure of a DSN, where a vertex $v_{i}\in V$ represents a
user, and an edge $e_{ij}\in E$ represents social interactions between users
$v_{i}$ and $v_{j}$. A positive, real-valued weight $u_{i}\in U$ is assigned
to each vertex $v_{i}$ following Eq. (2) to quantify the user’s importance.
And a weight $w_{ij}\in W$ is assigned to each edge $e_{ij}$ following Eq. (1)
to quantify the strength of social interactions between the users connected by
the edge. The type of social interaction studied in this paper is the _joint
discussion_ relationship between users on OSS platforms such as GitHub.
Platform users can post issues and pull-requests to an OSS repository to ask
questions and making contributions (Bird et al., 2008; Tamburri et al., 2019).
They can also provide responses by leaving comments under posted issues and
pull-requests. We use the term _a conversation_ to refer to the collection of
the initial body and all the comments to a single issue or pull-request. There
is an edge $e_{ij}$ between two users, $v_{i}$ and $v_{j}$, if they join the
same conversation.

###  3.1. Construct DSN Snapshots

We construct a series of DSN snapshots from the conversations of an OSS
repository.

####  3.1.1. Data Segmentation

Given a series of temporally ordered conversations obtained from a project’s
repository, $\mathcal{\vec{D}}=\langle d_{1},d_{2},\cdots,d_{N}\rangle$, where
$d_{i}=\langle t_{i},V_{i}\rangle,i=1\cdots N$, records the creation time
$t_{i}$, and the set of participants444The participants of a conversation
include the author and the users leave comments in the issue or pull-request.
$V_{i}$ of the $i$-th record, we apply a non-overlapping sliding window of
length $\omega$ to divide $\mathcal{\vec{D}}$ into a series of segments
$\mathcal{\vec{S}}=\langle s_{1},s_{2},\cdots,s_{T}\rangle$. The $t$-th
segment in $\mathcal{\vec{S}}$ include conversations created in the $t$-th
window, i.e., $s_{t}=\\{d_{i}|t_{1}+(t-1),\omega\leq
t_{i}<t_{1}+t\omega)\\},j=1\cdots T$, where $t_{1}$ is the creation time of
$d_{1}$.

Figure 2. Migration of community members between consecutive time steps. With
a slight abuse of notations, we omit the time indicators $t$ and $t+1$ in the
matrix shown in (a), and the weights shown in (b) and (c).

####  3.1.2. Build Local DSNs from Data Segments

For each segment $s_{t}\in\mathcal{\vec{S}}$, we build its corresponding local
DSN $G^{L}_{t}=\langle V^{L}_{t},E^{L}_{t},U^{L}_{t},W^{L}_{t}\rangle$ by
letting $V^{L}_{t}$ to include all the participants of conversations in
$s_{t}$, and $E^{L}_{t}$ to include all the joint discussion relationships
between the users in $V^{L}_{t}$, respectively. There is an edge between user
$v_{i}$ and $v_{j}$ if there is at least one conversation $d_{k}\in s_{t}$
that both users are participants of $d_{k}$. $U^{L}_{t}$ and $W^{L}_{t}$
include the weights of users and edges in the local DSN, which are calculated
as follows.

For each edge $e_{ij}\in E^{L}_{t}$, there is a weight $w_{ij}\in W^{L}_{t}$
that quantifies the strength of interactions between user $v_{i}$ and $v_{j}$.
Let $cnt_{ij}$ be the count of conversations both $v_{i}$ and $v_{j}$
participate in segment $s_{t}$, we assign the weight $w_{ij}$ as follows.

(1) $w_{ij}=\ln(cnt_{ij}+1)$

We take the natural logarithm of counts to prevent large counts to overwhelm
small ones. From Eq. (1), we have $w_{ij}=0$ if $cnt_{ij}=0$, and $w_{ij}>0$
if $cnt_{ij}\geq 0$. Note we always have $cnt_{ij}=0$ if $i=j$. Further, we
assign a weight $u_{i}\in U^{L}_{t}$ for each user $v_{i}\in V^{L}_{t}$ to
quantify the user’s importance in the DSN as follows.

(2) $u_{i}=\ln(\sum_{j=1}^{|V^{L}_{t}|}w_{ij}+1)$

where $|V^{L}_{t}|$ is the number of users in segment $s_{t}$, and $w_{ij}$ is
as defined in Eq. (1). Intuitively, a user with a large weight is a user who
actively interactions with many other users, who is considered important in
the DSN. The minimal weight of a user $v_{i}$ is $u_{i}=0$ if the user does
not communicate with any other user in the segment. With the above approach,
we can extract a series of temporally ordered local DSNs
$\vec{\mathcal{G}^{L}}=\langle G^{L}_{1},G^{L}_{2},\cdots,G^{L}_{T}\rangle$
from the segments $\mathcal{\vec{S}}$.

####  3.1.3. DSN Snapshots with Aggregated Local DSNs

While it is possible to perform subsequent community detection and evolution
analysis with the local DSNs above, it is not trivial to decide the optimal
window size $\omega$ for segmentation (Hong et al., 2011). A large window
(e.g., from several months to a year (Hong et al., 2011)) allows us to take a
comprehensive snapshot of the DSN with rich data. However, it keeps us from
performing fine-grained community evolution analysis due to the large time gap
between consecutive windows. On the other hand, a small window allows us to
perform fine-grained community evolution analysis. But a short window may
cover too few data to generate a useful snapshot.

To support fine-grained analysis with sufficient data, we generate DSN
snapshots by aggregating multiple local DSNs built from one week’s data. We
empirically set each snapshot to contain twelve local DSNs to cover data in
three months. We assign more credits to recent data than early data in the
snapshot by multiplying a decaying factor to the edge weights of the local
DSNs. Let $G^{L}_{t-i}$ be the $i^{\text{th}}$ local DSN being included in the
snapshot for time $t$, we decay its edge weights, $W_{t-i}^{L}$, with a factor
$\gamma^{i}$, where $\gamma$ is heuristically set to $e^{-1}$. With the above
approach, we can obtain a series of DSN snapshots $\vec{\mathcal{G}}=\langle
G_{1},G_{2},\cdots,G_{T}\rangle$ by aggregating local DSNs.

###  3.2. Detect Communities in DSN Snapshots

The communities studied in this work are groups of users with close and
intensive interactions among each other in a snapshot of DSN. Given the $t$-th
snapshot of a DSN, $G_{t}=\langle
V_{t},E_{t},U_{t},W_{t}\rangle\in\vec{\mathcal{G}}$, we adopt the extension
(Chakraborty et al., 2017; Newman, 2004) of the Clauset-Newman-Moore (CNM)
greedy modularity maximization algorithm (Newman, 2003; Newman and Girvan,
2004) to detect the communities within it. Developed from the traditional CNM
algorithm for unweighted graphs, the extended version of CNM performs commnity
detection on weighted graphs using the strength of connections between nodes
indicated by the edge weights.

The result of community detection for $G_{t}$ is a set of non-overlapping
communities $C_{t}=\\{c_{t,1},c_{t,2},\cdots,c_{t,n}\\}$, where
$c_{t,i}\subseteq V_{t}$ contains a subset of users in the social network with
strong internal joint discussion relationships. Communities involve only a
single member are removed. By applying community detection to all the
snapshots in $\vec{\mathcal{G}}$, we obtain a series of evolving communities
over time $\vec{\mathcal{C}}=\langle
C_{1},C_{2},\cdots,C_{t},\cdots,C_{T}\rangle$. In the next section, we propose
metrics to measure community evolution in $\vec{\mathcal{C}}$.

##  4\. Community Evolution indices

Based on the temporally ordered series of communities $\vec{\mathcal{C}}$
detected in the above section, this section presents the process and metrics
proposed to measure community evolution.

###  4.1. Community Member Migration Matrix

Given two consecutive sets of communities in $\vec{\mathcal{C}}$, e.g.,
$C_{t}$ and $C_{t+1}$, we compute a community member migration matrix to
quantify member migration between the communities as shown in Fig. 2(a). Let
$n=|C_{t}|$ and $m=|C_{t+1}|$ be the number of communities in $C_{t}$ and
$C_{t+1}$ (without loss of generality, we assume $n\geq 1$ and $m\geq 1$),
respectively, we obtain a $(n+1)\times(m+1)$ matrix $M_{t}$ where the $ij$-th
element $a_{i,j}$ is the number of members migrate from $c_{t,i}$ to
$c_{t+1,j}$, calculated following Eq. (3), for $i\leq n$ and $j\leq m$.

(3) $a_{i,j}=c_{t,i}\cap c_{t+1,j},i=1,2,...,n,j=1,2,...,m$

where $c_{t,i}\cap c_{t+1,j}$ is the set of common users in $c_{t,i}$ and
$c_{t+1,j}$, i.e., the set of users in $c_{t,i}$ who migrate to $c_{t+1,j}$.
Member migration between exiting communities in consecutive time steps
correspond to the solid arrows in Fig. 2(b) and (c), respectively.

Two $Null$ communities, $Null_{t+1}$ and $Null_{t}$, are added to $C_{t+1}$
and $C_{t}$ to include members not involved in these communities. The
$Null_{t+1}$ community involves members of a community in $C_{t}$ who leave
the project in time $t+1$, i.e., members of $C_{t}$ who do not show in any
community in $C_{t+1}$. And the $Null_{t}$ community include newly joined
members in a community in $C_{t+1}$ who do not appear in any community in
$C_{t}$. Elements related to the $Null$ communities are in the last column and
row of $M_{t}$ as illustrated in Fig. 2(a), which are calculated following Eq.
(4).

(4) $\displaystyle b_{i}=c_{t,i}\setminus\bigcup_{j=1}^{m}a_{i,j},1\leq i\leq
n$ and $\displaystyle d_{j}=c_{t+1,j}\setminus\bigcup_{i=1}^{n}a_{i,j},1\leq
j\leq m$

where $\bigcup_{j=1}^{m}a_{i,j}$ is the set of members in $c_{t,i}$ who stay
in the project (and join an arbitrary community) in time $t+1$, and
$\bigcup_{i=1}^{n}a_{i,j}$ is the set of members in $c_{t+1,j}$ who migrate
from an existing community in time $t$. As a result, members from $c_{t,i}$
who leave the project (into $Null_{t+1}$), and members in $c_{t+1,j}$ who are
new comers (from $Null_{t}$) are contained in sets
$b_{i}=c_{t,i}\setminus\bigcup_{j=1}^{m}a_{i,j}$ and
$d_{j}=c_{t+1,j}\setminus\bigcup_{i=1}^{n}a_{i,j}$, which correspond to the
dashed arrows in Fig. 2(b) and (c), respectively. We omit time indicators for
matrix elements, i.e., $a_{i,j}$, $b_{i}$, and $d_{j}$, to keep it concise.

The weights on arrows in Fig. 2(b) quantify the distribution of members
migrate to different communities from $c_{t,i}$ with respect to their weights
at time $t$, which are obtained following Eq. (5).

(5) $\psi_{i,j}=\frac{f_{t}(a_{i,j})}{f_{t}(c_{t,i})},j=1,2,...,m,\text{ and
}\eta_{i}=\frac{f_{t}(b_{i})}{f_{t}(c_{t,i})}$

where $a_{i,j}$ and $b_{i}$ are sets of users as defined in Eq. (3) and Eq.
(4), respectively; $c_{t,i}$ is the set of the community’s members; let $x$ be
a set of users, function $f_{t}(x)$ is the sum of weights for users in set
$x$, and the subscript $t$ indicate the weights are given by snapshot $G_{t}$:

$f_{t}(x)=\sum_{v_{i}\in x}u_{i},u_{i}\in U_{t},x\subseteq V_{t}$

Similarly, the weights in Fig. 2(c) are calculated following Eq. (6) to
quantify the distribution of members in $c_{t+1,j}$ from different sources
based on their weights in snapshot $G_{t+1}$ given by $f_{t+1}(\cdot)$.

(6) $\displaystyle\phi_{i,j}=$
$\displaystyle\frac{f_{t+1}(a_{i,j})}{f_{t+1}(c_{t+1,j})},i=1,2,...,n,\text{
and }\mu_{j}=\frac{f_{t+1}(d_{j})}{f_{t+1}(c_{t+1,j})}$

###  4.2. Entropy-Based Community Evolution Indices for A Single Community

In this section, we propose to measure the evolution of a single community
between consecutive time steps, i.e., time $t$ and $t+1$, based on the
information entropy of the weight distributions shown in Fig. 2(b) and (c).
While existing works describe community evolution with six patterns including
_split_ , _shrink_ , _extinct_ , _merge_ , _expand_ , and _emerge_ (Hong et
al., 2011), we omit the _extinct_ and _emerge_ patterns because they are
special cases of community evolution studied in this work, as discussed in
Sec. 4.2.4. More importantly, different from existing works (Palla et al.,
2007; Hong et al., 2011) that assign a single pattern to each matched pair of
communities, we propose that the evolutionary behaviors take place in every
pair of communities in consecutive time steps simultaneously, just a matter of
degrees. As a result, we do not require to find the match between prior and
post communities.

####  4.2.1. The split and shrink indices of community $c_{t,i}$

We use a community detected in time $t$, i.e., $c_{t,i}$, as shown in Fig.
2(b) to explain how the split and shrink indices are calculated.

Given the $m+1$ communities in the next time step (which include the $m$
detected communities in $C_{t+1}$, and $Null_{t+1}$), and the weight vector
$\langle\psi_{i,1},\psi_{i,2},\cdots,\psi_{i,m},\eta_{i}\rangle$, we obtain
the distribution of users’ weights who stay in the project by normalizing
their actual weights:

(7) $\hat{\psi}_{i,j}=\frac{\psi_{i,j}}{\sum_{j=1}^{m}\psi_{i,j}}$

Clearly, we have $\sum_{j=1}^{m}\hat{\psi}_{i,j}=1$. And we can calculate the
information entropy (Shannon, 1948) of the normalized weight vector by:

(8)
$\mathcal{H}_{c_{t,i}}=-\sum_{j=1}^{m}\hat{\psi}_{i,j}\log_{2}(\hat{\psi}_{i,j})$

With $m$ fixed, the entropy $\mathcal{H}_{c_{t,i}}$ is upper-bounded by the
following maximum entropy obtained when
$\hat{\psi}_{i,j}=\frac{1}{m},j=1,2,\cdots,m$:

(9) $\mathcal{H}^{*}_{t\rightarrow t+1}=-\log_{2}(\frac{1}{m})$

Intuitively, $\mathcal{H}_{c_{t,i}}$ measures the degree of $c_{t,i}$’s
members spread into different communities (excluding $Null_{t+1}$) in the next
step. And $\mathcal{H}^{*}_{t\rightarrow t+1}-\mathcal{H}_{c_{t,i}}$ measures
the degree of $c_{t,i}$’s members gather to a single community in the next
step. Both $\mathcal{H}_{c_{t,i}}$ and $\mathcal{H}^{*}_{t\rightarrow
t+1}-\mathcal{H}_{c_{t,i}}$ are equal or above zero. Based on the entropy in
Eq. (8), we compute community $c_{t,i}$’s _split_ and _shrink_ indices as
follows.

The _split index_ of $c_{t,i}$, denoted as $\mathcal{I}^{\psi}_{c_{t,i}}$,
measures the degree of separation of its members into concrete communities
detected in the next step, which is calculated as:

(10) $\mathcal{I}^{\psi}_{c_{t,i}}=(1-\eta_{i})\mathcal{H}_{c_{t,i}}$

where $\eta_{i}$ is defined in Eq. (5).

The _shrink index_ of $c_{t,i}$, denoted as $\mathcal{I}^{\eta}_{c_{t,i}}$,
measures the degree of its members move to the $Null_{t+1}$ community in the
next step:

(11) $\mathcal{I}^{\eta}_{c_{t,i}}=\eta_{i}(\mathcal{H}^{*}_{t\rightarrow
t+1}-\mathcal{I}^{\psi}_{c_{t,i}}+\sigma_{\eta_{i}})$

where $\sigma_{\eta_{i}}$ is defined as follows to guarantee that the shrink
index is always positive when $m\geq 1$ and $\eta_{i}>0$.

(12) $\sigma_{\eta_{i}}=\begin{cases}0.5\eta_{i}&,m=1,\\\
0&,otherwise.\end{cases}$

####  4.2.2. Properties of the split and shrink indices

Fig. 3 illustrates the curves of the indices under varying conditions. The
proposed split index, $\mathcal{I}^{\psi}_{c_{t,i}}$, and shrink index,
$\mathcal{I}^{\eta}_{c_{t,i}}$, have the following properties that are
desirable when measuring community evolution.

Figure 3. Curves of the split and shrink indices under different conditions
specified by $m$, $\eta_{i}$, and $\hat{\psi}_{i,j}$. The even distribution
corresponds to case $\hat{\psi}_{i,j}=\frac{1}{m},j=1,\cdots,m$. The random
distribution is obtained by randomly assigning $\hat{\psi}_{i,j}$’s values.

$\mathcal{I}^{\psi}_{c_{t,i}}$ and $\mathcal{I}^{\eta}_{c_{t,i}}$ are strictly
monotonic increasing functions of $m$, given that $\eta_{i}$ is fixed, and
$\hat{\psi}_{i,j}=1/m,j=1,2,\cdots,m$. Intuitively, the property states that
when a fixed portion of members in community $c_{t,i}$ leave the project
(i.e., $\eta_{i}$ fixed), and the remaining members of $c_{t,i}$ who stay in
the project migrate evenly to the communities detected in the next step (i.e.,
$\hat{\psi}_{i,j}=1/m,j=1,2,\cdots,m$), the split and shrink indices increase
with the increasing number of communities detected in the next step (i.e.,
$m$).

$\mathcal{I}^{\eta}_{c_{t,i}}$ / $\mathcal{I}^{\psi}_{c_{t,i}}$ is a strictly
monotonic increasing / decreasing function of $\eta_{i}$, respectively, given
that $m>1$ and the distribution of $\hat{\psi}_{i,j},j=1,2,\cdots,m$ fixed.
Intuitively, this property states that the shrink / split index increases /
decreases with the increasing portion of users who leave the project (i.e.,
$\eta_{i}$), respectively. A special case is that when $m=1$, we have
$\mathcal{I}^{\psi}_{c_{t,i}}=0,\forall\eta_{i}\in[0,1]$, which is intuitively
correct that the community cannot split if there is only one community
detected in the next step. For the shrink index
$\mathcal{I}^{\eta}_{c_{t,i}}$, we guarantee that
$\mathcal{I}^{\eta}_{c_{t,i}}$ is a strictly monotonic increasing function of
$\eta_{i}$ for $m\geq 1$ by introducing the term $\sigma$ as defined in Eq.
(12).

Given $m$ and $\eta_{i}$, the maximum split index
$\mathcal{I}^{\psi}_{c_{t,i}}=(1-\eta_{i})\mathcal{H}^{*}_{t\rightarrow t+1}$
is obtained when the members of $c_{t,i}$ migrate to the communities detected
in the next step with a even distribution, i.e., when we have
$\hat{\psi}_{i,j}=1/m,j=1,2,\cdots,m$. And the minimum split index
$\mathcal{I}^{\psi}_{c_{t,i}}=0$ is obtained when all the members of $c_{t,i}$
who stay in the project migrate to a single community in the next step, i.e.,
there exists a $j^{\prime}$-th community in time $t+1$ that
$\hat{\psi}_{i,j^{\prime}}=1$ and $\hat{\psi}_{i,j}=0,\forall j\neq
j^{\prime}$, resulting in $\mathcal{H}_{c_{t,i}}=0$ and
$\mathcal{I}^{\psi}_{c_{t,i}}=0$.

Given $m>1$ and $\eta_{i}$, the maximum shrink index
$\mathcal{I}^{\eta}_{c_{t,i}}=\eta_{i}\mathcal{H}^{*}_{t\rightarrow t+1}$ is
obtained when the corresponding split index is minimized, i.e., all stayed
members of community $c_{t,i}$ migrate to a single community in the next step.
And the minimum shrink index
$\mathcal{I}^{\eta}_{c_{t,i}}=\eta_{i}^{2}\mathcal{H}^{*}_{t\rightarrow t+1}$
is obtained when the members of $c_{t,i}$ migrate evenly to communities in
time $t+1$. For the special case of $m=1$, the shrink index is only determined
by $\eta_{i}$ and $\sigma_{\eta_{i}}$.

It is straightforward to proof the above properties given the indices’
definitions and the properties of information entropy (Shannon, 1948). We omit
the proof in this paper due to page limits.

####  4.2.3. The merge and expand indices of $c_{t+1,j}$

Next, to measure community evolution on community $c_{t+1,j}$’s side as shown
in Fig. 2(c), we develop the _merge_ and _expand_ indices of $c_{t+1,j}$
following a similar framework as described above.

The _merge index_ of $c_{t+1,j}$, denoted as $\mathcal{I}^{\phi}_{c_{t+1,j}}$,
measures the degree of its members that come from different source communities
in the previous time step, which is calculated as follows.

(13) $\mathcal{I}^{\phi}_{c_{t+1,j}}=(1-\mu_{j})\mathcal{H}_{c_{t+1,j}}$

where $\mu_{j}$ and $\mathcal{H}_{c_{t+1,j}}$ are defined in Eq. (6) and Eq.
(15), respectively.

The _expand index_ of $c_{t+1,j}$, denoted as $\mathcal{I}^{\mu}_{c_{t+1,j}}$,
measures the degree of its members emerge from $Null_{t}$ in the previous step
as follows.

(14) $\mathcal{I}^{\mu}_{c_{t+1,j}}=\mu_{j}(\mathcal{H}^{*}_{t+1\leftarrow
t}-\mathcal{I}^{\phi}_{c_{t+1,j}}+\sigma_{\mu_{j}})$

where $\sigma_{\mu_{j}}$ is as defined similar to $\sigma_{\eta_{i}}$ as
follows.

$\sigma_{\mu_{j}}=\begin{cases}0.5\mu_{j}&,n=1,\\\ 0&,otherwise.\end{cases}$

The entropy values in the above equations are computed by:

(15) $\mathcal{H}^{*}_{t+1\leftarrow t}=-\log_{2}(\frac{1}{n}),\text{ and
}\mathcal{H}_{c_{t+1,j}}=-\sum_{i=1}^{n}\hat{\phi}_{i,j}\log_{2}(\hat{\phi}_{i,j})$

where $\hat{\phi}_{i,j}=\frac{\phi_{i,j}}{\sum_{i=1}^{n}\phi_{i,j}}$ is the
normalized weights. The merge and expand indices have similar properties as
split and shrink, respectively. We omit the details to keep the paper concise.

####  4.2.4. Community Extinction and Emergence

With the above indices, community extinction and emerges are two special
combinations of index values as follows:

The _extinction_ of a community $c_{t,i}$ happens if all of its members leave
the project and migrate to $Null_{t+1}$, which leads to the case that
$\eta_{i}=1$ and $\mathcal{H}_{c_{t,i}}=0$. In this case, the _shrink index_
takes the maximum value of
$\mathcal{I}^{\eta}_{c_{t,i}}=\mathcal{H}^{*}_{t\rightarrow
t+1}+\sigma_{\eta_{i}}$555When $\mathcal{I}^{\eta}_{c_{t,i}}$ takes the
maximum value, we have $\sigma_{\eta_{i}}=0.5$ if $m=1$, and
$\sigma_{\eta_{i}}=0$ if $m>1$. Similar for the value of $\sigma_{\mu_{j}}$ in
the case of emergence.. And the _split index_ takes the minimum value of
$\mathcal{I}^{\psi}_{c_{t,i}}=0$.

The _emergence_ of a new community $c_{t+1,j}$ happens if all its members are
from $Null_{t}$, in which case we have $\mu_{j}=1$, and
$\mathcal{H}_{c_{t+1,j}}=0$. In this case, the _expand index_ takes the
maximum value of $\mathcal{I}^{\mu}_{c_{t+1,j}}=\mathcal{H}^{*}_{t+1\leftarrow
t}+\sigma_{\mu_{j}}$. And the _merge index_ takes the minimum value of
$\mathcal{I}^{\phi}_{c_{t+1,j}}=0$.

There are more combinations of the index values that form meaningful cases,
which we leave for our future studies.

###  4.3. Aggregate Indices for All Communities

Following the above process, for each community we can obtain indices that
quantify its degree of split and shrink with respect to the next step, and its
degree of merge and expand with respect to the previous step. We calculate the
aggregated indices for the four patterns across all communities in the
snapshot by taking the weighted average of the communities’ indices, where the
weight for a community is the sum of node weights in the community over the
total weight of nodes in all communities. We can then obtain four aggregated
indices that measure the overall, snapshot-level community evolution for each
time step.

##  5\. Empirical Studies

In this section, we conduct empirical studies to evaluate the validity and
usefulness of the proposed community evolution measures.

Table 1. Overview of the data set, where # Conv. is the count of conversations, #Weeks is the time duration of the project’s data, and Status indicates whether the project is active by the end of May, 2019. No. | Project | #Conv. | #Weeks | Status | No. | Project | #Conv. | #Weeks | Status
---|---|---|---|---|---|---|---|---|---
1 | angular-ui/bootstrap | 34783 | 342 | inactive | 17 | jekyll/jekyll | 46354 | 530 | active
2 | apache/couchdb | 9211 | 522 | active | 18 | jessesquires/ JSQMessagesViewController | 10390 | 305 | inactive
3 | beautify-web/js-beautify | 6151 | 475 | active | 19 | jruby/jruby | 28347 | 527 | active
4 | boltdb/bolt | 2830 | 221 | inactive | 20 | junit-team/junit4 | 2840 | 501 | active
5 | carrierwaveuploader/ carrierwave | 10531 | 528 | active | 21 | kevinzhow/PNChart | 939 | 277 | inactive
6 | celery/celery | 26594 | 521 | active | 22 | mbleigh/acts-as-taggable-on | 3786 | 526 | active
7 | Compass/compass | 2692 | 484 | inactive | 23 | onevcat/VVDocumenter-Xcode | 854 | 231 | inactive
8 | davezuko/react-redux-starter-kit | 6138 | 156 | inactive | 24 | prawnpdf/prawn | 5161 | 526 | active
9 | divio/django-cms | 27416 | 526 | active | 25 | Prinzhorn/skrollr | 3729 | 299 | inactive
10 | django-extensions/django-extensions | 5716 | 528 | active | 26 | rails/rails | 196487 | 2578 | active
11 | eczarny/spectacle | 4198 | 456 | inactive | 27 | redis/redis-rb | 4000 | 523 | active
12 | eventmachine/ eventmachine | 4565 | 526 | active | 28 | sferik/twitter | 3934 | 521 | active
13 | facebookincubator/create-react-app | 28207 | 79 | inactive | 29 | Shopify/liquid | 6125 | 526 | active
14 | i3/i3 | 17286 | 532 | active | 30 | sinatra/sinatra | 6598 | 531 | active
15 | JakeWharton/ ActionBarSherlock | 4860 | 341 | inactive | 31 | sparklemotion/nokogiri | 10516 | 530 | active
16 | jcjohnson/neural-style | 3328 | 191 | inactive | 32 | thoughtbot/paperclip | 13025 | 524 | active

###  5.1. Preliminaries

####  5.1.1. Data Set

As summarized in Table 1, we collect a data set involving thirty-two OSS
projects on GitHub to conduct the studies. The projects are randomly selected
from a candidate set of popular (with $\\#stars\geq 1000$) projects with
sufficient data (with $\\#Conv.\geq 800$) that cover different topics
including programming language (e.g., rails/rails), social networks (e.g.,
sferik/twitter), database (e.g., apache/couchdb), mobile (e.g.,
Prinzhorn/skrollr), and etc. Among the projects, twelve inactive
projects–determined following the process in (Coelho and Valente, 2017)–are
included to cover projects in different stages. For each project, we retrieve
data starting from its earliest record on the platform to the end of May, 2019
from two sources: the GHTorrent database (Gousios and Spinellis, 2012) and the
Github GraphQL API666https://developer.github.com/v4/. The data for issue and
pull-request discussions are extracted for community detection and calculating
community evolution indices. We also retrieve the commit history of the
repositories to support correlation analysis between community evolution and
team productivity.

####  5.1.2. Experiment Organization

We evaluate the construct validity of the proposed indices with the concurrent
and discriminant validity criteria following exiting work and guides (Raja and
Tretter, 2012; Meneely et al., 2013; Kanika et al., 2015). As defined in
(Kanika et al., 2015), construct validity is “the extent to which your measure
or instrument actually measures what it is theoretically supposed to measure”.
In this work, we aim at showing the proposed indices are effective in
capturing and quantifying community evolutionary behaviors of DSNs around OSS
projects.

First, we adopt the concurrent validity criterion to validate the proposed
indices. Concurrent validity accesses the ability of a measure to distinguish
between groups it should theoretically be able to distinguish between (Raja
and Tretter, 2012; Kanika et al., 2015). In this work, we compare the
categorical evolution patterns detected following an existing approach (Hong
et al., 2011) with the patterns detected using the proposed indices.

Next, we evaluate the discriminant validity of the indices which requires the
dimensions to be independent or orthogonal to each other. Based on the
properties of the indices discussed in Sec. 4.2.2, and by further evaluating
the discriminant validity of the measures, we aim at showing that the proposed
indices are capable of measuring different aspects of community evolution.

Unfortunately, we are unable to assess the convergent validity of the proposed
indices because to the best of our knowledge, this is the first work that
quantifies the degree of community evolution that include different evolution
patterns simultaneously.

Besides construct validity, we also show the usefulness of the proposed
indices by studying their correlations with projects’ team productivity
measured by the count of commits (Catolino et al., 2019; Vasilescu et al.,
2015). Details of the experiments and their results are as follows.

###  5.2. Concurrent Validity

Table 2. Rules to determine the evolution patterns of a community, e.g., the $i^{\text{th}}$ community at time $t$, $c_{t,i}$. Pattern |  Existing Approach (Hong et al., 2011) |  Our Approach
---|---|---
extinct |  Community $c_{t,i}$ has no matching post community. |  $\mathcal{I}^{\psi}_{c_{t,i}}\leq 0.05(\mathcal{H}^{*}_{t\rightarrow t+1}+\sigma_{\eta_{i}})$ and $\mathcal{I}^{\eta}_{c_{t,i}}\geq 0.95(\mathcal{H}^{*}_{t\rightarrow t+1}+\sigma_{\eta_{i}})$, i.e., split index close to zero and shrink index close to the maximum value.
emerge |  Community $c_{t,i}$ has no matching prior community. |  $\mathcal{I}^{\phi}_{c_{t,i}}\leq 0.05(\mathcal{H}^{*}_{t\leftarrow t-1}+\sigma_{\mu_{i}})$ and $\mathcal{I}^{\mu}_{c_{t,i}}\geq 0.95(\mathcal{H}^{*}_{t\leftarrow t-1}+\sigma_{\mu_{i}})$, i.e., merge index close to zero and expand index close to the maximum value.
split |  Community $c_{t,i}$ has at least two communities in its post community set. |  $\mathcal{I}^{\psi}_{c_{t,i}}>\mathcal{I}^{\eta}_{c_{t,i}}$, i.e., split index greater than shrink index.
shrink |  Community $c_{t,i}$ has only one community in its post community set, and the size of the post community is less than the size of $c_{t,i}$.† |  $\mathcal{I}^{\psi}_{c_{t,i}}<\mathcal{I}^{\eta}_{c_{t,i}}$, i.e., split index less than shrink index.
merge |  Community $c_{t,i}$ has at least two communities in its prior community set. |  $\mathcal{I}^{\phi}_{c_{t,i}}>\mathcal{I}^{\mu}_{c_{t,i}}$, i.e., merge index greater than expand index.
expand |  Community $c_{t,i}$ has only one community in its prior community set, and the size of the prior community is less than the size of $c_{t,i}$. |  $\mathcal{I}^{\phi}_{c_{t,i}}<\mathcal{I}^{\mu}_{c_{t,i}}$, i.e., merge index less than expand index.
undefined |  Others. |  Others.
† The size of a community is the sum of its members’ node weights. We also
slightly modify the rule for shrink in (Hong et al., 2011) to compare the size
of $c_{t,i}$ with its post community to make the detection results comparable
to ours.
Figure 4. Confusion matrices that compares the community evolution patterns
detected with existing approach (Hong et al., 2011) and the proposed approach
following rules specified in Table 2.

We evaluate the concurrent validity of the proposed indices by comparing the
community evolution pattern detection results of our approach and existing
approaches. We adopt the process proposed in (Hong et al., 2011) to detect
community evolution patterns in DSNs which serve as the ‘ground-truth’ for
evaluation. More specifically, for consecutive time steps $t$ and $t+1$, we
first calculate the similarity between each pair of communities detected in
the two DSN snapshots. The generation of DSN snapshots and detection of
communities are the same as introduced in Sec. 3 to conduct a fair comparison.
Slightly different from the original algorithm, the size of a community is
defined as the sum of its members’ weights instead of the count of its
members. The similarity of two communities is the sum of weights of their
common nodes over the smaller value of the two communities’ total weights. We
take the threshold of 0.3 proposed in the original work to perform community
matching. Based on the matching results, we adopt rules in Table 2 to
determine the evolution patterns for each community. We modify the rule for
determining community _shrink_ by comparing a community’s size with its
matching community in the next step to make the results comparable with ours.
With these rules, for each community, we can assign two evolution patterns to
it: 1) one to describe how it evolves towards the next step, which can be
_extinct_ , _split_ , or _shrink_ ; 2) the other to describe how it evolves
from the previous step, which includes _emerge_ , _merge_ , and _expand_. An
_undefined_ pattern is added to label cases that are not included in the
existing set of rules.

For community evolution pattern detection using the indices proposed in this
paper, we simply compare the index values to determine the patterns of
community _split_ , _shrink_ , _merge_ , and _expand_ as shown in Table 2. For
a community, say community $c_{t,i}$, to _extinct_ , the ideal case is that
its split index is zero ($\mathcal{I}^{\psi}_{c_{t,i}}=0$), and its shrink
index takes the maximum value
($\mathcal{I}^{\eta}_{c_{t,i}}=\mathcal{H}^{*}_{t\rightarrow
t+1}+\sigma_{\eta_{i}}$) as discussed in Sec. 4.2.4. However, this condition
is too stringent to effectively detecting community extinction in real-world
data. As a result, we relax the condition as shown in Table 2 that label a
community to _extinct_ when its split index is close to zero, and its shrink
index is close to the maximum value. The same relaxation also applies to the
rule to detect community _emerge_.

The confusion matrix that compares the ground-truth and our detection results
is shown in Fig. 4(a). The overall accuracy of our approach involving all six
patterns and the _undefined_ pattern is 89.2%. Because the _undefined_ pattern
is not clearly defined in existing work (Hong et al., 2011; Palla et al.,
2007), we also evaluate the accuracy by removing the _undefined_ label (i.e.,
by removing the last column and row in the confusion matrix). Without the
_undefined_ label, the overall accuracy is 84.7%. From Fig. 4(a), we can
observe that 52% of the _shrink_ cases are classified as _split_ with our
approach. And 45.8% of the _expand_ cases are detected as _merge_. This is
because there is a threshold of 0.3 to filter out matching but less similar
communities in the exiting approach. As a result, the ground-truth is biased
to shrink and expand compared to our approach which does not perform
filtering. Since there is no evidence showing that the threshold of 0.3 is the
optimal one, we repeat the test by setting a threshold of 0.1 to increase the
chance of community matching when obtaining the ground-truth. As shown in Fig.
4(b), we can observe that the detection accuracy with and without the
_undefined_ pattern increases to 92.7% and 94.1%, respectively.

The above results suggest that, with a simple set of rules, the proposed
indices can accurately distinguish between different patterns of community
evolution which are consistent with the results obtained following the
existing approach (Hong et al., 2011). We conclude that the proposed indices
for community evolution are valid with respect to the concurrent validity
criterion.

###  5.3. Discriminant Validity

Table 3. Interpretation of correlation coefficients ($r$). Levels | Correlation Coefficients ($r$) | Symbols
---|---|---
Perfect |  $r=1$ or $r=-1$ | P
Strong |  $0.7\leq r<1$ or $-1<r\leq-0.7$ | S
Moderate |  $0.4\leq r<0.7$ or $-0.7<r\leq-0.4$ | M
Weak |  $0.1\leq r<0.4$ or $-0.4<r\leq-0.1$ | W
No |  $0\leq r<0.1$ or $-0.1<r\leq 0$ | N
Table 4. Pairwise correlation of the aggregated indices (Spearman’s Correlation Coefficient). Project No. follow Table 1. Notations follow Table 3. The significance levels are shown without the $p$ values to make the table concise. Project No. | split-shrink | split-merge | split-expand | shrink-merge | shrink-expand | merge-expand
---|---|---|---|---|---|---
1 |  -0.05 (N) |  0.41 (M)*** |  0.05 (N) |  -0.06 (N) |  0.50 (M)*** |  0.12 (W)*
2 |  0.23 (W)*** |  0.73 (S)*** |  0.53 (M)*** |  0.23 (W)*** |  0.20 (W)*** |  0.54 (M)***
3 |  -0.07 (N) |  0.20 (W)*** |  0.14 (W)* |  -0.11 (W) |  0.06 (N) |  0.43 (M)***
4 |  -0.10 (W) |  0.39 (W)*** |  0.16 (W)* |  -0.10 (W) |  0.10 (N) |  0.23 (W)***
5 |  0.08 (N) |  0.49 (M)*** |  0.24 (W)*** |  0.06 (N) |  0.26 (W)*** |  0.33 (W)***
6 |  0.17 (W)*** |  0.59 (M)*** |  0.25 (W)*** |  0.28 (W)*** |  0.31 (W)*** |  0.26 (W)***
7 |  0.32 (W)*** |  0.64 (M)*** |  0.53 (M)*** |  0.35 (W)*** |  0.39 (W)*** |  0.56 (M)***
8 |  0.06 (N) |  0.61 (M)*** |  0.29 (W)*** |  0.16 (W)* |  0.12 (W) |  0.29 (W)***
9 |  -0.07 (N) |  0.52 (M)*** |  -0.04 (N) |  -0.01 (N) |  0.10 (N)* |  0.07 (N)
10 |  0.03 (N) |  0.32 (W)*** |  0.19 (W)*** |  0.09 (N)* |  0.15 (W)*** |  0.34 (W)***
11 |  0.09 (N) |  0.32 (W)*** |  0.41 (M)*** |  0.07 (N) |  0.15 (W)** |  0.43 (M)***
12 |  0.08 (N) |  0.50 (M)*** |  0.38 (W)*** |  0.07 (N) |  0.08 (N) |  0.38 (W)***
13 |  -0.20 (W) |  0.24 (W)* |  -0.22 (W) |  0.01 (N) |  0.09 (N) |  -0.19 (W)
14 |  0.65 (M)*** |  0.76 (S)*** |  0.62 (M)*** |  0.63 (M)*** |  0.68 (M)*** |  0.66 (M)***
15 |  0.48 (M)*** |  0.79 (S)*** |  0.68 (M)*** |  0.42 (M)*** |  0.39 (W)*** |  0.66 (M)***
16 |  0.11 (W) |  0.66 (M)*** |  0.33 (W)*** |  0.15 (W)* |  0.24 (W)*** |  0.43 (M)***
17 |  0.03 (N) |  0.64 (M)*** |  0.10 (W)* |  0.12 (W)** |  0.13 (W)** |  0.10 (W)*
18 |  0.32 (W)*** |  0.65 (M)*** |  0.52 (M)*** |  0.40 (M)*** |  0.42 (M)*** |  0.51 (M)***
19 |  0.11 (W)* |  0.67 (M)*** |  0.16 (W)*** |  0.14 (W)** |  0.17 (W)*** |  0.25 (W)***
20 |  0.35 (W)*** |  0.79 (S)*** |  0.63 (M)*** |  0.34 (W)*** |  0.34 (W)*** |  0.58 (M)***
21 |  0.07 (N) |  0.50 (M)*** |  0.34 (W)*** |  0.06 (N) |  0.09 (N) |  0.37 (W)***
22 |  0.04 (N) |  0.43 (M)*** |  0.26 (W)*** |  0.11 (W)** |  0.12 (W)** |  0.31 (W)***
23 |  0.27 (W)*** |  0.54 (M)*** |  0.45 (M)*** |  0.14 (W)* |  0.16 (W)* |  0.37 (W)***
24 |  0.02 (N) |  0.48 (M)*** |  0.30 (W)*** |  -0.03 (N) |  0.07 (N) |  0.33 (W)***
25 |  0.22 (W)*** |  0.25 (W)*** |  0.36 (W)*** |  0.27 (W)*** |  0.33 (W)*** |  0.50 (M)***
26 |  0.16 (W)*** |  0.41 (M)*** |  0.23 (W)*** |  0.25 (W)*** |  0.24 (W)*** |  0.24 (W)***
27 |  -0.00 (N) |  0.56 (M)*** |  0.43 (M)*** |  -0.01 (N) |  0.10 (N)* |  0.38 (W)***
28 |  -0.03 (N) |  0.44 (M)*** |  0.32 (W)*** |  0.03 (N) |  0.14 (W)** |  0.34 (W)***
29 |  0.28 (W)*** |  0.75 (S)*** |  0.48 (M)*** |  0.26 (W)*** |  0.19 (W)*** |  0.51 (M)***
30 |  -0.06 (N) |  0.50 (M)*** |  0.31 (W)*** |  -0.10 (N)* |  0.01 (N) |  0.37 (W)***
31 |  0.07 (N) |  0.37 (W)*** |  0.15 (W)*** |  0.12 (W)** |  0.17 (W)*** |  0.29 (W)***
32 |  0.01 (N) |  0.54 (M)*** |  0.15 (W)*** |  0.03 (N) |  0.21 (W)*** |  0.22 (W)***
Overall |  0.21 (W)*** |  0.68 (M)*** |  0.37 (W)*** |  0.22 (W)*** |  0.27 (W)*** |  0.40 (M)***
***p <0.001, **p <0.01, *p <0.05

We calculate the Spearman’s Correlation Coefficients of each pair of the
indices given a project. Spearman’s Correlation Coefficients are selected over
the Pearson’s Correlation Coefficients because we find that the indices do not
always follow normal distributions. We adopt the rule of thumb in (Akoglu,
2018; Dancey and Reidy, 2007) to interpret the correlation coefficients, i.e.,
the $r$ values, as summarized in Table 3. It is worth noting that a strong
correlation alone does not invalidate the design of the proposed measure
because the correlations between community evolution indices are largely
determined by the members’ activities in real-world OSS repositories. The
phenomenon we would like to observe in this study is that whether there are
occasions that the indices are weakly correlated in the real-world. Combining
the results in this study and the properties of the indices as discussed in
Sec. 4, we aim at showing that the proposed indices are measuring different
aspects of community evolution.

The Spearman’s Correlation Coefficients together with their significance
levels for all the projects are listed in Table 4. We also append the results
of mixing all projects’ data in the last row of the table. It can be observed
that among the thirty two projects involved in our study, there are four
projects, i.e., project 4, 10, 13, 31, show a weak or no correlation between
all pairs of the indices, which cover both active and inactive projects (refer
to Table 1). And over half of the projects only show a moderate correlation
between a single pair of indices. As summarized in the last row of Table 4,
most of the pairs show a weak, but significant correlation with $r$ values
below 0.4. The merge and expand indices show a moderate correlation with a $r$
value of 0.4, which is at the borderline between a moderate and weak
correlation.

An interesting discovery made from the results is that the split and merge
indices show a moderate correlation for most of projects, and even a strong
correlation for five projects. The overall correlation coefficient between
split and merge is 0.68, suggesting a positive, moderate correlation which is
statistically significant. Recall the way we calculate community split and
merge, and the results of concurrent validity presented above, it is clear
that the two indices are capable of measuring different patterns of community
evolution. The correlation between split and merge is a natural result emerges
from the issue and pull-request discussion activities of the community
members. A possible explanation to this positive correlation is that real-
world communities often regroup themselves in OSS projects studied in this
paper. It is our future work to inspect more patterns of community evolution
based on the proposed indices.

###  5.4. Correlation with Team Productivity

The last experiment demonstrates the usefulness of the proposed indices in
predicting OSS project teams’ productivity. We operationalize OSS team
productivity by the count of commits pushed to the repository following
existing work (Catolino et al., 2019; Vasilescu et al., 2015). We perform
regression analysis with the linear mixed-effects models (LMMs) to study the
correlation between the indices and team productivity. Compared to simple
linear models, LMMs allow random effects to be included in the analysis. In
this study, the random effects are the effects caused by the differences of
OSS projects. For each snapshot extracted following Sec. 3.1, we obtain a
sample consists of six variables as follows. First, the outcome variable is
the count of commits in a snapshot. Second, the aggregated indices for
community split, shrink, merge and expand are used as the independent
variables. Log transformation is performed to the above variables to stabilize
variance and reduce heteroscedasticity (Li et al., 2020; Afifi et al., 2007).
Finally, the project name is included in each sample as the indicator for
random effects.

Table 5. Correlation between log transformed community evolution indices and team productivity. The later is measured by $log(\texttt{count of commits}+0.5)$. Regression analysis with linear mixed-effects models. | Coeffs (Errors) | Sum Sq.
---|---|---
(Intercept) | 2.9307 (0.2287)*** |
$log($split$+0.5)$ | 1.1428 (0.04734)*** | 1565.28***
$log($shrink$+0.5)$ | 0.2593 (0.07427)*** | 32.75***
$log($merge$+0.5)$ | 1.0495 (0.04620)*** | 1386.35***
$log($expand$+0.5)$ | -0.9238 (0.08525)*** | 315.46***
AIC=50005.521; BIC=50057.839; Accuracy=0.718;
$R_{m}^{2}$=0.139; $R_{c}^{2}$=0.455; Num. obs.=13018; Num. groups: project
name=32
*** $p<0.001$, ** $p<0.01$, * $p<0.05$.

The results are shown in Table 5. The variance inflation factors (VIFs) for
predictors including split, shrink, merge, and expand are below 1.5, which are
well below the suggested threshold of 5 in existing guidelines (Li et al.,
2020; Cohen et al., 2014), suggesting that there is no strong collinearity
among the predictors. The conditional R-squared $R_{c}^{2}$=0.455 is greater
than the marginal R-squared $R_{m}^{2}$=0.139, suggesting that the adoption of
LMMs for regression analysis is suitable.

The results suggest, after log transformation, all the indices show a
significant correlation with team productivity. Three indices including split,
shrink, and merge are positively correlated with team productivity. It is
surprising to find that expand shows a negative effect. By further observing
the coefficients and ‘Sum Sq.’, we can find that split and merge are more
important predictors than split and expand. A possible explanation to the
effects of split and merge is that members of communities with high degrees of
split and merge are actively regrouping themselves to join issue and pull-
request discussions which results in productive teams. And a potential reason
for the negative effects of expand is that team performance are known to be
influenced by many factors beyond team size, e.g., team diversity (Robert and
Romero, 2015; Vasilescu et al., 2015), developer synchronization (Xuan and
Filkov, 2014), and etc. Growth in team size potentially increases the
communication and coordination costs which reduce the working efficiency. The
above results, together with the results in Sec. 5.3, inspire us to explore
different combinations of the indices as meaningful patterns, and to conduct
more studies to understand the effects of community evolution in team
productivity and performance in our future work.

In summary, the regression model achieves an accuracy (i.e., the correlation
coefficient between the actual and the predicted value of the outcome
(Lüdecke, 2021)) of 0.718, suggesting that the aggregated indices of community
evolution are useful predictors of team productivity. A potential threat to
the robustness of the results is that non-normality and heteroscedasticity of
the residuals are detected. We consult the literature (Schielzeth et al.,
2020; Knief and Forstmeier, 2021; Gelman and Hill, 2006), and conclude that
the above results are trustworthy after carefully inspecting the Q-Q diagram.

##  6\. Threats to Validity

We present a discussion the threats to validity as follows.

Internal Validity. We conduct a data-driven approach to reveal the correlation
between community evolution and OSS development such as team productivity.
However, there are many other factors that are known to affect or characterize
the operation of OSS teams (Catolino et al., 2019; Schreiber and Zylka, 2020).
As a result, the conclusions made in this paper do not fully explain how OSS
teams behave or imply a causal relationship. Instead, the proposed indices
should be used as useful supplements to existing measures of DSN and community
evolution.

External Validity. We select thirty-two projects that cover various topics and
status in our study. However, the collection of projects is small compared to
the number of projects hosted on GitHub and other platforms. The conclusions
made in this paper may not generalize well to other projects. It is our future
work to include more projects in our studies.

Construct Validity. The indices are designed on top of the well-established
theory of information entropy to measure community evolution with clear
properties about how their values respond to parameter changes. We evaluate
the construct validity of the proposed indices in terms of concurrent and
discriminant validity. We plan to seek more criteria to validate our approach
in the future.

##  7\. Related Work

From a general perspective, this work belongs to the series of research about
the social aspects of OSS development started since the beginning of the OSS
movement (Tsay et al., 2014a; Madey et al., 2002; Hahn et al., 2008). In this
section, we introduce work closely related to this paper.

OSS projects are developed and maintained by the collaborative efforts of OSS
contributors over channels such as mailing lists (Bird et al., 2006), and on
“social coding platforms” (Dabbish et al., 2012; Wessel et al., 2018; Tsay et
al., 2014b) such as GitHub and GitLab. The interactions of OSS contributors
naturally generate social networks around OSS projects, which is refer to as
the developer social networks (DSNs) in existing literature (Hong et al.,
2011). Different types of DSNs–including communication (Bird et al., 2006;
Weiss et al., 2006; Panichella et al., 2014b; Hong et al., 2011; Hannemann and
Klamma, 2013; Aljemabi and Wang, 2018; Ngamkajornwiwat et al., 2008; Crowston
and Howison, 2005; Ehrlich and Cataldo, 2012; Bettenburg, 2011), collaboration
(Wang et al., 2007; Surian et al., 2010; Joblin, 2017; Hahn et al., 2008;
Singh, 2010), and hybrid (Panichella et al., 2014a; Tamburri et al., 2019)
networks–have been extracted by mining developer mailing lists and OSS
repositories to study the properties and evolution of DSNs. The extracted DSNs
are often modeled as graphs (Hong et al., 2011; Aljemabi and Wang, 2018). In
this work, weighted, undirected graphs are used to model DSNs that reveal the
communication structures of OSS contributors, based on which a series of
indices are proposed to quantify the evolution of communities inside DSNs. It
should be noted that the proposed approach can also be applied to DSNs of
other types.

Technologies for social network analysis (SNA) are applied to DSNs to
understand the properties, the structures, and the evolution of DSNs. Readers
can refer to (Schreiber and Zylka, 2020; Herbold et al., 2021; Chakraborty et
al., 2017) for comprehensive surveys for social network and community analysis
in DSNs. Different from work that performs analysis to static DSNs (Bird et
al., 2006; Crowston and Howison, 2005; Xu et al., 2005; Jensen et al., 2011;
Tamburri et al., 2019), this work focuses on understanding the dynamic
evolution of DSNs over time. Many studies about DSN evolution are conducted by
analyzing the changes and trend in series of DSN snapshots take over time
(Wang et al., 2007; Hong et al., 2011; Hannemann and Klamma, 2013; Aljemabi
and Wang, 2018; Mens and Goeminne, 2011; Huang et al., 2011; Joblin, 2017;
Ngamkajornwiwat et al., 2008). Network metrics, such as network diameter,
shortest path between nodes, node betweenness, modularity, hierarchy,
centrality, clustering coefficient, and etc, are adopted in existing work
(Hannemann and Klamma, 2013; Huang et al., 2011; Aljemabi and Wang, 2018;
Joblin, 2017; Pinzger et al., 2008; Chakraborty et al., 2017) to assess the
properties of DSNs. There are also metrics developed exclusively to measure
software communities (Wang et al., 2007). Based on these metrics, statistical
and data mining technologies are applied to understand the evolution of DSNs
(Huang et al., 2011; Syeed et al., 2013). This work is related to the above
work in that we propose indices to quantify the evolution of DSN communities
which can support further analysis including but not limited to regression
analysis, and pattern detection as shown in our experiments. Different from
the above work that takes the network perspective, this work takes the
community perspective (Aljemabi and Wang, 2018) and analyzes the evolutionary
behaviors of communities in DSNs.

The patterns adopted in this paper that describe the evolutionary behaviors of
DSN communities are originally proposed in (Palla et al., 2007), which involve
six patterns as introduced in the rest of the paper. These patterns are shown
to be promising in describing the evolution of communities in various types of
social networks such as co-authorship, phone call, and blog networks (Palla et
al., 2007; Lin et al., 2007). In (Hong et al., 2011), the authors adopt these
patterns to characterize community evolution in OSS projects including
Firefox, and Bugzilla. Similar patterns are also adopted in (Aljemabi and
Wang, 2018) to describe the evolution of DSNs at the community level. This
work is closely related to the above work in that we also adopt the patterns
as the basis to describe community evolution. Different from these approaches
that assign a unique, nominal pattern to a matched pair of communities in
consecutive time steps, we quantify the degree of different patterns which can
occur simultaneously during the evolution of the communities. Other
differences of this work from the above work include: 1) community emerge and
extinct are defined by combinations of the indices. As a result, we only
include indices for four patterns as introduced in the paper; and 2) we do not
require to match communities detected in different time steps to recognize
them as a single evolving community, which is a challenging task (Palla et
al., 2007) that can lead to biases if not treated with caution.

Finally, we note that the community evolution patterns studied in this work
are about the patterns introduced above, which are different from the general
patterns of OSS evolution in existing work, which include studies that
characterize the process of preferential attachment in OSS developers when
forming DSNs (Weiss et al., 2006), or the stages of OSS project evolution
(Nakakoji et al., 2002), and etc.

##  8\. Conclusion

In this paper, we present four entropy-based indices to measure the degree of
community evolutionary behaviors with respect to patterns including split,
shrink, merge, and expand to understand the evolution of DSNs around OSS
projects. This work bridges the gap between pattern-based approaches which can
provide meaningful insights about the evolution of DSNs from the community
perspective, and metric-based social network analysis which can support
comprehensive and quantitative analysis. The construct validity of the
proposed indices are evaluated on a real-world data set about the issue and
pull-request discussions in thirty-two OSS projects. The results suggest the
indices can accurately capture different patterns of community evolution by
achieving a detection accuracy of 94.1% compared to existing work (Hong et
al., 2011), and show weak and moderate correlations. The results also show
that the indices can accurately predict OSS team productivity after log
transformation with linear mixed-effects models.

The proposed indices can be used and extended in many ways to support future
studies. For example, we can use the indices to assess and predict the
behavior and status of OSS teams and projects, e.g., to assess the health of
OSS teams, and to predict OSS projects’ sustainability (Raja and Tretter,
2012). More patterns of community evolution can be developed based on
combinations of the indices, e.g., community _regroup_ as discussed in Sec.
5.3, following the way we define community emerge and extinct. We can also
apply the proposed framework to other types of DSNs, e.g., collaboration
networks (Joblin, 2017), to understand their evolution.

## References

  * (1)
  * Afifi et al. (2007) Abdelmonem A Afifi, Jenny B Kotlerman, Susan L Ettner, and Marie Cowan. 2007.  Methods for improving regression analysis for skewed continuous or counted responses.  _Annu. Rev. Public Health_ 28 (2007), 95–111.
  * Akoglu (2018) Haldun Akoglu. 2018\.  User’s guide to correlation coefficients.  _Turkish journal of emergency medicine_ 18, 3 (2018), 91–93.
  * Aljemabi and Wang (2018) Mohamed Abdelrahman Aljemabi and Zhongjie Wang. 2018.  Empirical study on the evolution of developer social networks.  _IEEE Access_ 6 (2018), 51049–51060.
  * Asur et al. (2009) Sitaram Asur, Srinivasan Parthasarathy, and Duygu Ucar. 2009\.  An event-based framework for characterizing the evolutionary behavior of interaction graphs.  _ACM Transactions on Knowledge Discovery from Data (TKDD)_ 3, 4 (2009), 1–36.
  * Bettenburg (2011) Nicolas Bettenburg. 2011\.  Mining development repositories to study the impact of collaboration on software systems. In _Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of software engineering_. 376–379.
  * Betz et al. (2013) Stefanie Betz, Samuel Fricker, Andrew Moss, Wasif Afzal, Mikael Svahnberg, Claes Wohlin, Jürgen Börstler, Tony Gorschek, et al. 2013\.  An evolutionary perspective on socio-technical congruence: The rubber band effect. In _2013 3rd International Workshop on Replication in Empirical Software Engineering Research_. IEEE, 15–24.
  * Bird et al. (2006) Christian Bird, Alex Gourley, Prem Devanbu, Michael Gertz, and Anand Swaminathan. 2006.  Mining email social networks. In _Proceedings of the 2006 international workshop on Mining software repositories_. 137–143.
  * Bird et al. (2008) Christian Bird, David Pattison, Raissa D’Souza, Vladimir Filkov, and Premkumar Devanbu. 2008\.  Latent social structure in open source projects. In _Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of software engineering_. 24–35.
  * Bock et al. (2021) Thomas Bock, Angelika Schmid, and Sven Apel. 2021.  Measuring and Modeling Group Dynamics in Open-Source Software Development: A Tensor Decomposition Approach.  _ACM Transactions on Software Engineering and Methodology (TOSEM)_ 31, 2 (2021), 1–50.
  * Bródka et al. (2013) Piotr Bródka, Stanisław Saganowski, and Przemysław Kazienko. 2013.  GED: the method for group evolution discovery in social networks.  _Social Network Analysis and Mining_ 3, 1 (2013), 1–14.
  * Catolino et al. (2019) Gemma Catolino, Fabio Palomba, Damian A Tamburri, Alexander Serebrenik, and Filomena Ferrucci. 2019\.  Gender diversity and women in software teams: How do they affect community smells?. In _2019 IEEE/ACM 41st International Conference on Software Engineering: Software Engineering in Society (ICSE-SEIS)_. IEEE, 11–20.
  * Chakraborty et al. (2017) Tanmoy Chakraborty, Ayushi Dalmia, Animesh Mukherjee, and Niloy Ganguly. 2017.  Metrics for community analysis: A survey.  _ACM Computing Surveys (CSUR)_ 50, 4 (2017), 1–37.
  * Coelho and Valente (2017) Jailton Coelho and Marco Tulio Valente. 2017.  Why modern open source projects fail. In _Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering_. 186–196.
  * Cohen et al. (2014) Patricia Cohen, Stephen G West, and Leona S Aiken. 2014\.  _Applied multiple regression/correlation analysis for the behavioral sciences_.  Psychology press.
  * Conway (1968) Melvin E Conway. 1968\.  How do committees invent.  _Datamation_ 14, 4 (1968), 28–31.
  * Crowston and Howison (2005) Kevin Crowston and James Howison. 2005.  The social structure of free and open source software development.  _First Monday_ (2005).
  * Dabbish et al. (2012) Laura Dabbish, Colleen Stuart, Jason Tsay, and Jim Herbsleb. 2012\.  Social coding in GitHub: transparency and collaboration in an open software repository. In _Proceedings of the ACM 2012 conference on computer supported cooperative work_. 1277–1286.
  * Dancey and Reidy (2007) Christine P Dancey and John Reidy. 2007.  _Statistics without maths for psychology_.  Pearson education.
  * Ducheneaut (2005) Nicolas Ducheneaut. 2005\.  Socialization in an open source software community: A socio-technical analysis.  _Computer Supported Cooperative Work (CSCW)_ 14, 4 (2005), 323–368.
  * Ehrlich and Cataldo (2012) Kate Ehrlich and Marcelo Cataldo. 2012.  All-for-one and one-for-all? A multi-level analysis of communication patterns and individual performance in geographically distributed software development. In _Proceedings of the ACM 2012 Conference on Computer Supported Cooperative Work_. 945–954.
  * Gelman and Hill (2006) Andrew Gelman and Jennifer Hill. 2006.  _Data analysis using regression and multilevel/hierarchical models_.  Cambridge university press.
  * Gousios and Spinellis (2012) Georgios Gousios and Diomidis Spinellis. 2012.  GHTorrent: GitHub’s data from a firehose. In _2012 9th IEEE Working Conference on Mining Software Repositories (MSR)_. IEEE, 12–21.
  * Greene et al. (2010) Derek Greene, Donal Doyle, and Padraig Cunningham. 2010\.  Tracking the evolution of communities in dynamic social networks. In _2010 international conference on advances in social networks analysis and mining_. IEEE, 176–183.
  * Hahn et al. (2008) Jungpil Hahn, Jae Yun Moon, and Chen Zhang. 2008.  Emergence of new project teams from open source software developer networks: Impact of prior collaboration ties.  _Information Systems Research_ 19, 3 (2008), 369–391.
  * Hannemann and Klamma (2013) Anna Hannemann and Ralf Klamma. 2013.  Community dynamics in open source software projects: Aging and social reshaping. In _IFIP International Conference on Open Source Systems_. Springer, 80–96.
  * Herbold et al. (2021) Steffen Herbold, Aynur Amirfallah, Fabian Trautsch, and Jens Grabowski. 2021.  A systematic mapping study of developer social network research.  _Journal of Systems and Software_ 171 (2021), 110802.
  * Hong et al. (2011) Qiaona Hong, Sunghun Kim, Shing Chi Cheung, and Christian Bird. 2011\.  Understanding a developer social network and its evolution. In _2011 27th IEEE international conference on software maintenance (ICSM)_. IEEE, 323–332.
  * Huang et al. (2011) Hao-Yun Huang, Qize Le, and Jitesh H Panchal. 2011.  Analysis of the structure and evolution of an open-source community.  _Journal of Computing and Information Science in Engineering_ 11, 3 (2011).
  * Jensen et al. (2011) Carlos Jensen, Scott King, and Victor Kuechler. 2011\.  Joining free/open source software communities: An analysis of newbies’ first interactions on project mailing lists. In _2011 44th Hawaii international conference on system sciences_. IEEE, 1–10.
  * Joblin (2017) Mitchell Joblin. 2017\.  _Structural and Evolutionary Analysis of Developer Networks_.  Ph. D. Dissertation. Universität Passau.
  * Kanika et al. (2015) Arora Kanika et al. 2015\.  _Research methods: The essential knowledge base_.  Cengage learning.
  * Knief and Forstmeier (2021) Ulrich Knief and Wolfgang Forstmeier. 2021.  Violating the normality assumption may be the lesser of two evils.  _Behavior Research Methods_ 53, 6 (2021), 2576–2590.
  * Li et al. (2020) Zhixing Li, Yue Yu, Minghui Zhou, Tao Wang, Gang Yin, Long Lan, and Huaimin Wang. 2020.  Redundancy, context, and preference: An empirical study of duplicate pull requests in OSS projects.  _IEEE Transactions on Software Engineering_ (2020).
  * Lin et al. (2007) Yu-Ru Lin, Hari Sundaram, Yun Chi, Junichi Tatemura, and Belle L Tseng. 2007.  Blog community discovery and evolution based on mutual awareness expansion. In _IEEE/WIC/ACM International Conference on Web Intelligence (WI’07)_. IEEE, 48–56.
  * Lüdecke (2021) Daniel Lüdecke. 2021\.  Assessment of Regression Models Performance.  https://cran.r-project.org/web/packages/performance/performance.pdf.
  * Lungu et al. (2010) Mircea Lungu, Michele Lanza, Tudor Gîrba, and Romain Robbes. 2010.  The small project observatory: Visualizing software ecosystems.  _Science of Computer Programming_ 75, 4 (2010), 264–275.
  * Madey et al. (2002) Gregory Madey, Vincent Freeh, and Renee Tynan. 2002\.  The open source software development phenomenon: An analysis based on social network theory. In _Americas Conference on Information Systems (AMCIS2002)_. 1806–1813.
  * Meneely et al. (2013) Andrew Meneely, Ben Smith, and Laurie Williams. 2013\.  Validating software metrics: A spectrum of philosophies.  _ACM Transactions on Software Engineering and Methodology (TOSEM)_ 21, 4 (2013), 1–28.
  * Mens and Goeminne (2011) Tom Mens and Mathieu Goeminne. 2011.  Analysing the evolution of social aspects of open source software ecosystems. In _Proceedings of the Workshop on Software Ecosystems_. Citeseer, 1–14.
  * Nakakoji et al. (2002) Kumiyo Nakakoji, Yasuhiro Yamamoto, Yoshiyuki Nishinaka, Kouichi Kishida, and Yunwen Ye. 2002\.  Evolution patterns of open-source software systems and communities. In _Proceedings of the international workshop on Principles of software evolution_. 76–85.
  * Newman (2003) Mark EJ Newman. 2003\.  Mixing patterns in networks.  _Physical review E_ 67, 2 (2003), 026126.
  * Newman (2004) Mark EJ Newman. 2004\.  Analysis of weighted networks.  _Physical review E_ 70, 5 (2004), 056131.
  * Newman and Girvan (2004) Mark EJ Newman and Michelle Girvan. 2004.  Finding and evaluating community structure in networks.  _Physical review E_ 69, 2 (2004), 026113.
  * Ngamkajornwiwat et al. (2008) Kawin Ngamkajornwiwat, Dongsong Zhang, A Gunes Koru, Lina Zhou, and Robert Nolker. 2008\.  An exploratory study on the evolution of OSS developer communities. In _Proceedings of the 41st Annual Hawaii International Conference on System Sciences (HICSS 2008)_. IEEE, 305–305.
  * O’Reilly (1999) Tim O’Reilly. 1999\.  Lessons from open-source software development.  _Commun. ACM_ 42, 4 (1999), 32–37.
  * Palla et al. (2007) Gergely Palla, Albert-László Barabási, and Tamás Vicsek. 2007.  Quantifying social group evolution.  _Nature_ 446, 7136 (2007), 664–667.
  * Panichella et al. (2014a) Sebastiano Panichella, Gabriele Bavota, Massimiliano Di Penta, Gerardo Canfora, and Giuliano Antoniol. 2014a.  How developers’ collaborations identified from different sources tell us about code changes. In _2014 IEEE International Conference on Software Maintenance and Evolution_. IEEE, 251–260.
  * Panichella et al. (2014b) Sebastiano Panichella, Gerardo Canfora, Massimiliano Di Penta, and Rocco Oliveto. 2014b.  How the evolution of emerging collaborations relates to code changes: an empirical study. In _Proceedings of the 22nd International Conference on Program Comprehension_. 177–188.
  * Pinzger et al. (2008) Martin Pinzger, Nachiappan Nagappan, and Brendan Murphy. 2008\.  Can developer-module networks predict failures?. In _Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of software engineering_. 2–12.
  * Raja and Tretter (2012) Uzma Raja and Marietta J Tretter. 2012.  Defining and evaluating a measure of open source project survivability.  _IEEE Transactions on Software Engineering_ 38, 1 (2012), 163–174.
  * Robert and Romero (2015) Lionel Robert and Daniel M Romero. 2015.  Crowd size, diversity and performance. In _Proceedings of the 33rd Annual ACM Conference on Human Factors in Computing Systems_. 1379–1382.
  * Rossetti and Cazabet (2018) Giulio Rossetti and Rémy Cazabet. 2018.  Community discovery in dynamic networks: a survey.  _ACM Computing Surveys (CSUR)_ 51, 2 (2018), 1–37.
  * Schielzeth et al. (2020) Holger Schielzeth, Niels J Dingemanse, Shinichi Nakagawa, David F Westneat, Hassen Allegue, Céline Teplitsky, Denis Réale, Ned A Dochtermann, László Zsolt Garamszegi, and Yimen G Araya-Ajoy. 2020.  Robustness of linear mixed-effects models to violations of distributional assumptions.  _Methods in Ecology and Evolution_ 11, 9 (2020), 1141–1152.
  * Schreiber and Zylka (2020) Roland Robert Schreiber and Matthäus Paul Zylka. 2020.  Social Network Analysis in Software Development Projects: A Systematic Literature Review.  _International Journal of Software Engineering and Knowledge Engineering_ 30, 03 (2020), 321–362.
  * Shannon (1948) Claude Elwood Shannon. 1948\.  A mathematical theory of communication.  _The Bell system technical journal_ 27, 3 (1948), 379–423.
  * Singh (2010) Param Vir Singh. 2010\.  The small-world effect: The influence of macro-level properties of developer collaboration networks on open-source project success.  _ACM Transactions on Software Engineering and Methodology (TOSEM)_ 20, 2 (2010), 1–27.
  * Surian et al. (2010) Didi Surian, David Lo, and Ee-Peng Lim. 2010.  Mining collaboration patterns from a large developer network. In _2010 17th Working Conference on Reverse Engineering_. IEEE, 269–273.
  * Syeed et al. (2013) MM Mahbubul Syeed, Imed Hammouda, and Tarja Systä. 2013\.  Evolution of open source software projects: A systematic literature review.  _Journal of Software_ 8, 11 (2013), 2815–2829.
  * Tamburri et al. (2019) Damian Andrew Andrew Tamburri, Fabio Palomba, and Rick Kazman. 2019\.  Exploring community smells in open-source: An automated approach.  _IEEE Transactions on software Engineering_ (2019).
  * Tsay et al. (2014a) Jason Tsay, Laura Dabbish, and James Herbsleb. 2014a.  Influence of social and technical factors for evaluating contribution in GitHub. In _Proceedings of the 36th international conference on Software engineering_. 356–366.
  * Tsay et al. (2014b) Jason Tsay, Laura Dabbish, and James Herbsleb. 2014b.  Let’s talk about it: evaluating contributions through discussion in GitHub. In _Proceedings of the 22nd ACM SIGSOFT international symposium on foundations of software engineering_. 144–154.
  * Van Antwerp and Madey (2010) Matthew Van Antwerp and Greg Madey. 2010.  The importance of social network structure in the open source software developer community. In _2010 43rd Hawaii International Conference on System Sciences_. IEEE, 1–10.
  * Vasilescu et al. (2015) Bogdan Vasilescu, Daryl Posnett, Baishakhi Ray, Mark G.J. van den Brand, Alexander Serebrenik, Premkumar Devanbu, and Vladimir Filkov. 2015\.  Gender and Tenure Diversity in GitHub Teams. In _Proceedings of the 33rd Annual ACM Conference on Human Factors in Computing Systems_ (Seoul, Republic of Korea) _(CHI ’15)_. Association for Computing Machinery, New York, NY, USA, 3789–3798.  https://doi.org/10.1145/2702123.2702549
  * Wang (2012) Jing Wang. 2012\.  Survival factors for Free Open Source Software projects: A multi-stage perspective.  _European Management Journal_ 30, 4 (2012), 352–371.
  * Wang et al. (2007) Yi Wang, Defeng Guo, and Huihui Shi. 2007.  Measuring the evolution of open source software systems with their communities.  _ACM SIGSOFT Software Engineering Notes_ 32, 6 (2007), 7–es.
  * Weiss et al. (2006) Michael Weiss, Gabriella Moroiu, and Ping Zhao. 2006.  Evolution of open source communities. In _IFIP International Conference on Open Source Systems_. Springer, 21–32.
  * Wessel et al. (2018) Mairieli Wessel, Bruno Mendes De Souza, Igor Steinmacher, Igor S Wiese, Ivanilton Polato, Ana Paula Chaves, and Marco A Gerosa. 2018\.  The power of bots: Characterizing and understanding bots in oss projects.  _Proceedings of the ACM on Human-Computer Interaction_ 2, CSCW (2018), 1–19.
  * Xu et al. (2005) Jin Xu, Yongqin Gao, Scott Christley, and Gregory Madey. 2005\.  A topological analysis of the open souce software development community. In _Proceedings of the 38th Annual Hawaii International Conference on System Sciences_. IEEE, 198a–198a.
  * Xuan and Filkov (2014) Qi Xuan and Vladimir Filkov. 2014.  Building it together: Synchronous development in OSS. In _Proceedings of the 36th International Conference on Software Engineering_. 222–233.