A good algorithm to divide payments among ALL developers of a Github repo based on statistics

Question

Recently someone on r/bitcoin started using our crowd-payment system to directly reward the Bitcoin core developers. Our system divides payments based on participation levels. A kind of one-to-many payment.

This resulted in quite a discussion (but also in $600 of donations and 20-25 of the core developers quickly signing up to collect their rewards). One of the main arguments was that it is impossible to reward developers based on simple statistics such as LOC.

We only partly agree, and one of their lead developers Gavin Andreesen said our algorithm did quite well.

My question is, if you had to divide rewards among all contributors to a Github repo, based on the repo's Github statistics, what algorithm/calculation would YOU suggest.

On Github only a few types of participation are measured/rated. In that regard it is not a very social platform (yet). Instead of just using LOC, our algorithm weighs:

• the number of commits accepted into main branch
• number of lines added
• number of lines deleted
• recentness of a contribution
• It does some normalisation to reduce extremes

Also remember that repos are moderated by means of pull-request. So there is quality control before the algorithm does its thing.

To demonstrate the concept, we pledged EUR100 to this question. When an answer is accepted, it will be divided among ALL answers based on votings. Rewards can be collected by OAUTH-ing your stackoverflow account.

https://mobbr.com/#/task/aHR0cHM6Ly9zdGFja292ZXJmbG93LmNvbS9xdWVzdGlvbnMvMjk2MDY3NTgvYS1nb29kLWFsZ29yaXRobS10by1kaXZpZGUtcGF5bWVudHMtYW1vbmctYWxsLWRldmVsb3BlcnMtb2YtYS1naXRodWItcmVwby1iYXNlZA==

Answer 1

You don't ship code, you ship features. (well actually, maybe you don't ship anything, but still, you care about your code doing stuff, not just sitting there)

IMO the only reasonable way to spend grants for open-source projects is a bounty-based system.

For one thing, you get to spend the money you have now for future devs.

Secondly, you can involves the community much more directly, by letting them pledge to a specific bounty (for a feature or a bug) OR NOT.

Lastly some driving entity gets to prioritize the work by putting higher bounties or higher priority or more difficult tasks.

PS: "But We don't have such an entity". Then you are pirates. Take the money and run.

EDIT:

I understand that you would want to reward people for the work they have already done. It might be that this is felt as needed by your community, and I wouldn't pretend to know the politics involved.

However to a larger point, I think you are trying to solve with an algorithm ,a posteriori, some problem that should be solve by a steering committee and the community, a priori.

All the money that you have that isn't pledge directly at a specific feature or bug-related issue, you can use to fund refactoring and plumbing work (which tend to be underfunded by users via the bounty system).

It is never too late to put in place such a system and consider that the money pledged so far was pledge to the project in general and should be re-allocated within the project by the aforementioned steering committee.

Answer 2

My theory: Every measurement that can be determined solely by a program (e.g. # of lines of code added or deleted) is vulnerable to trivial gaming. Every other measurement by definition relies partly on human input (e.g. # commits accepted into main branch) and is vulnerable to the usual "social" problems like corruption and favouritism -- but these are still infinitely better than the first kind. Automatic measurements should only ever be used as "lower bound rules", like "Hasn't even visited the site in the last year ==> Not eligible for anything."