I would also add that while names, affiliations etc. change slowly over time, companies and individuals supporting a project (and possible funding links) change much more quickly. With any pom being immutable, one will end up with a large set of outdated information that can not be changed.
Having a link in <url> ... </url> to a web page and have that information being there seems to be a more future-proof way to do that. -h On Wed, Sep 3, 2025 at 11:31 PM Hervé Boutemy <[email protected]> wrote: > funding: complex topic, no silver bullet, require vast and diverse > contributions... > > adding a few pure conventional property names in pom.xml is an easy first > step: we already did such conventions on small things (like default > encoding, activation of Reproducible Builds, etc...) > each time, it just required a good doc in a Wiki to have a chance for > people to learn about the convention > and no need for global form of consensus to start: it's "just" a convention > no need for strong global consensus either on creating a plugin goal that > uses the convention > > the only strong consensus would be if we want to add by default a one line > summary independently of a plugin: we're not there > > will it solve everything? no (as shown by npm case), but it's a step and a > way to try to move softly instead of just complaining > so could be a good tactical try > > > at wider level, funding/support clarifications is part of the use cases > for SBOMs, even if not yet concrete: other use cases for SBOMs are in > progress and proven as not so easy to make a uniform approach for everybody > > > I'm in for a small step in the right direction: > - documentation for such properties (ideally with references of what has > been done in other ecosystems: npm comes to mind, other cases welcome) > - new goal on some plugin > this will also permit to start listing example of funding examples seen > here and there > > it won't solve everything, nothing can solve everything > it's simple, concrete, pragmatic > > Regards, > > Hervé > > On 2025/08/22 08:52:06 Olivier Lamy wrote: > > Hi, > > While having a play with npm recently, I came across this message: > > 117 packages are looking for funding > > run `npm fund` for details > > > > That got me thinking, why don’t we have something similar in the Maven > > ecosystem? > > > > Plenty of the artifacts published to Maven Central come from > > individuals who’d probably appreciate a small donation (a bit of “beer > > money”), or from companies that provide professional or commercial > > support for their open-source libraries. GitHub already offers a > > funding button, but in the Maven world, we don’t help surface this > > sort of information. > > > > So here’s an idea: what if projects could include > > documented/formalised metadata in their POMs that Maven core and/or > > plugins could use? Since we can’t change the POM structure itself, we > > could start with some standardised properties, for example: > > > > <properties> > > <support.commercial.0>URL</support.commercial.0> > > <support.eol.0>DATE</support.eol.0> > > <support.security.0>DATE</support.security.0> > > <support.commercial.1>URL</support.commercial.1> > > > > <funding.url.0>URL</funding.url.0> > > <funding.url.1>URL</funding.url.1> > > </properties> > > > > We could then imagine new goals such as: > > - dependency:fund > > - dependency:support > > > > And, just like npm, Maven could finish the build with a simple summary: > > > > X artefacts have commercial support or are looking for funding > > run mvn dependency:fund or mvn dependency:support for details > > > > To be clear, this isn’t about Apache Maven requiring the metadata, but > > rather about encouraging a general convention for artifacts in Maven > > Central. > > > > What do you reckon? > > > > Cheers, > > Olivier > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
