DSH Plugin market delisted or unmaintained: what next

A plugin that stops changing in the DSH Plugin market can be stalled, archived or simply frozen, and the three states call for different levels of urgency. Reading the signal correctly separates a note on a review list from a migration project.

Three DSH plugin deprecation signals that look alike

Stalled, archived and frozen all look like silence, but each one removes a different kind of support.

The signals differ in what kind of support they remove:

• Stalled entry: it still exists and still points at a package, but nothing new arrives.
• Archived repository: the maintainer has explicitly stated that work has stopped.
• Frozen version: shipping has stopped by choice, and the project may remain healthy.

The visible symptom is similar: no recent update.

The difference matters because each state leaves you with different options. Stalled projects can resume; archived ones rarely do; frozen versions may be intentional and safe for a while. Treating all three as "dead" leads to unnecessary migrations, and treating all three as "fine" leads to surprise breakage.

The table below separates the signals by what they imply rather than by how they look. The point is to assign a response, not a label. A label without a response is just anxiety with a name.

A stalled DSH Plugin market entry is not always abandoned

A stalled entry is a question about attention, not a verdict about quality.

Many small plugins are finished rather than abandoned. Their feature set is complete, the code needs no changes, and the maintainer has moved on. That is a legitimate end state, and it can survive several Harness releases without incident.

The problem is that finished and forgotten are indistinguishable from the outside until something breaks. A compatibility change in the runtime is the test: if the plugin still loads and behaves after an upgrade, the silence was harmless. If it fails, the silence becomes a maintenance gap.

The useful response is a review point rather than an immediate replacement. Pin the version you know works, note the Harness version it was last verified against, and check again after the next upgrade. That keeps the plugin in service without pretending the risk is zero.

Archived repositories and what they change for a DSH plugin

An archived repository is a maintainer's explicit signal, and it should move the plugin onto a replacement timeline.

Archiving is not ambiguous. It usually means the owner has decided not to accept issues or merge changes, even if the code remains readable. From that point, compatibility fixes will not arrive, and any breakage is yours to patch or route around.

That does not require deleting the plugin today. A working archived plugin can keep running while you search, and an abrupt removal is often worse than a planned transition. What changes is the default: you are now maintaining a local copy in spirit, whether or not you touch the code.

The search should start from capability rather than the old name, because equivalent DSH plugins rarely share names. Describe what the plugin did in a few words, find candidates that claim the same job, and compare their maintenance and permissions before testing. A replacement that solves the same job is worth more than a familiar name.

Frozen versions of a DeepSeek Harness plugin

A frozen version can be a deliberate compatibility decision, so read the reason before treating it as decline.

Some maintainers freeze a major version to keep a stable surface for existing users while work continues elsewhere. Others freeze because the project is done. The version number alone does not tell you which, but release notes and repository activity usually do.

A frozen DeepSeek Harness plugin is safe only as long as the runtime it targets remains compatible. That makes the Harness release notes part of your maintenance routine: a change to plugin APIs or the sandbox can turn a stable freeze into a broken install. Treat that as a standing constraint rather than a one-time check.

When the freeze is deliberate and the plugin still works, there is no reason to migrate. When the freeze hides an incompatibility that nobody is fixing, the frozen version is just an archived project with better branding. That distinction decides whether a freeze is a fact to accept or a warning to act on.

When to prepare a replacement for DSH plugins you rely on

Prepare a replacement when the cost of waiting exceeds the cost of switching, and not before.

The trigger is rarely a single event. It is a combination: an archived repository, a Harness upgrade on the horizon, and a workflow that depends on the plugin every day. Any one of those alone can be tolerated; together they turn a background risk into a planned task.

Preparation is cheaper than emergency migration. Identify a candidate, map the old configuration to the new fields, and note which scripts reference the old tool names. None of that requires uninstalling anything, and all of it shortens the eventual switch.

The worst outcome is discovering the dependency during an incident, when the old plugin has already stopped loading and the replacement has never been tested. Preparing early costs a few hours; discovering the gap during an incident costs a working day. A little attention at the right signal prevents that, which is the entire value of reading the signs.