Gittip + GitHub For Project Royalties

Gittip (an awesome project) has potential beyond its intent. I want to discuss one such possible project: taking revenue made by commercial open-source GitHub projects and divvying it by percentage-contribution amongst its committers. Aka, royalties. The idea is to encourage profitable software to go open-source, and to pay contributors to those projects via royalties, using Gittip as the payment platform. I've built an HTML prototype for the project, follow along here.

Commercial Open-Source

First, you have an open-source project that makes money (or has potential). Examples are:
* Investment Funding (eg, Meteor)
* KickStarter Campaign (Light Table)
* Purchasable Product (Textmate)
* Freemium Service (HabitRPG)
* More Examples

GitHubRoyalties (or "GHR", to be renamed) would collect the revenue - eg, interfacing with Kickstarter - and use Gittip to distribute these funds each week based on project-contribution. Whatever revenue the project made that week is divvied by % cumulative contribution of the committers. This will vary over time, and sometimes be zero. However, for every week the project makes money - the revenue is divvied by percentage, so it acts more as royalties (or stock) than an hourly rate.


To determine contribution percentages, GHR would track:
* Issue queue participation.
* Commit statistics (eg, lines added & removed a la the "Contributors" graph)
* This would benefit coders, designers, legal specialists (LICENSE), writers (README, gh-pages, documentation), etc.

However, all commits aren't created equally. To mitigate the varying difficulties of commits, GHR users rate the difficulty of file-type contributions. For example, 10 lines of C++ takes more time than 10 lines of These "difficulty ratings" are globally normalized and become more accurate over time, and when combined with overall commit statistics will produce an accurate % contribution.

Non-Code Contributions

For contributions not made on GitHub (eg, KickStarter Campaign Writing), users can manually submit hours. Those hours must be approved by the project maintainer, and task-hour pairings become normalized over time similar to "difficulty ratings" to produce more accurate results (with the side benefit of providing a task estimations table for future use).

Pure Bootstrappage

With GHR, projects with good profit potential wouldn't have to hit the gauntlet with fundraising. Instead, you create a project, throw it on HN to gain some interest, and start coding. If the project has legs, a team will develop organically around it because they see the money potential. It can create dynamic, auto-pilot, micro-companies; and better incentivize contribution to open source. It also enables coders to invest with their commits.

I'd love to hear your thoughts - does this sound viable? What pitfalls do you see? I'd be honored to pilot my own HabitRPG if enough interest is rallied.