I am a massive proponent of people making money off of plugins. I think they can and should find a way to create a business in this ecosystem we’ve created.

There’s a problem with the approach of some of these products, and in a way we created it ourself, and it hit WordPress 4.5.

There is a plugin, it doesn’t matter which one, that’s a premium plugin. It’s not available for free on WordPress.org. You have to buy it, get a license, enter the license into the plugin, and in that way get updates. That’s fine. But there’s a complication. Actually a couple.

Licenses Expire and People Aren’t Informed

That’s a big ‘no kidding’ moment, but they do expire. And people don’t always notice that their license expired. Even if you post a big sign on the dashboard and email them.

Worse, people don’t know they have license. One of the major problems with software, when purchased for a company, is ownership. If I buy an app on the company dime, it’s their app. But when I buy an app for someone I’m building a site, and I pay for it myself, even if I charge them for it, who owns it? Who keeps the license? Who has the information for running a site?

This is an aspect of WebDevelopment where we collapse, regularly. Not just WordPress, every single person who builds websites for someone has screwed this up at least once. Either the information isn’t clear, or it’s not there at all. Regardless, what happens in the end is you have someone who lacks the information they need to keep their company going.

The Plugin Is Often Bundled in Themes

This is worse than you think. The official directions for this says that if your theme bundled it, and you need an upgrade, you need to wait for the theme to upgrade or you need to buy a license yourself. That’s perfect, to me, except for the problem I mentioned before. People don’t know. I’m not sure how they should know. But those bundlers, they’re so very problematic because they remove users one more step from the information.

If I buy a theme, and it has a library inside it, it’s the job of the theme developer to update that theme regularly, test it with WordPress before the new version comes out, and push fixes. If I buy a plugin, ditto. When the stream cross, though, is where we have the drama. Because I know I bought the theme, but I do not know that I bought this mystery plugin, hiding deep inside. Now it’s the theme owner’s job to update and make sure I get the information right away.

Pretty Much No One Gets It Right

Not even people I respect get this right all the time.

Let’s say you’ve written a plugin and have decided to handle all the updates yourself. I buy it, install it, and it works, everyone’s happy. What happens when I stop paying my license? Well I stop getting updates, that’s for sure. But do I still get notifications about them? Do I get an email? Do I even get an update?

There are some plugins that are free from pay-walled sites, but if you don’t have an active license for that free plugin, you will not get updates. At first I thought it was strange, since if I had a free plugin why wouldn’t I put it up on WordPress.org, right? But then I realized they’re creating the relationship. Once you ‘buy’ the free plugin, you have an account and information in their system. If it’s free, you’re the product.

All that aside, it comes back to the problem of what happens if that license, free or not, lapses? You could be annoying and pop up on the settings page “Hey! The license expired!” but people hate that and ignore it. You could email, but they ignore that too. There really isn’t a great way to remind people that (a) the license expired and (b) there are updates available.

Or Is There…?

What if the updater kept checking, license expired or not, and when you clicked to upgrade it alerted you?

You license for Foobar has expired. Please renew it in order to upgrade.

What if you got this email?

Hey, you bought Foobar back in 2014 and that license lapsed. Normally I’d never bother you, but today I’ve pushed a major security fix. Since this is a security release, I’m offering you a discount. It’s already applied to your account, just log in and you can buy the upgrade at 50% off. If you’re not using Foobar anymore, click here and I’ll have your account flagged so we don’t bother you about this again.

How happy would you be to find out someone saved your soy bacon?

This would require the original developers to have your information, which they probably do, and some way to track those two things. That is, did your license lapse and do you care? That’s all they need to track and only one is an ‘extra’ since I’m reasonably sure everyone tracks the license.

Make It Easy

If you make it easy for someone to know “This has been expired, here is one click to pay” people will pay. Yes, we love free, but we love easy even more. If you make it easy to pay, people will renew and pay. If you inform them of security issues, they will pay and upgrade. If you push them, the good way, about your updates, and make sure they know, they will be safer.

And then, when WordPress upgrades, your users won’t hate you.

Reader Interactions

Comments

  1. This is something through which I’m currently working, and it’s not easy. Checking the status of a license takes some work, and then there is the question of how pushy to be with the admin notices. I like the idea of including a link to purchase a new/renewal license straight from the upgrade screen, so that’s next on the list. Thanks for the thoughts!

  2. Howdy, Mike.

    Bob from Max Foundry. Great post about an issue we think a lot about.

    The issue as a plugin publisher you run into is all of the moving parts aren’t there. You have to build a lot of them yourself.

    We used wp-updates and so did over 1,000 others until they just closed down. So we wrote our own updater that week. Then we rewrote it to handle multiple plugins on a site because one of our products has addons.

    We use WooCommerce but its system for licensing of downloads is sorely lacking. And this is particularly true in anything we want to do around renewals. And that’s the best ecommerce system out there.

    Finally the notifying users in the plugin is going to require some infrastructure and coding too. The folks at Gravity Forms have done a nice job on this, btw.

    Sending email for renewal works pretty well.

    But the point is that none of this stuff makes us much money. It’s all sunk cost.

    So that’s why most of your plugins don’t bother with fixing it. It’s a lot of work to do right. And most plugins don’t make enough money to justify it.

    We email users

    • @Bob Senoff: It’s not a sunk cost when you factor in what will happen when (not if) your product breaks with an upgrade to core.

      Core updates are a constant and consistent. They happen. People do not upgrade plugins. So when they upgrade core, the plugin breaks and the bad press will start with ‘WordPress 4.9 broke my site’ but end with ‘Plugin Foobar broke with WP 4.9’

      And then you will get one star reviews. You will get angry posters. You will get angry blogs.

      And you will lose money.

      This isn’t a sunk cost, it’s a preventative CYA move.

    • @Ipstenu (Mika Epstein):

      I agree. It just doesn’t add that much additional revenue compared to how much work it is. Building a system like this the right way is 2 months of work.

    • @Bob Senoff: I call bullshit 🙂

      All development is an investment. Building ANY system right is a time sink. It’s about saving you time and money later.

      You’re forgetting (or ignoring) that the after cost and time sink of dealing with angry customers will be more than 2 months and more than the cost of those 2 months.

      Spend the time to get it right, once you know there’s a problem, fix it, and you will save time later since you can reuse the code and users will be more easily notified, informed, and in the loop, which saves you moneys and times later.

    • @Ipstenu (Mika Epstein):

      So I’m not saying that it’s not worth it. What I’m saying is that with thousands upon thousand of folks writing and sell plugins it is a sunk cost for any single dev to write this stuff.

      So either just use email which is fine for a lot of free low cost usage plugins who don’t use the wordpress repo, use EDD which probably works out to $100 a site by the time you get a payment extension and license keys and another extension or two or write your own.

      When you write your own it’s a lot of work that is not trivial. Which in my point.

    • @Bob Senoff: I think you’re not using sunk cost properly.

      A sunk cost means something you’ve already paid for and cannot be recovered. So your argument sounds like you’re saying that if you spend $200 or 200 hours on developing your own software, the money or time is gone and can’t be recovered.

      That doesn’t mean it’s not worth doing. Which is why I call bullshit. It’s not a sunk cost any more or less than any development is a sunk cost. All work costs something. That’s just the nature of work.

      The question is not “Will this cost me time/money?” but “Will this be time/money well spent?” and also “Will this time/money expenditure net me a profit?”

      Is spending 200 man hours today in order to save you 12 hours of support tickets in a month when you release an update? Is it worth not being on the front page of Sucuri when your plugin is the latest target of a 0-day exploit? Is it worth the inevitable loss when your userbase loses trust?

      Yes. Yes it is.

      And if you wanted to save the 200 man hours and spend $200 instead to buy software to do it for you ($239 for Pippin’s EDD software licensing for unlimited sites, $82 for one site), then that’s cheaper (assuming you charge at least $20/hour) but again, comes at a different cost.

      But now we’re into understanding the risk and reward of software development, which is a whole different topic.

      My point is this.

      It’s not a sunk cost. It’s the cost of doing business.

    • @Bob Senoff: BTW, her name is Mika, not Mike.

    • @George Stephanis:

      Thank you George.

      Mika, my deepest apologies.

  3. It would also be great for premium plugin developers to adopt a standardized handling of license keys in the database of a site. Wouldn’t it be great to be able to go to a single page on your site (or an extra column on the plugin page) and see every license that is active/expired?

  4. It’s hella tricky, and I’ve seen dozens of different ways of doing it, ranging from Genesis: which says basically…

    If you have any version of our codebase, licensed or not, you can have an update. Why? Because we want you to be running the most stable, secure version we can provide.

    to Freemius: which says:

    When your license expires and you’re not getting upgrades anymore, the plugin itself deactivates and becomes non-functional.

    This can (suprisingly) be a good thing from some perspectives — sometimes it’s better to run no plugin than an outdated, insecure, buggy old version? (It can also be bad and potentially problematic if it’s GPL, but I’m just saying that in some circumstances it’s better to have a plugin deactivate itself than allow an insecure, outdated version to continue)

    • @Ipstenu (Mika Epstein): Great post. I think it’s another reason why automatic renewals are important (with an email reminder a few weeks before the renewal). In my opinion, the combination of one-time email reminder, one dismissable admin notice and a message in the admin plugins page (just like other .org plugins) is the perfect combination.

      @George Stephanis: Thanks for mentioning Freemius. Just to clarify, it’s up to the developer how he implements it. Technically speaking, we provide a simple SDK function like:

      is_plan(‘professional’) ){
      ……
      }
      ?>

      The logic in the scope will always run if the user has a valid license. But, if the license has expired, the developer can choose whether the logic will continue to run, or not. We don’t enforce deactivation.

  5. One simple way to handle this is to split functionality of plugin between…

    Free features + Paid/Premium features.

    Then publish one plugin to handle all features in the WordPress repository.

    When license lapses, have API for premium features return no data + status code notifying user they require to login into site providing API features to renew their license.

    Clients I host Websites for, this is how I suggest they deliver their API based features to their clients.

    • @David Favor: That would be a terrible business model. And not permitted to boot. At least not in the way you described it.

      If you make a plugin with all the features, and arbitrarily disable some, first of all you’re violating the guidelines. If the code is in the plugin and can work, you cannot license check to enable/disable. This means you need to remove the code that’s in the premium add on. And we’re back to the beginning again.

      License checks have no place in the wordpress.org repository (unless you’re a service).

      Now a ‘work around’ would be have the base code that can do the license checks in the main plugin, which is what EDD and others do. It’s inert, and only activated by the child plugin with the add ons. Basically the main plugin can do everything it says it can. The child can hook into the system and update the licenses etc via the main plugin, but it’s a two-part system. On it’s own, the main plugin makes no checks. It must have that second plugin.

      But that is the exact issue people have today with an all-premium plugin, and that is they’re not making the check in a way that informs users for security issues (or any updates) if the license is expired.

  6. Pippin Williamson says:

    We made this change in Easy Digital Downloads a few months ago around the release of version 2.5. It applies to both our own extensions and any plugin our customers sell through our Software Licensing extension.

    The difference it makes is phenomenal, not only are significantly more customers running up to date plugin versions, renewal rates associated with those license keys also goes up dramatically, simply by the customer being aware that an update is available.

    • @Pippin Williamson: Funny you mention that. I was just about to post that after seeing EDD lead the way in this I’ve also started emailing customers when important updates are released for our pro plugins.

      Also worth noting… for those that use EDD Software Licensing check out Downloads > Licenses > Expired > Bulk Actions > Send Renewal Notice
      ^^ Isn’t hard to get a list of past customers that need to be notified about an urgent upgrade.

    • @Maeve:

      Really nice work on EDD, Pippin. Impressive job.

  7. We just do lifetime free updates for WP All Import / Export. 🙂

    Everyone keeps telling me I’m insane and maybe we’ll test out yearly licenses again in the future but lifetime free updates solves so many problems, users love it, and I really don’t think we make less money because of it.

  8. The biggest problem with plugins hosted outside of w.org: multisite.

    On stand-alone sites, any activated plugin can hook WP to run its own update checks. The key word here is “activated”.

    On multisite, only plugins activated on the primary site are able to hook the update check process to normally flag its updates. Anything activated only on non primary sites (blog ID > 1) will not be checked. Plugins that host outside w.org need to recognise that and handle it themselves somehow.

    EDD’s Software Licensing does a reasonable job of this, but still isn’t perfect. It can’t be, because WordPress multisite isn’t built that way. On multisite, you must be running in the context of the site where the plugin is activated for your plugin’s code to be executed. That includes any update hooks you set.

    As Bob says above, Gravity Forms has done a pretty good job here (better, I believe); must look more closely at how exactly…

%d bloggers like this: