ArticlePDF Available

Abstract and Figures

Software Ecosystem (SECO) comprises third-party developers cooperating and competing when contributing to a platform provided by a central organization (keystone). There are keystones investing in Developer Relations (DevRel) internal team as a global business strategy to attract and engage a critical mass of third-party developers in producing and evolving contributions. For this reason, the DevRel team should promote social relationships among SECO actors and synergy among keystone’ goals and developers’ expectations to survive to inherit changes. However, the understanding of DevRel structure and the way DevRel team can act on a SECO to better engage the developers’ communities establishing a robust VCN (Value Creation Network) remain a challenge. In this article, we advance on the structure for developers' governance from DevRel by proposing and refining a model because of the following research methods: grey literature review, opinion survey, and interviews. The model is called DevGo (DEVeloper GOVernance) and consists of four focus areas, three developer advancement phases, six stages, enablers, and value transfer objects. In addition, a set of 62 lessons learned from DevRel practitioners is associated with DevGo stages.
Content may be subject to copyright.
A Developer Relations (DevRel) Model to Govern
Developers in Software Ecosystems
A Preprint
Awdren Fontão
Federal University of Mato Grosso do Sul (UFMS)
Campo Grande, MS, Brazil
Sergio Cleger-Tamayo
SIDIA Institute of Science and Technology
Manaus, AM, Brazil
Igor Wiese
Federal University of Technology - Paraná (UTFPR)
Campo Mourão, PR, Brazil
Rodrigo Pereira dos Santos
Federal University of the State of Rio de Janeiro (UNIRIO)
Rio de Janeiro, RJ, Brazil
Arilo Claudio Dias Neto
Federal University of Amazonas (UFAM)
Manaus, AM, Brazil
September 20, 2021
Software Ecosystem (SECO) comprises third-party developers cooperating and competing
when contributing to a platform provided by a central organization (keystone). There are
keystones investing in Developer Relations (DevRel) internal team as a global business
strategy to attract and engage a critical mass of third-party developers in producing and
evolving contributions. For this reason, the DevRel team should promote social relationships
among SECO actors and synergy among keystone’ goals and developers’ expectations to
survive to inherit changes. However, the understanding of DevRel structure and the way
DevRel team can act on a SECO to better engage the developers’ communities establishing a
robust VCN (Value Creation Network) remain a challenge. In this article, we advance on the
structure for developers’ governance from DevRel by proposing and refining a model because
of the following research methods: grey literature review, opinion survey, and interviews.
The model is called DevGo (DEVeloper GOVernance) and consists of four focus areas, three
developer advancement phases, six stages, enablers, and value transfer objects. In addition,
a set of 62 lessons learned from DevRel practitioners is associated with DevGo stages.
Keywords First keyword ·Second keyword ·More
1 Introduction
The new dynamic of interactions between third-party users, developers, companies around a common platform
has moved the organizations that maintain software platforms towards expanding their platforms, attracting
communities of developers and meeting the demands of usersKude et al. [2018], Fontão et al. [2018]. This
scenario, which involves technical (e.g. development process), social (e.g. interaction among users, companies
and third-party/internal developers), and business (e.g. synergy surrounded by organizational intentions
and developer expectations) dimensions, has been known as Software Ecosystem (SECO)Jansen et al. [2013],
Manikas [2016].
This work was supported by FACOM/UFMS and CAPES - Financing Code 001.
arXiv Template A Preprint
Organizations such as Amazon, Apple, Facebook, Google, Niantic, Nintendo and Microsoft have invested in
an infrastructure to engage a critical mass of third-party software developers. It can help keystones (central
organizations) in developing and evolving contributions to SECO platformFontão et al. [2015], Steglich
et al. [2019]. An engaged mass of developers also promotes the ecosystem in communities, provides relevant
insights to keystones and sustain a competitive ecosystem. For example, only in the mobile SECO (MSECO)
context, Android has about 5.9 million developers involved in creating mobile applications, technical resources
or developer events (e.g. developer conferences, hackathons) and 2.8 million developers concentrating on
Apple’s iOS
. The developers’ engagement leads to complement the value that the platforms offers to their
costumersSchaarschmidt et al. [2019]. A SECO platform depends on developers because the platform’s
attractiveness is determined by a frequent evolution of its software offeringsBenlian et al. [2015].
There is a need for strategies to support the SECO capacity to increase or maintain its developer communities
over time and survive inherent changesConstantinou and Mens [2017]. In this scenario, the Developer Relations
(DevRel) organizational area emerge as a possible strategy. DevRel can be defined asMeier [2015]: it is
about creating a vibrant ecosystem of third-party developers, by being the interface between those developers
and the platform’s product, engineering, and design teams. DevRel consists of an internal organizational
area that builds relationships among developer communities, partner companies, and the organizationFontão
et al. [2020a]. This area is responsible for creating and communicating technical resources (e.g., APIs, code
samples), planning and performing developer events (e.g., hackathons), and managing developer programs
(e.g., AWS Heroes, Google Developers Experts, Microsoft Valuable Professional), to cite some tasks Meier
[2015]. As part of SECO governance, planning and execution of DevRel activities are not trivial and focus
on delimiting developer actions without excessively restricting the desired level of value creationAlves et al.
[2017], Fontão et al. [2019]. DevRel practitioners need to have a realistic view of value creation and the
DevRel supporting structure within the SECO aiming to meet the needs of developers and achieve keystone
goalsKude et al. [2018], Fontão et al. [2018], Vorraber et al. [2018].
A challenge in the scenario presented above refers to the understanding of value creation networks (VCN)
in DevRel and the governance structure to support DevRel activities. The VCN (Value Creation Network)
considers the exchanges of value among all SECO actors (i.e., developers, DevRel Team and organization).
The understanding of a VCN and a governance structure helps in identifying the mechanisms that deliver
value creation to the SECO actors. A model can be used to support it both to communicate internally to
keystone investments made in DevRel and to better use the critical mass of developers. PiddPidd [1999]
defines a model as: "an external and explicit representation of part of reality as seen by the people who wish
to use the model to understand, change, manage and control that reality in some way". Models are used in all
fields of software engineering, from requirements engineeringHorkoff et al. [2019] to software testingEl-Far and
Whittaker [2002], and also for the comprehension of human interactionsBarricelli et al. [2019], for example.
These models have been used in the way that practitioners and researchers describe: that is either to explore
possible consequences of an action before taking that action or as embedded parts of a system to aid in
routine decision makingPidd [1999].
Therefore, studying a model for developer governance from DevRel is important because it can: (a) Guide
organizations in constructing and evolving DevRel strategies; (b) Help keystones in the understanding and
prediction in a DevRel setting; and (c) Assist researchers and practitioners to structure the mechanisms of
value creation and DevRel, to facilitate the communication of ideas and knowledge on DevRel. Considering this
scenario, in this article we propose a model for developer governance from DevRel, called DevGo (Developer
Governance). DevGo consists of: focus areas, developer advancement phases, stages, enablers, and value
transfer objects. In addition, DevGo comprises a set of lessons learned from DevRel practitioners associated
with DevGo stages and a set of repository categories with a focus on monitoring developer engagement.
This article is organized as follows. In Section 2, we present the concepts regarding SECO, DevRel, and
Value Creation. In Section 3, we discuss the related work. In Section 4, we present the research methodology.
The DevGo model is discussed in Section 5. In Section 6 we present the implications of DevGo model to
theory and practice. Finally, in Section 7, we discuss the conclusions and future work.
2 Background
The relationships that emerge with the evolution of software development, which are composed of components,
infrastructure and services of other companies, moved the scenario of a software product towards a SECO
arXiv Template A Preprint
platformJansen et al. [2013]. ManikasManikas [2016] define SECO as: the software and actor interaction in
relation to a common technological infrastructure, that results in a set of contributions and influences directly
or indirectly the ecosystem. There are roles in the SECO, such as: keystone, developer, and developer relations
team. A keystone is responsible for governing the ecosystem by applying rules and providing infrastructure
to SECO expansionValença and Alves [2017]. A developer produces and evolves contributions to platform
and communitiesFontão et al. [2015], Steglich et al. [2019]. The interactions that occur in SECO among
their elements – from which emerge complex tasks – require the coordinated effort by the organization that
maintains the ecosystem through governance strategies. When a SECO organization is defining governance
strategies, a sustained management commitment is a key enabler for any advanced developer engagement
program. Such management commitment is needed to drive the adaptation to new processes that affect
organizational changeFontão et al. [2018] and selecting appropriate SECO governance mechanisms is not a
trivial taskAlves et al. [2017].
Considering this context, there are also internal keystone employees supporting developers in SECO onboard,
engagement and recognition. These roles are known asKude et al. [2018], Fontão et al. [2016], Oliveira et al.
[2021]: developer advocate, developer evangelists, partner engineer etc., that compose an internal team
called Developer Relations (DevRel). DevRel as the public interface of ecosystem products and platform is
responsible for the critical task of translating developer community interactions into trusted relationships with
the organizationAlves et al. [2017]. DevRel can be understood as a set of instruments to forge and nurture a
thriving community that maintain collaborative relationships between developers and keystoneFontão et al.
[2020a]. DevRel must be conducted in a win-win context: balance between developers’ goals and ecosystem
platform’s valueFontão et al. [2019], Parker et al. [2016]. It affects business and economic features of industry
and the quality of ecosystem platform. In this scenario, SECO actors’ activities are motivated by value
creation towards both the actor and the ecosystemManikas [2016], Vorraber et al. [2018].
Value creation is defined by Bowman and AmbrosiniBowman and Ambrosini [2000] as the difference between
use and exchange of value at several levels of analysis. In our study, we use the framework of Amit and
ZottAmit and Zott [2001] that was proposed to analyze aspects of e-business products regarding the value
creation. This framework has been selected because it provides insights into the value sources on e-business
models. In addition, it is the most cited work in the scientific community on the topic, with about 7,898
citations by January 2021. This framework was used by Hyrynsalmi et al.Hyrynsalmi et al. [2014] to analyze
the value sources in a SECO from the perspective of mobile application developers. CristofaroCristofaro
[2020] also uses the value creation sources indicated by Amit and Zott to analyze the mobile applications’
business models.
A value creation network (VCN) also comprises products and transactions. In this article, “product” refers
to contributions produced or consumed by DevRel practitioners, which involve technical resources such as:
source code, developer events, technical solutions, and engagement in questions/answers portals. On the other
hand, “transactions” refers to exchanges among a keystone, DevRel team and developer community. Amit
and Zott’s framework is composed by four value sources creation: (1) Efficiency: the transaction efficiency
increases as the cost of transactions within the ecosystem decreases. Several mechanisms exist to reduce costs,
e.g., product search costs for DevRel practitioners and developers; (2) Retention: developers are motivated
to engage in transactions continuously and are willing to continue their relationship with the keystone. A
retention situation can result in increased willingness for developers to consume more products from the
ecosystem; (3) Complementarity: it involves the scenarios of grouping multiple products as a way to generate
more value than offering the same set of products separately; and (4) Innovation: the successful exploration
of new products and services, as well as the introduction of new methods of conducting and organizing the
business. Each value source consists of items that allow its operationalization, known as operationalizing
3 Related Work
After analyzing systematic reviews and mapping studies on SECOBarbosa et al. [2013], Manikas [2016],
Franco-Bedoya et al. [2017], Mobile SECO (simply, MSECO)Fontão et al. [2015], Steglich et al. [2019]
and SECO governanceAlves et al. [2017], few developer governance models were found, but none of them
analyzed developer governance models from the perspective of DevRel. Jensen and ScacchiJensen and Scacchi
[2010] examine how practices and processes allow governing open-source projects when brought together and
configured as networks of socio-technical interaction. The evaluated elements can be analyzed at the micro
or macro level. The micro-level consists of resources that developers use to control the project’s work and
contributions. The macro-level consists of the relationship between the project and other ecosystem projects.
arXiv Template A Preprint
The authors carried out two case studies that indicate that there is a need for a developer governance model
that involves the community at the micro and macro levels.
Jergensen et al.Jergensen et al. [2011] investigate the migration of developers within an open-source ecosystem
through an “onion” model that describes the flow of progress of developers within the ecosystem. The
authors identified that the use of collaborative repositories of software projects such as Github and BitBucket
allowed an advance in socialization among developers. The authors indicate that there is a need to identify
and analyze the variety of technical and social effects that arise within the developer community. Qiu et
al.Qiu et al. [2012] conducted a study to identify the governance model from Mac platform developers based
on a logical perspective: ecosystem logic and platform logic. As such, it focuses on the identification of
resources and the environment of the developers. They still investigate the developers’ side and the role of
the organization, in this case Apple, which have an impact on the dynamism and economic dimension of the
developers. The authors point out the need to examine other SECO’ environments, governance policies and
resources, and their impact on developers.
Wareham et al.Wareham et al. [2014] study the governance of a platform as a way to orchestrate a portfolio
of contributions produced by independent and heterogeneous actors that form an ecosystem. The authors
investigate appropriate governance mechanisms to promote a balance between the stability and evolution of
the ecosystem. In this context, the authors contribute to the understanding of the dynamics of an SECO, with
the effective governance project of a platform, and explain tensions resulting from the relationships between
those involved in the ecosystem. The authors suggest studying the different phases of governance evolution.
Sadi et al.Sadi et al. [2015] proposed a generic approach based on the Android and iOS ecosystems to identify
types of developers and derive alternative solutions to design an appropriate collaboration. This study
focuses on the developers’ objectives and decision criteria. However, it does not provide specific guidance on
how these activities can be carried out. To demonstrate the feasibility of the proposed recommendations,
experimentation in real cases is necessary.
Kude et al.Kude et al. [2018] explore the skills for profiles of partnership managers for the governance of
SECO. They discuss how these profiles help to start, grow, and maintain SECO. The authors also discuss
strategies for recruiting, selecting, and training partnership managers for the SECO governance. The identified
competencies involve attention to situations, networking, relationships, and partnership programs. One of
the opinions obtained from the practitioners interviewed in the study is that SECO governance needs to be
structured as a way to reduce costs, and that it will facilitate the organization’s connection with partners
and internal sectors. Although the authors refer to roles that help support governance, as in other works,
the focus is not on developer governance. Vorraber et al.Vorraber et al. [2018] explore a framework to align
objectives between developers and business managers around an open-source and free software project. The
framework, which focuses on project managers, helps to gain insights related to value mechanisms within the
ecosystem. The analysis, through the framework, is made from a project within the ecosystem. The authors
indicate that there is a need to create a holistic view of needs, values, and connections within SECO from the
developers’ perspective, given that they are essential actors for the success and growth of contributions in
This paper is a extended version of our previous workFontão et al. [2020b] about DevRel value creation
networks. In Fontão et al.Fontão et al. [2020b], we advanced on investigating the perceptions of 31 DevRel
practitioners from large, medium and small-size companies based on seven countries about value creation
in DevRel. We found 55 elements of value creation distributed in retention, efficiency, innovation, and
complementarity. Aiming to advance on the understanding of developer governance structure to support
DevRel strategies, we extended Fontão et al.Fontão et al. [2020b]’s study by considering the value creation
elements as part of a DevRel model to govern developer in SECO. The methods applied to achieve this goal
is described in the next section.
4 Research Methodology
Based on what was presented in the previous section, this research aims to investigate and answer the
following question: What are the elements that comprise a model that can be used by DevRel practitioners to
govern developers in the context of Software Ecosystem? The research methodology considering the methods
presented in Figure 1 was conducted based on empirical software engineering guidelines and inspired in Design
Science Research (DSR)Hevner and Chatterjee [2010]. We conducted four cycles of DSR as shown in Figure
1. Regarding the opinion survey, we followed the Molléri et al.Molléri et al. [2016]’s and Shull et al.Shull et al.
[2007]’s guidelines. To search and extract data from Grey Literature, procedures indicated by Garousi et
arXiv Template A Preprint
al. Garousi et al. [2019] were used to review grey literature. Regarding the interviews, we based the plan,
execution and analysis on guidelines proposed by Hove and AndaHove and Anda [2005] and Witschey and
Murphy-HillWitschey et al. [2013].
Our research methodology was defined to construct and refine a model that is supported by empirical evidence.
Such evidence is important in choosing among alternative descriptions, explanations, predictions etc. Shull et
al.Shull et al. [2007] argue that pursuing empirical evidence has the advantage of treating both confirming
and disconfirming evidence as informative. For each cycle of DSR a method was used, as shown in Figure 1,
the research questions and the sections where the methods are discussed are described also in Figure 1. The
model is called DevGo (Developer Governance). In the next sections, the methods used for the design and
refinement of DevGo are presented. To answer the main research question, we defined a set of sub-questions
as present in each section below.
Figure 1: Research Methods applied in this study
4.1 What is the relevance of developer governance strategies for DevRel practitioners?
There is a need for the definition, analysis and evaluation of developer governance mechanisms (e.g. practices,
guidelines, approaches, tools) that support the ecosystem actors in DevRel. Given this point, we prepared an
opinion survey on the relevance of a previously identified set of 42 strategies for developer governance in
SECOFontão et al. [2017]. Such strategies (e.g. practices, processes, methods) were applied in real-world
setting within open-source, proprietary, and hybrid SECO. We analyzed the strategies to each ecosystem type:
open-source, proprietary, and hybrid. Then,
this survey was planned and executed with the aim of
analyzing 42 previously identified strategies for developer governance
in order to
characterize them
respect to
the relevance
from the point of view of
DevRel practitioners
in the context of
governance activities in a SECO. As a metric, we established the percentage of relevant strategies for developer
governance in SECO, i.e. list of strategies consolidated from the initial set or added by the participants.
A questionnaire was proposed to participants in order to characterize their profile in terms of
their experience and the ecosystems in which they work/worked, in addition to the Term of Free and Informed
Consent. The questionnaire was also prepared to assess the relevance of developer governance strategies
in the context of SECO guided by the research question: “What is the relevance of developer governance
strategies for DevRel practitioners? . The Likert scale was used, offering options among: 0 (Irrelevant), 1
(very low relevance), 2 (low relevance), 3 (neutral), 4 (high relevance) and 5 (very high relevance). In addition,
there was an open question “What is your opinion on the presented strategies? Is there any other strategy?”
The opinion survey questionnaire is available at:
Study Participants and Execution
To rank the set of 42 developer governance strategies regarding their
relevance, we contacted a total of 60 DevRel practitioners identified in LinkedIn with the job title “developer
relations” – 18 answered the questionnaire, giving 85% of confidence level according to the Hamburg’s
formulaHamburg [1974] and a response rate of 30%. Considering a convenience sampling approach these
practitioners were selected because they represent part of the population of DevRel practitioners, people
acting within the industry with experience confirmed on their LinkedIn profiles. All of them had worked with
at least one of the following ecosystems: Amazon, Azure, Blackberry, Google Android, Google Cloud, Intel,
iOS, Symbian, watchOS, or Windows. Participants also work/worked in subsidiaries of those organizations in
Brazil, Canada, China, Israel, Mexico, and USA. They had an average of 5 (standard deviation: 3.06) years
of professional experience in DevRel.
Data Analysis
Participants evaluated each strategy based on a Likert scale in which the minimum value
(0) indicates irrelevance, and the maximum value (5) corresponds to very high relevance to support developer
governance. We calculated such relevance based on the participant’s experience and the ecosystem in which
arXiv Template A Preprint
he/she works/worked for. It is necessary to differentiate the practitioners’ answers by assigning a weight to
each participant, considering for example years of work experience and level of experience as wellDias-Neto
and Travassos [2008]. The level of relevance for each strategy was calculated as follows. Each participant has
a weight (Wi) associated, where NumSECO is the number of ecosystems, YExp is the years of experience,
and YExpAll is the years of experience of all participants:
Wi=NumSEC O +Y Exp
median(Y ExpAll)(1)
The answer of each participant is multiplied by its weight. Then, the results for each strategy were added.
Finally, the level of relevance was calculated at a value between 0 and 100% by normalizing the value obtained
in the previous step. For each strategy (j), the value reached in the previous step was divided by the maximum
possible value:
Relevance(j) = T otal(j)
The formula composed by (1) and (2) helped us in analyzing a level of relevance for each strategy. It was
necessary to differentiate the practitioner answers by assigning a weight to each participant, considering
for example years of work experience and level of experience as well. For example, the NumSeco variable
considers the number of ecosystems that the practitioner has worked on. This is important for a broader
view of domains that governance strategies could be applied.
Results and Discussion
We selected 13 strategies (Table 1) that reached a relevance level equal or greater
than the calculated median (74%). The set of strategies based on the knowledge body and evaluated by
practitioners served as the basis for the conception of the initial version of DevGo. Based on participants’
comments, the relevance ranking also helps to establish a more comprehensive view of developer governance.
There is a need to identify a model that involves dynamics of DevRel in a structured (guided more closely
by the organization) or organic (decentralized decision-making, not much direct supervision) way. Another
aspect indicated by some participants was that more effort to adapt a governance model for specific regions
(e.g. Latin America, Europe) is necessary, for example, through partnerships.
Table 1: 13 strategies to govern developers in ecosystems according to their scores in a 0-5 scale of relevance
in the perspective of 18 DevRel practitioners
Rank Strategy Score
1 Analyzing barriers for developers’ participation and potential remedies to them. 90%
2 Establishing partnership models as well as analyzing community monitoring indicators. 84%
3 Analyzing the flow of developer progress within the ecosystem. 80%
4 Identifying market needs to build a well-defined development process. 80%
5 Meeting developers’ needs to maintain absorptive capacity and avoid discouraging them. 80%
6 Using ecosystem’s data and social network to better understand the platform’s technical elements. 79%
7 Increasing developer maturation based on feedback. 79%
8 Analyzing the lifecycle of developers from business and partner management. 77%
9 Developing a system in which the talented developers are chosen and moved ahead based on their achievement. 76%
10 Offering developers’ conferences to allow discussion of directions regarding the underlying platform. 74%
11 Establishing a platform for publication and propagation of error reports, performance measures etc. 74%
12 Facilitating integration among developers and users adding value to the platform. 74%
13 Identifying the community based on the structure, processes, patterns of interaction and performance. 74%
DevGo Conception
The initial version of the DevGo model was conceived from the analysis of the most
relevant strategies by three researchers with knowledge in Software Engineering. They analyzed the full
description of each relevant strategy (Figure 2 - a). To do so, thematic analysisCruzes and Dyba [2011]
procedures and the creation of mind maps were used to extract the main components of the model. The
following thematic analysis steps were performed: 1) Read and re-read opinion strategy data; 2) Generate
initial codes; 3) Combine codes; 4) Analyze how data is supported by themes; 5) Define each theme; and 6)
Decide which themes make significant contributions to the understanding of what is happening in the dataset.
As can be seen in Figure 2, the first DevGo version comprises the definition of developer governance, a set of
arXiv Template A Preprint
15 facilitators, four developer advancement phases (Attending, Onboarding, Contributing, and Recognizing)
including goals for each phase, a set with indefinite number of repositories, and a set of organization’s goals
associated with each phase. The initial version of DevGo is presented in this section to the reader as a way
to position him/her in the study. The model in its final version is presented in Section 5 with all details.
Figure 2: The initial version of DevGo, including an overview of thematic analysis in (a)
This study lead us in the following insight:
The analysis of the relevance of each of the 42 developer governance strategies by the participants
of the opinion survey allowed us to obtain a set of 13 relevant strategies. As such, it was possible
to generate an initial version of DevGo describing the necessary structure to support the developer
governance from DevRel. An important point is that there was a need to refine the model through
the evaluation of DevRel practitioners who work in real developer governance scenarios in SECO. For
this reason, a set of interviews was carried out as described in the Section 4.2.
Threats to Validity
The threats to validity were organized into 4 categories: construct, internal, external,
and conclusion. Regarding the conclusion validity we performed through a simple demonstration of the level
of relevance (or not) of the strategies extracted from the previously identified developer governance strategies.
To support the internal validity it was proposed to select experienced DevRel practitioners who work/worked
at SECO, their profiles are discussed in Section - Study Participants and Execution. As such, it was assumed
that they are representative of the population of DevRel practitioners in SECO and that they can give the
keystone’s perspective on developer governance.
Considering the construct validity the study is characterized by the analysis of the relevance of the strategies
for developer governance in SECO. The strategies were extracted from primary studies, through a systematic
mapping study, involving experiments with developers in SECO. Regarding the external validity the study
participants in general can be considered representative of the population of DevRel practitioners. For
the assessment of the level of involvement in developer governance in the context of SECO, data from the
questionnaire on the experience of the participants were analyzed. The materials used in the study can be
considered representative and current for the problem under analysis. Such materials are formed by the
strategies that are related to the developer governance in SECO.
4.2 What are the elements that make up the structure of a model for developer governance
in SECO?
The interviews were
planned and executed with the aim of
analyzing the elements that make up the
structure of the developer governance model
with the purpose of
refining it with respect to adherence to
a DevRel real scenario
from the point of view of
DevRel practitioners in the context of SECO. To do
so, the following research question was investigated by the interviews: “What are the elements (concepts,
arXiv Template A Preprint
developer advancement phases, facilitators, goals) that are part of the structure of a model for developer
governance in software ecosystems?".
Participants and Execution
To refine DevGo, we conducted semi-structured interviews with 15 expe-
rienced DevRel practitioners. These participants were selected following the same procedure used in the
previous opinion survey (Section 4.1). They had an average of 7 (standard deviation: 2.03) years of experience.
We obtained 27 suggestions related to developer governance that were used to refine the proposed model
A questionnaire was proposed to the participants aiming to characterize their profile with regard to their
experience and the ecosystems in which they work/worked, in addition to the Term of Free and Informed
Consent. A set of questions was defined to guide the semi-structured interviews. The questions cover the
structure of the model and how it adheres to the real scenario of developer governance in ecosystems. The
interview questions (IQ) are: IQ1) Do you agree with the concept and the structure of the presented developer
governance model? IQ2) What is your opinion about adjustments to the concept and the structure of the
developer governance model presented? IQ3) Do you agree with the phases presented that are related to the
flow of developer advancement? IQ4) What are the necessary adjustments in the phases? IQ5) Do you agree
with the developer governance facilitators that are associated with the developer advancement phases? IQ6)
What are the necessary adjustments in the facilitators? IQ7) Do you agree with the stated organizational
goals? IQ8) Is there an objective that has not been presented and an adjustment to the existing ones?
Data Analysis
The analysis of suggestions resulted in the fact that developer governance has a main
pillar: Developer Relations (DevRel). DevRel involves a group of software engineers who are outgoing and
great at public speaking. It considers developer evangelism and advocacy and serves as an interface between
developers and organization’s platform product and technical teams. In this context, evangelism focuses
on promotion and awareness. On the other hand, advocacy prioritizes gathering product feedback from
Regarding the
four suggestions focused on the concept of developer governance
there is confirmation
of the scope of the concept, as the following participant says (participants are indicated as PX, where X is
his/her ID):
The concept presented looks very good and seems to cover most items.” (P1)
However, the concept needs to make clear the importance of considering different developer profiles during
developer governance. Developer segmentation must be taken into account and those specific developer
communities must be fostered through partnerships to enhance niche creation:
You should consider the developer’s segmentation.” (P4)
Another participant (P8) warns that the concept is not well understood among organizations that benefit
from the ecosystem scenario, even considering that he/she understood the concept. Moreover, developer
governance is not known by the developer community within the ecosystem, which is also a comment from
participant P7:
Certainly, the proposed developer governance concept is clear and describes how interaction with
stakeholders should be and how each of them will benefit. I believe that it is not so clear in most companies or
is not known by the network of developers.” (P8)
My only concern is about communicating this model with the developer’s network and what conflict
management would be between, mainly, developers. Despite that point, I think it is a good proposal.” (P7)
Participant P12 indicates that the need to include the Developer Marketing team in conjunction with DevRel
practitioners so that developer governance is possible:
Developer Marketing works in conjunction with Developer Relations, helping to improve content awareness,
providing market research, supporting developer events, and creating consistent brands.” (P12)
Considering the suggestions, the definition of developer governance in ecosystems could be stated as follows:
it is a set of mechanisms (i.e. developer marketing and developer relations - evangelism and advocacy) to
support win-win relationships between a thriving developer community and an organization with the objective
arXiv Template A Preprint
of guaranteeing/monitoring the economic and social well-being of the developers. It is necessary to consider
the developer’s segmentation to maintain the vitality of the ecosystem and reduce costs and risks.
Regarding the analysis of suggestions on the
Model Structure
, the first two suggestions are related to the
structure of the model which in its initial version did not clearly demonstrate the benefits for the organization
and the developers, as well as the sequence and involvement between the elements of the model structure and
the feedback cycle. These can be some of the reasons that also lead to the following perception of participant
P7: “In general, my guess is that the model presented makes sense as a starting point. We present the
comments of the participants on these aspects below:
I would like to see more clearly what are the benefits of the organizational goals (for the organization) and
the benefits (for the developers) - perhaps changing the way it is shown in the image.” (P1)
I understand that there is a sequence that could be evidenced, showing cause and effect 1) Phases (the core
of the model); 2) Facilitators and 3) Goals. It would also be good to highlight the costs and risks that are
mentioned, and how this model is mitigating this.” (P2)
Virtually complete, only the cycle is unclear.” (P3)
It seems that you have almost everything covered with these facilitators, however, this model has to be very
empirical for this to be adjusted in time according to the information collected from the feedback cycle.” (P6)
About the steps from the comment of participant P15, it was possible to realize that it was necessary to
expand the four steps present in the initial version of the model:
The structure we use in our DX sector involves awareness, evaluation, purchase/construction, publication,
routing/advocacy (or something like that).” (P15)
Participant P5 suggested that agile values such as collaboration, ownership, transparency and trust be
incorporated into the model to govern developers within an ecosystem. In addition, the participant P6 was
unable to perceive the connection between the stages, which may indicate that it was not possible to give the
idea of stages of progress of the developer within the ecosystem:
I have feedback on the absence of a clear link between "contributing", "participating" and "acknowledging" on
Github-style social project management and font sharing platform. I believe that making social platforms a
part of "contributing" and "recognizing" is a strong gain in the value proposition. I would like to cite, as an
example of a development environment that does this well, the migration of parts of the Unity engine to
official Github projects to leverage access to contributions from the organization and the community”.
Considering the comments about the value
it conducts us to consider the value creation networks in
the model structure. It can be important to support practitioners in communicating the value of DevRel
activities internally. Developer Relations involve a group of software engineers who are outgoing and excellent
at public speaking, as indicated by participant P13: “DevRel includes technological evangelism, management
of community leaders, training and documentation. The advocacy part works with existing developers, while
evangelism focuses on spreading the organization’s “word”. As a common feature, both advocacy and evangelism
must build trust by helping other departments in the organization”. From the comment of the participant P13,
we consider proposing two pillars within the focus area that deals with DevRel: Evangelism and Advocacy.
As such, DevRel serves as an interface between the developers, the technology and product teams of the
ecosystem. In this context, evangelism focuses on promotion and awareness. On the other hand, advocacy
prioritizes the collection of product feedback from developers.
Regarding the
goals for each developer advancement phase
mentioned in the DevGo model (Figure
2), it was realized from the analysis of the suggestion of the participant P1 that it is necessary to make
clear in the model a better alignment between the organization’s objectives and how this can be present:
“Need to state more clearly what these goals represent for the organization in terms of gain (users, revenues,
visibility etc.)”. Another point refers to the inclusion of objectives that are related to the sale of products and
services of the organization, as indicated by participant P2: “In the Contribution phase, I would include some
goals related to sales, after all, this is the purpose of the organization”. Regarding synergy (i.e. a win-win
relationship between the organization and the developers), it is not clear how it is possible to support such
arXiv Template A Preprint
I think they are good enough, too. It is very important to keep in mind that these relationships must be a
win-win model and, for the developer, what is the real impact of their work and an expectation of being
rewarded at the same level.” (P7)
Moreover, in the attending phase, it is important to publicize, generate material for the organization’s
marketing department and strengthen the organization’s public relations - a refinement perceived from the
comment of the participant P12: “Technological awareness: disseminate, generate leads for marketing, purely
technological public relations”. Participant P14, the most experienced one, reports on the moment when the
keystone’s goal is to evangelize or advocate within the governance of ecosystem developers: “If a company
wants to focus on raising awareness or potentially keeping costs low by participating in fewer activities, so they
can decide to focus on evangelism. Evangelists can focus much more on activities that result in acquisitions,
such as documents, blog posts, sponsoring events, and lectures. See that the mentioned activities can help
raise awareness and contribute. If a company prioritizes collecting product feedback from developers, advocacy
may be the best approach. Lawyers can perform all of the above activities as part of their developer relations
program. In particular, these professionals are more connected with activities that involve the product or
retaining developers”.
These considerations led the model to have Focus Areas
Platform and Products, DevRel
(Evangelism and Advocacy), Developer Advancement Flow, and Monitoring
. It was a way to
better group the organization’s goals and how the developer can benefit from being engaged in an ecosystem.
Thus, it was possible to adjust the relationships between the focus areas. The focus area also strengthens the
understanding of where the organization wants to invest to expand the ecosystem.
Regarding the
suggestions about the developer advancement phases
, there is a need to show a
direction in the flow of the image, as well as the duration of each phase:
The direction of flow in the image can be shown more clearly.” (P1)
Show the temporality of these phases.” (P9)
Regarding the reference phase, participant P10 commented on the scope: “Relationships are two commitments
and represent an investment of time by the influencer. Strategic partnerships with community leaders.
Recognition: developers build recognition and achieve their own goals, leading to positive interactions and
closer relationships”. Still on scope, participant P13 commented on awareness: “Awareness - awareness of
the platform and what it does”. There were also suggestions aimed at a better definition of the elements that
make up the flow of progress of the developer, which involve the importance of each of the elements and new
phases of the flow, as follows:
Integration has a little diffuse concept, not very clear what his role is. Is it a separate organization?” (P6)
Phases: Discovery, Integration, Support and Advocacy. They can be grouped into Launch, Growth, and
Maturity.” (P11)
Considering the comments about the structure and phases
it guided us in refining the names
of each Focus Areas and including Stages associated with each Developer Advancement Phases
As such, the DevGo structure started to be composed of the phases: Beginning, Growth, and Maturity. The
Beginning phase with the stages: Awareness and Onboarding. The Activation and Retention stages are
associated with Growth phase. Finally, the Maturity phase with the stages: Recognition and Reference.
Suggestions regarding facilitators
involve the inclusion of new facilitators
or the presence in another phase of one that has been previously identified.
It supported us in changing the name of Facilitator to Enabler
, since an Enabler can be used to
identify and solve the DevRel practitioner/research problems. As suggested by some participants:
It would include technical support in the integration phase.” (P2)
Impact of training the 4 phases.” (P3)
I agree with the facilitators, with the exception of the aforementioned lack of social project collaboration tools
in the ‘contributing’ and ‘recognizing’ part.” (P5)
There is also a need to describe the benefits of facilitators for developers - not mixing developer governance
activities with channels of communication with the developer:
arXiv Template A Preprint
It looks very good and I don’t see any other facilitator than the ones portrayed. (lacking only clearer benefits
for the developer - for example: what a revenue model, etc. would represent for them).” (P1)
Facilitators should not mix activities and channels.” (P4)
The DevGo was refined and then started covering the aspects indicated by the interviewed DevRel practitioners
representing the keystone’s perspective.This study conducted us in the following insight:
A necessary aspect to refine DevGo is to retrieve experiences acquired in DevRel. As such, lessons
learned from DevRel practitioners were analyzed as described in Section 4.4.
Threats to Validity
Aiming to support the conclusion validity we performed through the analysis of
the model structure guided by the interview questions. Regarding the internal validity it was proposed to
interview DevRel practitioners who work/worked in SECO involved in developer governance. As such, it was
assumed that they are representative of the population of DevRel practitioners in SECO.
Considering the Construct validity the study is characterized by the analysis of the elements involved in
the structure of a model conceived from relevant strategies for developer governance in SECO. Regarding
the external validity the study participants in general can be considered representative of the population of
DevRel practitioners. To assess the level of involvement in developer governance in the context of SECO,
data from the questionnaire on the experience of the participants were analyzed.
4.3 What are the lessons learned shared by DevRel practitioners for developer governance?
According to PMBOKBayona et al. [2018], a lesson learned refers to the experience acquired during a project.
Registering, documenting, and especially, disseminating the lessons learned is a way of preventing such
problems from recurring in future projects. This scenario is also applicable to the developer governance in
SECO through DevRel activities. In the case of this study, lessons learned are related to each stage present in
DevGo. Lessons learned can be used by DevRel practitioners to help third-party developers advance within
the ecosystem and mitigate possible risks.
As a way to find lessons learned reported by DevRel practitioners, Medium
was chosen as an experience
sharing repository, as it is also a space where DevRel practitioners share their experiences resulting from
developer governance activities. A mapping (Grey Literature Review method) of lessons learned on Medium
articles was planned and executed
aiming to
identify the lessons learned from DevRel
in order to
in respect of
developer governance
from the researchers’ point of view in the context of
Search Strategy and Data Extraction
The procedures indicated by Garousi et al.Garousi et al. [2019]
were used to review grey literature to search and extract data. The source for this study was Medium, which
is an environment for sharing stories, perspectives, and ideas through articles. Within Medium, the following
search string was applied: “developer relations”. The inclusion criteria were defined as: (1) The article share
the lesson learned, concept, or strategy (technique, methodology, approach, framework) or within the DevRel
area; (2) The article is written in English; (3) The author of the article has proven experience in DevRel
through profile analysis on Linkedin. Any Medium article that did not meet all inclusion criteria should be
excluded. To employ specific criteria to assess the quality of the GLR, based on Zhang et al.Zhang et al.
[2021] used the practical experience of the article authors measured in years of experience in the subject (in
our case, DevRel). And also as indicates by Garousi et al. Garousi et al. [2019] we analyzed the authority,
confirmed by the profile on LinkedIn of each article author.
The interest in understanding developer governance, from the point of view of DevRel, is growing in the
industry. After running the search string, it was possible to find 167 Medium articles by DevRel practitioners.
From these articles, after applying the inclusion criteria, 132 articles were selected for analysis and extraction
of the lessons learned. The article filtering process went through peer review with three experts in Empirical
Software Engineering, Software Ecosystem, and Systematic Literature Reviews. At the end, 267 lessons
learned were extracted from the articles related to the report of lessons learned from DevRel in actions that
refer to developer governance.
arXiv Template A Preprint
Data Analysis
To synthesize the set of 267 lessons learned, thematic analysisCruzes and Dyba [2011]
procedures were used to classify the lessons in categories that represented the stages of the DevGo model:
awareness, onboarding, activation, retention, recognition, and reference. Similar lessons learned were grouped
together to form a single one. Thus, a total of 62 lessons learned were reached: 27.5% for awareness (17),
17.7% for reference (11), 17.7% for recognition (11), 16.1% for retention (10) , 11.3% for onboarding (7), and
9.7% for activation (6). The set of lessons learned is presented throughout the description of the current
version of the DevGo model (Section 5).
The study on the identification and analysis of lessons learned in DevRel to govern developers leads to the
understanding that the industry has also invested in a knowledge body in the field. It is also possible to see
from the analysis of the recommendations that there is no structure in which the developer governance within
ecosystems is discussed. The vast majority of the practitioners’ experiences are related to the awareness
stages, i.e. to communicate the benefits of the ecosystem as a way to attract developers. Of course, there are
experiences in each of the other stages that are indicated in DevGo, but lessons learned on awareness are
most discussed in the industry.
With this study the DevGo has been refined to consider lessons learned associate to each stage of developer
advancement phase. The set of 62 lessons learned is described in Section 5. This study guided us to the
following insight:
An important point also identified in the opinion survey (Section 4.1) and in the grey literature review
is the understanding of the Value Creation Network (VCN) involved in DevRel within the ecosystem.
The study on the perception of value is described in the next section.
Threats to Validity
Considering the conclusion validity it was carried out by analyzing the set of Medium
articles. The article should address some lessons learned for developer governance and be written by a DevRel
practitioner. As a way to support the internal validity the lessons are based on the experience of DevRel
practitioners involved in developer governance. Thus, it was assumed that the lessons and practitioners are
representative of the population of DevRel practitioners in SECO.
Regarding the construct validity the study is the identification and analysis of the lessons learned involved
in the stages of the developer governance model. For conducting the analysis of the lessons, procedures
indicated, respectively, by Garousi et al.Garousi et al. [2019] and Cruzes and DybaCruzes and Dyba [2011]
were applied. The stages of the model conceived from relevant strategies for the developer governance in
SECO went through opinion survey and interviews by experts in the field. Aiming to support the external
validity the participants and lessons learned are considered representative in relation to the population of
DevRel practitioners. The lessons were also analyzed in relation to the stages of the model, which represent
the real flow of engagement of a developer within an SECO, as indicated by practitioners in previous studies.
4.4 What is the perception of DevRel practitioners about value?
This method considers a qualitative approach that guides us to the understanding on how the DevRel
practitioners perceives the value creation during their activities. Then, a set of semi-structured interviews was
conducted with practitioners from DevRel area.
The purpose of the interviews was
to analyze a set of
with the purpose of
characterizing them
with respect to
value creation perception in DevRel
from the point of view of
in the context of
DevRel activities for developer retention
in SECO. The research question that helped us to reach our goal is: “What is the perception of DevRel
practitioners about value creation and how it can be operationalized?”. Prior to starting the interview, we
explained the goal of the research and asked for consent to record the audio from interview. All participants
were encouraged to speak freely while answering the questions. We conducted the semi-structured interviews
via Skype or Google Hangouts with participants.
As a first step, the participants were asked about their experience regarding their education, role in DevRel,
the ecosystem in which they work/worked, and the size of the organization they work/worked for. Then,
we asked the participants using the following questions: (1) In your opinion, what is Developer Relations
(DevRel)? (2) How do you perceive the value creation in DevRel? (3) What are the suppliers and consumers
of value creation in DevRel? Each interview took approximately 40 minutes. In all interviews, we took notes
to facilitate our analysis. All interviews were recorded. At the end of each interview, notes were discussed
with the respective interviewees aiming to ensure they reflected what was discussed during the interviews.
arXiv Template A Preprint
Study Participants
To participate in this study, 97 DevRel practitioners identified on LinkedIn with the
job title involving the term “developer relations” were contacted – 31 demonstrated interest to be interviewed
(in this study, they are represented as P01 until P31). All participants work or have worked with at least one
of the following SECO: Android, iOS, Nokia, Windows, Actions on Google, Amazon Web Services, Facebook,
Google Cloud Platform, IBM Cloud, JVM, Linux, Maemo, Microsoft Azure, OSX, Shopify, Twitter, and
Unity. They also work in subsidiaries of those organizations in Brazil, Canada, China, Germany, Israel,
Mexico, and UK. The interviewed participants include heads, managers, developer evangelists, developer
advocates, and developer program engineers.
The participants have an average of 4.8 (standard deviation: 3.26) years of professional experience at DevRel.
On average, they planned and performed 44.8 (standard deviation: 64.30) events (e.g. hackathon, training
sessions, developer conference, meetups) with developers as part of their DevRel activities. Considering the
size of the organizations in which they are employees, we had the following scenario: 15 (48.39 %) work in
large companies, 10 (32.26%) in medium companies, and 6 (19.35%) in small companies.
Data Analysis
In this study, we performed a thematic analysis from DevRel practitioners’ comments who
participated in the study. The method was applied over 31 DevRel practitioners’ interview full transcription
documents. The following steps were performed by five researchers with experience in SECO and qualitative
data analysis (at least 5 years): (1) Read and re-read interview data: two researchers read the interview
transcripts to verify for consistency with the audio files; (2) Generate initial codes: three researchers analyzed
participants’ comments. The framework of Amit and ZottAmit and Zott [2001], which deals with aspects of
value in business, was used as a basis. It helped to extract 54 fragments of comments. These fragments were
associated to the items that operationalize the value sources indicated by Amit and Zott, 19 (35.2%) of these
fragments were classified as related to “Retention”, 12 (22.2%) to Efficiency, 12 (22.2%) to Innovation, and 11
(20.4%) to Complementarity; (3) Combine codes: by conducting a consensus meeting, the five researchers
reviewed the codes using the guideline proposed in Amit and Zott’s framework. In this step, the researchers
discussed about the suppliers and consumers. The next steps helped in the discussions related to suppliers,
customers and insights focused on the value creation network: 4) Look at how data is supported by themes;
5) Define each theme; and 6) Decide which themes make meaningful contributions to the understanding of
what is going on from the dataset.
Results and Discussion
In the next sections, we present each operationalizing item related to value source.
Then, we discuss the DevRel practitioners’ comments and the elements that compose the operationalizing
items. We also describe for each DevGo’s focus area their suppliers, consumers and value creation transfer
objects in Section 5.
The retention operationalizing items from Amit and Zott’s framework are: Loyalty Program,
Confidence, Customization, Contact Point, Virtual community, and Network Effect. The identified items
in the 19 retention comments’ fragments are distributed as follows: 5 (26.3%) for Contact Point, 4 (21.1%)
for both Loyalty Program and Confidence, 3 (15.8%) for Network Effect, 2 (10.5%) for Virtual Community,
and 1 (5.2%) for Customization. Regarding the
Contact Point
, the practitioners’ comments cover the good
relationship between DevRel practitioners and the developer. This makes it easier to understand developer
expectations. The construction and maintenance of a good relationship can be identified as a DevRel pillar,
because DevRel team acts as a bridge among developers, keystone and other SECO actors.
It’s a good relationship between evangelist and developer. (. . .)” (P13)
Another identified element is the DevRel practitioner’s ability to empower their technical audience by
understanding their needs and expectations to provide a flow of developer advancement in the SECO.
(. . .) And that defines how you need to approach your audience, how you need to be present for your
audience, but also the expectations you can set with them and the understandings you have when working with
them.” (P17)
DevRel’s practitioner action should bring the developer closer to the product as a way of getting feedback.
The feedback also leads to understanding the probability of a developer recommend SECO platforms or
resources to another developer.
(. . .) This is where you ask someone who has subscribed to the likelihood of recommending your service to
someone else.” (P25)
arXiv Template A Preprint
Contact Point
also allows the DevRel practitioner to keep the developer closest to the keystone
perceiving developer’s expectations and producing what it really needs.
Keep them excited by giving them value through new opportunities, and if that value will return to you.
As a way to foster the link between developer and DevRel, this team can offer official gifts (e.g. gadgets,
vouchers, shirts) to create an identity of developers with SECO platforms. Such official gifts are part of a
DevRel budget provided by keystone.
Keep them excited by giving them value through new opportunities, and if that value will return to you.
Engage developers during events by offering them shirts and then dragging them to a computer and giving
them a demo, not to wrap them in the product, but to get their product feedback.” (P23)
Loyalty Program
comments indicate the value of the official recognition of the developer by the
keystone as a way to drive their engagement.
Public recognition. Praising some specific developers in your media can be a big boost to your ego and your
business ...” (P24)
The value is still linked to long-term relationships within the ecosystem. The intensity and duration of
developer engagement are important to DevRel demonstrates the maturity of SECO.
. . . Building long-term community relationships, which is an essential aspect of the approval economy.
It leads to a community of experts who in addition to generating relevant contributions can serve as support
to DevRel team for other developers.
When developers can increase your value, reach and recognition by developing your platform and growing
your audience, they will be much more dedicated to you and your brand ...” (P30)
The developers need to realize that keystone supports them within the ecosystem. The access to developer
programs as software beta access programs, advanced SDK and APIs, testing tools and app analytics, e.g.
provide the developer with what is needed for this perception. In developer programs, DevRel practitioner
rewards products’ continued use or purchase.
Especially successful or innovative apps deserve a pat on the back, so take one and let your developers know
you’re paying attention. Create and communicate the availability and access to technical developer programs.
Regarding the
Confidence item
, the comments indicate the credibility of DevRel practitioners as a relevant
value. Credibility can be related to technical knowledge and experience; budget and community management;
or ability to conquer developer community respect. A keystone must structure, maintain and monitor a
DevRel team with valid credibility.
(. . .) Engage with credibility, even if it means recommending a competing solution.” (P28)
(. . . ) It’s about building trust with developers (. . . ).” (P3)
As a result of trusting in companies that comprise the ecosystem in the work of DevRel practitioners, it is
the interaction between the most experienced developers with the industry partners.
Presentations for industry peers. An e-mail about that seasoned developer - with appropriate shared-contact
information - can go a long way in creating good feelings.” (P24)
The scale and size of communities of the ecosystem are values that aid in the reliability of other developers,
as a SECO only remains sustainable and growing with actors and interactions that enable it. The scale and
size of communities are also related to, for example, resources availability, developer evolution, developer
events to specific niches.
arXiv Template A Preprint
(. . .) Another point is in scale and size. So talking about the size of our ecosystem is a point of reliability
(...)” (P19)
The comments of
Network Effect
item focus on actions that allow face-to-face and web-based contact with
the developer community, such as seminars, developer conferences, hackathons, events, tool demonstrations,
and webinars. These methods can help in increasing the number of developers in an organic way (without
the initial contact with a DevRel practitioner).
Seminars, spoken events, webinars, demos - whatever you do to get your attention to the world, invite some
developers to share the spotlight and help explain things as they expose themselves (...)” (P24)
The planning and execution of these developer events involving developers in conjunction with DevRel
practitioners in community outreach is valuable.
They want to go there and teach the world why it’s so good.” (P26)
The scenario discussed above drives developers themselves to act as ecosystem ambassadors that support the
expansion of DevRel’s actions primarily to attract more developers. The ambassador can be understood as
an official role of a third-party developer with recognized contributions for SECO that can act as part of
DevRel team operations.
(. . .) constructing a ambassadors’ network – within the third-party developers’ community – directly
associated to me. It can help me to support more developers to enter the market.” (P2)
Regarding the
Virtual Community
item, the participant P07’s comment strengthens the use of the
community to foster the establishment of a robustness network involving developers and other ecosystem
actors. It strengthens the DevRel practitioner’s work by broadening the action, as suggested by participant
P26: “And so they become part of their community and become part of their broader developer relationships
than that you can achieve”.
Regarding the
Customization item
, by the concept of a SECO, one of the main goals is to expand
the platform, which includes a SECO platform customization supported by developers’ contributions The
participant P22 commented that the value around customization is to allow new products to be created
through infrastructure: “Helping developers build software for customers using the APIs and ensuring they
can make a living from these projects is very satisfying”.
The identified items in the 12 comments’ fragments are distributed as follows: 5 (41.7%) to
Selection Range, 4 (33.3%) to Symmetric Information, 2 (16.7%) to Simplicity, and 1 (8.3%) to Search Cost.
In relation to the
Selection Range
item, the practitioners’ comments indicate as value the resources desired
by developers that can help them in generating monetary transactions during the use of SECO products.
When someone pays for your product, your motivation is to get the desired resources so that they pay for the
product. And your main challenge is to find out what they are.” (P17)
The resources desired by developers can indicate their engagement and the possibility of evolving contributions.
So, another point is the set of contributions developed by developers that are promoted within the SECO.
Promote your apps. Driving app downloads creates a lot of value in terms of developer relationships and
also helps to sell your platform.” (P24)
In order for the desired resources to be offered and products to be promoted, an aspect that helps and is
valuable from the point of view of the participants is the technical training of the developers. Technical
trainings involving SECO technologies can be considered as a main activity of a DevRel team.
Focuses on training developers to take advantage of our APIs ...” (P22)
Technical training.” (P5)
Symmetric Information
item addresses aspects related to the DevRel area as an articulating agent for
the flow of information about ecosystem products among DevRel practitioners, organization, and developers.
It favors communication and trust around information produced by developers based on DevRel’s actions.
arXiv Template A Preprint
There are many moving parts (engineering, PM, marketing, professional services, business development,
etc.) and DevRel is the grease that keeps the machine moving.” (P12)
Strong communication and trust.” (P13)
Awareness about ecosystem products for all possible people interested in the use and expansion. In order to
favor this expansion, the production and availability of qualified content for the SECO is necessary.
(...) increasing awareness about your product.” (P28)
(. . .) It is quality content that can help a developer to grow (...) helping the developer learn more efficiently,
providing maximum value to him.” (P22)
Regarding the
item, comments indicate the communication of the organization’s vision and
expectations as well as clarity about the robustness of the ecosystem.
In fact, selling the vision and expectations around the platform to customers. Thus, sales are the first point
of contact for customers and they need to understand the vision of their platform.” (P19)
... you need to be clear about how to go back if there is a problem.” (P16)
The organization’s vision and expectations can be used to establish a synergy among developers, DevRel and
SECO actors. In this context, the robustness of an ecosystem is important because it sustains the developer
communities around the SECO platform.
The identified items in the 12 comments’ fragments are distributed as follows: 5 (41,6%) to
Process and Transactions Restructuring, 3 (25%) to New Content, and 2 (16,7%) both to New Features
and Migration. Regarding the
Processes and Transactions Restructuring (PTR)
item, practitioners’
comments cover the value of DevRel as an essential area in the organizational structure, which helps the
organization to focus on costs and also on the organization’s maturity.
You need to focus on the cost.” (P16)
... the maturity of the company, the maturity of the product, the amount of adoption you are gaining in the
community, this will change your strategies and shape the way you think about things.” (P27)
It is completely necessary for the development team, for the project managers, for the daily actions and
mainly for the delivery of the product.” (P6)
The DevRel area directly impacts the developer experience (i.e. the expectations and perceptions generated
from the use of ecosystem products). Moreover, DevRel generates revenue through the use of services and
helps with brand recognition. So, it should be inserted strategically as part organization’s business.
(...) are a market entry strategy, the developer’s experience is a function of the product and should be
measured as a business unit.” (P29)
Generating revenue through the use of your service or perhaps it is implied because you are creating brand
awareness for some” (P16)
Regarding the
New Content
item, the comments explore the availability of free content to developers, new
contributions from developers to the ecosystem and new services for developers that are generated from their
The content can be provided to developers at no cost to them.” (P22)
Deliveries produced by developers participating in a program.” (P10)
People are now consuming more of their operating system, which is generating more services.” (P16)
In relation to the
New Features
item, the value aspects are related to the contribution to existing products,
contributions from extensions to free and paid products. It can support the development of derived products.
arXiv Template A Preprint
... deliveries produced by developers participating in a program.” (P10)
Someone buys your product and then it develops ...” (P21)
Regarding the
item, the participant P15 mentioned that it related to have active developers
in the ecosystem. The active developers are starting their participation in a SECO. So, they are involved
in an onboard phase. The participant P22, as described below, mentions new opportunities that allow the
developer to advance within the ecosystem.
Helping them to create businesses that take advantage of the opportunities that exist in our technology.
The identified items in the 11 comments’ fragments are distributed as follows: 5 (45,5%)
to Products and Services, 3 (27,3%) para Activities, 2 (18,2%) to Technologies, and 1 (9%) to On-line and
Off-line Resources. Regarding the
Products and Services
item, the practitioners’ comments cover the
financial investment of the developers in the resources offered by DevRel team and by the organization’s
products/services. It can provide Accurate information about SECO roadmap so that developers can tailor
their needs.
It’s about the developers’ return and the investment with more money on their part.” (P21)
They are excited to be associated with someone who provides them with accurate information about their
needs in relation to a company’s product launch.” (P28)
The scenario presented above may allow us to understand what the organization expects from the DevRel
area and the developer community. Open source products were also mentioned as a value. Another aspect
addressed refers to data generated by the use of products and services to understand what developers want
and how they use ecosystem resources.
Data on how well our product does, what people want, open source developers. You just want people to use
things so that you can show that you have value.” (P27)
The most important step for anyone who is a DevRel professional is to really understand what your
company expects of you and what it is that you can bring to your community.” (P17)
Regarding the
item, the analysis of practitioners’ interview data covers the balance for actions
with different types of developer communities.
It is about balancing the needs of reaching out to developers and working with the free and open source
developer communities.” (P17)
Another perception of value and activities is to contribute to other products in the ecosystem. The DevRel
team still connects developers in a scalable way to ecosystem products.
The idea is that you create users for some other product through a DevRel strategy.” (P21)
It connects developers to the product in a scalable way.” (P11)
Regarding the
item, the comments indicate the combination of technologies from a SECO
in the contributions of the developers. This fact creates differentiation for the market by attracting users
and creating niches within the ecosystem. As such, developers increase their reputation by creating new and
competitive products in a highly competitive environment.
Threats to Validity
The first threat relates to the number of participants. As we got 31 interviewees, we
cannot generalize our results to all DevRel practitioners context. Therefore, there is still a need of expanding
this research by including a larger number of participating practitioners. Another aspect involving the
qualitative data analysis is that it is not possible to use statistical arguments for generalization of any results.
However, it is important to stress that the participants had roles in which they could use their expertise to
assess the perception about value creation in DevRel. The third threat refers to the subjectivity of the data
classification, since the qualitative analysis that was performed. We used the thematic analysis procedure to
mitigate such threat. The researchers have large experience in SECO and qualitative data analysis.
arXiv Template A Preprint
DevGo Refinements
With the result of the comments’ analysis, an expansion of the value framework
proposed by Amit and Zott Amit and Zott [2001] was carried out. The extension of the framework with the
value perception in DevRel allowed to refine the DevGo model (related to the business dimension) and the
value transfer objects. The operational items identified for each source have been improved the value transfer
objects of the DevGo model.
5 The DevGo model
DevGo (Developer Governance) consists of a model composed of structural elements and a set of lessons
learned for creating and maintaining a successful ecosystem for the central organization (keystones) and
developers. SECO keystones can benefit from DevGo to learn what elements of the model structure have
been addressed, helping to identify lessons learned and favoring collaboration and competitiveness. As such,
they will be able to gain an insight into the adequacy of their developer governance model. DevGo, as
shown in Figure 3, is composed of
Focus Areas
, which indicate the areas that a keystone needs to take
care of to govern developers and maintain DevRel standards. Each focus area has at least one organizational
goal. A focus area can be composed by
. Each of these phases is related to the change in developer
advancement within the ecosystem that is driven by a set of steps to be taken. Each phase consists of
which comprise a period to improve the developer skills. A stage is formed by an objective, a set of enablers
that allow the relationship with the developer, a milestone of the stage that represents when the developer
can leave that stage, and a set of lessons learned.
The model comprises
Four focus areas: Platform and Products (Section 5.1.1), DevRel (Evange-
lism and Advocacy) (Section 5.1.2), Developer Advancement Flow (Section 5.1.3), and, finally,
Monitoring (Section 5.1.4)
. These focus areas help to support a structured and/or decentralized (organic)
approach to developer governance from DevRel. The
set of arrows in the model represents value
transfer objects
between the focus areas. For each focus area, which is described in the next sections,
maps with the Value Creation Networks (VCNs)
are presented where it is possible to identify some
of these transfer objects between the focus areas. Value transfer objects are mechanisms for creating value to
generate and distribute value to the entire ecosystem based on innovation, investments, and cost-sharing.
Figure 3: DevGo Model
5.1 Focus Areas
5.1.1 Platform and Products
This focus area aims to
provide information and resources that support an organization’s goals in terms
of productivity, niche creation, and quality of contributions. It comprises the platform, infrastructure,
arXiv Template A Preprint
budget, products (e.g. APIs, SDKs, IDEs), and services of the keystone, since an organization invests
in an ecosystem to attract users to consume its products. The keystone’s vision and incentives can be
stored in proprietary repositories, such as mobile app stores and developer support portals (e.g. Android
Developers). Moreover, they can make use of open-source repositories to favor a social coding environment. In
Figure 4,
the value transfer objects
that are consumed and provided by this focus area are shown.
focus areas consumes
DevRel (Evangelism and Advocacy) objects that are related to the credibility and
articulation capacity of DevRel professionals, maturity and organizational structure, as well as objects related
to costs, services and products. In the Developer Advancement Flow area, objects that deal with the financial
profile of the developers and the recognition/recommendation of the platform and its products are consumed.
The objects consumed in the Monitoring area help to describe characteristics and perceptions of the developer
communities and ecosystem products/services.
This focus areas provides
to DevRel (Evangelism and
Advocacy)accurate information about the ecosystem roadmap and infrastructure that supports developers
and the DevRel team, as well as developer programs. To Developer Advancement Flow are provided new
products and the capacity to support inherent changes. And all the products, organizational vision and
expectations, technical patterns/documents are provided to Monitoring focus area.
As an example of actions within this focus area, we can highlight the support portals for developers (e.g.
Android Developers, Apple Developer), which have information about tools, available resources that support
the development, and products focused on users of the platform devices. It is important to make it clear that
this area is strongly focused on what the organization has as a vision concerning its business.
Figure 4: Value Transfer Objects - Platform and Products
5.1.2 DevRel - Evangelism and Advocacy
This focus area aims to
help incorporate potential contributions (i.e. complementary products, services,
and innovations) that arise from developers to the ecosystem platform in the Platform and Products focus
area. It helps to maintain a balance between the expectations of the developers and the needs of the keystone,
including balancing the organization’s internal roadmap with the needs of developers.
This area is composed of evangelism and advocacy. The advocacy part works with existing developers, i.e.
with the gain of interest and the loyalty of potential developers. This is done through quality and specific
content for these developers. The advocacy part is related to the stages of retention, recognition, and reference
within DevGo. Evangelism focuses on spreading the organization’s “word”, i.e. prospecting for developers,
influencing external developers. The evangelism part is associated with the stages of awareness, onboarding,
and activation of DevGo. As a common feature, both advocacy and evangelism must build trust between
sectors of the keystone and developers.
In this focus area, the appropriate resources, such as open-source components and tools, are provided to
support developers, dividing an organization’s goals according to the different target audiences. These
resources and tools are developed based on organizational guidelines that include platform specification,
emerging ideas, best practices, technologies, development and marketing tools, quality criteria, and user
interface design. The value transfer objects that are consumed and provided by this focus area are shown
in Figure 5.
This focus areas consumes
from Platform and Products all the organizational objects that
support the alignment among internal areas and DevRel team. From Developer Advancement Flow consumes
arXiv Template A Preprint
all the information about developers’ communities as their contributions. From Monitoring focus area, the
DevRel consumes the desired resources and data related to developers’ interaction and the use of products.
This focus areas provides
to the Platform and Products area the objects that inform about the DevRel
team’s credibility, desired resources and tools by developers, and also innovations generated by developers
from the ecosystem platform. To the Developer Advancement Flow are provided objects involving, for
example, the technical specialization of developers, gifts, developer events, and official tools and resources to
support in creating/evolving developer contributions. This area provides the Monitoring area accessible and
free technical and non-technical content.
Figure 5: Value Transfer Objects - DevRel
5.1.3 Developer Advancement Flow
This focus area aims to
support the monitoring and analysis of the progress of developers within the
ecosystem. Understanding how developers are moving and generating contributions within the ecosystem is
important for an organization to direct its action strategies to govern them. If there are many developers
with problems to enter the ecosystem, the organization will experience activation and retention problems, e.g.
stages necessary for generating quality contributions. Figure 6 presents the objects that help in the transfer of
value in this focus area (those consumed and those provided by the area).
This focus areas consumes
Platform and Products new products and a robust infrastructure. From DevRel (Evangelism and Advocacy)
area consumes objects related to recognition, interaction with community and technical/non-technical
documentation. From Monitoring area consumes developers’ interaction data and free technical/non-technical
This focus areas provides
to Platform and Products the developer’s financial information, the
revenue generated and recommendation probability. To DevRel (Evangelism and Advocacy) are provided
objects involving the community of experts, ambassadors, new and competitive products, for example. This
area provides to the Monitoring new contributions, and the evolution of existing contributions and developers’
Specifically in this area, there is a set of phases, as explained in the model structure (Figure 3), which are
described later. There are three phases to support the progress of the developer and these phases consider
business models and partnership management. Thus, there are the following phases: Beginning, Growth, and
5.1.4 Monitoring
This focus area aims to
serve as a strategy to monitor developer engagement, supporting transparency
for both the organization and the developers. As such, it is possible to ensure that everyone has a chance
to understand and provide feedback. Besides, it features mechanisms for storing data about developers’
contributions and interactions. It helps to promote the feedback cycle to adapt the developer governance
strategies in the Platform and Products focus area and in DevRel (Evangelism and Advocacy).
This focus
area is composed by the following repositories
(this set of categories was investigated in a previous
arXiv Template A Preprint
Figure 6: Value Transfer Objects - Developer Advancement Flow
exploratory studyFontão et al. [2019]): (1) Questions and Answers: it keeps questions and answers around
problems and technical solutions described by developers (e.g. Stack Overflow); (2) Mailing List and Forums:
it stores discussions around any issue related to ecosystems (e.g. Android Developers, Apple Developer and
Discourse); (3) Social Coding Environment: it group projects, sample codes, defects and other artifacts
(e.g. Github and Gitlab); (4) Social News Website: it stores information about news shared by users in
sub-communities (e.g. Reddit and Hacker News); (5) Social Networks: it is comprised by social interactions
tools that involve content such as images, texts, videos and emoticons (e.g. Facebook and Twitter); (6)
Team Communication: it involves communication tools that integrate information between teams and help
to organize better (e.g. Confluence, Gitter, Slack, Telegram, Discord and WhatsApp). (7) Apps Store: it
stores software products that can be downloaded and reviews by uses. It is a source of information about the
quality of ecosystem’s products (e.g. App Store, Google Play). (8) Developer Dashboard: it is the developer
portal that support the submission of new contributions to the Apps Store it also mantaing a catalog of
technical resources (e.g. Android Developers and Apple Developer.
This focus area allows DevGo to have a two-way communication channel, providing information about
knowledge and experience from the bottom-up and top-down directions (feeding all the focus areas). The
repositories support the alignment between local ecosystems (e.g. a specific community in South Africa) and
the global developer ecosystem. The value transfer objects for this focus area, which consumes and provides
value for all other focus areas, are described in Figure 7.
This focus areas consumes
from the other
three focus areas all information and data related to developers, organizational goals and products/services.
This focus areas provides data, information and insights involving the interactions among DevRel team,
developers, users and products/services as also contributions.
Figure 7: Value Transfer Objects - Monitoring
5.2 Phases, Stages and Enablers
Each phase comprises a set of Stages
of Developer Advancement.
Each of these stages contributes
to a feedback loop
that increases both the organization’s knowledge of SECO and the developers. This
feedback loop supports the keystone as well as the developers, through problem-solving and risk reduction
(cooperative situation). The feedback loop consists of the continuous exercise of gathering the perception-
arXiv Template A Preprint
s/expectations of the developers and facilitating their response. This response can be made either by the
keystone, through the DevRel practitioners, or by the developer community.
Each stage is associated with a set of enablers
. Enablers are organizational mechanisms associated
with each stage of developer progress to help developers achieve their own goals. Training is a enabler
common to all stages that make up DevGo, since it is one of the main mechanisms for training developers
and exchanging knowledge between DevRel practitioners and developers. At each stage, there is still a
that may be one of the indications that the developer has already gone through a certain stage
and will advance to the next stage.
5.2.1 Beginning Phase
At this phase, the developer learns about the culture, customs, and realities of the ecosystem. It is the stage
of the decision to participate in the ecosystem. The developer is inserted in the context of the platform,
products, and the community of developers and users of the ecosystem. At this stage, for example, information
about the installed user base (e.g. users who are actively using the products around the platform), devices,
and development tools available is important. To do so, this phase involves two stages: Awareness and
Onboarding. The beginning phase involves the work of evangelism by DevRel practitioners.
Awareness Stage
At this stage, the keystone, through its DevRel team, must show the developer that
the ecosystem is attractive to his/her expectations. This awareness can also happen through the following
enablers: product roadmap, events (hackathons, conferences, lectures, meetups), and social media.
: Advertise roadmap of devices to be launched on the market and development tools; Attract developers
through conferences, hackathons, lectures, social networks and advertisements; Communicate adjustments on
the platform; and Involve technical leaders and developers who act as influencers within the ecosystem.
The milestone that indicates that the developer has already gone through
this stage is when a developer joins the ecosystem through registration (i.e. registration on a developer
portal or registration for submission of contributions).
In this stage, there is a set of 17 lessons learned:
Publicize events (social media). To do so, create a value proposition matrix - for developers,
organization and community. Events are similar to a product, rather than a single “activity”.
Determine whether It helps support and increase your organization’s goals;
(LL2): Define a structured approach to advanced learning, e.g., tools such as Udacity can be an attempt;
Encourage online discussion groups to discuss new products. Podcasts, blogposts, newsletters are
good for sharing a message. It is critical to understand the developers want to improve their developer
products. You will quickly discover the main pain points;
Plan educational initiatives such as coding labs, workshops, hackathons, webinars etc. Allow
additional planning time if the event happens during a busy time of year;
Create segmented mailing lists based on experience and interest. This will help to personalize emails
and information favoring the creation and support of various niches. This will facilitate your quick
response to the developers;
Perform live coding when conducting a lecture as it is an amazing way to show how easy it is to
implement and use a particular SDK or API;
Provide links to your products and official communication channels in both online material and
in-person actions. This must be accessible without registration;
(LL8): List and publicize all the events you are supporting, planning to visit etc;
Engage with your developers in their native habitat (i.e. universities, developer conferences) priori-
tizing niche creation. You need to gather feedback from the product team and help prioritize the
Communicate with your (growing) audience through social media, blogs, forums and Slack channels.
Whatever your choice, you need to manage it well and communicate even better. Give a message to
each product and group of developers. Establishing periodicity is a great idea, because people will
know that you are maintaining a serious communication channel;
arXiv Template A Preprint
Consider working with developers and partner companies when planning face-to-face events. This
immediately expands the community even before you host the event. Create a disclosure plan showing
the DevRel team that will be present and the organization’s logo. People will get used to these
two images and, when the event happens, the developers will recognize their DevRel team and will
already trust it.
Consider launching and advertising products under an open source license, unless there is a compelling
reason not to do so;
Talk to developers during an event. Even if it does not result in conversion to contribution, any
positive interaction or assistance, at the very least, creates a positive image of your company. This
can result indirectly in the future adoption of products by those same people or by someone they
recommend your product;
Make your presentation slides available in an editable way to the community where you delivered an
event. As such, the community can reuse and translate them;
Know as much as you can about your products and represent them in a technically reliable way.
Because developers always have the option to find articles about their products on third-party
Ask your developers what they want to read. This can be done on social media. In addition to your
social media, use DevRel accounts so that other team practitioners can support you;
Prioritize the dissemination of content related to products through SEO (Search Engine Optimization)
tools and keywords, such as:,, Google AdWords Keyword Planner, and
Google Webmaster Tools.
Onboarding Stage
This stage is related to the developer’s objective of generating some contribution to
the ecosystem or to his professional career. A developer has gone through the awareness stage and has some
motivation to act in the ecosystem. At this stage, the developer is considered a novice in some product of the
ecosystem because he/she is starting his/her possible contribution. As such, it is important to reduce the
barriers to the participation of this developer. The DevRel practitioner can use the following set of
benefits package, partnership fees, and technical support.
: Establish partnership; Maintain the capacity to absorb new and/or potential developers; Support
development; Support negotiations; and Provide a connection between novice developers and experienced
The milestone that indicates that the developer has already passed this
stage is when a developer has a ready contribution at the submission level to any of the SECO
In this stage, there is a set of 7 lessons learned:
(LL18): Build, update and share a well-designed set of developer support tools;
Focus on individuals who have a noticeable interest in a specific technology or approach among
ecosystem products;
(LL20): Communicate the economic benefits of building and developing contributions;
Help developers to feel at home when interacting with the DevRel team or with SECO products and
services, even if the developer is already a contributor to another ecosystem;
(LL22): Direct developers to get involved in communities around something tangential to their products;
(LL23): Create and maintain your product documentation. Make information easy to find and understand;
Insert the developer into a complete developer loyalty program - one that supports and engages
developers, adding value to both the developer and the organization.
5.2.2 Growth Phase
At this stage, a developer must have at his disposal the necessary resources to advance the acquisition of
theoretical and practical knowledge to generate contributions to the expansion of the ecosystem. As part of
this phase, two stages were identified: Activation and Retention.
arXiv Template A Preprint
Activation Stage
This stage acts as a trigger that indicates whether the developer generated his/her
first contribution to the ecosystem, e.g., through the publication of a mobile application. At this stage, the
developer is designing, developing and submitting his/her first contribution. The following
can be
used by DevRel practitioners: portfolio of mobile devices and applications, contribution certification, and
quality level agreements.
Provide gain momentum; Manage platform change; Support niche contributions; Support development;
and Analyze peripheral, active and top developers.
The milestone that indicates that the developer has already passed this
stage is when a developer has a published contribution (e.g. mobile application, functionality in an
open-source project, technical article) in any of the SECO repositories.
In this stage, there is a set of 6 lessons learned:
Direct the developer during the development process to share about the social media ecosystem
Involve developers to talk about pain points and solutions that can be implemented. Developers do
not need you to impress them by solving all their problems, focus on those that your company’s
product solves;
Develop your community by planning and running Hackathons. Such an event helps to engage active
ecosystem developers. Enabling everyone to get to know each other and giving you the opportunity
to show that you care about them;
(LL28): Involve developers in a collection of materials written by them for the community;
Make sure that product documentation for the developer is an essential part of the experience on the
platform website. It should be easy to navigate, clean and simple to provide instructions that are
easy for developers to evaluate and follow;
Provide project templates and usage scenario guidelines so that developers can evolve contributions
to ecosystem products and services. This allows for the evolution of contributions with the least
possible resistance within a very short period.
Retention Stage
At this stage, a developer continues to use the platform, as well as new/additional
features, and provides new contributions. However, the developer has other opportunities in competitors. So,
at this stage, it is important to value the developer to retain him/her in relation to monetization and benefit
opportunities and the culture itself within SECO. Some
help the DevRel practitioner at this stage:
a portfolio of mobile devices and applications, contribution certification, business plan, income generation
model, quality level agreements, and social collaboration.
: Provide gain momentum; Manage platform change; Support niche contributions; Enable developers
to work with the latest and best technologies in the ecosystem; Support development; and Analyze peripheral,
active, and top developers.
The milestone that indicates that the developer has already passed this
stage is when a developer generated a contribution considered by the organization relevant to the
ecosystem (e.g. a mobile application that has achieved high visibility, a technical resource that is
widely used by the community, or a critical bug fix in an important platform project).
In this stage, there is a set of 10 lessons learned:
Focus on developer value in whatever content you are producing, be it blog posts, guides etc. This
means that the focus must be on problem-solving;
Recognize the diverse motivations of each member of the community, as there is no single type of
developer, and continually seek to align everyone’s interests. Understand and clearly state what the
organization is trying to achieve through a developer loyalty program. This will allow you to support
the goals of multiple business units. Try a portfolio that includes a range of activities, from quick
wins to big/important projects;
arXiv Template A Preprint
Draw the developers’ attention to the fact that their own brand will grow with the amount of
contributions they have made and the reputation they receive for it;
Be present at Stack Overflow. You can see what the developers write about your product and, even
if other developers cannot help each other, you can come in and help someone else. Show that you
are there to help them when they need you;
Keep an eye on the competition. Benchmark against key competitors to keep up with trends over
time. In addition to helping you understand industry leaders, this also helps you avoid the pitfalls of
retaining developers;
Involve developers in demonstrations and previews of new products and tools. Thus, in addition to
having early access, they will help to find possible problems for use;
Analyze the contributions of your developers, write about and publish on official channels and during
Encourage developers to read “developer stories”, a dedicated website about how developers are
succeeding within the ecosystem. It can help developers create a business, not just a mobile
(LL39): Be inclusive by sharing large open source and community libraries as part of the solution. Android
has become much more inclusive for the community. The most obvious example is Kotlin’s “hug”
and the collective work to make it the best possible on Android;
Direct developers to engage with communities that do the work in specific areas of the platform (e.g.
device fragmentation and building support libraries).
5.2.3 Maturity Phase
At this phase, the developer needs to stay updated, share experiences, establish trust with the keystone and
the developer community. It is also important that the developer is recognized for his contributions and is
prepared to move the community by acting as an extension of the DevRel team.
A developer at this phase is a reference for other developers in the ecosystem and needs a direct link to the
keystone through the DevRel team. This phase comprises a developer recognition stage (Recognition stage)
and a stage that helps to identify and prepare developers who are references for the ecosystem (Reference
stage), as described next.
Recognition Stage
An organization must perceive and highlight its best developers within the ecosystem
in aspects that demonstrate impactful contributions to the ecosystem, e.g. developer success stories, extensions
such as tools, platform correction reports, and mobile applications that stand out in the store. The following
assist the DevRel practitioner within this stage: developer support programs, marketing benefits,
incentives for innovation, meritocracy, and social collaboration.
: Lead positive interactions and closer relationships; Support developer recognition by users, organization
and community; Identify community leaders; Build and get feedback on products; and Communicate the real
impacts of the developers’ work.
The milestone that indicates that the developer has already passed this
stage is when the developer obtains recognition from a local community and has skills close to a
professional profile of DevRel (leadership, communication and technical knowledge of the technologies
involved in the ecosystem).
In this stage, there is a set of 11 lessons learned:
Work directly with hackathons award winners, promoting projects through blogs using the contribution
as promotional material, if that makes sense;
Promote the contributions of developers, such as mobile applications. Driving downloads of mobile
applications will create a lot of value in terms of developer relationships and will also help to sell
your platform;
Praise some specific developers on their official channels. This can be a major boost to public
recognition and the developer’s business;
arXiv Template A Preprint
Connect potential developers in the community with colleagues across organizational sectors. It is
also important to have a variety of programs to connect developers directly to small and medium
business customers;
Help developers to help their DevRel area. Seminars, events, webinars, demos - whatever you’re
doing to bring your platform’s attention to the world, invite some developers to share knowledge and
Help create status and identify leaders in the community. Developers want to build their social
status, gain a reputation and share their knowledge with other developers;
Invest in training community leaders. These leaders will be able to work as an extension of the
DevRel team by recruiting, training and qualifying ecosystem developers;
Give reputation to the right people, show appreciation and reward the most active. When done
correctly, people create lectures, write books, help develop the community with you. When developers
can increase their value, reach and recognition by building their platform and increasing their target
audience, they will be much more dedicated to you and your brand;
(LL49): Offer 1: 1 training at various levels as a reward - instead of getting tired of training everyone, have
self-training materials that developers can use to get to the next level;
Have a defined code of conduct for leaders and communities - your reputation is also at stake when
one of your community members “gets out of line”;
Connect your Talent acquisition team to the developers, educate that team on how the community is
working. It helps in identifying communities and influencers who can partner to create incredible
content for the DevRel area.
Reference Stage
At this stage, the focus is on making sure that a developer, identified as a leader at the
previous stage, can influence the community and act to raise awareness among new developers. The influencer
tells others about the platform. In this scenario, relationships are two-way commitments and represent an
investment by the developer. As
for this stage, we have: technical support, marketing support, and
a network of influencers.
: Establish and support a network of specialized influencers to scale the activities of the ecosystem;
Lead strategic partnerships; and Empower key developers and key contributors as influencers.
Specifically at this stage, there is no milestone for changing the flow of
advancement from the developer. As a reference stage, the developer leverages himself as an influencer
and in working closely with DevRel team.
In this stage, there is a set of 11 lessons learned:
Establish a strong relationship with local influential developers called influencers. These are the
people who will stand up during a meeting and propose your product as the solution to the problem
they are trying to solve. They are part of my support system. An influencer is someone with whom
you have created an especially deep and meaningful relationship, which you have delegated to go out,
act on your behalf and increase your reach;
Invest in events, preferably organized by influencers, ensuring they understand that they affect the
company’s goals and what they can do to make a positive impact. Keep your team of influencers
informed of the events you are planning;
Build a strong network between the different influencers in the community, a community of influencers.
Then, recognize them as official communities of experts and grant them expanded privileges. This
will help to increase the community and decrease the burden on DevRel teams;
Introduce your community of influencers to developers and partner companies. Inform the various
sectors of your organization about your influencers - this is the final step in turning volunteers into
Define an event manual - as the influencer somehow speaks of your company name using your
materials, they must also have goals to be achieved;
Ask influencers to submit lectures to technical conferences so that they deliver technical lectures and
assist in spreading the ecosystem;
arXiv Template A Preprint
Involve influencers in coding technical demonstrations of ecosystem products. It helps in empowering
the influencer;
Teach influencers to create technical articles that inform, convince and/or establish the author’s
Ask influencers to plan and hold meetings with local communities, in addition to analyzing the results
of engagement engagement;
(LL61): Guide influencers to be active on sites such as GitHub, Medium and YouTube;
(LL62): Direct the influencer to collect feedback on your product trends.
6 Implications to Theory and Practice
The study for the conception and refining of DevGo contributes to advances in research and the construction
of a body of knowledge for the DevRel (Developer Relations) area. As mentioned in the related work section
(Section 3) and identified in the grey literature review (Section 4.3) , although there are investments in the
industry to understand the DevRel area, the scientific community had not yet addressed the topic of DevRel.
It can be perceived that the use of DevGo generates
research opportunities
, in general, in the following
areas: (a) Developer Governance Maturity: as the DevGo model is established, it will be possible to analyze
and diagnose the maturity of each organization from the point of view of DevRel. In addition to being
a means of recognizing the level of the organization, actions for the maturation of the organization may
be indicated. As in other maturity models (e.g. CMMI), it is necessary to define levels, evaluation, and
implementation guides, for example; (b) DevRel Process: create DevGo instances from business and software
processes. Analyze which notations favor the understanding of instances, in the form of processes, by DevRel
practitioners; and (c) Specific studies for each DevGo focus area: each of the DevGo areas can be expanded
structurally through new studies. The DevRel area (Evangelism and Advocacy), e.g., as indicated in some
of the studies, needs to be improved concerning the existing roles within evangelism and advocacy. Each
element that composes DevGo can be a research target. With this, the structure defined for DevGo can
support as a basis for DevRel theory and for empirical software engineering studies.
DevGo can support
industry demands
, such as ROI (Return on Investment) in DevRel activities; effects
on the developer experience (DX); and identification of barriers to developer onboarding, engajement and
recognition. The use of DevGo can contribute to expanding efforts in the DevRel teams. DevGo model
can also help DevRel practitioners and researchers in situations when: (1) There is no DevRel program:
knowledge of the essential areas to plan and start a developer governance program through DevRel; (2)
DevRel strategies at a basic level, documented and defined: identification of where the organization is and
where it can go; (3) DevRel’s own strategies: guide in decisions involving risks and trends to maintain
competitiveness concerning other organizations; (4) Monitoring and control: more focused on the use in the
Monitoring area to form a solid base of evaluation mechanisms and tools for SECOs with a broader base of
developers; and (5) Introduction of innovative strategies to better meet the organization’s goals: supporting
organizations in the evolution of the developer’s governance strategies, dimensioning efforts, and forming
internal teams. Another point for the practice is the educational training of professionals for the DevRel
area. With DevGo as a guide in establishing courses or disciplines, the practice and scientific community can
discuss ways to educate this new generation and enhance the skills of professionals who are working in the
7 Conclusions and Future Work
This article presented a model known as DevGo to support developer governance from DevRel (Developer
Relations) in Software Ecosystems. The DevGo comprises four focus areas (Platform and Products, DevRel -
Evangelism and Advocacy, Developer Advancement Flow, Monitoring), three developer advancement phases
(Beginning, Growth, Reference), six stages (Awareness, Onboarding, Activation, Retention, Recognition,
Reference), enablers, value transfer objects and set of 62 lessons learned from DevRel practitioners is associated
with DevGo stages. The DevGo was built and refined by an opinion survey, interviews and grey literature
review methods. It involved 64 DevRel practitioners.
In future work, we will perform case studies using DevGo as an intervention for planning, executing and
analyzing the results of DevRel activities. In addition, a tool is being built to make it easier for DevRel
practitioners and researchers to instantiate DevGo. It is important in helping refine DevGo. There is an
arXiv Template A Preprint
ongoing study for the identification of roles and the structuring of teams for DevRel, the results of these
studies will be incorporated into the DevRel (Evangelism and Advocacy) Focus Area. We can also move
forward in establishing a set of items that structure value creation in DevRel. Another work is to perform an
alignment between DevRel’s perspective and the work of Hyrynsalmi et al.Hyrynsalmi et al. [2014] about
value creation from the perspective of app developers. This value structure will allow practitioners, e.g.,
to analyze DevRel’s ROI and the scientific community to operationalize DevRel and SECO value creation
analysis. It can be done using software repository mining strategies and machine learning.
We thank FAPEAM, FAPERJ (Proc. 211.583/2019), CNPq, Coordenação Development Aperfeiçoamento
de Pessoal de Nível Superior - Brasil (CAPES) - Finance Code 001, and in part by Federal University of
Mato Grosso do Sul (UFMS) for the financial support. The first author also thanks to FACOM/UFMS for
partially support this research. Finally, we thank the participants for the participation.
Author contributions
AF wrote the introduction, background, related work and participated in the design of the studies and
performed the results’ analysis. SGT wrote related work and participated in results’ analysis. IW participated
in the design of the studies and reviewed the analysis of research questions answers. RPS helped to draft the
manuscript and participated in the results’ analysis of the studies. ACDN reviewed the design of the studies.
All the authors contributed to reviewing the paper, discussing the implications to theory and practice and
refining the proposed model. All authors read and approved the final manuscript.
Financial disclosure
None reported.
Conflict of interest
The authors declare no potential conflict of interests.
Data Availability Statement
Data sharing not applicable to this article as no datasets were generated or analysed during the current study.
Thomas Kude, Thomas Huber, and Jens Dibbern. Successfully governing software ecosystems: Competence
profiles of partnership managers. IEEE software, 36(3):39–44, 2018.
Awdren Fontão, Bruno Ábia, Igor Wiese, Bernardo Estácio, Marcelo Quinta, Rodrigo Pereira dos Santos,
and Arilo Claudio Dias-Neto. Supporting governance of mobile application developers from mining and
analyzing technical questions in stack overflow. Journal of Software Engineering Research and Development,
6(1):8, 2018.
Slinger Jansen, Stef Peeters, and Sjaak Brinkkemper. Software ecosystems: From software product management
to software platform management. In Proceedings of the Fourth International Conference on Software
Business (ICSOB), pages 5–18. Springer, 2013.
Konstantinos Manikas. Revisiting software ecosystems research: A longitudinal literature study. Journal of
Systems and Software, 117:84–103, 2016.
Awdren Fontão, Rodrigo Pereira dos Santos, and Arilo Claudio Dias-Neto. Mobile software ecosystem (mseco):
a systematic mapping study. In 2015 IEEE 39th Annual Computer Software and Applications Conference,
volume 2, pages 653–658. IEEE, 2015.
Caio Steglich, Sabrina Marczak, Luiz Pedro Guerra, Luiz Henrique Mosmann, Marcelo Perin, Fernando
Figueira Filho, and Cleidson de Souza. Revisiting the mobile software ecosystems literature. In 2019
IEEE/ACM 7th International Workshop on Software Engineering for Systems-of-Systems (SESoS) and 13th
Workshop on Distributed Software Development, Software Ecosystems and Systems-of-Systems (WDES),
pages 50–57. IEEE, 2019.
arXiv Template A Preprint
Mario Schaarschmidt, Dirk Homscheid, and Thomas Kilian. Application developer engagement in open
software platforms: An empirical study of apple ios and google android developers. International Journal
of Innovation Management, 23(04):1950033, 2019.
Alexander Benlian, Daniel Hilkert, and Thomas Hess. How open is this platform? the meaning and
measurement of platform openness from the complementers’ perspective. Journal of Information Technology,
30(3):209–228, 2015.
Eleni Constantinou and Tom Mens. Socio-technical evolution of the ruby ecosystem in github. In 2017 IEEE
24th International Conference on Software Analysis, Evolution and Reengineering (SANER), pages 34–44.
IEEE, 2017.
R Meier. Why do we pay these people anyway? relating to developer relations and developers. digital, 2015.
Awdren Fontão, Bruno B. P. Cafeo, Bruno Bonifácio, Rodrigo Pereira dos Santos, and Arilo Claudio Dias-Neto.
On developer relations team’s reasons for using repositories. In Proceedings of the 13th International
Workshop on Cooperative and Human Aspects of Software Engineering (CHASE 2020), ICSEW’20, page
187–188, New York, NY, USA, 2020a. ACM, Association for Computing Machinery. ISBN 9781450379632.
doi:10.1145/3387940.3392170. URL
Carina Alves, Joyce Aline Pereira de Oliveira, and Slinger Jansen. Software ecosystems governance-a
systematic literature review and research agenda. In Proceedings of the 19th International Conference on
Enterprise Information System, pages 215–226. Springer, 2017.
Awdren Fontão, Rodrigo Pereira dos Santos, and Arilo Claudio Dias-Neto. Exploiting repositories in mobile
software ecosystems from a governance perspective. Information Systems Frontiers, 21(1):143–161, 2019.
Wolfgang Vorraber, Matthias Müller, Siegfried Voessner, and Wolfgang Slany. Analyzing and managing
complex software ecosystems-a framework for creating a common understanding and aligning shared goals
for developers and business managers, applied to a free open source software project. IEEE software, 2018.
Michael Pidd. Just modeling through: A rough guide to modeling. Interfaces, 29(2):118–132, 1999.
Jennifer Horkoff, Fatma Başak Aydemir, Evellin Cardoso, Tong Li, Alejandro Maté, Elda Paja, Mattia
Salnitri, Luca Piras, John Mylopoulos, and Paolo Giorgini. Goal-oriented requirements engineering: an
extended systematic mapping study. Requirements Engineering, 24(2):133–160, 2019.
Ibrahim K El-Far and James A Whittaker. Model-based software testing. Encyclopedia of software engineering,
Barbara Rita Barricelli, Fabio Cassano, Daniela Fogli, and Antonio Piccinno. End-user development, end-user
programming and end-user software engineering: A systematic mapping study. Journal of Systems and
Software, 149:101–137, 2019.
George Valença and Carina Alves. A theory of power in emerging software ecosystems formed by small-to-
medium enterprises. Journal of Systems and Software, 134:76–104, 2017.
Awdren Fontão, Rodrigo Pereira dos Santos, Jackson Feijó Filho, and Arilo Claudio Dias-Neto. Mseco-dev:
Application development process in mobile software ecosystems. In Proceedings of the International
Conference on Software Engineering and Knowledge Engineering, pages 317–322. IEEE, 2016.
Raphael Oliveira, Camila Ajala, Davi Viana, Bruno Cafeo, and Awdren Fontão. Developer relations (devrel)
roles: an exploratory study on practitioners’ opinions. In 2021 Brazilian Symposium on Software Engineering
(SBES ’21). ACM, 2021.
Geoffrey Parker, Marshall W Van Alstyne, and Xiaoyue Jiang. Platform ecosystems: How developers invert
the firm. Boston University Questrom School of Business Research Paper, (2861574), 2016.
Cliff Bowman and Veronique Ambrosini. Value creation versus value capture: towards a coherent definition
of value in strategy. British journal of management, 11(1):1–15, 2000.
Raphael Amit and Christoph Zott. Value creation in e-business. Strategic management journal, 22(6-7):
493–520, 2001.
Sami Hyrynsalmi, Marko Seppänen, and Arho Suominen. Sources of value in application ecosystems. Journal
of Systems and Software, 96:61–72, 2014.
Matteo Cristofaro. E-business evolution: an analysis of mobile applications’ business models. Technology
Analysis & Strategic Management, 32(1):88–103, 2020.
Olavo Barbosa, Rodrigo Pereira dos Santos, Carina Alves, Claudia Werner, and Slinger Jansen. A systematic
mapping study on software ecosystems from a three-dimensional perspective. In Software Ecosystems.
Edward Elgar Publishing, 2013.
arXiv Template A Preprint
Oscar Franco-Bedoya, David Ameller, Dolors Costal, and Xavier Franch. Open source software ecosystems:
A systematic mapping. Information and software technology, 91:160–185, 2017.
Chris Jensen and Walt Scacchi. Governance in open source software development projects: A comparative
multi-level analysis. In IFIP International Conference on Open Source Systems, pages 130–142. Springer,
Corey Jergensen, Anita Sarma, and Patrick Wagstrom. The onion patch: migration in open source ecosystems.
In Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations
of software engineering, pages 70–80. ACM, 2011.
Yixin Qiu, Anand Gopal, and Il-Horn Hann. Synthesizing professional and market logics: A study of ios app
entrepreneurs. In Academy of Management Proceedings, volume 2012, page 12803. Academy of Management
Briarcliff Manor, NY 10510, 2012.
Jonathan Wareham, Paul B Fox, and Josep Lluís Cano Giner. Technology ecosystem governance. Organization
science, 25(4):1195–1215, 2014.
Mahsa H Sadi, Jiaying Dai, and Eric Yu. Designing software ecosystems: How to develop sustainable
collaborations? In International Conference on Advanced Information Systems Engineering, pages 161–173.
Springer, 2015.
Awdren Fontão, Sergio Cleger-Tamayo, Igor Wiese, Rodrigo Pereira dos Santos, and Arilo Claudio Dias-Neto.
On value creation in developer relations (devrel): A practitioners’ perspective. In Proceedings of the 15th
International Conference on Global Software Engineering, ICGSE ’20, page 33–42, New York, NY, USA,
2020b. ACM, Association for Computing Machinery. ISBN 9781450370936. doi:10.1145/3372787.3390440.
Alan Hevner and Samir Chatterjee. Design science research in information systems. In Design research in
information systems, pages 9–22. Springer, 2010.
Jefferson Seide Molléri, Kai Petersen, and Emilia Mendes. Survey guidelines in software engineering:
An annotated review. In Proceedings of the 10th ACM/IEEE International Symposium on Empirical
Software Engineering and Measurement, ESEM ’16, New York, NY, USA, 2016. ACM, Association for
Computing Machinery. ISBN 9781450344272. doi:10.1145/2961111.2962619. URL
Forrest Shull, Janice Singer, and Dag IK Sjøberg. Guide to advanced empirical software engineering. Springer,
Vahid Garousi, Michael Felderer, and Mika V Mäntylä. Guidelines for including grey literature and conducting
multivocal literature reviews in software engineering. Information and Software Technology, 106:101–121,
Siw Elisabeth Hove and Bente Anda. Experiences from conducting semi-structured interviews in empirical
software engineering research. In 11th IEEE International Software Metrics Symposium (METRICS’05),
pages 10–pp. IEEE, 2005.
Jim Witschey, Emerson Murphy-Hill, and Shundan Xiao. Conducting interview studies: Challenges, lessons
learned, and open questions. In 2013 1st International Workshop on Conducting Empirical Studies in
Industry (CESI), pages 51–54. IEEE, 2013.
Awdren Fontão, Bernardo Estácio, Igor Wiese, Rodrigo Pereira dos Santos, and Arilo Claudio Dias-Neto.
Governing developers in software ecosystems. digital, 2017.
Morris Hamburg. Basic statistics: A modern approach. Houghton Mifflin Harcourt P, 1974.
Arilo Claudio Dias-Neto and Guilherme Horta Travassos. Surveying model based testing approaches
characterization attributes. In Proceedings of the Second ACM-IEEE international symposium on Empirical
software engineering and measurement, pages 324–326. ACM-IEEE, 2008.
Daniela S Cruzes and Tore Dyba. Recommended steps for thematic synthesis in software engineering. In 2011
international symposium on empirical software engineering and measurement, pages 275–284. IEEE, 2011.
Sussy Bayona, Jose Bustamante, and Nemias Saboya. Pmbok as a reference model for academic research
management. In World Conference on Information Systems and Technologies, pages 863–876. Springer,
He Zhang, Runfeng Mao, Huang Huang, Qiming Dai, Xin Zhou, Haifeng Shen, and Guoping Rong. Processes,
challenges and recommendations of grey literature review: An experience report. Information and Software
Technology, page 106607, 2021.
ResearchGate has not been able to resolve any citations for this publication.
Conference Paper
Full-text available
Amazon, Google, Nintendo, and Facebook have invested in DevRel (Developer Relations) teams to support the synergy among developer communities' expectations and the organization's goals. The DevRel strategies, which need to be planned, executed, and monitored, require the understanding of team structure to improve results. Identifying roles is a critical activity because DevRel people must plan, perform and monitor specific strategies to attract, engage, and mature developer communities. This research investigates the DevRel Roles by describing definitions and skills for each role. We synthesize the "voice" of 116 practitioners from 19 countries with a grey literature review. We discuss nine identified roles regarding definition and skills. The roles include, for example, Developer Programs Engineer, Developer/Technical Advocate, Developer/Technical Evangelist, and Technical Writer. We noticed a lack of standardization of roles in DevRel.
Conference Paper
Full-text available
Software Ecosystem (SECO) comprises third-party developers cooperating and competing during contributions around a platform provided by a central organization (keystone). These keystones have invested in a Developer Relations (DevRel) internal team, as a global business strategy, to attract and engage a critical mass of third-party developers in producing and evolving contributions. For this reason, the DevRel team should promote social relationships among SECO actors and synergy among keystone’ goals and developers’ expectations. It can help to establish and sustain a competitive value creation network (VCN) within the SECO that must survive to inherit changes. However, it is still a challenge on how DevRel team can act on the SECO to better engage the developers’ communities aiming to establish a robust VCN. In this paper, we advance on investigating the perceptions of 31 DevRel practitioners from seven countries and large, medium and small-size companies about value creation in DevRel. We found 55 elements of value creation distributed in retention, efficiency, innovation, and complementarity. Based on this analysis, we contribute with a set of seven insights and a DevRel VCN involving elements, suppliers and consumers. It fosters a common perspective for DevRel practitioners, keystones and researchers for designing strategies and research roadmap.
Full-text available
Context: A Multivocal Literature Review (MLR) is a form of a Systematic Literature Review (SLR) which includes the grey literature (e.g., blog posts, videos and white papers) in addition to the published (formal) literature (e.g., journal and conference papers). MLRs are useful for both researchers and practitioners since they provide summaries both the state-of-the art and –practice in a given area. MLRs are popular in other fields and have recently started to appear in software engineering (SE). As more MLR studies are conducted and reported, it is important to have a set of guidelines to ensure high quality of MLR processes and their results. Objective: There are several guidelines to conduct SLR studies in SE. However, several phases of MLRs differ from those of traditional SLRs, for instance with respect to the search process and source quality assessment. Therefore, SLR guidelines are only partially useful for conducting MLR studies. Our goal in this paper is to present guidelines on how to conduct MLR studies in SE. Method: To develop the MLR guidelines, we benefit from several inputs: (1) existing SLR guidelines in SE, (2), a literature survey of MLR guidelines and experience papers in other fields, and (3) our own experiences in conducting several MLRs in SE. We took the popular SLR guidelines of Kitchenham and Charters as the baseline and extended/adopted them to conduct MLR studies in SE. All derived guidelines are discussed in the context of an already-published MLR in SE as the running example. Results: The resulting guidelines cover all phases of conducting and reporting MLRs in SE from the planning phase, over conducting the review to the final reporting of the review. In particular, we believe that incorporating and adopting a vast set of experience-based recommendations from MLR guidelines and experience papers in other fields have enabled us to propose a set of guidelines with solid foundations. Conclusion: Having been developed on the basis of several types of experience and evidence, the provided MLR guidelines will support researchers to effectively and efficiently conduct new MLRs in any area of SE. The authors recommend the researchers to utilize these guidelines in their MLR studies and then share their lessons learned and experiences.
Full-text available
There is a need to improve the direct communication between large organizations that maintain mobile platforms (e.g. Apple, Google, and Microsoft) and third-party developers to solve technical questions that emerge during the project and development of developers' contributions in a Mobile Software Ecosystem (MSECO). In this context, those organizations may not know how to define and evolve strategies to govern their developers towards achieving their organizational goals. Such organizations use an infrastructure to support developers, for example, questions and answers (Q&A) portals such as Stack Overflow. Interactions among developers in these portals feed a Q&A repository that can serve as a mechanism to understand and define strategies to support developers. In this paper, we mined 1,568,377 technical questions from Stack Overflow related to Android, iOS, and Windows Phone platforms. Next, we performed comparisons among those MSECO regarding: (i) developers' activity intensity, (ii) hot-topics (using Latent Dirichlet allocation algorithm) from all and more commented/viewed questions, (iii) "What" and "How to" questions, (iv) hottopics from more viewed unanswered questions, and (v) relationship among questions and official developer events. From the results, we identified four key insights: recruiting, educating, and monitoring strategies; barrier reduction; management of technology insertion; and fostering of relationships. The relevance of the four key insights to support developer governance was evaluated by practitioners through a survey. Finally, for each key insight we associated a total of 10 strategies to support developer governance activities. Such strategies were extracted from 65 studies identified through a systematic mapping of the literature.
Context Systematic Literature Review (SLR), as a tool of Evidence-Based Software Engineering (EBSE), has been widely used in Software Engineering (SE). However, for certain topics in SE, especially those that are trendy or industry driven, academic literature is generally scarce and consequently Grey Literature (GL) becomes a major source of evidence. In recent years, the adoption of Grey Literature Review (GLR) or Multivocal Literature Review (MLR) is rising steadily to provide the state-of-the-practice of a specific topic where SLR is not a viable option. Objective Although some SLR guidelines recommend the use of GL and several MLR guidelines have already been proposed in SE, researchers still have conflicting views on the value of GL and commonly accepted GLR or MLR studies are generally lacking in terms of publication. This experience report aims to shed some light on GLR through a case study that uses SLR and MLR guidelines to conduct a GLR on an emerging topic in SE to specifically answer the questions related to the reasons of using GL, the processes of conducting GL, and the impacts of GL on review results. Method We retrospect the review process of conducting a GLR on the topic of DevSecOps with reference to Kitchenham’s SLR and Garousi’s MLR guidelines. We specifically reflect on the processes we had to adapt in order to tackle the challenges we faced. We also compare and contrast our GLR with existing MLRs or GLRs in SE to contextualize our reflections. Results We distill ten challenges in nine activities of a GLR process. We provide reasons for these challenges and further suggest ways to tackle them during a GLR process. We also discuss the decision process of selecting a suitable review methodology among SLR, MLR and GLR and elaborate the impacts of GL on our review results. Conclusion Although our experience on GLR is mainly derived from a specific case study on DevSecOps, we conjecture that it is relevant and would be beneficial to other GLR or MLR studies. We also expect our experience would contribute to future GLR or MLR guidelines, in a way similar to how SLR guidelines learned from the SLR experience report a dozen years ago. In addition, other researchers may find our decision making process useful before they conduct their own reviews.
Prior scholars have deeply defined the sources of value, typologies, and value capture mechanisms of website businesses. The advent of new e-businesses, i.e., mobile applications, requires investigation into which are the successful variations of e-businesses that have been selected and retained for surviving the new digital era, and how they have been formed. A mixed qualitative-quantitative business model analysis of 2,250 mobile applications of the Google Play Store is proposed. Results are interpreted according to evolutionary lenses. Content apps, whose value is driven by their efficiency, lock-in, design, and ability to add complementary monetization mechanisms (i.e., In-App purchases) beside the ads value capture schema (or ‘mixed’ for ‘pay per download’ apps), are the ones that can survive digital Darwinism. E-business models and their innovations are the products of evolutionary processes; from that, e-business models should be evaluated and re-evaluated over time according to the modifications of the multi-level environment.
The emergence of software platforms and ecosystems has led platform owners to create the new role of the partnership manager—responsible for putting their partner programs into practice. However, there is little guidance as to what the required competences for this new role are. Based on studying a multitude of partnerships in different software ecosystems, we derive two typical competence profiles of partnership managers that provide the basis to either governing partnerships in an arm’s length or dyadic style. The competence profiles help platform owners to systemically develop and deploy the competencies of their partnership managers. We further discuss how the profiles help platform owners to start, grow, and manage software ecosystems. Finally, we discuss insights for complementors.
Managing complex software ecosystems, such as Free Open Source Software projects, is crucial for software-producing organizations. This article presents a framework that helps to visualize complex ecosystem settings and to gain insights on value-engines. This provides a basis to align business strategies to the needs of all relevant contributors and customers. A visual representation is used to describe relationships between ecosystem partners, which forms a basis for detailed strategic analysis.