I Scanned 10,000 Open Source Repos on GitHub: The 5 Patterns That Actually Predict Project Survival

Ever looked at a dead GitHub repo and wondered, “How did that die while that other one thrives?”

I’ve been there. A lot.

I Asked Claude Code and Cursor to Refactor a Legacy Node.js API — What I Learned About AI Coding Tool Limits

I Asked Claude Code and Cursor to Refactor a Legacy Node.js API — What I Learned About AI… ...

After maintaining a few open source projects over the years—and watching plenty of others rot in silence—I got tired of guessing. So we did something about it.

My team at ECOA AI (shoutout to our developers in Ho Chi Minh City and Can Tho who helped crunch the numbers) built a scraper that analyzed 10,000 active repositories on GitHub. We looked at repos that started between 2018 and 2021, then tracked their health through 2025.

Vietnam Outsourcing: Why Southeast Asia’s Rising Tech Hub Is Beating India and Philippines

TL;DR: Vietnam outsourcing is exploding because of its young, highly skilled engineering talent, competitive costs (40–50% lower than… ...

The goal was simple: find the metrics that actually predict long-term survival. Not vanity metrics. Real signals.

Here’s what we found.

Pattern #1: Issue Response Time Under 48 Hours

This one blew me away.

84% of repos with a median first-response time under 48 hours were still active after 3 years. For repos where issues sat for over a week? That number dropped to 22%.

It’s not about fixing everything. It’s about acknowledging that someone cared enough to open an issue.

We saw a pattern: maintainers who replied fast—even with “I’ll look at this next sprint”—kept contributors engaged. Silence kills momentum faster than any bug.

The hard data: Repos with a median response time under 24 hours had a *5.2x higher contributor retention rate* than those averaging over 72 hours.

If you’re maintaining a project, set up a GitHub Action to auto-respond with a triage message. Or better yet, integrate with a bot that routes issues to the right person. We’ve used this exact approach for our own projects.

Pattern #2: Consistent Commit Frequency (Not Volume)

Here’s another counterintuitive finding.

Commit volume doesn’t predict survival. I saw repos with 10,000 commits that were completely dead, and repos with 200 commits that were thriving.

What matters? Consistency.

Projects that had at least one commit every 14 days over a 6-month period had a 91% survival rate. Projects that went dark for more than 30 days? That number crashed to 34%.

Think about your own behavior. When you hit a repo and see no commits for 3 months, do you invest your time in it? No. Nobody does.

The fix is simple: schedule small, regular updates. Even if it’s just updating a dependency or fixing a typo in the docs. Show the world you’re alive.

Our Vietnamese team jokes about this: “GitHub is like a Tamagotchi. Feed it every day or it dies.”

Pattern #3: PR Merge Ratio Above 60%

This one’s for the maintainers who gatekeep too hard.

Repos with a PR merge ratio above 60% saw 3x more repeat contributors. Repos below 30%? Almost always dead within 18 months.

I get it. You have standards. Your codebase is pristine. But here’s the uncomfortable truth: you’re not building a museum. You’re building software.

The data showed that overly strict maintainers created a bottleneck. Contributors submitted once, got rejected (or ignored), and never came back.

Compare that to projects where 60-80% of PRs got merged—even if with significant changes requested. Those repos grew. They built communities.

One pattern we noticed: successful repos used a “merge fast, refactor later” approach for non-critical contributions. They’d pull in the code, then clean it up in a follow-up. That kept the contribution loop tight.

Pattern #4: Documentation Updates Track with Code Changes

This one was a surprise even to me.

Repos where the docs/ folder had commits within 7 days of code changes had a 78% higher chance of surviving 3+ years.

Why? Because it signals that the maintainers care about *usability*, not just technical excellence.

We found a strong correlation between documentation freshness and contribution quality. When docs are up to date, new contributors onboard faster. They make fewer mistakes. They ship better PRs.

It’s a virtuous cycle.

Look at your own repo. When was the last time you updated the README? If it was more than 3 months ago, your project is showing signs of decay—even if the code is perfect.

Pattern #5: Active Issue Labeling and Triage

This one separates the pros from the amateurs.

Repos that used a consistent labeling scheme (good first issue, bug, enhancement, needs info) had 4x more first-time contributors. The key word is *consistent*.

We saw repos with 20 custom labels that no one understood. And repos with just 5 labels that guided every single interaction.

The magic isn’t in the number of labels. It’s in the workflow behind them.

Successful projects used labels as a signal: “good first issue” meant *actually* easy to fix, not “I haven’t gotten around to documenting this.” “needs info” meant the maintainer would close the issue automatically after 14 days of no response.

This reduced noise. It made the issue tracker a useful tool instead of a dumping ground.

What About Code Quality?

You’re probably wondering: “What about test coverage? Code complexity? Number of contributors?”

We tested all of those.

None of them predicted survival with statistical significance.

Projects with 0% test coverage survived just as often as projects with 90% coverage—provided they had fast issue response times and consistent commits. Quality code doesn’t keep a project alive. *People* do.

That’s the lesson.

The Vietnam Connection

Why am I telling you this while writing for a company that rents Vietnamese developers?

Because the same principles apply to building software teams.

When we onboard developers in Can Tho or Ho Chi Minh City, we don’t just look at their commit history. We look at how they communicate. How fast they respond to feedback. Whether they can document their work.

These are the same signals that predict open source survival. It’s always about the human layer.

Our developers know this. They’re trained to maintain communication loops, update docs alongside code, and keep the feedback cycle tight. It’s not a coincidence that our clients see higher retention in their offshore teams when they follow these same patterns.

The Bottom Line

If you want your open source project to survive, stop optimizing for stars. Start optimizing for humans.

Respond to issues fast – within 48 hours
Commit consistently – at least every 14 days
Merge PRs generously – target 60%+ merge ratio
Update docs with code – keep the README fresh
Label issues consistently – make the tracker useful

That’s it. No magic. Just discipline.

Frequently Asked Questions

How did you collect the data for the 10,000 repos?

We used the GitHub REST API to pull metadata from repos created between 2018 and 2021. Our scraper ran in batches, collecting commit frequency, issue response times, PR merge ratios, documentation patterns, and label usage. We excluded forks and repos with fewer than 10 stars to filter out noise. The analysis was done using Python with Pandas and scikit-learn for basic regression modeling.

Does project popularity (star count) actually matter for survival?

Not in the way you’d think. Repos with 100 stars had similar survival rates to repos with 10,000 stars—provided they maintained fast issue response times and consistent commits. Stars are an outcome of activity, not a driver of it. Don’t chase stars; chase contributor satisfaction.

What’s the single most impactful action a solo maintainer can take today?

Set up automated issue response and commit to checking in once every two weeks. Use a GitHub Action to comment on new issues within 24 hours with a triage message. Then schedule a recurring calendar reminder to push at least one commit every 14 days. Do those two things, and you’ll outlast 80% of similar projects.

How do you handle open source maintenance with a remote team?

We treat it like any other software project. Our developers in Vietnam follow the same patterns: daily commits, same-day issue responses within business hours, and documentation updates bundled with code changes. We use the ECOA ACP platform to orchestrate this workflow across time zones. The key is making the process automatic so nothing falls through the cracks.