The Plugin Stopped Shipping. The Syntax Stayed in Your Notes

Of the 100 most-downloaded Obsidian community plugins, 22 have shipped no release in more than two years. What they wrote into notes is still there. Some of it is data — a list, a field, a highlight — and reads fine anywhere. Some is an instruction — without the plugin it shows as raw code. A grep tells them apart.

The count comes from the public plugin registry, read on 2026-10-25.¹² Obsidian is the dataset here — not the target. It runs the one large Markdown-note plugin registry that publishes a release date and a download total for every plugin, and a list of every removal with its reason. That openness is what makes the measurement possible.

A missing release is not a fault. Some plugins are finished. One maintainer of a finished project told researchers it "works great and needs no updates for any reason."³ The narrower risk is simple. If the app changes underneath a quiet plugin, nobody may be left to ship the fix.

So this piece does three things. It measures how often popular plugins go quiet, with a script anyone can re-run. It sorts the syntax those plugins leave in a note into what survives and what does not. Then it gives six grep recipes, tested on a throwaway vault, that find each kind in your own files.

How many popular plugins have stopped shipping releases?

On 2026-10-25 the registry listed 9,427 community plugins; 9,423 had a release date. Of those, 15.6% had shipped nothing in over a year and 9.6% in over two. The share is higher at the top: 22 of the 100 most-downloaded plugins have no release in two years.

The registry is two JSON files in Obsidian's obsidian-releases repository.¹² One lists every plugin. The other holds each plugin's lifetime downloads and an updated timestamp — the date of its latest release. The script further down joins the two and buckets plugins by age.

The median plugin shipped its last release 0.19 years ago — about ten weeks. Most of the registry is fresh.

The top is older for a structural reason — age buys downloads. A plugin needs years to collect enough downloads to reach the top 100, so the most-downloaded list leans toward plugins that arrived early. That is also why it matters. Those are the plugins with the most notes behind them.

Here are the 22, with lifetime downloads and last release date from the same file. Four are now held by the Obsidian Community Archive, marked (Archive).

The other side of the ledger is just as real. Templater (6,010,066 downloads) shipped a release on 2026-10-11, Excalidraw (8,695,868) on 2026-10-12, Tasks (4,496,659) on 2026-10-16 and Admonition (1,005,244) on 2026-10-19.² Quiet plugins are a minority, even at the top.

Is a plugin with no recent release broken?

Not necessarily. The registry's updated field records the last release, not the last commit, and some projects are simply done. In a survey that drew 118 replies from maintainers of popular GitHub projects that had gone quiet, 17 said their project was finished. A quiet plugin can work perfectly; the risk is an app change nobody patches.

Coelho and Valente asked those maintainers why their projects stopped, in a paper at ESEC/FSE 2017.³ The paper sums up one group in a line: "17 developers consider that their projects are finished and do not need more features (just few and sporadic bug fixes)." The paper kept that group out of its table of failure reasons — a finished project has not failed.

One respondent, D69, put it plainly: "I felt it was done. I think the dominant idea is that you have to constantly update every open source project, but in my opinion, this thing works great and needs no updates for any reason, and won't for many, many years, since it's built on extremely stable APIs (namely git and Unix utilities)."³

A plugin is in a different position. It runs inside an app that ships its own updates, so its API is only as stable as the host.

Git does not change under a finished tool. A host app can.

The release date also undercounts work. Kanban's repository received a push on 2026-03-06. Its latest release, 2.0.51, is dated 2024-05-31.⁴ Five spot checks against GitHub's latest-release records — Calendar, Periodic Notes, Kanban, Dataview and Highlightr — matched the registry's dates exactly. So read every number in this piece as "no release in N years", never as "no commits".

What happens when a plugin's developer steps back?

Sometimes the developer says so in public and asks for successors. Kanban's developer wrote in January 2026 that he no longer has the bandwidth to maintain it. The plugin now lives with the Obsidian Community Archive, which adopts popular plugins. Adoption is common in open source, but it does not guarantee new releases.

Matthew Meyers's note in Kanban's MAINTAINERS.md, dated January 12, 2026, reads: "I no longer have the bandwidth to maintain the Kanban plugin (and haven’t for a while) and I’m looking for new maintainers to take over the project."⁵ The README opens with the same request. It is a generous way to step back — many developers just stop answering.

The archive describes itself in one line — with a wink: "A home for Obsidian plugins, themes, and tools kept alive by the community. It's alive... alive!"⁶ It now holds Kanban, Style Settings, Zotero Integration and Full Calendar from the top-100 list.

Adoption is a real path, not a hope. Avelino, Constantinou, Valente and Serebrenik followed 1,932 popular GitHub projects: "We found that 315 projects (16%) were abandoned and 128 of these projects (41%) survived because of new core developers who assumed the project development."⁷ An adopted project still needs someone to cut the release.

Kanban sits in the archive and has shipped none since May 2024.

The people downstream rarely have a plan. Miller, Kästner and Vasilescu interviewed 33 developers who had been left relying on an unmaintained dependency. "We found many developers felt they had little to no support or guidance when facing abandonment, leaving them to figure out what to do through a trial-and-error process on their own."⁸

The registry's own removal list shows how a plugin leaves. It has 175 entries; 95 give a reason that is a variant of "archived" — "Repository archived" or "Archived repository". Other verbatim reasons include "No longer maintained", "Broken & unmaintained", "Repository deleted" and "Features available in app".⁹ A quiet repository that is not archived stays listed. That is exactly the case measured above.

What does a note look like when its plugin is not running?

It looks like plain Markdown with some code in it. Every plugin's syntax falls into one of three kinds. Data syntax is text the plugin renders, and it stays readable. Instruction syntax is a request the plugin answers, and the answer disappears. Some plugins write no syntax at all.

The safest way to see this is Obsidian's own Restricted mode. Its help page says: "Installed plugins remain in your vault even if you turn on Restricted mode, but are ignored by Obsidian."¹⁰ Nothing is uninstalled, so the test is reversible. With it on, each note shows roughly what any plain Markdown reader would show — your text, and the syntax around it.

Here is one note seen both ways:

WHAT THE PLUGINS DRAW               WHAT IS IN THE FILE
---------------------------------   ------------------------------------
Projects, by due date               ```dataview
  Garden fence   2026-10-27         TABLE due FROM "projects"
  Tax return     2026-10-30         SORT due ASC
                                    ```
Status: done                        status:: done
key line (highlighted yellow)       <mark class="hltr-yellow">key line</mark>
Board: Todo / Doing / Done          ## Todo
                                    - [ ] Ship it

The left column is what the plugins draw. The right column is what is in the file — and what a plain reader gets. The board and the field lost nothing. The table of projects is gone — only the question survived, not the answer.

Calendar, the most-downloaded plugin on the quiet list, belongs to the third kind. It works from daily-note files named by date, so there is nothing of it to find in a note. Not every quiet plugin leaves anything in your notes.

Which plugin syntax survives without the plugin?

Data syntax survives: Kanban's lists, Dataview's key:: value fields and frontmatter, and highlights written as inline HTML. Instruction syntax does not: Dataview query blocks and inline queries, and Templater's dynamic commands. Their results were never in the file. The difference is whether the note holds the answer or the question.

Kanban is the clearest data case. Its source writes a new board's frontmatter as kanban-plugin: board.¹¹ The cards are ordinary Markdown list items. The board's settings sit at the end in a %% kanban:settings block of JSON, which a plain reader shows as code. The cards themselves lose nothing — that format is why boards outlive the plugin, as a plain-text Kanban board you own argues.

Highlightr shows the split inside one plugin. Depending on a setting, its source emits <mark style="background: …;"> or <mark class="hltr-…">.¹² Its README explains the default: "The use of inline CSS is essential in maintaining the longevity of your notes. When you export, you will not be reliant on any external CSS styling."¹³ Class mode depends on a stylesheet the plugin generates. Without the plugin, the text stays and the colour goes.

The same plugin, two settings, two different futures for the file.

Why does a query leave nothing behind?

Because a query plugin is designed never to write its answer into your file. Dataview's own documentation says it "will always leave them untouched" — your notes and metadata. So the query text is saved, and the result exists only on screen. That is a good design for safety, and it is what makes a query fragile.

The Dataview overview is explicit: "Dataview is meant for displaying and calculating data. It is not meant to edit your notes/metadata and will always leave them untouched".¹⁴ The one exception it names is checking off a task through Dataview. Its FAQ spells out what that means for inline fields. When you store an inline query in a field, "the saved value inside your metadata field is still your Inline DQL calculation".¹⁵ The field holds the formula, never the number.

Templater is mostly the opposite — easy to get wrong. An ordinary <% … %> command runs once, when a template is inserted, and the note keeps its output as plain text. Only dynamic commands stay in the note. Written <%+ … %>, they are resolved "when entering preview mode".¹⁶ Templater's documentation adds a warning: "Dynamic commands have known issues, and will likely not be maintained going forward".¹⁶

The same split appears in a core feature that ships with the app itself. Obsidian's help page for Bases says: "All the data in Obsidian Bases is stored in your local Markdown files and their properties. The views are described by the Bases syntax, which can be saved as a .base file or embedded in code blocks within your Markdown files."¹⁷

That is the general rule for query views, not a flaw in one plugin.

The data lives in plain properties. The view is syntax that only its renderer understands.

How to reproduce the count

The measurement is a short Python script over two downloaded JSON files, with no dependencies. It joins the plugin list to the stats file, computes each plugin's years since its last release, and prints the shares by threshold. Re-run it any day; the registry changes daily, so every figure here carries its date.

Download the two files from the registry. Then run the script on the folder that holds them:

mkdir registry && cd registry
for f in community-plugins.json community-plugin-stats.json; do
  curl -sSfLO "https://raw.githubusercontent.com/obsidianmd/obsidian-releases/master/$f"
done
cd .. && python3 measure.py registry

import json, sys, time, statistics

d = sys.argv[1]
reg = json.load(open(d + '/community-plugins.json'))
st  = json.load(open(d + '/community-plugin-stats.json'))
NOW = time.time() * 1000  # the stats file stores milliseconds

# (id, lifetime downloads, years since last release)
rows = [(i, st[i].get('downloads', 0), (NOW - st[i]['updated']) / 86400000 / 365.25)
        for i in {p['id'] for p in reg} if i in st and 'updated' in st[i]]
tot = sum(r[1] for r in rows)
print("listed", len(reg), "with a release date", len(rows))

for y in (1, 2, 3):
    n = [r for r in rows if r[2] > y]
    print(f">{y}y: {len(n)} ({100*len(n)/len(rows):.1f}%), "
          f"{100*sum(r[1] for r in n)/tot:.1f}% of downloads")

print("median years:", round(statistics.median(r[2] for r in rows), 2))
ranked = sorted(rows, key=lambda r: -r[1])
for k in (100, 500):
    top = ranked[:k]
    print(f"top{k} >1y:", sum(r[2] > 1 for r in top), " >2y:", sum(r[2] > 2 for r in top))

Run on 2026-10-25 against registry commit 8d2f5084, it printed:

listed 9427 with a release date 9423
>1y: 1473 (15.6%), 32.0% of downloads
>2y: 902 (9.6%), 21.5% of downloads
>3y: 434 (4.6%), 10.4% of downloads
median years: 0.19
top100 >1y: 30  >2y: 22
top500 >1y: 199  >2y: 142

An earlier run the same morning, against commit 8dfe74ab, listed 9,426 plugins. Every percentage and top-list count was identical. The thresholds are strict: a plugin released exactly one year ago does not count as more than one year.

How to audit your own vault for plugin syntax

Run six grep commands from your vault's root folder. Each finds one kind of plugin syntax. The first three find instructions whose results are not in the file: query blocks, inline queries and dynamic Templater commands. The last three find data that survives: Kanban boards, class-mode highlights and inline fields.

# Instructions — the result is NOT in the file
grep -rlE '^```(dataview|dataviewjs)' --include='*.md' .                 # query blocks
grep -rnE '`\$?= [^`]+`' --include='*.md' .                              # inline queries (DQL and JS)
grep -rnF '<%+' --include='*.md' --exclude-dir=templates .               # Templater dynamic commands

# Data — readable without the plugin
grep -rlE '^kanban-plugin:' --include='*.md' .                           # Kanban boards
grep -rnoE '<mark class="hltr-[^"]+"' --include='*.md' .                 # class-mode highlights (colour needs CSS)
grep -rnE '^[A-Za-z_][A-Za-z0-9_ -]*:: ' --include='*.md' .              # inline fields: "key:: value"

These were tested on a throwaway vault of eight small files: one planted per pattern, an inline JavaScript query, a template and a plain control note. Each command returned only the files planted for it. A templates/daily.md holding an ordinary <% tp.date.now() %> was correctly skipped, because ordinary Templater commands are expected inside templates.

Two settings can hide hits. Dataview lets you change its inline prefixes — = for queries, $= for JavaScript.¹⁸ If you changed them, adjust the second pattern. If your templates folder has another name, change --exclude-dir.

What to do with the hits is a judgment call. Data hits need nothing.

For an instruction you care about, paste its current result below it as plain Markdown — a table, a list, a number. Then the note holds the answer as well as the question.

Then run the visual test. Turn on Restricted mode under Settings → Community plugins, read the notes the greps found, and turn it off again. The plugins were never removed from the vault; check that the ones you use are enabled again before you go back to work.

What this measurement does not show

It counts releases, not health, and it weights by lifetime downloads, which favour old plugins. The top-100 list is old-biased by construction. The greps find syntax in Markdown files only. Each limit narrows what the numbers mean; none of them changes the audit, which costs a minute whatever the numbers say.

Download totals only grow. A thread on Obsidian's forum asked, "Are plugin download stats actually misleading?" One member, replying, called the count "a combined measure of popularity and longevity (and release frequency)."¹⁹ So the 21.5% figure is a share of lifetime downloads, not a share of current users. The counts — 902 plugins, 22 of the top 100 — are the steadier numbers.

The release date is a proxy. A plugin can be maintained without releases — Kanban's 2026 push shows that. It can also be finished, as the Coelho and Valente survey found.³ The script also cannot tell which quiet plugins write syntax into notes. That classification was not checked plugin by plugin, so this piece gives no count of it.

The greps have edges too. They read only .md files, so any settings or data a plugin keeps elsewhere in the vault are out of scope. The inline-field pattern can also match an ordinary sentence that happens to contain :: .

None of this is a reason to skip the audit.

A rule for choosing plugin syntax

Prefer syntax that stores the data in the note and leaves only the view to the plugin. Use instruction syntax freely, but keep a copy of any result you would miss. A query is a question — if the answer matters, write the answer down.

The rule does not mean avoiding plugins. Kanban, inline fields and inline-CSS highlights are good examples of plugins that render your own text. Their syntax is data first, so the files outlive the software. Query blocks are worth having too. They are just the one place where the file holds less than the screen shows.

Write for the reader that has no plugins.

The risk was named before. A defence of Markdown put it in one line: "Dataview queries render in Obsidian and do not exist anywhere else." That piece called each extension a vendor-scoped choice; this one adds the count and the audit. For the same question one level up — what survives when the company behind an app is gone — see note apps compared by what survives.

Frequently Asked Questions

Why do so many popular Obsidian plugins stop getting updates?

Some are finished, some lost their developer's time, and some were overtaken. Of the 100 most-downloaded plugins, 22 had no release in over two years on 2026-10-25. In a survey that drew 118 replies from maintainers of quiet GitHub projects, 17 said theirs was simply done.²³

What happens to my notes if a plugin is no longer maintained?

Nothing changes in the files. Whatever the plugin wrote stays there. Data syntax — Kanban lists, key:: value fields — stays readable. Instruction syntax, such as a ```dataview block, shows as raw code. Its result is gone, because it was never saved in the note.¹⁴¹⁵

How do I check whether an Obsidian plugin is still maintained?

Look up its last release date in the registry's community-plugin-stats.json, or on the plugin's GitHub releases page, and read its README for a maintainer note. A release date is a proxy: Kanban's repository had a 2026 push but no release since 2024-05-31.²⁴⁵

Will Dataview queries work without Dataview?

No. Without the plugin, a ```dataview block is an ordinary code block and an inline = … query is inline code. Dataview's documentation says it "will always leave" your notes untouched, so the result was never written to the file. Your inline fields and frontmatter stay readable as plain text.¹⁴¹⁵

Are Obsidian plugin download stats misleading?

They are lifetime totals, so they only grow. An old plugin keeps climbing even after it stops shipping, which is why the most-downloaded list leans old. Treat downloads as installed history, not current use, and prefer counts of plugins over download-weighted shares when judging how widespread a pattern is.²¹⁹

What is the Obsidian Community Archive?

It is a GitHub organisation — it describes itself as "A home for Obsidian plugins, themes, and tools kept alive by the community." It holds four of the 22 quiet top-100 plugins, including Kanban. Being in the archive keeps the code available; it does not guarantee new releases.⁶²

How do I find which plugins my notes depend on?

Grep the vault for each plugin's syntax: ```dataview fences, `= …` inline queries, <%+ dynamic commands, kanban-plugin: frontmatter, hltr- highlight classes and key:: value fields. Then turn on Restricted mode, which ignores installed plugins without removing them, and read the notes you found.¹⁰¹⁸

When a plugin stops shipping, the syntax stays in your notes. The developers of these plugins built tools with millions of downloads, and several built them so that what stays behind is still readable. That is the part worth copying.

Keep the answer in the file. The plugin can keep the view.

MNMNOTE keeps notes as open Markdown on your own device, so the answer you write down is the one that stays in the file. mnmnote.com

References