Planned Obsolescence in WordPress

One of the things that we often see in the “offline marketplace” – for lack of a better term – is the idea of planned obsolescence.

Simply defined:

a policy of producing consumer goods that rapidly become obsolete and so require replacing, achieved by frequent changes in design, termination of the supply of spare parts, and the use of nondurable materials.

This is something that we see in auto industry, in the electronics industry, and in the computer industry. Think of it this way: Remember the iPhone 3? Or remember the Chevrolet Monte Carlo?

These are but two examples of products that were widely used – some for decades – and then were replaced by another product either by one with a brand new version or by an entire new line.

This is one of those things we don’t necessarily consider or talk about in the context of software. But why? All other platforms and languages aside, would planned obsolescence in WordPress be so bad?

What is Planned Obsolescence in WordPress, Anyway?

I’m not talking about the core application – although I think there’s a lot of good to be discussed there – but I’m thinking more in terms of themes and/or plugins.

For example, when it comes to themes, let’s say that you start off working on a new theme today and you’re introducing some cool new features, using some nice HTML5, CSS3, and/or JavaScript effects, and then you sell it and support it for a few years.

But then some aspects of the aforementioned languages become deprecated, or newer techniques are introduced. Then what?

Keep supporting the current version?

Introduce a New Version!

Sure – but does this new version have backwards compatibility or does it only support the latest and greatest features? If users upgrade to it, do they lose anything? What do they gain?

It’s worth asking these questions because in one case, you’re talking about maintaining legacy code. That’s a slippery slope once you get on it, and, unfortunately, legacy code gets a bad wrap especially in the economy of WordPress.

On the other hand, then you’re stuck supporting an older product for people who have yet to upgrade. And that’s completely fine so long as you set expectations and then explain to them why they should move and how to upgrade (or why they should upgrade) or even offer alternative themes.

Planned Obsolescence in a New Version

In this scenario, I see the following factors:

  1. A new version of the theme is introduced
  2. The previous version is maintained for a finite amount of time with a sunset date that gives the customer more than ample time to upgrade
  3. Any prior versions before the current version and the last version are retired. They can be made available for download with no support, or they can be removed.

Support Multiple Versions!

But for how long? The more versions of WordPress that are released, the more new features are introduced and the more that are deprecated. This means your customers and/or users are left running code that is declining in compatibility with the latest version of WordPress.

Sure, some people aren’t as interested in upgrading WordPress once it’s installed, and though this does bring about security concerns, I digress.

Additionally, continuing to support multiple versions may ultimately cost revenue because the amount of time it takes to support a product that’s no longer in development costs money.

So is this an option? I think yes – at least for the previous version for a comfortable, finite amount of time. What – two years? One year? I think it all depends and this is something that has to be managed on a case-by-case basis.

Planned Obsolescence in a Multiple Versions

To be honest, these two ideas seem to be the most in conflict with one another. After all, is it really planned obsolescence if multiple versions will persist? Personally, I don’t think so.

Regardless, in this scenario, I see the following factors:

  1. A new version of the theme is introduced along side all of the previous versions
  2. Each version is maintained but only for the version of WordPress for which it was built.
  3. No prior versions are retired, but no prior versions are for sale; otherwise, you’re left with telling people it’s okay to use old versions of WordPress and support costs will begin eating into profit.

The Latest Version is The Only Version

Truth be told, I really do like this idea.

I know: it’s aggressive, it forces people to potentially redesign or rework some of their site, and it requires some really clear and strict guidelines in the business model. Additionally, it means that newer versions should be incremental upgrades rather than huge overhauls of certain features (think about the way Chrome does their upgrades versus, say, iOS6 to iOS7).

The thing is, if you want your users to have the latest version of WordPress and you want them to adopt the best practices and/or the latest and greatest in code (assuming you’re doing your part), this is the – well, at least, a way to do it – it just takes some serious planning to make sure you’re planning it correctly and your users will enjoy the upgrade – not be disgruntled.

I’m sure those of us in the WordPress economy have seen both good and bad examples of this.

Planned Obsolescence with a Single Version

In this scenario, I see the following factors:

  1. A new version of the theme is introduced that deprecates previous features, but doesn’t do anything to harm the users blog functionality or design-wise.
  2. The version of the theme works with the current and the previous version of WordPress, but that’s all.
  3. There is only one version of the theme that’s available for purchase or for download. Think of Chrome – there’s only Chrome (be it Chrome 22, 23, …, 29) – and that’s all that’s available for download.

This would obviously take into account keeping in close contact with users so that they are aware of the work that’s going into the product, but that’s another blog post.

Planned Obsolescence: A Crazy Idea?

Obviously, don’t think it’s a crazy idea, but I don’t think it’s a simple one to implement either.

I tend to favor pushing things forward which is why I have no problem retiring plugins or discussing things like this. On top of that, I’ve seen other people retire themes when it was their time, and I’ve seen vendors release new versions that have completely trashed customer’s sites without providing backwards compatibility. I’m no fan of that, either.

That said, the idea is something that I’m particularly interested in – I just think it must be handled with care and there are a lot of factors that go into implementing it.

6 Replies to “Planned Obsolescence in WordPress”

  1. Interesting discussion starter!

    I guess in a way, this is the new approach to WordPress development, starting with 3.8, right? Build plugins with the features you’d like to get into core, and then at some point roll them in, thus rendering the plugin obsolete.

    Some won’t ever get rolled in, so the plugin may continue to live on, or it could be retired as an idea that didn’t pan out.

    It’ll definitely be interesting to see how this goes for 3.8 and if it is actually continued on for 3.9+.

    1. I guess in a way, this is the new approach to WordPress development, starting with 3.8, right? Build plugins with the features you’d like to get into core, and then at some point roll them in, thus rendering the plugin obsolete.

      That’s not what I had in mind, but it’s completely feasible, for sure. The only thing that I see this bringing is that what if there are a number of plugins that get rolled into core, thus making core bloated?

      I see an analogy being Microsoft Office. Up until, what, Microsoft Office 2003, I think, they just continued to pile features into the application that were requested by the enterprise.

      A decade passes and now people have word processors in which they use only a fraction of the features.

      I’d hate to see that happen to WordPress.

      I was thinking more in terms of WordPress-centric development shops maintaining their software, but it certainly works both ways :).

  2. I have no problem with planned obsolescence in certain respects, providing it is used for real upgrades which provide new advantages for the user rather than planned obsolescence used merely to gain profit – as we see so often in such industries as Smart Phone and so on, where a component is designed to fail after a set length of time. The bottom line shouldn’t be the most important thing, certainly not as far as WordPress is concerned, but customer satisfaction and real advances.

    1. The bottom line shouldn’t be the most important thing, certainly not as far as WordPress is concerned, but customer satisfaction and real advances.

      It should never be the bottom line, but more of a byproduct of the fact that certain things are going to age or are going to go out in favor of newer technology.

      So, with that said I’m with you on this:

      I have no problem with planned obsolescence in certain respects, providing it is used for real upgrades which provide new advantages for the user…

  3. Allow me to bring the IQ down a few notches.

    Not only do I think that this should be adopted by more software author’s in the WordPress marketplace, but I think it’s inevitable to build a sustainable business.

    Why is it that the World Wide Web and WordPress theme customers at large so against having to dish out a bit of coin to get some damn good software?

    My girlfriend subscribes to US Weekly for her fix of celeb gossip — on the back I just saw an ad for Madden 25.

    25!!

    Why can’t we release full version updates and drop support for themes? We do it in contract work with web browsers all of the time. As the web evolves and our themes and WordPress get even more powerful, why should we continue to support old coding standards?

    I don’t know, but I think it’s time we’re charging a bit more and not just give away the farm. Customers should begin to understand that paid upgrades are going to keep us around for years to come.

    /rant_off

    1. Not only do I think that this should be adopted by more software author’s in the WordPress marketplace, but I think it’s inevitable to build a sustainable business.

      This is what I was hitting on with regards to support. At some point, the curve at which you’re providing support becomes larger than the curve at which you’re churning out product / maintaining product and it becomes unsustainable.

      Why is it that the World Wide Web and WordPress theme customers at large so against having to dish out a bit of coin to get some damn good software?

      It’s the same thing that’s happened with the App Store. Gotta stay competitive, I suppose, so it forces people to drive down their prices.

      Again, though, though contributes to offering support that can only go so far.

      My girlfriend subscribes to US Weekly for her fix of celeb gossip — on the back I just saw an ad for Madden 25.

      Chrome is doing this – which is probably the cliched example at this point – but a couple of other vendors, as well.

      Personally, I’m a fan of this model, but it’s completely new to the WordPress world so it’ll take time for it to be adopted. At least, I would imagine :).

      I don’t know, but I think it’s time we’re charging a bit more and not just give away the farm. Customers should begin to understand that paid upgrades are going to keep us around for years to come.

      Paid upgrades or subscriptions for, say, a year. Either one sounds good to me.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.