Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Idea - Github for sharing revenue amongst contributors
6 points by lefnire on Aug 26, 2012 | hide | past | favorite | 7 comments
What do ya'll think: A service which takes all revenue made by an open source project on Github and distributes it by percentage contribution amongst its committers?

So first you have an open source project which has revenue or revenue-potential. Maybe it's funded by investors (Meteor) or Kickstarter (Light Table), a purchasable product (Textmate), a Freemium service with a private branch hosting its premium IP, etc. Then you have the service I'm proposing: a web app which collects the revenue somehow - this needs to be thought out, but maybe interfaces with Kickstarter as an example, and the funds are escrowed to this service per project instead of the project owner. The service monitors the Github project's "Contributors" graph (eg, http://goo.gl/3Byjj) and uses Gittip to distribute funds based on percentage contribution. This includes commits by coders, designers, legal specialists (LICENSE), writers (README, gh-pages, documentation), etc.

It strikes me as something that could create dynamic, auto-pilot micro-companies; catalyze bootstrapped products; and better incentivize contribution to open source. It also enables coders to invest with their commits. "Meteor? Oh, I'd totally use that - I'll start committing to make sure it happens."

Anyway, what you guys think?




I think it is interesting idea. However, I think you need a better system than just the number of commits, or lines of code committed. I don't these are very accurate measurements for the degree which someone contributed to the project. You need a more sophisticated system to determine that.


This strikes me as quite similar to the difficulty in paying teachers by their performance. You can use a lot of objective data for your decision-making, but there probably needs to be some subjectivity in there as well.


In other parts of software as well: the use of lines of code, and various modified LOC metrics, to quantify programmer productivity is fairly notorious.


I don't think quantifying contributor value can be automated. You'd do better with some sort survey among the contributors where they are asked what percentage of the revenue they would give to each other contributor.


That's true, there could be a lot of time in research and offline action going behind a single commit. Any suggestions re: other Github-provided data?


Perhaps look into # of github issues closed.. but that means you need to somehow account for "major" bugs versus "feature requests", etc.. and make the tagging is as consistent as possible.





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: