Over 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?
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.