I spoke with Jarek at Community Over Code Conference EU last week about an interesting policy Airflow uses to manage their ecosystem of providers. [1] In short, they have policies for accepting, maintaining, and removing providers based on various constraints. The general approach seems like a good inspiration for how to potentially handle acceptance and removal of plugins. For example, integrations with OSS projects require appropriate integration tests that can spin up the underlying software being integrated with. For integrations with proprietary services, the service provider has to maintain a test suite along with publishing test statistics and such to stay valid. When providers (or plugins in our case) start to fail tests or similar problems, if they’re not fixed by the contributors or experts from the community, then the provider is disabled in future releases until someone fixes them.
While I think we can adapt the Airflow guidance to Log4j, we will likely have some different requirements. I think this would help a lot in determining when and for how long to support plugins that involve third party dependencies. [1]: https://github.com/apache/airflow/blob/main/PROVIDERS.rst
