A joke with a real base-rate curve behind it.

1. What death means here

Death is an operational label. A public repository dies on its current last-push date after 12 calendar months with no later public push. The rule can call a finished, seasonal, or moved project dead. A bot push can keep an abandoned project alive. A private or deleted project can disappear from observation. The label measures public GitHub silence. It does not identify intent, project quality, or future revival. The survival model learns this label and returns one date.

The 12-month threshold sits in the middle of the published range. Studies of abandonment use thresholds from six months to 24 months. Coelho and Valente asked the maintainers of repositories that had been silent for a year whether the project was still maintained: among 118 respondents, 101 agreed it was not and 17 disagreed. That disagreement shows that public silence does not identify maintainer intent. The sources for every number on this page are listed in docs/MODEL.md.

2. The corpus

status

real

repositories fitted

6,363

observation date

2026-08-13

under 10 stars

6,007

younger than 3 years

2,091

censored share

27.1%

accept rate

84.0%

fork share seen

30.7%

draws

69,760

sampler seed

2026081401

id span per repo, 5th

1.91

id span per repo, median

2.64

id span per repo, 95th

3.37

residual draw spread

1.76x

The sample frame is GitHub's monotonic repository ID space, read through the public repositories endpoint. Each creation window is bracketed by two IDs. The crawl draws a uniform random ID, fetches the page of about 100 repositories that starts after it, and picks one of them uniformly at random. The last step matters: a keep-the-first rule would weight every repository by the ID gap in front of it, which is a measured bias near seven times.

The uniform pick reduces that bias but does not remove it. A repository that follows a sparse stretch of ID space is still slightly over-sampled, in proportion to the mean ID gap over the page it arrived on. The spread of that weight is the number above: the 95th percentile page span divided by the 5th. The rule it replaced was measured near seven times on single gaps. ID density follows how fast GitHub was creating repositories at that moment, not how long any repository survives, so the residual is close to unrelated to the outcome. That last sentence is an argument and not a measurement, and it is stated as one.

The crawl drops every fork at the sampler. A fork answers the commits call with the upstream project's history, which would corrupt every feature and inject false variance into the spread gate. The crawl never samples by last-push date, because that selects only dead repositories.

Author identities are hashed with a project salt at ingest. Only counts are stored. The tool contacts no repository owner, and it never posts to GitHub.

3. The landmark, the event, and the censoring rule

The training landmark sits at 6 months of repository age. Features come only from commits before the landmark. The label is the time from the landmark to the observed endpoint. The two never touch, which is what stops a circular fit.

Follow-up ends at the observation date minus 12 months. The observed endpoint is the earlier of the last push and that boundary. The event flag is 1 only when the last push falls before the boundary. A repository silent for six months is unknown, not dead, and it enters the fit as a censored row. A censored row says only that the true time is later than the observed one. It never says an event happened.

A repository whose last push falls at or before its landmark was not at risk at the landmark, so it leaves the corpus rather than enter the fit with a non-positive survival time.

not at risk at the landmark

48,482

kept

6,363

no commit before the landmark

132

4. The features

Six numbers reach the model. Every one is read only from commits that land before the landmark.

• log_commits · commits before the landmark, log transformed · coefficient -0.0538
• log_commits_recent · commits in the 90 days before the landmark, log transformed · coefficient 0.0423
• log_authors · distinct commit authors before the landmark, log transformed · coefficient 0.0120
• log_days_since_last · days from the last commit to the landmark, log transformed · coefficient -0.0267
• slowdown · the change in the median gap between commits, early against late · coefficient 0.0367
• slowdown_missing · a flag for a commit series too short to measure the change · coefficient -0.0237

Repository age is not a fitted feature. The training landmark is fixed, so age has no variance in the corpus and its coefficient cannot be estimated. The cost is real and it is stated here: inside the served age band, two repositories with the same commit history get the same date whatever their age. Age still decides whether a repository earns a model date at all.

5. The model

The fit is a Weibull accelerated failure time model. A Weibull hazard can only fall, hold flat, or rise, so it cannot represent a population where many projects stop early and a few run for years. The fit tries three families and selects on held-out likelihood rather than assume one.

rows in the fit

4,498

observed events

3,278

events per parameter

409.8

scale

1.1879

held-out rows

1,865

6. What the model can and cannot separate

Two numbers describe how well the model orders one repository against another. Harrell's C-index is the familiar one. Uno's C-index corrects for censoring, and it is the honest one to lead with, so it is first here.

uno c-index, held out

0.4937

harrell c-index, held out

0.4874

A C-index of about 0.65 means the model puts the shorter-lived repository first in about 65 of every 100 comparable pairs. A coin does that 50 times. It is not a hit rate on a calendar date, and no number on this site is.

The published work this tool builds on reports two rows for richer feature sets than this one. Its thinnest row reports 0.748 Harrell and 0.653 Uno, and even that row uses monthly star, issue, and pull-request histories this tool does not collect. Its full-telemetry row reports 0.846 Harrell and 0.781 Uno. Both rows describe a different and more popular population, so both are upper bounds for a richer feature set than this one, and neither is a claim about this model.

7. The spread gate

Before the model may print its own date, it has to show that it separates the population it serves. The gate runs on a held-out slice cut to the product's own population: under 10 stars, at most two distinct authors, and enough follow-up to matter.

The gate did not pass. Every result therefore leads with the labelled base-rate median for a comparable project, and says so on the page, in the calendar file, and on the badge. The model’s own date ships when the gate passes.

8. The band the model serves

At training the landmark is fixed. At scan time the landmark is the moment of the scan. The two only line up for a repository between 3 and 12 months old, so that is the only band that gets a model date. Outside it, the result leads with the base rate and names the reason.

9. The quiz

The six questions are proxies for the same six measurements the scanner takes. Five of them are countable, and each answer carries the count its own label names. The scanner feeds the model the number it measured, and the quiz feeds the model the number the answer names, on the same scale. That is what makes both paths one model. The sixth question asks how the pace changed, which nobody can state as a number, so that answer alone maps onto a corpus quantile.

An earlier version mapped every answer onto a corpus quantile. It was wrong, and the error was large. The corpus is a uniform draw from the public repository ID space, and most of that space is a repository somebody pushed once. Measured on the crawl so far, the answer over 200 commits reached the model as 21 commits, and three of the four answers about team size all reached it as one author. A person who answers this quiz is not a uniform draw from that space. They are a person with a side project.

A quiz answer carries more error than a count. A person estimating their own commit history lands in a band, and the scanner would read the exact number. The quiz therefore inherits every limitation on this page, plus the width of the band each answer falls in.

10. The percentile

A percentile with no named window means nothing, so no surface prints one. Every percentile on this site names its reference set: how many distinct public repositories it holds, and both inclusive dates of the window. Ties split at the midrank, and a repository is excluded from its own comparison. Under 100 scored repositories in a window, no percentile renders at all.

11. The transfer caveat

The corpus was crawled on 2026-08-13. Every visitor arrives later, and the gap grows every month. GitHub's population changes, and a model fitted at one date describes that date. Nothing on this site corrects for that gap, and this paragraph is the correction.

12. What this site will never say

• Not that a project will die on the date. It is a median.
• Not that the model is reliable, confident, or accurate.
• Not that a date is correct to within any number of days.
• Never a bare percentile, with no window and no count.
• Never a number the crawl has not measured, without the word sample beside it.

These are not intentions. A test in the build checks every one of them on every page, and a build that breaks one does not ship.