🌐 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

Beta Give feedback

1. Initial Proposal, based on feedback
2. Legal and IT approvals
3. Initial setup for a few pilot projects
4. Hosting and community governance guidelines
5. Release Automation and templates
6. 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.

[oleg-nenashev]

@lacasseio sorry, I dropped the ball on responding.I actually had it in the drafts :(

The Gradle Plugin Portal is definitely a part of the longer-term vision for this initiative. As you sais, many features can and should be implemented there. In particular, we had a discussion with @ljacomet and a few stakeholders about updating the plugin portal UI or... maybe even replacing the user-facing bits by a generic open source plugin marketplace engine. There is even a pending idea about reusing bits of https://plugins.jenkins.io/ and a few other portals in a new open-source project for that. For backend tooling and hosting, the current portal implementation is here to stay.

To address your comments about enforcement, there is no goal to enforce anything or to force migration to the new organization by providing org-only features or preferential threatment. The Community Hub does not even have to be owned by Gradle IMO. It could be another entity, e,g, CommonHaus established recently.

Below, there are comments on a few points:

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.... 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.

Nothing is going to be forced. But yes, I consider offering reusable automation on GitHub Actions for those maintainers who want to adopt it. All auutomation will be supplied via reusable components that could be used within the suggested GitHub organization or not: GitHub Action Steps, Gradle Convention Plugin, etc. But it is totally up to plugin maintainers to adopt them or not

That solution is better and more applicable to the entire ecosystem than gatekeeping the health score to only plugins on the central hub.

It will not be gatekeeped to a single GitHub organization. As long as metrics can be collected from the plugin portal (ofc needs API) or from repository (e.g. GitHub API), there is no dependency on a single organization. In Jenkins and in R.I.P. LibreCores, metrics were collected in a more or less agnostic way.

All repositories can join, with a low bar for doing so.

This point describes how the plugin portal works at the moment.

Plugin Portal does not manage source code repositories. For the rest, indeed some transfer features will need to be implemented there

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.

There is no way to ensure sustainability of this solution in GitHub organization (e.g. admin might be removed). And for individual account where many plugins live now, there is just no way to do that. Organization transfer makes it easier.

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

This point still describes the plugin portal.

Yes, and it is the Plugin portal which is definitely in the scope in longer run
E.g. https://plugins.jenkins.io/gradle/ for example

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.

Yes, and hence remains despite the introduction of a new entity that does some consolidation

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.

I totally support that. And it is on my radars too

[JamesXNelson]

I love the idea of this, but I kinda hate the name gradliverse. Really, the i seems out of place. Do I pronounce this "gradle-ee-verse" or "gradle-i-verse"? The extra phoneme in the middle for both feels ...clumsy.

Alternatives name suggestions in increasing order of personal preference:
gradlverse
gradleverse
gradlehub

[JamesXNelson]

also, as a completely random third party interjecting where I have no authority whatsoever... I think oleg's idea is important outside of the lens of "core gradle-maintained ecosystem / plugin portal".... for plugins that have many users but a burned out maintainer, the only future for that plugin is a fork, often done at the whim of some random helpful person (who hopefully isn't going to hijack a popular plugin and then insert vulnerabilities into it).

It doesn't matter if improving the official plugin portal would make things functionally better, the issue I believe is that a community-managed org/hub would be able to absorb the abandoned-but-popular plugins with some oversight and community involvement / official process to move from individual-maintained to org-maintained, without requiring every abandoned plugin to create its own org / standards / tooling / etc.

A plugin with a group id like com.gradlecommunity or com.gradlehub would confer a slight bump in credibility over com.mynamehere, and I think that credibility would be well-deserved, since a project maintained by a community org actually does have more oversight than "random person on github has a popular plugin they do whatever they want with".

...so.... I don't think this is something that can be fixed on gradle's end / with better plugin portal features. It doesn't matter how well the plugin portal works if the person maintaining the code decides to spend time with their kids instead of maintaining a popular hobby project. Even if you can transfer ownership of plugins on gradle's side, it still requires a new maintainer in github, and having that new maintainer be an org with some standards / rules / official processes is always going to be better than "well, @coolDude743 has a fork that seems active, guess I'll run their code on my intranet".

Basically, I think this is most relevant on the github side of things rather than the gradle side of things.

[oleg-nenashev]

I love the idea of this, but I kinda hate the name gradliverse.... The extra phoneme in the middle for both feels ...clumsy.

This name is not finalized, and feedback is more than welcome :)
FWIW my mother tongue is Russian, and there "i" or another vowel separator would be rather expected in such a name

A plugin with a group id like com.gradlecommunity or com.gradlehub would confer a slight bump in credibility over com.mynamehere

It is right. At the same time Gradle has no notion of changing Group IDs like Apache Maven has with Relocation JARs, or like other plugin ecosystems handle on their own (e.g. Jenkins plugins that operate solely based on ID). So changing the groupID will be a breaking change as of now, but I agree that for some cases it will be necessary.