Large-scale software development has become a highly collaborative and geographically distributed endeavour, especially in open-source software development ecosystems and their associated developer communities. It has given rise to modern development processes (e.g., pull-based development) that involve a wide range of activities such as issue and bug handling, code reviewing, coding, testing, and deployment. These often very effort-intensive activities are supported by a wide variety of tools such as version control systems, bug and issue trackers, code reviewing systems, code quality analysis tools, test automation, dependency management, and vulnerability detection tools. To reduce the complexity of the collaborative development process, many of the repetitive human activities that are part of the development workflow are being automated by CI/CD tools that help to increase the productivity and quality of software projects. Social coding platforms aim to integrate all this tooling and workflow automation in a single encompassing environment. These social coding platforms gave rise to the emergence of development bots, facilitating the integration with external CI/CD tools and enabling the automation of many other development-related tasks. GitHub, the most popular social coding platform, has introduced GitHub Actions to automate workflows in its hosted software development repositories since November 2019. This chapter explores the ecosystems of development bots and GitHub Actions and their interconnection. It provides an extensive survey of the state-of-the-art in this domain, discusses the opportunities and threats that these ecosystems entail, and reports on the challenges and future perspectives for researchers as well as software practitioners.
Software Heritage is the largest public archive of software source code and associated development history, as captured by modern version control systems. As of July 2023, it has archived more than 16 billion unique source code files coming from more than 250 million collaborative development projects. In this chapter, we describe the Software Heritage ecosystem, focusing on research and open science use cases.On the one hand, Software Heritage supports empirical research on software by materializing in a single Merkle direct acyclic graph the development history of public code. This giant graph of source code artifacts (files, directories, and commits) can be used-and has been used-to study repository forks, open source contributors, vulnerability propagation, software provenance tracking, source code indexing, and more.On the other hand, Software Heritage ensures availability and guarantees integrity of the source code of software artifacts used in any field that relies on software to conduct experiments, contributing to making research reproducible. The source code used in scientific experiments can be archived-e.g., via integration with open-access repositories-referenced using persistent identifiers that allow downstream integrity checks and linked to/from other scholarly digital artifacts.
This chapter defines and presents different kinds of software ecosystems. The focus is on the development, tooling and analytics aspects of software ecosystems, i.e., communities of software developers and the interconnected software components (e.g., projects, libraries, packages, repositories, plug-ins, apps) they are developing and maintaining. The technical and social dependencies between these developers and software components form a socio-technical dependency network, and the dynamics of this network change over time. We classify and provide several examples of such ecosystems. The chapter also introduces and clarifies the relevant terms needed to understand and analyse these ecosystems, as well as the techniques and research methods that can be used to analyse different aspects of these ecosystems.
The use of third-party packages is becoming increasingly popular and has led to the emergence of large software package ecosystems with a maze of inter-dependencies. Since the reliance on these ecosystems enables developers to reduce development effort and increase productivity, it has attracted the interest of researchers: understanding the infrastructure and dynamics of package ecosystems has given rise to approaches for better code reuse, automated updates, and the avoidance of vulnerabilities, to name a few examples. But the reality of these ecosystems also poses challenges to software engineering researchers, such as: How do we obtain the complete network of dependencies along with the corresponding versioning information? What are the boundaries of these package ecosystems? How do we consistently detect dependencies that are declared but not used? How do we consistently identify developers within a package ecosystem? How much of the ecosystem do we need to understand to analyse a single component? How well do our approaches generalise across different programming languages and package ecosystems? In this chapter, we review promises and perils of mining the rich data related to software package ecosystems available to software engineering researchers.
The concept of ecosystem emanates from ecology and subsequently has been broadly used in business studies to describe and investigate complex interrelationships between companies and other organizations. Concepts that are transferred from other disciplines (and used both in research and in practice) can, however, be ambiguous and problematic. For example, the use of the ecosystem concept has been questioned in the literature. To better understand the potential ambiguities between the business ecosystem concept and other related concepts, this study presents a conceptual analysis of business ecosystem. We continue by analytically comparing business ecosystem with other concepts used to describe business relationships, namely industry, population, cluster, and inter-organizational network. The results indicate a need for conceptual clarity when describing business networks. We conclude with a synthesis and discuss under what circumstances using the business ecosystem concept may add value for research and practice. The paper contributes to the business ecosystem literature by positioning the business ecosystem concept in relation to other closely related concepts
. Since CPQ (Configure, Price, Quote) suppliers are often referring to their products as platforms, a question arises as to what extent present CPQs have such characteristics supporting platform ecosystems. In this paper, the features of seven case CPQs are compared to each other and to the critical characteristics of a multisided platform. CPQs have diverse features, and most are very similar to their competitors. CPQs are internal platforms, but they typically do not have the characteristics of industry platforms that enable multisided ecosystems. Some CPQs are clearly on the way to becoming true multisided platform ecosystem enablers, but none of the case CPQs studied was ready yet.
Developing countries take frog leaps in technological advance. For example, moving to 4G communications from scratch. This reveals tremendous opportunities as infrastructure for advanced service delivery is suddenly in place. As the technological advancement is so disruptive, a lot of prefacing needs to be carried out prior to an ecosystems’ emergence. This article presents an experience report on ecosystem prefacing for emerging developing country markets. We provide an analysis of the Tanzanian working environment; noting aspects that are present for a developing country, unique to the distinct culture, and similar to industrial countries. We then apply an ecosystem prefacing process that actively finds challenges and solutions for a fixed application context whilst acknowledging the previous aspects. For this experience report, we gather empirical data by executing the process in two-phase innovation workshop and stakeholder co-operation event where the fixed application context consists from SmartCity concept based on a major ICT vendor.
Ecosystems, platforms and app stores have become a de factomodel for the modern software business. In the curated marketplaces of software ecosystems, independent software vendors are able to distribute their products and services to the customers. As the software industry has a tendency towards the winner-takes-all phenomenon, often only few of the competing ecosystems survive and share the market. As the software vendors are depending on the ecosystems to be able to publish their offerings, the orchestrators have achieved ultimate power to decide who are eligible to work and who are not. This study presents an ethical discussion on the ecosystem ruling dilemma: ecosystem focal company’s right to orchestrate what they offer against restricting liberty of independent software vendors. In the analysis, John Rawls’ theory of justice is used as a framing philosophical concept.
. Studying new venture success and failure is central to understanding the dynamics of new venture persistence. Investments, would they be subsidies, venture capital or shareholder investments, are seen as a statement of venture quality, but also as a tool for rapid growth. This study is a exploratory study that focus on creating understanding on if investment serve as a explanatory factor to increased activity (revenue). This study address whether software start-ups differ if the company has early stage investments and what is this relationship with the company being active later. We use the set of over 1,000 Finnish companies founded during 2010–2013 as an empirical material for our inquiry. The results show that, invested companies are different than not invested companies, but revenues are higher for the latter.
Many software ecosystems comprise rival vendors that cooperate and compete with each other simultaneously. This type of relationship is termed coopetition wherein enterprises cooperate to increase collective benefits while competing to maximize their individual gains. In such a relationship, strategic moves by an actor can have significant consequences for other actors in the ecosystem. This paper proposes a model-based approach for analyzing strategic moves in software ecosystems using i* and game trees. We offer a methodology for developing complementary i* models and game trees. We also explicate guidelines for applying this methodology in a consistent manner. We draw upon a published case study as an illustrative example and instantiate a model based on it to assess the strengths and weaknesses of this methodology.
Today, the competition and speed in software development has increased. Companies are forced to produce more value to the customer at an accelerating pace. This has led to the phenomena where companies, who can leverage existing code, ecosystems and services to rapidly produce value to the customer can scale their operation faster. This has led to many companies becoming a part of a selected ecosystem, locking themselves into it, but reaping the benefits. Here we investigated what kind of ecosystems software companies use to grow and in what role do they want to participate in these ecosystems to leverage them for their growth. Two main types were identified, software ecosystems which provide ready made technologies to focus on providing added value to the customer, not in infrastructure development, and mutualistic software ecosystems where the value provided to the client is a sum of services provided by multiple companies in the ecosystem.
. Hybrid Open Source Software projects are virtual organizations that express characteristics of both static and dynamic behavior. They are choreographed through complex organizational structures that mix centralized governance with distributed community drivenness. While many communities use standard software tools to support their development processes, each community has its own ways of working and invisible power structures that influence how contributions are submitted, how they are verified and how decisions about the long-term direction of the software product are made. Navigating this environment is especially challenging for new developers who need to prove their abilities to gain rights to make contributions. This paper provides a viewpoint on the factors that influence a new developer’s perception of the hybrid OSS developer community landscape. We apply an established developmental theory to build an initial model for the developer’s context and discuss the model’s validation, providing its practical and theoretical implications for building and managing on-line developer communities.
