On WordPress and Release Cycles

The annual State of the Word session by Matt covers the latest updates on the platform – usage, coming updates and new features from the past year and other valuable stats so that WordPress experts could see their place on the map and see if there are any business decisions to be taken for the next few months (or a year).

The platform/application direction makes sense for the next level of growth for the WordPress platform. Matt had a great slide for the structure and architecture of WordPress as a framework for building various components and extend in the future:

[tweet https://twitter.com/no_fear_inc/status/361193778654097410]

The Release Cycle Problem

The guys at WPwatercooler mentioned the release cycles issue in their session today. The short story is: plans are for WordPress to be automatically updated just as Chrome and Firefox are for the past 1-2 years so that backwards compatibility could be avoided and latest security updates would be applied automatically to all users around the world.

I like the idea, but there are two essential problems with it: the intensive plan for quick major updates for WordPress and the maintainability of themes and plugins for WordPress for every single major version. More often than not themes and plugins work just fine, but larger plugins normally reuse functionality from various Core aspects, fully relying on it, and maintenance is quite problematic. Professional themes should also work on latest WordPress and provide a proper presentation of all features out there. This however takes months of work, updates for new versions might be applied and tested for weeks and having 2-3 month release cycles could actually annoy a number of users and ruin various businesses.

Theme and Plugin Authors

I have several friends from the WordPress community building themes or plugins for sale. At some point of time the amount of support they have to provide requires up to 3 or even 4 days of full-time support. Their marketing channel relies on timing and the older the product, the less the sales on a weekly/monthly basis. That leads to a combination where profit per product decreases over time, time required for support is increasing drastically and authors should either hire support staff which the profit often can’t cover or freeze the new work process in favor of almost full-time support with a decreasing user base.

I broke this blog just a week ago with a plugin autoupdater, latest plugin changes led to some issues and I had to disable the plugin.

Even if that could be handled at the moment by building a reliable and stable product and preparing docs and videos for the latest WordPress version, speeding up with rapid release cycles leads to more testing, patches, updates and outdated docs/videos for every version. Take a look at WP101 – new videos are usually recorded for every new release due to UI and functional updates in every new major version.

WordPress as an Application Platform

The platform definition of WordPress came from Matt himself. I have seen that application in practice and I completely agree with the use of WordPress for larger solutions – it’s mature enough, it scales well, it’s adopted to an extend where large applications could be built and could live for quite some time on the top of WordPress. The intensive release cycles for WordPress would lead to chaos and lack of availability from large businesses to adopt new versions.

Over the past 2 years I have worked with several large businesses running platforms on WordPress and adoption of latest WordPress even with about 2 versions a year is still not straight forward. It requires a bizarre amount of time to replicate everything to a staging environment (for large applications), update, test all the plugins and themes (usually talking about large Multisite projects), fix tons of small issues and bottlenecks here and there, and then plan for migrating all changes to production in a suitable time without causing loss of data and a massive downtime. Chris Lema also mentioned in today’s WPwatercooler other side effects such as training customers for every new single update and keeping the staff in hands-on mode too often to be able to handle surprises.

Enterprise Systems

Few years ago I was working as a Java Developer. I had been teaching Java courses in a private technical academy. We also had course programs for large businesses (running .NET or Java stacks).

Back then Java 5.0 was already out (Java 5.0 release date was late 2004, my corporate training courses were 2006-2009). Even 6.0 was out there and we had to migrate our training curriculum to the new version, adapting the latest changes to the JSE and JEE stacks.

Most businesses were actually running Java 1.3.2 or even older version. Java 1.3 was released in 2000 and that was still one of the most popular versions in enterprise businesses in 2008. People had been having hard time adopting and updating major releases – being too busy running a real business. We are talking about telecoms and financial institutions, large chain stores, hospitals, governments. The technical community behind the Java development was fully aware of their business niche. The actual non-cosmetic language changes were applied every 5 years, or more.

.NET have been a bit more aggressive, releases being introduced more often and language changes applied accordingly. It is still worth saying that larger corps were also running older versions and new features were primarily adopted by new startups or products. Another important aspect is that .NET is not open, it’s owned by Microsoft and does not rely or depend on other large communities or authorities.

Have you noticed how many governments and large corporations still use Windows XP with IE6 or IE7?

Last month I got invited for a consulting job in Amsterdam – migrating a COBOL app to WordPress. The COBOL language was created in 1959 and apparently there are still applications using it.

And again – WordPress and Browsers

I don’t advocate against updating at all. The Chrome and Firefox projects are pretty neat by updating themselves all alone without confirmation and so. However, my business does not rely on Chrome, neither on Firefox. If my Chrome crashes, I would switch to Firefox. If my Firefox crashes, I will open my Opera. I use web browsers for browsing, for testing web applications, for reading my email and my social networks, for blogging. I get a bit annoyed if my browser crashes, but I can always check what I need in seconds with another browser or through my phone.

Is it really the same compared to WordPress Platforms as a Service?

2 thoughts on “On WordPress and Release Cycles”

  1. Stephen Cronin says: July 30, 2013 at 6:19 am

    Totally agree with what you’re saying here. I included much of this in my WordPress and Government talk / article from a couple of years ago, which looked at why WordPress wasn’t used in Government as much as we’d like. For example:

    Remember, when an update is released, they can’t just upgrade. They’re going to need anywhere from several weeks to several months to digest the changes, analyse the security implications, plan the update, get it approved by CAB, do extensive testing on the impact on functionality (including on plugins), come up with a plan for training if anything’s changed, etc.

    If you have to do that every couple of years, fine. A couple of times per year is another matter. It’s not just a case of a one click upgrade.

    They also won’t like the automatic updates that are coming!

    Now that’s from the IT department’s perspective and they’re slowly shift away from being so risk averse. Also the marketing department sometimes just goes around IT for smaller sites. But it’s still an issue for many larger government websites (at least here in Queensland)..

  2. Mario Peshev says: July 30, 2013 at 6:31 am

    Hey Stephen,

    Thanks for your comment! I fully agree and I’ve explained above.

    Since it doesn’t make sense to slow down the development either, I see it as either decoupling the core as much as possible (so that new plugins could be added and core is really small and independent) or creating two or three versions of WordPress, when one of them is only used for large enterprise projects (similarly to Fedora, Cent OS and Red Hat EL with their entire life cycle).

Leave a Reply

Your email address will not be published. Required fields are marked *