The Features as Plugins First Model Is a Mess

Released in late 2013, WordPress 3.8 was packed with new features including, a new theme browser experience, widgets area chooser, and a redesign of the backend. It’s also the first release to include a feature using a new formal development process called features-as-plugins first. The backend redesign started off as a plugin called MP6 with development beginning in March, 2013.

Prior to MP6, features were largely developed inside of core during the development cycle. This method caused some versions to be delayed, as was the case for WordPress 3.6. The success of MP6 proved that by developing core features as plugins first, they were easier to test, manage, and merge into core at the appropriate time. Since adopting the development process, at least seven features have landed in core. However, as an outsider looking in, the process seems to be falling apart.

MP6 Set The Bar

MP6 WordPress Admin Plugin
MP6 WordPress Admin Plugin

Each week, Matt Mullenweg and Matt Thomas released a new version for people to test. They also kept everyone updated on what changed and left the comment form open to solicit feedback. This made it easy for people to participate in the development and testing process. By using P2 and the comment section, it was a lot easier to provide feedback. Since MP6 was a plugin, testing it was as easy as installing it on a stable version of WordPress.

The Lack of a Testing Audience

MP6 was available for download on the WordPress plugin directory. This made it accessible to anyone who wanted to test it. Recent plugins like the User Session Manager by John Blackbourn don’t have any P2 posts on the Make WordPress Core site. As with several other features, discussion took place within a trac ticket. Development of the plugin was handled on Github until it received a pass to be merged into core. Having a feature plugin only available on Github and a lack of communication surrounding the feature prevents a lot of people from potentially being part of the testing group.

WordPress lead developer, Ryan Boren, noted in an open thread in November of 2014, that when it comes to gathering a testing audience, no feature plugin has reached the standards set by MP6. For plugins to be merged into core, Boren suggested the following items should be met:

  • Be present and up-to-date in the plugin directory.
  • Be as ready to go on mobile as they are on desktop.
  • Have visual records for major flows through all new interfaces on all devices.
  • Have mature UI that isn’t going to derail the release train.
  • Have a history of posting weekly updates to make/core.
  • Have a history of regular plugin directory updates.
  • Have a testing audience.
  • Publish a merge consideration post on make/core complete with visual records and other diligence.
  • Exist for at least one release cycle. Plugins created at the beginning of a release cycle should not be considered for merge until the next release.

Several feature plugins fail to adhere to many of these proposed guidelines. In June of 2014, Andrew Nacin added a “Beta Testing” tab to the add plugins screen for those who use WordPress trunk. The tab lists Feature Plugins that are available for testing.

Featured Plugin Development Looks Dead
Feature Plugin Development Looks Dead

Based on the results in the screenshot, it looks like every feature plugin is dead in the water, including the WP API. However, if you look at the activity for WP API on Github, there’s plenty of development taking place. How can more people participate in the testing process if feature plugins are not routinely updated and available for download in the directory? This needs to change sooner rather than later.

Feature Plugins are More Like Experiments

Feature plugins are not guaranteed to be added to WordPress. Instead, the process is similar to a lab with each one being an experiment. Sometimes a plugin won’t be added but parts of it will. For example, many of the improvements to the post editor in 3.9, 4.0, and 4.1 are derived from the Front-end Editor. Maybe the core team should think about renaming them to feature experiments as it’s more representative of what they really are.

Project Management

When I brought up the subject of feature plugin development at the January 7th core development meeting, Scott Taylor made an excellent point, “Features-as-plugins often become Projects without requirements or tasks, which leads to a non-schedule, and then often require all-or-nothing to go in.” Feature plugins are generally driven by one or two people who might be good developers, but lack project management skills. It’s almost like someone needs to constantly shepherd feature plugins to make sure they’re following a schedule and keeping them all on the same page.

The Process Needs to be Fixed

It’s clear that the feature plugin development process is disjointed at best. Communication is lacking, synchronized development between plugins on Github and is non-existent, and some plugins are merged too quickly. If users are to receive the maximum benefits from the experimental process, it needs to be orchestrated better. At least the core team is aware of the problems and is working towards improving the situation for the 4.2 development cycle.


13 responses to “The Features as Plugins First Model Is a Mess”

  1. In my opinion, the problem with the current Feature-Plugin model is that it lacks the *context* of a core team-defined road map. I have long complained about the lack of a robust, publicly available, long-term road map for WordPress development.

    So, without that context, the Feature-Plugin model is akin to throwing strands of undercooked spaghetti against the wall, and seeing what sticks. There’s no direction, and no buy-in, either from core or from the contributor community. Thus, you end up with a bunch of Feature Plugins that wither on the vine. Too many development resources get diluted among too many Feature Plugins, with no real project-management type leadership.

    I would (still) love to see WordPress development have some defined development goals and milestones. Then, direct contributor resources toward those Feature Plugins that best accomplish those goals.

    • Indeed. WordPress is a lot of different things for a lot of different people, but each release should be a coherent set of new/improved features with some kind of plan behind them. It’s great that some things just happen to be ready in time for a release and get “thrown in,” but that’s a bonus at best. Each actual version (as opposed to security bug fix releases) should have a reason to exist, an identity that can be explained and anticipated. We may not know where WordPress is going in the long run, since it is getting pulled in so many directions and is ultimately an expression of the mass of developers who are contributing to it, but at least in the short term (ie through the next major version) there should be a plan.

  2. Regardless of how messy the process may be, these experiments have still made beneficial contributions to core. I do agree that the process needs some refinement. Let’s hope the recent rush to get some features in core will not usher in unforeseeable issues down the road. I think the model is certainly good and its implementation needs attention, as you mention.

    The link you included to Make WordPress Core does show planning for the 4.2 cycle, but I don’t see specific work toward improving the framework and process for featured experiments. The guidelines/requirements set forth by Ryan Boren seems like a good start, if adopted. What other first steps could be taken?

  3. In WP-APIs defense, the reason they haven’t updated the plugin on .org is because it’s undergoing a massive overhaul for a version 2.0 that they’d like to get merged into core, but yeah, it’s unfortunate that there isn’t more information on MakeWP about it. It’s pretty much the Next Big Thing in WordPress and I’m sad it hasn’t been merged in yet.

  4. I think one of the main issues here is and SVN. Think about it, what if SVN was dropped, and instead all the plugins were integrated with Github. Since all the plugins are GPL anyway, there would be no problems with the movement. Since the .org plugin sites would look active since the Github repo is active.

    Here’re some more integration ideas:
    * Github has a “release” feature, we can take the latest release there as a stable release version of plugins. Clicking on the download button in would simply get the latest release version.
    * A button called “development branch” (or something cooler) can also be added beside the normal download button in That would install the files straight from the dev files instead of the stable releases.
    * The last commit messages can be used as the changelog between plugin versions
    * Github’s issues tab can be used as the support tab in the plugin page.
    * can be used instead of readme.txt if it’s present.

    I don’t know about the legalities and how hard the .org can be transitioned to this. But for me the ideas I gave above are more than enough to consider doing this.

  5. I don’t think the feature as plugins model is the issue, but more of a general issue with getting things all the way there. Take the JSON Api, it’s already in use by many sites using the plugin and it’s a big success. But it hasn’t landed in core and it doesn’t look like it will in the next release either. Version 0.1 was available around June 2013. It has been teased as an inclusion in various releases since then, but it still looks like a long shot.

    For some reason development just slows down. Maybe this is in part because there isn’t a strong enough organisational drive to commit to certain features and simply get them done all the way by a certain time frame.

    • I wouldn’t attribute it to slowdowns or a lack of drive. It’s hard to get something from “Mostly works in most environments” to “Totally works in virtually all environments.” On projects I’ve worked on, that’s felt like at least half the work. (Related is Hofstadter’s Law and a bunch of other things like it. It’s just really hard to estimate complexity.)

      Hitting and climbing the wall of “it’s mostly/sort of/almost done, but…” complexity is where strong project management and a decently sized, really committed team come in; and I think it’s also (for those same reasons) where feature plugins risk bogging down.

      I’d love to see stronger ties of official support for all feature plugins, rather than the possibility of a “Good luck, come back when it’s perfect” approach to some of them. The “Project Management” section of the article captures this really well.

  6. A great outsider’s view – I really appreciated your take on this issue Jeff.

    Feature Plugins have certainly not worked near as well as promised by MP6. It seems though that the core team is aware of the shortcomings & Ryan Boren, in particular, has a clear strategy to fix it. Hopefully well see this issue start to be addressed a lot more during 4.2 and beyond.


Subscribe Via Email

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

%d bloggers like this: