Jody, I think you have a tendency to make things more complex than necessary…
Community modules are a well established concept in GeoServer, citing from the documentation:
Warning
Community modules are generally considered experimental in nature and are often under constant development. For that reason documentation in this section should not be considered solid or final and will be subject to change.
Note
Unlike the official extensions, these modules are not released and stored on SourceForge when an official GeoServer release is produced. As a consequence, using a module built against the nightly build of GeoServer with an official release won’t probably work.
If you need a community module for an official release, the only way is to build it with the sources of the GitHub tag matching the release.
Also, community modules are already being distributed, otherwise nobody would give a damn about them. We get funding to push them forward because people can actually use them, otherwise nobody would care.
Now, docker provides a different way to download things and people might just be ignoring the wealth of warnings and docs we have built around community modules to warn people… docker users need to be communicated in a way they understand, and that would make the realize what they are doing… the faint of heart please stop reading here because I’m going to say it: “non repeatable deploy”!.
The way the official GeoServer docker image is setup means playing russian roulette with the deploy the moment a community module steps in:
- If a nightly build of both GeoServer and the community module are deployed toghether, they are at least from the same code base, but one is exposed to all the changes happening between one “docker run” and the next. For extra fun, if it’s a cluster, it means running different code in different nodes. Also for reference, GeoServer receives around 2 new commits per day.
- If a release is deployed with a community module, then the core is stable, but the community module is new at every deploy, with a distance between the two that grows over time.
On top of that, nightly builds of older series get eventually removed, so it is guaranteed that after a few years that one deployment will be bricked.
Just have them read this when they look for a way to deploy community modules, and then let them decide what to do. Hopefully that will make someone bend towards shelling out some funding, or developer time, to get the module they need in extension. It has to be in this order, “I verified I need it, it’s part of my deployed infrastructure and it was working, it’s then worth spending money on, rather than spending redoing the infrastructure with a different product”. Make them choose between two ways to spend money, that they have to spend anyways.
Then funding finally shows up, rather than just telling developers they should be doing this or that on a Sunday, for free, for some stranger in urgent need, instead of spending time with their family or getting some rest.
We don’t need new rules for semi-supported community modules, we just need the have the user base aware of what they are getting themselves into.
Cheers
Andrea
