Revenue sharing model

[jiri-janousek]

Background

It is necessary to have a clear revenue sharing model to be allowed to use Gratipay for fund raising. gratipay/gratipay.com#3390 (comment)

whit537 (Gratipay):
To receive payments on Gratipay, you must meet these criteria:

• Offer goods or services in exchange for voluntary payments.
• Offer open work. That is, you must provide a clear path for any individual to voluntarily begin contributing effort to the production and delivery of the goods and services you offer, and to be paid for the same (whether via Gratipay's Payroll feature or some other mechanism).
• Not clash too strongly with our brand.
• Provide a working withdrawal mechanism.

My major concern is that there is not a lot of extra revenue to share with contributors for now. gratipay/gratipay.com#3390 (comment)

whit537 (Gratipay):

I believe the core of the concern is that income is so low that it barely covers expenses and perhaps a bit of labor, but certainly there is not a lot of extra revenue to share with contributors. Am I hearing you right?

Fenryxo (Nuvola Player):

Exactly, there is not a lot of extra revenue to share with contributors for now. I plan to start sharing the revenue as soon as I get funded at least one work week monthly (40 hours, €10 per hour) of my own work on the project. This is a reasonable threshold that allows me to do some core development, manage package repositories, respond to support requests and actually review and accept pull requests from contributors. The contributors will be paid individually based on their preferred payment method (e.g. Gratipay, PayPal, Patreon, Bitcoin, ...). Is this revenue sharing model with a threshold OK for Gratipay?

However, the proposed revenue sharing after a certain threshold is OK for Gratipay if the conditions are clearly stated. gratipay/gratipay.com#3390 (comment)

Fenryxo (Nuvola Player):

Is this revenue sharing model with a threshold OK for Gratipay?

whit537 (Gratipay):

Yes, definitely, as long as it's clearly communicated up front so when I'm evaluating whether or not to contribute to NuvolaPlayer I can potentially use that information to inform my decision. "Hmmm ... what are the chances I could get paid eventually for hacking on NuvolaPlayer? Let's see ..."

Tasks

• Draft conditions for revenue sharing model.
• Create list of past contributors to Nuvola Player 3.
• Invite contributors to this discussion.

Draft of the model

Formal conditions

You can receive a revenue share as

• Occasional contributor: You sometimes contribute a significant code portion or graphics to the project and your work gets accepted through a code review. You will be rewarded per work according to available budget. If the budget is low, your work will be recorded and you will get rewarded later unless the project is discontinued. Your work won't be forgotten.

• Active Service maintainer: You maintain a web app integration script under the Tiliado organisation at GitHub and your script has no serious unresolved issues. You keep it in sync with development of the Nuvola Player core and project policies, apply recommendations from the development mailing list and are responsive. You will get your first reward as an occasional contributor (see above) and you will be rewarded monthly according to the budget after one or two months of active maintenance.

  Note: A very frequent issue in Nuvola Player 2 was that a contributor created an integration script, but didn't respond to any bug reports or project policies since then. I don't want this to happen again as broken integrations scripts make look Nuvola Player like a crap.

Legal conditions

These conditions are necessary because I don't want to end up in jail or be hunted by financial authorities. They tend to be pretty greedy!

• You must be able to provide a bill/receipt in exchange for the reward.
• The bill/receipt must contain following information: real name, e-mail address and country.
• You must clearly state whether you act as an individual, sole proprietorship or a business. There might be extra tax duties.

Threshold: €400 monthly

I plan to start sharing the revenue as soon as I get funded at least one work week monthly (40 hours, €10 per hour) of my own work on the project. This is a reasonable threshold that allows me to do some core development, manage package repositories, respond to support requests and actually review and accept pull requests from contributors.

Extra revenue above €400 after paying for project expenses will be split into three budgets:

1. Rewards for occasional contributions (including unpaid rewards from the past).
2. Rewards for service maintainers.
3. Development of the Nuvola Apps 4 platform.

[chadwhitacre]

Thanks for following through with this, @fenryxo. I'm not used to saying this but I do have to finalize things with my lawyer before Gratipay's terms are firm. That said I think you are on the right track here.

One thing I'll add: Have you considered Gratipay's teams feature? That feature is intended to provide projects with a way to share revenue among contributors. As part of Gratipay's terms rewrite we are looking at reimplementing that as a proper "Payroll" feature where we would collect identity information for contributors on your behalf. You and your contributors would still be responsible for any tax reporting and obligations in your respective jurisdiction. Is this Payroll feature something you would be interested in?

[jiri-janousek]

The team feature is indeed interesting, @whit537. But I'm not sure whether it will fit for my project:

1. Let's say we have extra revenue $90, so the budget for service maintainers is then $90/3 = $30. Since I cannot set the take of a contributor, how can I ensure that the total take doesn't exceed this budget?
2. Another issue is that Gittip operates weekly whereas the funding of the project is evaluated monthly. But a little of math should be enough.

[chadwhitacre]

Hmmm ... you're probably right that Teams is not the best fit for you as things stand today. Once we get through this pivot hopefully we can improve Gratipay to better address your use cases. :)