🌐 Community Hub for Gradle plugins and integrations

[oleg-nenashev]

I am interested in building a community hub and community-governed GitHub organization that would offer a home for plugins and other vital component, whose maintainers who want to ensure continuity of the plugins. I call it Project Gradliverse (inspired by Quarkus's Quarkiverse), but this is not a finalized name.

From the implementation standpoint, It would be a standalone open-source GitHub organization that:

1. Hosts repositories and offers various automation to simplify the life of maintainers: CI/CD, integration testing, release flow, changelogs, documentation hosting
2. Encourages the best practices for plugin development, ideally by offering a kind of plugin health score and recommendations/certifications for the plugins following the best practices
3. Modeled in a confederation way. All repositories can join, with a low bar for doing so. Also, maintainers can leave the organization or archive the projects if there is a consensus to do so
4. Has an open and transparent governance model that offers the maintainers almost full powers but defines a transition process should the maintainer want to move one or become inactive. It is somehow aligned with how Jenkins governance is defined and how we support maintainers
5. Integrates with existing ecosystem as much as possible: the Gradle website, community documentation, etc., etc.
6. Remains vendor-agnostic and open to collaboration, including adding maintainers from any organization. The governance model is focused on individuals

Potential Pilot projects

• Shadow Plugin for Gradle - Future home/support for Shadow? GradleUp/shadow#908
• Projects from Gradle core should there be a consensus to detach them
• // Suggestions are welcome!

Discuss

• #roadmap channel on the community Slack

References

• Quarkiverse - similar hub for Quarkus
• Jenkins - the main jenkinsci organization is built in the same way
• Gradle X - A collection of high quality Gradle plugins - some recommendations and best practices can be used from there, and maybe Gradliverse idea could be merged into this project
• GradleUp - Also a collection of Gradle plugins

Scope

### Tasks
- [x] Initial Proposal, based on feedback
- [ ] Legal and IT approvals
- [ ] Initial setup for a few pilot projects
- [ ] Hosting and community governance guidelines
- [ ] Release Automation and templates
- [ ] Public Announcement

[3flex]

Another pilot candidate: https://github.com/ben-manes/gradle-versions-plugin

I won't tag him here but I recall Ben saying previously that this should have better support from Gradle directly. This seems like a good middle ground.

[lacasseio]

1. Hosts repositories and offers various automation to simplify the life of maintainers: CI/CD, integration testing, release flow, changelogs, documentation hosting

I'm generally not a massive fan of point number 1 because it hides the underlying problem with project automation, which is the lack of "composable automation" for projects. To me, the real win is to offer a space where plugin developers can contribute to plugins that help develop plugins, which is one of the goals for Gradle Plugins. Despite the initial idea, the practicality of this goal is quite poor as there are so many possible tools/CI/etc. to integrate with. Forcing developers to use particular technologies is where most projects go to die. Everything listed could be done via plugins instead of a central hub. The central hub could also create an unwanted division where plugins in the central hub are perceived as "better" than the other plugins.

2. Encourages the best practices for plugin development, ideally by offering a kind of plugin health score and recommendations/certifications for the plugins following the best practices

While working at Gradle, the discussion was about offering developers access to a health-score linter plugin to check their plugins before submission. Upon submission to the plugin portal, the same checks would be made to score the plugin on the portal. That solution is better and more applicable to the entire ecosystem than gatekeeping the health score to only plugins on the central hub. This point also lacks empathy towards private plugins (in companies) that can't submit their plugins to a central location (for obvious reasons) but would still want/need a health score to guide the internal maintenance of their plugins.

3. Modeled in a confederation way. All repositories can join, with a low bar for doing so. Also, maintainers can leave the organization or archive the projects if there is a consensus to do so

This point describes how the plugin portal works at the moment. Each plugin has (or at least should enforce) a link to the repository where the code lives. The barrier of entry is very low; for example, there are example plugins that made their way. The archiving could be made clear on the portal via some process. The transfer to new maintainers could also be made easier (instead of plugin portal requests).

4. Has an open and transparent governance model that offers the maintainers almost full powers but defines a transition process should the maintainer want to move one or become inactive. It is somehow aligned with how Jenkins governance is defined and how we support maintainers

That would be great, but I believe it can be achieved via a different process. For example, projects that agree to
the governance have to invite a special GitHub user that Gradle maintains to hand off the repository to another maintainer. However, adding "governance" to plugins may also create an unwanted "governance-agreed" vs "non-governance-agreed" plugin division, which would be counterproductive to the community.

5. Integrates with existing ecosystem as much as possible: the Gradle website, community documentation, etc., etc.

This point still describes the plugin portal. A better alternative would be to introduce a new artifact that can be submitted alongside the plugin, which includes the documentation, site page, etc. However, there are times when the plugin documentation may group multiple plugins. In those cases, forcing plugin authors to conform to specific documentation formats may be too restrictive. On top of this, it can be risky/damaging to Gradle brand to allow low entry to the central hub and allow integration into existing Gradle resources such as the Gradle website. Not every maintainer keeps a high level of security, offering an interesting attack vector.

6. Remains vendor-agnostic and open to collaboration, including adding maintainers from any organization. The governance model is focused on individuals.

The current state of the community plugins is already vendor-agnostic, letting all maintainers use whatever they want.

Proposition

As mentioned earlier, the effort would have a bigger impact if the proposed central hub focused on improving the plugin portal. It's already an index of all community plugins. Most features of this effort would nicely integrate into the portal and be discoverable by existing users without extensive communications. The biggest issue with Gradle plugin development is the lack of composibility inside third-party repositories. Within the Gradle codebase, plugin development works great (been there). But as soon as we step out, there is a huge lack of support. Centralizing plugins takes the easy way around the core issue. We should spend more time solving that issue instead of working around it.