If that is not possible, it would be nice to have an open-source way of letting people host their own registry. The Web should be decentralized. It is paramount for freedom and a less risky future. Do you imagine the damage that can be done if the WordPress.org API registry gets hacked and goes rogue?
I believe this project is a great opportunity for us to make a difference. The open and self-explanatory API spec makes it a project where our contributions are truly valued and integral.
If there are multiple implementations, some can also introduce the concept of secure releases with signed ZIP files, shifting the trust from the registry owner to the package maintainer. Although, this is just a thought that lives free in my head since I asked this question in Paris in 2017 (in a WordCamp)
PS: I understand the recent issue with WPEngine, and I'm with Matt on the debate; running WordPress.org is not cheap, and CPU time and bandwidth are associated. Although the software is free (as in freedom), the infrastructure cost is not Free (as in free beer). Profitable companies and any serious organization should run their registry with trusted plugins, not delegating the trust and costs to a free service such as WordPress.org.
While not end-user friendly, a lot of professional WordPress development had long switched to Composer which is a baseline PHP solution now and is a lot more flexible about both consuming packages from different sources and hosting your own.
Most importantly that can be done by Composer externally, independently of WordPress core. Which had always been hostile to idea of alternate infrastructure.
So, in my opinion, people who care professionally would just rather use Composer than get in a (losing) fight with core, again, about making it more friendly to hypothetical new infrastructure that doesn’t exist and needs to be built (official repositories aren’t open source).
I wrote about the need for this and the plan going forward: [https://www.reddit.com/r/Wordpress/comments/1frd37p/its_time_to_solve_the_singlepointoffailure/](https://www.reddit.com/r/Wordpress/comments/1frd37p/its_time_to_solve_the_singlepointoffailure/) And you can follow progress at [aspirepress.org](http://aspirepress.org) TL;DR – we’re about a thrid of the way there.
Doesn’t this mean users would have to submit plugins to both?
I think an open source solution would be great. Agreed, I’ll start on something. I’m better at java than php, so it’ll most likely be a java based version. Very good for multi-threading
[wpackagist](https://wpackagist.org/) is 100% open source, so you can run your own wpackagist mirror if you like. Or just use the existing one, its infrastructure is backed by github. Next step I think is to write an implementation of the api.wordpress.org backend backed by composer, as well as scripts for publishing directly to a composer repo instead of wordpress.org (using any vcs composer understands, not just bloody svn).
Maybe just move it all to packagist at some point and live in the wider PHP ecosystem.
I code a small solution plugin today: Easily Install and Update WordPress Plugins from External Servers.
It allows you to install and update WordPress plugins directly from external servers — like GitHub or private repositories — without relying on the official WordPress infrastructure.
Check out the demo video where I show how to install and update plugins using this plugin: [YouTube Demo](https://www.youtube.com/watch?v=yObVOO1x9A4).
Plugin [https://github.com/algorithmspatterns/remote-plugin-manager](https://github.com/algorithmspatterns/remote-plugin-manager)
**Please note:** This is a **very early version** of the plugin, so there may be bugs or features that will be improved over time. I’d really appreciate any feedback or suggestions to help make it better!
i built one years ago. it’s on GitHub. i imagine it would need updating but it worked. https://github.com/norcross/reaktiv-remote-repo
Isn’t this the idea behind composer?
For the signing issue you might just want to start with like a sha256 or sha3-256 integrity hash and make the signing optional, so we can really basically check plugin + slug + version for integrity, and if there’s a signature as well, then you can also do authentication of the author.