1. Chip Bennett

    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.


    • David Decker (deckerweb)

      The above post plus your comment: THIS! ‘nough said! :)


    • Joe

      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. Jeffrey

    Thank you for the insight. I guess it is one of the challenges in open source software development.


  3. UaMV

    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?


  4. James DiGioia

    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.


  5. Benjamin Intal

    I think one of the main issues here is WordPress.org 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 WordPress.org 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 WordPress.org. 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.
    * Readme.md 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.


  6. peterrknight11s

    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.


    • fredclaymeyer

      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.


  7. David Mccarthy

    I’m with Chip and Joe – WordPress, along with every other app (and people too), needs to have a plan, a direction … even if they end up some place else. Isn’t that how all successful businesses work?


  8. buzztone

    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.


  9. Alec Kinnear

    I like the idea of Github only repository as well. Maintaining SVN and Github is duplicate work for us.


  10. Terence Milbourn

    It never fails to amaze me how myopic developers can be.

    This is a discussion that needs to take place between developers and knowledgeable users.

    The majority of WordPress site owners don’t have sufficient knowledge to contribute here.

    Likewise on the ‘suppository’.


Comments are closed.

%d bloggers like this: