You know the feeling. You find a plugin that does exactly what you need. Five stars. Glowing reviews. You install it, configure it, build your client’s site around it.
Then you notice the date. Last updated: two years ago.
You check the support forum. Questions from six months ago. No responses. The developer vanished.
We’ve all been there. And most of us assume it’s just how open source works—people build things, share them, move on. Circle of life.
But what if it didn’t have to be this way?
I Wanted to Know How Bad It Really Was
So I pulled the data. 6,000 plugins from the WordPress.org directory, split into three groups: plugins that are 1-2 years old, 2-3 years old, and 3-4 years old.
The results were worse than I expected.
By year two, 55% of plugins haven’t been updated in over a year. By year three, that number holds steady. The plugins that make it past that point tend to keep going—but more than half never get there.
Here’s what’s interesting: the survivors almost always have one thing in common. They have a business model. A premium version. A SaaS component. Something that pays the bills.
The plugins that die? They’re the passion projects. The “I built this to scratch my own itch and thought I’d share it” plugins. The ones where a solo developer poured their nights and weekends into something genuinely useful—and then realized they couldn’t keep doing it forever for free.
The Directory Wasn’t Designed for Sustainability
When you submit a plugin to WordPress.org, you agree to a set of guidelines. They’re well-intentioned. They protect users from dark patterns and aggressive upselling and bait-and-switch tactics.
But they also make it really, really hard to make money.
You can’t offer a trial that unlocks with payment. You can’t lock features behind a license key. You can’t show upgrade prompts that are too prominent. Your free version has to be genuinely useful on its own—which means you’re competing against yourself.
The models that are allowed require serious infrastructure. You can do freemium, but you need to host your premium version somewhere else, handle your own payments, manage two codebases. You can build a SaaS, but that means building actual infrastructure, not just a plugin.
For a company with resources, that’s fine. For a solo developer with a day job? It’s a wall.
So they do the math. Realize the economics don’t work. Stop maintaining the plugin. And the graveyard grows.
The Part That Surprised Me
Here’s what I didn’t expect to find: none of this is required by the GPL.
The Free Software Foundation—the people who created the GPL license that WordPress uses—are explicit about this. From their official position: “We encourage people who redistribute free software to charge as much as they wish or can.”
And: “The right to sell copies is part of the definition of free software.”
Read that again. The organization that invented the GPL says selling software is part of the definition of free software. Not a loophole. Not an exception. A defining feature.
The WordPress.org guidelines go above and beyond what the GPL requires. That’s a policy choice, not a license requirement.
Policy choices can be changed.
What If We Built Something Different?
Picture a WordPress plugin directory where developers can actually make a living.
A plugin could offer a 14-day trial of premium features. Clear disclosure, graceful fallback to the free version when it ends. Users discover value before they pay. Developers get a conversion path that doesn’t require building a separate empire.
WordPress.org could facilitate payments directly. Take a cut—that’s fair. But handle the infrastructure so developers can focus on building, not on becoming e-commerce experts.
Discovery could actually work. Real curation. Editorial picks. A “new and noteworthy” section that surfaces quality work instead of just install counts. Give good plugins a fighting chance to find their audience.
When a developer is done, they could say so. “This plugin is looking for a new maintainer.” A graceful sunset instead of silent decay.
None of this is radical. None of it violates the GPL. Other platforms do it already.
This Is the Future I Want to Build
Open source already won. WordPress powers 40% of the web. The question isn’t whether open source works—it’s whether the people building it can sustain themselves doing it.
The answer should be yes.
The GPL says yes. The Free Software Foundation says yes. The economics of every other successful software ecosystem say yes.
Right now, WordPress.org’s policies say no. But policies aren’t physics. They’re choices made by people, and people can make different choices.
55% plugin abandonment isn’t a law of nature. It’s the output of a system. We can design a different system.
One where open source and commercial sustainability aren’t enemies. Where a solo developer can build something great and not burn out maintaining it for free. Where users get plugins that actually get updated because someone’s getting paid to update them.
That’s not a fantasy. That’s just… how software should work.
Let’s make it happen.
I want to hear from you. If you’ve abandoned a plugin, what pushed you over the edge? If you’ve kept one alive, how? If you’ve got ideas for how we fix this, let’s talk. This is a conversation, not a manifesto.
The Data (For the Curious)
Source: WordPress.org Plugin Directory API v1.2
Sample: 6,000 plugins (2,000 per cohort)
Cohorts: 1-2 years old, 2-3 years old, 3-4 years old
Analysis date: December 8, 2025
Primary threshold: 12 months without update
| Threshold | 1-2 Years | 2-3 Years | 3-4 Years |
|---|---|---|---|
| 6 months no update | 62.6% | 71.4% | 71.1% |
| 12 months no update | 40.1% | 55.0% | 56.2% |
| 24 months no update | 0% | 36.2% | 42.1% |
Average 3-4 year old plugin: 593 days since last update (over 1.5 years).
The survivors almost universally have business models—premium tiers, SaaS components, or they’re maintained by companies using them internally.
Analysis script available for replication.