WordPress Plugin License Renewals and the Challenge of Churn

When you buy a WordPress plugin, what are you actually buying? Is it software? Access to support and updates? Something in between?

Last week, a controversy sprang up on Reddit (alongside a more insightful discussion on Twitter) about MemberPress. MemberPress currently blocks access to your admin backend if you don’t renew your annual support license. Beyond the disgruntled users expecting a cheap or free lunch is a legitimate and challenging question: When someone “buys a WordPress plugin,” what are they actually buying? What do they think they are buying? What expectations are you communicating to them as a developer or product owner?

Let’s take a look at MemberPress’s new approach to license renewals. I’ll explain why they might be trying to represent their plugin more as a software-as-a-service tool than a piece of software you can use indefinitely. We’ll also consider why MemberPress is likely to be effective at increasing renewals even though an average WordPress developer can easily jailbreak the blocked MemberPress admin screen with a few lines of code.

With so many WordPress plugin companies dependent on annual renewals, it’s clear that we need a better solution than crippleware and intrusive, high-pressure sales messaging in the admin interface.

But most importantly, I want to talk about churn: the rate at which a recurring program loses subscribers. With so many WordPress plugin companies dependent on annual renewals, it’s clear that we need a better solution than crippleware and intrusive, high-pressure sales messaging in the admin interface. How can we make plugin renewals easy and fair for users — and profitable and predictable for developers?

The MemberPress Churn Challenge

MemberPress is a plugin that allows people to sign up for your site, pay a recurring fee, and get access to members-only content. We have some clients who use it, and I’m a fan. That said, this is a very competitive space. There are many other WordPress plugins like WooCommerce Memberships, Restrict Content Pro, and a wide array of software-as-a-service solutions like Memberful and Patreon. They’re all angling to take a cut of your membership dues in exchange for making membership management easier for site builders. 

It’s not uncommon for MemberPress’s target audience of content creators to be plagued by churn in their membership programs too.

Despite all this competition, a simple membership system is not a very difficult thing to build if you’re a full-stack developer. MemberPress is good software, but it’s also competing in a space with a lot of confusing options. It’s targeting users who aren’t super tech-savvy or willing to spend money on custom coding.

MemberPress plans range from $179 to $399 per year. For the WordPress ecosystem, that’s high. MemberPress is no doubt a key — if not the most important — component of its users’ membership sites and business operations. We can assume those customers are highly engaged with MemberPress. It’s not the sort of thing you just set up and let sit untouched for long. However, I think we can safely assume the MemberPress team believes they are losing people on annual renewals. It’s likely those lapsed customers are using older versions of the software without upgrading to save some money on license fees each year. These users are churning out of their annual renewal, and MemberPress makes less money as a result. The per year pricing may be a key barrier, a point I’ll come back to later.

The fundamental question: When you pay $179 for a plugin, what exactly are you buying?

To combat churn, MemberPress now checks your license key and turns off its admin backend if you don’t pay. While this is normal behavior for a software-as-a-service tool, it’s very unusual for a WordPress plugin. Plugins usually keep working (but refuse to download future version updates) even if you don’t renew. Some features might be disabled, but core features and the admin screen will operate as usual. An outdated, unrenewed plugin might eventually break in a future version of PHP or WordPress, but for the most part, you’d still have functional, unrenewed software for several years. Unpatched security vulnerabilities may also become a dangerously ignored issue.

It’s not uncommon for MemberPress’s target audience of content creators to be plagued by churn in their membership programs too. I think we can safely assume that MemberPress knows this and has done a ton of research helping its customers deal with churn rates. That knowledge may have led them to experiment with a more aggressive approach to plugin license churn. It’s an extreme escalation of the trend my colleague Brian Coords discussed recently, in which more and more plugins are screaming more and more loudly in your admin notifications.

The Right Way, the Wrong Way, and the Elusive WordPress Way

There are significant differences in the ways plugin owners think about and operate their businesses. This is an opportunity to learn and grow together. WordPress developers, product and agency ownerswe want your perspectives on these topics.

Buying software, or buying access?

MemberPress has raised some eyebrows in the WordPress world because locking admin screens is an unorthodox approach to churn there. There’s also been a pattern of popular plugins making dramatic changes that are jarring for users. For example, in 2021 a similarly named but unrelated plugin called ProfilePress released a major update to a recently acquired codebase as part of a rebrand and transformation of a free plugin into a fremium product with many new features. The existing base of users was surprised and many were angry — it wasn’t what they had signed up for, including the paying customers.

Additionally, admin notifications being used for sales have caused enough clutter and frustration that plugins to block them have emerged, along with other attempts at finding a solution.

The fundamental question: When you pay $179 for a plugin, what exactly are you buying?

We should know this, and our customers should know it. We should all be on the same page. But that’s generally not the case in the WordPress ecosystem.

It should be a red flag for the WordPress community that it is not obvious which of these two scenarios applies to commercial WordPress plugins. They are very different from the standpoint of the end user — but the professional WordPress community provides little or no guidance on how plugin sales should be structured.

One camp thinks you’re buying the software itself — just as you might pay $59.99 for a video game or $210 for a CD-ROM copy of Windows 95. Even though there is technically an “end user license agreement” that puts some legal restrictions on that software, nobody can take it away from you or suddenly make it stop working. From this angle, the annual fee is optional, and you can skip it if you don’t want future updates or support.

The alternative is that you’re buying access to a tool — just as you pay $8 a month for access to Slack or $29 a month for access to the squat rack and treadmill at the gym. In this scenario, you don’t feel like you own anything, and you expect to lose access as soon as your billing period expires.

It should be a red flag for the WordPress community that it is not obvious which of these two scenarios applies to commercial WordPress plugins. They are very different from the standpoint of the end user — but the professional WordPress community provides little or no guidance on how plugin sales should be structured. Inevitably, this leads to boondoggle situations where users are unpleasantly surprised. I tend to view a plugin purchase as buying software, but that’s just a tradition, not a hard-and-fast rule.

We shouldn’t be setting up situations where our highly sophisticated web developer audience is incentivized to jailbreak our products, just as people do with ebooks and other products subject to copyrights and “digital rights management.”

Similar issues are popping up, for example, with Kindle ebook licenses. It turns out you don’t own the book at all, and in rare cases, Amazon can unilaterally remove it from your Kindle forever even though you paid for it. This is so ridiculous and baffling, I think it is self-evident that the WordPress community should not encourage this type of licensing scheme. WordPress is not Amazon or Apple or Nintendo. We shouldn’t be setting up situations where our highly sophisticated web developer audience is incentivized to jailbreak our products, just as people do with ebooks and other products subject to copyrights and “digital rights management.”

I downloaded the MemberPress plugin as I was writing this article, and it took me less than four minutes to find the function where you could swap out a few lines of code to spoof an active license status. (That’s way easier than jailbreaking an iPhone or modding a Nintendo Switch!) Doing this is not illegal, since the GPLv3 under which MemberPress is distributed allows you to “change the software to suit your needs” and even “share the software with your friends.”

Since any WordPress developer would have access to all the plugin code in plain text, it would be trivially easy (and legal) for them to get around this alert if they wanted to stop upgrading. Unlike plugins that rely on cloud services to function, such as Akismet and Imagify, this plugin would probably work just fine without updates, as unwise as that may be to do.

Who is this upgrade prompt for?

So, MemberPress believes users are buying access to a tool, and yet they are distributing software that can be easily modified by any developer or code-savvy WordPress user to allow unpaid access. It’s like an exclusive gym membership that comes with a normal, copyable key to the door of the building. How does this make sense for their business?

It works because MemberPress is targeted toward a non-technical audience — and thus its customers by definition can’t get past its upgrade prompt. (Sorry, anonymous Reddit guy!)

The real problem is the people who don’t even know they need to take action.

Their target users are not coders and may not even fully understand that they need to pay for an annual license or keep their plugin up to date. Because MemberPress serves a relatively novice audience and many of its competitors are software-as-a-service platforms, MemberPress can act more like a SaaS tool than a traditional WordPress plugin. It would be silly to do the same thing for a developer-centric plugin, such as Better Search Replace Pro or WP Migrate, because users would just roll their eyes and hack their way around it.

At the same time, let’s remove ourselves from the Reddit complaint-fest for a moment and think about the actual implications of blocking the admin backend. If you’re not using the plugin anymore, it doesn’t matter if you renew, because you’re not using it. But if you are actively using the plugin and it is actively helping you make money from memberships, how could you possibly justify not paying for it anymore?

In short, I think the number of scenarios where you need the plugin but have a justification not to pay for it is almost zero. The real problem is the people who don’t even know they need to take action. Their lack of awareness is largely a result of a disjointed developer-to-client (or employee-to-owner) hand-off process, in which a tech-savvy person buys a plugin, gives it to a site owner, and a year or two later, nobody knows whose job it is to renew the license.

License handoff churn is a WordPress crisis

License handoff churn is something my team and I think about a lot. It’s one the cornerstone of WP Wallet, which is a tool we built to easily track plugin purchases and quickly bill clients for annual reimbursements. (It’s a fremium SaaS with a plugin in the WordPress.org repo.) We learned from experience that most companies (whether agencies, small clients, or large organizations) don’t have a good way of tracking what they’re buying and when they need to renew a subscription. They often theoretically have this information in a spreadsheet somewhere, but it’s out of date and the key people don’t have access to it or know how to use it.

The result is the site owner takes no action on annual renewals, and this drives the plugin owner to devise a way that cannot be ignored to remind them to pay their bill. Because of the nature of the hand-off, the plugin developer often doesn’t even have the email address of the person who makes financial decisions. And when it comes time to pay, the stakeholders say:

“Do I already have a key or should I buy a new one?”

“Should I pay for this and get reimbursed, or should my client/employer pay?”

“Does anyone know the password to this random e-commerce site I have to log into once a year?”

“What is this cryptic company name on my credit card statement that doesn’t match the name of the product I bought?”

“I think we should loop in Bob from Accounting.”

Needless to say, these are major logistical barriers, and the confusion around plugin renewals is costing our community’s commercial developers a ton of money. WP Wallet is one way to solve this problem. When you build a site, you can sync all your plugins, we’ll estimate how much they cost, and then you can create a recurring invoice and send it to your client so they pay you back every year automatically. Plugin developers get paid, site developers get paid, and clients don’t have to get yelled at when they log into WordPress.

Down the road, one of the possible futures for WP Wallet is a consolidated way to purchase and renew many plugins from a single interface. While this will be a big community-driven project, we believe there’s an opportunity to help everyone. Plugin developers can reduce churn by allowing people to renew through a simple and common interface. End users can easily track their renewals and request reimbursements from the same place. (If you’re a plugin developer and want to work with us on reducing your churn, email me and we’ll chat about Beta testing.)

I’m not just here to plug my software, even though it’s awesome! There are other ways you can reduce churn too.

Offer five-year licenses for the cost of four. Offer monthly plans. Make your identity or your product’s identity clear on credit card statements.

For example, they could offer five-year licenses for the cost of four years, ensuring they get paid upfront for what is essentially the full life of the newly built website. This means no renewals, nobody having to do an annual accounting reimbursement and way less friction. The plugin developer gets paid for the full value, and it’s less hassle for the end user. If the site still exists in five years, everyone can celebrate by renewing the license. This is a good option if you’re not sure you want to commit to a “lifetime” license but want many of its benefits. (Done right, lifetime memberships can work too.)

They could also go the other direction and offer monthly plans, which have the benefit of being high-touch and top-of-mind with end users. While software-as-a-service sites believe that monthly renewals have a higher churn rate than annual renewals, I believe the fact that most plugins are paid for by someone other than the direct buyer makes the WordPress ecosystem a bit different. Seeing that charge on your statement each month might make it easier to remember what it is, why it’s useful, and why you’re paying for it — and it also spreads out the cost so it’s not a source of sticker shock once per year. (As much as I love annual discounts, it’s always a little grating to pay a huge amount once a year instead of a small amount every month.)

Plugin developers can also clarify who they are and what they are selling on credit card statements. I have a shocking number of recurring charges from companies with random-seeming names that are not relevant to the actual plugin I purchased. From an accounting standpoint, simply having the correct product name and URL somewhere in the statement descriptor would make accounting much easier, and make it simpler for people to know what they need to renew and when.

An app store for WordPress?

Post Status Editor Dan Knauss asks whether WordPress would benefit from an app store. Automattic has flirted with this idea by selling a select group of plugins via the WordPress.com dashboard, and WooCommerce has an extension store. However, when it comes to selling commercial plugins to WordPress.org developers, we have some big hurdles between us and a functional, widely used plugin marketplace.

The first challenge is that WordPress plugin developers are outstanding developers. It is trivial for them to set up a simple site to sell their software, most often using WooCommerce or Easy Digital Downloads. My company did this for our Understrap premium child themes in a matter of minutes. Because plugin creators have a very low barrier to building a decent e-commerce site (something not true of other industries), they are highly averse to paying a commission to a centralized marketplace. If their plugin takes off, even a small commission costs them tens of thousands of dollars — far more than what they’d spend building a quick site of their own. The status quo incentivizes developers to decentralize and create lots of disparate e-commerce sites selling a few plugins each.

I hope we can find better solutions than simply cranking up the volume of the admin notifications.

Unfortunately, this is awful for end users, so it quickly devolves into a tragedy of the commons. Every new e-commerce site is good for the individual developer, and in isolation, one new site doesn’t seem like a big deal. But when you repeat this for hundreds or thousands of commercial plugins, the customers end up with an indecipherable labyrinth of plugin renewals, password resets, and forgotten license keys. How many of us keep track of every single plugin license we buy? This decentralized, largely manual process is annoying for end users — and even though it seems beneficial to developers in the short run, it ultimately increases their churn rate because it makes the renewal process so cumbersome for their customers.

One of my whiteboard visions for WP Wallet is building a simple, centralized place for users to buy plugins, for developers to get paid (without unfair Apple-esque fees), and for everybody to keep their purchases organized, as automatically as possible. My team gently reminds me that this is not a reasonable goal for the minimum viable product, but we are still headed in that direction. With smart software and a fair cost structure, I believe a centralized marketplace can pay for itself many times over by reducing churn for plugin creators and dramatically simplifying the license-key busywork that frustrates so many WordPress freelancers and agency employees.

For now, plugin developers will experiment with novel ways to remind people to renew their licenses in the Wild West of the WordPress ecosystem. The struggle with churn continues — and I hope we can find better solutions than simply cranking up the volume of the admin notifications.

Rob Howard is the owner of WP Wallet, MasterWP, and Understrap.


Get thought-provoking writing like this and more in our weekly WordPress community news digest — Post Status’ Week in Review — covering the WordPress and WooCommerce news plus significant writing and podcast episodes from the WordPress community and beyond. It’s all in our newsletter. 💌

Similar Posts

2 Comments

  1. I get the idea of WP Wallet and the idea of a centralized place for purchasing plugins or themes, which does exist to a degree already (isn’t that what Envato is? Or Freemius?), but this question feels silly to me:

    “How many of us keep track of every single plugin license we buy?”

    Uh, everyone?

    Maybe it’s just me, but isn’t keeping track of subscriptions you pay for a part of running a business and normal accounting functions? I feel like the author is trying to manufacture a problem where there is none.

    Would it be convenient if all WordPress plugin purchases could be managed on the same website? Maybe. But I’m not sure that would resolve the issue of a developer making the first purchase then canceling the subscription and expecting the client to purchase their own license for subsequent years. If the client is supposed to maintain a license themselves, the solution is just to make them purchase it from day one. Then they can track the subscription through whatever process they track all of their subscriptions.

    Really, if you think about it, most businesses already have a centralized place for tracking all of their SaaS (or WordPress plugin) subscriptions – their accounting software. Categorized appropriately, it would be easy to run a report and see every plugin that you’ve purchased, for how much, and when it renews. If a business doesn’t have that capability set up already, then they have way bigger problems than an expired license key.

    1. No, I don’t think anyone can speak for everyone, and no big group ever does anything all the same way.

      I’ve heard versions of this “you must be doing it wrong” / “it’s not a real problem” response many times, and I think it’s not only incorrect, but it also discourages different views from being expressed. (It’s often present in the old “who is a ‘real developer'” drama.)

      But in my experience, EVERYONE IS DOING IT WRONG. 😀

      Think about what “keeping track of X” really means in any business, especially the more hands are involved. Is having an emailed invoice, a billing statement on a bank account, an automated accounting expense item, or a spreadsheet somewhere really the same as knowing “Today/tomorrow/next week license X is going to expire if Y hasn’t yet renewed it — and Y is still alive and the person responsible for this at company Z?”

      If you have reminders set up and someone keeping all this well-updated and monitored, you are accruing a lot of overhead to do what WP-Wallet apparently will do much better.

      So I don’t think Rob was manufacturing a problem. That would be a bad business model for WP Wallet as a solution to a non-problem. 🙂

      As to the possibility of making clients purchase all their licenses from day one, how is that a solution? To make it go well, you’d have to get a site into production, assess all the moving parts, document them, give special attention to the breaky bits and single points of failure (including licenses) and then try to educate the appropriate people on the client’s team about this. Maybe set up an email user or alias on their domain specifically to receive notifications from the site and key sources, like plugin companies they use.

      That’s a lot of (ideally billable) work for you and them. Do they have the people and capacity for it? Today? Tomorrow? Syed and others say you should take their money to make this all go away so only you have to think about it. Or a maintenance company. Or a service like WP Wallet…

      It’s really complicated and client-specific!

      It astonishes me there’s not a clear best practice that’s well known for freelancers, small to mid-sized agencies, and those serving enterprise clients. Everyone does it their own way, but does anyone have a fantastic method?

      Why haven’t commercial WordPress product owners made it easier for all these possible stakeholders in their customer base to understand their product, how and why to renew it, and cater to those who have agency/developer licenses and clients using them?

      Seems like lots of opportunities to do things better / less wrong together. 🙂

Comments are closed.