# Understanding the Effects of Practices on KDE Ecosystem Health

Simone Da Silva Amorim, John D. McGregor, Eduardo Almeida, Christina

Von Flach Garcia Chavez

► To cite this version:

Simone Da Silva Amorim, John D. McGregor, Eduardo Almeida, Christina Von Flach Garcia Chavez. Understanding the Effects of Practices on KDE Ecosystem Health. 13th IFIP International Conference on Open Source Systems (OSS), May 2017, Buenos Aires, Argentina. pp.89-100, 10.1007/978-3-319-57735-7_10 . hal-01776279

HAL Id: hal-01776279

https://inria.hal.science/hal-01776279

Submitted on 24 Apr 2018

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
Understanding the Effects of Practices on KDE
Ecosystem Health

Simone da Silva Amorim<fnref n="1" />, John D. McGregor<fnref n="2" />, Eduardo Santana de Almeida<fnref n="3" />,
and Christina von Flach G. Chavez<fnref n="3" />

**Abstract.** Open source software ecosystems have adjusted and evolved a set of practices over the years to support the delivery of sustainable software. However, few studies have investigated the impacts of such practices on the health of these ecosystems. In this paper, we present the results of an ethnographic-based study conducted during the Latin-American KDE users and contributors meeting (LaKademy 2015) with the goal of collecting practices used within the KDE ecosystem and understanding how they affect ecosystem health. The analysis was based on softgoal interdependency graphs adapted to represent practices and relate them to non-functional requirements and goals. Our results provide a preliminary insight to understand how KDE ecosystem community interacts, which working practices have been adopted and how they affect ecosystem health.

**Keywords:** Open source software ecosystems, ethnographic studies, software practices, software ecosystem health.

# 1 Introduction

The software ecosystem (SECO) strategy has been used with great success for several years [1, 2]. This strategy has facilitated the emergence of communities surrounding hardware and software computing platforms, such as the Apple iOS community, and certain configurable products, such as the Eclipse Rich Client Platform. Each organization joining a SECO is looking to fill a role in the community that will foster its business objectives. The community members leverage the work of other members to grow bigger products faster than they could have on their own.

Within a SECO, one or more platform providers work to attract product developers to use the provider's platform as the foundation for products. The platform organization shares some degree of control over their platform, provides tools that make product development easier on their platform, and provides

<footnote n="1">¹ Federal Institute of Education, Science and Technology of Bahia, Bahia, Brazil
simone.amorim@ifba.edu.br</footnote>

<footnote n="2">² Clemson University, South Carolina, USA
johnmc@cs.clemson.edu</footnote>

<footnote n="3">³ Federal University of Bahia, Bahia, Brazil
esa@dcc.ufba.br, flach@ufba.br</footnote>
access to information about the current structure and future changes to the platform. The dominant organization in the ecosystem, usually the platform owner, heavily influences the culture of the ecosystem.

The *health* of a SECO stands for *the growing and continuity of the software ecosystem remaining variable and productive over time* [11]. The assessment of SECO health can be performed with respect to different aspects, including robustness, productivity, and niche creation [11]. Some studies present quantitative assessment on SECO health [13].

Practices can be useful to understand a SECO and assess its health. For instance, the practice "*review all code before accepting into the release*" may impact several quality indicators and contribute to increasing productivity while avoiding rework. However, to our knowledge, there is no qualitative study that focuses on software practices and their relation to SECO health.

In this paper, we present the results of an ethnographic-based study conducted with the purpose of investigating the practices used by a SECO from three perspectives [5] – business, social, and technical – and their impact on SECO health. The selected research method, ethnography, has been used to study software practices in different contexts [16, 17]. The object of our study was KDE<fnref n="4" />, an open source SECO that gathers a set of platforms and products for Linux distributions. During the Latin-American KDE users and contributors meeting (LaKademy 2015), we collected day-to-day practices and analyzed them to understand their impact on SECO health. Softgoal interdependency graphs (SIG) [7] extended with practices, support the analysis of KDE practices and their influence on health aspects of SECO such as productivity and robustness.

The remainder of the paper is organized as follows: Section 2 presents background on SECO. Section 3 introduces SIG-P, our customized SIG [7]. Section 4 presents the context and design of our study. Section 5 presents the collected KDE practices and a preliminary analysis of their relation to KDE health. Section 6 presents findings, contributions and limitations of our work. Section 7 presents related work. Finally, Section 8 provides a brief description of future work and some concluding remarks.

## 2 Background

The concept of *software ecosystem health* was introduced by Iansiti and Levien as *the growing and continuity of the SECO remaining variable and productive over time* [11]. They argued that the performance of an organization also depends on its interactions with the whole ecosystem – not only on the relationship with competitors and stakeholders and on the organizational potential. Iansiti and Levien drew an analogy with biological ecosystems, and argued that SECO health should be assessed based on three aspects: robustness, productivity, and niche creation [11].

Robustness refers to the ability of the ecosystem to survive radical changes and problems resulting from these changes. The ecosystems should face and over-

<footnote n="4">⁴https://www.kde.org/</footnote>
come all inevitable difficulties inherent in the evolutionary process. Productivity
is related to the way in which the work is accomplished with the least waste
of time and effort. The ecosystem should add value through innovation, man-
agement of resources and cost control. Lastly, niche creation represents SECO
features that encourage and support diversity among the different species in the
ecosystem. The ecosystem should provide the structure for creating new features
over time, increasing the diversity among SECO members' products [11].

Campbell [5] introduces three views to classify the features of a SECO: tech-
nical, business and social. The Technical View presents the architecture and ap-
proaches to implementing software. The Business View captures business strate-
gies at play in the ecosystem. In some cases, organizations will be in direct com-
petition and making decisions on release dates and licensing in response to the
actions of others within the ecosystem. The Social View captures relationships
among humans: developers, users, managers and other participants.

SECO health should not be evaluated only by considering metrics. Practices
also aid in understanding a project and its evolution with greater fidelity. They
provide clear goals and forms to assess a good working performance to achieve
a successful end [12]. For example, the practice “Provide continuous integra-
tion tools to check code every day and report errors” will impact several quality
indicators as well as contribute to increasing productivity while avoiding rework.

3 The NFR Framework with Practices

The NFR framework [6, 7] provides a systematic approach for defining and repre-
senting non-functional requirements (NFR) for software products. A set of goals
represent NFR, design decisions and claims to support or not other goals. Goals
are decomposed into subgoals and related with AND/OR relationships [7].

The term *softgoal* introduces the concept of *satisficing* [7]. Softgoals may
contribute to some degree (positively (+, ++) or negatively (-, --), fully or par-
tially), in satisfying other softgoals. A Softgoal Interdependency Graph (SIG)
models NFR and their interdependencies to achieve a softgoal (or desired qual-
ity). Design decisions are represented by operationalization softgoals. SIG dia-
grams provide a visual representation for SIG [7].

3.1 SIG with Practices (SIG-P)

SIG with Practices (SIG-P), our customized SIG, models SECO practices and their influence on SECO non-functional requirements. In SIG-P, each practice is modeled as a *satisficing technique* [7] and the degree of its influence on SECO health is documented.

Aspects of SECO health such as robustness, productivity, and niche cre-
ation [11] are modeled as *softgoals*. Each softgoal can be decomposed and re-
fined into mandatory and optional subgoals/NFR that influence directly the
achievement of such aspects of SECO health. Practices are connected by inter-
dependency links to NFR to indicate that they contribute to reach softgoals.
Social, business and technical views [5] are presented in SIG-P diagrams.
<figure><img src="image_2.png" /><figcaption>Fig. 1. SIG-P for Business View</figcaption></figure>

SIG-P diagrams can be used to enhance general understanding about a SECO and its health. They provide a graphical representation for practices, their interdependencies and impacts on NFR and SECO aspects. Moreover, evaluators can build SIG-P models to reason and provide qualitative assessment on SECO health and use SIG-P diagrams to support discussions about correlations and trade offs among softgoals. Figure 1 presents an example of a SIG-P diagram. Details about this example are presented and discussed in Section 6.

## 3.2 SIG-P Construction

The construction of a SIG-P graph for a specific SECO view [5] starts with one or more ecosystem health aspects [11] and a set of practices used by some target SECO. A catalogue of documented NFR, such as the one provided in [7] is strongly recommended.

We defined three steps to guide the bottom-up construction of a SIG-P for each SECO view. Given a set of practices of a target SECO, a catalogue of NFR and SECO softgoals: (1) For each practice, identify a subset of NFR and consider its influence on each NFR; (2) For each identified NFR, analyze its influence on softgoals, considering ambiguities, trade offs and priorities; and (3) For each identified NFR, evaluate the impact (positive or negative) of NFR on softgoals.

These steps can be refined with many iterations considering the reasoning about NFR and their different alternatives. The SIG-P diagram from Figure 1 illustrates a SIG-P for a business view.

## 4 Methodology

The KDE ecosystem<fnref n="5" /> is an international community that provides a Free Open Source desktop environment for many Linux distributions. The KDE ecosystem has several initiatives to promote their projects around world. In Brazil,

<footnote n="5">⁵http://www.kde.org/</footnote>
a branch of the global organization gathers a team of KDE supporters. The Brazilian group promotes LaKademy (Latin American Akademy), an annual event at which KDE users and contributors meet in person to exchange ideas about projects and discuss the future of KDE. At this event, attendees participate in a set of activities such as lectures, hackathon sessions, and meetings on specific topics.

Hackathons are events that produce working software in a limited period of time. They consist of strenuous and uninterrupted intervals of coding, and are very useful as social and educational events [14]. Komssi et al. stated that hackathons' participants can also learn new practices, technologies, and attitudes, which can be used in everyday work [14]. During KDE events, hackathons provide informal ways to meet new people and learn new technologies.

## 4.1 Research Method

In this study, research techniques commonly used in ethnographic studies were adopted to support the researcher in understanding the practices and communication strategies KDE uses to work collaboratively. Most of the work in the context of open source SECOs, including KDE, is performed by distributed teams and contributors. Therefore, LaKademy provided an appropriate setting for conducting an ethnographically-inspired [9, 18], short term study about KDE. The researcher could observe and participate in LaKademy through in-person meetings and activities.

To address practical challenges faced when conducting ethnographic studies [16], we joined the KDE community to gain better access to the setting of the practices and the use of a common vocabulary. We also conducted our investigation without unnecessary formality, explaining our research, who we were and what we were doing, and trying not to interfere with the activities of LaKademy. Verbal consent was captured on audio recordings at the beginning of sessions. Furthermore, we were rigorous in data collection and analysis to avoid bias.

The first days of Lakademy hackathons are used to disseminate KDE practices and knowledge about the ecosystem. Then developers follow a plan to work hard and deliver planned features. Therefore even knowing that developers are not working in their natural setting, we assume that many practices can be transfered to everyday work of participants.

## 4.2 Data Collection and Analysis Procedures

On-site immersion and data collection took place at LaKademy 2015⁶ event held in Salvador, from 3rd to 6th June, 2015. The event had 15 participants including students, professionals and KDE collaborators. During 4 days, we conducted semi-structured interviews, listened to lectures, analyzed KDE documents, and observed interactions of community members, mainly during hackathon sessions. Observations were documented in the form of field notes and audio records.

<footnote n="6">⁶https://br.kde.org/lakademy-2015</footnote>
<table><caption>**Table 1.** Social Practices</caption><thead><tr><td>Id</td><td>Most Important Social Practices</td><td>Id</td><td>Other Social Practices</td></tr></thead><tbody><tr><td>S7</td><td>Conduct a general annual face to face meeting to discuss community issues.</td><td>S12</td><td>Promote happy hours and dinners to facilitate social integration during events.</td></tr><tr><td>S1</td><td>Create confidence in a member based on his work history. Based on this, provide different levels of responsibilities.</td><td>S2</td><td>Require that at least two persons nominate a member to be promoted up the levels of responsibilities.</td></tr><tr><td>S4</td><td>Promote networking in the work market.</td><td>S3</td><td>Conduct annual meetings among translators by projects.</td></tr><tr><td>S8</td><td>Perform elections to assign responsibility levels for new members.</td><td>S5</td><td>Promote social relationships with members in other countries.</td></tr><tr><td>S11</td><td>Use tools to support communication in the group such as: mailing lists, forums, IRCs, wikis, and blogs.</td><td>S6</td><td>Create opportunities to practice another human language such as English.</td></tr></tbody></table>

**Interviews.** Interviews were semi-structured, with 24 open-ended questions intended to understand the daily practices used in KDE ecosystem. Interviews were audio-recorded and later transcribed. We had interview sessions with 4 KDE members that have contributed actively to KDE for 6 years or more – three of them were members of KDE e. V. [3], a group that represents the KDE Community with respect to legal and financial issues. One of the interviewed KDE members is part of the KDE Board responsible for business management. We assumed that these people were heavily engaged and up to date regarding most of KDE decisions and practices. They also provided relevant information about the KDE community, contribution areas, financial issues and future plans. The questionnaire can be found at http://homes.dcc.ufba.br/~ssamorim/lakademy/.

**Hackathons.** During LaKademy 2015, the researcher joined two hackathon sessions for removing bugs from two KDE applications: Cantor, a mathematical application, and the Plasma Network Manager. These sessions provided a good opportunity to observe developers with different levels of experience performing tasks with their own style and ask questions about reasons behind their actions. Some practices, not identified during interviews, were collected during hackathon sessions.

**Document Analysis.** The researcher also gathered references to online KDE documents. The community maintains a rich website that describes various aspects of KDE ecosystem. We had access to international and Brazilian websites and their documents. Thus, we could explore in detail the dynamics of interactions of the entire KDE ecosystem.

# 5 Results and Analysis

## 5.1 Practices in KDE

We collected 68 practices used in KDE SECO. Although a practice could be associated to more than one SECO view (social, business, or technical), we linked
<table><caption>**Table 2.** Business Practices</caption><thead><tr><td>Id</td><td>Most Important Business Practices</td><td>Id Other Business Practices</td></tr></thead><tbody><tr><td>B5</td><td>Provide a nonprofit corporation to manage legal and financial issues.</td><td>B6 Divide activities into working groups responsible for areas such as marketing, infrastructure, design, community to keep the group healthy.</td></tr><tr><td>B8</td><td>Attract companies that will invest money to support the ecosystem.</td><td>B1 Provide flexibility in translation schedule and negotiate deadlines.</td></tr><tr><td>B11</td><td>Define a schedule of releases that will affect the work of the entire community.</td><td>B2 Reach an agreement in the community on how to answer questions that are not addressed in tutorials or guidelines.</td></tr><tr><td>B16</td><td>Assign a lead maintainer for each project for making technical decisions.</td><td>B4 Provide lectures to teach how to translate and how to become a contributor.</td></tr><tr><td>B3</td><td>Make decisions based on discussions in the mailing list.</td><td>B7 Make technical decisions independently within each project.</td></tr></tbody></table>

<table><caption>**Table 3.** Technical Practices</caption><thead><tr><td>Id</td><td>Most Important Technical Practices</td><td>Id Other Technical Practices</td></tr></thead><tbody><tr><td>T1</td><td>Each person chooses the work they desire to perform among available tasks in the ecosystem, e.g., file to translate, code to develop, applications to test, and so on.</td><td>T11 Provide tools for code optimization, static analysis of code, code review, and test automation.</td></tr><tr><td>T2</td><td>Review all code before accepting into the release.</td><td>T15 Provide a manifest which project must follow to be considered part of the ecosystem.</td></tr><tr><td>T10</td><td>Provide a freeze period to stabilize the translation of a version before the launch of that version.</td><td>T16 Require that all infrastructure must be under the control of the ecosystem and be based on technologies created by the ecosystem.</td></tr><tr><td>T13</td><td>Provide continuous integration tools to check code every day and report errors.</td><td>T25 Keep backward compatibility for a long time (around 6 years).</td></tr><tr><td>T23</td><td>Develop code to be extensible. The use of T19 plug-ins and compilation is separated between the core and applications.</td><td>T19 Use scripts to do an initial code review and catch errors.</td></tr></tbody></table>

it to a single view for which the practice seemed to be most influential. The collection of 68 practices was validated by two interviewees. Five practices (B14, T3, T21, T27, and T35) were not validated. We also asked the two interviewees to choose five important practices for each view.

Table 1 presents 10 Social Practices, related to working together in the community, selected by two interviewees. Accordingly, Table 2 presents 10 Business Practices, related to aspects of management, strategic planning, and innovation, and organized activities such as marketing, making decisions, and so on. Finally, Table 3 presents 10 Technical Practices (out of 40 practices), related to product development (core and applications), technologies used, code rules, and others. Other practices are available at http://homes.dcc.ufba.br/~ssamorim/lakademy/.
## 5.2 Analysis

We resorted to SIG-P diagrams to understand and analyze the effects of identified practices on KDE health. SIG-P diagrams were built, one for each SECO view, by following steps described previously (Section 3).

SIG-P diagram for KDE business view (Figure 1, introduced in Section 3) supports the analysis of KDE business practices. For instance, practice B5 (*Provide a nonprofit corporation to manage legal and financial issues*) may influence *Sustainability* that, in turn, provides a positive influence on *Niche Creation*.

<figure><img src="image_3.png" /><figcaption>Fig. 2. SIG-P for Social View</figcaption></figure>

Figure 2 presents a SIG-P diagram for KDE social view that is used to reason about KDE social practices. For instance, Practices S7 (*Conduct a general annual face to face meeting to discuss community issues*) and S8 (*Perform elections to assign responsibility levels for new members*) affect *Controllability*<fnref n="7" /> that, in turn, provides a positive influence on *Robustness* and *Productivity*.

Figure 3 presents a SIG-P diagram for KDE technical view. For instance, Practice T16 (*Require that all infrastructure must be under the control of the ecosystem and be based on the technologies created by the ecosystem*) may influence *Reliability* that, in turn, provides a positive influence on *Robustness* and *Productivity*. At http://homes.dcc.ufba.br/~ssamorim/lakademy/ other SIG-P diagrams are available.

# 6 Discussion

## 6.1 Findings

This study allowed us to uncover implicit features of SECO practices and reveal the context in which they were immersed: (a) Many practices are not documented or standardized; (b) There is a great amount of tacit knowledge sharing

<footnote n="7">⁷Controllability can be defined as a quality of ecosystems interested in keeping stable and pursuing sustainable development [15].</footnote>
<figure><img src="image_4.png" /><figcaption>Fig. 3. SIG-P for Technical View</figcaption></figure>

during hackathon sessions – this highlights the importance of meeting people face-to-face to strengthen the community; and (c) Practices do have influence on KDE ecosystem health, which can be exploited later to support decision-taking processes.

## 6.2 Contributions

SECO participants can use the knowledge base of practices and related effects in situations such as: (a) SECO adoption, whenever an organization wants to adopt some ecosystem platform, the NFR with practices can be used to evaluate risks; (b) Getting involved, whenever an individual or team wants to contribute with an open source ecosystem, documented practices and their effects on SECO health can improve the learning curve; and (c) Partnership establishment, in scenarios of feasibility analysis, the NFR with practices can provide useful information to judge the feasibility of partnerships.

Researchers can use our results as input to new evaluation models and quality models for SECOs, and inspiration for performing additional qualitative studies on SECO health. So far additional studies and data are necessary to analyze which practices are more influential or the degree of their influence on SECO health. A deeper understanding on SECO practices will help us to further investigate factors that may contribute to balancing the trade-offs necessary for SECO health.

## 6.3 Limitations

The contributions of this study should be balanced against some limitations relating to the timing of the study, observer bias, and observed subject bias. Classical ethnographic studies are performed over a long period of time[10]. However, LaKademy provides a rare opportunity to meet people face-to-face in an ecosystem that carries out many online activities.

Additionally, there are limitations regarding practices not captured, variability of SIG-P configurations, and validation of the results. SIG-P models are
supposed to support understanding and analysis of SECO practices with respect to their influence on NFR and different health aspects (robustness, productivity, and niche creation) of KDE. In this paper, we only show one combination for SIG-P, but many other combinations are possible including negative impacts. Moreover, we worked to avoid bias taking a rigorous approach to data collection and analysis. Nevertheless, we should perform more combination of practices and NFR and validate the results to produce a more comprehensive analysis.

# 7 Related Work

To our knowledge, there is no qualitative study in the context of SECO health that focuses on software practices. In this section, we outline related work that addresses ethnography and practices.

Sharp et al. [17] presented an ethnographic study to identify XP practices, conducted in a small company that developed web-based intelligent advertisements. Their findings included 5 characterizing themes within XP practice. The identified practices indicated that, in the XP culture, individuals and teams are respected, take responsibilities, and act to maintain the quality of working life. This work helped us in the identification of XP practices used by KDE.

Evangelista [8] in his PhD thesis investigated the Free Software Movement (FSM), with the overall goal of studying the relation between free software and topics such as culture, power, labor and ideology. To understand the FSM in the Brazilian context, he conducted an ethnographic study during the 9th International Free Software Forum (FISL) <fnref n="8" />. His study reported several practices used in open source ecosystems. Furthermore, it inspired us to apply ethnography in our work, and provided guidance on observing and understanding practices used by KDE.

# 8 Conclusions and Future Work

SECOs have achieved success and attracted the attention of researchers. However, little is known about SECO practices and reasons for their success. In this paper, we presented an ethnographic-based study conducted during LaKademy 2015 to collect practices of the KDE ecosystem and understand how they affect ecosystem health. These practices were linked to non-functional requirements to provide a preliminary support to SECO health assessment.

This work provides a set of practices and a SIG-P catalogue of the analyses of the impact of practices on SECO health. These results are important steps for our ongoing research proposal of an assessment method for SECO health based on practices [4]. Our results can also support researchers in understanding operational aspects of open source SECOs.

**Acknowledgments.** We are thankful to Lakademy 2015 organizers and participants. John McGregor is partially funded by the NSF grant #ACI-1343033.

<footnote n="8">⁸http://softwarelivre.org/fisl17</footnote>
## References

1. Android's Success: by the Numbers. Information Week (2012), http://www.informationweek.com/mobile/mobile-devices/androids-success-by-the-numbers/d/d-id/1103058

2. Global Hadoop Market - industry analysis, size, share, growth, trends and forecast 2012 - 2018. Transparency Market Research - White Paper (2013), http://www.transparencymarketresearch.com/hadoop-market.html

3. 20 Years of KDE: Past, Present and Future. Lydia Pintscher (Editor) (2016), http://20years.kde.org/book/20yearsofKDE.pdf

4. Amorim, S.S., Almeida, E.S., McGregor, J.D., Chavez, C.v.F.G.: Towards an evaluation method for software ecosystem practices. In: Proc. of the 10th European Conference on Software Architecture Workshops. ECSAW '16 (2016)

5. Campbell, P.R.J., Ahmed, F.: A three-dimensional view of software ecosystems. In: Proc. of the Fourth European Conference on Software Architecture. pp. 81–84. ECSA '10 (August 2010)

6. Chung, L., Mylopoulos, J., Nixon, B.: Representing and using nonfunctional requirements: A process-oriented approach. IEEE Transactions on Software Engineering 18, 483–497 (1992)

7. Chung, L., Nixon, B., Yu, E., Mylopoulos, J.: Non-Functional Requirements in Software Engineering. International Series in Software Engineering, Kluwer Academic Publishers (1999)

8. Evangelista, R.: Traidores do Movimento: política, cultura, ideologia e trabalho no Software Livre. Ph.D. thesis, University of Campinas (2010), in Portuguese.

9. H. Robinson, J. Segal, H.S.: Ethnographically-informed empirical studies of software practice. Information and Software Technology 49, 540–551 (2007)

10. Hammersley, M., Atkinson, P.: Ethnography: Principles in Practice. Routledge (2007)

11. Iansiti, M., Levien, R.: Keystones and dominators: Framing operating and technology strategy in a business ecosystem. Harvard Business School (03-061) (November 2002)

12. Jacobson, I., Ng, P.W., Spence, I.: Enough of processes – lets do practices. Journal of Object Technology 6(6), 41–66 (2007)

13. Jansen, S.: Measuring the health of open source software ecosystems: Beyond the scope of project health. Information and Software Technology 56, 1508–1519 (November 2014), Special Issue on Software Ecosystems

14. Komssi, M., Pichlis, D., Raatikainen, M., Kindström, K., Järvinen, J.: What are hackathons for? IEEE Software 32, 60–67 (2015)

15. Mens, T., Claes, M., Grosjean, P.: Ecos: ecological studies of open source software ecosystems (2014), http://pdfs.semanticscholar.org/55d9/b45fbab62fbcb7ec09ef4495103361880419.pdf

16. Passos, C., Cruzes, D.S., Dybå, T., Mendonça-Neto, M.: Challenges of applying ethnography to study software practices. In: Proc. of the ACM-IEEE international Symposium on Empirical Software Engineering and Measurement (ESEM). pp. 9–18 (September 2012)

17. Sharp, H., Robinson, H.: An ethnographic study of xp practice. Empirical Software Engineering 9, 353–375 (2004)

18. Sharp, H., Dittrich, Y., de Souza, C.R.B.: The role of ethnographic studies in empirical software engineering. IEEE Transactions on Software Engineering 42(8), 786–804 (August 2016)