Funding links in Clojars

[danielcompton]

It could be great to add support in Clojars for funding links. This would help maintainers show ways that people can support their projects. It could also be used by other downstream tooling to show you how to fund your dependencies.

Ref: https://mobile.twitter.com/martinklepsch/status/1167707490513018880, cc @martinklepsch

[martinklepsch]

Here's the reference for the POM structure: https://maven.apache.org/ref/3.6.1/maven-model/maven.html

It seems that there is a properties key at the top level that can hold any additional string fields. Maybe that would be sufficient although I can imagine that not all pom.xml building tools support this directly.

[victorb]

This would be quite a nice change to get in, as OSS is always in need more funding :)

Adding a top-level field for funding like what package.json does sound like a good beginning, which can be pointed to whatever URL at first (just like the homepage field), alternatively, have a allow-list with known sites for funding OSS (OpenCollective/Kofi/Patreon/GitHub Sponsors) that can be put there.

As a start, clojars can display the link at the project page, bit more prominently than the website. If/once projects start to use it more widely, it might be appropriate to suggest patches to boot/lein/clojure cli tools to display the links as well, either as you've downloaded the dependencies, or as a separate command entirely.

If this idea is still on the table to be implemented, then I'd like to take a stab at it.

What you think @tobias?

[tobias]

I agree this would be nice to get in @victorb. If we use the pom file as the avenue to report this, I think our only option is to define a property; we can't add our own tags to the pom since it has a schema that tooling may enforce.

Looking at GitHub's FUNDING file specification, they support services explicitly instead of a just a link, and support multiple targets within a service (multiple GH users, for example).

I can think of a few ways we could support this:

A property in the top-level properties element

This would require tooling changes to set this value in generated poms, and could support a url (or a sequence of urls with some separator character). This would support tooling showing the URLs, since it would be in the downloaded pom.

A GitHub-style FUNDING file in the uploaded jar

This may require tooling changes to include the file in the jar, or may be doable via the way resources are added, depending on the tooling. We would need to then read the file from the jar on the Clojars side, and we don't currently open jars, so there is work/risk there. This would support tooling similar to using a pom property, but would require tooling to open the jars as well.

A settings page in Clojars to add links

This wouldn't require tooling changes, but doesn't allow for the funding info to be in any of the downloaded artifacts. We could expose the funding information via the Clojars API that could be used by tooling.

This would be a bit of work, only because the Clojars data model has no concept of a project; we only have releases in the jars table, one per version. But it's not a big lift I don't think.

We look for a FUNDING file in the repository

This would use the scm information to get the URL of the repository, then try to get a top-level FUNDING file from it. We would then need to parse the GitHub FUNDING format. We could then expose this via the API as well.

Of these options, the settings page in Clojars requires the least coordination with tooling, but may not be the best solution. What do others think?

[zerg000000]

Clojars might not be the right position to support this.

1. for a package repository like Clojars, it is almost transparent to the users.
2. Clojars only can provide half-bake convention based support because Clojars cannot alter upstream specification.
3. It don't look like a good way to raise fund. Where does Clojars show funding information? is it effective?
4. It is not only benefits, but also some drawbacks.

A better place to start would be maven/deps.edn/leiningen, project repository (github), or documentation (cljdoc) perhaps? At least we need to get upstream noticed about this issue and respond accordingly? If they support funding information we can think of how to help in the process.

Reference

rust-lang/cargo#8846
https://internals.rust-lang.org/t/cargo-thanks-fund-tools/16567/6

[victorb]

for a package repository like Clojars, it is almost transparent to the users.

You mean you think people don't usually visit Clojars but get the package coordinates from somewhere else? I'm not sure about that but I also don't have any concrete data about it. I only know my own usage pattern which is usually to find the library directly via Clojars search, or via GitHub repository and then clicking the badge (which leads to Clojars) to find the coordinates I want.

Clojars only can provide half-bake convention based support because Clojars cannot alter upstream specification.

That's probably true. But I'm not sure how we could convince any of the tooling to add support for new data/a new field if there is no usage of it anywhere. Bit of a chicken & egg problem I guess.

It don't look like a good way to raise fund. Where does Clojars show funding information? is it effective?

I'd say that's up to library authors to decide, if it's good or not. Main point would be to allow authors to show how users could fund them, if the authors want to, not in any way force everyone to use it.

I can see a couple of different places we could put the funding information. Right above the coordinates via a new section. Inside the #jar-info-bar which shows the link to clj-doc. Or at the sidebar on the left side, similarly to where the website is displayed.

It is not only benefits, but also some drawbacks.

Is there any specific drawbacks to Clojars support thing or you're thinking in general that Open Source should have nothing to do with money?

I can definitely see some points in the latter, but I'm not sure Clojars is the right place to make a stand against that. Simply allowing authors to make the choice themselves feels like a good thing. With the first, I'm not sure I see any drawbacks with letting authors add another URL specifically for receiving donations for their OSS work.

A better place to start would be maven/deps.edn/leiningen

As mentioned either, I think (in the case of tools like lein/boot) we'd need to add support for it in Clojars first, then we can contribute patches to lein/boot to add support for it. Otherwise there is no point in getting any patches accepted in those tools, if the data is not used anywhere.

project repository (github),

This is already supported by GitHub. Adding it to Clojars would just bring some more visibility to it.

documentation (cljdoc)

Yeah, that would be really cool to have as well as in Clojars. The more the merrier :) If it doesn't already support it, should definitely suggest it in their issue tracker. I do know they support links to the GitHub repository already, so maybe a funding URL wouldn't be too much trouble to add.

[zerg000000]

let data speaks

[tobias]

@zerg000000 I'm not sure how relevant that data is, given that we aren't trying to solve the problem of how an open source library maintainer can publicize funding, but specifically how a Clojure library maintainer can.

As discussed above, GitHub already has a way to specify funding, and I think it is fine for us to follow that lead. I agree with @victorb that the more places we can show funding within the community the better, so I'd like to move forward with this if @victorb is still willing to implement it.

[zerg000000]

As someone building business on top of Clojure and its ecosystem, I wish to make clojars a very robust and stable infrastructure. That's my priority. It is certainly more than welcome to have someone to add more features. But I also offer my 2cents from my point of view for reference only.

As I mentioned, if we introduce something that is not supported by upstream, library maintainers needs extra effort to implement and have the risk to create confusion and inconsistent. If it is a success, everyone follows and upstream feels the pressure and update. If it is not success, basically, we are wasting maintainers' time and create a feature that we needs to maintain for quite a long time if it is not forever.

I think the jndi lookup feature in log4j project is a good example of the risk of why not approach. The consequence could be quite disastrous and needs the whole ecosystem to pay off the price.

If we really want to do something, even it might not be so effective. We should be at least

1. reduce the effort of adaption/abortion, so that in fail case, maintainers and us could just drop it without wasting a lot of effort. e.g. reading from github repository directly, instead of including FUNDING.yml in artifact?
2. having discussion/PR with upstream before actually push it on street.
3. Adding measurement of the change, so that we know we should do more / refine / do less / drop it.

Or even simpler, just make a new tool that extract funding info from project dependencies like
https://internals.rust-lang.org/t/cargo-thanks-fund-tools/16567/6

To me, a list of CVEs of a version of an artifact / no maintainer notice which would drive me to fund/contribute to a project.