This collective is not officially affiliated with the Apache Groovy project (or the Apache Software Foundation) but aims to support endeavours related to that project. The ASF values community integrity and vendor independence very highly. As a general principle, it doesn't accept "cash for code" so that individual cash payments can't force contributions into a project which aren't aligned with community consensus.

We encourage you where possible to contribute to Apache Groovy in the traditional ways, such as writing code or documentation, by creating issues, or by being involved in discussions. We also recommend that you consider sponsoring the ASF. If however, you aren't in a position to assist Apache Groovy via the traditional mechanisms, this open collective allows you to assist development and promotion of the language in complementary ways.

This collective does accept cash contributions and uses those to support the Groovy community in an unofficial capacity. This is intended to augment the activities of the official project rather than overlap in any way. The collective may choose to use funds to:

develop features and fix bugs for Apache Groovy (see disclaimer below)
sponsor outreach activities (e.g. educational events in cities which might not otherwise be visited by the popular conferences)
cover travel expenses to promote Groovy (when other sources of travel funding aren't available).

As a general principle, we try to direct funds as best we can to meet the desires of contributors.

Disclaimer

Any code or documentation produced with the assistance of this collective must be submitted to the project in the normal way and are subject to normal community vetting.

Plans

Some of the developments we may be able to accelerate through this initiative include:

Enhancement of the Groovy static type checking system, e.g. support for @Nullable, better support for generics type, bug fixing(GROOVY-8409, etc.)
Re-write of the Meta-Object Protocol (MOP) for Groovy 4.0
Support for JEP 325 Switch Expressions
Improvements to JDK module support (JPMS), e.g. writing module descriptors in Groovy
Native default methods in interfaces (currently implemented as traits)
Improvements to supporting tools, e.g. Netbeans/Eclipse/IDEA IDE support and or Maven/Gradle plugin improvements
Re-work GPars to account for recent developments on the JDK and overlapping technologies like Kotlin coroutines and AKKA
or suggest your own priorities

Funding priorities

At the moment, we expect most code contributions to the Apache Groovy project will still come from normal involvement in the project, i.e. will be contributed for free or by (partially) sponsored contributors. This collective will focus on giving additional emphasis to particular activities that aren't proceeding (or not proceeding quickly enough) under the steam of the project's normal resources. This involves funding or subsidising particular agreed upon activities. As a general rule, if you want to be involved or submit an expense, please get in touch. We generally only accept expense submissions for previously agreed activities with a well-defined outcome.

Friends of Apache Groovy