Trusting a Library: A Study of the Latency to
Adopt the Latest Maven Release
Raula Gaikovina Kula∗ , Daniel M. German∗‡ Takashi Ishio∗ , Katsuro Inoue∗∗ Osaka University, Japan ‡ University of Victoria, Canada{raula, ishio, inoue}@ist.osaka-u.ac.jp
dmg@turingmachine.org

Abstract—With the popularity of open source library (re)use
in both industrial and open source settings, ‘trust’ plays vital rolein third-party library adoption. Trust involves the assumption ofboth functional and non-functional correctness. Even with theaid of dependency management build tools such as Maven and
Gradle, research have still found a latency to trust the latest
release of a library. In this paper, we investigate the trust of OSS
libraries. Our study of 6,374 systems in Maven Super Repository
suggests that 82% of systems are more trusting of adopting thelatest library release to existing systems. We uncover the impact
of maven on latent and trusted library adoptions.

I. I NTRODUCTION
As software systems grow, so does its size and complexity.
Known software engineering best practices suggest that we
re-compose code into easy–to–understand and maintainable
functional modules or libraries. With the emergence of large
collections of software repositories over the Internet, now systems integrate popular Open Source Software (OSS) libraries
like J UNIT1 and S PRING2 . The effect of heartbleed bug3
and more recently the shellshock vunerability4 demostrates
OSS library widespread effect on everyday systems. Online
collections of libraries together form super repositories like
GitHub5 and the Maven Central Repository6 .
Well-known benefits of adopting libraries includes efficientdevelopment with credible assurance of quality. ‘Trust’ of alibrary plays an important role. Trust involves the assumptionof a module’s functional and non-functional correctness. For
instance, system maintainers need to trust the reliability of
non-functional attributes such as security and stability of an
adopted library.
Libraries, much like any software, are never perfect. Overtime, release updates are sometimes necessary to address bugs
or perform other maintenance activities such as refactoring.
New features are added to expand functionality. Some updates
become mandatory and is crucial patch vulnerabilities. However, sometimes updates break systems, causing incompatibility issues with shared system-wide resources. According tomaven, ‘dependency management becomes crucial, especiallywith large-scale multi-modules software systems with tens
1 junit.org
2 spring.ioof hundreds of modules’.7 The tracking and maintenance oflibraries has come to be known as dependency management
issues (colloquially termed as ‘dependency hell’[1]). To handle
dependency management issues, many system maintainers
utilize build tools such as Maven8 and Gradle9 . These tools
promote updates and the trust of latest available library releases in the super repository.
However, studies by Raemaekers et. al.[2], [3] and ourprevious work [4], [5] all report evidence of latency when
updating to the latest release of a library. Incompatibilities,
such as API breakages and technical rework needed to facilitate the new library may cause such delays. Other speculations
involve the lack of awareness of a newer library release. Since
trust has a human aspect, other various reasons may exist.
In this study, we investigate the impact of dependency
management tools such as maven have on trusting a library.
We coin the term ‘trusted adoption’ to when the latest releaseof new library is adopted. Conversely, ‘latent adoption’ refers
to when a maintainer does not adopt the latest library release.
The motivation is to investigate the latency of trust phenomena. We carried out an empirical study to evaluate trusted
adoption of OSS libraries within the maven super repository.
The following research questions guided our study:1) How much ‘latent adoption’ exists? In RQ1, we empirically detect when a system does not adopt the latest
release of a new library.
2) What is the current trend of maintainers trust? In RQ2,
we investigate the trend over recent times to understandthe current state of trust of OSS libraries.
We present a set of algorithms to classify initial andintroduced library dependency types. Our results suggest thatwith the current tools and technology, latent adoption isstill common. Maintainers, however, are more trusting whenintroducing new libraries into existing systems.
II. BACKGROUND AND M OTIVATION
A. Trust of a Library
We consider trust to play an important role when choosing
and maintaining a third-party library. Trust intrinsically is ahuman trait, thus making it very difficult to ‘pin down’ to a

3 http://heartbleed.com/
4 https://shellshocker.net/

7 http://goo.gl/TO2P1u

5 https://github.com/

8 http://maven.apache.org/index.html

6 http://search.maven.org/

9 http://www.gradle.org/

978-1-4799-8468-8/15/$31.00 c 2015 IEEE520

SANER 2015, Montréal, Canada

entrusted dependency

𝐴1

𝐴2

Point in Time(S3 release date)

Initial dependency

𝑆1

𝑆3

𝑆2

𝑆4

Initial systemrelease

𝐵1

𝐵3

𝐵2

𝐵4
Latest release

time
Fig. 1: Example of systems and library dependencies over time. The Figure depicts the evolution of system S with libraries A and B.

generalized reason. Trust is at varying degrees and for manyreasons. In this paper we consider four broad types of trustthat would cause a latent adoption.
The first type of trust is of a library’s both functionaland non-functional related specifications. Examples of nonfunctional correctness are missing or inconsistency of functions corresponding to the API documentation. Similarly,
trusting the correct use of Semantic Versioning (SemVer MAJOR.MINOR.PATCH)10 matching the changes in the release (i.e, major changes are only introduced in major version
releases). A study by Raemaekers [6] uncovered that many
libraries do not follow the SemVer schema, causing many
breaking changes which could lead to latent adoptions.
The second type of trust is that the introduced library is
not volatile towards the current system environment. This
involves compatibility with other libraries or the shared-system
resources. Take for example the java ASM11 library. ASM isa tiny and flexible java byte-code manipulation library usedin many popular frameworks like H IBERNATE12 , S PRING,G LASSFISH13 and D ERBY S ERVER14 . It is known for its fast
execution speed due to its small size. The cost of keeping
such a small size was that incompatibilities would occur
whenever a new JDK compiler was released. The main issue
occurred when systems adopted libraries that internally had
different versions of ASM as they would break. For instance,systems that had adopted the D ERBY server and S PRING
framework encountered incompatibility issues when Spring
updated from ASM3.x to ASM4.x . Eventually latter releasesof ASM allowed for backward compatibility. This example
illustrates the importance of the ASM library development teaminfluence on trust adoptions15 .
We refer to the third type of trust as loyalty for a certain
version of a library based on experienced usage. For instance,

in an informal interview, a developer replied that: ‘although it
is an way older version, I use Junit3.8 as I am familiar with it.
It is not a critical compile component of my system and suits
my needs.’ This trust of a particular release promotes latent
adoption.
Finally, a system maintainer may not trust the test maturityof latest version release. In informal interviews, we found thatmany maintainers are hesitant of the rigor of internal testing.
They believe that undetected bugs that can only be uncover
during in practical use may exist. In this case, maintainers
search for most stable version (in many cases deemed as the
popular) release.
III. S OFTWARE S YSTEMS AND L IBRARIES
We investigate the evolving relationship between systems
and their dependent libraries. In this research we are only
concerned with the adoption of new libraries. Updates toexisting library dependencies are ignored. We used the modelin Figure 1 to describe the necessary terminology.
A. Terminology and Definitions
System and Library Releases. We conjecture that systems form a dependency relationship with a set of libraries. A release refers to an instance of a system orlibrary. Let Sver be the notation for a unique releaseof a software system and Lver as libraries. In Figure 1,
S1 , S2 , S3 , S4 are different system releases of system S.
A1 , A2 , are releases of library A and B1 , B2 , B3 , B4 aslibrary B releases. As depicted in Figure 1, all related
releases are connected.
• Releases Ordering. Since releases have a temporal property, we can order releases by their release date. Thus,pre(Sver ) refers to a previous release while suc(Sver )refers to successive releases of a system. Likewise forpre(Lver ) and suc(Lver ).
We use the notation > and < to represent the temporalordering between all system and library releases. For
instance, in Figure 1, B4 > S3 > B3 describes theordering between B4 , S3 and B3 . We use the ordering•

10 http://semver.org/
11 http://asm.ow2.org/index.html
12 http://hibernate.org/
13 https://glassfish.java.net/
14 http://db.apache.org/derby/
15 This is the report of the asm compatibility issues http://goo.gl/x9EeKx
known as the asm NoSuchMethodError incompatibility issue521

to identify particular releases. The initial release is used
to describe an instance where no predecessor exists.
(ı.e @pre(Sver ) or @pre(Lver )). For example, in Figure
1, releases A1 , S1 and B1 are initial releases. The
latest release is such that no successive release exists(ı.e @suc(Sver ) or @suc(Lver )). In Figure 1, the latest
releases are A2 , S4 and B4 respectively.
• Dependency Relations. This refers to the dependency
relationship that forms when a library is being adopted
by a system. Suppose a system Sx and library Ly ,depends(Sver , Lver ) describes to the adoption of library Ly into a system Sx . In Figure 1, for system
S, depends(S1 , A1 ), depends(S2 , A2 ) depends(S3 , A2 )and depends(S3 , B2 ) depicts how libraries A and B are
adopted. As shown in Figure 1, dependency relations are
the edges that exist between a system and library (i.e,edge between A1 and S1 ).
• Initial Dependency. An initial dependency is all dependencies that exist at the initial system release.
(ı.e depends(Sver , Lver ) where @pre(Sver ) conditions
must be met). As depicted in Figure 1, depends(S1 , A1 )is an initial dependency for system S.
• Introduced Dependency. An introduced dependency
refers to new dependencies introduce to an already existing system. (ı.e depends(Sver , Lver ) where ∃pre(Sver )and @depends(pre(Sver ), Lver ) conditions must be met).
In Figure 1, depends(S3 , B2 ) is an example of an introduced dependency.
• Trusted Dependency. Trusted dependency is the adoption of the closest library release at a particular point
in time. (ı.e depends(Sver , Lver )). One of the two
conditions must be met 1.) Lver is the latest version suchthat @suc(Lver ) and 2.) If condition 1 is not true, (i.e,∃suc(Lver) ), then suc(Lver ) must be released after thesystem release Sver (i.e, suc(Lver ) > Sver ).
In Figure 1, taking S3 as a reference point, the dependency
depends(S3 , B2 ) is not an trusted dependency adoption. Thisis because B2 is not the latest release. and the successor B3
was released before S3 (B3 < S3 ). The entrusted dependency would be depends(S3 , B3 ) as the successive release
B4 was released after S3 (i.e, B4 > S3 ). Also, in Figure 1,
depends(S3 , A2 ) is an trusted dependency as A2 is the latest
release of library A (condition 1 is satisfied).

Introduced

InitialStep2. Determine
Dependency Relation

LatentTrustedLatentTrusted(iniTA)(iniLA)(introTA) (introLA)

Step3. Determine
Trusted Dependency

Fig. 2: The Figure depicts the algorithms used to classify our
proposed types of dependency adoptions.

a trusted dependency.
As shown in Figure 2 using the algorithm we classify
into the interested dependencies. Formally each dependency
is defined as follows:a) Initial Trusted Adoption (iniTA): Trusted adoption oflatest library release at initial conception of a system.
S
iniT A(S) = { ∃x.depends(Si , Lx )|@pre(Sx )i∈n∧ (@suc(Lx ) ∨ if (∃suc(Lx ))then(suc(Lx ) > Si ))} (1)b) Initial Latent Adoption (iniLA): Latent adoption at
initial conception of a system.
SiniLA(S) = { ∃x.depends(Si , Lx )|i∈n@pre(Sx ) ∧ (∃suc(Lx ) ∧ (suc(Lx ) > Si ))} (2)c) Introduced Trusted Adoption (introTA): Trusted adoption of latest library release introduced to an existing system.
S
introT A(S) = { ∃x.depends(Si , Lx )|@pre(Lx )i∈n∧ (@suc(Lx ) ∨ if (∃suc(Lx ))then(suc(Lx ) > Si ))} (3)d) Introduced Latent Adoption (introLA): Latent adoption of library introduced to an existing system.
S
introLA(S) = { ∃x.depends(Si , Lx )|@pre(Lx )i∈n∧ (∃suc(Lx ) ∧ (suc(Lx ) > Si ))}B. Dependency Algorithms
To determine a trusted dependency, we follow three steps as
depicted in Figure 2. Suppose for a system S and n represents
all of the system releases of S, we perform the following steps:
1) Extract related dependency relations. For all releases
of S (i.e, S1 , ..., Sn ), we extract all related dependency
relations.
2) Determine dependency relation. In this step we distinguish if the dependency is either an initial or introduced
dependency.
3) Determine trusted dependency. To determine a trusted
introduced dependency, we check the conditions to satisfy

Maven Dependencies

Step1. Extract related
dependency relations(4)

IV. E MPIRICAL S TUDY
We implemented our trust dependency algorithms to study
the ‘latent adoption’ phenomena between maven 2 repository
libraries. The Maven Super Repository is the home to alarge collection of software libraries that originate from theJava Virtual Machine (JVM) based languages such as Java,
Scala and Clojure. Systems in the maven repository includes
a Project Object Model file POM.xml that describes the
project’s configuration meta-data —including its compile-timeand run-time dependencies. We developed a tool to extract thisdependency information from all versions of the POM-files in522

TABLE I: Maven Super Repository
Time Period# Dependency Relations# Implicit Relations# of Systems# of Libraries

TABLE V: Top 5 Introduced Trusted Libraries

Maven Dataset
2005-11-03 to 2013-11-24
188,951
11, 195
6,374
5,146

Libraryjunit
hibernate-corespring-integration-corescala-libraryhibernate-testing# Dependencies
243
238
235
227
217

TABLE II: Dependency Classification Results# Libraries
4,192
848
3,064
823

# Dependencies (%)
20,372 (59.63%)
13,791 (40.37%)
29,303 (81.16%)
6,543 (18.24%)

the repository (PomWalker16 ). Our implementation relies on
version 3.1.1 of maven’s own maven-model project
to parse each POM file and extract syntactic references to its
dependencies.
POM files can either reference be explicit to a specificrelease version or be implicit. For instance, the syntax(<version>$library.version</version>) is used
to import managed dependencies. For simplicity, we onlyused explicit release versions in our study. We implemented
R scripts of the dependency algorithms. Using the extracted
dependency information, we were then able to determine
trusted dependencies. All scripts and tools are available asa replication package17 .
V. R ESULTS
Table I is a summary of the data collected by PomWalker.
We extracted 188,951 dependency relations from the maven
super repository. This consists of 6,374 systems using 5,146
libraries over 7 years. Table II refers to the extracted introduced and initial entrusted dependencies. In the case of initialdependencies, 59.63% of the detected dependencies trusted thelatest release, while 40.37% did not adopt the latest release
version. The results show a relatively smaller set of latent

TABLE VI: Top 5 Introduced Latent Libraries
Library
junit
glassfish-corba-orbgenericglassfish-corba-omgapi
httpclient
commons-logging

Initial Library Adoption Over Time

15000
trusted adoption
10000

2006

Library
scala-library
junit
log4j
slf4j-api
commons-logging# Dependencies
710
595
191
178
169

TABLE IV: Top 5 Initial Latent Libraries
Library
scala-libraryjunit
servlet-api
commons-logging
log4j# Dependencies
1,468
1,411
496
481
394

2008

2010

Time

2012

2014

Fig. 3: A comparision of trust of initial dependencies over time in
the Maven Super Repository.

Introduced Library Adoption Over Time
Cumulative sum of introduced libraries

TABLE III: Top 5 Initial Trusted Libraries

latent adoption

5000

16 https://github.com/raux/PomWalker
17 http://sel.ist.osaka-u.ac.jp/∼raula-k/LatentAdoption/# Dependencies
392
126
122
120
119

20000

Cumulative sum of initial libraries

iniTA
iniLA
introTA
introLA

30000

20000
trusted adoption
latent adoption
10000

0
2006

2008

2010

Time

2012

2014

Fig. 4: A comparision of trust of introduced dependencies over timein the Maven Super Repository.

523

adopted libraries (848) compared to their trusted counterparts(4,192). In the case of introduced libraries, 81.16% of the
adopted libraries were latest releases. The results reveals a
relatively smaller set of latent adopted libraries (823) thatmaintainers introduced into their systems.
The Top 5 libraries adopted at the conception of a system areshown in Table III (intital trust adoption) and Table IV (initiallatent adoption). For introduced libraries, Table V (introduced
trusted adoption) and Table VI (introduced latent adoption).
Notice that popular libraries like SCALA - LIBRARY and J UNIT
are apparent in all the dependency types. Both Figure 3 andFigure 4 depicts a cumulative number of initial and introduced
library adoptions in the maven super repository from 2006 to2014. Figure 3 shows a more steady trend between trusted andlatent adoptions. On the other hand, in Figure 4 it is observedthat when introducing new libraries, systems are more trustingof the latest releases.

[13] and Cossette et al. [14] have explored library migrations,particularly on candidate library replacements. Both studies
provide additional insights behind latent library adoptions.
VIII. C ONCLUSION AND F UTURE W ORK
In this paper we explore the notion of trust when re(using)
OSS libraries. Our results suggest that maintainers are becoming more trusting. Existing systems more inclined to adopt
the latest releases to existing systems. The reasons for latent
adoption are difficult to generalize. Related work reports lapses
in updates and SemVer guidelines not being strictly enforced.
Therefore, we believe that further investigation behind thereasons trust issues should be performed, such as maintainers satisfaction surveys on our current tools. We envisionthat future dependency management tools like maven should
ensure OSS libraries are trustworthy, possibly resolving ourdependency updating issues.

VI. I MPLICATIONS OF R ESULTS

ACKNOWLEDGMENT

Issues of updating libraries stems from the trust of releases.
We did not study if these libraries eventually update theselibraries, but a latent adoption may set a precedence of
not updating libraries. The study shows a smaller subset oflibraries may be responsible for latency in adoptions. Future
work is towards identification and exploration of approaches
to reduce latent adoptions. The study finds that trust adoptions
are more apparent with introduced libraries. We speculate that
introducing new libraries could indicate of adding new features
to a system.
We are only beginning to understand the trust involved with
OSS libraries. More study into trust of libraries will lead
to better strategies to support component-based software. For
example, how to ‘certify’ trust of a newly released release.
Now we answer our research questions:
RQ1. How much ‘latent adoption’ exists?: The results
show that the latent adoption exists, particularly at the initialconception of a system. Maintainers are less likely to adopt
the latest releases at the beginning of project.
RQ2. What is the current trend of maintainers trust?:
Figure 3 and Figure 4 suggests that maven libraries are
becoming more inclined to adopt the latest releases whenintroducing new libraries (updating there existing systems).

This work is supported by projects ‘Collecting, Analyzing, and Evaluating Software Assets for Effective Reuse’,Japan Society for the Promotion of Science, Grant-in-Aid
for Scientific Research (No.25220003) and ‘Software License
Evolution Analysis’, Osaka University Program for Promoting
International Joint Research.

VII. R ELATED W ORK
The trust of components is well-known in fields of Dependable and Secure Computing [7], [8], [9]. In this paper, we
explore how trust of components can be realized with OSS
libraries. Related work in Software Engineering are concernedwith library API usage and popularity. Holmes et al. appeal
to popularity as the main indicator to identify libraries ofinterest [10]. De Roover et al. explored library popularity
in terms of source-level usage patterns [11]. Mileva et al.
study popularity over time to identify the most commonlyused library versions [12]. These studies to an extent, areevidence to update to the most popular as opposed to thelatest release of a library. More recently, work by Teyton et al.

R EFERENCES[1] M. Jang, “Linux annoyances for geeks,” 2009.
[2] S. Raemaekers, A. van Deursen, and J. Visser, “Measuring software
library stability through historical version analysis,” in Proc. of Intl.
Comf. Soft. Main. (ICSM), Sept 2012, pp. 378–387.
[3] S. Raemaekers, G. Nane, A. van Deursen, and J. Visser, “Testing
principles, current practices, and effects of change localization,” in
Mining Soft. Repo. (MSR), May 2013, pp. 257–266.
[4] R. G. Kula, C. D. Roover, D. M. German, T. Ishio, and K. Inoue,“Visualizing the evolution of systems and their library dependencies,”
Proc. of IEEE Work. Conf. on Soft. Viz. (VISSOFT), 2014.
[5] N. Kawamitsu, T. Ishio, T. Kanda, R. G. Kula, C. D. Roover, andK. Inoue, “Identifying source code reuse across repositories using lcsbased source code similarity,” in Proc. of SCAM, 2014.
[6] S. Raemaekers, A. van Deursen, and J. Visser, “Semantic versioning
versus breaking changes: A study of the maven repository,” in Proc. of
SCAM, Sept 2014, pp. 215–224.
[7] Z. Yan and C. Prehofer, “Autonomic trust management for a componentbased software system,” IEEE Transactions on Dependable and Secure
Computing, vol. 8, no. 6, pp. 810–823, 2011.
[8] W. Hasselbring and R. Reussner, “Toward trustworthy software systems,” Computer, vol. 39, no. 4, pp. 91–92, April 2006.
[9] R. V. Guha, R. Kumar, P. Raghavan, and A. Tomkins, “Propagation oftrust and distrust,” in WWW’04, pp. 403–412.
[10] R. Holmes and R. J. Walker, “Informing Eclipse API production andconsumption,” in OOPSLA2007, 2007, pp. 70–74.
[11] C. De Roover, R. Lämmel, and E. Pek, “Multi-dimensional explorationof api usage,” in Proc. of Int. Conf. on Prog. Comp.(ICPC), 2013.
[12] Y. M. Mileva, V. Dallmeier, M. Burger, and A. Zeller, “Mining trendsof library usage,” in ERCIM Workshops, 2009, pp. 57–62.
[13] C. Teyton, J.-R. Falleri, M. Palyart, and X. Blanc, “A study of librarymigrations in java,” Journal of Software: Evolution and Process, vol. 26,
no. 11, 2014.
[14] B. E. Cossette and R. J. Walker, “Seeking the ground truth: a retroactive
study on the evolution and migration of software libraries,” in Proceedings of ACM SIGSOFT Int. Symp. on the Found. of Soft. Eng. (FSE),
2012.

524