In 2017, Caldera Forms was one of the most widely recommended contact form plugins for WordPress.
It had a clean codebase, responsive developers, a loyal following in the WordPress community, and appeared on what felt like every “essential plugins” list published that year. Developers recommended it. Tutorials were built around it. Thousands of sites across the world were using it as their primary way to receive enquiries, bookings, quote requests, and customer messages.
In 2019, Caldera was acquired by the company behind Easy Digital Downloads and Restrict Content Pro.
In 2021, Caldera was sunset. Security updates ended. Active development stopped.
And here is the part that nobody writes about: most of the sites running Caldera didn’t know. The plugin stayed in the WordPress repository. It still appeared on the installed plugins list looking, from the outside, the same as always. The forms worked. The emails arrived. Nothing had visibly broken — it just wasn’t being maintained anymore, by anyone, for any reason.
For a forms plugin handling contact enquiries and booking requests, “no longer maintained” means “slowly accumulating security risk with every passing month.” It means the plugin is not being updated to track changes in WordPress core. It means discovered vulnerabilities will not be patched. It means that the developers who built workflows around it — the business owners who installed it, the developers who deployed it, the managed hosting providers who supported it — were now running an unmaintained dependency at the centre of their business enquiry pipeline.
This is what plugin burnout actually looks like. Not a dramatic failure. Not a pop-up warning. A quiet process of neglect that only becomes visible when you go looking.
Why This Keeps Happening
There are approximately 60,000 plugins in the WordPress directory. A meaningful proportion of them — the long tail below the top 10,000 by active install count — are maintained by solo developers or very small teams.
A solo developer maintaining a plugin has one primary resource: their own motivation. They built the plugin because they had a problem, or because they wanted to learn WordPress development, or because they thought there was a market for it. They release it. It gets some traction. They maintain it for a while — fixing bugs, handling support questions, updating compatibility with new WordPress versions. Then life moves on. They get a new job. They start a family. They lose interest. The plugin hasn’t broken, exactly. It’s just stopped receiving attention.
The economics that drive this pattern are not complicated. A plugin priced at $49/year with 500 active paid installs generates $24,500 annually — before payment processing fees, before support overhead, before the time cost of tracking WordPress core changes across every release. For a solo developer, this is meaningful income if they’re in a lower-cost-of-living environment, and a rounding error if they’re paying a mortgage in Auckland. The marginal revenue from maintaining the plugin eventually becomes insufficient justification for the ongoing cost of maintaining it.
The successful case burns out too — it just takes longer. A developer whose plugin reaches a large install base and produces a genuine full-time income has not escaped the pattern; they have built a one-person business they cannot step away from. Every WordPress core release needs prompt compatibility work. Every security report needs an immediate response, because every one of those installs is exposed until the patch ships. Support arrives seven days a week, from every timezone, and there is no colleague to hand any of it to — no holidays where someone else watches the queue, no sick days where the vulnerability report waits. Three to four years of that is commonly what it takes. In this version the plugin does not fade from neglect: the author sells it, or shuts it down, and the sites depending on it find out afterwards which it was.
This is not anyone’s fault. Open-source software runs on discretionary contribution. Nobody owes anyone a plugin. The problem is structural: the WordPress plugin ecosystem was built on an implicit assumption that the individuals who create things will continue to maintain them indefinitely, for free or for low ongoing fees. That assumption fails routinely and predictably across the entire directory.
And “burnout” is just one way it fails.
The Acquisition Trap
The solo-developer burnout story is easy to understand. What gets less attention is the version that happens inside commercial organisations.
ManageWP was a respected WordPress management platform — site updates, backups, performance monitoring, all from a single dashboard. In 2016, it was acquired by GoDaddy. ManageWP still exists. It still functions. But developers who had built workflows around ManageWP’s API before the acquisition discovered, over subsequent years, that feature priorities had shifted significantly under the new ownership structure. The product served GoDaddy’s strategic interests, not the independent developer community’s wishlist.
iThemes Security — one of the most widely deployed security plugins in the WordPress ecosystem — was acquired by StellarWP (a subsidiary of Liquid Web, a managed hosting company) in 2021 and rebranded as Solid Security. Commercial continuity was maintained. But integrations and workflows built around the iThemes namespace, the iThemes API, and iThemes’ specific approach to security configuration all required rework. Existing sites running iThemes needed attention they hadn’t been budgeted for.
Caldera itself was an acquisition story before it was a sunset story. When Sandhills Development bought it in 2019, the acquisition was framed positively — more resources, continued development. The sunset came less than two years later. The acquirer’s priorities had changed again.
The acquisition trap works like this: a plugin you depend on gets bought by a larger entity whose business model may or may not align with maintaining the plugin as a standalone product. The plugin might continue, but its direction is now controlled by the acquirer’s board, not by the community that relied on it. It might be sunset entirely because it competes with the acquirer’s existing product. It might be “maintained” in a technical sense while the features that made it valuable to your workflow are deprioritised indefinitely.
You have no advance warning. You have no vote.
And the time between “this plugin was recommended to me” and “this plugin is now a liability” is typically three to five years — long enough to be thoroughly embedded in your site’s architecture when the moment of reckoning arrives.
The $118 Question
Here is the calculation that changed how I think about this.
For $118 a year, I can build and maintain a custom plugin.
For $118 a year, I cannot evaluate and find a plugin, and run security updates on it, and monitor its maintenance status, and repeat this process in four years when the author has burned out.
Let me be precise about what this means.
Building a custom plugin for a specific, bounded use case — a contact form, a staff directory, a testimonials rotator, a simple events list — takes a working developer four to eight hours. The codebase is small. There is no upstream compatibility to track. There are no API changes from a third-party developer. There is no acquisition risk. When WordPress core updates, you make minor adjustments as needed. The total four-year cost of a custom plugin is: build time, plus occasional minor updates as the platform evolves. Known. Fixed. Low.
Depending on an external plugin is a different equation entirely. There’s the purchase price or annual subscription ($50–$200/year for a premium plugin). There’s the time to evaluate and select the plugin initially, which, if done properly, is two to four hours — comparing options, reading documentation, testing in a staging environment. There’s the ongoing time to monitor for updates, test updates, verify compatibility each time WordPress core or another plugin in the stack releases a new version. There’s the risk of security exposure during any gap in maintenance, which is real and unquantifiable. And there’s the migration cost when the plugin reaches end of life — because it will — which is four to eight hours of work plus testing plus the risk of disruption to a live site.
The economics only favour depending on an external plugin in two cases: 1. The functionality is genuinely complex to build — WooCommerce, Elementor, Gravity Forms for complex multi-step workflows. These are cases where the plugin represents years of specialist development that custom code cannot reasonably replicate. 2. The plugin has structural continuity — it is maintained by a large team with aligned commercial incentives, transparent roadmap, and no meaningful acquisition risk.
For the majority of plugin use cases — contact forms, basic galleries, simple sliders, cookie notices, SEO metadata — the calculation favours building a minimal custom implementation over installing a third-party dependency with an expiry date you cannot predict.
This is why I recommend replacing any plugin that can be replaced by fewer than ten lines of code with code in a custom mu-plugin. One mu-plugin per site. It serves as documentation, it’s version-controlled, it doesn’t phone home, it doesn’t run ads in your dashboard, and it doesn’t break when someone else loses interest.
This is the argument from Truth #1: Fewer Plugins, More Custom Code. Truth #9 is that same argument, extended to its logical conclusion: the plugins you cannot replace with custom code are the ones you should be planning to replace anyway — because their authors are on borrowed time.
Case Evidence
Three anonymised patterns from across the managed portfolio, representing a common type of situation rather than specific identifiable clients:
The hospitality business and the booking plugin. A managed client in the hospitality sector had been running a booking plugin recommended by the original developer who built their site. The plugin had not received an update in eighteen months when a WordPress core update changed the way certain JavaScript events were handled. The booking form calendar broke on mobile. The plugin’s support forum showed a pattern of unanswered questions going back fourteen months. The developer had moved on.
The site was taking a meaningful portion of its bookings through this plugin. The calendar issue meant the booking form was functionally unusable on mobile — which, for a hospitality business, is most of its audience. The migration to a supported booking plugin was urgent, unplanned, and disruptive. Not because anyone made a bad decision. Because nobody had been tracking whether the plugin was still actively maintained.
The professional services firm and the forms plugin nobody knew was deprecated. Multiple professional services sites in the portfolio were using Caldera Forms as their primary contact mechanism. The migration to a supported alternative — Gravity Forms, WPForms — was straightforward once it was raised. But it wasn’t raised until an active audit found it. In the meantime, the forms were live, handling real enquiries, on a plugin with published end-of-life status. The plugin hadn’t broken. It was just silently becoming a liability with each passing month.
The e-commerce site and the extension that stopped being prioritised. A WooCommerce site had a product comparison feature that broke following a WooCommerce core update. The breaking came from a third-party WooCommerce extension developed by a commercial plugin company — not a solo developer, not an abandoned codebase, but a live commercial product. The extension’s developer had prioritised compatibility updates for their higher-traffic products. This extension, lower in the commercial hierarchy, received its update weeks after the WooCommerce release. During those weeks, the comparison feature was broken, the business didn’t know, and customers were encountering errors.
This is the version of the burnout story that doesn’t fit the simple narrative: it wasn’t abandoned, it was deprioritised. Commercial plugin companies make rational prioritisation decisions. Those decisions don’t necessarily align with what any individual site needs. Depending on a plugin means depending on that developer’s priorities, and you have no visibility into what those priorities are until something breaks.
What “Planning For It” Looks Like
The argument so far establishes that plugin authors burn out, get acquired, change direction, and deprioritise — and that this is structural, not exceptional. Planning for it is not a special precaution. It is the minimum necessary practice for any site intended to operate for more than two or three years.
In practice, this means: maintain a plugin inventory and review it annually — any plugin that hasn’t been updated in twelve months gets flagged. For every business-critical plugin (forms, booking, e-commerce), know what you’d migrate to if it disappeared tomorrow. Favour boring, well-maintained options backed by stable commercial models over innovative one-person projects. And replace any plugin that can be handled in fewer than ten lines of code with custom code in a mu-plugin — eliminating the dependency entirely, as covered in Truth #1.
This sounds like overhead. It takes thirty minutes per site per year. The alternative is discovering you’re running an abandoned plugin at the worst possible time.
The Managed Hosting Layer
There is a version of this responsibility that belongs to the hosting provider.
A business owner running a WordPress site has no way to know that Caldera Forms has been sunset, that a particular booking plugin hasn’t been updated in fourteen months, or that a WooCommerce extension they depend on is lower in the developer’s commercial priority stack. They installed it because someone recommended it. It appears to work. They have no visibility into the maintenance status of the code running on their site.
A managed hosting provider who actively monitors the plugin stacks across their client portfolio — who tracks end-of-life announcements, who notices when a plugin stops receiving updates, who initiates migrations before the vulnerability disclosure happens — is delivering something genuinely valuable that no shared hosting plan or generic platform provides.
This is one of the specific things we track across our portfolio. When a plugin in active use across multiple client sites goes twelve months without an update, we flag it. When an acquisition is announced for a plugin in our stack, we review the acquirer’s track record. When a security disclosure affects a plugin version that clients are running, we have already been planning the migration.
Truth #6: Only 3-5 Plugins Per Vertical Actually Matter establishes that the number of plugins you need is much smaller than most people install. Truth #9 adds the temporal dimension: of the plugins you do install, you need a plan for what happens when the author is gone.
The Practical Question
If you’re running a WordPress site right now, the question is: which of your plugins are one owner’s decision away from being sunset?
For every plugin that handles something business-critical — contact forms, bookings, WooCommerce and its extensions, payment processing — run through this checklist:
- When was the last update? (If more than twelve months ago for an active plugin, flag it.)
- Who maintains it? (Solo developer, small team, or organisation with clear commercial continuity?)
- Has the plugin changed hands in the last three years? (Acquisition history is public for commercial plugins.)
- What would you migrate to if this plugin became unavailable tomorrow? (If you don’t have an answer, you should.)
- Can the functionality be handled by custom code instead? (For small plugins: almost always yes.)
This is not a one-time exercise. Plugin dependency is an ongoing condition of running WordPress at any scale. The plugin stack you have today is different from the one you’ll need to manage in two years, because the plugin landscape will have changed — and not always in ways you control.
The managed hosting provider who makes this review part of standard practice — who tracks dependency risk across a portfolio, not just a single site — is the provider who prevents problems that other providers respond to.
A Note on Dependencies You Can Control
The larger argument, across this series, is about what you can and can’t control in a WordPress installation.
You can’t control when a plugin author loses motivation. You can’t control when a plugin company decides to sunset a product. You can’t control what a private equity acquirer decides to do with a plugin it bought because the customer data was interesting.
What you can control: the number of external dependencies you run, the replacement readiness you maintain, the proportion of your functionality that lives in custom code rather than third-party plugins, and the operational discipline to notice when a dependency starts showing signs of neglect before it becomes an emergency.
The WordPress ecosystem is extraordinary — built on the discretionary contribution of tens of thousands of developers over twenty years, serving 43% of the web. It is also structurally fragile in one specific way: any given plugin in that ecosystem is dependent on a human decision to keep maintaining it. That decision is not guaranteed. It is not permanent. And on a long enough timeline, it fails for every plugin.
Planning for it is not pessimism. It’s operational realism.
This is part nine of The 11 Truths About Web Hosting. Read Truth #1 — Fewer Plugins, More Custom Code for the argument about replacing small plugins with a custom mu-plugin. Truth #6 — Only 3-5 Plugins Per Vertical Actually Matter covers the Caldera case study in depth and explains which plugins genuinely matter per business type.
Free site audit including plugin dependency review: managedhosting.partners
