Before we get to flying cars and space tourism, I would really like to see the WordPress ecosphere consider separating release candidates into Feature Updates and Security Updates whenever possible. WordPress, and its component ecosphere, releases updates combining new features with better security on a frequent basis. With this can come the dreaded white screen of death, general crashiness, and the urge to do something else for a living. The problem is well known among WordPress professionals, and those still married to them I am sure. In fact, though I know this is not a relationship advice website let me give my fellow WordPress professionals some relationship advice: don’t discuss this article at dinner. It’s a real mood-killer, no matter how delighted you may be about it.

Unlike poor dinner conversation, its possible to mitigate the impact of the update cycle. Changes would be needed, of course, to how updates are released, but it needs to be considered by the Open Source Community given where things are going with WordPress and its rapidly evolving relevance to complex use cases. By releasing feature updates apart from security updates, selective control is handed back to the vendors creating client websites, or to clients managing their own websites.

As of today, the problems with the update cycle are less severe than in years past. There is better guidance available for the correct way to implement a WordPress website and more understanding that security has to be built into even the simplest project. The quality of plugins has improved dramatically since I started building with WordPress back in 2009, and this has led to WordPress becoming relevant to an increasingly complex set of use cases. So, it is not a surprise that WordPress is so popular. Where it goes next heavily depends on how easy it is to tame, feed, and care for. Right now I’d settle for it biting the hand that built it just a little less, and that’s what I’m hoping a consideration for separating release candidates by features or security might accomplish.

In case you have never had a single problem in your life updating a WordPress website, here is the joy that awaits the rest of us mere mortals on a regular basis. New features, or feature modifications, in an update can cause conflicts in a plug-in stack no matter how well vetted everything was before the update. Some feature modifications can violate custom security configurations, rendering meaningless the intended improvement to security provided by the update. Then there’s the fact that most WordPress component authors are not technical writers. I mean, why would they be? That’s not what they do. The result is often a fantastic theme or plugin with very little technical guidance for troubleshooters to reference when something goes wrong.

The Potential Benefits

For those that just want the security updates, this would likely mean less updates throughout the year. When I say “security updates” in this context I mean the normal fixes and patches, plus anything required for a WordPress plugin or theme to remain compatible with the latest version of WordPress. I’m not suggesting that WordPress itself should modify it’s release cycle. They are already doing something very close to what I’m describing here, or at least that’s how it appears to me.

If the security update does not require a significant change to a feature (sometimes that’s unavoidable of course) then such updates will be far easier for a WordPress website to survive. Impressed WordPress professionals will be more likely to purchase other components from such vendors.

To summarize: Less updates required overall, and for some these will also be less destabilizing. This can be a good way for plugin authors to build loyalty and win enough to trust to get sales of other components.

If you ignored my advice and got so excited about all of this that you’re giving this talk to your love interest over dinner, right about now you are freeing up all kinds of future time to work on websites as much as you want. But we’re almost to desert so let’s just finish off the evening, and the romance, with a thud and get a bit more analytical.

Why not separate feature releases from security releases?

Market pressures and the cost of maintaining the code bases are considerations here. These pressures can be made worse from a misunderstanding of the ideal client and what they value more: features or security?

The thinking, as it relates to component licensing, can go like this, “If the features and performance are not improving, why would anyone opt-in for another year?” I am very glad my marriage license did not come with this assumption. The good news is that most clients are more sophisticated than that, and if not, it does not take much to educate them. Any business that values its reputation is going to be worried about the security of its web properties.

It’s easy to demonstrate that stability and security are inseparable concepts. You simply cannot make any endorsement of security for a system that is prone to unexpected behavior. I focus my clients on that view of security from day one.

I am very careful to enumerate licensing costs when premium plugins are used, and emphasize that the only reason these licenses need to be kept current is so that compatibility and security updates can come through. If I told my clients that licensing fees were valuable so that we could get the next coolest feature set, they would be very unlikely to care. We have what we need at go live. Modifications are now problematic, not a benefit.

Still, confusing “existing clients” with “new clients” might cause some vendors to believe everyone values beautiful features over boring security. But these are two different phases of the customer life cycle, not two different customers. New clients are looking for features, and expect security.  Existing clients have what they need, and don’t like paying web experts for help every time an update breaks their website. If updates are frequent, this issue becomes a significant irritant.

The WordPress community is understandably hostile to stagnant plugins and themes because such components can  become the source of security problems or incompatibilities with the core platform as WordPress continues to evolve. However, insisting “people must update” should in turn drive us toward approaches that make people want to update.

Right now we repeat the update mantra knowing such updates are often not relevant to security or WordPress compatibility, can cause headaches for even the most seasoned WordPress developer, and that it is the website owner whom ultimately pays for this.

At some point over the past few years we left the Information Age and entered the Age of Reputation. Code bases, like people, have personalities; some friendly, some not. They also have a reputation. You can see this in the Support threads on WordPress.org.

I am not a programmer, but my programming friends tell me some code has a certain “smell” to it. I know it isn’t good when the code has a “funny smell to it.” It usually means it is not refactored or annotated, and that some twisted half-hacked path is being taken for the execution of code. The closest real world analogy is that it reflects the same experience I had when my late mother-in-law (who was very forgetful due to her blood pressure medication)  baked me some cookies a few years back. It was a last act of love with one caveat: you cannot actually be sure what went into the oven, so there’s no way to tell what has come out until you put the result in your mouth and bite down. At some point a person realizes nothing can possibly taste good enough to warrant the risk. Cookies get left uneaten, WordPress websites get left un-updated. There is indeed a symmetry to the universe.

A formally recognized security rating, with a human readable definition that is consumer oriented, would help define a component’s reputation in the community. Of course the rating would have to be meaningful and predicated on an objective evaluation of the component’s behavior. “This thing sucks eggs!” is not quite what we’re looking for.

Conclusions

As WordPress has grown in sophistication, the Open Source community has done a remarkable job working independently to create the powerful interlocking components called themes and plugins. But the complexity introduced by the platform’s growing capabilities requires reviewing current practices for releasing updates to WordPress and its components. Wider adoption of the platform is theoretically possible with improvements to this aspect, which is perceived by website owners as a hidden soft cost or even a danger to the stability of their website.

By maintaining release candidates for feature updates separate from security updates, whenever possible, the frequency of updates could decrease significantly for clients that do not need new feature sets pushed into their website’s code base. The reduction in cost of ownership would mitigate the cost of the licenses for the clients, potentially increasing customer loyalty and cross-sales of other components to happy WordPress professionals.

Maintaining two code bases, however, is not a trivial endeavor. The cost to do this is not only money, but in the Open Source community it is also time. Many coders do what they do out of love for the work. They are code poets accepting donations for their work instead of charging a fee. Then too, many cannot afford the technology or time required to maintain two code bases, making such a requirement something that could put aspiring component authors who actually do very solid work at a disadvantage.

Letting the market decide is usually the right answer. Perhaps a trial run of this concept, with a subsequent post-mortem to see what preconceptions were killed by reality, is possible. Whatever we do, let’s not bore our loved ones with it over dinner.