💻 computer science

Quantifying Competitive Relationships Among Open-Source Software Projects

This paper introduces "Mutual Impact Analysis of OSS (MIAO)," an automated method using macroeconomic modeling techniques to quantify competitive relationships among open-source software projects, successfully identifying development cessation caused by competition with up to 81% accuracy and predicting project decline one year in advance with 77% accuracy.

Original authors: Yuki Takei, Toshiaki Aoki, Chaiyong Ragkhitwetsagul

Published 2026-02-20

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: Yuki Takei, Toshiaki Aoki, Chaiyong Ragkhitwetsagul

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine the world of Open-Source Software (OSS) not as a quiet library of code, but as a bustling, high-stakes marketplace. In this market, thousands of projects are trying to sell their "products" (features, tools, libraries) to developers. Sometimes, a new, shinier product arrives, and the old one starts to fade away.

For a long time, researchers tried to predict which projects would survive by looking at internal factors: Is the code clean? Are the developers happy? Is the documentation good?

But this paper argues that's like trying to predict a car crash by only checking the engine, while ignoring the fact that a giant truck just swerved into your lane. The real danger often comes from external competition.

Here is a simple breakdown of how the authors, Takei, Aoki, and Ragkhitwetsagul, figured out how to measure this competition.

1. The Problem: The "Chainer vs. PyTorch" Mystery

Think of two runners in a race: Chainer and PyTorch. Both were running the "Deep Learning" marathon.

At first, they were both running fast.
Then, PyTorch started sprinting.
Chainer didn't just slow down; it stopped running entirely. The company behind Chainer actually announced, "We are quitting this race and joining PyTorch's team."

The big question is: How do we know, before Chainer stopped, that PyTorch was going to kill it?
It's hard to prove because competition is invisible. You can't just look at a spreadsheet and say, "Ah, PyTorch's activity caused Chainer's death." You need a way to measure the invisible "shockwaves" one project sends to another.

2. The Solution: Borrowing from Economists (The "Weather Forecast" for Code)

The authors realized that software projects behave a bit like economies.

In economics, if the price of oil goes up, it might cause a ripple effect that changes the price of plastic, then the price of toys, and so on.
In software, if Project A gets a sudden burst of activity (a "shock"), does Project B slow down? Does Project C speed up?

To measure this, they used a tool called MIAO (Mutual Impact Analysis of OSS).

The Analogy: Imagine you are a weather forecaster. You don't just look at the clouds today; you use a complex model to see how a storm in one part of the country will change the wind in another part three days later.
The Tool: They used a mathematical model called SVAR (Structural Vector Autoregressive). It's a fancy way of saying: "Let's look at the history of three projects together and calculate exactly how a 'sneeze' in Project A causes a 'cough' in Project B."

3. How MIAO Works (The Three-Step Dance)

The method works in two main phases:

Phase 1: The "Shock" Test
They take the history of commits (code updates) for a target project and its two main rivals. They ask the computer: "If Project A suddenly had a huge spike in activity, how would Project B react 1 month later? 6 months later?"

They do this over and over, breaking time into chunks (like looking at 1-year periods, then 2-year periods) to see if the relationship changes as the projects age.

Phase 2: The "Scorecard"
The computer spits out a bunch of numbers. The authors turn these into a MIAO Score.

Positive Score: Project A is helping Project B (maybe they are friends or partners).
Negative Score: Project A is hurting Project B (they are enemies fighting for the same users).
The Twist: They found that the most dangerous signal isn't always the rival hurting you. Sometimes, the signal is you hurting the rival. If your project is so dominant that it's crushing the competition, it might actually be a sign that you are the "winner" and the other is dying. Conversely, if you are trying to fight a rival but they are ignoring you, you might be the one losing.

4. The Results: Can We Predict the Crash?

They tested this on 187 groups of software projects (a target project + 2 competitors).

The Retrospective Test (Looking Back): They asked, "Can MIAO look at the past and tell us which projects died because of competition?"
- Result: It was right 81% of the time. It successfully identified the "Chainers" of the world.
The Predictive Test (Looking Forward): They asked, "Can MIAO look at the data from one year ago and predict which projects would die in the future?"
- Result: It was right 77% of the time.

This is huge! It means MIAO acts like an early warning system. It can tell a project maintainer: "Hey, your competitor is gaining too much ground, and your relationship score is dropping. You need to change your strategy now, or you'll be obsolete in a year."

5. The Big Discovery: The "One-Way Street"

The most interesting finding was about the direction of the fight.

Old belief: The winner crushes the loser. (Competitor $\to$ Target is bad).
New finding: It's often about unidirectional influence.
- Sometimes, the target project is so strong it's actively suppressing the competitor (Target $\to$ Competitor is bad for the competitor).
- Sometimes, the competitor is so strong it's suppressing the target (Competitor $\to$ Target is bad for the target).
- Key Insight: If the influence is one-way (one side is dominating the other), that's a sign of a "Rising Event" (REV)—meaning one project is about to take over and the other is about to die. If the influence is two-way (they are fighting back and forth), they might both survive.

Why Should You Care?

For Project Maintainers: Don't just look at your own code. Use tools like this to watch your rivals. If the "score" says you are losing the war, you can pivot your strategy before it's too late.
For Companies: If you are building a product on top of an open-source library, don't just pick the one with the most stars. Pick the one that isn't being crushed by a competitor. MIAO helps you pick the "survivors."
For Everyone: It proves that software isn't just about code; it's about ecosystems. Just like in nature, if a new predator enters the forest, the old prey doesn't just get sick; it gets eaten. This paper gives us the telescope to see that happening before it's too late.

In short: The authors built a "seismograph" for the software world. It measures the tremors of competition so we can predict which software projects will survive the earthquake and which will crumble.

1. Problem Statement

Open-source software (OSS) ecosystems are characterized by a continuous cycle of rise and fall driven by competition. While many studies focus on internal factors (e.g., code quality, developer activity) to predict project sustainability, the impact of external competitive relationships remains poorly understood and difficult to quantify.

The Gap: Existing methods struggle to empirically measure how the emergence of a strong competitor causes an existing project to cease development (a phenomenon the authors term a "Rising Event" or REV).
The Challenge: Quantifying these relationships requires complex causal inference over time-series data, as competitive dynamics evolve and are often non-linear.
Motivation: The case of Chainer vs. PyTorch illustrates this: Chainer, once a leading deep learning framework, ceased development after PyTorch gained dominance. The paper aims to create a method to detect such competitive pressures before a project collapses.

2. Methodology: MIAO (Mutual Impact Analysis of OSS)

The authors propose MIAO, an automated method that adapts econometric models to analyze OSS activity time series.

Core Components

Data Representation:
- Activity Time Series: The study uses the number of commits as a proxy for project activity.
- Dataset Construction: 187 project groups were mined from GitHub. Each group consists of a Target project and two Competitors.
  - REV Class: 87 groups where the target ceased development due to competition (identified via README migration notices).
  - Non-REV Class: 100 groups where the target remained active.
- Preprocessing: To handle non-stationarity, the authors employ fractional differencing (rather than integer differencing) to preserve long-term memory in the data while ensuring stationarity for VAR models.
Statistical Model (SVAR):
- MIAO utilizes a Structural Vector Autoregressive (SVAR) model. Unlike standard VAR, SVAR imposes structural constraints to model instantaneous causal relationships between variables.
- The model is defined as: $B_0 y_t = c + B_1 y_{t-1} + \dots + B_p y_{t-p} + u_t$ , where $y_t$ represents the activity vector of the target and competitors.
Impulse Response Functions (IRF):
- The core of the analysis is the IRF, which quantifies how a "shock" (a sudden change in activity) in one project propagates to others over time.
- Phase 1 (Calculation): The analysis is divided into multiple time periods ( $T_m$ ) to account for the OSS lifecycle (Born $\to$ Obsolescence). IRFs are calculated for each period.
- Phase 2 (Scoring): The authors aggregate IRFs into a Cumulative Impulse Response (SCE) and then into a MIAO Score (MS).
  - $MS_{ij}$ represents the cumulative negative impact of project $j$ on project $i$ .
  - A positive $MS_{ij}$ indicates a strong negative impact (competition) from $j$ on $i$ .
Robustness Enhancements:
- Period Shifting: To mitigate sensitivity to specific start/end dates, the analysis is run with shifted time windows (up to 3 months), and the results are averaged (similar to bagging in ensemble learning).
- Variable Ordering: For the REV class, the order is fixed (Competitor 1 $\to$ Competitor 2 $\to$ Target). For Non-REV, all permutations are tested to ensure sensitivity.

3. Key Contributions

Novel Methodology (MIAO): The first framework to quantitatively measure temporal competitive relationships in OSS using econometric SVAR and IRF models.
Empirical Validation: A large-scale study mining 187 OSS project groups from GitHub, distinguishing between projects that failed due to competition and those that survived.
Predictive Capability: Demonstrated that MIAO can predict project cessation one year in advance with high accuracy.
Theoretical Insight: Identified that unidirectional influence is the key signature of competitive decline, challenging the assumption that mutual competition is always symmetric.

4. Experimental Results

The study evaluated MIAO using Decision Trees for classification.

Retrospective Classification (EVAL1):
- Accuracy: Up to 81% (Average 75% across permutations).
- F1-Score (REV): 0.71.
- Finding: The model successfully distinguishes projects that ceased due to competition from those that did not.
Predictive Classification (EVAL2):
- Setup: The final year of data was masked to simulate predicting the future one year in advance.
- Accuracy: Up to 77% (Average 73%).
- Significance: This proves MIAO can serve as an early-warning system, detecting competitive threats before a project officially stops development.
Key Factors (RQ2):
- Decision Tree Analysis: Revealed that the degree of unidirectional influence is the primary predictor.
- Mechanism:
  - In the predictive phase (1 year prior), the key indicator is a strong negative impact from the competitor on the target ( $Competitor \to Target$ ).
  - In the retrospective phase (full data), the indicator shifts to the target having a large impact (positive or negative) on the competitor ( $Target \to Competitor$ ).
- Interpretation: As a project begins to decline, the competitor's activity starts to negatively impact the target. Eventually, the declining project loses the ability to influence the competitor, or its activity becomes a "shock" that the competitor absorbs without reaction.

5. Significance and Implications

For OSS Maintainers: MIAO acts as a quantitative early-warning system. Maintainers can monitor competitive pressures and proactively adjust roadmaps or form alliances before a project becomes obsolete.
For OSS Adopters: Organizations can use MIAO to assess the long-term viability of a technology stack, avoiding projects showing early signs of competitive decline.
For Researchers: The study shifts the focus from internal project metrics to external ecosystem dynamics, providing a scalable, data-driven methodology to study the "rise and fall" of software technologies.

6. Limitations and Future Work

Validity: The study relies on commit counts and assumes README migration notices are accurate indicators of competitive cessation.
Scope: The analysis excludes fork-based competition (where a project splits from another) due to multicollinearity issues in the VAR model.
Dimensionality: The model is fixed to 3 variables (1 target + 2 competitors) to ensure statistical comparability, which may not capture complex ecosystems with many rivals.
Future Directions: Expanding the dataset, incorporating alternative activity signals (e.g., issues, releases), and developing methods to handle fork-based competition.