No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Successfully Governing Software Ecosystems: Competence Profiles of Partnership Managers
Abstract
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.
... For the industry the process of expanding a platform through a Software Ecosystem (SECO) approach requires the creation of new strategies that promote collaboration of the central organization that maintains the ecosystem with third-party developers [1]. A Software Ecosystem (SECO) can be defined as the interactions between developers around a common platform to meet the demands of users [2]. ...
... Only in the mobile SECO (MSECO), Android has about 5.9 million developers involved in creating technical resource or events (e.g., conferences, hackathons). The SECO platform depends on developers because the platform's attractiveness is determined by a frequent evolution of its software offerings [1]. ...
... At the peak, where the ratio is 1, there are the same number of answered and unanswered questions. This point needs to be investigated, but we can raise some considerations about the ecosystem that is dead: (1) there is no diversity in the developers' questions and therefore the community does not invest time in answering replicated questions; (2) those who are engaged in technical resources answer specific questions and the others who could answer the other questions are no longer engaged; (3) some questions may be answered in the coming months, so time is not a priority and the Q&A repository is no longer an environment to accelerate progress in the use of resources by a community of developers. ...
The Developer Relations (DevRel) is a strategy to attract, engage, and mature developers in producing and evolving contributions to a platform. DevRel supports the establishment of a Software Ecosystem (SECO). However, even with investments in the DevRel area, some organizations face the death of their ecosystems, for example, Symbian (2012), Firefox OS (2016), Windows Phone (2017). It can be compared based on Ecology to a disruption of the food chain that can turn a dynamic ecosystem in a static or dead ecosystem. For example, Microsoft announced in 2017 that Windows Phone would no longer push any updates and became only focusing on maintenance. We want to contribute to understanding how, why, and when a SECO is losing the dynamics and turning on static (i.e., dying). We initially study the Windows Phone from 46,030 questions in Stack Overflow. From our result analysis, we perceived that it can be useful to understanding the signals of ecosystem collapse, migratory/survival patterns, technical resource recycling, and the energy transfer among individuals, populations, communities, and SECOs.
... 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 developers and meeting the demands of users [1] [2]. This scenario, which involves technical (i.e., the development process), social (i.e., interaction among users, companies and third-party/internal developers), and business (i.e., synergy surrounded by organizational intentions and developer expectations) dimensions, has been known as Software Ecosystem (SECO) [3]. ...
... As part of SECO governance, planning and execution of DevRel activities is not trivial and focus on delimiting developer actions without excessively restricting the desired level of value creation [10] [11]. DevRel practitioners need to have a realistic 1 Statista, "App Developers -Statistics & Facts," https://www.statista.com/topics/1694/appdevelopers/, 2019 Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. ...
... Copyrights for components of this work owned by others than ACM must be honored. ICGSE '20, October 5-6, 2020 view of value creation within the SECO aiming to meet the needs of developers and achieve keystone goals [1] [2] [12]. ...
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.
... The interactions among developers, users, companies around a common platform have moved the keystones (organizations that maintain software platforms) towards expanding their platforms, attracting developers, and meeting the demands of users Kude et al. [2018], Fontão et al. [2018]. This scenario has been known as Software Ecosystem (SECO) Manikas [2016]. ...
... This scenario has been known as Software Ecosystem (SECO) Manikas [2016]. There are also internal keystone employees supporting developers in SECO onboarding, engagement, and recognition Kude et al. [2018], Fontão et al. [2020b]. They compose an internal team called Developer Relations (DevRel). ...
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.
... The new dynamic of interactions between third-party developers over a common technological platform has moved the organizations that maintain software platforms towards the engagement of a critical mass of developers to meet the users' demands [1] [2]. This scenario has been known as a Software Ecosystem (SECO) [3]. ...
... The developers' engagement leads to complement the value that the SECO platforms offer to their customers. A platform depends on developers because its attractiveness is given by a frequent evolution of its software offerings [1]. ...
Organizations such as Amazon, Apple and Google have been investing in Developer Relations (DevRel) team to engage a critical mass of third-party developers in producing and evolving contributions to a common technological platform. It fosters the establishment of a Software Ecosystem (SECO). However, it is still unknown how the DevRel team should act on monitoring a SECO aiming to establish a robust ecosystem. One tangible possibility is to mine repositories to enhance DevRel strategies. In this paper, we report on an investigation of the reasons that lead 31 DevRel practitioners to use software repositories during their activities. The results point out a common perspective for DevRel practitioners and researchers in developing strategies and research roadmaps.
... ex.: ferramentas, práticas, processos, modelos) sustentáveis para governar desenvolvedores, ela corre o risco de falhar no atendimento das demandas dos usuários. Uma governança de desenvolvedores insustentável ao longo do tempo pode resultar na "morte" do ecossistema [Wareham et al. 2014] [Kude 2018]; por exemplo, o MSECO Windows Phone foi declarado oficialmente "morto" em 2017 porque os desenvolvedores não apoiaram a plataforma 3 . As organizações podem passar por dificuldades ao tentar monitorar os efeitos das ações de governança de desenvolvedores [Mäenpää et al. 2017]. ...
Organizações que mantêm ecossistemas de software móvel (MSECO), como Apple e Google, têm investido em estratégias de governança de desenvolvedores com a formação de um time de Developer Relations (DevRel). Busca-se, com DevRel, estabelecer sinergia entre expectativas das comunidades de desenvolvedores externos e objetivos da organização. Porém, isto não é trivial: se a estratégia for insustentável, pode-se incorrer na “morte” do ecossistema. Por meio de estudos secundários na literatura, estudos primários envolvendo 68 profissionais de DevRel e estudos de mineração de repositórios de software, foi desenvolvido na tese um modelo para a governança de desenvolvedores em MSECO a partir de DevRel – DevGo (do inglês, DEVeloper GOvernance). O DevGo é composto por: áreas de foco, fases de avanço do desenvolvedor, estágios, facilitadores e objetos de transferência de valor. Além disso, um conjunto de lições aprendidas de profissionais de DevRel associadas a estágios do DEVGO, categorias de repositórios e motivações para uso deles com foco em monitoramento.
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.
The reuse of artifacts generated throughout the proprietary software development has been improved to support and promote relationships among vendors, consumers and a central organization that maintains the common technological platform. This scenario has been investigated as Software Ecosystems (SECO). When the ecosystem is centered in a closed platform, it is known as a proprietary SECO. In this case, establishing software asset management policies and guidelines is a critical aspect for maintaining a sustain-
able SECO. Contributions from actors that are external to the central organization should be allowed without exposing internal knowledge and risking the ecosystem robustness of the ecosystem. In this context, this study investigates asset governance mechanisms in a proprietary SECO by: (1) a survey research with 34 participants to capture insights on some mechanisms, (2) a set of 8 interviews with a group of managers to analyze the most relevant mechanisms; and (3) a correlation analysis from the managers’ opinions.
Organizations that maintain mobile software ecosystems (MSECO), such as Apple, Google and Microsoft, have engaged a critical mass of outside developers to expand their platforms. As such, they explore strategies for developer governance. These strategies depend on the associated operation between the organization's goals and the expectations of the developers. The MSECO developer governance area still needs formalization, theories and models.
In this context, organizations have invested in Developer Relations (DevRel).The industry requires new strategies that promote the organization's collaboration with external developers. As part of these strategies, DevRel professionals need to have a realistic view of developers' behavior within the ecosystem and then meet the developers’ needs and achieve organizations’ goals.
The definition of developer governance strategies is not trivial; it consists of delimiting the actions of developers without restricting excessively the desired level of value creation. If developer governance is unsustainable, it can lead to the "death" of the ecosystem. For example, one of the factors by which the Windows Phone MSECO was officially declared "dead" in 2017 was because the developers no longer supported the platform.
In this thesis, through a set of secondary and primary studies and mining software repositories involving DevRel professionals, we investigate the structure of MSECO developer governance and a set of lessons learned. Next, we built and refined a model for governance of developers in MSECO called DevGo (DEVeloper GOVernance). DevGo consists of: areas of focus, developer advancement stages, stages, facilitators, and value transfer objects.
In addition, a set of lessons learned from DevRel professionals associated with DevGo stages, repository categories, and motivations for their use with a focus on monitoring. From the case studies, participants noted that the DevGo framework facilitates understanding of developer governance, value transfer objects, as well as the communication of the importance of the field to the organization and the focus area regarding ecosystem monitoring. There was no disagreement regarding the adequacy, control, understanding and generality of DevGo.
Based on an exploratory multiple-case study in two platform ecosystems, we develop a process theory that explains how and why different ways of practicing ecosystem-wide governance are more or less successful in navigating the tension between co-created value and governance costs. Our process theory shows that the way how ecosystem-wide rules and values are practiced considerably varies and changes over time. Initially, governance practices follow ecosystem-wide rules; if and how they go beyond the rules hinges on specific necessary conditions. Irrespective of which governance route is taken, the tension between co-created value and governance costs is more successfully addressed if practices are sensitive to ecosystem-wide values.
In an agile software development project, customer representatives (CRs) have explicit and implicit responsibilities that facilitate the creation of software to meet evolving customer needs in a timely manner. We describe a competency model for effective CRs that was developed following interviews with four agile development teams. The model comprises 10 competencies grouped within three competency areas: Business, Socio- Relational and Systems. We provide recommendations for CIOs on how to use the model as a tool for communication, education and training, performance assessment and diagnostics.
Platform Ecosystems is a hands-on guide that offers a complete roadmap for designing and orchestrating vibrant software platform ecosystems. Unlike software products that are managed, the evolution of ecosystems and their myriad participants must be orchestrated through a thoughtful alignment of architecture and governance. Whether you are an IT professional or a general manager, you will benefit from this book because platform strategy here lies at the intersection of software architecture and business strategy. It offers actionable tools to develop your own platform strategy, backed by original research, tangible metrics, rich data, and cases. You will learn how architectural choices create organically-evolvable, vibrant ecosystems. You will also learn to apply state-of-the-art research in software engineering, strategy, and evolutionary biology to leverage ecosystem dynamics unique to platforms. Read this book to learn how to: Evolve software products and services into vibrant platform ecosystems. Orchestrate platform architecture and governance to sustain competitive advantage. Govern platform evolution using a powerful 3-dimensional framework. If you're ready to transform platform strategy from newspaper gossip and business school theory to real-world competitive advantage, start right here! Understand how architecture and strategy are inseparably intertwined in platform ecosystems. Architect future-proof platforms and apps and amplify these choices through governance. Evolve platforms, apps, and entire ecosystems into vibrant successes and spot platform opportunities in almost any-not just IT-industry.
Employing a software platform is an approach to achieve a higher degree of software reuse by enabling multiple software products to share the platform-provided services. However, platform development usually involves stakeholders from different application domains. Their application situations vary widely and thus nonfunctional requirements (NFRs) for the software platform must address a wider range of needs than those for a single product. This article describes lessons learned in developing NFRs for a large software platform, the challenging issues, and the techniques used to address them. The techniques are pragmatic and helped with NFR reconciliation and management. The improved quality of the NFR specifications has permitted automation of platform performance testing for the past two years.
Libro de metodología cualitativo para investigación en las ciencias sociales. La utilización de la computadora, el uso de datos y la recolección de los mismos. Se describen detalladamente numerosos métodos de datos y análisis.
Platform Revolution: How Networked Markets are Transforming the Economy -And how to Make Them Work for You
- G Parker
- M W Van Alstyne
- S P Choudary
G.G Parker, M.W. Van Alstyne, and S.P. Choudary, Platform Revolution: How Networked Markets are
Transforming the Economy -And how to Make Them Work for You. New York, NY: WW Norton & Company,
2016.
Atom Launches with Mission to be the Uber of Online Banking
- Guardian
Guardian. (2015, 29-11). Atom Launches with Mission to be the Uber of Online Banking. Available:
https:www.theguardian.com/business/2015/jul/25/atom-uber-online-banking.
- J Wareham
- P B Fox
- J L Cano Giner
J. Wareham, P.B. Fox, and J.L. Cano Giner, "Technology Ecosystem Governance," Organization Science, vol.
25, pp. 1195-1215, 2014.
for more information. This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication
- S Allier
- O Barais
- B Baudry
- J Bourcier
- E Daubert
- F Fleurey
S. Allier, O. Barais, B. Baudry, J. Bourcier, E. Daubert, F. Fleurey et al., "Multitier Diversification in Web0740-7459 (c) 2018 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/MS.2018.2874553, IEEE Software
based Software Applications," IEEE Software, vol. 32, pp. 83-90, 2015.