An Exploratory Study on Library Aging by
Monitoring Client Usage in a Software Ecosystem
Raula Gaikovina Kula∗ , Daniel M. German‡ , Takashi Ishio∗ , Ali Ouni∗† and Katsuro Inoue∗∗ Osaka University, Japan‡ University of Victoria, Canada† UAE University, UAE{raula-k, ishio, ali, inoue}@ist.osaka-u.ac.jp

dmg@uvic.ca

ouniaali@gmail.com

Abstract—In recent times, use of third-party libraries has become prevalent practice in contemporary software development.
Much like other code components, unmaintained libraries area cause for concern, especially when it risks code degradation
over time. Therefore, awareness of when a library should be
updated is important. With the emergence of large libraries
hosting repositories such as Maven Central, we can leverage thedynamics of these ecosystems to understand and estimate when alibrary is due for an update. In this paper, based on the conceptsof software aging, we empirically explore library usage as ameans to describe its age. The study covers about 1,500 libraries
belonging to the Maven software ecosystem. Results show thatlibrary usage changes are not random, with 81.7% of the popularlibraries fitting typical polynomial models. Further analysis showthat ecosystem factors such as emerging rivals has an effect on
aging characteristics. Our preliminary findings demonstrate thatawareness of library aging and its characteristics is a promising
step towards aiding client systems in the maintenance of theirlibraries.

I. I NTRODUCTION
In software development, a third-party library is a reusable
software component that provides a certain functionality forclient systems. With promises of quality implementations,libraries offer an effective and efficient means to softwaredevelopment [11]. Reuse of these popular libraries have leadto the rise of large-scale library hosting sites, thus creating an
ecosystem between software that are either library providers(systems) or library users (clients). For instance, in 2010,
Sonatype reported that the Maven Central [3], one of thelargest online ecosystem of Java OSS libraries contained over
260,000 maven libraries and served over 70 million downloads
every week [2]. By November 2016, this ecosystem had
multiplied almost five times over, with more than 1,680,822
maven libraries available for client usage1 . Other notablelibrary ecosystems include the NPM [4] JavaScript package
ecosystem for node.js, RubyGems [5] for Ruby and CPAN
[1] for Perl packages.
Software reliability is widely regarded as the predictionof whether a software system functions as expected without
failure. There are theories of system failure that are related toaging components. Parna’s software aging theory [15] statesthat as time passes, aged components are faced with a higher
likelihood to fail. Similarly, Eick’s code decay principle [10]1 statistics taken from https://search.maven.org/#stats on Nov, 2016

978-1-5090-5501-2/17 c 2017 IEEE

states that unless an ongoing process of maintenance is inplace, changes in external environments creates an:‘unanimous feeling among developers of the software that code degrades through time and maintenance becomes increasingly difficult and expensive’
Mitigation of code decay, which prolongs the lifespan of asoftware is regarded as code rejuvenation.
In this paper, inspired by reliability concepts of software
aging, we model library aging by monitoring client-usage ofa software library within its software ecosystem. Specifically,
we represent library aging characteristics such as library decay
or rejuvenation. Since library age depicts ecosystem changes,
it may prove useful in guiding client developers on whether
they should update, especially if a library is about to reach its
end–of–life.
In an exploratory study of over 4,500 client projects that
adopt and use over 1,500 different java library versions, wefirst investigate whether this phenomena can be modeled as amathematical function. Analyzing library usage data collectedfrom clients, we identify typical polynomial mathematicalcurve models (i.e., First-order model, Second-order model,
or Higher-order model) that ‘best fits’ library aging. Results
show that 93.87% of the tested library versions can fitted
to any of the models. Furthermore, we found that 81.7%
fitted the Higher-order model. To investigate usefulness of thecurves, we took a more qualitative analysis of Higher-ordermodel, by manual examination of the curve shape and aging
characteristics of two case studies. Interestingly, we foundempirical evidence that rivals do have an effect on the aging
of popular libraries.
II. BACKGROUND & D EFINITIONSSoftware ecosystems are defined as ‘a collection of softwaresystems, which are developed and co-evolve in the sameenvironment’ [13]. In the context of library ecosystems, thisconsists of a plethora of library units that share and compete for clients that share a commonality, such as the same
technological platform. For instance, the Maven Central [3]ecosystem host a multitude of library packages that can be
integrated into any java client system.
In this study, we are interested in the relationship betweena client system and its dependent libraries. Therefore, we use
the population count of library dependents (i.e., library usage)
for a certain library, to determine its age. We propose the407

SANER 2017, Klagenfurt, Austria
Early Research Achievements

Accepted for publication by IEEE. c 2017 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.

Point x in time

Peak LU

Point y in time

Client A
use

LU

Library L

Current Usage

Client B

Peak Age

Current Age

timeline

Time t (days)

Fig. 1. Library migration between library and systems. The orange arrow
represents a dependency between Systems A , B and Library L.

following aging process: (1) younger attractive libraries will
experience a growing number of clients that adopt the library.
Later, (2) the library reaches maturity with a maximum peakof clients. Once the library reaches its peak and cannot attract
any more new users or clients abandoning the library, (3) it
falls into library decay. Finally, (4) a library is said to reach its
end of life when its not attracting any more clients or no moreclients remain. Since aging is temporal, from the universe of
known client systems we can determine the usage of a library,which we denote as Library Usage (LU): is a population countof client systems that use a certain library at a specific point
in time.
Figure 1 shows how LU changes through that adoption
and migration of library versions by clients in the ecosystem.
Suppose we represent Lv as a library and Cv as a clientsystem. In this example, we have a library L with two versions(L1 and L2 ) and two clients: A (A1 and A2 ) and B (B1 , B2
and B3 ). Library migration is shown at point x in time, where
the LU of L1 is two (system A and B); however at point y,since B3 adopted L2 , the LU of L1 is one (client A) while
the LU of L2 is now one (client B).
Library migration is sometimes caused when a better alternative to the current library emerges in the ecosystem. In
this context, we define these competing libraries as Library
Rival: is a competing library that causes library migrationfrom other libraries. The most common rival to any libraryversion is the newly released version, especially if it fixes bugs
or includes needed features that the previous library version
lacks. In Figure 1, we observe that evidence that L2 is indeed
the rival of L1 , thus causing future versions of client B to use
it instead of L1 .
III. L IBRARY AGING BASED ON LU
In this paper, we propose that LU can be interpreted theaging of a library over time. In Figure 2, we show that thisrelationship between LU and time can be plotted visually as
a curve. We see that for the shown GUAVA14.0.1 library, thisrelationship is represented with as a mathematical equationor curve. From Figure 2, a curve may exhibit the following
distinguishable feature characteristics:

Fig. 2. Modeling Library Aging as a mathematical curve equation.

Fig. 3. Shapes of the curves showing (i) a concave or (ii) a convex aging
curve

Current Age - is measured by the time from first usage
by a client till its most recent last seen LU by a system.
(i.e., library age = 912 days).
• Current LU - is the LU count at the oldest age. (i.e., current LU = 102 at day 912).
• Peak LU - is the point in which the maximum LU has
been reached. (i.e., peak usage =157 LU).
• Peak Age - is the number of days point in which thePeak LU has been reached. (i.e., peak age was reachedin 164 days).
As shown in Figure 3, the LU can either increase (i.e., rejuvenation) or decrease (i.e., decay) to form a upward or
downward curve, which is either concaving or convexing.
Hence, we define these curve shapes:• Library Decay - starts once the LU peak has beenreached. Visually, decay which is evident by the decreasing rate of LU over time with a concave aging curve.
(i.e., Figure 3 (i))• Library Rejuvenation - is the time period in which therate of LU is steady or increases over time with a convex
aging curve. (i.e., Figure 3 (ii))
Mathematical models are commonplace in many fields of
biology, medicine, economics and the social sciences [8]. They
describe and predict the estimation of a quantitative measureover time. In software engineering, different models havebeen applied primarily in the context of software reliability(e.g., [7], [16]). In this study, we use fundamental polynomial
equations are shown in Figure 4 and Table I for our curve
fitting. Thus, for the relationship between library usage LU

408

•

500

600

10
100

300

300

LU

500

time t (days)(a) First-order model

0

0

100

2

200

4

LU

6

400

8

10
8
6
LU
4
2
0
0

0

50 100

200

300

0

time t (days)

500

1000

1500

time t (days)(b) Second-order model(c) Higher-order modelFig. 4. Library Aging for three libraries representing the proposed three models. In each plot, a dot is one system that uses it; and the full line is the model thatfits the curve best. Note that Figure 4(a) represents the First-order model (FINDBUGS - ANNOTATIONS2.0.1 ), Figure 4(b) the Second-order model (CGLIB3.0 )and
Figure 4(c) illustrates the best-fits for Higher-order model (JUNIT4.10 ).

TABLE IS UMMARY S TATISTICS OF THE COLLECTED DATASET
ModelFirst-order model
Second-order model
Higher-order model

TABLE II
S UMMARY S TATISTICS OF THE COLLECTED DATASET

Equation
LU = at + b
LU = at2 + b
LU = aty + b + cand time t, key characteristics of each model are described
below:• First-order model. The first degree polynomial equation
is depicted in Figure 4(a) as having single linear line andmathematically where variables a and b are constants withno convex or concave curve. The linear relationship typically indicates that LU for a library is steady increasingover time, with no signs of slowing down.
• Second-order model. The second degree polynomial
equation is depicted in Figure 4(b) as having a bellshaped curve and mathematically where variables a andb are constants. This characteristic is typical of libraries
dropped immediately, due to an exposed vulnerability.
• Higher-order model . The third and higher degree
polynomial equation is depicted in Figure 4(c) as having
multiple inflections points in its curve and is expressedmathematically where variables a, b and c are constants
and y = [3, 4]. Higher-order model have multiple inflection points of decay or rejuvenation in the aging curve.
IV. E MPIRICAL E VALUATION
A. (RQ1) Do popular libraries share common aging characteristics of their usage? If so, what are some of these
distinctive characteristics?
1) Research Method: Our research method comprises ofthree steps. In the first step, we need to collect empirical datathat represents library usage for a particular software ecosystem. Table II shows a summary of collected Open Source

projects creation dates
projects last update# unique systems (projects)
total size of projects# commits related to pom.xml# library migrations# library versions curves

Dataset statistics
2004-Oct to 2009-Jan
2015-Jan onwards
48,495 (4,659)
630 GB
4,892,770
852,322
9,197

TABLE IIIB EST F ITTING R ESULTS FOR THE 1,503 POPULAR LIBRARY VERSIONS .
I NDECISIVE IS WHEN ALL THREE MODELS SCORE THE SAME AIC.
ModelFirst-order model
Second-order model
Higher-order model
Indecisive
No FitTotal# Fitted
40
143
1228
63
29
1,503

% of Studied Libraries
2.66%
9.51%
81.70%
4.19%
1.93%
100%

Source (OSS) client projects used libraries from the Maven
ecosystem. To ensure validity and quality of the collected
data, we (i) selected projects showed activity (commits tothe project) from January 2015 onwards and (ii) removed
projects that had less than 1,000 commits to its codebase.
Similar to our prior work [12], we used our PomWalker2 )tool and jgit3 to extract a history of library dependencychanges. As a result, we were left with 852,322 dependency
facts between the system and a maven library. Additionally,
we set a minimum threshold of 8 LU with a lifespan ofat least more than a day. For the second step, we then run
experiments by which the library aging data is fitted against
the proposed models. We employ the widely-used Akaike409

2 https://github.com/raux/PomWalker
3 https://eclipse.org/jgit/

TABLE IV
S UMMARY S TATISTICS OF L IBRARY AGING C HARACTERISTICS FOR THE 1,474 FITTED LIBRARY VERSIONS . HIGHLIGHTED VALUES SHOWS THAT THE
CHARACTERISTICS WERE DEEMED STATISTICALLY SIGNIFICANT (T UKEY HSD TEST ).

Current Age (# days)

Peak Age (# days)

Peak LU (LU)

Current LU (LU)

Fitting ModelFirst-order model
Second-order model
Higher-order modelFirst-order model
Second-order model
Higher-order modelFirst-order model
Second-order model
Higher-order modelFirst-order model
Second-order model
Higher-order model

Min.
1.00
1.00
1.00
8.00
15.00
8.00
8.00
8.00
8.00
1.00
1.00
1.00

1st Qu.
149.50239.00181.00487.50487.00544.00
8.00
10.00
10.00
8.00
8.00
8.00

x̄ = median
756.00520.00500.50980.00837.00967.50
10.00
12.00
14.00
9.50
10.00
12.00

µ = mean838.00712.90753.801003.00
1052.00
1112.00
10.78
14.85
27.69
9.68
13.13
25.01

3rd Qu.
1,361.00
983.001,138.00
1482.00
1482.00
1528.00
11.25
17.00
24.00
11.00
15.00
22.00

Max.
3,106.00
2,812.00
3745.00
3151.00
3053.00
3745.00
20.00
63.00
779.0020.00
63.00
746.00TABLE VT OP 10 H IGHER - ORDER MODEL LIBRARIES BY P EAK LU.
ID

Library

Version

L1
L2

junit
commons-collections

4.8.2
3.2.1

Peak LU
(LU)
373
268

Current LU
(LU)
340
266

Information Criterion (AIC) [6] to evaluate the goodness of
fit of each model. Specifically, the model with the lowest AICscore is deemed the best fit. This criterion provides us with ameasure of the relative quality of the models that accounts forthe trade-off between their goodness of fit and their complexity(see [14] for a thorough treatise of model fitting). For the
curve-fitting, we use the R4 statistical environment to produce
each library model. We rely on R’s (grofit)5 package, which
implements the AIC score, to fit against First-order model,
Second-order model and Higher-order model. Finally, in thethird step, we examine our proposed feature characteristics.
Specifically, we compare the Current Age, Peak Age, PeakLU and Current LU characteristics of the different models. To
this end, we use the Tukey HSD [14] test to find significancedifferences (p > 0.05) between the libraries that fitted eachmodel.
2) Findings: Table III lists the percentages of library aging
that are best-fit by each model. The most important findingis that 93.87% of the 1,503 eligible library versions are bestfitted by one of the models (i.e.,1.93% of libraries did not fit
any model, while 4.19% as indecisive). A practical example ofa no fit was libraries that had a constant LU, thus reflecting astraight line. The result shows that library aging is not random,
but can be modeled. Furthermore, looking at the Table III, we
observe that 81.7% of the library versions fitted the Higherorder model. Based on the nature of Higher-order model, we
can assume that most library versions show multiple inflection
points of either decay or rejuvenation during its lifespan.
Table IV shows the statistics of library characteristics that
4 http://cran.r-project.org/
5 https://cran.r-project.org/web/packages/grofit/grofit.pdf. grofit relies on
glm https://stat.ethz.ch/R-manual/R-devel/library/stats/html/glm.html to fit afunction

Peak Age(#days)959
2508

Current Age(#days)1809
2570# Rivals(succeeding releases)
8 (ver.4.9∼4.12)2 (ver.3.2.2 & ver.4.0)

are specific to the fitted library versions. As highlighted in
the Table, using the Tukey HSD test, we found significant
differences for Peak LU (p=0.008) and Current LU (p=0.005)
between the Second-order model and Higher-order model.
Hence, the results indicates that most rejuvenated and popularlibraries (i.e.,indicated by high Peak and Current LU) fit theHigher-order model. Importantly, it shows that many libraries
do not fit the Second-order model, not immediately dropped.
Hence, we answer RQ1:
We found 81.7% of the popular libraries (i.e., with highPeak LU and Peak Age) best fitted the Higher-order model.
B. (RQ2) What is the effect of ecosystem factors such as
library rivals to popular library aging characteristics?
Results from RQ1 indicate that library versions tend to fit
the Higher-order model, especially towards the more popularlibraries. Hence our motivation for RQ2, is to take a morequalitative approach to manually examine the visual aspectsof the library curve with the effect of ecosystem factors suchas rivals.
1) Research Method: In order to address RQ2, we randomly select two popular libraries that best fitted the Higherorder model in RQ1. Our research method has two steps tounderstand the usefulness of our curve characteristics. In thefirst step, we visually examine the library aging curves todraw some interesting observations. Such observations include
identifying the Peak LU and determining if the shape of thecurve. In the second step, we identify rival library versions.
2) Findings: Figure 5 and Table V shows the two selected
libraries and their rivals. In the analysis we make two main
observations. First, in Figure 5(a), we observe that L1 is still alibrary that has reached Peak LU. Visually, we identify that the

410

250
LU

100

150

200

300
200

LU

0

50

100
0
0

500

1000

1500

0

time t (days)(a) L1 (JUNIT4.8.2 )

500

1000

2000

time t (days)(b)

L2(COMMONS COLLECTIONS3.2.1 )Fig. 5. Library Aging for the selected three popular libraries. In each plot, a
dot is one system that uses it; and the full line (red) is the fitted Higher-ordermodel.

library has a concave aging curve. This characteristic suggeststhat since the library has reached Peak LU, it is now in library
decay. Manually inspecting the release dates of the rivals, wefind that the cause of the decay may be attributed to a rival
rival junit4.9 , which was released at the same time (i.e., 1000days (2.7 years)). However, although the library is decaying,
there is no significant reason for library migration. In fact,
since reaching its Peak LU, LU has only dropped to 53. We
conjecture that due to the nature of junit as a testing library,developers may not consider upgrading to rival libraries as apriority. However, we can recommend that new systems should
consider other rival libraries.
Second, Figure 5(b), we observe L2 as having a concave
aging curve. The curve suggests that L2 took a longer time toreach its Peak LU and the absence of rivals during this period.
Currently, its Peak Age is at 2,500 (i.e., 6 years). Coincidently,
at this same time, its rival of the next version (commons −collections4.0 ) was released, possibly explaining the Peak LU.
It is interesting to note that also the next rival (commons −collections3.2.2 ) was later released in 2015, to accommodate
existing users of the older version 3 systems users. This isbecause commons − collections4.0 is a major upgrade to the
new JDK from 4 to 5. In this case study, we also recommend
new users to consider other rival libraries as this library hasreached its peak, but due to the long convex age curve, we
can see that it was a very popular and reliable library, withusers hardly moving away from this library to other rivals in
the ecosystem. Hence, we answer RQ2:
Emergence or absence of rival libraries in the ecosystemhave an effect on library decay or rejuvenation, especiallycausing a library to reach its Peak LU.
V. C HALLENGES AND F UTURE W ORK
In this paper, we modeling library usage as aging curves,using them as a means to guide client developers on whether alibrary version should be either adopted or migrated away. In
this study, we found that that 81.7% of 1,503 popular libraries
fit a curve model. Furthermore, using two case studies, we

manually were able to explain the curve characteristics toecosystem factors such as library rivals.
Although results show promise, many challenges exist.
In the study, we only considered rivals as the superseding
library versions. There may be unrelated rival libraries in theecosystem that will age a library. As stated by Bavota et al. [9],other global factors such as security vulnerabilities or a change
in the environment platform may affect the aging of a library.
We consider this as future work. Currently, the curves are
only historic monitoring of client usage reporting the current
state. As the mathematical functions have predictive properties,
future work includes further investigation of prediction about
the potential lifespan a library. Also, the current experiment isonly performed within the Maven JVM ecosystem. It would beinteresting to extend the research to different ecosystems suchas the JavaScript npm, RubyGems and CRAN R ecosystems
to investigate this phenomena.
VI. ACKNOWLEDGMENTS
This work is supported by JSPS KANENHI (Grant Numbers
JP25220003 and JP26280021) and the “Osaka University
Program for Promoting International Joint Research.”
R EFERENCES[1] Comprehensive perl archive network,accessed 2016-07-20. http://www.
cpan.org/.
[2] Maven central statistics,accessed 2016-07-20. http://blog.sonatype.com/
2010/12/now-available-central-download-statistics-for-oss-projects/#.
Vmgw77 2O7g.
[3] The maven central,accessed 2016-07-20. http://search.maven.org/.
[4] Npm package manager for javascript,accessed 2016-07-20. https://www.
npmjs.com/.
[5] Rubygems community gems,accessed 2016-07-20.
https://www.
rubygems.org/.
[6] H. Akaike. Information theory and an extension of the maximum
likelihood principle. In 2nd Intrnl Symp. on Info. Theo., pages 267–
281, Budapest, 1973.
[7] V. Almering, M. van Genuchten, G. Cloudt, and P. Sonnemans. Using software reliability growth models in practice. Software, IEEE,
24(6):82–88, Nov 2007.
[8] G. Annadurai, S. Rajesh Babu, and V. R. Srinivasamoorthy. Development of mathematical models (logistic, gompertz and richards models)describing the growth pattern of pseudomonas putida (nicm 2174).
Bioprocess Engineering, 23(6):607–612, 2000.
[9] G. Bavota, G. Canfora, M. Di Penta, R. Oliveto, and S. Panichella. How
the apache community upgrades dependencies: An evolutionary study.
Emp. Softw. Eng., 20(5):1275–1317, Oct. 2015.
[10] S. G. Eick, T. L. Graves, A. F. Karr, J. S. Marron, and A. Mockus.
Does code decay? assessing the evidence from change management data.
IEEE Transactions on Software Engineering, 27(1):1–12, Jan 2001.
[11] W. Frakes and K. Kang. Software reuse research: status and future.
Softw. Eng., IEEE Trans. on, 31(7):529–536, July 2005.
[12] R. G. Kula, D. M. German, T. Ishio, and K. Inoue. Trusting a library:A study of the latency to adopt the latest maven release. In 22nd IEEE
Intrnl Conf. on Soft. Ana., Evol., and Reeng., SANER 2015, Montreal,
Canada, March 2-6, 2015, 2015.
[13] M. Lungu. Towards reverse engineering software ecosystems. In ICSM,
pages 428–431. IEEE Computer Society, 2008.
[14] H. Motulsky and A. Christopoulos. Fitting models to biological datausing linear and nonlinear regression: a practical guide to curve fitting.
Oxford University Press, 2004.
[15] D. L. Parnas. Software aging. In Software Engineering, 1994.
Proceedings. ICSE-16., 16th Intnl. Conf. on, pages 279–287, May 1994.
[16] S. Yamada, M. Ohba, and S. Osaki. S-shaped reliability growth modelingfor software error detection. Reliability, IEEE Trans., R-32(5):475–484,
Dec 1983.

411