BitHub = Bitcoin + GitHub. An experiment in funding privacy OSS | Hacker News Reader

BitHub = Bitcoin + GitHub. An experiment in funding privacy OSS

whispersystems.org

163 pointschilgart49 comments

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.

Perhaps this would create an incentive for contributors to better explain the significance of their changes in their commit messages. Whether or not this would be a positive effect is up for debate.

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.

My gut instinct was "this is perfect". However, sferik says it's made maintaining his repo much, much harder:

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.)

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.

But, we could be wrong! We'll see.

When I saw the fluff commits I was immediately reminded of a conclusion from "Punished By Rewards" - once a reward is applied, people will start doing the minimum required to obtain the reward, as their motivation has shifted from intrinsic ("I want to improve the project") to extrinsic ("I want a reward, so what do I have to do to get it").

I actually think your attitude is the right one to have for this kind of experiment. We can pontificate endlessly on what people might do, how people might exploit such a system, but I'm of the (possibly naive) opinion that just because a person can, doesn't mean a person will.

I suspect that, despite the potential for abuse, you won't actually see very much actual abuse.

Alternatively, it may influence commit behavior. People may not want to be accused of filing fluff commits & slow their contributions to accumulate 'enough' changes to justify the payout.

We added a FREEBIE keyword today for commits that are small enough the author doesn't think they should get a reward.

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.

Why not let the person submitting the request set the value? All the maintainer would have to set is a cap, so no strange values slip by on accident. The value of specific issues and milestones could be determined as a function of the global cap.

Doesn't fix the problem. Actually makes it harder: I shouldn't have this level of management forced on me. Perhaps the repo owner (or whoever manages pull requests) should receive an amount? Obviously this could be abused too.

What do you mean? You are the repo owner and you set up issues with a specific value, then whoever submits a pull request (merged) for those issues automatically gets paid.

Or maybe I didn't properly understand how it works?

I was thinking more along of the lines of sferik's situation, where someone other than the repo owner funded the rewards. I certainly am not interested in paying anyone to improve any of my projects, but if any were valuable, a third party might.

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.

Although to be honest, after the first few changes to readme/documentation[.] there really isn't much more left to update. And the actual maintainer of the repo has the final say on deciding what will and will not be pulled in. If you are just sending me lines upon lines of refactored code that literally does nothing but just move stuff around, I'm not going to merge it. Simple as that.

[.] Finally! We'll be having people fighting each other for a more up-to-date documentation!

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).

> These studies are typically set up such that there's no choice; you have kids (usually)

There's a lot more literature behind this than just studies with kids, though I'm a total novice here. Here's[1] a painfully detailed meta-analysis I found.

> 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.

Reducing this down to just "more or fewer contributors" is the kind of over-simplifying that I worry about here. The software industry is not historically people-savvy, and open source is an entirely social phenomenon. It's easy to mess things up.

I'm less worried about the number of people changing than I am their relationship with the projects they work on changing. Right now, if I send someone a patch, I feel good because I know I'm doing a purely good thing. If I send a patch to a project that pays for patches, that's not bad, but it means now I feel more like I'm freelancing or some other more complication jumble of emotions.

Likewise, if someone sends me a patch, do I get excited that they want to be a part of my project? Have I met a kindred spirit? Or are they just gunning for a chunk of BTC in their off hours?

I'm not saying introducing money is a bad thing here, but like all other avenues of social activity, involving even a small amount of money radically changes the nature of it. Don't believe me? Try tipping your parents after they have you over for dinner. Maybe leave a fifty on your significant other's bedside table and see how that goes. :)

[1]: http://www.rug.nl/gmw/psychology/research/onderzoek_summersc...

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.

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.

Aren't you paid by Google to work on Dart? Apologies if I have the entirely wrong person.

How is that different?

> Aren't you paid by Google to work on Dart?

I am, this is a great question!

> How is that different?

What it means is that working on Dart is my job. It's a great job, and I love it. Like other good jobs, I get lots of both extrinsic and intrinsic reward from it. (In fact, a curious facet of being at Google is that the intrinsic rewards of being at the company feel like they overshadow the extrinsic ones. I'm constantly in this "and you pay me too?!" fugue of astonishment.)

But it also means that working on Dart is work. I do some extra-curricular activities related to it: I've spoken at a couple of conferences. But even then, I'm getting time off from work for free to go there, so in some sense I'm still being compensated.

I spend time answering questions about Dart online outside of work hours, but that's because, through some Hermione-like mental affliction, I will spend time answering questions about anything I know (and several things I don't).

But, aside from that, I actually don't do much of anything Dart-related when I get off work. Dart is what I do 40 hours a week. It's a happy 40 hours, but when I go home, I stop working on it and stop thinking about it.

Would I hack on it until the wee hours if I wasn't getting paid to do it while the sun was up? I don't know.

Thanks this makes total sense.

I've been grappling with this question because I, myself, have been paid to contribute to OSS for the last few years. I think my experience is much more blurry than yours is, at least with work/life separation.

> I think my experience is much more blurry than yours is, at least with work/life separation.

Well one thing that definitely helps is having two small kids. :)

I basically have to have a strong work/non-work separation now because most of my evening is booked solid with dinner/clean up/pajamas/brush teeth/vitamins/books/stories. Back before I was a family man the boundary between work and the rest of my life was a lot squishier.

I think this is genius.

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?

One thing I see as a problem here is that anonymity enforces very careful code reviews focusing on security imlications of the changes.

I think that can be a feature as well.

Also, are the contributors anonymous in the sense that you have no way of knowing the identity of the contributor? Or, anonymous in the sense that the contribution originates from a particular pseudonym?

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.

I wonder how well this would work tied in to the stack exchange model?

Now HERE is an interesting idea.

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.

So right now the model is similar to tip4commit, but by running their own service the model can be changed to whatever works best down the line.

https://news.ycombinator.com/item?id=6882374

http://tip4commit.com/projects/230

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.

I think the idea has potential but would this not encourage users to purposely commit sparsely?

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.

Moxie are you communicating with the DarkMail guys at all? I'm sure they would appreciate your input.

I think this could work as long as you have very detailed contributor and style guides.

This is great! I just sent them $100 in BTC! I love what WhisperSystems is doing!

I look forward to when StackOverflow integrates BitCoin.

I think you would be better off implementing something easier to use like dogecoin. The reddit community seems to be adopting it, and it seems much more reasonable to buy 1000 doge for $1 than .00001 BTC

BTC has a huge problem and the mBTC uBTC just ended up confusing people even more.

Reply on news.ycombinator.com