This is very cool, but my initial reaction was "this is amazing" to a misunderstood model of what this is.
This is: Create a pool of btc, distribute to those who commit to current round.
What I thought this is: Anyone can tip on individual commits that they find useful or of exceptionally high quality, akin to Reddit Gold for code. This way, not all commits are treated equally and great commits can be compensated. To further the reddit gold analogy, this can tip for premium features (i.e. tip some btc or usd for a month of free github premium) or just straight out money.
I realize there's gittip, but this is on the level of commits, not developers.
Sure, except that tippers (users) are not likely to be in position to judge the quality of a commit, nor really want to wade through hundreds of commits to decide which ones might be worth spending money on, and for the most part, just want to support the development of the project rather than micro-manage it. It's a nice ideal us developers can dream of, but the model implemented BitHub is just easier to use.
To use a restaurant analogy, a shared tip jar that gets split evenly at the end of the night results in much fairer distribution (and includes the chef and cashier as well) as opposed to personalized tips which get unfairly / unevenly distributed between waiters. Most people tip because of the full service, from ambiance to service and cooking, not just the front-man performance.
And you can still always ways to tip individuals developers (or waitresses) personally if you so wish.
I think Open Source would benefit from having both models.
Your model/the gittip model is good.
So many times, there are only a small handful of people who care about a bug being fixed or a capability added -- but that small handful are both willing and able to tip generously for work that meets their specific need! We've all been there. Either as an individual, an agency, or a software company, we've been in a place, dependent on a relatively lower-profile project where we'd cheerfully tip in the $50-$300 range. That's probably good for everyone. There are a few ways of doing this, but what you've described -- 'tip for this specific commit' -- is how easy we all wish it was. I wish it was a feature of github.
But their model is good, too.
Some open-source projects are relied upon by thousands, tens of thousands, or more people, and they want to know that everything, small and large, is being done to keep the software stable. As others have commented in this thread, this would be a way to pump up the ecosystem for popular, highly-depended-upon open-source software projects.
Sure, adding features like this might induce gaming. But if I understand their model, this may just mean that those reviewing pull requests may just need to take an additional factor into account -- whether or not the commits involved are substantive, or if they're too 'gamed'. It seems like it might be a self-licking ice cream cone, because larger-scale gaming (attempts to earn Real Money through mostly-frivolous PRs) could be caught by review, whereas minor cleanups for docs or comments in the commits of a PR that includes more substantive work might be, as other commenters have mentioned, perhaps just a few percentage points of 'wastage'.
I don't think we really know if it's feasible or not, but I applaud these efforts tremendously.
I also wonder if a hybrid system could work -- perhaps as a feature to be added to the 'tip for all commits' approach. Allow tipping for individuals, but a certain percentage (50%? 25%? something?) could go into the general pool for all accepted commits.
Our hypothesis with this project is that any commit, even a "fluff commit," is better than no commit, and that the overhead of trying to build a more complex accounting model is higher than the cost of paying out 2% for "fluff." Basically, worse is better.
I hadn't thought about this... but honestly a simple solution would be to let the repo maintainer decide how much to give for each commit in a scale of importance.
You can't obviously measure it on number of lines changed or something because that doesn't reflect the importance of a change, but maybe just say "okay, I can merge this but you get only 0.0001% because it's just a minor typo" or something like that. And if somebody is trying to abuse the system then just give them 0.
A better way would be to set up issues with bounties (what is already mentioned in the article) so the actual developers can decide the worth of contributions before the contributions are actually made, in order not to do favoritism.
Yeah, I think this has the intractable problem of effectively useless commits.
One might argue that initially those problems would fix themselves as people would grab for the lowly hanging fruit, and that's fine, but I could see someone refactoring segments of code for no realistic reason, but "selling" it as an improvement, for the explicit goal of collecting the money.
Having a gatekeeper prevents this somewhat, but this company seems more interested in some kind of idealistic anarchy.
This seems like a terrible idea to me. I believe the entire world of open source functions based on intrinsic motivation: people participate because the act of participation itself is enjoyable. This has some flaws (less fun stuff like docs don't get as much love), but unlocks a huge pool of untapped motivation in people.
Studies have shown that if you add in even a small amount of extrinsic motivation (i.e. pay people) it dramatically affects their perception of intrinsic reward. In other words, if you pay someone for doing the exact same thing, the task becomes less enjoyable.
If we start throwing cash around, it's going to have a huge impact on the psychological aspect of open-source, and probably not for the better.
>Studies have shown that if you add in even a small amount of extrinsic motivation (i.e. pay people) it dramatically affects their perception of intrinsic reward.
These studies are typically set up such that there's no choice; you have kids (usually) do some activity like drawing for either no reward or extrinsic reward, and then see how many continue once you remove the extrinsic reward.
There are a lot of possible explanations for this; the one I like the most is based on self-perception theory, which would predict that once you've accepted the reward, you attribute your motivation to the reward.
There are some differences between those studies and this scenario:
1. Open-source developers have a far wider range of options, and must actively choose to work on a project with financial reward.
2. Open-source developers who have already contributed some amount for free should be less influenced than new developers -- they already have had altruistic/intrinsically-motivated self perceptions.
Developers that are attracted to OWS projects because of this reward probably won't stay if the reward is removed, but I'm not sure, and don't predict, that OWS projects will attract fewer developers overall because of this.
I think that intrinsic and extrinsic motivators can definitely co-exist, especially for domains where there are differences in the tasks -- for example, offering these bounties for "less fun" stuff (or dynamically offering more for parts of the repo that have been touched further into the past).
I agree, and while it's not quite ready for a show HN yet.. I've been working on a quick side-project that allows people to send a 'thank you' to (github) open source committers.
I just completely agree that trying to motivate people who give huge amounts of time with small amounts of cash isn't a great idea. That said, it's good that there's a place for it (gittip etc.) should people want to.
I'm not sure if I'll ever really get the culture change in encouraging more "thanks" in the world, but it has been a fun little project getting up to speed on rails4, octokit etc.
Call me naive but this is a really nice idea. Reminds me of flattr except it's automated. The idea of having bounties to various project issues and setting up a commit/pull-request payout could be a real incentive for a lot of people to contribute to actual open source software.
Bitcoin is just the icing, makes this really well integrated and anonymous too. I can't wait to see where this project leads us to. Maybe an actually fully decentralized open source employment career?
I've got kind of a complicated picture to paint, so please bear with me...
1) Services can be bought with Bitcoin.
2) Github is awesome, but currently it's a totalitarian regime. Anyone with power can accept a Pull Request. There is no other form of government possible.
The thought occurred to me that for some kinds of projects, it might make sense to encode a form of government into the Source Code Repository / Source Code Review / Account system, itself. And possibly to have the entire thing - government, source code, data, and the running project itself - be self-hosting on a cloud server.
Self-hosting is the critical, and very interesting part to me. You pay your membership dues with BitCoin, and the service pays for its own hosting with BitCoin. And perhaps that's it - no one else has the keys to the BitCoin account, no possibility to profit off the service, it just pays for itself as long as it can, and then shuts down.
You could imagine a direct democracy, of everyone who pays their monthly membership fee. Or perhaps you gain voting privileges once you've been a paying member for 3 months in a row. All kinds of parameters could exist, and a single Community could possibly even modify their own laws, through something like a Constitutional law process. Maybe if the community is really successful, the governing body can start paying people with BitCoin to fix bugs, add features, create new art assets, etc.
There could be separate partitions of government. Like, picture an MMO RPG. Member for 3 months can vote on engine. Member for 12 months can vote on the content of the game itself, like where cities go, how much manna a spell costs, etc. Or maybe you get the right to vote, once you've completed an in-game quest!
As the code is modified, the service waits for all of the unit tests to pass before accepting a code change, waits for the government to approve of the changes, and then does something like restart the server at midnight.
And depending on the licensing, it may be possible for someone else to throw some BitCoin at a new server, and fork the whole Community, picking slightly different Constitutional and legal parameters. Over time, people end up with accounts on systems that have content and laws they like.
I've got a lot more thoughts about such a system, and I hope it comes to exist some day.
I had the same idea, it's great to know I'm not alone :-)
I was imagining an 'enforced' democratic website ie the website runs the live code that any user can submit patches and/or vote on, and no-one has root.
At some point this sort of thing becomes a co-operative business... kind of big for a side project :-/
Anyway I started a python prototype (see my profile), and would love to bounce ideas off you!
I have found (small) money to not be a good incentive or motivation for people to work on FOSS. It might be worth trying for small simple tasks but it really is a one timer and not benefiting the continuing work and maintaining on the software on the long run.
Hmm. I took a look at the code and was disappointed to see it's using the Coinbase API. Hardly decentralised.
Unfortunately it's hard to replace with direct usage of the P2P network because it relies on sending money to an email address: i.e. a trusted third party has to hold the money until the recipient picks it up. What if they never pick it up? What if they don't actually want bitcoins?
It seems to me like a decentralised solution would be easy to code up, if only we add an additional requirement: someone who wants a payout should put a Bitcoin address into the pull request or commit description. Then BitHub would be able to make payouts directly from its own wallet with no Coinbase dependency, and a committer has to opt-in to receiving the funds.
I might take a look at coding this up soon. BitHub is Java so using bitcoinj and XChange would be very easy.
As many others in this discussion, I'm not sure whether this will be net positive or not, but I would try it if I could make the payments per merged pull request.
Additionally, I would like to provide bonuses for each checked-off item of
1. Does it have appropriate tests?
2. Is there appropriate documentation?
3. Has it been peer-reviewed and signed off? (Reviewer shares this bonus.)
These are the above-bare-minimum things I would like to encourage in my open source projects. Not everyone has time to go above and beyond when fixing a bug they encountered, but it's more than appreciated when they do.
In fact, maybe the payments should only be for the bonuses, not the merged PR itself.
That said, I'm not sure what field to try this on. StackOverflow is damn near perfect, IMO, in its current state. There are endless high-quality answers, without rewards.
IMO bug bounty payouts are a more effective use of funds for a project. Paying per commit is like paying per line of code. At least with a bug bounty you (the giver) can specify which particular item interests you. If you want to donate money to the project as a whole, then it seems easier to just communicate with the project owner/maintainer and send them funds directly.
In the line of worst case scenario that seems to permeate today's world, GitHub can now become a tool for money laundering. All you need is a few scripts creating puppet users and repos, and automate shill commits and pull requests.
I'm going to try this out. I'm a freelancer who wants to contribute front-end dev/UX/UI to OSS crypto projects but don't have the ability to join a project full-time. Plus most of my "free" time where I'd normally contribute to OSS, I'm now writing or maintaining my own projects.
I'm going to dig into WhisperSystems to see if there is anywhere I can contribute.
Hopefully more OSS apps do this.
It'd be nice if more projects open-sourced their marketing landing pages or homepage as well. I'd love to be able to do conversion-optimization and copywriting for OSS projects, instead of just programming.
I'm excited about the mix of coding and compensation. As a coder with a strong open source ethic, I feel there are enough secondary benefits to direct compensation to justify the potential loss in 'pure' motivation.
The twist I would like to see, which I feel fixes the fluff commit problem, is to write unit tests associated with a coin bounty. It puts a burden on the test author to write tests that are not easily gamed, but thats good practice anyways.
The problem about handling donations can be given to an external party like Software Conservancy, the Apache Foundation, or for GNU software, the Free Software Foundation. We use the last one for GNU Octave.
This seems to me like a better solution for collecting donations, which is a solved problem.
You could use the m-of-n feature of Bitcoin where a certain number of people from a larger group have to agree to a transaction and manage the funds for the project collectively like that. Whether to set rewards for committers, or just pay for the new build box.
You should take a look at Devcoin (devcoin.org): A crypto-currency specialized in rewarding open source projects (hardware, software, music, blog posts ...).
The main differentiator here is that 90% of mined coins go directly in rewards.
[+] [-] yan|12 years ago|reply
This is: Create a pool of btc, distribute to those who commit to current round.
What I thought this is: Anyone can tip on individual commits that they find useful or of exceptionally high quality, akin to Reddit Gold for code. This way, not all commits are treated equally and great commits can be compensated. To further the reddit gold analogy, this can tip for premium features (i.e. tip some btc or usd for a month of free github premium) or just straight out money.
I realize there's gittip, but this is on the level of commits, not developers.
[+] [-] madcat123|12 years ago|reply
To use a restaurant analogy, a shared tip jar that gets split evenly at the end of the night results in much fairer distribution (and includes the chef and cashier as well) as opposed to personalized tips which get unfairly / unevenly distributed between waiters. Most people tip because of the full service, from ambiance to service and cooking, not just the front-man performance.
And you can still always ways to tip individuals developers (or waitresses) personally if you so wish.
[+] [-] mr_luc|12 years ago|reply
Your model/the gittip model is good.
So many times, there are only a small handful of people who care about a bug being fixed or a capability added -- but that small handful are both willing and able to tip generously for work that meets their specific need! We've all been there. Either as an individual, an agency, or a software company, we've been in a place, dependent on a relatively lower-profile project where we'd cheerfully tip in the $50-$300 range. That's probably good for everyone. There are a few ways of doing this, but what you've described -- 'tip for this specific commit' -- is how easy we all wish it was. I wish it was a feature of github.
But their model is good, too.
Some open-source projects are relied upon by thousands, tens of thousands, or more people, and they want to know that everything, small and large, is being done to keep the software stable. As others have commented in this thread, this would be a way to pump up the ecosystem for popular, highly-depended-upon open-source software projects.
Sure, adding features like this might induce gaming. But if I understand their model, this may just mean that those reviewing pull requests may just need to take an additional factor into account -- whether or not the commits involved are substantive, or if they're too 'gamed'. It seems like it might be a self-licking ice cream cone, because larger-scale gaming (attempts to earn Real Money through mostly-frivolous PRs) could be caught by review, whereas minor cleanups for docs or comments in the commits of a PR that includes more substantive work might be, as other commenters have mentioned, perhaps just a few percentage points of 'wastage'.
I don't think we really know if it's feasible or not, but I applaud these efforts tremendously.
I also wonder if a hybrid system could work -- perhaps as a feature to be added to the 'tip for all commits' approach. Allow tipping for individuals, but a certain percentage (50%? 25%? something?) could go into the general pool for all accepted commits.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] gkoberger|12 years ago|reply
https://news.ycombinator.com/item?id=6882374
(SFErik had nothing to do with the bitcoin stuff; someone else put up the money and started it for his repo.)
[+] [-] moxie|12 years ago|reply
But, we could be wrong! We'll see.
[+] [-] Morgawr|12 years ago|reply
You can't obviously measure it on number of lines changed or something because that doesn't reflect the importance of a change, but maybe just say "okay, I can merge this but you get only 0.0001% because it's just a minor typo" or something like that. And if somebody is trying to abuse the system then just give them 0.
A better way would be to set up issues with bounties (what is already mentioned in the article) so the actual developers can decide the worth of contributions before the contributions are actually made, in order not to do favoritism.
[+] [-] diminoten|12 years ago|reply
One might argue that initially those problems would fix themselves as people would grab for the lowly hanging fruit, and that's fine, but I could see someone refactoring segments of code for no realistic reason, but "selling" it as an improvement, for the explicit goal of collecting the money.
Having a gatekeeper prevents this somewhat, but this company seems more interested in some kind of idealistic anarchy.
[+] [-] munificent|12 years ago|reply
Studies have shown that if you add in even a small amount of extrinsic motivation (i.e. pay people) it dramatically affects their perception of intrinsic reward. In other words, if you pay someone for doing the exact same thing, the task becomes less enjoyable.
If we start throwing cash around, it's going to have a huge impact on the psychological aspect of open-source, and probably not for the better.
[+] [-] tedks|12 years ago|reply
These studies are typically set up such that there's no choice; you have kids (usually) do some activity like drawing for either no reward or extrinsic reward, and then see how many continue once you remove the extrinsic reward.
There are a lot of possible explanations for this; the one I like the most is based on self-perception theory, which would predict that once you've accepted the reward, you attribute your motivation to the reward.
There are some differences between those studies and this scenario:
1. Open-source developers have a far wider range of options, and must actively choose to work on a project with financial reward.
2. Open-source developers who have already contributed some amount for free should be less influenced than new developers -- they already have had altruistic/intrinsically-motivated self perceptions.
Developers that are attracted to OWS projects because of this reward probably won't stay if the reward is removed, but I'm not sure, and don't predict, that OWS projects will attract fewer developers overall because of this.
I think that intrinsic and extrinsic motivators can definitely co-exist, especially for domains where there are differences in the tasks -- for example, offering these bounties for "less fun" stuff (or dynamically offering more for parts of the repo that have been touched further into the past).
[+] [-] patrickdavey|12 years ago|reply
I just completely agree that trying to motivate people who give huge amounts of time with small amounts of cash isn't a great idea. That said, it's good that there's a place for it (gittip etc.) should people want to.
Anyway, if you want to give feedback http://github.com/thankadeveloper/thankadeveloper and http://thankadeveloper.herokuapp.com (in the process of polishing, domain etc.).
I'm not sure if I'll ever really get the culture change in encouraging more "thanks" in the world, but it has been a fun little project getting up to speed on rails4, octokit etc.
[+] [-] steveklabnik|12 years ago|reply
How is that different?
[+] [-] Morgawr|12 years ago|reply
Call me naive but this is a really nice idea. Reminds me of flattr except it's automated. The idea of having bounties to various project issues and setting up a commit/pull-request payout could be a real incentive for a lot of people to contribute to actual open source software.
Bitcoin is just the icing, makes this really well integrated and anonymous too. I can't wait to see where this project leads us to. Maybe an actually fully decentralized open source employment career?
[+] [-] mateuszf|12 years ago|reply
[+] [-] VikingCoder|12 years ago|reply
1) Services can be bought with Bitcoin.
2) Github is awesome, but currently it's a totalitarian regime. Anyone with power can accept a Pull Request. There is no other form of government possible.
The thought occurred to me that for some kinds of projects, it might make sense to encode a form of government into the Source Code Repository / Source Code Review / Account system, itself. And possibly to have the entire thing - government, source code, data, and the running project itself - be self-hosting on a cloud server.
Self-hosting is the critical, and very interesting part to me. You pay your membership dues with BitCoin, and the service pays for its own hosting with BitCoin. And perhaps that's it - no one else has the keys to the BitCoin account, no possibility to profit off the service, it just pays for itself as long as it can, and then shuts down.
You could imagine a direct democracy, of everyone who pays their monthly membership fee. Or perhaps you gain voting privileges once you've been a paying member for 3 months in a row. All kinds of parameters could exist, and a single Community could possibly even modify their own laws, through something like a Constitutional law process. Maybe if the community is really successful, the governing body can start paying people with BitCoin to fix bugs, add features, create new art assets, etc.
There could be separate partitions of government. Like, picture an MMO RPG. Member for 3 months can vote on engine. Member for 12 months can vote on the content of the game itself, like where cities go, how much manna a spell costs, etc. Or maybe you get the right to vote, once you've completed an in-game quest!
As the code is modified, the service waits for all of the unit tests to pass before accepting a code change, waits for the government to approve of the changes, and then does something like restart the server at midnight.
And depending on the licensing, it may be possible for someone else to throw some BitCoin at a new server, and fork the whole Community, picking slightly different Constitutional and legal parameters. Over time, people end up with accounts on systems that have content and laws they like.
I've got a lot more thoughts about such a system, and I hope it comes to exist some day.
[+] [-] dustyneuron|12 years ago|reply
At some point this sort of thing becomes a co-operative business... kind of big for a side project :-/
Anyway I started a python prototype (see my profile), and would love to bounce ideas off you!
[+] [-] hnha|12 years ago|reply
[+] [-] mike_hearn|12 years ago|reply
Unfortunately it's hard to replace with direct usage of the P2P network because it relies on sending money to an email address: i.e. a trusted third party has to hold the money until the recipient picks it up. What if they never pick it up? What if they don't actually want bitcoins?
It seems to me like a decentralised solution would be easy to code up, if only we add an additional requirement: someone who wants a payout should put a Bitcoin address into the pull request or commit description. Then BitHub would be able to make payouts directly from its own wallet with no Coinbase dependency, and a committer has to opt-in to receiving the funds.
I might take a look at coding this up soon. BitHub is Java so using bitcoinj and XChange would be very easy.
[+] [-] shazow|12 years ago|reply
Additionally, I would like to provide bonuses for each checked-off item of
1. Does it have appropriate tests?
2. Is there appropriate documentation?
3. Has it been peer-reviewed and signed off? (Reviewer shares this bonus.)
These are the above-bare-minimum things I would like to encourage in my open source projects. Not everyone has time to go above and beyond when fixing a bug they encountered, but it's more than appreciated when they do.
In fact, maybe the payments should only be for the bonuses, not the merged PR itself.
[+] [-] ErikRogneby|12 years ago|reply
[+] [-] sejje|12 years ago|reply
That said, I'm not sure what field to try this on. StackOverflow is damn near perfect, IMO, in its current state. There are endless high-quality answers, without rewards.
[+] [-] shtylman|12 years ago|reply
[+] [-] bdcravens|12 years ago|reply
[+] [-] dmix|12 years ago|reply
I'm going to dig into WhisperSystems to see if there is anywhere I can contribute.
Hopefully more OSS apps do this.
It'd be nice if more projects open-sourced their marketing landing pages or homepage as well. I'd love to be able to do conversion-optimization and copywriting for OSS projects, instead of just programming.
[+] [-] donpdonp|12 years ago|reply
The twist I would like to see, which I feel fixes the fluff commit problem, is to write unit tests associated with a coin bounty. It puts a burden on the test author to write tests that are not easily gamed, but thats good practice anyways.
[+] [-] j_s|12 years ago|reply
https://news.ycombinator.com/item?id=6882374
http://tip4commit.com/projects/230
[+] [-] jordigh|12 years ago|reply
This seems to me like a better solution for collecting donations, which is a solved problem.
[+] [-] spindritf|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] fatbat|12 years ago|reply
[+] [-] joemocquant|12 years ago|reply
The main differentiator here is that 90% of mined coins go directly in rewards.
[+] [-] salient|12 years ago|reply