Bounties and Tips
Last week I wandered into the tip4commit fracas and a “helpful” commenter pointed out Bountysource, so I started asking some questions there. There must have been a few others doing the same thing because, to their credit, they started a discussion about it.
Since then I’ve been thinking about money in open source and what exactly it is that makes me uncomfortable with things like tip4commit and, yes, Bountysource. Why am I uncomfortable? Does it extend to other projects like Codesy.io (yes) or Gratipay (no)? What do I think is a better solution?
I have no problem with people being paid to do open source work.
I do have a problem with maybe paying people.
I have a problem conflating “merged” and “done.”
Tip4Commit
I don’t want to talk about Tip4Commit, except to say that they incentivize the wrong thing (lots of commits) and their attitude is bizarre (who would ever be unhappy about unsolicited email and a quarter of a cent?!).
But, when faced with that, they did add the blacklist. Credit—not, you know, a lot—where it’s due.
Libraries
Most of the open source work I’ve done has been on libraries: they aren’t end-user applications, but they’re the tools to build them.
Periodically, someone wants to add proxy support to django-ratelimit. I always say no, because proxy configuration is too deployment-specific.
But let’s say, for whatever reason, Alice would rather add proxy support to the ratelimit decorator than use one of the workarounds. Because the code is under an Apache License, she is free to clone the code, make the change, and run her copy. She is, further, free to redistribute the changed version, if she wants. (C.f. django-brake.)
If Alice did that at work, she was paid for her time. If it was for a personal project, she was paid exactly what she is paid for the rest of her personal project work (which might be nothing, of course, but that’s her call). It doesn’t matter if I never merge the pull request. In fact, Alice never has to open a pull request. The deliverable was the functionality and it’s done.
For library code, “done” and “merged” are two completely different things. If Bob wants a feature in a library, he can gamble and put a bounty on it, or he can do it himself, or pay Alice to do it for him. If he really believes the library is better with the feature and I’m not willing to merge it, he’s free to release the fork.
I’m not involved in any of those transactions, nor do I want to be. If Alice or Bob decide to contribute the change back in the form of a pull request, then I’m free to decide whether it belongs in the project regardless of any money changing hands.
Alice did the work, the work was useful—or not—and she was compensated according to fair rules that have nothing to do with me, the maintainer.
Applications
A reasonable way to distinguish an application from a library is that merging does matter. There’s one running copy or one canonical distributor. For example, GitHub just put a $1000 bounty on an old Firefox bug.
In this case, for the work to be “done,” it really does need to be in Firefox—and make it all the way to hundreds of millions of computers. Unlike a library, GitHub doesn’t benefit from running their own Firefox fork.
The first critical piece of that is buy-in from the maintainers. If the Firefox module owners don’t believe they should do it, no bounty is going to matter.
So let’s say they do, but, being a small team, they don’t have the time to do it themselves.
Like Bob, GitHub has a couple of options. They employ hundreds of programmers, maybe someone there has enough background with Firefox to write the patch. Or they could contract someone who has done work on Firefox. Or, they can gamble on it being done and put a bounty on it.
Here, my last issue goes away: the deliverable is the functionality but it isn’t delivered until it’s distributed. Since distribution requires buy-in from the maintainers and distributors, they should be free to choose whether bounties make sense for their community.
I do, however, still have other issues with bounties.
The High Bounty Problem
GitHub said this issue is worth $1000 to them. OK. Divide that by your freelance rate, and if you think it’s worth it, go for it.
But remember to multiply that by the odds that you get paid.
If it really is worth no more than $1000 to GitHub, then they admit that they are perfectly happy for this bug to never be fixed, if the market can’t match them with a developer. If they’re just bidding low, and are willing to raise the price, maybe they should just hire someone and agree on deliverables.
The Low Bounty Problem
But, they say, “Bounties should always be treated as rewards, and never as guarantees“. They should be icing on the cake, a thank-you for something you’d do anyway.
People are not rational when it comes to money. The Ultimatum Game is a result that’s surprising to no one (I got to see RadioLab do this experiment live, most people rejected anything less “fair” than 60/40).
In the world of open source, I think it goes something like this:
My time writing patches, reviewing pull reqs, corralling issues, etc, is a gift*. (If you’re doing work for hire, it’s a gift from your employer.) It’s a gift to the world at large, and it’s worth whatever my time is worth.
* There are, of course, benefits to me for doing it.
Once you offer me money for that time, it’s no longer a gift, it’s a transaction. And it’s worth whatever you offered.
If I thought the gift of my time was worth more than what you offered, I may be insulted, even if the “rational” answer is that it’s free money for something I would have done anyway. I may reject the “unfair” deal.
On the other hand, if someone offered me a beer (ahem, Justin) it’s a gesture of thanks. Even though it’s worth nearly nothing—most places, anyway—it’s, as with any gift, the thought that counts.
Whether the motivation is intrinsic (I want/need this to work) or extrinsic (someone will pay me to), I don’t buy that bounties are a good primary or extra incentive. If people behaved rationally and all bounties were small enough to be secondary, maybe they would be.
If anyone has data showing meaningful metrics improvements even correlated with bounties, please do let me know.
Gratipay
The other novel idea in open-source funding is Gratipay, where money is entirely divorced from deliverables.
When talking about compensation, bonuses and commissions are for what you did, while salaries and raises are for what we expect you to do. Gratipay, interestingly, tries to approach money in open source from the salary side.
(I had a Gratipay account, but card numbers changed and I forgot about it, etc, so I shut it down.)
Because it’s to a specific person, and completely separate from any specific work, Gratipay feels much more like a thank-you-for-the-work-you-do gift. If I look at Gratipay, the problem I see it solving is that I can’t buy you a beer from across the country, not crowd-funding a development contract.
Is that the real problem? I don’t know, and so I don’t know if Gratipay is the right solution. But it’s certainly worth exploring.
Addendum: GitHub and Opting In
Finally, because it comes up a lot, just because I put something on GitHub, does that mean I opted-in to Bountysource?
GitHub obviously has terms of service that I did agree to and the code we’re talking about is usually open source (though not always: if it doesn’t have a license it isn’t FLOSS, even if it’s on GitHub; and when it is, the license covers use, modification and redistribution of the code, not butting into my community management).
But those are red herrings, because if your claim is that what you’re doing is not illegal then maybe you need to step back in to the realm of should you do it?
If you’re going to interact with the management of an open source project in an ongoing way, you should ask the people managing it. If your idea is great (hi, Travis CI!) people will opt-in. If people don’t opt-in, you need to figure out why.