Why Does AI Call My Open-Source Project Abandoned or Recommend a Fork?
AI calls an open-source project abandoned, or recommends a fork, because the signals it reads say so, even when the project is healthy. Those signals include an old last-release date from when the model was trained, and a large backlog of open issues. An archived old repository or a deprecated old package name adds to the picture, as do blog posts declaring the project dead. So does a fork whose launch announcement explains that it forked because the original was unmaintained. A stable project that rarely changes looks the same as an abandoned one unless it says otherwise. State your maintenance status plainly in the README and docs, release on a regular schedule, and fix your registry metadata. Describe the fork factually, then retest the questions developers ask.
What signals make a project look abandoned?
| Signal | How it reads | What to publish instead |
|---|---|---|
| No release for a long time | "Unmaintained" | Regular small releases, or a stated policy: "stable; security fixes only" |
| Hundreds of open issues, many unanswered | "No one is responding" | Triage: labels, closing stale issues with a reason, a response-time statement |
| An archived old repository | "The project was shut down" | A pointer in the archived README to the current repository |
| A deprecated old package name | "Deprecated, use something else" | A deprecation message that names the new package |
| Blog posts saying "X is dead, use Y" | "The community has moved on" | A current status statement that can be cited instead |
| A fork's launch announcement | "The fork is the maintained version" | A factual comparison of the two projects |
| A lapsed docs domain or broken docs links | "The project is gone" | Working docs at a stable address, with redirects |
Automated health checks read some of these signals in the same way. The OpenSSF Scorecard's "Maintained" check gives an archived project the lowest score. It gives the highest score to one with at least one commit per week over the previous 90 days. Its documentation adds that a lack of active maintenance is not necessarily a problem, since some small utilities need no changes. An assistant is unlikely to make that distinction unless your project states it.
How can open-source maintainers investigate why AI recommends a fork?
- Ask the questions developers ask, several times each, in ChatGPT, Gemini, Perplexity and Google's AI features. Examples: "Is [project] still maintained?", "[project] vs [fork]", "best [language] library for [task]", "alternatives to [project]".
- Record the claims and the cited sources for each answer: which page said the project was abandoned, and which page recommended the fork.
- Classify the sources: - your own pages (README, docs, release notes) that say nothing about status; - registry pages showing old versions, deprecation or an outdated repository link; - the fork's announcement or README; - third-party posts and comparison articles; - no source, meaning the answer comes from model knowledge.
- Check your registry metadata. Does the repository link in your package metadata point to the current repository? Is an old package name deprecated with a message that names the new one?
- Search your project name. If the fork, an old repository or a "project is dead" post outranks your current repository or docs, assistants will find it first.
- Check dates. If answers cite a last-release date from years ago, the model's knowledge predates your recent releases, and search-based answers are not finding the newer ones.
What should you publish?
A maintenance status section in the README and docs home. For example: "Status: actively maintained. We release roughly every two months and aim to respond to security reports within a week." For a stable project: "Status: stable and feature-complete. We maintain it for security fixes and compatibility with new [language] versions; the API is not expected to change." That sentence turns "no recent commits" from a warning into a stated policy.
Regular releases, even small ones, with release notes. A dated release is the clearest evidence of activity.
Issue triage. Label issues, close ones you will not address with a short reason, and say how quickly you respond. A backlog with no responses reads as neglect.
Governance and security files. A maintainers list, a governance note and a security policy show who is responsible.
Correct registry metadata. Point repository and homepage links to the current locations. If you renamed a package, deprecate the old one with a message naming the new one. npm lets maintainers deprecate a package or version with a message shown on install. PyPI supports project status markers, including archived, which installers and mirrors can read.
Moves done properly. If you move a repository to a new organisation, transfer it rather than recreating it. GitHub redirects links from the previous location to the new one after a transfer.
How should you describe the fork?
Factually and without hostility, on a page of your docs or an FAQ entry:
- When and why the fork was created, in neutral terms, such as "after the 2025 licence change" or "during a period with no releases in 2024".
- What differs now: licence, governance, features, compatibility and release pace.
- Which to choose when: "If you need [feature], [fork] supports it; if you need [compatibility], [project] does."
Assistants often repeat a fork's framing because it is the only account of the split. Your own account gives them a second, current source. How assistants choose between competing sources is covered in how LLMs choose which sources to cite.
What if the fork really is more active?
Then the answers may be right, and it is better for users to know. Consider the honest options: collaborating with the fork, merging work, or archiving your project with a clear pointer to the fork. Archiving on GitHub makes a repository read-only for everyone and signals that it is no longer actively maintained, which is the clearest message you can send. A project that is effectively unmaintained but not marked as such causes more harm than one that says so.
What might an illustrative case look like?
Consider an illustrative data validation library that had released only patch versions for two years because its API was stable. A community fork, created during a quiet period, had added async support. Assistants described the original as "no longer actively maintained" and recommended the fork. They cited the fork's README and a blog post titled "[project] is dead". The original's README had no status section, 300 open issues and a docs link to an expired domain. The maintainers added a status section and triaged the issues, closing 180 with reasons. They restored the docs at a new domain, added an FAQ comparing the two projects, and published a release with notes. Two months later, most answers described the original as maintained and stable, and recommended the fork only for async use.
What do people ask about AI and open-source projects?
Do stars and download counts matter?
They may influence which projects appear in comparisons, but they do not answer "is it maintained?". Status statements and release dates do.
Should we ask blog authors to update "project is dead" posts?
Yes, politely, with your status statement and recent releases. Many will add an update note.
How often should we check AI answers?
After each release for a few months, then quarterly.
Published by The Kovmere Team · updated Sep 29, 2026 · More resources