WordPress turns 10 years old this month, around the same time version 3.6 is set to release. Such a milestone deserves worldwide celebration as WordPress is now the most popular publishing application on the web. From an open source blogging platform, WordPress has grown into a mature Content Management System (CMS) with as many different uses as there are users. For many, WordPress has become the gateway to web publishing, and as a result has changed the face of the web. To call it impressive is a gross understatement.
But with great power comes great responsibility. This 10 year anniversary should also be a time for review, revision, and vision for the future. Should WordPress remain a one-size-fits-all CMS grown out of a blogging platform? Or is it time to rethink the structure of the application and modularize it to meet the demands of different user groups? I say it’s time for a fork.
Issues – The Why
With this growth, and the break-neck speed at which WordPress is currently evolving, there are bound to be hiccups along the way. Technical problems appear and are dealt with on an ongoing basis, but the problem I fear the most, the one we are quickly converging on, is a philosophical one:
In its quest for broad appeal, WordPress is becoming overgeneralized. I fear this may erode its foothold on the web and in the end break the application as a whole.
The problem is rooted in WordPress’ popularity. When the project began, WordPress had a neatly defined target user: The Blogger. But 10 years and 80 released versions later, the end user is no longer a homogenous group but a fragmented spectrum of users with widely different requirements and usage scenarios. WordPress is currently built to serve all these fragments, trying to do everything for everyone and as more complexity is added, it is slowly becoming a Jack of all trades but master of none. To misquote one of my favourite movies, “Overgeneralize and you breed in weakness.”
The Many Faces of WordPress
Looking at how people use WordPress today, one thing becomes clear: WordPress is different things to different people. You have bloggers who see it as a blogging tool, developers who use it as a CMS, themers who use it as a target application, large scale developers who use it as a core application for networks of sites, web hosts who use it as a hosted SAAS application, schools who use it as a social networking tool, enterprise clients who use it as a web publishing application, the list goes on.
Each of these scenarios have vastly different requirements, demands, applications, users, and target audiences. And yet they are all using the same application.
This is to the credit of the developers of WordPress. To build an application that can serve such a variety of usage scenarios is an impressive achievement. But when we look at how this came about, it is clear the current situation is sub-optimal.
As much as I hate to say it, WordPress is not really a CMS but rather an extremely built-out blogging platform. And because a large number of its users are bloggers, front end features are constantly added to help them. At the same time, new CMS features are added on the back end, allowing advanced developers to plug in and hook up. The end result is an application that grows in complexity with every iteration providing each individual user with an ever longer list of features she does not use nor need.
The tools and functions needed by a blogger are not the same as the tools and functions needed by a CMS developer. Or a network developer. Or an enterprise developer. But since the present goal of WordPress is to meet the demands of all parties, the application ships with everything for everyone, to the detriment of all.
Ant vs. Tank
Sit down with a novice WordPress user and you’ll see what I mean: What was once considered a simple and straight forward blogging tool has become a stunningly complex application with some blogging features. The novice user is often overwhelmed and this is usually followed by either frustration or overconfidence, both of which in turn lead to dangerous behaviour. The number of bloated, unsecure, spam infested, server killing WordPress sites on the web today is staggering, and it’s all because while we say “it’s so simple anyone can do it,” the reality is it’s so complex you need to be an expert to do it right.
I used to joke that using Drupal was a bit like killing an ant with a tank. Well, WordPress is starting to take on some pretty tank-ish qualities of its own.
Prongs – The How
So what do we do to solve this? How do we stake a path forward that meets the demands of a fractured user base while still retaining an agile core that continues to evolve with (or evolve *the*) web?
Here is my suggestion: I see WordPress stripped down to a core application with a series of prongs, each targeted towards a distinct user group or scenario. This can be done either through distinct forks or through plugins much like BuddyPress and e-commerce are being handled right now. The structure could look something like this:
WordPress Core (root)
WordPress Core is the root branch on which all other entities are built. The Core consists of the most stripped down version of WordPress possible with core functionalities only.
Focus: Functions, security, and stability.
Target audience: Developers who don’t want any cruft but want to use WordPress as the base for applications.
WordPress for Bloggers (terminated branch)
Inspired by the front end of WordPress.com today WordPress for Bloggers is a simplified version of WordPress focussing on blogging features while disabling or hiding more advanced CMS features. UI is akin to WordPress.com rather than the current WordPress dashboard. New features like in-post editing and modal settings displays make it unneccessary for the average blogger to ever visit the admin interface.
Focus: Writing and publishing blog posts. Post Formats are front and center while features like custom permalink and front page setup are handled at setup with editing under a simplified Settings panel. Themes are handled through the Theme Preview and Customizer function. Advanced features like SEO integration and social buttons are built in. Security updates are automatic and a security checker is built in to alert site owners of possible security issues.
Target audience: Bloggers who want a low-touch plug-and-play solution with plenty of hand holding. There is little to no room for a novice to be dangerous in this environment.
WordPress CMS (branch)
Essentially current WordPress with Custom Post Types and content management elevated to first rate citizenship. Content and settings is managed in admin. Blog-centric tools like Post Formats are relegated to plugins. WordPress CMS is close to what WordPress is today.
Focus: Extended functionality including modules / meta boxes, Custom Post Types, Custom Post Templates, advanced data handling, and extended user management including added roles and capabilities.
Target audience: WordPress designers and developers building advanced sites. Small and medium scale dev shops. Advanced site managers.
WordPress Enterprise (branch from CMS)
WordPress CMS with enterprise level security and compartmentalization at the core.
Focus: Security and scaleability.
Target audience: Enterprise developers and large-scale solution owners.
WordPress Network (branch from Enterprise)
Network installation of WordPress Enterprise allowing for sub-sites of either CMS or Blogger editions.
Focus: Scalability, user management, extsibility for social networks and forums
Target audience: WordPress Network managers, MU community, bbPress, BuddyPress etc.
WordPress Experimental (terminated branch)
Branch for experimentation and testing of new ideas.
Focus: New iterations and unexplored territory.
Target audience: Developers and those who see WordPress as a blank canvas.
Platform development would work as follows:
- All branches are dependent on and built on top of WordPress Core.
- Any update to WordPress Core is mandatory for all branches.
- New features are developed against the appropriate branch.
- When new features are pertinent to all branches they are published to Core.
- New features can migrate backwards towards core or forwards towards branches.
This structure will allow for parallel development of new core and branch features while at the same time avoiding specialized branch features from bloating other branches or core.
This is a suggested draft map and outline meant to be the basis for a larger discussion about the future of WordPress. At the root of this discussion should be the end user – the person installing and running WordPress – and how to meet the demands of this person without bogging down other users in the process. To do this we need to identify who the target users are, how they use WordPress, what features they use, what features get in their way, and what features they need to move forward. It’s a complicated process and it will require a rethink of how WordPress is developed and used, but in the end I believe it will lead to a stronger platform with more opportunities for everyone who wants in.
Now it’s your turn. Discuss!
Further reading + relevant-ish links
- John Saddington of WPDaily.co makes a case for why WordPress should not be forked. Also a must-read: I Will Never Fork WordPress.
- WPTavern has an excellent writeup and response to this article with lots of links and references to older discussions about forking and evolving WordPress. It’s pretty much a must-read: At 10 Years Old, is it Time to Fork WordPress?
- Several commenters have pointed out the success of the Ghost Kickstarter project as an indicator that the time is ripe for a WordPress for Bloggers or WordPress Lite fork. If you are not familiar with Ghost go check out the campaign. As a sidenote it looks like Ghost may have initially been conceived as a fork of WordPress (and may still be) which makes this even more interesting.
- Eric Danzer’s take on the topic: Please Don’t Fork WordPress
- The Dire Straits of WordPress
- Discussion of The Dire Straits of WordPress on Hacker News
- Why WordPress is Doomed
- Why WordPress is Not Doomed
- Who Owns WordPress?