Как Предсказать «Смерть» Open-Source Проекта С Помощью Статистики Выживания.

Введение

Жизненный цикл проекта с открытым исходным кодом характеризуется нелинейной динамикой. После первоначального всплеска интереса значительная часть репозиториев переходит в режим технической поддержки, затем — эпизодических обновлений, и лишь впоследствии полностью прекращает развитие. Существующие методики классификации (например, разделение на «активные» и «заброшенные» по пороговому значению дней без коммитов) не учитывают два существенных фактора:

1. Временную динамику: вероятность «заморозки» проекта изменяется в зависимости от этапа его существования.
2. Правостороннее цензурирование: на момент проведения анализа часть проектов сохраняет активность, и точное время прекращения их развития остаётся неизвестным.

Методы статистики выживаемости (survival analysis), первоначально разработанные для медицинских исследований и задач надёжности технических систем, эффективно адаптируются к моделированию «времени до наступления события» (time-to-event). В контексте данного исследования событием считается переход репозитория в состояние «заморозки», а временной шкалой — количество месяцев, прошедших с момента создания или первой значимой активности.

Данные и определение события

Для построения аналитической модели необходим следующий набор данных:

• repo_id — уникальный идентификатор репозитория;
• start_date — дата создания репозитория или дата первого коммита;
• last_activity_date — дата последнего зафиксированного события: коммита, pull request или issue, связанного с изменениями в коде;
• snapshot_date — дата формирования выборки (среза данных).

Определение «заморозки». Репозиторий классифицируется как «замороженный», если в течение периода T_freeze = 6 месяцев не было зафиксировано ни одного коммита, а также ни одного обращения (issue/PR), требующего модификации программного кода. Указанный порог может быть адаптирован под специфику предметной области (например, 3 месяца для веб-фреймворков, 12 месяцев для системных утилит).

Цензурирование. Если на дату snapshot_date репозиторий продолжает демонстрировать активность, соответствующее наблюдение считается цензурированным: известно, что проект «выжил» до указанного момента, однако точное время наступления события («смерти») остаётся неизвестным. Данный аспект принципиально отличает задачу от стандартной регрессионной постановки и обуславливает предпочтительность использования оценки Каплана–Мейера вместо расчёта простых средних значений.

Статистика выживания: интуитивное объяснение

Функция выживаемости S(t) характеризует вероятность того, что проект сохранит активность дольше момента времени t:

где T — случайная величина, обозначающая «время до заморозки».

Оценщик Каплана–Мейера формирует ступенчатую кривую S(t), обновляя её значения в моменты наблюдения «смерти» проектов. Расчётная формула имеет вид:

где:

•  — моменты времени, в которые зафиксирована «заморозка» хотя бы одного проекта;
•  — количество проектов, перешедших в состояние «заморозки» в момент ;
•  — число проектов, находящихся «под риском» непосредственно перед моментом  (активных и ещё не цензурированных).

Аналогия для понимания. Представьте, что исследователь наблюдает за 100 новыми репозиториями. Спустя 3 месяца 10 из них прекращают активность. Из оставшихся 90 ещё 5 перестают получать коммиты к 6-му месяцу, а 20 проектов исключаются из наблюдения по причине цензурирования (они остаются активными на момент сбора данных). Метод Каплана–Мейера последовательно учитывает каждый из этих этапов, не исключая «живые» проекты из анализа и не искажая результаты за счёт усреднения.

Реализация на Python с использованием библиотеки lifelines

Для практических расчётов рекомендуется использовать библиотеку lifelines. Ниже представлен минимальный рабочий пайплайн обработки данных.

# Импорт необходимых библиотек

import pandas as pd

import numpy as np

from lifelines import KaplanMeierFitter

import matplotlib.pyplot as plt

# 1. Загрузка данных (пример: CSV с данными GitHub API / GHTorrent)

# Ожидаемые столбцы: repo_id, created_at, last_activity_at, snapshot_date

df = pd.read_csv("github_repos_activity.csv", 

                 parse_dates=["created_at", "last_activity_at", "snapshot_date"])

# 2. Расчёт длительности (в месяцах) и статуса события

FROZE_MONTHS = 6

df["duration_months"] = (df["last_activity_at"] - df["created_at"]).dt.days / 30.44

# Событие произошло, если проект замёрз до snapshot_date

df["event"] = ((df["snapshot_date"] - df["last_activity_at"]).dt.days / 30.44) >= FROZE_MONTHS

# Если проект активен на snapshot_date, длительность обрезаем, event = 0 (цензурирование)

mask_active = ~df["event"]

df.loc[mask_active, "duration_months"] = (

    (df.loc[mask_active, "snapshot_date"] - df.loc[mask_active, "created_at"]).dt.days / 30.44

)

# 3. Оценка Каплана–Мейера

kmf = KaplanMeierFitter()

kmf.fit(durations=df["duration_months"], event_observed=df["event"], label="Все репозитории")

# 4. Визуализация

plt.figure(figsize=(8, 5))

kmf.plot_survival_function(ci_show=True)

plt.axhline(0.5, color="gray", linestyle="--", linewidth=1)

plt.axvline(kmf.median_survival_time_, color="red", linestyle="--", linewidth=1)

plt.xlabel("Месяцы с момента создания")

plt.ylabel("Вероятность активности, S(t)")

plt.title("Кривая выживаемости open-source проектов")

plt.grid(True, alpha=0.3)

plt.show()

Интерпретация результатов и «период полужизни»

После построения кривой выживаемости возможно извлечение ряда практических метрик:

• Медианное время жизни — момент, когда . Данная величина соответствует «периоду полужизни»: к этому сроку половина проектов из выборки уже перешла в состояние «заморозки».
• Вероятность выживания через N месяцев: значение функции выживаемости в точке N. Например,  означает, что спустя 2 года 62 % репозиториев сохраняют активность.
• Сегментный анализ: при разбиении выборки по признакам (язык программирования, количество звёзд, размер сообщества) возможно построение нескольких кривых на едином графике для сравнительной оценки устойчивости различных экосистем.

На реальных данных GitHub (выборки за период 2015–2023 гг.) кривая выживаемости, как правило, демонстрирует характерную форму: резкое снижение в первые 3–6 месяцев (отсев экспериментальных форков), за которым следует плавный пологий спад. Медианное время жизни обычно составляет 18–30 месяцев для типовых пользовательских репозиториев и превышает 40 месяцев для проектов с количеством звёзд более 500.

Заключение и ограничения

Применение методов статистики выживаемости к данным GitHub позволяет перейти от бинарных классификаций к вероятностным прогнозам, учитывающим временной фактор и цензурирование наблюдений. Оценка Каплана–Мейера обеспечивает прозрачную, не требующую сложных априорных допущений, оценку риска «заморозки» проекта, которую легко интерпретировать и визуализировать.

Ограничения методики:

1. Определение «смерти» проекта через пороговое значение месяцев без активности носит субъективный характер и может не учитывать проекты, находящиеся в режиме долгосрочной поддержки (LTS).
2. Базовая модель не учитывает ковариаты (размер команды, наличие финансирования, использование CI/CD). Для включения данных факторов требуется применение регрессии Кокса (Cox PH) или методов ансамблевого обучения для задач выживания.
3. Данные GitHub API подвержены выборочному смещению: приватные репозитории, архивированные проекты и репозитории без трекера обращений могут искажать репрезентативность выборки.

Перспективы развития: расширение модели за счёт динамического обновления кривых выживаемости, применение библиотеки scikit-survival для предсказания индивидуальных рисков, интеграция с метриками сообщества CHAOSS (bus factor, time to response, contribution diversity). В сочетании с мониторингом активности такой подход может стать полезным инструментом для оценки надёжности зависимостей в enterprise-среде и поддержки принятия решений о форках или спонсорстве проектов.