How many plugins are too many? The case for granular plugins

[anon71687268]

@Simone

My opinion is that we can define a plugin bloated for two main reasons:

• a plugin that has too many unuseful (for who? this is very personal) features
• a plugin that carries a lot of unuseful code

The second case is the one where (examples):

• a plugin offers four styles, but loads just one CSS with all styles inside
• a plugin developer embeds materializeCSS just to add a nice effect in the backend
• a theme developer uses jQuery in front end for three lines instead of using javascript
• a plugin developer don’t use transient where needed

This is the kind of problem many people don’t address.

Everything you’ve listed here is opinion, though… This is what I referred to by personal interpretation and inequity. Although, I do agree with one item you listed regarding style sheets. The rest is pretty subjective.

[joyously]

Whether you store it in a repository or list it in a directory, you only have control over the first version. The author can update it at any time to be different, with flaws or malware or cryptomining. How much responsibility does CP have for every update?
Also, for the legal angle, CP is bound to use the GPL, and so is every plugin and theme, as derivative works (although there is some question whether all plugins are derivative). The GPL is about distribution. A repository with a download button is distributing the code. A directory – does it have a download button? does it point to private repositories? Authors selling their code would not want open distribution because it’s GPL which means anyone can distribute it once they have it.

[timkaye]

How much responsibility does CP have for every update?

The duty to take reasonable care. What that means depends on the precise context but the very fact that we don’t have control over the code hosted elsewhere means that our responsibility is essentially limited to taking appropriate action when we know, or ought to be aware, that there is a significant problem with the code.

there is some question whether all plugins are derivative

Not really. Matt Mullenweg is one side, and pretty much all the lawyers are on the other! There is no question that some code is not derivative and therefore need not be licensed under the GPL (though I am not sure that CP would include it in the directory). The true issue there is in working out when specific code is not derivative.

[timkaye]

I don’t recall any decision to take a commission on premium plugins. It certainly would change things somewhat. But, as I say, I’m not sure we’ll be going down that particular route.

And, yes, we will spell out the details in a policy governing the terms of use of the directory.

[anon71742606]

@timkaye

Not really. Matt Mullenweg is one side, and pretty much all the lawyers are on the other!

Would be interesting to see when case law starts coming out on transformative vs. derivative.
There are very different feelings about that in U.S. vs in Europe.

[LinasSimonis]

@timkaye

I don’t recall any decision to take a commission on premium plugins.

Not a decision. But there was a silent approval that it can be a good idea to have 3 different plugin groups in the directory: free, freemium and paid; we can act as middleman between end users and plugin authors with the reasonable commission (say, 20%).

Some discussions are here: Premium Services Discussion
And this quote made me impression about general acceptance of this idea:

@james

I think this idea is along the right lines. Providing a centralized way to sell and update premium plugins and/or themes would be a big benefit to a large chunk of the community, at least the three different groups you mentioned in exactly the ways you mentioned.

Sometimes it is worth to bring back an old discussion.

[timkaye]

Actually, James says specifically there that he’s not speaking on behalf of the committee. We haven’t discussed it further because we haven’t yet worked out all the technical aspects. So it’s a possibility, sure, but I think it’s dependent on a few other things being in place first.

[anon71742606]

It is a viable monetization option though…

[LinasSimonis]

@timkaye

he’s not speaking on behalf of the committee

I understand that. Just wanted to point to the discussion and the old idea how to arrange plugin directory. Still think that this is a good way to earn money to further CP development. And I didn’t hear any objection to this monetization idea.

[timkaye]

Sure, it is. But I daresay others will have other suggestions when we get nearer to implementing the directory.

[LinasSimonis]

Then, the question is “how to bring all ideas to the one place and choose the best one”.

[timkaye]

Start a thread on that precise topic.

[anon71742606]

Monetization is most likely to be successful with multiple revenue streams, not just one.

[james]

@anon71742606

So, what would be best practice for encouraging granular plugins?

I’d like for us to include a measure of plugin and/or bundle size in the directory search results. We also need to continue our efforts around education (why smaller plugins are usually better). To me this boils down to “do one thing and do it well”, and @anon71687268 and @azurecurve are well-positioned to be leaders in small ClassicPress plugins.

@anon71742606

Personally I suspect that extension-based plugins will be easier to moderate. @james ?

In the spirit of the original post I am taking “extension-based” to mean “granular” or just “smaller”. In which case, yes, less code is always easier to review and manage than more code.

@LinasSimonis

Providing a centralized way to sell and update premium plugins and/or themes would be a big benefit to a large chunk of the community

I still agree with this, but we have to build the initial (free) version first.

[ozfiddler]

@james

I’d like for us to include a measure of plugin and/or bundle size in the directory search results.

I was thinking exactly the same thing. I’d like to see the overall size in kb and the total number of files for any plugin before I install it. Given a choice between two similar plugins I’d always try the leaner one first.

[anon71687268]

The number of files can be a misleading stat. Plugins that have more abstracted code will often have more files, but, that doesn’t necessarily mean it’s a lesser quality plugin. Indeed, the exact opposite could be true.

[ozfiddler]

@anon71687268

The number of files can be a misleading stat.

Yep. Good point. OK - just size would be enough for me then.

[joyously]

When I put forward a design for the WP plugin search, I included plugin size, but was told in Slack that “size didn’t matter” (!!) on plugins. That ticket has some good feedback for accessibility of the filter part of the page.

[anon71687268]

I do think size matters somewhere in terms of plugins. Take Caldera Forms, for example, last time I installed it (admittedly, quite some time ago by now,) it came with a bunch of needless weight, including the entire testing suite. I think it was near 15Mb. It would be good to know this ahead of time if I’m on a metered or slow connection.

[timkaye]

Size definitely matters here! There’s an events plugin that’s bigger than WP core, and it really doesn’t do much. It’s highly rated, but heaven knows why.

I have been seeing many bloated plugins recently. I keep wondering what problems they are introducing.