A Tip for Convincing Customers to Renew License Keys

Mika Epstein, who helps review plugins before they’re added to the directory and is a dedicated support forum volunteer, has a great post on the difficulties associated with plugins that require license keys for updates. She addresses topics like keeping users informed, ownership, and bundling plugins with themes. She also suggests the following solution to get users with an expired license key to renew.

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

Your 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?

Based on the comments of her article and from what Epstein has experienced from years of providing WordPress support, it’s a complex problem without a solution. The perils of updating commercial plugins bundled with themes that require a license key were apparent two years ago when a critical security vulnerability was discovered in Revolution Slider.

Had the news not been published across media outlets, many users may not have known about the update. In some cases, users couldn’t update because they didn’t have the required license key, as was the case with Brenda.

The slider plugin was bundled in a theme that a PREVIOUS web developer installed for one of my clients. As such, I do not have the theme license key. There is NO WAY that I would ever have known about this extreme vulnerability had Sucuri not released it.

Some companies make security updates available to all customers regardless if their license is expired. For example, earlier this year, a critical security vulnerability was discovered in Elegant Themes products. Due to the severity of the issue, the company made the updates available for free to expired accounts. The updates contained only the security fix without any of the new features developed in recent versions.

There’s a delicate balance between pushing customers to upgrade, renew license keys, and making it easy to do so. As Epstein says in the conclusion of her post, “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’re a commercial plugin developer, how do you inform and convince customers to renew their license keys? Also, how do you handle security updates for customers with expired licenses?


27 responses to “A Tip for Convincing Customers to Renew License Keys”

  1. If a developers code brings your website at risk he should fix the issue regardless expired licenses. His code should have been secure in the first place. In most cases the fix applies to only one file that will also work on the older versions and or he can just provide the lines of code to replace. If not possible he should replace the plugin or theme update for free. Its like buying a car. When they discover a serious issue you get a callback to the garage of all the affected models. What foo plugins is doing is very bad at the expense of their customers to fill their own wallet.

    Btw this never applied to the revslider as the updates are free. The issue was fixed in feb 2014 and only existed for a week after it was discovered. Whereas sucuri brought it in august. The theme developers with the integrated plugins should have updated their themes and plugins long before that date but they never did as they did not know the issue. The rev team kept it quiet for a good reason. Unfortunately that backfired because of the way sucuri dropped it on the internet in order to gain as much publicity for their own business sales model. Sucuri should have contacted envato and the revslider team instead of dropping the leak on the internet putting all none updated websites at a great risk. Their sales benefit from it. I consider that a very bad way of doing business. They posted the leak As fast as they could open on the internet. They even posted the way to use it and get access to the sql database by the admin ajax call. How stupid can one be todo so? Thank you Sucuri ! (Not). The solution was simply update the plugin or theme with the plugin.

    But then again if a plugin updates and after 6 months the theme with the bad integrated plugin still is not updated or even users that bought the plugin did not update them then who is to blame? They all got more then one update notification since feb 2014, but they just neglected them. I have seen many themes updating the revslider in feb 2014. They never had the issue more then 2 weeks after it was discovered by the rev team.

    How different this was when the prettyphoto vulnerabilitty was discovered. It was silently brought to envato by somebody who discovered it and all the themebuilders and plugin builders using the script got a email to fix it which they did. It simply said security issue fixed in their update list. No big fuss like sucuri created. The developers where forced by envato to update otherwise their product was taken offline. Its a way sucuri could have taken. Instead they wanted the credits, big publicity and sales for their own product. To me that stinks even more then the security issue itself.

    • I have to laugh at the idea that it is somehow sucuri’s fault. Somehow you assume that bad guys can not find security problem in code by themselves. News flash. – bad guys are not idiots and probably can find security holes as well as sucuri’s experts. More likely that sucuri was reactive and got the announcement after analyzing security breaches that actually happened.

      • I did not say the leak is Sucuri’s fault. I said bringing it into the open and tell everybody how to hack a website using this leak caused all website being at risk of being hacked from that moment on instantly. That was Sucuri’s fault for which they are to blame !

        They should have contacted Envato and the RevSlider-Team first.

        Envato would have forced all developers to update their themes at risk of being taken offline. Also Envato would have send all people who bought such theme and the plugin a email telling them to update because of a security risk. But no one at Envato would have told the world how the hack worked.

        It’s the most stupid thing one can do for being a company who claims to make your website secure.

  2. This is an interesting topic, and I believe the solution is actually not so complex and already used. It’s SaaS.
    Users should always have the last version of the product. It is not possible to have users on a version that is 5 years old. Google and many other understood that so they have automatically update on Chrome for instance.

    I don’t think the model of a one lifetime fee really helps users. Because after one year, they don’t have support or updates. And no support means a really bad experience.

    You can’t charge someone a one lifetime fee for an ongoing service. This makes no sense.

    So the answer is SaaS.
    Users pay yearly (or monthly) as long as they use the plugin or stop whenever they want. They are free to keep using the service or stop it. As long as they pay, they have support, updates.

    I conclude on an interesting post from Chris Lema about this form last week :

    • So instead of a user having his or her content potentially held hostage by a hacker, s/he should agree to having that content effectively held hostage by the SaaS provider? How is that better?

      And let’s think about where the logic of the SaaS suggestion leads to. If every plugin developer were to make his or her plugin available only on this model, then the plugin eco-system would vanish completely.

      Either you’d just have plugins developed by that SaaS provider, or else every plugin developer would have to try to do a deal with a SaaS provider to get his or her plugin offered and supported on the platform.

      Frankly, if that’s the cure, I’d prefer to have the disease.

      • Agree with with @Peter. It’s really strange how just the word “SaaS” sometimes make people dubious and use words like “hostage”… It’s even stranger when you see outside of WordPress, where SaaS is hugely adopted and working fine.

        • It’s really strange when people claim to support mutually contradictory positions. If updating a plugin is all you meant, @Remy, then why call it a SaaS? You do know that SaaS means a hosted solution, don’t you?

          outside of WordPress, … SaaS is hugely adopted and working fine.

          For the providers, sure. But for users, it depends. What about providers who close? Or who raise prices significantly? Or who change their API, or their terms of business?

          If you’ve never had that happen to you, congratulations! But don’t generalize from that to think it’s the solution. The recent changes to OneDrive’s terms of business affected millions in just one go!

        • A lot of big companies are applying the ideas of SaaS to their deployments, which are basically just subscription based models, regardless of where the software is running (not always centrally hosted).

  3. There is another side of this, which is that on a commercial WordPress plugin you do not charge for the code, but for the support and updates over a period of time.

    The code itself, as derived from WordPress, is (or should be) GPL, which means that users with old versions can indeed get new versions from “lateral” sources if they want and can do it, but they will not get support should this “lateral” version not be safe or cover what he needs.

    I work for a company developing commercial plugins, and we do know this by heart. We have trademarked our product names, but nothing stops someone from taking our code, getting rid of product names and API calls to our own upgrade system, and go with it.

    So no, I do not think that someone that bought a plugin at some point should get security updates for life since that is exactly one of the things that you pay for. There can be some grey line if a security breach was found the week after your subscription expired, but at some point the deal is broken.

    Otherwise, someone could take WordPress as guilty for keeping old insucure plugins outdated in the plugins directory, which does not make sense at all.

    Just my 2c.

  4. @jadpm i disagree. You can secure your plugin enough so they cant get rid of code and if they do it should stop working. There are many ways to protect your code (f.e zend). Not all code has to be gpl. Look at what is sold at codecanyon. If your code puts websites at risk in a way like it happened with the revslider or f.e. Timthumb ( but that was free) it should be updated for that part to close the leak. You dont have to give away all new features. You can close the leak part and publish about it how people can apply it even if they run a old version. Or like the revslider plugin can do force a update for that part. You are responsible for big coding mistakes and can not hide behind a license agreement excluding all. At least i would not bet on that if your plugin is widely used and sold on a commercial base. Of course you need to make money but there is also your responsibility to take care of your mistakes. Its like buying a car. If they make mistakes putting your life at risk the car is called backed and the issue is fixed. If you want the new features of the next model you buy that car and thus upgrade. Why should this be different for software? Should your software malfuntioning put my business out of order? Then why do you feel its normal to get free updates from linux,microsoft and apple and you dont feel the same way for your own product? What do you think would happen if we all had to pay for security updates for microsoft and apple? And nobody complains after 10 years that it is fased out and not supported anymore. But why do i have to pay every freaking year for a plugin? I dont want the new features i just want a secure website. I paid more money the last few years on plugins then that i paid my whole life on OS software. Most plugins are more expensive then the complete OS software your computer is running on at only 1% of its coding size in comparison to the OS. Like all developers believe they should be reembursed for their coding effords. Sure but you have responsibilities too which you should take care of the correct way.

    • Besides all the direct questions asking for my opinion, you seem to have missed the point. The car analogy does not apply, because… you pay for the car! In WordPress commercial plugins, as stated time after time by the community, the code is or should be GPL as derivative work, an you pay for the support.

      So the question is: if a car maker decided to give its cars for free, but charge yearly fees for upgrades and support (including, of course, security reviews), do you really think it is fair that paying and not paying drivers get the same service in the event of a problem that could collapse support locations? The car was free, you got it and could change the engine yourself, we did our best to make it perfect at that time and we explicitly told you that our support required an annual fee.

      If so, how do you plan to pay for the workers?

      I am not against publishing an errata with a patch that you can apply yourself, do not get me wrong. But that is all.

        • If a code is an open source under GPL, it’s practically free. Even if the developer of that code does not offer it free, anybody else can. If anybody can, it means it’s free.

          If you can’t find that GPL code for free, it’s not bc. it costs something, just bc. nobody shares it with you.
          In most situation the developer will distribute that code to you for some $ with some service or a nice word.

  5. Three items.

    1. If every plugin will require a yearly payment for critical (security) updates there is a limit that many buyer/users will pay… meaning that they will use fewer plugins. It is one thing to have 15 plugins and pay $50 each for them one-time, but quite another for them to pay the same $750 EACH YEAR for a 48 month site life-cycle… $3000.

    2. The other problem is the logistics. No one wants to cut 15 checks a year to vendors. And no one wants to give some vendor they don’t know their credit card for annual billing. What would help if there is a clearing house of some kind (think Envato) so that users can write ONE check a year to a known entity for all of their plugins (pro rated if necessary for first year) and the house will take their service charge and remit the balance to the plugin vendors.

    3. The “pay me forever” system is going to work for the large, established, well-known vendors. I know the quality of the code that Woo or Gravity or Studio or Espresso sells. If I’m going to be locked in, I want to be locked into a company I believe will be around for a while. I probably won’t ‘waste my time’ on YOUR company’s plugin because I never heard of you and have no idea of what kind of code you write. If it means I have a choice of paying Gravity $400 over four years and paying you $400 over the same time… I’m probably going with the Gravity.

    Everyone here is looking at this from the side of the vendor. You need to look at this from the side of the buyer as well. The ‘solution’ has to be a win-win for both sides… and each side needs to recognize the needs of the other side… that the vendors need a recurring income and that the buyers don’t want to feel like they are being ripped off for updates with features they don’t want or need, nor feel they are being held hostage for site-breaking updates.

    There is a middle-ground somewhere and I’m sure that the market will find it.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: