I've killed two open source projects. One had 340 stars. The other had 180. I've also kept one running for four years with 1,800 stars. The difference between the ones that died and the one that survived has almost nothing to do with technical quality.
The Standard Lifecycle of a Failed Project
Phase 1: You build something to solve your own problem. You open source it because it took you three days and you figure other people might need it. You post it to a Reddit thread or Hacker News. It gets 200 stars in a week. This feels amazing.
Phase 2: Issues start coming in. Bug reports, feature requests, questions about documentation, requests for integrations with things you've never heard of. You're excited. You fix bugs and merge PRs. The project is growing.
Phase 3: About six months in, you've solved your original problem. The project is no longer solving a pressing personal need. But the issues keep coming. Pull requests arrive from strangers, some well-written and easy to merge, others low quality or out of scope.
Phase 4: Life happens. A new job, a baby, a new project that's more exciting. The issue queue grows. You feel vaguely guilty about it. You tell yourself you'll get back to it. The last commit was fourteen months ago.
What Kills Projects (It's Not the Code)
Maintainer motivation isn't a bug — it's the most critical resource any open source project has. When the original itch has been scratched and the project is no longer needed in the maintainer's daily life, the energy required to keep up with issues, reviews, and releases has to come from somewhere else: community appreciation, professional obligation, or pure determination. Most projects run out of these resources.
The issue flood is a significant factor. Issues create psychological debt. Every unread issue is a reminder of something you haven't done. For projects with active users, this debt compounds faster than most solo maintainers can manage.
What the Surviving Projects Do Differently
The projects that survive past 200 stars to 2,000 and beyond tend to share a few characteristics. First: they build a co-maintainer relationship early, while the project is still exciting. Two committed maintainers is dramatically more resilient than one.
Second: they manage the issue queue deliberately. Clear contributing guidelines, issue templates, automatic labelling, and a willingness to close issues that are out of scope or won't be worked on. Letting the issue queue grow unbounded creates the burnout cycle.
Third: they have users who contribute more than issues. Projects that attract pull request contributors — not just users who file bugs — have a healthier dynamic. This comes partly from documentation quality and partly from explicitly asking for contributions and making the contribution process easy.
The Honest Advice for New Project Maintainers
Before you open source something: think about whether you're willing to maintain it for two years when it's no longer new and exciting. Not whether you're willing to today — whether you'll be willing to in month 18. If the honest answer is probably not, either don't open source it or do it with the explicit framing that it's unsupported, provided as-is.
