At 10 Years Old, Is It Time To Fork?

Design Is Philosophy LogoOver at Design Is Philosophy, Morten Rand-Hendriksen raised the question if after 10 years, is it time to fork WordPress? The gist of the post is an argument/discussion that’s been made over the years at different times. It boils down to figuring out a way to remove all the stuff that’s not needed in WordPress and coming up with a lean, modular core. Morten takes an interesting approach in that this new WordPress would consist of branches. You start with WP Core connected to different branches that contain specific functionality such as WP CMS or WP For Bloggers. In this way, those specific use case branches would have most of what you needed out of the box without having one WordPress package that contained everything for everyone.

On paper, I like the idea of a lean WordPress with modules that I enable or disable based on the functionality I need. Several years ago, I used a CMS called e107 that behaved in this manner. It was pretty cool at the time because if I wanted forums, I just enabled the forums module. If not, I left it disabled and the forums never loaded. Back in 2009, a lengthy discussion took place around the very topic of making WordPress more modular, Less than Core, More than Plugins/Themes: Proposing Optional Modules. Unlike creating different packages or branches of WordPress to fulfill specific needs, optional plugins could offer that functionality so that it wouldn’t be stuck in core.

What I’d like to propose is the creation of a new concept for WordPress, the “Optional module.” Optional modules would be singular like the core and would be versioned with the core but they would not be included in the default installation. Optional modules would be “installed-on-demand” based on a plugin’s request and admin’s approval to install, and the version of the optional module installed would be determined by the version of the WordPress core that is installing it.

Having “Optional Modules” for WordPress such as I propose would allow progress in the direction of common infrastructure without bloating the core. And one of the first such optional modules could be a basic theming framework

One of the biggest arguments against the idea is that the mostly volunteer based team that works on the core of WordPress is already pressed for time, (pardon the pun) and by creating these optional modules or plugins, it would significantly raise their work load to the point where it negatively affects their ability to work on WordPress core. That discussion took place around February of 2009. In late 2009, early 2010 the term Canonical Plugin was created to differentiate these plugins from a normal WordPress plugin. A poll was conducted with different name choices with Core Plugins winning the top spot. At the time, a core plugin was defined as follows:

Core plugins are community developed and encourage collaboration with multiple developers to satisfy the most popular functionality requests that would not make it into the Core of WordPress. These plugins would be developed alongside the core of WordPress to ensure compatibility, coding standards are met, secure code, etc. To highlight these plugins, a screen would be added to the plugins page in the back-end of WordPress to highlight these special plugins. Everything sounds great right? Let’s take a look at some of the possible unintended consequences this could have on the community.

One of the only plugins that I know of that ended up with this Core Plugin status was called Health Check by Peter Westwood. This plugin was used as a test bed for the idea of creating core plugins through collaboration.

I reached out to Aaron D. Campbell as he was one of the volunteers to generate effort and focus towards the Core Plugin project and asked him a few questions about the work that’s been completed since 2010 for Core Plugins.

Jeff – On January 11th, 2010 you published on the Make.WordPress.core blog on creating a Core Plugin Infrastructure. The only core plugin that I know up which was an experiment was Health Check by Peter Westwood. Do you know of any others that have been created since 2010? Has there been much progress or work done towards the idea of Core Plugins since?

Aaron –No. Post by E-Mail never really got off the ground. I’m hoping to get it kicked off at some point, possibly with a GSoC student this year (it was one of the ideas). Honestly, the best example of the CONCEPT of community driven development AROUND WordPress is probably _s. It’s a theme not a plugin, but it accomplished what we were envisioning

Jeff – Well, Jetpack has sort of taken the Post by email feature and put it into a plugin. My guess would be that eventually that feature will be removed in WordPress like Links in favor of the Jetpack version.

Aaron – I don’t think so. I don’t think any feature will ever be removed in favor of Jetpack.

Jeff – I was under the impression that core plugins would enable WordPress to be able to take things that became not so widely used anymore and be able to put stuff like that into a plugin enabling a light nimble core. Therefor, decreasing the need to argue that WordPress is bloated and we need to fork it.

Aaron – That’s certainly one of the goals of core plugins. However, Jetpack is not a core plugin.

Jeff – So since 2010, not much work has been accomplished around the idea of Core Plugins but it’s still an idea that’s being kicked around and will possibly make headway in the future?

Aaron – Yep. I think almost everyone agrees it’s a good idea, but having the hours needed to actually make it happen is a whole different thing.

Jeff – Agreed. It was one of the issues immediately brought up in the hackers mailing list article first proposing the idea of these core modules. Time and effort which wouldn’t detract from the time and effort of Core itself

The issues that Morten has raised such as being stuck with old backwards compatibility code and future development of WordPress are justified but I don’t like the idea of different WordPress branches or cores. I don’t want to go through a process of figuring out which specific type of WordPress I need and I doubt new users will be able to easily grasp which one is best for them. We’ll end up needing flow charts, bar graphs and such to explain the differences. At the same time, I have noticed how much stuff WordPress has added over the years that I simply don’t use. Yet, the features I don’t use are the ones my neighbor does. It seems counter-productive to install plugins that remove unused functionality just so it’s completely out of my way. It also bothers me that so much of the unused portions of WordPress are loaded or even processed when they shouldn’t. This is why I’m for the idea of compartmentalizing WordPress to the point of simply being able to turn things on or off. Then again, I can see how having a module for the simple task of disabling or enabling image editing in WordPress could be cumbersome.

I want to see WordPress continue on for another 10 years but at the same time, I don’t want it to bring everything from the previous 10 years with it. Although I haven’t mentioned the word bloat, this post from 2009 is relevant in that it discusses the question, What is WordPress bloat?


I’d be re missed if I didn’t mention Ghost somewhere in this conversation. Ghost is a vision proposed by John O’Nolan that aims to get back to the roots of simple, easy, publishing. I’m excited about Ghost and joined in with the crowd of wanting to see it in action. At this point, Ghost is just a bunch of pretty screenshots but I like what I see. John started a Kickstarter campaign to acquire 25,000 Great British Pounds to get the project off the ground. Not only did he reach that goal within hours of starting the campaign, he has since quadrupled the goal amount with 19 days left to go. What this tells me is that there is pent-up interest in seeing a platform that gets back to the basics of publishing. Many of the names on the backers list are long-time WordPress users.

There are techniques and methods to get WordPress back to its roots of being the easiest software to use to publish words to the web. Forking is not one of those methods. Are you willing to stick with WordPress through the long haul or are you ready to pack your bags and jump ship the minute something easier and better looking is released?


15 responses to “At 10 Years Old, Is It Time To Fork?”

  1. I agree with what Otto said on the other thread that it should be more about loading or not loading functionality than segmenting out core into chunks. In the end the result is the same, you’d get some — but not all — pieces loading and therefore a pseudo-customized experience.

  2. I think at this point WordPress is so ubiquitous that a fork isn’t recommended and more importantly would probably not succeed.

    Entirely new solutions like Ghost have a better chance of gaining some traction starting from scratch rather than forking WordPress. But it’s still a tough row to hoe. This isn’t exactly a space lacking solutions. There’s tons of blogging apps and CMS apps out there. But Ghost is very promising and it’s garnered a lot of attention which will give it a huge leg up when it comes to gaining some traction.

    As for core plugins… I didn’t expect them to gain traction. So it’s progressed exactly how I thought it would. Good plugins are products themselves. To do them right if it’s anything other than extremely basic functionality is going to take dedication and lot’s of effort. Dedication that would be better focused on the core rather than a plugin given it’s development not being done for money.

    But I do agree that the best usage for Core Plugins would be to remove functionality from core itself and provide it as a plugin.

  3. It boils down to figuring out a way to remove all the stuff that’s not needed in WordPress and coming up with a lean, modular core.

    Rather than talking about vague abstractions like modules, forks, core plugins or a lean, modular core, it would be more productive to talk about specifics. What exactly can or should be removed from WordPress core and packaged into an optional module?

    People seem to be talking about WordPress lately as if it’s some kind of bloatware. It’s a mature application supports a wide variety of server configurations. This is the reason that there are portions of the code that are more complex or more bloated than they would otherwise be.

    WordPress does a lot, but I honestly can’t think of a lot that would make sense to move into an optional module without causing unnecessary confusion or frustration for end users. Certainly none that would impact performance to such a degree that it’s justified.

    It would be good to get some suggestions from people for what specifically could be removed or placed into optional modules, and then discuss the impact and the advantages of doing so.

  4. What I got from watching the pitch video for Ghost is that it makes the post writing experience better. It’s not about adding or stripping away any functionality from WordPress.

    And I have to agree that post writing, previewing, and editing on WordPress is very painful. It’s sluggish and cumbersome.

    WordPress as a software maybe is amazing, but the user experience is pretty terrible. I’m a long time WordPress user and developer and recently I wanted to start a blog on and wow. What a nightmare that was! The back end and configurations are more confusing than cPanel!

    Sent from my iPhone

  5. Excellent writeup and a great analysis of my article and the other work that has been done and published on the subject. I am appending a link to this article in mine as suggested further reading.

    To some of the points: My intention is not necessarily to insist that a forked approach is the only way to go. It is rather to kick off a renewed discussion about where WordPress is headed and more importantly what the goal is of WordPress as a whole. I guess in some way the idea of a fork is distracting from this main point so let me clarify:

    My main beef with WordPress right now is the same issue Ghost is hoping to solve: It’s way too complicated for the novice. But that’s just the tip of the iceberg. There is also a lot of effort being put into elements that may not have as much user appeal as they seem. One prime example is the new Post Formats UI. Having discussed this at length with users, developers, UX designers, designers, and everyone in between I have been hard pressed to find anyone who needs or even wants this new feature. It seems to be a feature desired by core developers but not necessarily wanted by the people who actually use WordPress. I may be wrong or my polling data may be off, but it’s a strange focus of energy, especially when the much more useful update to Post Revisions was put aside.

    Likewise the development of MP6 seems less of a demand from the users and more something the core developers themselves want.

    Now before you get me wrong here: I appreciate the work and the time put into these things, but from my perspective what matters is the person at the other end of the chain who actually uses WordPress in the real world. Post Formats produce weird questions like “Do I click the Video button when I want to add a video to my post” while MP6 requires retraining of everyone who uses the application. That’s fine for casual bloggers, but in an enterprise environment where hundreds of people work on a highly customized install it means hours of retraining and endless questions from IT and management about why everything looks different and why the weird media buttons don’t work the way they should. Think of the backlash Microsoft faced when they switched form “old” Office UI to “new” Office UI and you get the idea.

    To me the primary focus of WordPress (and any other application for that matter) is to meet the demands of the end user. And like I said, the end user of WordPress is not homogenous. Just like there is a PhotoShop Elements to PhotoShop, an iMovie to Final Cut Pro, and a Windows Home Edition to Windows Enterprise, there should be a WordPress Blogger to WordPress CMS.

  6. @Drew Jaynes – Yes, even a pseudo-customized experience would be better than segmenting everything into core plugins or optional modules.

    @Carl Hancock – That’s my feeling as well. Because of the large third party ecosystem and the economy surrounding WordPress, forking it just isn’t going to get anyone very far. However, I love seeing things like Ghost come up where they have a clean slate. Fresh code and a fresh take on how to accomplish tasks while revamping the publishing experience. It will be interesting to see how well Ghost is received after it hits the public’s hands. With the financial backing, I imagine John is now under a lot of pressure to deliver the goods.

    I outlined the development of Core Plugins because somewhere within that idea, was the revelation of taking out some functionality from WordPress and applying it to a plugin. But as we can see, a few years later development of Core Plugins has really stagnated. Too much effort directed to core and not enough left over for those plugins.

    @John Blackbourn – You raise some good points and in fact, I’m going to outline a list of things that I wouldn’t mind seeing removed from WordPress and either put into a plugin or just disappearing entirely. But like I mentioned in the post, the things I don’t use and would like to see be put into a plugin are the same things my neighbor probably uses every day. Although with what happened to the Blogroll/Links area in WordPress, it’s been proven that longstanding functionality can be removed from WordPress.

    @MK Safi – That video is what got me excited to try out Ghost. If John can nail down the publishing experience and make it better than what WordPress offers, he could be really onto something. Funny you mention because I completely agree with you. One day, I decided to reopen my account on .com and was amazed at everything that was put in front of me. To put it bluntly, it’s a cluster#$@!. I have no idea how new users can easily navigate around and accomplish tasks using

  7. @Morten Rand-Hendriksen – Thanks for stopping by and clarifying some of your points. I think we can all agree that at the end of the day, what matters is the end user. I think another example I could throw in here is the image editing features that were added. Just another group of features I don’t use because I do my image processing/editing on my desktop outside of WordPress.

    It’s an interesting paradox. In the early days of WordPress, we wanted more features to be added to WordPress. 10 years later, we want features taken away. As for your MP6 example, I’m not sure if that is actually going to be added to core or if it will remain as an experimental plugin. At least some of the bigger ideas for WordPress can start out as plugins first, then be added to core when they are in demand or are ready.

    I remember a few years ago in an interview I conducted with Matt where I asked him what was the overall goal of WordPress considering its userbase. I remember him saying that the goal was to simply democratize publishing and enable anyone in the world to get their thoughts published online. I don’t know about you but I think WordPress as is does a fairly decent job at reaching that goal. A lot could be done to improve the process of publishing those words and removing anything that may be getting in the way of putting those thoughts and words online.

  8. “One prime example is the new Post Formats UI. Having discussed this at length with users, developers, UX designers, designers, and everyone in between I have been hard pressed to find anyone who needs or even wants this new feature. It seems to be a feature desired by core developers but not necessarily wanted by the people who actually use WordPress.” (@Morten Rand-Hendriksen)

    Totally agree. Sometimes I wonder what’s the point of if it’s completely ignored by the core developers.

  9. @Morten Rand-Hendriksen -Actually, I CAN’T WAIT for post formats to finally make its fully-formed debut. The delays in releasing 3.6 are driving me nuts!

    Also, WP seems pretty darned easy to use. Complaints of complexity seem overblown.

  10. This reminds me of discussion the Postnuke-Community had 10 years ago. They started a fork in 2005 iirc: Postnuke 0.8 which became Zikula 1.0 – a total rewrite and a core without modules. You are able to assemble just the function you need. Its based on Symphony now. From a developer perspective, it’s a great piece of Software, but they lost most of their community to Joomla and WordPress because they offer a lot of stuff out of the box… it seems, history is repeating.

  11. […] There seems to be chatter lately about the possibility of forking or otherwise building derivatives for WordPress. The most prominent example is Ghost, which has gained a lot of traction as well as funding on Kickstarter. This week, Morten Rand-Henricksen posted a missive on creating multiple forks from WordPress with great responses on WPDaily and  WPTavern. […]

  12. I have to agree with @Morten Rand-Hendriksen about beginners. I work with them all the time, and the belief WordPress is fantastically easy for beginners to learn and use is, at best, half-myth. The most common complaints I hear are overwhelmingly about the admin Dashboard–way too many exposed options and features, too many different ways to do the same task, and no clear path through the interface.

    And more often than not, the beginners I help or talk to don’t understand the difference between a “blog” and a “website”–or rather, they almost always want “a website with blogging”, not “a blog”. In other words, they don’t really care about “posts”, and are confused by them when they don’t really want a blog. In fact, most WP beginners I talk to want (a) the front-end design part to be (a) much simpler, and a CMS (though they don’t call it that, of course). The “header image” functionality, for example, is awkwardly bad and outdated for today’s needs.

    And so on. WP really is headed down a path of diluted strength, I think despite best intentions. I’d support a fork of some sort, or even a re-imagining of things.

  13. Really enjoying this discussion. I think it’s very valid.

    Check out what we’ve been building at

    It’s designed to be your home on the web, where you can show off all of your social networks you’re on, you can post blogs and you can even aggregate content via auto-posts from your existing apps.

    We’ve built a very custom layer on top of WP. IMHO, it’s one of the most ambitious undertakings ever to be built with WordPress. In my experience with building this layer on top of WP, there are certain parts of the core that just need to be forked, such as the post editor. We could sit around and wait for the team to add the features & functions we need, but that could take months or even years based on the rate of development.

    I am trying to figure out if we’re going to fork it, or just use our existing solution. If we do fork, I’m wondering if we should just fork the entire thing. Would love any feedback or thoughts.

    Be happy to set anyone up with a beta account, so you can see what we’ve done. Get in touch! brandon @ seshn dot com


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: