Why charge for addon/plugin updates

The ExpressionEngine add-on marketplace, Devot:ee has implemented a pricing option for add-on developers that I believe will change the commercial add-on industry for the better (not just for ExpressionEngine). That option is what they call “timed downloads.

At it’s core, “timed downloads” allows add-on developers to set expiration dates for updates on their licenses. When a customer purchases an add-on, they are eligible for updates to that add-on for a period of either 6 months, a year, or two years, depending on what the add-on developer has specified. Once that time period is over, the customer has the option to renew at an update price if they want to continue to receive updates.

This is a major shift in how add-ons have been priced. Previously, if a customer purchased an add-on through Devot:ee, they were eligible for updates to that add-on for life. Buy once, use and get improvements forever.

As EllisLab has continued to evolve and change ExpressionEngine, keeping up with major versions has increasingly put a large tax on the add-on developer community. What’s more, a lot of add-ons have evolved overtime to grow their feature set and give customers greater control over their EE sites.

Let’s look at the change log for Backup Pro, the earliest version of Backup Pro listed is 1.3.1 which was released on June 2011. Since 2011 Eric Lamb has added some amazing features:

– Remote FTP
– Backups to Amazon S3
– Backups to Rackspace Cloud
– Windows IIS/Apache support!
– Language / International support
– Numerous checks to ensure data consistency

You can also see he’s fixed a lot of bugs and issues (more on that later). So what version of EE was 1.3.1 released on? Well checking the ExpressionEngine change log 2.2.0 came out on June 22, 2011. Just this week we’re on version 2.9.1 of ExpressionEngine, that’s 21 versions in four years!

Just look at all of the code changes EllisLab has made to the product in that time, a lot of these changes have affected Backup Pro. Can you imagine how much time Eric has had to put into testing and developing for each version? Testing and developing by himself, for four years. So if you upgrade to the latest and greatest EE version today from 2.2.0 you can upgrade and use Backup Pro as well and it will work (it has to work after all, it’s backing up and restoring your data).

The worst thing about a version number is that it tricks us into thinking all 2.x or 1.x versions of software are the same. They’re not, EE 2.2.0 is a drastically different CMS from 2.9.1, and Backup Pro 1.9.4 is a drastically different product than 1.3.1. Reading the change logs on any add-on that’s been around for a couple of years will tell the same story.

So with that in mind, do you think a one time fee of $99 (or less) for 4+ years of valuable improvements?

Can you start to see the toll it’s taking on a number of developers who are supporting these add-ons part-time and for essentially steakhouse night money (we’re not all Pixel & Tonic or Solspace)?

Is it any mystery why we’re starting to see great add-ons abandoned or put on life support? Blueprints, Title Master, Membrr have all been dropped. CartThrob thankfully made it through last year but it was a close call.

I’ve been reading a lot of reactions on twitter and blog posts about this issue, and I think it’s great we can have a healthy discussion. I think there’s a lot of fear and uncertainty that comes across with change, especially when it means a change you’ll have to explain to a client. Let me throw in my two cents on some of the concerns I’ve seen.

Why is this retroactive?

Simply because it has to be for it to work. If Devot:ee doesn’t make it retro-active you’ll create a gold rush of add-on purchases before Nov. 1. Purchases add-on developers will have to support with free updates for years to come. That’s not going to make this better.

How do I explain this to my clients?

This I can empathize with, since I’m a full-time freelancer as well (most EE add-on developers do btw). I’m going to inform my client that a major shift in the add-on industry is happening that will ensure their sites will be supported with the same quality add-ons for years to come. This means, at times, when there is an upgrade to EE they may have to purchase updates to their add-ons. I’m going to advise my clients to upgrade to EE 2.9.1 this month and upgrade every add-on as well before Nov 1.

It may be helpful to explain to clients who EE add-on developers are: they are usually freelancers (like you) who sell add-ons as supplemental income. They are for the most part, one or two developers and they do most of the support and quality assurance as well. If it helps, remind clients that the cost of add-ons helps keep the implementation and billable hours low and helps you deliver features on time and within budget.

Why can’t I just pay for new features? Paying for bug fixes doesn’t seem fair.

I understand, but you probably charge your clients for bug fixes as well right? Do you only charge clients when you deliver new features? Code is code, there’s little difference between code that delivers a feature and code that fixes issues. Would Windows IIS/Apache support in Backup Pro count as a bug fix or a feature? Customers on Windows would likely say a bug, while Eric I’m sure sees it as a feature.

Why can’t add-on developers just raise their prices? Charge more and this wouldn’t be an issue.

I actually agree with this, most add-ons should cost more money, especially since they perform critical time-saving tasks. But let’s say the typical EE site lasts 5-8 years. If Eric were to price Backup Pro to account for a lifetime use of 5 years he would charge $500. That doesn’t seem unreasonable for backing up and restoring data.

However let’s look at my add-on, PDF Press. It’s currently priced at $35, if I were to apply the same math the lifetime price of PDF Press should be $175. Charging $175 for HTML to PDF conversion starts to look less reasonable.

Well isn’t that what this update pricing is doing? Charging us and our clients a yearly fee?

Not exactly, the update price only kicks in when you update. If the version of an add-on continues to work for your client (even after updating EE) then by all means don’t pay the update price. However if you need to upgrade and the license is up for renewal you’ll have to pay the update price the developer sets.

What about security fixes or the stability of my site?

Security and stability are a concern, but just as bug fixes and features can’t be separated in code I don’t think there’s an easy way to only roll out free “security” updates. That would mean we’d have to maintain and test multiple variations of our code to make sure we don’t release a security update that contains a feature customers we want to charge to customers.

Most of us work on good faith and we do our best to write our code well and without issues. Add-on developers don’t distinguish between fixes and features because they both provide value to the end-user. Security and stability of their websites are things clients need to constantly invest in, just as they need to invest constantly in the physical security and stability of their businesses.

Wouldn’t better docs, guides, videos help reduce developer’s support requests?

Absolutely! We all do our best to document our work and we know every customer throughly reads the docs and watches all of our videos before purchasing and using our software right? 🙂

All kidding aside, better docs and guides will help reduce support requests. But this isn’t really about support requests, it’s about finding a pricing structure that equalizes the add-on developer / customer relationship.

If you don’t like supporting it, don’t charge! Put it on GitHub and make it open source!

I hear this one a lot, and I could write a whole blog post about this. But let me be clear, if you think making something open source and free will allievate the burden of support you are living in a fantasy. Most open source projects are maintained by a single contributor. If you don’t believe me, create an add-on right now and put it on GitHub and wait for the pull-requests to flood in. They won’t come.

What will come are the questions on the support forums, the emails, the twitter mentions from users asking for help. If you don’t give them help or respond they’ll send angry emails and angry tweets and will likely remember you as that jerk that wrote that crappy plugin and had the gall to not support it.

This is an ExpressionEngine problem, if sales were strong add-on developers wouldn’t complain.

I don’t think this is true. WordPress has issues with plugin abandonment and support burdens on commercial add-ons as well. In fact, researching a startup idea regarding product support lead me to a great post by Thomas Griffin from last year “Making Amends for Business Decisions”.

In it Thomas details how he tried various support options for his popular commercial plugin Soliloquy, including charging customers for support tickets. The backlash against him was very strong. After a year of struggling he finally settled on charging yearly for support and updates. I urge everyone to read his post throughly.

Also read this post from WP Ninjas “The Cost and Challenges of Selling WordPress Products”. They make a very popular WP plugin for forms that has over half a million downloads and they struggle with support costs (they do an annual subscription plan).

Final Thoughts

Annual subscription for add-ons has been on my mind since last year (after reading Thomas’ post). I found the “pay once and get improvements forever” model to be the worst idea to come out of the software industry. No other product is sold that way. Even Apple has acknowledged this and given app developers the ability to charge for updates. It’s lethal to small dev shops and in the end customers are hurt when the developer is forced to abandon their product just to end the massive toll on their lives.

I really appreciate Ryan Masuga and the folks at Devot:ee for giving us this new pricing option and I urge every add-on developer to seriously consider using it. In time, your customers will see the value and you will too. I urge any add-on or plugin developer in all CMS platforms (WordPress, Craft, Statamic, etc) to consider annual subscriptions for support and updates from the beginning.

I welcome an open, reasonable and civil dialogue about this with any current or potential customer of PDF Press. I’ll be at EE Conference starting Sunday evening through Tuesday. We will make sure our update price is visible and transparent and we’ll work to continue to provide the best support we can.