I read this question by Tim a while ago in an older thread.
It has sort of been mulling in my head.
A lot of authors who contribute to repositories / directories understandably create a single product that is an all-in-one solution of sorts.
What bothers me though, is that sometimes one only needs a small part of a plugin.
And some of the functions may be replicated across the more “commercial” plugins.
A number of plugin authors also use open source code (let’s say 20% of the plugin to be generous) that covers all the essential functionality of a plugin, but then write another 80% of the plugin that simply deals with user-interaction (admin menus and such) and pretty much nothing else.
There are also plugins and plugins. Some may be one simple function. Others may have several folders and dozens of files.
So, what would be best practice for encouraging granular plugins?
Part of the USP (as discussed in Elisabetta’s post) is that CP will give control back to its users by not just being modular, but also by being granular.
If reducing bloat is a core coding philosophy for CP, how is it possible to encourage plugin authors to also adhere to it, by, for example, creating a core plugin with multiple extensions instead of just having one very large plugin?
One way could potentially be in the search of the directory; give extra weighting in the results to single purpose plugins (or at least give the user the option to enable this when searching).
Definitely agreed that CP could incentivize certain behaviours in the directory design. +1
Personally I greatly prefer filters over weightings, for reasons that are best addressed in a separate thread
@azurecurve and @anon71687268 (because it is mainly your plugins that I have seen as tagged with “ClassicPress” in the WP repo) @norske@joyously and anyone else I may have missed or who is willing to chime in… Do you have any thoughts on:
Are granular / extension-based plugins easier / harder to monetize?
Are granular / extension-based plugins easier / harder to provide support for?
Personally I suspect that extension-based plugins will be easier to moderate. @james ?
Every plugin/add-on/extension has an overhead simply by virtue of it existing. Unless splitting up a plugin generates enough extra revenue to compensate for the loss of development bandwidth, from the perspective of the developer I’d say it’s a bad idea.
The concept of core plugins is a little misleading. We use the word “core” to be all the code that comes in the installation bundle. It is always there. We use the word “plugin” to be additional code that is 3rd party, has a different author and development process, and modifies how the core functions.
Putting the two together is a little confusing. If there is core code that can be turned off, is it a plugin? Or if it’s code that used to be core, but has to be installed separately, is it still core? I’m not sure I know what form the “core plugins” are designed to be. If they are actually core (always installed), can 3rd party plugins call that code reliably or do they need to check if it’s there (or enabled)?
I’m bring this up because it’s the same for plugins that enhance other plugins. Themes also. They have to check if the plugin exists before using it, otherwise, fatal errors abound. One way around this is to only extend using filters and actions. Even if they don’t exist, it is not an error to add either one. This has been called “doing things the WordPress way”. So the more event-driven the code is, the better for everyone. That is sort of outside of granular vs. non-granular.
My opinion is that plugins like JetPack are too big to use. I would choose several small plugins over one JetPack.
I don’t think the search should be influenced at all. It should faithfully show the data the user searches for, without bias because every user has a different intent and the search algorithm can’t deduce what that intent is.
I don’t see what monetizing and support have to do with a conversation on granularity of plugins. Are you trying to build a marketplace or a directory?
Agreed. The same thing with the more popular security plugins.
For example, you may install an extra plugin because that one has brute force protections that you prefer over what you use for other general security functions, but that code bloat doesn’t go away.
Any successful organization has to share certain core values.
At the end of the day, CP is a multi-sided platform.
It needs plugin and theme developers in particular to contribute to its options in order to be successful.
So, it is important to consider (from the beginning, even if plans change later on) how core philosophies impact on the various stakeholders.
If you want people to contribute to your platform and to form long term successful partnerships, it is important to consider how they will be monetizing their content (if they will be doing so) and how your design decisions are likely to impact that.
We’re going to have plugin dependencies; at some point the core plugins won’t be included at all (maybe from v2 if we can test things well enough) as they’ll be installed if something else needs them.
As for monetization and support, we need people to write plugins and themes for CP. If we create a system that is hostile to their interests they simply won’t develop for CP.
I also prefer filters over weighting, they’re inherently less biased. And, they don’t promote gamification.
On extensible plugins being easier/harder to monetize. I suspect there are arguments for both. I fall into the camp that believes extensible plugins are probably easier to monetize. This is just an educated guess; virtually all of my plugins have been built to spec for bespoke purposes, so, I don’t have direct experience on which to rely. However, it seems logical enough…
Let’s say you had a client who needed functionality that was in the neighborhood of $100 to fully realize (ie, free plugin + paid extensions) - let’s just use WooCommerce as an example. Would you rather pay $100 and buy it a la carte and give the user just what they need, or would you rather buy a fully-fleshed-out Woo for $300 and then potentially deal with support or training requests for features (bloat) your client didn’t even need? It seems like extensible plugins would be the better choice.
On extensible plugins being easier/harder to support: I think extensibility helps. For example, if you develop an extension for someone else’s plugin, you’re expected to support it unless the developer specifically agrees to do so. Due to this tradition, it reasons that your plugin can grow in users and features without your having to take on more support activities.
My feeling on managing support (and you’ll see this in practice when I shortly launch my onsite plugin hub) is that plugin developers are best served when they get out in front of it. To me, this involves documenting the work, setting up an FAQ, providing examples…even all of the above…for every single plugin…even the tiny one-off utilities. For those who can’t be troubled to read the docs, they’ll probably send an email (and that’s fine)… I can quickly reply with a link to the relevant information, rather than feel pissy that they didn’t look at the very first item in the FAQ.
As far as I understand things, in CP we need to take “functions” out of core.
Core should be an infrastructure allowing things to work, functions should be in plugins.
Some functions are criical, like the ability to use XMLRPC or the blogging function with the commenting system and so on. Those important and vital features are defined core plugins for they are hybrids. They are so important that wp developed them in core, but we feel it’s a better choice to have them separated from it to allow for a better control (also what can happen if we allow for variuos commenting systems? Or editors? people will have choices, and control over what their site is).
That said granular control passes also from best practices like NOT having monsters like yoast seo, and jetpack. Jetpack is a spaghetti plugin willing to do too much. It has everything and its opposite. It’s just wrong IMHO for it’s not able to get in depth. you don’t have much control, they had to standardize to allow for all those things to be put together.
IMHO it was born to answer a particular question of an uneducated part of the market… at forst when wp was democratizing publishing for all, people would start a blog without knowning about plugin conflicts, fatal errors and the like. Jetpack is a big collection of features made in a way to avoid fatal errors for those “simple blogs” made by uneducated people. You installed wp, akismet, hello dolly, jetpack and yoast seo and maybe woocommerce and you were good to go without hassles.
IMHO CP should avoid this policy of feature rich plugins doing things superficially.
what i think is that we ca have many plugins doing one little simple thing, and also developers may charge for them (the model of it’s free ad will stay like this forever does not empower developers. Noone should work free. I know I want to be paid for my best efforts and gratitude does not pay the rent, why should a dev be different?).
So the issue is not weather it’s better having a free plugin with paid extensions or a big plugin or several little plugins.
the issue is we need to give value to devs. allow them to have plugins with extesions or single little plugins AND to benefit from their job.
That way devs will start developing for real profit and will naturally find giving user more control benefits them also, weather it’s by extending a simple plugin or having many singular plugins.
There is some nuance to that…
One needs to balance individual and community interests.
Having certain foundations available is what makes innovation i.t.o. open source possible.
No person can be a specialist in everything.
Open source is sort of like an informal joint venture.
Not just between the various dev-related persons, but also between the devs and pure consumers.
Pure consumers are likely testing your products for free, in addition to the marketing value their installations provide.
It isn’t fair to withdraw their access to it without proper notice.
Additionally, enforcement would be unattainable and therefore by its very nature unequal.
Let’s also note that “open source” does not mean that you are prohibited from charging for it.
I completely agree.
But I don’t necessarily agree about the mechanism for achieving this.
I would suggest that CP needs to find a philosophy which allows it to create a vibrant, monetized ecosystem while still adhering to the fundamental principles of open source.
Creating trust in a brand means behaving consistently with expectations.
If CP’s USP / coding philosophy is grounded in code without bloat, but there are very limited / no plugins / themes that adhere to that same philosophy, then the end user still feels the weight of the code bloat.
And they likely won’t know (or care) whether that bloat originates from the core or the plugin.
The product as a whole then fails to achieve its fundamental differentiation from its competitors (whose “feature-rich” proposition suddenly becomes more appealing to them).
What I mean is, let’s avoid the freemium phylosophy. The “you have to put your work out there for free to be noticed, then you may charge for additions in the future if you gain traction”.
Obviously we need to set coding standards, like no bloat. But if devs adhere to them they should be free to treat their involvement as a job, if they like. Being really free to choose to code for free or monetize. Not like in wp repo that clearly states only free plugins are allowed.
A directory allows us to accept both totally free and paid plugins. Users may filter their search results to show free plugins, paid ones or both.
This results in more control.
They do that for legal reasons (primarily), related to the fact that they host the content themselves and to avoid involving themselves in drawn-out ownership disputes later on.
You also should consider the impact on their enforcement costs if they allowed paid plugins.
Consumer protections legislation in various jurisdictions hold anyone in the supply chain responsible for refunds.
Localized versions add to complexity and costs.
It gets messy.
On the other hand, if it is free, people can’t ask for refunds
Not saying I would necessarily reach the same conclusions they did, just saying that that there were valid concerns that went into that choice.
It needs to be decided whether the directory / repository distinction sufficiently mitigates this, which from my understanding, is CP’s position, but I may be mistaken.
Which relates to my hesitation in compiling related documentation.
I know they had reasons for that, but what I am saying is using a directory based model allows us to do something different.
I think first we have to set rules about coding standards to be enforced for core, themes and plugins. then, we can enforce rules allowing us more freedom and control, like abandoning the freemium model for three definite options (totally free, totally paid or free with paid extensions).
To be noted that a free with paid extensions is not a freemium model IMHO. what I see as freemium is I have the full plugin features but limited (for example a newsletter plugin free to use up to 2000 newsletters sent then billing a specific amount for upper tiers)
That is not something I feel comfortable concluding.
I would like to see evidence of sufficient mitigation in that case.
The term freemium to describe this model appears to have been created only much later, in response to a 2006 blog post by venture capitalist Fred Wilson summarizing the model:[3]
Give your service away for free, possibly ad supported but maybe not, acquire a lot of customers very efficiently through word of mouth, referral networks, organic search marketing, etc., then offer premium priced value added services or an enhanced version of your service to your customer base.
I could find better citations, but freemium has always meant some free features and some paid features.
It has always been a core service / Value Added Services distinction.
While having a limited number of times that a particular feature can be used, can be seen in the context of freemium models, they are more analogous to free trials.
I always prefer voluntary adoption over enforced compliance wherever realistically possible.
I would posit that it is valuable to consider (right from the start) how an environment can be created where a particular philosophy (in this case, “no bloat”) is encouraged, rather than enforced.
I would prefer creating “buy-in” among plugin and theme authors (plus core contributors!) i.t.o. not excessively bundling services.
I agree with you that just having the intention to be different is not enough, what i mean is the two solutions (directory/repository) allow for different features and policies.
As to freemium, my distinction may be biased, I usually appreciate a completely free plugin that I am able to extend further with a paid add on, but I do not like when the plugin is a complete one based on tiers (you can optimize up to 100 images per week, then you need to select a plan).
As concerns enforcing, I am realistic. We may encourage people to follow a set of standards like the less bloat one, but we need to say we follow those standard first, and in a way it’s clear we strongly prefer those devs who follow them too.
and that is enforcing…
If we live coding standards to a simple declaration of intent and give the chance to devs to follow them or not, most likely there will be a group of devs who will be happy to follow and a mass of devs not following them cause they never did for other projects and following different standards for different projects may be a cost they don’t want to undergo.
So yes, it would be better to ecourage and them following the stadards without any level of enforcement, but it’s more realistic if we state a set of rules telling people to abide by them instead of giving them freedom not to.
Since I was tagged on this, I will say that having a directory rather than a repository mitigates our legal risk significantly because ClassicPress will then not be part of the supply chain. Someone who chooses to download code from a developer whose plugin is listed in our directory will then be making a purely private arrangement – often, a contract – with the developer, to which CP will not be a party.
I would also add that my question that forms part of the title of this thread, “How many plugins are too many?” was originally directed at someone in this forum who kept asserting that people should not use too many plugins. So I was asking her what she considered too many.
The question was essentially rhetorical, because the concept of “too many” plugins is completely misguided. Whether code takes the form of one plugin or many is simply a matter of human convenience. It doesn’t make any difference to the code itself. The things that matter are the size of the plugin (i.e. how much code), where and when it runs, and – above all – the quality of the code.
If the legal / liability risk and compliance costs are sufficiently mitigated, the next step would be to decide on a strategy to mitigate any potential reputational risk.
With regards to the “How many plugins are too many?” question, I should find a link to the thread and post it
I realize that the question was rhetorical and I very much agree that the concept of “too many plugins” is misguided.
The question mulled in my mind for a different reason, which is this:
The aim of the thread is to
So, in short, I would greatly prefer “many” plugins over
Who decides what constitutes bloat for my plugins and my users? My users do. Bloat isn’t the same thing to every person. The idea of discouraging bloat is a good one, but, legislating it away seems a lost cause that will be littered with personal interpretation and inequity. I think this is a case where our end users will make the decision about what constitutes bloat and make decisions to use our work accordingly.
If nobody wants to use bloated plugins, they will fall away from the ecosystem naturally. Thing is, users are very often willing to use bloated plugins because of the value they provide – just look at virtually every top freemium plugin in the WP repo; they’re bloated to the gills.
To clarify, the above is nothing to do with code standards; it is only in relation to breadth-of-features in any given plugin. I do support creating strict standards for code.
Maybe i’m wrong, but as I understand, to the premium authors we want to offer payment processing and have some commissions? If yes, we are in the legal binding. How tight, and how deep our responsibilities - this is a matter of the TOS.
first 
