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.