Educating to Achieve Healthy Open Source Ecosystems
Simone da Silva Amorim
Federal Institute of Education,
Science and Technology of Bahia
Salvador, Brazil 40110
simone.amorim@ifba.edu.br
Eduardo Santana de Almeida
Federal University of Bahia
Salvador, Brazil 40170
esa@dcc.ufba.br
ABSTRACT
When developers contribute to an open source software ecosystem
project, they follow practices de�ned by governing authorities, ar-
chitects, maintainers, committers, and other stakeholders. Many
of these practices are incorporated into training videos and guide-
lines for newcomers to guide the work of contributors, including
architectural practices that in�uence the quality of the software
product and the health of the open source ecosystem. This research
is investigating architectural practices intended to orient and train
newcomers during their �rst contacts with the ecosystem. This
includes using the software architecture to trace a picture of how
has been built the education to achieve a healthy ecosystem. This
research identi�es architectural practices spread by some training
resources and analyzes how these practices contribute to achieving
a healthy ecosystem. Our method consisted of a qualitative study
conducted with data obtained from various training sources. This
research provides empirical support for investigating the existing
education on architectural practices to create healthy open source
ecosystems.
CCS CONCEPTS
• Software and its engineering → Software design engineer-
ing; Software development methods; Open source model;
KEYWORDS
Software Architecture, Software Practices, Software Ecosystems,
Open Source Systems
ACM Reference format:
Simone da Silva Amorim, John D. McGregor, Eduardo Santana de Almeida,
and Christina von Flach G. Chavez. 2018. Educating to Achieve Healthy
Open Source Ecosystems. In Proceedings of 12th Workshop on Distributed
Software Development, Software Ecosystems and Systems-of-Systems, Madrid,
Spain, September 2018 (ECSAW’18), 6 pages.
DOI: 10.1145/nnnnnnn.nnnnnnn
Permission to make digital or hard copies of part or all of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for pro�t or commercial advantage and that copies bear this notice and the full citation
on the �rst page. Copyrights for third-party components of this work must be honored.
For all other uses, contact the owner/author(s).
ECSAW’18, Madrid, Spain
© 2018 Copyright held by the owner/author(s). 978-x-xxxx-xxxx-x/YY/MM. . . $15.00
DOI: 10.1145/nnnnnnn.nnnnnnn
John D. McGregor
Clemson University
Clemson, USA 29634
johnmc@clemson.edu
Christina von Flach G. Chavez
Federal University of Bahia
Salvador, Brazil 40170
�ach@dcc.ufba.br
1 INTRODUCTION
Open source ecosystems are changing the scenario of technology
development. There are powerful modern tools available to assist de-
velopers in starting to contribute to open source projects instead of
starting with no resources. The ways to collaborate with a commu-
nity, to develop code, and apply the organizational principles have
matured. They accelerate innovation and collaboration like never
seen before[2]. This scenario of growth re�ects the healthy state of
some open source ecosystems such as Android, KDE, Hadoop, and
others.
Iansiti and Levien stated that a healthy ecosystem provides
“durably growing opportunities for its members and for those who de-
pend on it”[8]. A healthy ecosystem keeps working and growing e�-
ciently, as well as surviving crisis and generating innovation. These
attributes are represented by three health indicators: robustness,
productivity, and niche creation. There are some proposals under
development to evaluate the health of an ecosystem[4, 6, 10]. Our
assumption considers that health states are also created through
practices adopted in the community. Speci�cally, the software ar-
chitecture practices used impact directly on the products and their
performance. Practices can be validated consistently by address-
ing speci�c parts of a problem[9]. The use of adequate practices
contributes to achieving and keeping the ecosystem healthy.
In addition, practices adopted in an open source ecosystem are
performed by all members of the community. Experienced mem-
bers already have the knowledge to create and maintain adequate
practices. However, newcomers are inexperienced and should be
trained to know and use the adopted practices. Based on the train-
ing received, they will develop their own way-of-working following
the rules of the community. Adequate training will contribute to
e�ciently using architectural practices that impact the ecosystem
health. For this reason, we realized the need to investigate architec-
tural practices that are being taught in newcomers’ training. We
analyzed the in�uence of these practices on the health indicators.
This way, we can establish a scenario describing the education pro-
vided for newcomers to achieve healthy open source ecosystems.
The remainder of the paper is organized as follows: Section 2
introduces work related to our research. Section 3 presents a descrip-
tion of the architectural healthy of software ecosystems. Section 4
discusses the methodology used to gather the practices. Section 5
presents the architectural practices collected on this study. Section 6
discuss in�uence of practices on ecosystem health. The threats to
ECSAW’18, September 2018, Madrid, Spain
validity are presented in Section 7. Finally, Section 8 o�ers some
concluding remarks.
2 RELATED WORK
Several studies have been conducted considering the barriers for
newcomers in open source ecosystems [14, 16, 19]. Some of them
suggest practices and training to educate these new developers
[17, 20]; however, we did not �nd studies explicitly considering
the impact of these practices on the health of software ecosystems.
Below, we brie�y review some studies that discuss the training of
newcomers and activities to achieve the health of ecosystems.
First, considering the training of newcomers, Steinmacher et al.
introduced guidelines for the two faces of the system: OSS com-
munities that desire to attract new developers and newcomers that
desire to get involved in OSS communities [20]. The goal of these
guidelines is to help newcomers face the existing barriers to engag-
ing in OSS projects, as well as to enhance the growth and diversity
of OSS communities. Their results emphasize the need for OSS
communities to pay attention to socialization factors that retain
newcomers.
In another work, Sarma et al. investigated the learning of new-
comers in the BugExchange ecosystem. This ecosystem organizes
tasks from OSS projects and helps train newcomers. The idea is
to help newcomers to know how to begin making contributions
and/or how to choose appropriate tasks to develop. Through ade-
quate training, newcomers gain an understanding about the project
and can contribute to keeping the work organized. The information
available about the ecosystem will provide the correct support for
deciding how to work e�ciently.
Finally, regarding the health of ecosystems, Wnuk et al. presented
an exploratory case study about governance activities and how they
prevent or improve the health of ecosystems [21]. They evaluated
the governance model applied by the Application Development
Partner (ADP) software ecosystem considering the degree to which
the ecosystem performed governance activities: performing no
activities, performing a partial set of activities, and performing
a full set of activities. Their outcomes showed the percentage of
activities executed, and these activities do not follow completely a
governance model proposed by Jansen and Cusumano[11, 12].
These studies described training issues for newcomers in OSS
projects, and a model of evaluation of the health a�ecting gover-
nance activities. The studies provide di�erent perspectives that
should be considered about the impact of the newcomer activities
on the health of the ecosystem. We use this work as the base for our
investigation about the training to achieve a healthy ecosystem.
3 ARCHITECTURAL HEALTH OF
ECOSYSTEMS
In 2012, Iansiti and Levien introduced a framework to evaluate
the health of a business ecosystem[8]. From the idea of biological
ecosystems, they created the framework to understand the behav-
ior of large, loosely-connected networks. Focusing on operational
characteristics of an entire ecosystem, they de�ned three health
indicators that represent the state of health of the ecosystem. They
are: (i) Robustness: the capability to handle disturbances while
staying alive over time; (ii) Productivity: the ability to transform
S. Amorim et al.
natural inputs of innovation into new products and functions e�-
ciently;and (iii) Niche Creation: the skill of creating an environment
receptive to diversity and new capabilities through integration and
innovation.
Based on the Iansiti and Levien study, several authors have
studied the health of software ecosystems and created evaluation
methods[4]. Regarding the necessity of evaluating the health, we in-
troduced the concept of Architectural Health of Software Ecosystems
in previous work[3]. This idea is based on the way in which the
ecosystem creates and maintains the software architecture impact
directly on their performance indicators. This way, the architectural
health represents the “weight” of the software architecture issues
on the health of a ecosystem.
Going further, we believe that the practices adopted to handle
the software architecture impact directly on the health. So, we infer
that through evaluating the architectural practices it is possible to
have a notion of the health state concerning architectural issues[3].
Moreover, regarding practices Jacobson et al. advocates that the use
of practices is more e�cient than using processes because they can
de�ne and encompass di�erent ways of working [9]. Reinforcing the
belief that by assessing practices we can gather di�erent scenarios
related to ecosystem health.
In our previous study [3], we introduced that the architectural
health can be analyzed considering seven key areas that grouped
practices in accordance with their purpose. These key areas are:
(i) Architectural Knowledge (AK) - related to manage all learning
about the software architecture; (ii) External Management (EM) -
related to manage the interfaces third-party developers; (iii) Choice
of Technology (CH) - refers to choose the best technologies to attend
and support the ecosystem community; (iv) Resource Management
(RM) - encompasses practices to manage tools, hardware, people, etc.
required by the ecosystem; (v) Design-Making (DM) - encompasses
practices related to create and build the architecture to meet the
functional requirements; (vi) Quality Management (QM) - refers
to manage the quality of the various structures designed into the
architecture; (vii) Changes Management (CM) - related to maintain
the changes and reduce the impact caused by the changes on the
software architecture.
We can envision that to achieve a healthy ecosystem it is neces-
sary the ecosystem organization to attract and train the developers
to adopt healthy architectural practices. This is particularly the case
when these developers are newcomers, through adequate training
they could contribute to the ecosystem becoming more healthy.
4 METHODOLOGY
In this section, we introduce the main research objectives, the
context in which the study was conducted, and the approach used
to investigate architectural practices in the literature and a real-
world ecosystem.
4.1 Objectives
Looking for growth and prosperity software ecosystems work to
attract and keep new contributors. To facilitate the process of en-
gagement, the organization adopts several architectural practices
related with guidance and training for newcomers developers. The
goal of this study is to know how newcomers are accepted and
Educating to Achieve Healthy Open Source Ecosystems
also trained to accomplish and maintain the health of an open
source ecosystem concerning architectural practices adopted by the
ecosystem organization. To perform this, we capture and analyze
architectural practices that are used to facilitate the engagement of
newcomers. We also examine the in�uence of these practices on
the health of these open source ecosystems. Based on this goal, we
de�ned the two following research questions:
RQ1: What are the architectural practices that are focused
on the engaging process in open source ecosystems? This re-
search question is intended to identify architectural practices used
for accepting and training newcomers about open source ecosys-
tems.
RQ2: How do the architectural practices used to accept and
train newcomers in open source ecosystems in�uence the
ecosystem health? This research question is intended to discover
how the architectural practices taught to newcomers in�uence
the ecosystem health through the health indicators: productivity,
robustness, and niche creation in open source ecosystems.
4.2 Context
The real-world ecosystem that we investigated is the KDE ecosys-
tem1 . This is an open source community dedicated to develop a set
of multi-platform applications projected to work on GNU/Linux,
FreeBSD, Solaris Microsoft Windows, and Apple Mac OSX. KDE
o�ers several applications for communication, work, education
and entertainment, as well as it provides a platform that supports
building new applications.
KDE has existed for 20 years and has around 5,539 contribu-
tors representing 57,899,444 lines of code. The main programing
language is C++ and the most popular project is a desktop called
Plasma[7]. KDE has a speci�c website2 for newcomers where it of-
fers some guidelines to engage the community. In addition KDE has
some communities focused on disseminating and strengthening the
work carried out by the open source ecosystem. One of them, the
Brazilian community, has organized activities to attract newcomers.
There are some training materials, including video-classes available
on the internet used for this purpose.
4.3 Approach
The research approach used to investigate the architectural prac-
tices encompasses two empirical methods. First, we conducted a
literature review to identify architectural practices reported in stud-
ies about guidelines for newcomers in open source ecosystems.
Second, we performed a netnographic-based method to extract
practices from training material for newcomers on the internet.
Netnography “adapts the common ethnographic procedures of partic-
ipant observation to the peculiar contingencies of computer-mediated
social interaction: alteration, accessibility, anonymity, and archiv-
ing”[13]. We performed our netnographic-based study on the KDE
ecosystem to gather architectural practices.
1 http://www.kde.org/
2 https://community.kde.org/Get_Involved
ECSAW’18, September 2018, Madrid, Spain
Table 1: Research Studies about Newcomers
Identity Research Study
S1 Overcoming Open Source Project Entry Barriers with a Portal for
Newcomers[19]
S2 Let me in: Guidelines for the Successful Onboarding of Newcomers
to Open Source Projects[20]
S3 Lessons Learned from Teaching Open Source Software
Development[14]
S4 How Modern News Aggregators Help Development Communities
Shape and Share Knowledge[1]
S5 Producing Open Source Software: How to Run a Successful Free
Software Project[5]
S6 Newcomer Integration and Learning in Technical Support Com-
munities for Open Source Software[18]
S7 Beyond Pretty Pictures: Examining the Bene�ts of Code Visualiza-
tion for Open Source Newcomers[15]
Applying two empirical methods, we collected and analyzed data
to gather practices to connect to each health indicator. In the rest
of this section, we describe more detail about the methods.
Literature Review - We found six studies describing recommen-
dations or o�ering some guidance for the ecosystem organization
and newcomers about engaging on open source ecosystems. In each
study the authors investigate barriers for newcomers and provide
some guidance to facilitate the engagement process. We extracted
from these studies speci�c architectural practices recommended
for ecosystem organization. Some practices were reported by two
or more authors, so we collected each practice and conducted a
crossed analysis to summarize and avoid redundancies. From the
literature review, we selected 29 architectural practices. Table 1
shows the studies included on our literature review.
Netnography - Our netnographic-based method included pro-
cedures such as planning, input, data collection, interpretation and
adherence to ethical standards. We analyzed websites which the
KDE ecosystem provided for newcomers to extract initial informa-
tion. Also, we analyzed six videos available on Youtube3 provided
by KDE Brazilian community to attract new developers and facili-
tate their engagement. Three videos show KDE videoconference
episodes called “Engrenagem”. These episodes introduce the KDE
ecosystem for beginners, including sessions of questions and an-
swers to clarify the process of engagement. Other three videos are
video-classes focused on introducing the KDE ecosystem and their
interactions with other ecosystems, installing technologies and
preparing the development environment to work on contributions.
When we were transcribing the video recordings for this study, we
searched for answers to identify architectural practices adopted on
KDE ecosystem. During coding and identi�cation of practices we
mapped relevant statements of actions to support the knowledge
of the practices. Figure 1 shows the research approach used for the
netnographic-based study.
5 RESEARCH RESULTS
In this section, considering the research question RQ1: What are the
architectural practices that are focused on the engaging process in open
source ecosystems?, we describe speci�cs architectural practices re-
ported in the literature review and also found by the netnographic-
based study. Table 2 shows a summary with 29 practices. We
3 www.youtube.com
ECSAW’18, September 2018, Madrid, Spain
Figure 1: Netnographic Method[13]
grouped each practice considering architectural key areas more
proper with their characteristics. We found 18 practices for Archi-
tectural Knowledge (AK) area, 9 practices for External Management
(EM) area, 2 practices for Change Management (CM) area, and 2
practices for Quality Management (QM) area. Table 2 also shows
the type of source where the practice was collected: literature re-
view or netnographic-based method. For studies from the literature
review we identi�ed the research study following the �eld Identity
from table 1. For example, practice P1 was found on the study S2 -
Let me in: Guidelines for the Successful Onboarding of Newcomers to
Open Source Projects.
Considering the research question RQ2: How do architectural
practices used to accept and train newcomers in open source ecosystems
in�uence the ecosystem health?, we analyzed the practices gathered
from RQ1 and connected them to health indicators: robustness,
productivity, and niche creation. We believe that these practices
exert relevant in�uences on the health indicators. Table 2 also shows
the relationship between practices and health indicators.
Robustness - In spite of obstacles the software ecosystems
should be capable of facing problems and continue working to
achieve success. Considering this idea we observed that 19 practices
in�uence the robustness of the ecosystem. First, among these prac-
tices studied, we observed that when the software ecosystem o�ers
updated information to newcomers, it avoids components being
modi�ed causing complications. So practices such as: identify and
dismiss outdated information on website (P2), provide visual infor-
mation such as the class diagrams or dependency views, and code
visualization tools (P12), and tag all task in accordance with degree
of di�cult(easy, medium, di�cult) (P24) guide newcomers to what
to do and in what order, giving con�dence and awareness for their
steps inside the ecosystem. Other practices such as: keep the list of
tasks updated informing who is working on the solution (P20) and
S. Amorim et al.
provide information about how to report translation mistakes (P17)
help to control the work inside the community avoiding misun-
derstandings. Similarly, practices as: provide unit test automation
for main functionalities (P28) and provide an automated process
to launch release of applications (P29) reduce the probability of
human mistakes mainly coming from newcomers.
Productivity - Several actions are needed to transform inputs
into new products and functions e�ciently. The productivity is
highly a�ected by the majority of practices related to newcom-
ers. We observed 22 practices connected to productivity directly.
Practices such as providing generation of (semi-)automated docu-
mentation �ltered to up-to-date information relevant to newcomers
(P3), answer questions on mailing list quickly (P4), and create a
detailed step-by-step tutorial linking information about common
problems and possible solutions (P6) accelerate the identi�cation of
tasks to be performed by newcomers. They also allow newcomers to
work independently and reduce the time required to search support-
ing information. Joint practices such as provide proper indications
to enable newcomers to �nd the artifacts that need to be changed
(P26) and provide information about dependencies among artifacts
(P27) facilitate the change management performed by newcomers
and reduces the possibility of improper changes avoiding rework.
In addition, provide documentation about translation rules that
developers must follow to prepare code to other languages (P18),
provide a virtual machine with pre-con�gured build environments,
web-based IDEs, or a container management tool (P22), and provide
a message template for newcomers interact with the community
(P25) facilitate the �rst interactions with the community and guide
newcomers to keep the focus on working instead of losing time
looking for con�guration data.
Niche Creation - Creating an environment receptive to di-
versity and new capabilities requires several e�orts to keep the
ecosystem attractive. 16 practices were identi�ed interfering on
niche creation. The ecosystem should receive newcomers by facili-
tating their training and work. Practices as: establish mentorship
through designating a few experienced members to communicate
with new members (P5), provide a newcomer-speci�c page or portal
guiding their �rst steps (P1), and provide a dictionary to newcomers
to learn the technical jargon and acronyms of the community (P11)
facilitate the engagement process for newcomers allowing them to
focus their e�ort on creating new functionalities or applications
instead of losing time trying to understand the ecosystem environ-
ment. Further the existence of a manifest explaining requirements
for an application belonging to the ecosystem (P14) and the gen-
eration of (semi-)automated documentation �ltered to up-to-date
information relevant to newcomers (P3) inform the newcomer what
they can do to innovate and how to integrate their ideas into the
ecosystem.
6 DISCUSSION
The analysis presented in the previous section exempli�es the con-
nection of some practices to health indicators. Many practices in�u-
ence more than one health indicator. Each action of the ecosystem
organization to facilitate the engagement of newcomers increases
the probability of retaining them longterm so that they increase
their portfolio of functionalities and applications. Each ecosystem
Educating to Achieve Healthy Open Source Ecosystems ECSAW’18, September 2018, Madrid, Spain

Table 2: Practices x Health Indicators

Practices Key Areas Sources Robustness Productivity Niche Creation

P1. Provide a newcomer-speci�c page or portal guiding their �rst steps, AK S2 3 3
including architectural information
P2. Identify and dismiss outdated information on websites AK S2 3
P3. Provide generation of (semi-)automated documentation �ltered to AK S2 3 3
up-to-date information relevant to newcomers
P4. Answer questions on the mailing list quickly AK S2 3 3 3
P5. Establish mentoring by designating a few experienced members to AK S2 3 3 3
communicate with new members
P6. Create a detailed step-by-step tutorial linking information about com- AK S2 3 3
mon problems and possible solutions
P7. Provide updated documentation about code's organizational structure, AK S2 3 3 3
and how the components, modules, classes, and packages are related to
each other
P8. Support the participation of the ecosystem on aggregators’ sites such AK S4 3 3
as stack over�ow, reddit, hacker news, and so on
P9. Keep documentation organized and indexed providing a level of di�- AK S3 3
cult from beginners to experts
P10. Inform newcomers to write informative subjective lines when desir- AK S6 3
ing an answer of the community. They should post direct-to-the-point
questions
P11. Provide a dictionary to newcomers to facilitate their learning of the AK S6 3 3 3
technical jargon, acronyms of the community
P12. Provide visual information such as the class diagrams or dependency AK S7 3 3 3
views, and code visualization tools
P13. Provide video-classes about introducing the ecosystem, installing AK netnographic 3 3
technologies, con�guring the development environment, and using the
dependencies with other ecosystems
P14. Provide a manifest explaining requirements of an application belong- AK netnographic 3
ing to the ecosystem
P15. Provide videoconference sessions with questions and answers about AK netnographic 3 3 3
relevant topics
P16. Provide information about the translation process (how to participate AK netnographic 3
and tools used)
P17. Provide information about how to report translation mistakes AK netnographic 3
P18. Provide documentation about translation rules that developers must AK netnographic 3 3
follow to prepare code for other languages
P19. Point newcomers to easy tasks �ltered by di�culty, skills needed, EM S1 and S2 3 3
and topics
P20. Keep the list of tasks updated informing about who is working on EM S2 3 3 3
the solution
P21. Setting a code of conduct to avoid mistreatment among members EM S2 3
P22. Provide a virtual machine with pre-con�gured build environments, EM S2 3
web-based IDEs, or a container management tool
P23. Inform newcomers about technical background required. Identify EM S1 3
which speci�c technologies they need to know or they should learn to
achieve their goal of contributing to the ecosystem
P24. Tag all task in accordance with degree of di�culty (easy, medium, EM S1 3 3
di�cult)
P25. Provide a message template for newcomers to use to interact with EM S1 3 3
the community
P26. Provide clear directions to enable newcomers to �nd the artifacts CM S1 3 3
that need to be changed
P27. Provide information about dependencies among artifacts CM S1 3 3
P28. Provide unit test automation for main functionalities QM netnographic 3 3
P29. Provide an automated process to launch release of applications QM netnographic 3 3

establishes their appropriate way-of-working and their approach to
being pro�table, so newcomers arriving in this environment need to
learn fast and �nd a way to contribute with minimal complications.
We observed that the 29 practices cover several aspects of the
engagement process of a newcomer. However, in our collection of
practices we did not see practices directly related to explaining the
alignment of business strategies to the technical architecture. So, the
beginner can have some di�culty in understanding the reasoning
behind decisions made by the ecosystem board. The existence of
a short history, showing the last decisions and future directions,
could situate newcomers in the ecosystem context in�uencing niche
creation.
This is an exploratory study intended to understand the impact
of the newcomers engagement process on the ecosystem health.
Taking consciousness actions to keep and achieve health should
come from everyone - beginners to experienced members. We did
not determine how much e�ort is necessary to implement all these
practices; however, newcomers who are well prepared overcome
initial obstacles faster. As a result, they can keep the focus on
working and contributing to achieving a healthy state. Additional
studies are necessary to analyze architectural practices in detail as
ECSAW’18, September 2018, Madrid, Spain
well as empirical studies to consolidate their connection with an
software ecosystem’s health.
7 THREATS TO VALIDITY
There are some threats to validity for our study. They are described
and detailed as follows:
- Generalization of practices: Although we used data from a va-
riety of projects in our literature review, the �ndings cannot be
generalizable to all open source ecosystems. Regarding the practical
veri�cation, we only studied the KDE ecosystem. We are aware of
di�erent practices adopted by di�erent open source ecosystems, and
that some practices recommended by literature cannot be applied
in some real-world ecosystems.
- Incomplete list of practices: Another problem could be that the
list of architectural practices is incomplete. We can have forgotten
some relevant architectural practice. In order to minimize this prob-
lem, we collected practices from recent studies published providing
guidance for newcomers. We also chose to consider only updated
pages from the KDE website.
- Interpretation of the architectural practices: In order to avoid any
bias of interpretation with architectural practices, we decided to
keep the same description from literature studies and netnographic
material such as web pages, tutorials, and video-casts.
8 CONCLUSION
Achieving a healthy open source software ecosystem involves the
adoption of adequate practices, development of consistent strategies
to attract and retain newcomers, providing extensive training, im-
plementing guidance policies, and others. Concerning architectural
practices, these have a direct impact on the quality and survival
of the ecosystem products. So, practices used to accept and train
newcomers should be proactive to prepare them for contributing to
a healthy ecosystem from the start. Realizing this vision requires
that we investigate and analyze in detail the in�uences of the archi-
tectural practices adopted on open source ecosystems concerning
the engagement process for newcomers.
In this paper, we presented di�erent architectural practices rec-
ommended by literature to be part of newcomers training. Also,
we performed a case study based on a nethnographic method to
study what practices and how a real-world ecosystem uses these
practices for receiving newcomers. Further, we analyzed the impact
of these practices on health indicators. These results will contribute
to our ongoing research proposal of an assessment method for the
architectural health of software ecosystems based on practices [3].
ACKNOWLEDGMENT
The contribution by �rst author Simone Amorim was partially
funded by DPGI-IFBA-Campus Salvador.
REFERENCES
[1] Maurício Aniche, Christoph Treude, Igor Steinmacher, Igor Wiese, Gustavo Pinto,
Margaret-Anne Storey, and Marco AureÌĄlio Gerosa. 2018. How Modern News
Aggregators Help Development Communities Shape and Share Knowledge.
[2] Laurence Bradford. 2018. How Open-Source Development Is Democratizing
The Tech Industry. https://www.forbes.com/sites/laurencebradford/2018/03/26/
how-open-source-development-is-democratizing-the-tech-industry/. Accessed:
2018-04-28.
S. Amorim et al.
[3] Simone da S. Amorim, John D. McGregor, Eduardo S. de Almeida, and Christina
von F. G. Chavez. 2017. Software Ecosystems’ Architectural Health: Another
View. In Proceedings of the 5th International Workshop on Software Engineering
for Systems-of-Systems and 11th Workshop on Distributed Software Development,
Software Ecosystems and Systems-of-Systems (SESoS/WDES ’17).
[4] Simone da Silva Amorim, Félix Simas S. Neto, John D. McGregor, Eduardo Santana
de Almeida, and Christina von Flach Garcia Chavez. 2017. How Has the Health
of So ware Ecosystems Been Evaluated? A Systematic Review. In Proceedings of
the 31st Brazilian Symposium on Software Engineering (SBES ’17).
[5] Karl Fogel. 2005. Producing Open Source Software How to Run a Successful Free
Software Project. O’Reilly Media.
[6] Oscar Franco-Bedoya, David Ameller, Dolors Costal, and Xavier Franch. 2014.
Measuring the Quality of Open Source Software Ecosystems Using QuESo. ,
39-62 pages. https://doi.org/10.1007/978-3-319-25579-8_3
[7] Open Hub. 2018. The KDE Open Source Project on Open Hub. https://www.
openhub.net/p/kde. Accessed: 2018-04-29.
[8] M. Iansiti and R. Levien. 2002. Keystones and Dominators: Framing Operating
and Technology Strategy in a Business Ecosystem. Harvard Business School
03-061 (November 2002).
[9] I. Jacobson, P. W. Ng, and I. Spence. 2007. Enough of Processes – Let’s Do
Practices. Journal of Object Technology 6, 6 (2007), 41–66.
[10] Slinger Jansen. 2014. Measuring the health of open source software ecosystems:
Beyond the scope of project health. Information and Software Technology 56
(November 2014), 1508–1519. Issue 11. https://doi.org/10.1016/j.infsof.2014.04.
006 Special issue on Software Ecosystems.
[11] Slinger Jansen, Michael Cusumano, and Sjaak Brinkkemper. 2013. Software
Ecosystems: Analyzing and Managing Business Networks in the Software Industry.
Edward Elgar Publishers.
[12] Slinger Jansen and Michael A. Cusumano. 2013. Defning Software Ecosystems:
A Survey of Software Platforms and Business Network Governance. In Software
Ecosystems: Analyzing and Managing Business Networks in the Software Industry,
Slinger Jansen, Sjaak Brinkkemper, and Michael Cusumano (Eds.). Edward Elgar
Publishing, Chapter 1, 13–28. https://doi.org/10.4337/9781781955635.00008
[13] Robert V. Kozinets. 2010. Netnography. Doing Ethnographic Research Online. Sage
Publications.
[14] Becka Morgan and Carlos Jensen. 2014. Lessons Learned from Teaching Open
Source Software Development. , 133-142 pages.
[15] Yunrim Park and Carlos Jensen. 2009. Beyond Pretty Pictures: Examining the
Bene�ts of Code Visualization for Open Source Newcomers. In Proceedings of
the 5th IEEE International Workshop on Visualizing Software for Understanding
and Analysis (VISSOFT ’09).
[16] Gustavo Henrique Lima Pinto, Fernando Figueira Filho, Igor Steinmacher, and
Marco Aurelio Gerosa. 2017. Training Software Engineers Using Open-Source
Software: The Professors’ Perspective.
[17] Anita Sarma, Rafael Leano, Marco AurÃľlio Gerosa, and Igor Steinmacher. 2016.
Training the Future Workforce through Task Curation in an OSS Ecosystem. ,
932-935 pages.
[18] Vandana Singh. 2012. Newcomer Integration and Learning in Technical Sup-
port Communities for Open Source Software. In Proceedings of the 17th ACM
international conference on Supporting group work (GROUP ’12). 65–74.
[19] Igor Steinmacher, Tayana Uchoa Conte, Christoph Treude, and Marco Aurélio
Gerosa. 2016. Overcoming Open Source Project Entry Barriers with a Portal for
Newcomers.
[20] Igor Steinmacher, Christoph Treude, and Marco Aurélio Gerosa. 2018. Let me
in: Guidelines for the Successful Onboarding of Newcomers to Open Source
Projects. IEEE Software (2018). https://doi.org/10.1109/MS.2018.110162131
[21] Krzysztof Wnuk, Konstantinos Manikas, Per Runeson, Matilda Lantz, Oskar Wei-
jden, and Hussan Munir. 2014. Evaluating the Governance Model of Hardware-
Dependent Software Ecosystems âĂŞ A Case Study of the Axis Ecosystem. In
Proc. of the 4th International Conference on Software Business (ICSOB). 212–226.