The WordPress 3.0 Milestone

Although it’s only slated for release sometime in May, the first beta of the new WordPress 3.0 is already doing the rounds. Blog Oh Blog has a nice summary of the changes and additions in the new version: most of the updates are fairly innocuous, perhaps the largest mention should go to the integration of WordPress-mu, for setting up multi-user blogs and networks.

However, the announcement that really put the cat amongst the pigeons has been that the core development team may now be promoting what were formally called canonical plugins, now known as core plugins following the unpublished results of a poll in December. It appears that whilst attempting to address a genuine issue, the very idea of having plugins that stand in the limelight with an official stamp of approval has incensed many community plugin developers.

Some really excellent debate has been held which has, amongst other things, revealed that the initial go ahead for core plugins will be very limited; just three plugins, including an old, out-of-date plugin, a chunk hived off from the core, and a newly developed plugin. Nevertheless, the potential for these core plugins to have wide-reaching effects on the plugin development pool, create stagnation in the community and a greater top-down hierarchy is something that in the eyes of many developers and enthusiasts, has not been addressed.

The Pros

Most of the people arguing in favour of core plugins have the same ultimate motivation as the core developers. They don’t acknowledge the potential negative side-effects of the move, and if they do, they don’t consider them to be negative.

• Reliability. Perhaps the biggest driving issue for this move is that of plugin reliability. Most WordPress users will have come across the problem of using a plugin to such an extent that a site essentially relies on its features, or may even have been built around it, only to find that the plugin developer has got bored of his project, and the next version of WordPress breaks it entirely. Finding a suitable, working replacement may take a lot of time and effort, but will not guarantee that the situation won’t repeat itself.
• Security. Stemming largely from the above phenomenon, users making use of plugins that are no longer maintained by their developers find themselves loath to update their WordPress installations for fear of having their sites fall apart should those plugins no longer be compatible. They voluntarily take the risk of running an out-dated version with potential, known security flaws, unnecessarily making themselves a potentially viable target. Of course, even if that plugin works in the latest version of WordPress, it doesn’t preclude that the unmaintained plugin itself isn’t wide open to abuse, just another potential security hole in an otherwise fairly sound system.
• Support. There are literally thousands of plugins out there, the vast majority written by individuals who developed their plugins for their own special needs, and out of a bit of thought for the community, decided to share their creations with other users. They probably aren’t looking for any form of reimbursement, neither gold nor glory, other than a bit of gratitude. And whilst there may be some of that, they are far more likely to drown in a hail of support issues, bug fixing and feature requests, something they are neither capable or inclined to cope with. Some people post on the WordPress Extend site itself, many ask questions on the release post on the author’s blog, other plugin authors run their own forums, but even these may require that users sign up just to find how little information there is or how infrequently the author actually answers posts. Where exactly can users go then for help?
• Quality. The WordPress Extend repository proudly states that there are over 9,000 plugins with a cumulative 80 million downloads: and the vast majority of those are utter cruft. I don’t think anyone should have any illusions about that. A plugin is obviously more than just what it purports to do on the box, and a good plugin in particular is one that ticks more than just the boxes for functionality. It needs to have accurate and up-to-date documentation, how to install, use and (ideally) uninstall the plugin. There should be an accurate and preferably human-readable changelog detailing the key alterations, bug fixes and feature additions between each version. That’s a lot of work for one man, and I very rarely find a plugin that gets it all right: I’ve seen plugins which link to other pages for an up-to-date changelog that doesn’t include the last two versions, or others which link to a trac page without even the slightest attempt to translate that list in something regular users would likely understand. One popular plugin has documentation that is sadly so incomplete, that users point to posts on other blogs for fuller idea of how to use it.

The Cons

• Labels. Core, Canonical, Official, Godly, call it what you will, all those plugins which make it into the selected few and get the rubber stamp will destroy the efforts of many other plugin developers who weren’t so lucky. Regular users will of course browse through the official lists before turning to true third-party solutions to their problems. In what developers like to call the plugin free market, it really is a case of all plugins are equal, but some are more equal than others.
• Hierarchy. One of the other big concerns from developers is that the move presents an encroachment in an otherwise egalitarian ecosystem. Plugin developers invariably create their plugins to fulfill a particular need, their own or someone else’s. They are the ones with the final say when it comes to fixing bugs, adding features and writing the code. With an official plugin, however, who’s the one who gets the final say when it comes to adding new features? Who’s to decide which code gets included, which issues get priority, and so on?
• Monopoly. A developer sets up a WordPress site and finds he needs something that isn’t covered in the core software, and for whatever reason hasn’t been implemented or implemented well by another plugin, so writes his own and publishes it for others to use. Of course, in all likelihood there are other plugins already available, which may approach the issue from different angles, or with different feature sets. These plugins, however, essentially overlap in terms of their usage, and the ensuing competition should result in more well-rounded plugins that are up-to-date, flexible, reliable and secure. Only the fittest survive. At least, in theory. With these official plugins, all of this competition goes out of the window, technically more proficient plugins with better features and tight code, will be overlooked by users in favour of the canonicals.

A personal take

In case it wasn’t already clear, I would have to say that despite the objections, everytime I’ve gone through the arguments in my head I’ve come out in favour of the core plugins idea. One of WordPress’ greatest strengths has definitely been its flexibility and easy extensibility. As one critic of this decision wrote, the bar for entry is low, it doesn’t take a coding genious to install WordPress, decide he needs something extra, and write a plugin to cover it. Recent updates have also made the WordPress repository so much more accessible; users can now search for and install plugins right from the WordPress installation.

Yet the quality and reliability of those plugins remains a major issue. I’m not even referring to those coding one-offs with barely a hundred downloads that presumably make up the vast majority of the plugin repository. ((Some actual statistics on plugin downloads and updates etc. from the repository would actually make interesting reading.)) Many of the more well-known solutions out there still fall at one or another hurdle as already mentioned, whether it concern support, timely updates or documentation. To say nothing of the millions of potential issues of interoperability.

One of the more interesting complaints that a number of developers had was that of having a top-down hierarchy dictating what goes into which plugin, something that I found entirely fallacious. As it stands, the vast majority of plugins I’ve come across are developed by a single person, with occasional patches sent in by more able users. They are the ones who decide what happens, what gets fixed, what gets included, when things are released. And if they decide to give up on the project, for us mere mortal users we can only hope that someone equally competent will pick up the reigns and provide support and future updates. Sadly, that isn’t necessarily going to be the case. The idea of the core plugins brings at least some stability to proceedings, a guarantee that updating WordPress won’t bring everything to a crashing halt, and the knowledge that the entire project doesn’t revolve around the mind of a single man. It’s the very principle that has ensured WordPress itself has grown from strength to strength, why should it bring nightmares to the plugin world?

The great alternative that many people seem to be lauding is that of making improvements to the tools available to plugin developers. As already mentioned, recent WordPress updates brought the regular users and the plugin repository much closer together, by making the latter navigable from within the regular WordPress installation. This change, as well as other updates on the repository itself, have ensured that users can see when a new version of their favourite plugin is available, as well as read a changelog (assuming there’s one available), and check to see if the current version will work on the latest version of WordPress.

But these changes need to continue to support good plugin development work, and help users separate out the chaff. One of the most popular plugins on the repository, with well over a million downloads, has has only 800 ratings from users: the compatibility of the latest version with the latest version of WordPress at the time of writing has been reported on by less than 10 users, and there’s no elucidation as to what’s going wrong for the few who’ve reported it to be broken. With that in mind, how are regular users expected to know which plugin to install, when they search for an open or popular term and are presented with a dozen or more plugins? And since these are all likely one-man projects, what will they do when the time invariably comes and the developer gives up on updating the plugin and moves on to new horizons? Actually mentioned facetiously, since one of the contentious issues of the core plugins is that they will be presented on their own page on the WordPress backend, but the idea of having an editor’s choice list of plugins that fulfill a selection of standards for inclusion actually wouldn’t go amiss as an alternative to the current turmoil.

All in all I can only say I welcome the move, and look forward to its repercussions. Attempting to ensure high standards, compatibility, support and open source development are all laudable goals, that neither preclude the disappearance of competition and variety, nor the ability to provide plugins that are commercially supported (just that the open source alternatives might be all the better!). And here’s to a core plugin for creating multilingual blogs, I’ve had enough trouble switching over from one system, to another, to another!

For anyone really interested in the debate, the posts on Weblog Tools Collection and One Fine Jay in particular are definitely the places to look.