bevry-archive/sponsored

Deprecated. Use https://github.com/bevry/github-api

sponsored

Pull in sponsors across different services and correlate against your reward tiers

Goals

Bevry is an open-source community that is behind several popular open-source projects which get millions of downloads a month.

The primary way we have funded our open-source development has been:

1. Unsustainably using our related at the time then unrelated consulting profits - unsustainable, as the business model is a misplaced loss leader, loss leaders are a gamble that only work if the project has a sutainable business model
2. Relying on donations from individuals, which are provided with no expectation of reward - reliable way to cover expenses through low tiers ($50/total/month over years)
3. Relying on sponsorship from companies, which are provided with reimbursement through various reward schemes (usually exposure, however mechandise is another example) - sporadic way of funding development through high tiers ($2000/total/month over a few months then a large gap)

Donations work off the intrinisic motivation of the donators ideology - socialism, altruisim, pay it forward, free culture, etc.

Sponsorships work off the extrinisic motivation of the sponsor to recoup their investment to ensure their business thrives - as altruistic spending is the end of a business.

Currently Bevry receives funds through several sources - Stripe, PayPal, Coinbase, Bank Transfer - as well as several services - Patreon, Open Collective, Gratipay.

Currently all the provided infrastructure only allows those to give funds to be treated as donators, who get nothing back, deincentivising large funding options through sponsorship - as all sponsorship rewards must be enacted manually, there is no automated service that rewards them.

This project aims to solve that by making it effortless to receive and reward sponsorship, incentivising and rewarding high-tier funding that covers development costs.

Plan

Part 1:

• pull in sponsor funding data from all different sources (stripe, paypal, bank transfer / manual input) and services (patreon, open collective, gratipay)
• correlate sponsor information (their funding data plus collected sponsor details) with your reward tiers
• expose data via api for rendering the sponsor data in your readmes and on your websites so they get a reward
  • JSON API
    • projectz integration (the thing that already renders the backers listing in this document)
  • web component

Part 2:

• provide an interface where sponsors can update their sponsor data

Part 3:

• add analytic tracker images to each sponsor render
• build dashboard and service to render to the sponsors how much eyeballs they got, qualifying their investment

Part 4:

• allow payments directly to sponsored, making us our own sponsor service (possible revenue option if wish to add fee - the lower the fee the better the competitive strategy)

Part 5:

• add merchandise and other type of reward fulfillments (definite revenue option) other type of reward fulfillments (definite revenue option)

Usage

This module is still under construction.

Join the overview discussion.

View install instructions.

View API specficiation plans.

View data specification plans.

View development instructions.

Find issues you can help with.

Backers

Maintainers

These amazing people are maintaining this project:

• Benjamin Lupton — view contributions

Sponsors

No sponsors yet! Will you be the first?

Contributors

These amazing people have contributed code to this project:

• Benjamin Lupton — view contributions

Discover how you can contribute by heading on over to the CONTRIBUTING.md file.

License

Unless stated otherwise all works are:

• Copyright © 2016+ Bevry Pty Ltd

and licensed under:

• MIT License

sponsored's Issues

fetch coinbase patrons

fetch gratipay patrons

fetch paypal patrons

Got this, but it doesn't seem to give us the details we need:

/* eslint camelcase:0 */
'use strict'

const {inspect} = require('./util.js')
const paypal = require('paypal-rest-sdk')

paypal.configure({
	mode: 'live',
	client_id: 'BLAH',
	client_secret: 'BLAH'
})

paypal.invoice.list(function (error, payment) {
	console.log(inspect(payment))
})

fetch open-collective patrons

they now have an API: https://github.com/OpenCollective/OpenCollective/wiki/API

fetch transferwise patrons

about this project / discuss this project

Just pushed this project up (first public commit, still under construction, not yet for public consumption) - which is the result from a lot of meetings, discussions, and month of experimentation - finally at a point where the solid foundations are being made - and about to create something quite cool.

I've updated the README with the details on the plan: https://github.com/bevry/sponsored

We can use this thread to discuss the project.

You can also join our Slack

Or schedule a meeting with me directly.

fetch patreon patrons

https://www.patreon.com/platform/documentation/api
https://www.patreon.com/manageRewards

• Patreon/patreon-js#11
• Patreon/patreon-js#12

fetch flattr patrons

setup credit and deduction system

as the only reliable data we can ascertain from services/sources is historical data - that relate to cumulative donation amounts - i.e. credit - rather than current month/tier details, instead we need to implement a system that does rewards by deductions from determined credit instead

The question then becomes how should deductions work?

There are cycle timing options:

• daily: start of next day to end of next day, according to some time zone
• monthly: start of next day, to the same date on the following month, according to some time zone
• monthly: start of next month, to the end of next month, according to GMT - this is what patreon does, but means if you donate on 2nd of March, you gotta wait until 1st of April for your sponsorship to go through (perhaps we can have an override button to force this month to be the sponsored month)

There are extra donation considerations:

• if a user has donated extra money than what their current selected tier is, then should that money go to the next month,
• or should that credit be consumed in levelling up their current month level up (perhaps could be a override button)

There are specification options:

• deductions occur by automatically consuming the highest tier that the credit can occur - this could consume credits quicker than expected, as a higher tier could be consumed over one month, when the plan could have been to spread out a lower tier over multiple months
• deductions occur by whichever tier the user has specified

There are notification options:

• when the user runs out of credit for the next cycle, they are notified to adjust their funding service
• if sources (stripe, paypal, coinbase) are configured, they could be billed automatically until they cancel
• if sources are configured, they could get an email to manually top up their credit
• when a users contribution on a funding service has determined to be ended, we send a thank you email to them for the time they did spend, and an email summary of all that they funded, and the exposure they got

Another option for the extra donation, and timing things can be:

• where if someone donates on the 14th of March, but doesn't want to wait until the 1st of April for their sponsorship to show, they could:
  • pro-rata it, so the deduction is only for 50% of the month - this makes historical listings complicated, as they effectively could get higher tiers at super discounted prices inside historical rendering
  • override it, so the deduction occurs like normal at 100% of the tier for the month, and they just sacrifice the passed days
  • or where such situations are not allowed, and they have to wait until the next month
  • the day cycle, and the date to date cycle, avoids this issue, as they just have to wait a day at most for the sponsorship to kick in - but it complicates historical listings as I'm not sure how you would render those things

One potential for rendering month to month historical listings (donated amounts will not be listed, just there for info)

# Backers

## 2017

### 03 March

- Bob Bill with url and description (donated $XX amount over 3 months, from 2017-01 to 2017-03)

### 02 February

- Jim Jones with url and description and logo (donated $XXX amount over 2 months, from 2017-01 to 2017-02)
- Bob Bill with url and description (donated $XX amount over 3 months, from 2017-01 to 2017-03)

### 01 January

- Jim Jones with url and description and logo (donated $XXX amount over 2 months, from 2017-01 to 2017-02)
- Bob Bill with url and description (donated $XX amount over 3 months, from 2017-01 to 2017-03)
- Richard Richie with url (donated $X amount over 1 month, on 2017-01)

One potential for rendering historical listings for all of the options, including date to date and day to day, would be the exact same method for rendering the current months listing, but where we pull everyone in:

# Backers

- Jim Jones with url and description and logo (donated $XXX amount over 2 months, from 2017-01 to 2017-02)
- Bob Bill with url and description and logo (donated $XXX amount over 3 months, from 2017-01 to 2017-03)
- Richard Richie with url (donated $X amount over 1 month, on 2017-01)

Notice how bob bill gets promoted, as his three $50/50/$50 listings put in the $150 tier - this is the only way that I think this listing style can properly reward people who have donated over a long period of time.

fetch stripe patrons

projectz integration

their issue over at bevry/projectz#80