I recently made my first contributions to TextSecure. For those not familiar, it’s a handle little secure messaging app that manages both SMS messages and secure push notifications. It’s one of the best examples of usable security out there for mobile, so I’m stoked to finally be able to contribute to it.

One of the many cool things about the project is that they’ve set up BitHub, an automated donations/payout service for open source projects. The service is remarkably simple in interface, allowing for donations to a pool of funds and paying out automatically for every commit. In my case, as soon as my commit landed, the equivalent of roughly 12USD landed in my BitCoin wallet. The process was transparent and painless for me.

Looking through the git history for the project, I noticed a bunch of commits that included the line:


While I couldn’t find any explicit documentation of it anywhere in the BitHub docs, it turns out that this does, as you’d expect, “donate” the commit in question. I tagged my second commit to TextSecure with FREEBIE, and sure enough, no payout resulted.

This whole mechanism is interesting for a few reasons, almost all of them having to do with usability and the API.

See, paying for open source contributions isn’t a radically new concept. There have been various attempts to make it work for years, and most of them end up looking or actually being small companies built up around various projects. Some particular projects have bug bounty systems. Others are covered by third-party bug bounty systems.

But a per-project-funded, per-commit-paying, automated donation and payout system, the API for which is almost entirely included in the existing git infrastructure is new. And what’s more, having used it now, I’m convinced it’s as close as we’ve come so far to the Correct way of doing payouts for open source contributions. Its transparency and seamless integration make it trivially usable. It can be configured to pay out or not by default, with overrides being as simple as appropriately tagging your commit. The bitcoin-based payout is so easy and quick that it’s damned near magic.

I haven’t looked into setup or configuration much, so I don’t know how much of a headache it is from an operational point of view. (I don’t know precisely where, e.g., it looked to discover the right BitCoin address, though I suspect it’s just doing a committer email lookup on CoinBase. I’m not sure what the payout mechanism would look like if I didn’t already have a CoinBase account setup or if can be setup to query identity services like OneName) But from a user’s point of view it was so easy and invisible that it would be easy to miss right up until the BTC landed in one’s wallet.

It’s this usability that makes something like BitHub a potential game changer. A zero friction way for developers to get a little payout for fixing something on a project creates a powerful new incentive for them to get over the learning curve. There’s a huge psychological difference between needing to learn a new codebase just to fix a bug or two, and learning a codebase that actively pays contributors. Especially when the actual payout mechanism involves no special setup for the dev.

In short, BitHub’s git integration, transparency, and near total lack of friction make it the best open source payment solution I’ve seen. And that’s not just a nice thing, it’s an important thing. Getting paid drives commits. Friction drives complacency. BitHub finally nails the best of both worlds for open source payments.