Shackling a free market: WordPress canonical plugins

[chipbennett]

The distributions thing was brought up during Janes keynote on Saturday from WordCamp Atlanta and she said WordPress currently has no plans on offering different distributions like Linux.

That appears to be a somewhat... uninformed answer, because that's not how the Linux world works.

Debian doesn't offer five different distributions, either. Other entities redistribute Debian as other distributions. Ubuntu is but one such redistribution - and there are other distros based on Ubuntu (e.g. Mint).

So, what Automattic (or the WPF) does is completely irrelevant to the question of WordPress "distributions", because it would be other entities doing the re-packaging and re-distribution.

My question is, if WordPress had lets say 5 different distributions, who then is going to maintain those distributions and keep them up to date and such with the core product? It sounds like in order to make that work, we would need canonical distributions of WordPress.

Simple: Automattic (or the WPF) releases WordPress v3.0. Then Joe Blow re-packages WP 3.0, adding custom plugins/themes, and re-releases it as JoeBlowPress (version-whatever).

Then, when a new WordPress version is released, Joe Blow incorporates the changes into JoeBlowPress, and re-releases it.

WordPress doesn't do (or concern themselves with) anything except updating and releasing WordPress.

[Ryan]

If I could have voted, I'd have chosen your suggestion too Chip. It looks like the decision has been made though so I'll just work out the best way to fit into the new system.

Your comment about plugins for plugins seems like a particularly good one. Even a "core" plugin (I twitch a bit on that too) is going to need to be fairly lean. So plugins to add more functionality to those plugins will likely be necessary.

They keep mentioning a "Twitter widget" as an example of what should be a "core" (twitch) plugin, but I suspect that "core" plugin will be quite lean and so a bunch of plugin-on-plugins will come in to add all sorts of extra functionality, like auto-URL shortening etc.

[kgraeme]

Oddly, I think I'm opposed to the canonical plugins idea.

As soon as I heard about them from a presentation by Mark Jaquith, they struck me as a form of stagnation for the WordPress community. Rather than encouraging diversity of ideas and solutions, they will instead codify and crystallize the community around a very small handful of solutions.

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.

Actually, it's not a question of how many, but the opportunity to differentiate.

For instance, given HyperDB, Automattic's multi-db plugin, why did Ron feel the need to develop SharDB? Or even better, with the defacto canonical plugin of Donncha's domain mapping plugin why did Ron write his own domain mapping plugin?

Yes, I know that in both cases they were solving problems that weren't handled in the orginal (canonical) plugins, and the obvious counter-argument is that with canonical plugins that Ron could have contributed his changes to the original plugin's development. Which would be great IF his changes get included or IF his changes don't change the intended functionality of the original plugin.

In the case of the domain mapping plugin, there is a specific difference in functionality between Donncha's and Ron's plugins that makes having two options better than one. Because while they do the same thing, they approach it from solving different use-cases. (For those that don't follow MU plugins, Donncha's gives MU blog admins the ability to map their own domain domains while Ron's limits it to the site "super" admin. And of course, Ron being the great guy he is also contributed to Donncha's.)

As for contributing to the plugin project, the problem there is the same as with WordPress. There have been many cases where I've gone to Trac to request an enhancement and found that it had already been requested and rejected. So much for contributing to the core/canonical project.

I'm not against plugins being collaboratively developed. Nor against certain plugins rising to become defacto preferred solutions. My concern is Automattic playing a governance role in the plugin development, declaring certain solutions to be canonical, and thus stifling development of valuable competitive plugins. Because if there's a canonical shopping cart plugin, why would anyone even bother to make a different one? And if that canonical shopping cart plugin doesn't solve a (non developer) customer's business needs? Then they're going to opt for a non-wordpress solution rather than a different wordpress shopping cart plugin, because there won't BE another choice.

[chipbennett]

If I could have voted, I'd have chosen your suggestion too Chip. It looks like the decision has been made though so I'll just work out the best way to fit into the new system.

Your comment about plugins for plugins seems like a particularly good one.

So, is my suggestion for "core components" (including all enumerated criteria) good enough that I should formalize/expound upon it, and present it for consideration (dev chat agenda, or something)? Or has the ship already sailed?

We did actually get somewhat of a response on the privacy-policy disclosure issue when I laid out the arguments on the dev chat agenda, so who knows?

[Ryan]

I suspect that ship has sailed.

BTW, I edited my post quite a bit since you quoted (I had a little more to say :p).

[hallsofmontezuma]

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.

Andrea_r, I don't know that anyone is specifically saying that "more is better," rather that actually choices are better. I believe that having a Core plugin for particular functionality effectively reduces or removes the actual choice.

[chipbennett]

I suspect that ship has sailed.

I suspect you're right, and it is such circumstances that frustrate me about the WordPress project: a half-cocked idea, not well thought-out, not well-defined (not to mention, not well-named), that obviously causes a great deal of consternation within the WordPress community, that is just taken and run with - with little or no consultation of or input from the WordPress community.

The underlying intent for "core plugins" is sound, and the idea could be developed into a very good one.

But as it is, the idea appears to be headed for disaster.

Matt, Westi, et al: what's the rush? Slow down, and listen to your community.

Remember that open-source philosophy? Apply it not just to code development, but to decisions such as this one, and you might just find that you'll end up with the enthusiastic support of the community rather than a building controversy.

BTW, I edited my post quite a bit since you quoted (I had a little more to say :p).

So do I, apparently (and at least it's not about the GPL this time. :) )

[andreasnrb]

Yep the impression is that the ship has sailed.
But I don't really like the idea of components either. Even more blackboxes and magic buttons.
Though a bunch of people making an API for certain functionality without any labels could be an alternative. If its marketed etc other devs will use it.
And then we are somewhat on the way to distros. Ubuntu devs don't make their own kernel. They don't make their own screenhandler? KDE or Fluxbox etc either.

[Ryan]

If we really wanted to push this in a certain direction we probably should have started jumping up and down when they first started mentioning the concept. As it stands, we've waited quite a long time before airing concerns about it. Personally I just figured it would work itself out, which it probably will, but in retrospect I would have been a little more vocal and been more proactive in suggesting ideas/promoting them.

[hallsofmontezuma]

The ship hasn't sailed. I'm concerned that should this be implemented, there's no going back. We need this to be discussed in the community and revisited in the dev chat.