Thanks for your work on Ignite’s repos and this thoughtful suggestion, but I am a hard no on this and here is why.
- Openfire, by default, should continue to work to reduce the security exposure/vulnerability of the software. For example, the recent change to restrict the admin console access to localhost only by default.
- The search plugin’s inclusion was a one-off due to some stock openfire requirement for it to be present, IIRC.
- Bundling plugins with the installer creates some thorny install time logic issues. For people that upgrade immediately with releases, it would likely be no issue as the bundled plugin would be the latest release. But if you have a properly testing, QA, staging environment, it may take months to bring openfire to production. When you do, you may have an installed plugin that is already newer than what the openfire bundled version provided.
- We generally want to keep releases of Openfire and plugins asynchronous. If we bundled
HTTPUploadand some vulnerability got fixed it in, would we need to immediately provide updated Openfire releases for all releases that bundled that plugin? - We generally have just one developer of Openfire and a number of us that just hack at the edges of the software. We don’t have the dev resources to support what you propose. Bundling plugins ends up providing a “contract” to users that this plugin gets significant amount of love to have as few bugs as possible, as with Openfire. We don’t want to give that impression.
- Openfire is used in a number of very restrictive environments, an installer would additional plugins would create a problem for these folks as they could not use the installer, but would have to do post install scripts/procedures to remove the plugins.