1.
How Libraries Evolve: A Survey of Two Industrial
Companies and an Open-Source Community
1CIRAD, UMR - SENS, Montpellier, France
2Arolla, Paris, France
3Univ. Lille, Inria, CNRS, Centrale Lille, UMR 9189 - CRIStAL
Oleksandr ZAITSEV1, Stéphane DUCASSE 3, Nicolas ANQUETIL 3, Arnaud THIEFAINE 2
29th Asia-Pacific Software Engineering Conference (APSEC 2022)
oleksandr.zaitsev@cirad.fr

2.
2
Arolla is a consulting company specialised in
the advanced techniques of software development:
Clean Code, TDD, BDD, Legacy Remediation, etc.
https://www.arolla.fr/

3.
Introduction
Part 1:

4.
4
Library Evolution & Update
Client
System
Library
v1.0
Client
Developer
Library
Developer
depends
Part 1 / 5

5.
5
Client
System
Library
v1.0
Library
v2.0
Client
Developer
Library
Developer
depends
Library Evolution
Library Evolution & Update
Part 1 / 5

6.
6
Client
System
Library
v1.0
Library
v2.0
Client
Developer
Library
Developer
depends
Library Evolution
! Errors!
Library Evolution & Update
Part 1 / 5

7.
7
Updated
Client
System
Client
System
Library
v1.0
Library
v2.0
Client
Developer
Library
Developer
depends
Library Evolution
Library Update
Library Evolution & Update
Part 1 / 5

8.
8
Updated
Client
System
Client
System
Library
v1.0
Library
v2.0
Client
Developer
Library
Developer
depends
Understanding the Developers
Part 1 / 5
Tools to support
client developers
Tools to support
library developers

9.
9
Updated
Client
System
Client
System
Library
v1.0
Library
v2.0
Client
Developer
Library
Developer
depends
‣ How do they behave
in the context of
library update?
‣ What problems do
they face?
‣ What support do
they need?
Understanding the Developers
Part 1 / 5

10.
State of the Art
Part 2:

11.
11
Technique Perspective
Client developer
Library developer
Both
Developer survey
Code analysis
SOTA: Criteria
Part 2 / 5

12.
12
Paper Survey Code Analysis Client Dev. Library Dev.
[Robbes 2012a] X ✓ ✓ X
[Jezek 2015] X ✓ ✓ ✓
[Hora 2015] X ✓ ✓ X
[Bogart 2016] ✓ X ✓ ✓
[Sawant 2016] X ✓ ✓ X
[Xavier 2017a] X ✓ ✓ ✓
[Xavier 2017b] ✓ X X ✓
[Hora 2018] X ✓ ✓ X
[Kula 2018a] ✓ ✓ ✓ X
[Kula 2018b] X ✓ X ✓
[Brito 2019] ✓ X ✓ ✓
SOTA: Empirical Studies
Part 2 / 5

13.
13
1. Most surveys analyse specific cases of breaking changes.
2. No survey has asked client developers about what makes
library update hard and what makes it easy.
SOTA: Shortcomings
Part 2 / 5

14.
Survey Setup
& Population
Part 3:

15.
15
Research Questions
Part 3 / 5
How do they perceive the impact
of library evolution on their clients?
Why do they introduce breaking
changes?
How motivated are they to support
their clients?
How do they help their clients to
update?
How do they perceive the impact of
library evolution on their systems?
What makes library update easy and
what makes it hard?
RQ1.
RQ2.
RQ3.
RQ4.
RQ5.
RQ6.
Library Developers Client Developers

16.
16
Pharo (open-source)
Pure object-oriented programming language designed in tradition of
Smalltalk. It is also an IDE developed entirely in itself.
Why? We are members of this community and have access to developers
Communities
Part 3 / 5
Arolla (industry)
Medium-size software consulting company - each dev. has their own project
Berger-Levrault (industry)
Medium-size software company - dev. work in teams
Why? We collaborate with both companies and they agreed to participate

17.
17
Open-Source
(33)
Industry
(14)
Unspecified
(8)
Library developers
(18)
11 5 2
Client Developers
(37)
22 9 6
participation was optional;
surveys were shared
through community chats
and forums
Developer Population
Part 3 / 5
?

18.
18
Q: What software they develop?
Library Developers
Part 3 / 5
Q: What is their level of expertise?
Expert
Advanced
Intermediate
Beginner
Absolute novice
5
9
3
0
0
Library
Framework
SDK
Microservices
Other
15
10
4
4
3

19.
19
Libraries and frameworks
Web (back end)
Web (front end)
Desktop applications
IDE
Compilers / VM
Mobile applications
Embedded systems
Security
Other
Q: What software they develop?
Client Developers
22
Part 3 / 5
21
16
12
9
6
4
2
2
5
Q: What is their level of expertise?
Expert
Advanced
Intermediate
Beginner
Absolute novice
8
18
6
2
0

20.
Survey Results
Part 4:

21.
21
Q: Do you think that breaking changes in
your releases have big impact on clients?
RQ1. Perception of impact
Very small impact
Small impact
Moderate impact
Big impact
Very big impact
1
0
9
6
2
Part 4 / 5
Library
Dev.
Less than an hour
Half a day
One day
Several days
A week or more
3
7
4
3
1
Q: How much time do you think client
developers need to update to the new
version of your library?

22.
22
RQ2. Why introduce BC?
Part 4 / 5
Library
Dev.
Q: What are your primary reasons for introducing
breaking changes?
Implementing a new feature
API simpli
fi
cation
Improving maintainability
Bug
fi
xing
Other
12
11
6
11
2
This confirms the results of
[Brito et al., 2019]

23.
23
Q: How important is it for you to maintain
backward compatibility?
RQ3. Motivation to support clients
Not important at all
Of little importance
Of average importance
Very important
Absolutely essential 1
8
5
4
0
Part 4 / 5
Library
Dev.
Not important at all
Of little importance
Of average importance
Very important
Absolutely essential
0
8
4
5
1
Q: How important is it for you to
encourage clients to update to the latest
version?

24.
24
RQ4. How do they support clients?
Part 4 / 5
Library
Dev.
Q: When you are forced to break backward
compatibility, what do you do to reduce the
negative impact on users?
(open question)
Practice mentioned dev.
Documentation 8
Deprecation 4
Automation 4
Communication 3

25.
3x a year or more often
Twice a year
Once a year
Less often
We do not do it regularly
25
Q: How much time does it usually take you
to update your dependencies?
RQ5. Perception of impact
Less than an hour
Half a day
One day
Several days
One week or more
17
10
3
3
1
Part 4 / 5
Client
Dev.
9
11
6
9
3
Q: Try to estimate how often do you have
to deal with the task of updating
dependencies?

26.
26
RQ6. What makes it easy/hard?
Part 4 / 5
Client
Dev.
Q: What makes library update easy? Q: What makes it hard?
Factor dev.
Documentation 15
Absence of breaking changes 11
Test coverage 6
Tool support 5
Deprecations 4
Simple breaking changes 4
Community support 3
Factor dev.
Breaking changes 11
Absent or bad documentation 10
Indirect dependencies 7
Big changes to the API 7
Poor test coverage 4
Removed functionality 3
Changed hooks or abs. classes 3

27.
27
Library
Developers
Client
Developers
‣ Often have to deal with the
problem of library update
‣ Need documentation and support
for breaking changes
‣ Want to help their clients
to update
Key Takeaways
Part 4 / 5

28.
Conclusion
Part 5:

29.
Contributions
29
Part 5 / 5
✓ Surveys of library and client developers from different communities.
✓ We are the first to ask client developers what is the support that they need
✓ We confirmed the results of previous studies on the motivation of library
dev. to introduce breaking changes and understanding of their impact.

30.
Threats to Validity
30
Internal External Construct
‣ General questions
‣ Only Pharo has
transforming
deprecations
‣ Some developers
answered both
surveys
Part 5 / 5
Conclusion
‣ Some participants
know us and our
research
‣ Relatively small size
of libraries
(no more than
500 clients)
‣ Some RQ can not
be expressed as
survey questions
‣ Most questions
have the list of
options
‣ Client perception
depends on how
the library is used
‣ Relatively small
population size
‣ No statistical tests.
Only descriptive
statistics

31.
✓ Surveys of library and client developers
from different communities.
✓ We are the first to ask client developers
what is the support that they need
✓ We confirmed the results of previous
studies on the motivation of library dev.
to introduce breaking changes and
understanding of their impact.
Summary
Contributions:
Updated
Client
System
Client
System
Library
v1.0
Library
v2.0
Client
Developer
Library
Developer
depends
Key takeaways:
• Often have to deal with the
problem of library update
• Need documentation and
support for breaking changes
• Want to help
their clients
to update
Client
Developers
Library
Developers

32.
Threats to Internal Validity
33
Support
• We asked about general experience, not specific projects.
(hard to analyse the context that originate certain situations / decisions)
• Some questions were hard to answer generally
(e.g., how much time it takes for clients to update)
• The transforming deprecations mechanism may have affected how Pharo
developers answered this survey.
• Some developers could have answered both surveys.

33.
Threats to External Validity
34
Support
• Some participants could know us personally and be aware of our research
(for convenience, we enlisted developers from the open-source community
that we are part of and companies that we collaborate with)
• Relatively small size of libraries: no more than 500 clients
(this is also a novelty because most related works focus only large libraries
which might introduce a bias)

34.
Threats to Construct Validity
35
Support
• Some research questions could not be fully expressed with survey questions
(e.g., to measure the impact of library evolution, we ask how clients perceive
this impact and how much time it takes to update)
• Most questions were not open but based on the list of options.
• The perception of the impact of breaking changes may tell us about the way
client uses the library rather than the actual impact

35.
Threats to Conclusion Validity
36
Support
• Population size is relatively small — 18 library and 37 client developers
(comparable to other surveys in this field: 28 dev., 7 dev., 16 dev., 102 dev.)
• Did not perform statistical tests and drew conclusions from descriptive stats.
(because of the small population size)