The Six-Week Silence: Mapping Where New Contributors Actually Fall Off

Every mature open-source project has seen it. A conference talk lands well, a blog post circulates, a 'good first issue' label gets applied with genuine enthusiasm — and for roughly six weeks, the repository hums with unfamiliar usernames. Then the traffic drops off. Not gradually, the way seasonal interest fades, but sharply, as if someone closed a valve.

The pattern is consistent enough that it deserves a name: the onboarding plateau. And the uncomfortable question is not why newcomers arrive — projects are generally good at attracting attention — but why so few of them survive the journey from first commit to second.

The Shape of the Drop-Off

Looking at contribution data from several widely deployed projects — CI run histories, pull request lifecycles, issue-to-PR conversion rates — the same inflection points appear again and again:

• Days 0–3: the build wall. A large share of would-be contributors never open a pull request at all. They clone the repository, run the setup instructions, and hit an environment failure. If the fix requires tribal knowledge that lives only in a maintainer's head, the attempt ends there. These failures are nearly invisible in project metrics because nothing was ever submitted — the contributor simply vanished.
• Days 4–14: the review vacuum. First pull requests that do get opened frequently sit unanswered. For a newcomer, a two-week silence reads as rejection, even when the maintainer's queue simply got long. Many never return to the thread.
• Days 15–30: the etiquette gap. The contributors who survive review often stall on unwritten norms: commit message conventions, the project's preferred style for changelog entries, whether to rebase or merge. None of this is documented, because to insiders it is invisible.
• Weeks 5–6: the plateau. Contributors who cleared every hurdle still need a reason to come back. If no one assigns them a follow-up issue or invites them into a discussion, momentum dies quietly.

The compounding effect is brutal. Even a 30 percent loss at each stage leaves you with roughly a quarter of your original intake — and most projects lose far more.

Instrumentation, Not Intuition

The standard response to contributor attrition is to write more documentation. That instinct is reasonable but blind. Without knowing where people actually stall, you are adding prose to sections that were never the problem.

The alternative is what we would call contribution instrumentation: treating onboarding the way a product team treats a signup funnel, with a measurable event at every stage.

The mechanics are unglamorous but tractable. Track clone-to-first-commit latency, even coarsely, via telemetry in your build tooling or a post-install survey. Tag every first-time pull request with a first-pr label so its time-to-first-response can be measured independently. Log which setup step fails most often in CI or in a structured issue template. None of this requires surveillance of individuals — aggregate curves are sufficient, and contributor privacy should be a design constraint from the start.

Once the funnel is measured, the fixes become obvious and prioritized. One project that adopted this approach discovered that 40 percent of abandoned setups traced to a single optional dependency that failed silently on Apple Silicon. A one-line fix in the bootstrap script did more for contributor retention than a quarter's worth of documentation sprints.

Fix the Leakiest Step First

The discipline that makes instrumentation valuable is refusing to spread effort evenly. In most funnels, one stage accounts for the majority of the loss. Fixing that stage — and only that stage — before moving on is the difference between engineering and fidgeting.

A few heuristics drawn from the projects we examined:

• If clones outnumber first commits by a wide margin, your setup instructions are lying, or your build has hidden platform assumptions. Verify the quickstart on a clean machine — a fresh cloud VM, not a maintainer's laptop — every release.
• If first pull requests age past 72 hours without a response, you have a review capacity problem, not a documentation problem. An explicit triage rotation, even a light one, outperforms any amount of CONTRIBUTING.md polish.
• If contributors pass review but never return, the gap is social, not technical. Assign a concrete second issue in the merge message. It takes ten seconds and it is the single highest-leverage habit we observed.

The Plateau Is a Design Artifact

The six-week silence is not a law of nature. It is the compound interest of small frictions, each individually forgivable, none of them measured. Projects that survive succession and scale are the ones that treat contributor onboarding as infrastructure — versioned, monitored, and maintained like everything else in the repository.

Open-source infrastructure is built in the open. That principle should apply to the funnel that produces its builders, too.