Fault-Prone Source File Analysis Focusing on theContribution Entropy in Open Source Development
Kazuki Yamauchi∗ , Hirohisa Aman† , Sousuke Amasaki‡ , Tomoyuki Yokogawa‡ and Minoru Kawahara†∗ Graduate School of Science and Engineering, Ehime University

Matsuyama, Ehime, 790–8577 Japan† Center for Information Technology, Ehime University

Matsuyama, Ehime, 790–8577 Japan‡ Faculty of Computer Science and Systems Engineering, Okayama Prefectural University

Soja, Okayama, 719–1197 Japan

Abstract—Open source software (OSS) products have been
widely used for information systems, and a successful quality
management of OSS development has become one of key topics
in the information technology world. Since the development
and maintenance of an OSS product is driven by various
developers, it would be worthy to focus on their contributions
and the cooperative structure. This paper proposes to measure adeveloper’s contribution to a source file as the cumulative lines
of code that he/she has changed on the file, and to evaluate thebalance of contributions to the file among different developers
in a form of an entropy. Through an empirical study using datacollected from 10 major OSS projects, the following findings arereported: (1) a source file which has been maintained by two or
more developers (entropy>0) is about two times more likely to befaulty than a file which has been done by only a single developer(entropy=0); (2) when two or more developers have maintained asource file and their contributions are more imbalanced (a lower
entropy), the source file is more fault-prone.

I. I NTRODUCTION
In recent years, open source software (OSS) products havebeen more and more popular in the information technologyrelated business world [1]. For example, commercial software
products may partially leverage OSS products, or commercial
services may run on OSS-based servers. As OSS products
become more popular, the importance of their successful
quality managements gets higher. Source files of OSS products
and their development history data (commit logs) are almost
always available to everyone through their software repositories, and those source files and history data are useful researchmaterials for the quality management of OSS products. Indeed,
the mining software repositories (MSR) [2] has been oneof the hottest topics in the field of software engineering,and there have been many MSR studies: for example, faultprone program predictions based on the fix history [3], [4];maintenance supports focusing on the logical couplings (cochange relationships) among source files [5], [6]; assessmentsof code change impacts [7], [8]; just-in-time quality assurance
methods [9], [10], etc.
More recently, the MSR studies have focused on not only
the OSS products and their development processes but also
the developers [11], [12], [13], [14], [15]. That is to say, in
addition to the analysis of “what was changed in a source
file” and “when the change was made,” MSR studies havefocused on “who made the changes” and “how the developers
have been involved” as well. Since a success of an OSS
project usually depends on the contributions by developers,
it is worthy enough to understand developers’ contributions
and the collaborations among different developers in more
depth toward a better quality management of OSS project.
As a part of a developer-oriented MSR study, we focuses on a
structure for cooperation among developers in the development
and maintenance of a source file, and tackle the following
two questions in this paper. (1) Is there a difference in thecode quality between a multi-developer file (a source filewhich has been developed and maintained by two or moredevelopers) and a single-developer file (a source file which has
been done by a single developer)? (2) when a source file has
been maintained by two or more developers, does the balanceof their contributions have an impact on the code quality?
The first question is on whether a source file has been maintained by only a single developer or not. In many OSS projects,
while many developers have joined in the development andmaintenance of source files, there are also source files whichhave been maintained by a certain developer only—no otherperson touched these files. We will empirically study if thedifference of contribution style, “single” vs. “multi,” has asignificant impact on the code quality in terms of the faultproneness.
The above second question is on an detailed insight into
the contributions by two or more developers. In this paper, adeveloper’s contribution to a source file is quantified by the
cumulative number of source code lines which the developer
has added to or deleted from the source file1 . When n (≥ 2)
developers have contributed to a source file, there are a lot ofvariations in the balance of contributions among n developers.
For example, one of the developers may have dominantly
contributed to the source file and the contributions by theremaining n − 1 developers may be really small. For anotherexample, all of n developers may have approximately equallycontributed to the source file. The difference of these two
example cases may cause a remarkable difference in the faultproneness of source files. We will evaluate the balance of
1 A code modification is interpreted as a pair of code addition and deletion.

developers’ contributions by introducing a metric using thenotion of entropy, and analyze the relationship between themetric value and the fault-proneness.
The remainder of this paper is organized as follows. Section
II explains our research questions and proposes our measure ofdevelopers’ contributions. Section III reports our data analysis
and discusses the results. Section IV briefly describes therelated work. Finally, Section V presents our conclusion andfuture work.
II. D EVELOPER ’ S C ONTRIBUTION
A source code repository stores source files and their change
history. Thus, for each source file, we can easily obtain thefollowing information from the repository: “when the file wascreated,” “when the file was changed,” “what was changed in
the file (the difference between before and after the change),”“who made the creation/change,” etc. By analyzing these data,
we can observe the contributions of developers to the development and maintenance of the source file. For example, given
a source file, we can investigate “who have been involved
in its development and maintenance” and “how many sourcelines of code have been added, deleted or changed by eachof the developers.” They form a history of contributions by
developers. Different source files have different histories ofdevelopers’ contributions. While one source file may havebeen developed and maintained by a certain developer only,
another source file may have been done by many different
developers. Moreover, for the latter kind of source file, there
would be many variations in the structure for cooperation
among developers. For example, suppose two developers dA
and dB have contributed to a set of source files. While one
source file may have been dominantly maintained by dA andthe contribution by dB is a little, another source file may havebeen evenly maintained by both dA and dB . Our researchinterest is to analyze how such differences of contributions
affect the code quality, especially, the fault-proneness of source
files.
Notice that we focus only on the change history stored in
the code repository in order to see a developer’s contribution;
there are also other types of contributions such as the code
reviews, tests and discussions. Although it is ideal to take into
account all kinds of contributions, it is hard to collect all ofsuch data from any OSS project. Since the code repository
is commonly available at any OSS project, we will limit our
focus of “contribution” to the code changes in this paper.
A. Research Questions
According to our research interest mentioned above, we now
set our research questions (RQs) as follows.
RQ1: Is there a difference in the code quality between asource file which has been developed and maintainedby two or more developers and a source file which
has been done by a single developer?
RQ2: When a source file has been maintained by two or
more developers, does the balance of their contributions have an impact on the code quality?

We explain the reasons why we set the above questions.
RQ1 is a fundamental question on the difference of developers’ contributions to source files. Needless to say, a source
file can be classified into two categories: 1) a source filewhich has been developed and maintained by two or moredevelopers, and 2) a source file which has been done by asingle developer. For the sake of convenience, we will call theformer source file as “multi-developer file” and the latter one
as “single-developer file.” An involvement of more developers
to the maintenance of a source file might be better to enhance
the code quality because the code would be reviewed bymore people. However, there might also be an opposite effect:
such an involvement might cause unnecessary confusion in
the coding. Shortly, RQ1 is our simple question: “which is
better” in terms of the code quality, multi-developer file orsingle-developer file?
Next, RQ2 is a further question on how developers contribute to the development and maintenance of source files.
As mentioned above, there would be various structures forcooperation in the maintenance of multi-developer files. The
aim of RQ2 is to clarify whether a difference in the structure
for cooperation is related to the code quality or not, fromthe perspective of the balance of developers’ contributions tomulti-developer files.
In this paper, we will assess a code quality of a source file by
the fault-proneness of the files. Through data analyses on the
RQ1 and RQ2, we would be able to see what kind of source
files are fault-prone and require more careful review, from apoint of view on a structure of contributions by developers.
B. Contribution Entropy
For our data analysis on RQ2, we now introduce a novel
metric which is called “contribution entropy.” This metricfocuses on the source lines which have been changed by eachdeveloper, and it quantifies the balance of these changed lines
among developers as an “entropy.” The notion of entropy iswell-known as a measure of information randomness in theinformation theory [16]. We apply this notion to an evaluationof the balance among developers’ contributions (the amountof changed lines) to a source file. Shortly, we consider thata source file has a high contribution entropy if the file has
been evenly changed by two or more developers because therandomness of contribution is high; if the contributions are
dominant by a certain developer, the randomness is low, so
the contribution entropy of the file is low.
As a previous study, Taylor et al. [11] proposed the author
entropy. They focused on “who is the author of each sourceline” in a source file. Fig. 1 presents a simple example of acode fragment showing the author of each line2 , where they
considered the author of line to be who edited it last. Then,the author entropy evaluates the balance of source lines amongauthors (developers). While the author entropy is an attractive
measure of developers’ contributions to a source file, there is
2 This example is based on the result of running “git blame” forsrc/main/java/io/reactivex/Completable.java in RxJava.

author line#
d1
1
d2
2
d3
3
d1
4
d2
5
d1
6
d2
7
d2
8
..
..
.
.

code
public final void subscribe(CompletableObserver s) {ObjectHelper.requireNonNull(s, ”s is null”);
try {s = RxJavaPlugins.onSubscribe(this, s);subscribeActual(s);} catch (NullPointerException ex) {..
.

Fig. 1. A simple example showing the author of each source line.

yet another way of evaluating the contributions focusing not
only the current code but also the past code. For example,
while the author of the second line in Fig. 1 is developer d2 ,it was a result of rewriting the line by d2 and its original code
was written by d3 . That is to say, the contribution of d3 tothe second line seems to be overridden by d2 when we use
the author entropy. Since it would better to regard that bothd2 and d3 have contributed to the second line in Fig. 1, we
introduce another notion using the “cumulative” source lineschanged by each developer.
There are two key reasons why we focus on the cumulativechanged lines rather than the current lines. One reason is that
we consider a deletion of source code to be a contribution as
well. Even if a developer just deleted some source code froma source file at a commit, it is one of essential modifications
to build the current version of the source file. Thus, we should
not avoid considering a code deletion in order to evaluate adeveloper’s contribution. Another reason is that there can be
two different developers before and after a code modification.
Suppose developer di modified a source code which was
originally written by different developer dj . Although themodification is a di ’s contribution, it may be based on theoriginal code and that is a dj ’s contribution. Hence, it would
be reasonable to take into account not only di but also dj forevaluating their contributions.
Let us take a simple example presented in Fig. 2 and Table
I. In the example, the source file was originally created bydeveloper d1 at revision 1 (“Rev-1” in Fig. 2). Through code
modifications and deletions by three developers d1 , d2 andFig. 2. A simple example of code change history.

TABLE IA SIMPLE EXAMPLE OF CODE CHANGE HISTORY.
revision
1
2
3
4
5

event
d1 created a source file (100 lines).
d1 deleted 10 lines, andmodified 15 lines (deleted 15 & added 15).
d2 modified 20 lines (deleted 20 & added 20),
modified 18 lines (deleted 18 & added 18),
and deleted 5 lines.
d3 deleted 20 lines.
d2 modified 15 lines (deleted 10 & added 15).

d3 , we obtain the revision 5 and then d2 is the developer
who last touched all lines of the source code (see “Rev-5 by
d2 ” row in Fig. 2; the green parts and the red ones signify
d1 ’s contributions and d2 ’s contributions, respectively). Since
the previous work [11] focused only on the current version(revision 5), it evaluates that d1 and d3 have no contributions
to this source file. This example shows an importance of ourviewpoint and our motivation in this paper.
Now we define the “contribution entropy” as follows.
Definition 1 (Contribution Entropy):
Given a source file f , and suppose that n developers di(for i = 1, . . . , n) have been involved in the development andmaintenance of f . Let ci (f ) be the contribution by di , whichis the total number of source lines added to or deleted fromf by di until the current version3 . Then, the following pi (f )is a measure of the relative contribution to f by di (for i =1, . . . , n):ci (f ).
(1)pi (f ) = n∑
ci (f )
i=1

We define the contribution entropy of f as:0(n = 1),n∑−1
H(f ) =pi (f ) log2 pi (f ) (n > 1) .
 log n2i=1(2)Constant log2 n in the denominator is used for normalizing
the range of H(f ) to [0, 1]. When n = 1, we specially defineas H(f ) = 0 because log2 n = 0.
□
As we described above, if f is a single-developer file, n = 1
so we have H(f ) = 0. When f is a multi-developer file,H(f ) varies from 0 to 1 in accordance with the balanceof pi (f ) among developers {di }. If all pi (f )’s are equal,i.e., all developers’ contributions to f are truly equal, we
get H(f ) = 1. As the contributions get more imbalanced
among developers, H(f ) becomes lower. That is to say, as thecontribution structure of f gets closer to a certain developer’s
monopoly, H(f ) becomes closer to 0.
3 One line modification is regarded as one line addition after one line
deletion. Thus, the contribution is expressed as two lines of changed code.

In the example case shown in Table I, we have c1 (f ) =140, c2 (f ) = 106 and c3 (f ) = 20 just after revision 5. From
Eqs.(1) and (2), we get
p1 (f ) =140
≃ 0.5263,
140 + 106 + 20

p2 (f ) =106
≃ 0.3985,
140 + 106 + 20

p3 (f ) =20
≃ 0.0752,
140 + 106 + 20

and

then
H(f ) =

−1
{ p1 (f ) log2 p1 (f )+log2 3p2 (f ) log2 p2 (f ) + p3 (f ) log2 p3 (f ) }≃ 0.8183.
While all lines of f just after revision 5 look to be ones
made by only d2 (see Fig. 2), d1 has more contributions thand2 if we focus on not only the current state but also the change
history of f ; if we focused only on the current state (revision
5) of f , the contribution is considered to be a monopoly ofd2 and H(f ) becomes zero.
III. DATA A NALYSIS
On our RQs mentioned in Section II-A, we conducted adata analysis using popular OSS projects. In this section, we
report and discuss the results.
A. Data Source
We collected data from popular OSS projects shown in
Table II. In order to ensure the generality and usefulness of ourresults as high as possible, we selected them: they all ranked
in top 10 Java projects4 in terms of “stars” at the GitHub.

B. Procedure
We conducted our data collection and analysis in the following procedure.
1) Make a copy of the repository from the GitHub5 .
2) Get the development history of each source file from therepository.
For each source file included in the current version,
we investigate its development history (change logs) byusing “git log” command. In the investigation, we trace
the renaming operations to the file as well.
3) Extract data items required for our analysis.
By analyzing the commit logs that we got at step 2),
we extract the following items for each commit of eachsource file: (a) commit hash, (b) whether it is aimed
at fixing a fault or not, (c) author’s name, (d) author’s
e-mail address, and (e) changed source lines.
The item (b) is decided if the corresponding commit
message contains a fault-fix-related keyword or not [17].
4) Organize the data collected at step 3).
Since there are source files which were renamed throughcommits, we assign unique file IDs to source files inorder to identify them.
There may be an author who uses two or more different
names or e-mail addresses on the repository. We tried
integrating duplicated author data by the following set ofrules—it is a simpler version of the algorithm proposedby Bird et al. [18]: (1) if two authors have different
addresses but the same name, then we regard them as
the same author; (2) if two authors have the same address
but different names, then we regard them as the sameauthor.
5) Analyze the collected data on RQs.
For RQ1:a) For each source file f , we see whether f is asingle-developer file or a multi-developer file atthe end of the observation period (see Fig. 3), andcheck if a fault fix is occurred at f during theexamination period or not. Here, the observation
period signifies the days in which we check thedevelopment and maintenance of the source file,

TABLE IIS URVEYED OSS PROJECTS
project
Butter Knife
Elasticsearch
Glide
Guava
Java Design Patterns
KotlinMPAndroidChart
OkHttpRetrofit
RxJavatotal# of source files
125
5, 527609
3, 131
1, 011
5, 090235
291
210
1, 49717, 726

4 This ranking at the end of November 2017.

# of commits
279
16, 671
1, 382
4, 054885
21, 406
1, 216
1, 344535
731
48, 503

Fig. 3. Observation period and examination period.
5 The repository URLs are https://github.com/{ akeWharton/butterknife,
elastic/elasticsearch, bumptech/glide, google/guava, iluwatar/java-designpatterns,
JetBrains/kotlin,
PhilJay/MPAndroidChart,square/okhttp,square/retrofit, ReactiveX/RxJava}.git, respectively.

C. Results for RQ1
On RQ1, we compared the set of single-developer source
files and that of multi-developer ones in terms of the faultproneness. Table III and Fig. 4 show the results. Notice that the
total number of source files shown in Table III decreases fromthe one show in Table II because new source files younger
than 15 months (the observation period plus the examination
period) are not included in our analysis.
The collected source files were dominated by the multideveloper files: about 62% (≃ 9675/15664) of source files
were multi-developer. As a result, the multi-developer files
are about two times more likely to be faulty than the singledeveloper one: 14.73% vs. 7.00%, and their difference wasstatistically significant at a 5% significance level6 .
TABLE IIIC OMPARISON OF SINGLE - DEVELOPER SOURCE FILES AND
MULTI - DEVELOPER ONES
file typemulti-developer
single-developer
total# of source files
9, 6755, 98915, 664# of faulty ones
1, 425419
1, 844FR
14.73%
7.00%
11.77%

6 The null hypothesis “the FR in multi-developer files is equal to the FR insingle-developer files” was rejected by a χ2 test with χ2 = 212.61, df = 1
and p value < 2.2 × 10−16 .

0.20

fault rate (FR)and the examination period corresponds to the daysin which we decide the file is faulty or not. Since a
new source file may be immature and require somefixes, we empirically set the observation period as
1 year from the day that f was newly created, andthe examination period as 3 months from the endof the observation period, respectively.
b) Classify the set of source files into two subsets:
the set of single-developer files and that of multideveloper ones. Then, compare their rates of faulty
source files (the fault rates: FRs). A higher FR
value means a higher fault-proneness of source files
in the corresponding subset.
For RQ2:a) For each source file f , compute its contribution
entropy, H(f ), at the end of the observation period(see Fig. 3). Then, we check if a fault fix is
occurred at f during the examination period or not,which is the same as the above step a) for RQ1.
b) Classify the set of source files into five subsets
according to their contribution entropy: C0, C1,
C2, C3 and C4. C0 is the set of source files suchthat H(f ) = 0, i.e., the set of single-developer
files. The remaining source files are categorized
into C1 – C4 corresponding to equally divided
ranges of H(f ): C1, C2, C3 and C4 correspondto 0 < H(f ) ≤ 1/4, 1/4 < H(f ) ≤ 2/4,
2/4 < H(f ) ≤ 3/4 and 3/4 < H(f ) ≤ 1,
respectively.
After that, compare FRs among C0 – C4.

0.15

total FR
0.10
0.05
0.00
multi

singlefile typeFig. 4. Comparison of the fault-proneness: single-developer source files vs.
multi-developer ones.

D. Discussions for RQ1
We compared multi-developer source files with singledeveloper ones in terms of the fault-proneness. The resultsof data analysis showed that a multi-developer file tends tobe more fault-prone than a single-developer one. The fault
rate of multi-developer files is about two times higher thanthat of single-developer ones. In general, it would not beeasy to appropriately comprehend and update other people’scode. Hence, such a difficulty may cause the above striking
difference between the two types of source file.
Now we consider a relationship with the program size
as well. The lines of code (LOC), one of the famous size
metrics, is well-known metric which is highly related to thefault-proneness of programs [19]: a program having a higher
LOC is more fault-prone in general. The above trend might
be different according to the program size (LOC). Thus, wecategorize source files by their LOC values, then compare theFRs between multi-developer files and single-developer ones
within each category. Table IV and Fig. 5 show the results,
where we have four categories according to the quartile of
LOC: (1) LOC ≤ 12, (2) 12 < LOC ≤ 41, (3) 41 < LOC≤ 113, and (4) 113 < LOC.
As Fig. 5 shows, in the relatively large-sized source files
whose LOC categories are (3) or (4), the magnitude relationship of FR between multi-developer files and single-developer
files is the same as the total result shown in Fig. 4. Moreover,the gap of FR between file types gets larger as the source file
becomes larger. On the other hand, interestingly, the magnituderelationship of FR inverts in the relatively small-sized source
files whose LOC categories are (1) or (2). The difference of

TABLE IVC OMPARISONS OF SINGLE - DEVELOPER FILES AND MULTI - DEVELOPERWITHIN LOC CATEGORIESLOC category(1) LOC ≤ 12(2) 12 <LOC ≤ 41(3) 41 <LOC ≤ 113(4) 113 < LOC

file
type
multi
singlemulti
singlemulti
singlemulti
single# of source
files
1, 7272, 3112, 145
1, 7182, 715
1, 1393, 088821# of faulty
ones
49
98
105
123
322
87
949
111

FR
2.84%
4.24%
4.90%
7.16%
11.86%
7.64%
30.73%
13.52%TABLE V
C OMPARISON OF SOURCE FILES CATEGORIZED BY THEIR CONTRIBUTION

typefault rate (FR)

0.3

multi
singleENTROPY

category
C0
C1
C2
C3
C4

0.2

0.1

0.0
(1)
<=12

(2)
12−41

(3)
41−113# of source files
7, 087
1, 6282, 2402, 6242, 085# of faulty ones
445
399
412
356
232

FR
6.28%
24.50%
18.39%
13.57%
11.13%(4)>=113

Fig. 5. Comparisons of the fault-proneness: single-developer files vs. multideveloper ones within LOC categories.

FR is statistically significant at 5% significance level in each
LOC category7 .
As mentioned above, a successful comprehension and update of other programmer’s code is not easy task. The difficulty
would increase as the program gets larger. Therefore, it seems
to be natural that the gap of FR becomes the largest one in
the LOC category (4). Similarly, as the program gets smaller,
a proper comprehension and update of code would become
easier even if the code was written by other programmers. A
smaller program originally tends to be less fault-prone, andfurthermore, its quality might be further enhanced throughcontributions by other developers. Hence, the inversion of themagnitude relationship in FR looks a natural trend as well.
Notice that the above results are derived from the dataof “fault fix” but not of “fault injection.” There may be acase such that: a fault was injected into a source file when
the file was a single-developer one, and then the fault was
detected and fixed after the file became a multi-developer one
by a participation of another developer. One of key reasons
why more faults were detected and fixed in multi-developer
files might be that more developers reviewed these files. In
other words, a single-developer file might have latent faults
which have not been detected yet because the file has been
maintained by a certain developer only. Although our focus
on whether a source file is a single-developer file or not seems
to be noteworthy through this data analysis, we have to do amore detailed analysis in the future: a further analysis on therelationship between the fault injection and the switching offile type from single-developer to multi-developer.
E. Results for RQ2
On RQ2, we classified the source files into five categories
C0, C1, . . ., C4 by their contribution entropy, and comparedthese categories in terms of the fault-proneness. Table V and
Fig. 6 show the results.
As a result, the least fault-prone category is C0 whose
contribution entropy is zero, i.e., the category of the singledeveloper files. In contrast, the most fault-prone category is
7 (1) χ2 = 5.1557, df = 1 and p value = 0.02317; (2) χ2 = 8.4042,
df = 1 and p value = 0.003744; (3) χ2 = 14.634, df = 1 and p value= 0.0001305; (4) χ2 = 99.438, df = 1 and p value < 2.2 × 10−16 .

fault rate (FR)LOC category
0.2

0.1

0.0
C0

C1

C2

C3

C4

contribution entropy category
Fig. 6. Comparison of source files categorized by their contribution entropy.

C1 which is right next to C0. Category C1 corresponds tosource files in which the developers’ contributions are highly
imbalanced. The fault-proneness (the FR value) decreases as
the contribution entropy gets higher, i.e., as the structure ofcontributions gets away from the most imbalanced state.
F. Discussions for RQ2
In order to investigate the impact of contribution balanceamong developers on the fault-proneness, we categorized
source files by their contribution entropy into five categories
C0 – C4, and compared their FR values. As a result, multideveloper source files in category C1 are the most fault-prone.
In such a source file, there are two or more developers who
have had contributed to the file, but their contributions arehighly-imbalanced and one of the corresponding developers isdominant. That state of source file would be made when thefile type was just changed from the single-developer to themulti-developer. By a participation of another developer inthe maintenance of a source file, it seems to become unstablein terms of the code quality and the most fault-prone.
As with the above discussion on RQ1, we categorized thesource files by their LOC, and examined changes in FR overC0 – C4 as well. Table VI presents the results, where thehighest FR within each LOC category is emphasized.
As the results, category C1 was always the most fault-prone
regardless of LOC. Thus, we can say with more confidence
that multi-developer source files with highly-imbalanced contributions are fault-prone. Such status would be created by aparticipation of a new developer in the maintenance of a source
file. While participations of new developers are important to a
successful OSS project operation, the quality of a source file
may become transiently unstable when another programmer
started to change a part of code. That is to say, it would

TABLE VI
C OMPARISONS OF FR S OVER THE CONTRIBUTION ENTROPY CATEGORIESWITHIN LOC CATEGORIES
category
LOC(1)
LOC ≤ 12(2)
12 <LOC ≤ 41(3)
41 <LOC ≤ 113(4)
113 < LOC

entropy
C0
C1
C2
C3
C4
C0
C1
C2
C3
C4
C0
C1
C2
C3
C4
C0
C1
C2
C3
C4

# of source
files
2, 873
45
96
219
498
2, 062
232
491
618
694
1, 252
485
744
888
512
900
866
909
899
381

# of faulty
ones
98
3
2
14
13
130
15
23
24
44
95
84
114
71
52
122
297
273
247
123

FR
3.41%
6.67%
2.08%
6.39%
2.61%
6.30%
6.47%
4.68%
3.88%
6.34%
7.59%
17.32%
15.32%
8.00%
10.16%
13.56%
34.30%
30.00%
27.48%
32.23%

be useful to pay more attention to such a source file for a
successful OSS project management.
We can consider the following two potential reasons why
C1 is the most fault-prone category of source file: (1) a fault
was created by a new developer through a code modification,or (2) a fault was detected by a new developer. In general,a code modification has a risk of a fault creation [20], [21].
Since it is not easy task to accurately comprehend and properlychange a source code written by other programmers, the faultcreation risk would get higher when a code change is madeby a new developer. In another perspective, a participation ofa new developer includes another code review. Then, a latent
fault might be detected as a result of code review by a new
developer. In both cases, more faults may be detected fromsource files of category C1. On the other hand, source files in
categories C2, C3 or C4 tend to be more changed and reviewed
more times by two or more developers. Through those codechanges and reviews, the source files may be polished andbecome less fault-prone. Because our data is based on fault-fix
events in the repository, we cannot clearly analyze the above
potential reasons in this study. In order to examine the reason
why C1 is so fault-prone and the fault-proneness gets lower as
the contribution entropy becomes higher, we need to performa further analysis using data of “fault injections” in the future.
G. Threats to Validity
We analyzed OSS projects whose main-development language is Java. Since our data collection method does notdepend on any Java-specific feature, we can perform a similar
analysis to other projects developed in other languages without
any changes of our method if their code is maintained with
Git. Since OSS projects written in other languages may show
different trends, it is a threat to the validity regrading thegenerality of our findings, and our significant future work.

In order to ensure quality of code, some OSS projects
have strict checking (reviewing) systems for a code change
proposed by a developer. Such a checking system may have a
big impact on our results of data analysis. To mitigate such a
threat to validity, we collected a lot of data from various OSS
projects in different domains. We plan to perform a further
analysis focusing on project-specific features in the future.
IV. R ELATED W ORK
Bird et al. [12] focused on an ownership of a source file: anownership metric in their paper is the percentage of commits
made by major contributors. They reported that a source filehaving lower ownership is likely to be more fault-prone. Amanet al. [22] performed a survival analysis of the time to fault
fix, and proved the trend such that a source file modified
by a new developer has a shorter time to the occurrenceof the next fault fix. These previous work showed a risk oftransiently increasing the fault-proneness of a source file by aparticipation of other developers in the maintenance of the file.
While the notion of such a risk is common to this study, we
performed a finer-grained data analysis which is at a sourceline-change level rather than a commit level.
Matsumoto et al. [23] proposed developer metrics andutilized those metrics for predicting faults in modules. Throughan empirical study using a dataset of the Eclipse Platformproject, they showed that their developer metrics can be usefulexplanatory variables in fault-prone module prediction models.
Moreover, they reported that a module which has been touchedby more developers tends to be more fault-prone. While theirfindings are consistent with our result for RQ1 mentioned
above, we have also performed an analysis of the relationshipwith the source file (module) size in this paper. Furthermore,
we have studied multi-developer files in terms of the balance ofdevelopers’ contributions rather than the number of developers.
Posnett et al. [13] focused developers’ contributions fromboth the perspective of developer and that of module. In theformer perspective, they quantified the degree to which adeveloper contributes to a certain module; in the latter one,they evaluated the degree to which a module is contributedby a certain developer. Through a data analysis, they reported
that a developer who has contributed to a certain module tends
not to induce a fault, i.e., he/she would be a specialist of themaintenance of the module; a module which is contributed bymore developers may be fault-prone. While we also have thelatter perspective of their work, we analyzed the balance ofcontributions as well in this paper.
V. C ONCLUSION
We focused on the cumulative contributions of developers
to the development and maintenance of a source file, andproposed a novel metric, contribution entropy, to evaluate thebalance of contributions to the file.
We performed a data analysis for 15, 664 source files from10 popular OSS projects. As the results, the following trends
were founds: (1) a source file maintained by two or moredevelopers tends to be more fault-prone than a file maintained

by a certain developer only. The fault-proneness of the formertype source file is about two times higher than that of thelatter-type one; (2) when a source file has been maintained by
two or more developers and the developers’ contributions are
more imbalanced, the source file is more fault-prone. From
the results, the fault-proneness of a source file seems to betransiently increased when the file type changes from singledeveloper to multi-developer, i.e., when another programmer
started to change a part of code. A successful OSS quality
management would be prompted by focusing on such changes
as well.
In order to understand a more detailed impact of anotherprogrammer’s participation, we plan to check not only faultfix commits but also fault-inducing commits, and analyze who
made the corresponding code changes as our significant future
work. Moreover, to predict the code quality stability, we will
examine the impact of number of contributing developers
on the quality, and investigate changes in the contribution
entropy over time. Other our future work includes: (1) a further
analysis using OSS projects whose development languages areother than Java to examine the generality of our findings, and(2) an application of our results to the just-in-time quality
assurance studies.
ACKNOWLEDGMENT
This work was supported by JSPS KAKENHI #16K00099
and #18K11246. The authors would like to thank the anonymous reviewers for their helpful comments to an earlier
version of this paper.
R EFERENCES[1] Black Duck Software, “The 2017 open source 360◦ survey,” https://www.blackducksoftware.com/open-source-360deg-survey, June 2017.
[2] A. E. Hassan, “The road ahead for mining software repositories,” inProc. Frontiers of Softw. Maintenance, Sept. 2008, pp. 48–57.
[3] F. Rahman, D. Posnett, A. Hindle, E. Barr, and P. Devanbu, “Bugcachefor inspections : Hit or miss?” in Proc. 19th ACM SIGSOFT Symp. &13th European Conf. Foundations Softw. Eng., Sept. 2011, pp. 322–331.
[4] C. Lewis and R. Ou, “Bug prediction at google,” http://googleengtools.blogspot.jp/2011/12/bug-prediction-at-google.html, Dec. 2011.
[5] T. Zimmermann, A. Zeller, P. Weissgerber, and S. Diehl, “Mining
version histories to guide software changes,” IEEE Trans. Softw. Eng.,
vol. 31, no. 6, pp. 429–445, June 2005.
[6] N. Ajienka and A. Capiluppi, “Understanding the interplay between the
logical and structural coupling of software classes,” J. Syst. & Softw.,
vol. 134, pp. 120 – 137, Dec. 2017.
[7] A. T. Misirli, E. Shihab, and Y. Kamei, “Studying high impact fixinducing changes,” Empir. Softw. Eng., vol. 21, no. 2, pp. 605–641, June
2016.
[8] S. Suzuki, H. Aman, S. Amasaki, T. Yokogawa, and M. Kawahara,“An application of the pagerank algorithm to commit evaluation on git
repository,” in Proc. 43rd Euromicro Conf. Softw. Eng. & Advanced
Applications, Aug. 2017, pp. 380–383.
[9] S. Kim, E. J. Whitehead, and Y. Zhang, “Classifying software changes:
Clean or buggy?” IEEE Trans. Softw. Eng., vol. 34, no. 2, pp. 181–196,
Mar. 2008.
[10] Y. Kamei, E. Shihab, B. Adams, A. E. Hassan, A. Mockus, A. Sinha,and N. Ubayashi, “A large-scale empirical study of just-in-time quality
assurance,” IEEE Tran. Softw. Eng., vol. 39, no. 6, pp. 757–773, June
2013.
[11] Q. C. Taylor, J. E. Stevenson, D. P. Delorey, and C. D. Knutson, “Author
entropy: A metric for characterization of software authorship patterns,”
in Proc. 3rd Int’l Workshop Public Data about Softw. Dev., pp. 42–47,
Sept. 2008.

[12] C. Bird, N. Nagappan, B. Murphy, H. Gall, and P. Devanbu, “Don’t touch
my code!: Examining the effects of ownership on software quality,” inProc. 19th ACM SIGSOFT Symp. & 13th European Conf. Foundationsof Softw. Eng., Sept. 2011, pp. 4–14.
[13] D. Posnett, R. D’Souza, P. Devanbu, and V. Filkov, “Dual ecologicalmeasures of focus in software development,” in Proc. 35th Int’l Conf.
Softw. Eng., May 2013, pp. 452–461.
[14] K. Yamashita, S. McIntosh, Y. Kamei, and N. Ubayashi, “Magnet or
sticky? an oss project-by-project typology,” in Proc. 11th Working Conf.
Mining Softw. Repositories, May 2014, pp. 344–347.
[15] S. Onoue, H. Hata, and K. Matsumoto, “Software population pyramids:
The current and the future of OSS development communities,” in Proc.
8th Int’l Symp. Empir. Softw. Eng. & Measurement, Sept. 2014, pp.
34:1–34:4.
[16] C. E. Shannon, “A mathematical theory of communication,” The Bell
System Tech. J., vol. 27, no. 3, pp. 379–423, July 1948.
[17] J. Śliwerski, T. Zimmermann, and A. Zeller, “When do changes induce
fixes?” SIGSOFT Softw. Eng. Notes, vol. 30, no. 4, pp. 1–5, May 2005.
[18] C. Bird, A. Gourley, P. Devanbu, M. Gertz, and A. Swaminathan,“Mining email social networks,” in Proc. Int’l Workshop Mining Softw.
Repositories, May 2006, pp. 137–143.
[19] N. E. Fenton and N. Ohlsson, “Quantitative analysis of faults and failuresin a complex software system,” IEEE Trans. Softw. Eng., vol. 26, no. 8,
pp. 797–814, Aug. 2000.
[20] E. N. Adams, “Optimizing preventive service of software products,” IBM
J. Research & Development, vol. 28, no. 1, pp. 2–14, Jan. 1984.
[21] N. Nagappan and T. Ball, “Using software dependencies and churnmetrics to predict field failures: An empirical case study,” in Proc. 1st
Int’l Symp. Empir. Softw. Eng. & Measurement, Sept. 2007, pp. 364–373.
[22] H. Aman, S. Amasaki, T. Yokogawa, and M. Kawahara, “A survival
analysis of source files modified by new developers,” in Product-Focused
Software Process Improvement, M. Felderer et al. Eds. Cham: Springer,
Dec. 2017, pp. 80–88.
[23] S. Matsumoto, Y. Kamei, A. Monden, K. Matsumoto, and M. Nakamura,“An analysis of developer metrics for fault prediction,” in Proc. 6thInt’l Conf. Predictive Models in Softw. Eng., Sept. 2010, pp. 18:1–18:9.