Your AI's Memory Is Someone's Side Project

I was updating our competitive tracker last week when mcp-memory-service's GitHub page returned a 404. Not an archived notice. Not a deprecation warning. The maintainer's entire account had vanished.

His last release shipped on March 13. Four days before it all disappeared. 1,516 stars. 38,000 monthly PyPI downloads. Featured in every "best MCP memory servers" listicle. Gone.

Heinrich Krupp, the sole maintainer, later confirmed on LinkedIn: "my account got flagged and disappeared from public view. Reinstatement Request is ongoing." Not a ragequit. Not a license dispute. An automated system flagged the account, and 1,500 stars of infrastructure blinked out.

One of the first comments on his post: "I am using this at work...since last week all information disappeared."

What was lost

We'd read the source code before it vanished. mcp-memory-service was the most architecturally ambitious open-source memory project we analyzed across ten repos. A 6-phase "dream-inspired" consolidation pipeline: decay scoring, semantic clustering, creative association discovery, compression, controlled forgetting, and timestamp marking. A multi-factor decay formula combining importance, time, connections, access recency, and quality. An association discovery system that specifically targeted the 0.3-0.7 cosine similarity range, where genuinely non-obvious connections live.

Over 200 releases. 968 tests. This was not a weekend experiment.

"Just fork it" doesn't work the way you think

Heinrich has a reinstatement request in progress. Someone offered to host a GitLab mirror. The community rallied. But none of that changes what happened in the interim.

165 forks existed, but GitHub severed the fork network when the parent account went down. Every fork became a standalone repo with no upstream. The issue tracker, wiki, release notes, and contributor graph are gone. The PyPI package still installs, but the source link in the metadata is a dead page.

The structural problem

This keeps happening. left-pad (2016), faker.js (2022), xz-utils (2024). Each triggers a week of discourse about open-source sustainability. Then everyone moves on.

The AI memory category has a version of this problem that's more acute than most. The Tidelift 2024 survey found 60% of open-source maintainers are unpaid, and 61% of unpaid maintainers work completely alone. OpenSSF's Census III found 40% of top projects had only one or two developers accounting for 80%+ of contributions.

These are the projects that AI coding tools are building their memory layers on. 11,000+ MCP servers listed on PulseMCP. The vast majority are personal GitHub repos. The memory layer becoming load-bearing infrastructure for AI development is maintained by individuals on nights and weekends.

Memory is different

A web framework disappearing is recoverable. You pin the version and migrate. The framework is stateless.

Memory accumulates state. Your team's decisions, your codebase's failure modes, the incident that explains why you don't touch the checkout module on Fridays. When a memory project disappears, you lose the pipeline that was building something you can't reconstruct from a fork.

Heinrich will probably get his account back. But for the MLOps architect who showed up to work and found his memory infrastructure returning 404s, the reinstatement request doesn't help on the day the tool disappears.

The question is whether the next project that implements these ideas will be someone else's side project too.

---

I'm building Mneme at mnem.dev — a memory layer that turns your team's engineering signals into institutional knowledge.

Previously: Stop Stuffing the System Prompt · Why Every AI Coding Tool Is a Perpetual New Hire