Recently, we submitted a template engine plugin called Willow – which we use on our projects to the WordPress plugin repo – but it was quickly rejected – the following reasons were given:

Your plugin has been rejected because we no longer accepting frameworks, boilerplates, and libraries as stand-alone plugins.

To explain the terminology here:

Framework/Boilerplate: a template from which more code can be built
Library: requires other plugins or themes to edit themselves in order to be used

We require that plugins be useful in and of themselves (even if only being a portal to an external service). This means that a plugin should either be installed and be fully functional, or it should have some administration panel.

When a plugin requires either the plugin itself to be edited to work, or can only be used by writing code elsewhere, it ceases to have as much a benefit to end users and is more of a developer tool.

While there are many benefits to frameworks and libraries, WordPress lacks any plugin dependency support at this time, which causes a host of issues.

The parade of likely support issues include (but are not limited to):

not recognizing the need for the library or and thinking they’ve been hacked
not properly forking the boilerplate and editing it in place, resulting in updates erasing code
not recognizing the need for the library plugin, and thus deleting it (causing others to break)
updating the library plugin separately from the dependent plugins, leading to breakage
updating a dependent plugin without updating the library, leading to breakage
different plugins requiring different versions of a library plugin without proper if-exists checks

We feel that libraries should be packaged with each plugin (hopefully in a way that doesn’t conflict with other plugins using the libraries). At least until core supports plugin dependencies. Frameworks, in and of themselves, have no place in our directory as they are non-functional templates.

They offered me a chance to argue my corner and show why this plugin should be hosted – which I did to the best of my powers – I argued from standpoint that this amounted to discrimination against advanced users – who would be forced to either bundle their frameworks into other plugins, making them harder to update or that we would be forced to write hacks to get our software into the WP update process – which seems wrong on many levels.

And, while the plugins team expressed some sympathy – nothing that they all used frameworks and the likes themselves, they were unmoved by my high and might rhetoric and the plugin remains rejected…

Of course, I can continue working in the way I have been until now – currently we use the Github updater plugin to integrate our public and private repos from GitHub into the WP updater – but it IS a hack – and it’s not seemless.

So – to my question – and please moderators, don’t delete this as a "too vague / opinionated" question – as this really is aimed at understanding how other developers use WordPress and has benefit both to us and I imagine others who have faced this same situation.

The question is – how should we host our own public plugins – for example on a 3rd party repo like GitHub – and make them easily available to find, install and update – in a way that is as native as possible to how they might work if they were hosted on wordpress.org?

Sub question might be about the relative pros and cons of bundling these "frameworks" into other plugins / themes – this feels wrong to me, especially considering WordPress’s lack of dependency management – but I would like to learn if this is viable and even recommended.