I’m planning a bunch of posts about WordPress plugins.

But first I thought it may be worth a quick ramble about how plugins came about, what they are, why they are (in general) A Good Thing … and a few words of caution.

Why a Plugin Strategy makes sense …

Keeping it Simple …

WordPress, like a lot of other open-source software sites, is written by a core of volunteers. These estimable individuals, for the most part, want to do interesting things like hacking cool new code.
Less interesting – and less attractive – are things like documentation and testing – particularly regression testing (making sure new stuff doesn’t break the old stuff).
This doesn’t mean these things don’t get done, it’s just that not so many people want to do it on their own time…

Bearing this in mind, there’s a lesson from experience, which suggests that over time, applications tend to grow in functionality and complexity. In turn this means more lines of code.
More lines of code mean more maintenance. It means more things to go wrong – and more things to be tested for each new release.
And as the proportion of effort on testing increases, frustrated developers tend to leave the project, potentially sending it into a “death spiral”.
As a result, applications which don’t control this “bloat” are less interesting to work on, and can tend to atrophy over time.
So, in developments such as WordPress, it’s really important to limit the scope of core functionality, rather than building in all sorts of options that a small proportion of the users might want.

To contrast open-source with commercial software : with the latter, the marketing dept. has typically wanted to cram as much functionality into the package as possible – both to have more boxes to tick against the competition, and to encourage existing users to upgrade.

But I really need …

But what your users really, really want the extra feature that’ll let their users “Like” them ? Or track their cat’s location in the sidebar ?
Even going back only 10 years, you’d address this by taking the source code and changing it so that it does what you want (I’ve modded software myself in the past). Or else you’d pay someone to do it.
But this has downsides…

… The main one of which is that those changes have to be reapplied every time the software gets upgraded. And they may be incompatible with some of those changes.
This leads to users becoming upgrade-averse. They want to be creating content and getting on with their lives, rather than reapplying (and testing, and installing) those changes with every update. Or paying someone to do it.

Release Cycle

And this reluctance has a knock-on effect – there are more versions of the software “in the wild” … which brings with it a need for more support.
This works against the agile way that open-source projects work at their best – Linus Torvald’s “Release Early, Release Often” model woesn’t work if developers are constantly fixing old software versions.
So ideally, only one “production” version of the software should be supported.
This is reflected with the automated update functionality – users should now have no reason to stay with an out-of-date version.

Again, to contrast with commercial products, these will often have a release date – with advertising and production schedules – booked months in advance, and this may drive the reliability and functionality available as a release goes “gold”.

Introducing the Plugin …

So what WordPress has done – and they aren’t alone in this – is to define and introduce a method to let developers “hook” into the application without breaking the code.

At various places in the application, the program checks to see if any registered plugins are supposed to do anything. If so, then that code gets executed, before control is returned to the main process. (If you’re interested, then Adam Brown is curating a database of these WordPress “hooks”.)

This is ideal because

• the core developers don’t need to worry about supporting extra functionality
• Users can write their own modifications, and be confident that they should (!) apply automatically to future releases
• As a result, they can have the confidence to update more frequently – taking advantage of security and functionality updates
• Different plugin developers can address the same problem in different ways – which lets the blogger choose the option that’s best for them

Of course, there are the same problems as with all open source software – plugins also need support and – occasionally – development. But as their source also tends to be open, then someone else can always run with the ball if the original developer gives up (that’s actually happened with one of the plugins I use).

There’s another advantage. As a user, you’re not wedded to any plugin. If someone develops a better one, then you can switch easily and without too much pain.

The Downsides …

Of course, you don’t get owt for nowt, and you can get a bit of a plugin pileup. There’s not necessarily a problem with the essential nature of plugins, but these are less likely to have been subject to critical scrutiny than the core codebase.

But the problems you hit will depend on the nature of the plugin.
From my perspective, the main effect to be concerned about is whether it significantly impacts your page load times.

These are the factors I’ll be taking into consideration when I compare plugins. There often won’t be an outright “winner”. As a general rule, plugins are developed and published by people with good intentions, and I don’t intend to disrespect any of them.
… And another general rule : they’ll tend to work as the developer intended. Of course, this isn’t necessarily the way you’d like them to work.

Any way … I hope to be fair, but my selections will, at the end of the day, reflect my values, and what I want for my blog.

External Services

Some plugins access external services. This isn’t a problem if it’s during post creation, but if it’s something that happens as the reader navigates, then you’re completely dependent on the performance of that service. If your plugin calls the Twitter API (an “API” is an standard request to retrieve data) to retrieve a tweet count, for example, or connects to wordpress.com to update your statistics, then if can slow your load times.

You’re also dependent on the developer keeping the plugin up-to-date with any changes to that API.

Contention

There’s a cumulative effect to this class of plugin as well – the greater the number of calls your page makes to external domains, then the greater the probability that performance will suffer – so you may be forced to choose between that Twitter button and your analytics stats.

Popularity

Not a good or bad thing in itself, but – functionality aside – it’s a fair bet that a plugin with 50,000 users is more likely to get continuing support that the one with 50 users …

And it’s in the nature of open source software that a “killer” solution may mean that alternatives tend to wither on the vine, as developer effort concentrates on areas that do still need a solution …
(If you’d like to read more about why this happens, then I recommend Eric S. Raymond’s excellent essays around “The Cathedral and the Bazaar“)

Complexity

Many plugins try to make things very easy for the user. But this can involve a lot of complicated code.
A more simple solution may need a bit more work to install, but once configured, will do all that’s needed.

As I noted earlier, there’s a general principle that complicated code tends to be less stable and needs more support.

There’s a similar problem with plugins that need to be updated to keep in step with external lists – you’re dependent on the list being maintained, while hoping that the developer doesn’t get bored of the whole thing.

So I’ll tend to lean towards the simpler solutions.

In Conclusion …

The plugin structure makes your blog easier to upgrade, and the right plugins can make it far more functional and relevant. But installing plugins for their own sake can make it look cluttered and – even worse – kill performance and your search rankings.

If you’ve got any more insights on plugins (or this post), please let me know in the comments section below.