Project Moiety - A Hypothetical WordPress Roadmap

Recently on the PostStatus Slack team, Brin Wilson started a discussion about what it would hypothetically take for WordPress to get to be installed on 51% of all websites (it currently sits at about 27% at the time of this writing):

It is an interesting thought experiment, and a lot of interesting points were made during the discussion. Matt Mullenweg weighed in on what he would think makes WordPress the “best possible product”:

Helen Hou-Sandí made an interesting observation about the two different “camps” that seemed to emerge:

Franck Frémont went ahead and wrote up a proposal for a long-term roadmap for WordPress, and challenged me to do the same from the technical perspective. So here’s my take on what I would think is necessary to get WordPress to account for 51% of the web.

Target Audience

Before making change suggestions to go on our roadmap, we need to define what audience we are mainly targeting. Given the methodology that is used to measure the market share (top 10 million websites according to Alexa rankings), I don’t think that targeting individual end users will amount to major changes in market share anymore.

I would rather think that big enterprise clients are the next major audience to target. Right now, WordPress is lacking a lot of important features for enterprise clients, and while they might use it here and there for a blog, it is not often used as a full-blown CMS in an enterprise setting.

The next target audience for major growth opportunity for #WordPress are enterprise clients.

That’s why I suspect the enterprise segment to provide the biggest growth potential and I will target my hypothetical roadmap accordingly.

Here it is then, my proposal for a long-term WordPress roadmap…

0 - Overview

1. Technical Requirements
2. Release Strategy
3. Compliance
4. Editorial Workflows
5. Integration Interfaces
6. Deployments
7. Command-line Control
8. Certification
9. Recommended Partners
10. Leadership

1 - Technical Requirements

For WordPress to be able to continually grow, it needs to have tools at its disposal to keep Software Entropy in check.

Please consider the following two laws from Lehman’s Laws of Software Evolution (paraphrased):

• The software must be continually adapted or it becomes progressively less useful.
• When the software is changed, its complexity increases.

This means that WordPress will need to deal with an ever-increasing level of complexity, and following from that, making changes to WordPress gets increasingly difficult and costly (at least in time and effort, if not financially).

#WordPress needs to have tools at its disposal to keep Software Entropy in check.

As WordPress is a procedural codebase with a lot of global state right now, most changes will need you to consider the entire code base (and thus, the entire complexity) at once. Therefore, my first priority would be to refactor the WordPress Core in a way that gets rid of that global state, and allows for complexity to be properly partitioned, so that you can deal with changes and their consequences in smaller subsets of the code without having any impact on the rest of the codebase.

This is necessary to be able to adapt to small and large requirements changes that the future might bring. What needs to be avoided at all cost is to encounter the next major web revolution without the means to meet its requirements in a timely and satisfactory way. Failing to do so might eventually lead to WordPress just becoming obsolete.

I have already written about what I think needs to be done to make WordPress ready for major changes in a previous post.

Apart from these basic technical requirements, I feel that two additional components should be provided by the WordPress Core:

• Logging subsystem, available to all components. Logging is such a vital feature that it ends up being implemented by nearly every substantial plugin and custom solution. Having a centralized solution provided by Core would avoid everyone reinventing the wheel and would allow for a company to route their entire logging efforts through external logging servers.
• Message Bus system, allowing to decouple processing tasks from the frontend page requests. There are cron jobs right now, but their usefulness is very limited, and they often cause all sorts of issues. Having a message bus system that can optionally be decoupled from the actual WordPress process (using something like RabbitMQ) would avoid having everything under the sun be directly coupled to the web server's page rendering process.

Both of these can easily be added through custom development right now, but having them be included within Core (at least as an interface and stub, with optional implementations installed separately) would mean they can be used across vendor boundaries. As an example, if there was a central bus system, a product like WooCommerce could create an event ProductAddedToCatalog, to trigger its own update mechanisms. This would allow third-party extensions to also listen for that Event and trigger their update mechanisms as well. Both would run independently from each other (so one can’t break the other) and wouldn’t be able to slow down the frontend page request (as they would run in a different process and could potentially even run on a different server).

2 - Release Strategy

WordPress lifecycle management policy should be rethought, so that there are occasional windows of opportunity where breaking changes are allowed and expected, so that there’s a structured way of shedding needless way and getting rid of legacy burden.

#WordPress lifecycle management needs occasional breaking changes and LTS releases.

The policy should include a long-term release schedule, with occasional long-term support releases (LTS) and recommended migration paths from one of these to the next.

Example: node.js release schedule (click to open node.js LTS schedule page)

The benefits of such a release strategy are the following:

• Backward compatibility (BC) needs only be kept up to the most recent LTS release.
• BC within the version spectrum between two LTS releases can be even more strict than it currently is.
• Legacy code and thus complexity can be regularly discarded.
• LTS releases let enterprises integrate the software into their own long-term planning.
• Maintenance / updates / migrations are foreseeable and plannable.

A proper release strategy is essential for enterprises, where less “agile” processes like 5-year-forecasts are rather the norm. They need to be able to orchestrate deployments across several different software projects in cycles that span years rather than months.

3 - Compliance

For enterprise clients, controlling compliance is not a “nice-to-have”, it is a basic requirement of doing business. If WordPress intends to be usable in any mission-critical context for larger organizations, it needs robust tools and solutions for implementing and/or supporting regulatory compliance. This could imply changes like subjecting the business content to enforced data retention policies, keeping auditing logs with the content workflows or even having connectors to integrate with over-arching compliance management solutions.

For enterprise #WordPress, controlling compliance is a basic requirement of doing business.

This is a very complex subject matter, and difficult to get right at an international level (being that most regulations differ from country to country). While having integrated solutions for all compliance-related areas is a lofty goal indeed, a good first step might be to go over something like the guidelines set forth in ISO 19600 and make sure that none of these recommendations are actively obstructed by WordPress at least.

4 - Editorial Workflows

Given that WordPress claims to be a full-blown Content Management System (CMS), it is quite alarming that managing content at scale (large team with large volumes of content) is not realistically possible without a combination of plugins and SaaS enhancements. The actual “Management” of the content does not extend much beyond a simple CRUD interface.

Right now, it is not realistically possible to manage content at scale with OOTB #WordPress UI.

Large content teams need workflows, customizable states, editorial calendars, communication and collaboration tools, notifications, reports, … In this regard, WordPress better fits the “development framework” drawer rather than the “content management system” drawer, as the management experience out of the box is far from polished.

I think this should be tackled from a UX perspective first, while completely disregarding the current technical underpinnings. When the ideal workflow has been identified, the implementation requirements for this workflow should inform the development roadmap, to make the perfect workflow “eventually” possible over a series of iterations. The important thing is that a specific goal has been decided that gives direction to all subsequent UI/UX changes. While there’s lots of work being done on the editorial experience, it often seems as a series of random, disjointed spot repairs, rather than a concerted effort.

5 - Integration Interfaces

Any larger organization already has lots of mission-critical systems in place that are not easily replaced. WordPress should provide the relevant integration interfaces where it makes sense, opening up the possibility to write connectors to the other systems in a reliable and fail-safe way.

#WordPress needs clear integration points to allow reliable connectors to external systems.

Although there is already the possibility to add functionality through plugins, this often results in solutions that are arbitrarily tacked onto existing functionality, and that break when using several of these in combination.

For each of the main integration points, there should be a clearly defined interface that makes it possible to add any number of these integrations in a reliable way.

Here are some examples of such integration points:

• User authentication, to provide integrated Single Sign-on, letting IT manage users from outside of WP and letting users log in via their fingerprint or other enterprise mechanisms.
• File management within Media Library, so that IT can attach several externally managed media libraries and document management systems (with correct support for authorization, searching, etc...)

6 - Deployments

Right now, proper deployments of a WordPress site are only possible with huge amounts of additional efforts. Two main issues need to be solved to allow for more streamlined deployments:

• Environment-specific data mustn't be stored within the content database. The content database should be completely agnostic of the current environment it is being used in.
• The content within the content database must be properly versioned. Currently, given two similar copies of a WordPress content database, it is next to impossible to find out what exact changes have been done in what order.

These issues are the more common nuisances that deployment systems for WordPress have to deal with. Addressing them to allow for straight-forward and reliable deployments would also encourage the use of standardized deployment tools, instead of all the custom WordPress-specific solutions you need to use right now.

#WordPress needs standardized deployment tools instead of a random collection of custom solutions.

7 - Command-line Control

An enterprise site needs to be scriptable. The IT department does not want to click through the admin screens on a daily basis to address upcoming action items. They want to write scripts that let them control the entire infrastructure as a coherent whole (or at least give it an honest try).

The IT department wants scripts that let them control the entire infrastructure as a coherent whole.

There’s already a great project called WP-CLI that allows you to control your WordPress installation through the command-line. However, it has a few inherent short-comings due to the fact that it is an external addition, not part of the WordPress Core.

Ideally, WordPress would move towards adopting a hexagonal architecture, with both user interface and command-line actions having practically the same execution paths. This opens up the opportunity for more advanced command-line antics and consolidates code between both WordPress and WP-CLI. Having the actual logical processes be decoupled from the user interface representation also makes it much easier to change said user interface in the future.

8 - Certification

Enterprise HR relies on certifications to be able to hire for minimum skill levels. We all know that this is far from ideal, but it is the only way that HR departments without technical expertise can make sure they don’t hire a complete lemon.

Enterprise HR relies on certifications to be able to hire for minimum skill levels.

There needs to be a network of certification bodies that can ensure that certified developers / implementors / coaches / … do indeed offer the minimum set of skills that their position would demand. As a bonus, these institutions could also offer “standardized” training as well.

As nice as it is to “hire for attitude” or similar approaches, your company will be in real trouble if your developers cannot write basic PHP code without copy-pasting from Google results.

While this will definitely have an impact on the current low barrier of entry of WordPress, I would assume that the enterprise much prefers having gatekeepers to avoid the most obvious abuse of trust.

9 - Recommended Partners

While the 5-minute install is nice for private end-users, most larger enterprise projects start by getting implementation/integration experts on location to support the in-house IT staff with collecting requirements first. So, they want to see a list of recommended partners from their area to know where to start and whom to contact.

Enterprise IT needs recommended partners to collaborate on large-scale projects.

It is very difficult to do this without introducing bias and unfair advantages that hurt the core philosophies of the WordPress project. This should be governed by an independent non-profit.

10 - Leadership

I’ve kept the most important one as the final entry. It is the one element that has a direct impact on the success of all the previous points.

For a group to make a concerted move into a specific direction, there needs to be leadership. Without leadership, movement will be distributed amongst all sorts of different directions and the result will just average out to lose its impact.

For a group to make a concerted move into a specific direction, there needs to be Leadership.

If an enterprise client wants to base its 10-year strategy on a specific offering, they need to see that the team behind that offering has a strong vision and a clear direction.

The Open Source WordPress Community should try to distil true leaders from its huge group of contributors, and encourage them to proactively shape and chase a bigger vision. While we already have several forms of “middle management” at different levels, it seems to me that the overall progress is decided by a random set of actions, rather than a concerted effort.

Okay, Where's The Source?

Unfortunately, I don’t have finished source code to share this time… 😜

All of the above is mostly meant as food for thought. The way the Open Source project has grown and is currently set up certainly makes it difficult (and maybe uncalled for) to have true leadership and an overarching vision. But that is probably “the next frontier” to explore.

Please put all feedback and expressions of dismay in the comments below!