Shackling a free market: WordPress canonical plugins

[Ryan]

Sometimes I feel the whole wordpress organisation is one big black box with a magic button that aint connected to anything.

I agree. I wish this would stop as these decisions seem to pop up out of the blue with no explanation.

It's quite concerning seeing canonical (or whatever they're called) plugins being created and officially endorsed already when we don't even have an explanation of what they are, who decides what is canonical and what sort of plugins are likely to become canonical in the future. Heck, we don't even know what to call them yet as we haven't been told what they're called.

I would strongly suggest against anyone creating a plugin which is potentially going to be used by a large number of people in case a canonical plugin is created which has the same functionality. Of course, we have absolutely no idea what is or isn't like to end up in that basket due to the "black box" issue. Imagine busting your rear end trying to create a plugin and then having the carpet swept out from underneath you by WordPress.org.

I'm sure there's no ill-intent with the way things are done, but it would be a lot more pleasant if the information flow was improved and we weren't left in the cold like this. I was become quite worried for a while that a menu plugin would be created. If this happened I would lose a huge amount of revenue (assuming it caused a significant drop in the number of users of my own plugin). I rely on my plugin to make a living and if it disappeared I would have been seriously in the poop. However I've now worked out a way to quickly develop something to hook into a canonical plugin, so I think I've managed to avoid that pitful now thankfully. And it looks like menu management is going into core, so it shouldn't be too hard to build something significant on top of that core system anyway (core code is likely to be less complex and feature rich than a canonical plugin I assume).

[redwall_hp]

If someone can't figure out which plugin they should use, why are they administering a WordPress blog? If it's too much for them, they can use WordPress.com.

We need to draw the line somewhere: WordPress is not for everyone. There is a minimum skill level required, and we keep trying to lower it below where it should be. If you can install WordPress, keep it up to date, back it up, etc., then you should be able to choose a plugin.

I really don't like the idea of canonical plugins, at least as people talk of them right now. I could see having canonical plugins for things that many believe belong in core, but others think should be abstracted into plugins. But canonical plugins shouldn't be simply a way of filtering plugins. Where will that end?

Canonical plugins aren't a bad idea for things like OpenID integration, theming the login page, or other things oft-requested in the Ideas board. But there should be no canonical plugins for automatically tweeting posts, creating contact forms, adding Google analytics tracking code, or other things like that.

Also, imagine working for months to create something like GravityForms, and then having the (GPL, of course) plugin pulled out from under you and "canonicalized." You work for months to create a commercial plugin, then it's made canonical, and your commercial package is largely ignored. People would likely go with the canonical version, because it's easy to find and free. That hardly seems fair.

[hallsofmontezuma]

redwall_hp

You worded this perfectly. "I could see having canonical plugins for things that many believe belong in core, but others think should be abstracted into plugins. But canonical plugins shouldn't be simply a way of filtering plugins."

BuddyPress is a fine example of a Core plugin. It's not a replacement for a group of plugins that had to be "filtered". It's code and functionality that people want a somewhat official team overseen by Automattic working on, yet not really in the core code. There's a big difference in that, and making an Official Core Canonical Twitter plugin just because the repository has so many plugins that deal with Twitter functionality.

[andreasnrb]

BuddyPress is the only good example of what could be a core plugin. But still its creator has been employed by Automattic. I don't like the idea of connecting projects to Automattic they should be connected to wordpress.org instead.

[Ryan]

BuddyPress is the only good example of what could be a core plugin. But still its creator has been employed by Automattic. I don't like the idea of connecting projects to Automattic they should be connected to wordpress.org instead.

WordPress is owned by Automattic and the leader of WordPress.org is the owner of Automattic, so they're about as intimately linked as they could possibly be.

[andreasnrb]

Yes but there are already a wordpress foundation formed. As I understand it things are suppose to be transferred to it.

[Ryan]

I was referring to the WordPress name, the trademark of which is owned by Automattic. Worrying about Automattic being overly involved with something like that seems odd when they have that much control over everything anyway.

[Ryan]

Jane Wells released a few tidbits of extra information here:
http://www.ustream.tv/recorded/3856705

[chipbennett]

If there were going to be a couple dozen canonical/core plugins for everything you would ever need, then there might be cause for concern.

But the idea behind it is for something like (pulling this out of my hat) a twitter plugin. there are *thirty* twitter plugins in the repo. A new user has no idea where to start there. A core twitter plugin would have these advantages:

- a team of people working on it, instead of some guy in his spare time
- a core dev looked the code over for vulnerabilities
- guaranteed to work on upgrades because someone official has an eye on it

Now, we could argue that more choice is better, but - REALLY? 30 plugins, where half of them do the *exact same thing* is not a real choice. Added bonus is the developers will be able to work more closely with other developers - not in isolation. They are planning on making it easier to do that for devs or those who wish to dev. You know, sharing knowledge & learning from one another?

BuddyPress, for example, is a *perfect* one to look to. No, it's not going to be bundled, but it is worked on (a lot), not going anywhere (but up), and core devs have given it a look-over. oh, and it's free. A win for users.

on the commercial side, this still leaves room for it. Even with BP, there are paid plugins for features that haven't been added to it yet. one dev can often get something out real quick & sell it to those who want it now and can't afford to wait, so they'll pay for it.

Let's take another example: say a contact form was a core plugin or even bundled in. Would this put gravity forms out of business? Probably not for a long, long time - if ever. There's plenty of notice for devs, enough so that if Carl did ever have to adjust things, he'd have plenty of warning & time. And there are always people who are willing to pay devs direct for better assurances of paid support (not guaranteed with core plugins either).

I do take a bit of umbrage with the post's tone of "It's the American way in a capitalist society, darn it!" We're not all American. The Internet is global, and so are many WordPress users. We're not all interested in capitalizing it as much as possible. And there are some plugins that died an early premature death (podpress anyone?) that could have been prevented had they been a small team with an official "approved" stamp.

edit:


Actually, I think they're trying to make it *easier* for those working in isolation to become closer to the project, and work on their own projects with more help. There's no preventing anyone from still going off on their own.

Jeez, considering the amount of complaints I've seen about the plugin repo being full of too many outdated & duplicate plugins, you'd think those same critics would like this idea. Which was put forth to partly help exactly that.

I think the biggest cause for concern is the discriminatory sanctioning such "core" (*twitch*) plugins will receive.

My thought is: if a plugin is important enough for core developers to be working on it, then it is important enough to be rolled into core.

Here's how I think the concept of "core" (*twitch*) plugins could work:

1. Such plugins would not be called "plugins"; call them "components" or "modules" or something.
2. Such plugins would be included in the default download, but not installed
3. Such plugins would have their own UI - separate from the Plugins UI.
4. Such plugins would address extensible/niche functionality of core, such as MU (MultiSite), BuddyPress, bbPress, PodPress, etc. (say, TwitPress for integrated Twitter functionality) - functionality that extends core as a CMS, but that would not be useful to the majority of users.
5. Such plugins would themselves be extensible, with well-documented APIs

In other words, the concept (in my opinion) is one of core components, that are disabled by default, address specific, important-yet-niche functionality requirements, and are themselves extensible via the plugin system with well-documented APIs.

I think Twitter (or, micro-blogging in general) is a perfect example:

1. Micro-blogging integration is still a niche area (though growing, at the moment), but incredibly important for those within that niche.
2. The micro-blogging niche would benefit greatly from "core" micro-blogging functionality
3. Such "core" micro-blogging functionality could be made itself extensible, so as to allow for other niche uses (presumably, part of the reason for the current existence of so many Twitter-related plugins in the repo).

Thus, an important niche functionality can be more adequately supported, while still leaving sufficient space for plugin developers.

[chipbennett]

I could be way off, but like you mentioned Andrea_r, from what I understand a justification is that when an inexperienced WordPress user looks for a plugin for particular Twitter functionality, they see Twitter Tools, TweetMeme, Twitter for WordPress, Twitter This, etc etc etc and could certainly be benefited should there be an Automattic TwitterPress plugin that is unlikely to be developed by someone who doesn't know what they're doing, abandoned, etc.
If the only cause for concern is that GravityForms may lose sales or go out of business when there's and official FormPress, then I would be fine with that. (No offense to GravityForms, I use and love the plugin.) The problem I see is the problem that exists whenever the governing body (Automattic in this case) socializes a particular industry. When the official TwitterPress comes out, we'll risk losing the innovation that goes into Tweetmeme, Twitter Tools, and the others. When FormPress comes out, we'll risk Cforms II and Contact Form 7 being dropped, when Oliver and Takayuki decide their contributions just aren't worth the hard work anymore. And yes, we'll risk Carl no longer being motivated to make a comprehensive and well-written GravityForms, if the canonized FormPress makes it so that people will tend to not use it.

Well, first things first: we need established guidelines on what sort of functionality is even eligible for consideration as a "core plugin" (or, as I have decided to suggest: "core component"). I don't think "whatever the core devs think should be one" is sufficient. Maybe contact-form functionality rises to the level of importance to be considered, but I'm not sure.

Second: these "core components" need to be themselves extensible, with well-documented APIs. That way, plugin development space still exists within core components. Twitter and contact forms are both good examples: even the sanctioned plugin/component would likely still lack some functionality or features, that could then be addressed by current Twitter/contact-form plugin developers.