Add financial support data to projects

[BenJam]

Thinking about how to prioritise support for well-used open source projects it is common for users to butt up against a problem: 'does this project already receive financial support?'.

Answering this question will enable organisations to better prioritise and distribute funding, raise the issue that important projects lack financial support and lead to some interesting research.

[BenJam]

moving past motivation and into implementation:

approaches that we can pursue here:

1. Indexing content from existing platforms (open collective, gratipay)
2. Allowing maintainers to 'claim' a project and adding data themselves
3. Allowing anyone to add financial support data themselves and gaining social proof somehow.

thoughts welcome.

[andrew]

First thing that comes to mind is that we'll need some measure of freshness to this information, if the funding for a project has been used up and it no longer has any financial support, our records should at least indicate when we last checked up on the project, for a first pass we can use the timestamps for when the data was created/last updated.

Then that can create a meta-list of projects to re-check their financial support status and update if required, when the info is available via a platform like open collective or gratipay, some of that can be automated in the future.

[BenJam]

I think this exposes the thing that we need to split: individual one-off funds versus repeating funds.

Thinking more generally about the kinds of support a project receives:

• indirect (employment) will account for 95+% of support and will be repeating
• direct (donation, sponsorship) will account for ~5% (gueess) but ultimately we want this to grow

I don't think we should consider anything that is about 'in kind' support re. hosting/services etc.

There's also an open question about self-generated revenues through product sales, services, licensing, consulting etc.

[BenJam]

I think we also need to draw a line somewhere on advertising too.

Could 'company X supports project Y' be a positive thing? Potentially. If we want more companies to support individual maintainer/contributors on a project. Then adding something to that effect could drive companies to do that. Does the fact that company X supports project Y mean anything to our users? Possibly. A project supported by bigcorp that isn't a key part of their business (think Facebook and React) is riskier (meaning the support could be pulled) than a project supported by mediumcorp that is a big part of their single product (think Shopify and Rails).

[andrew]

Another facet (that we might want to ignore for now) is going to be the support for individuals that isn't tied directly to a project, like https://www.patreon.com and to a lesser extent the bug bounty sites like https://www.bountysource.com and https://gitcoin.co

[BenJam]

I would say that Patreon is in the same bucket at Gratipay/OpenCollective and we should treat it that way for now (even if they would rather be the support engine for 'creatives' lol).

Bounties are a bit different. They could either be the product of other financial aid — the maintainer has some funding and will publish a bounty on work they cannot do, or direct funding from a company that may/may not also pay contributors to work on a project.

I'm a less comfortable about bounties as they might not actually lead to any sense of financial support for the project: A bounty an be posted by a company, contributed by a mercenary contributor and be pushed to a project without a thought for the community, sitting there in a branch/PR for an unpaid maintainer to pull in and support ad infinitum 🙈

[andrew]

If someone on patreon is getting $600/month and works on 3 different projects, how would you split that?

[BenJam]

Good point. I'm glad we started talking this through before diving in 😅

[andrew]

For a first pass, I'd skip that edge case, there are lot of patreon accounts that are focused on a single bit of software.

Another wrinkle might that the funding goes to an org which has a number of repos (and a repo can have a number of published libraries), for example https://github.com/vuejs, which has https://github.com/vuejs/vue as the main project but there are a number of others like the vuejs.org website https://github.com/vuejs/vuejs.org, which you can imagine get's worked done from the same org.

The vue one is quite interesting as it has both an open collective page: https://opencollective.com/vuejs and evan is funded via his patreon: https://www.patreon.com/evanyou

[BenJam]

As a first pass I think indexing everything we can would be great alongside adding a way for users to add their own data. The 'claim' a project could be useful for things other than this ticket. Of course we then get into how to claim a project 🤔

[andrew]

Do you think we should be indexing things like opencollective "collectives", gratipay "projects" and patreon "creators" as a separate entity, which can then be tied to a collection of orgs/users/repos/projects or attaching those things directly to one of those?

Connecting them to orgs/users makes sense to me as it's closer to the humans than the published artifacts.

You also mentioned there being a difference between recurring and one-off payments, but we'd still need to check if the recurring payments hadn't be changed/cancelled on a regular basis.

[xdamman]

Just append .json to their open collective url: https://opencollective.com/vuejs.json

You can also do:

$> npm install -g opencollective
$> opencollective webpack

[andrew]

Thanks @xdamman, is there any information about what github orgs/repos that collective is responsible for?

[xdamman]

There is a settings.githubRepo or settings.githubOrg, e.g. https://opencollective.com/fuse-box.json

But this is not a stable API, it will probably change in the future. But we can ping you if/when we will change it. Also, feedback on how we should implement such api is always welcome. We have an #api channel on https://slack.opencollective.org

[BenJam]

Do you think we should be indexing things like opencollective "collectives", gratipay "projects" and patreon "creators" as a separate entity.

I am not making decisions that might slow the DB down 🗡

Connecting them to orgs/users makes sense to me as it's closer to the humans than the published artifacts.

I agree for a first pass but you'll have the inverse problem: the project has funding but it doesn't pay for people. Ultimately we want to know whether people are going to be able to work on the project but there's a degree of safety in the knowledge that a project could pay for some development in am emergency if needed.

[andrew]

@xdamman FYI running opencollective webpack gives an error:

Cannot read property 'collective' of undefined

[xdamman]

I know, I tried to push a fix for it and I broke the internet :-/ https://twitter.com/xdamman/status/914906059692756992

In the meantime, just run the opencollective command within a project that has a package.json and it will work. Busy on deploying v2 for Open Collective now which is the priority atm.

[BenJam]

okay so a a first pass we will consider:

support: for a project may belong to an org, repo or user. Within support we'll store the primary currency and a balance (if any).

support evidence: is an example of gathered data for support with a currency, date, amount, source and submitter. This could be direct (donations, to a project, an org or an individual) or indirect (employment of a maintainer). We'll gather some of this data through providers like OC, Gratipay etc. and gather from others through a claiming or social-proof process.

[andrew]

I think we'll be able to get a similar dataset from https://salt.bountysource.com, which has a similar setup to gratipay/oc/patreon aside from the regular bountysource, not sure if they have an API but it's open source here: https://github.com/bountysource/core