Buy the boring plugin, not the exciting one
The claim When you add a third-party plugin, extension, or library to the software your business runs on, the feature list is the least important thing to evaluate. The number that...
The claim
When you add a third-party plugin, extension, or library to the software your business runs on, the feature list is the least important thing to evaluate. The number that predicts whether you will regret the decision is the maintenance signal — how recently and how consistently the thing is updated — and by that measure the exciting new plugin with the perfect feature set is usually the wrong choice, and the boring one that has done the same job quietly for six years is usually right.
Why the abandoned plugin is the expensive one
A plugin is not a purchase; it is a dependency you now carry. When the platform it runs on releases a security update, an unmaintained plugin breaks, and you face a bad choice: run the plugin and skip the platform update, leaving a known hole open, or apply the update and lose a feature your business depends on. Neither is a decision you want to make under time pressure, and an abandoned plugin guarantees you will eventually make it.
The costs are concrete. An unmaintained e-commerce plugin is a common entry point in the breach reports we read, because attackers scan specifically for known-vulnerable versions of popular plugins. And when a plugin blocks a platform upgrade, the workaround — forking it, or paying someone to patch it — frequently costs more than a year of the maintained competitor's licence.
The signals that actually predict longevity
Before the feature list, check these, most of which take two minutes:
- Date of the last release. Not the last commit — the last actual release. Under six months is healthy; over eighteen months is a warning regardless of how finished the project looks. "Done" and "abandoned" produce identical commit graphs.
- Release cadence, not just recency. A steady rhythm of small releases signals an active maintainer. One burst of activity two years ago followed by silence signals a side project whose author moved on.
- How fast the last few security issues were closed. Look at the issue tracker. A reported vulnerability that sat open for eight months tells you exactly what response time to expect when it is your emergency.
- Bus factor. One maintainer is a risk; when they lose interest, the project stops. Several active contributors mean the project survives any one person leaving.
- Whether it is someone's job. A plugin backed by a company with a paid tier has a financial reason to keep patching it. A volunteer project has goodwill, which is real but not contractual.
A worked comparison
| Signal | Exciting new plugin | Boring incumbent |
|---|---|---|
| Last release | 3 weeks ago | 5 weeks ago |
| Release history | 4 releases, all this year | 60+ releases over 6 years |
| Maintainers | 1 | 4 active |
| Last security fix turnaround | no history yet | 72 hours |
| Commercial backing | none | paid support tier |
The exciting plugin is not badly built. It simply has no track record, and a track record is the only thing that predicts how it behaves during the incident you have not had yet. The boring one has answered that question sixty times.
When new is the right call anyway
Sometimes the incumbent is genuinely worse: it is the market leader through inertia, it has architectural problems the maintainers will not fix, or the new entrant solves a real problem the old one structurally cannot. In those cases, adopt the new one deliberately — and budget for the risk. Pin the version, read the code you depend on, and have a written answer to "what do we do if this is abandoned in a year". The mistake is not choosing new; it is choosing new for the feature list and discovering the maintenance risk later.
Reduce your exposure regardless of what you choose
Every plugin you add is surface area, so the cheapest risk reduction is fewer plugins. Before adding one, ask whether the feature is worth a permanent dependency or whether a small amount of code you own would do. A 30-line function you maintain is often less total risk than a 30,000-line plugin you do not, precisely because you can read all thirty lines and none of the thirty thousand.
Audit what you already carry:
npm outdated # how far behind is each dependency
npm audit # known vulnerabilities in the tree
Run it quarterly. The dependency that is three major versions behind is the one that will be impossible to update in the emergency, because two years of breaking changes have accumulated between you and safety.