Canonical Plugins

[chipbennett]

Well, it's made the Twitter rounds: Jane Wells' blog post and poll regarding Canonical Plugins.

First, the working definition of a canonical plugin:

Canonical plugins would be plugins that are community developed (multiple developers, not just one person) and address the most popular functionality requests with superlative execution. These plugins would be GPL and live in the WordPress.org repo, and would be developed in close connection with WordPress core. There would be a very strong relationship between core and these plugins that ensured that a) the plugin code would be secure and the best possible example of coding standards, and b) that new versions of WordPress would be tested against these plugins prior to release to ensure compatibility. There would be a screen within the Plugins section of the WordPress admin to feature these canonical plugins as a kind of Editor’s Choice or Verified guarantee. These plugins would be a true extension of core WordPress in terms of compatibility, security and support.

So, in other words, a canonical plugin is one that is community developed, in close communication with WP core, to the utmost quality standard, and validated to work with current WP version.

Next, the proposed list of ideas for what to call them:

Standard - Implies that these are the standard by which all other plugins should be judged, as well as the idea of them being the default plugins.
Core - Makes the close relationship to core WordPress development very clear, and has the implication of bundled plugins (even though we don’t need to actually bundle them now that the installer is right in the admin tool).
Premium – Identifies these officially-supported plugins as best-in-class and of the highest value, and could potentially disambiguate the word Premium as it is currently being used in the community (to refer to anything from commercial support to licensing terms to actual code quality).
Validated - Focuses on the fact that the code is reviewed for compatibility with core and for security.
Official – Makes it plain that these are the plugins officially endorsed by the core team as being the best at their functions.
Canonical – Maybe once people get used to it, canonical wouldn’t confuse so many people?

My thoughts:

#1 Canonical, #2 Core: These two terms are really the only two that should be considered, as they are the most accurate terms to describe canonical plugins.

Core is slightly more misleading than Canonical, as "core" code is, by definition, part of the main body of code rather than an extension, such as a plugin. Thus, a "core plugin" is slightly contradictory.

#3 Standard: meh. Not misleading, but not terribly descriptive. Also, implies that non-canonical plugins are "non-standard". Implies an explicit standard by which canonical plugins are developed (when, in reality, no such explicit standard will exist).

#4 Official: likewise, meh. Implies that the canonical plugins are not just WordPress-endorsed, but are part of the WordPress code "family" - when in reality, they are still community-developed plugins.

#5 Validated: implies that non-canonical plugins are (or can) not be similarly validated.

#6 Premium: for better or for worse, the term premium has extant use and meaning, as a "premium" plugin (or theme) is a "commercial" plugin (or theme). Use here would simply cause confusion, and would have the detrimental consequence of implying that the currently so-called "premium" plugins are canonical.

Other possible terms (that were probably discussed and discarded):

• Endorsed
• Select
• Prime
• Elite
• Preferred
• Certified
• Recommended

How did you vote?

[Ryan]

I haven't voted yet because I don't think any of the options are suitable.

I'm worried that once a "canonical" plugin is released, that no one will even bother creating something to compete against it. You are effectively fighting an uphill battle then as it would take a lot to overthrow the canonical plugin due to the shear weight of users behind it. If it leads to better plugins overall, I'm for it, but I'm not entirely convinced it will help.

[ifranky]

I have not voted yet, I still am trying to come up with another term, but for now I lean towards Canonical.

Otherwise I would try to keep the name as 'neutral' as possible, I agree with most of your thoughts Chip and expressed pretty much the same thoughts on BloggingPro. I would rather lean towards something like 'Community Maintained/Developed' as name/label to avoid possible divides which could come from names such as Standard, Official, Core, Premium.

[Elpie]

I went for "Validated".
This, to me, means its been tested for code quality and security. It could also open the door to validation of other plugins. For users, the benefit is that they can be certain that a plugin works as expected and is as secure as the core code.

The "canonical" term will confuse users. Most people don't have a clue what it means or if they do then they associate it with Google's canonical URL. It will also cause confusion with Yoast's plugin: http://wordpress.org/extend/plugins/canonical/

I don't like this idea that they are "community created" as this sets up a feeling of "them and us" and further distances the community from the core developers. Everything in an open source project is community-created. Once a core team starts seeing itself as some kind of elite group community contributions drop off and simply become users. Until they get fed up with nobody listening to them and either fork or find something else.

[Otto]

I'm worried that once a "canonical" plugin is released, that no one will even bother creating something to compete against it. You are effectively fighting an uphill battle then as it would take a lot to overthrow the canonical plugin due to the shear weight of users behind it. If it leads to better plugins overall, I'm for it, but I'm not entirely convinced it will help.

That strikes me as a valid point, however many people shy away from plugins because they are worried about future support. An official plugin would go a way to relieve that issue, since the plugin will be widely used and thus supported by the community.

Basically, the goal here is to create an environment for plugins where they are contributed to by many people, in the same way the core is. Plugins now, for the most part, have single authors who can drop them on a whim. Look at what happened to PodPress, for example. It's very hard for somebody else to come along and pick it up because the original development environment was just one guy doing his thing.

The environment to do this already exists. Plugins in the official repo are version controlled in SVN. There's a separate trac for them. All the bits are available to make contributions easy, basically.

It will also cause confusion with Yoast's plugin: http://wordpress.org/extend/plugins/canonical/

That plugin will go away soon enough. They built it into core for 2.9.

I don't like this idea that they are "community created" as this sets up a feeling of "them and us" and further distances the community from the core developers. Everything in an open source project is community-created. Once a core team starts seeing itself as some kind of elite group community contributions drop off and simply become users. Until they get fed up with nobody listening to them and either fork or find something else.

That's a bit extreme, I think. Many of these official plugins are going to be created by core contributors, after all.

[andreasnrb]

I don't like the idea of canonical plugins at all. Its stupid, anti innovation, and an utter crap attempt to close the ranks against The Other Ones.

[chipbennett]

I haven't voted yet because I don't think any of the options are suitable.

I'm worried that once a "canonical" plugin is released, that no one will even bother creating something to compete against it.

Perhaps; perhaps not. It would depend on the features and implementation. Other developers can still find other niches, even in the same space. Granted, the "officialness" of the canonical plugin would create quite a barrier to entry.

You are effectively fighting an uphill battle then as it would take a lot to overthrow the canonical plugin due to the shear weight of users behind it. If it leads to better plugins overall, I'm for it, but I'm not entirely convinced it will help.

I suppose that will depend on what plugins become "canonical". I would imagine that the decision would be driven by overall interest/usage of the plugin, but who knows?

[chipbennett]

I went for "Validated".
This, to me, means its been tested for code quality and security. It could also open the door to validation of other plugins. For users, the benefit is that they can be certain that a plugin works as expected and is as secure as the core code.

My main problem with "validated" is that it implies that other, non-canonical plugins either aren't, or can't be, validated.

It implies that some standard exists by which the canonical plugins have been validated. And if such a standard exists, why can other plugins not be tested against that standard?

And if other plugins can be tested against that standard, can they not also be considered to be validated?

So, if other, non-canonical plugins can be validated, what are they called? "Unofficially validated"?

The term "validated" simply means "documented to conform to some standard". If such a standard exists, then it should be applied to as many plugins as possible.

Thus, the term "validated" should by necessity not apply only to canonical plugins.

The "canonical" term will confuse users. Most people don't have a clue what it means or if they do then they associate it with Google's canonical URL. It will also cause confusion with Yoast's plugin: http://wordpress.org/extend/plugins/canonical/

I don't think "most" users would associate the term "canonical" with Google's canonical URL. In fact, I think most people would not associate the term with anything.

And for those that do associate the term, they would associate it with its root - canon - and would associate "canonical" plugins with canonical books of Scripture (e.g. the Bible). Such association would likely help them understand what is meant by the term, in the sense that they would intuit that such plugins are somehow "official".

(Me? When ever I see the tem "canonical", I think of Ubuntu.)

I don't like this idea that they are "community created" as this sets up a feeling of "them and us" and further distances the community from the core developers. Everything in an open source project is community-created. Once a core team starts seeing itself as some kind of elite group community contributions drop off and simply become users. Until they get fed up with nobody listening to them and either fork or find something else.

I'm not sure how the suggested implementation really changes anything in that regard, other than the canonical plugins would go from single-developer ownership/responsibility to "community" ownership/responsibility. (And I can see how some developers would not be happy about that - but, it is part of working in the world of GPL, no?)

Do you see it as exacerbating any current such sentiment regarding core-dev vs. community, us-vs-them?

[chipbennett]

That's a bit extreme, I think. Many of these official plugins are going to be created by core contributors, after all.

I would hope not. I would hope that the canonical plugins would be gleaned from the existing pool of plugins, rather than created from scratch. Isn't that just the sort of wheel-reinventing that open-source developing is supposed to prevent/preclude?

[chipbennett]

I don't like the idea of canonical plugins at all. Its stupid, anti innovation, and an utter crap attempt to close the ranks against The Other Ones.

Interesting.

As someone who is solely a user, the idea as presented sounds pretty good. Certain (presumably, popular) plugins would get a larger support base, would be more likely to be kept updated (bugs/features), and would be essentially guaranteed to continue working seamlessly from WP version to WP version.

Care to expound? How do you see the idea being implemented, and how do you see it leading to the things you mentioned?