Following on from PSC discussions, I would like to update the documentation to highlight the purpose of community modules. Would these changes be acceptable, or how can they be improved?
These are NOT part of the GeoServer project, have not passed the minimum thresholds (test coverage, registered maintainer, etc) for promotion to an official extension and CANNOT be included in the monthly releases or docker builds until a dev/company is prepared to sponsor/maintain it. However, they are built along with the nightly GeoServer builds, so you can download and play with them, just not in production.
We list these purely as a service to the community to raise awareness of interesting add-ons to support, if there is sufficient common interest
If you want to use a community module (in production), YOU need to arrange funding to a) promote it to an official extension (passing tests, etc.) and b) maintain it going forward
An alternative to this is for YOU to build your own releases which include the desired community module, which is always an option, seeing as GeoServer is an Open Source project, and you are free to do with it what you want.
But they definitely are part of the GeoServer project, just not part of the release. They don’t match the minim conditions for allowing general consumption by normal users (the adventorous/enterprising user can find them in nighly builds)
Here we have to be careful about what maintenance means. Nowadays “maintenance” only means “will answer questions and review pull requests”.
Let’s not give anyone the idea that they can ask and get fixes for free, it does not match reality.
Freedom in open source also means that someone can take the code and binaries and do whatever they want with it. I’d word it as “we don’t believe this is production ready”. But besides this, you’re free to do whatever with it, as the GPL prescribes.
I’d also reiterate the idea that it would be nice if a module documentation would list the major fallacies of the module itself. E.g.
For COG, nowadays I would put something like “Not routinely tested against the actual cluods, we don’t know if the packaging works properly, inefficient against very large COG files, if used against a TIFF that is not a COG it may make the server go OOM”).
For OpenID connect, I would say something like “not security reviewed, we also noticed the module often needs changes to work against new OIDC servers or less common OIDC configurations”.
It’s also fine to contact the developrs behind the module and check what would it take (financially) to push the module up to production status. The user does not need to maintain it (it’s a possibility though).