Some time ago we began simmering a system called Tipsy that helps web users make voluntary micro-contributions to the content creators whose work they consume. It picked up steam when we started sharing ideas with Doc Searls. Since Doc mentioned it in a blog post yesterday, I thought it worth providing a bit more detail here.
Tipsy has several aspects that I consider important:
- Tipsy leaves it up to the consumer to determine the value of the content they consume from the Internet.
- Tipsy keeps things simple so people aren’t deterred from donating: it lets users specify their total desired donation and automatically takes care of dividing that donation fairly into arbitrarily small pieces among the many providers of content.
- Tipsy requires no new infrastructure; the (completely client-side) system connects the user directly to the provider to make payments using existing mechanisms
The absence of any centralized infrastructure has three valuable consequences:
- Tipsy costs nothing to operate and has no transaction costs, so arbitrarily small contributions can be delivered to producers with no loss of value
- There is no critical threshold; Tipsy becomes usable and useful as soon as one producer and one consumer adopt it
- No centralized record of user consumption activity is ever created, protecting privacy
Content creators deserve to be compensated for their creative work. But the question of how to accomplish this online has generated substantial discussion and no resolution. The old-fashioned method of forcing people to pay a set sum of money has generated significant anger (against entities like the RIAA) and many scofflaws. A newer, advertising-based approach forces people to pay in time/attention instead. Most people seem to accept this approach because it isn’t costing them actual money. But I’ve always hated ads because I put pretty high value on my time/attention so I feel like I’m being overcharged. And the fact that no real money is involved probably lets people rationalize the use of ad-blocking tools that cut off that source of revenue for the creator.
I believe that most people would be happy and even eager to pay a fair monetary compensation to content creators. The challenge is deciding what’s fair, and if you’re looking for voluntary patronage, you need to leave that up to the consumer. We’ve seen several examples of this idea in action, including Radiohead’s pay-what-you-want album experiment and the recent pay-what-you-want distribution of several popular video games. This week Amanda Palmer kicked off a similar effort for her latest album—interestingly, she had to charge 84 cents to pay for the right to cover Radiohead songs, but leaves consumers to decide whether to give her any money at all. Some popular web sites such as Wikipedia also seek support through donations. But the patronage approach is not as widespread as subscription and advertisement models.
If you’re a pessimist you’ll assume it’s because people are selfish and greedy and happy to steal content. But I’m an optimist; I think people are just lazy. If you give them a way to do the right thing without any work, they’ll take it. I’ve made this point before around publishing structured data; I think the same holds true for patronage.
In particular, paying for content takes time, attention, and effort. If you’re donating for an album or video game you’ll be using for hours, you may find it worth the time and effort to think hard about exactly how much it’s worth to you, to decide on a payment large enough that it won’t all be eaten up in transaction costs (note that of Amanda Palmer’s 84 cent minimum, a full 30 cents go to Paypal), and to turn that decision into an actual payment through some online service. But what happens when you stumble across one interesting post on a blog you never read, or listen to a song just once? The fair value of this content to you is probably just a few cents. But what can you do about it? Figuring out exactly how many cents is a large cognitive burden. And the work involved in actually making the payment transaction would dwarf the cost of the payment itself.
There’s been much work on micropayment systems that aim to reduce the transaction cost to the point where it doesn’t swamp the value being transacted. But none of these has taken off yet. There are several obvious reasons. First, transaction costs are real: the infrastructure needed to run a micropayment system that carefully tracks payments is expensive, requiring a substantial “tax” on each of the micropayments it executes. Second, there’s the network effect: until a large population are using a micropayment system, there’s no real incentive for anyone to jump on board, since they won’t get any payments. That means micropayment services can’t make the money they need to support their infrastructure. Finally, there’s still cognitive load: even if there were a button that let you pay a penny to anyone you wanted, would you really be willing to use it every time you visited a web page?
We designed Tipsy to try to get around some of these problems and let people’s “lazy generosity” manifest. The idea behind Tipsy is that you make one general judgment about how much Web content is worth to you in general, and Tipsy takes care of apportioning that value to the creators of the content you consume. For example, you might decide to pay a penny a page, or 10 cents a minute. Tipsy’s web browser plugin logs the web pages you visit and distributes payment based on the number of times you visit each page (or on the amount time you spend on each). It does this without any server-side infrastructure, so all the collected value can go to the content creators.
Tipsy’s overarching goal is to keep things simple, so people’s laziness doesn’t trump their altruism. Charging a flat rate by the visit or by the minute means users don’t have to think about exactly how much each action is worth. It’s clearly imperfect. A minute looking at the Mona Lisa may be worth more than looking at lolcats. But can we be sure? Flat rate seems a good default. We do offer one exception, a “tip” button that can be used to give extra lottery tickets to content you particularly value. But it’s crucial that Tipsy do something reasonable without such intervention. If someone develops a better automated way to compute “value” from the logs, that can easily be incorporated.
The implementation is quite simple. Logging is trivial, so the only issue is payment. How do we transact the hundreds or thousands of micropayments to all the sites you visit? Its asking too much for a user to make all those payments, so we reduce the work by running a lottery. When you visit a site, you notionally give them a lottery ticket. Once a week, you run a lottery and pay a large sum to the lucky winner. In this system, we’re exploiting the law of averages: any site with a large number of visitors will win the lottery about as often as you’d expect, and will therefore earn about the same as they’d earn by direct micropayments.
Here’s an example. Suppose people have decided to pay a penny a page for the sites they visit. Using Tipsy, they’ll give each page a one-penny lottery ticket. At the end of the week, if they’ve visited 500 pages, they need to pay out $5.00. To do so they choose a random lottery ticket and pay the winner $5.00. On average, each page expects to win a penny from that lottery—the face value of the ticket. Now consider a particular web site with (say) 20,000 penny-a-page visitors. This site’s expected earnings are $200.00 . How much they actually get depends on luck. But not very much. Only 5% of the sites will get less than 3/4 of what they should. If their total lottery ticket value rises to $2000.00, then all but two percent will get within 10% of their tickets’ face value. And for a “big” site earning $20,000, the odds of losing 5% are less than one in a thousand. I think these variations are dominated by the variation in people’s giving mood.
It remains only to direct the payment. To enable this, Tipsy specifies a format for a fragment of RDFa that can be embedded in any web page. This RDFa specifies a mechanism that can receive payments—for example, a particular Paypal account. When Tipsy’s lottery picks a winner, Tipsy uses that RDFa to launch an appropriate payment interface pointing at the proper account—so in the Paypal example, it can open a Paypal payment window with the payee information already filled in. A site may describe multiple payment mechanism, and the user’s Tipsy client can be configured to select the one the user prefers to use.
We introduced the lottery technique in order to avoid any centralized infrastructure. Flattr, a service currently in closed beta, takes that centralized approach. Flattr collects a single large sum from a user, then gives the user a button they can use to direct “tips” to specific web sites. Flattr tracks the tips and divides the user’s payment up appropriately. I see several downsides in this approach. First, the fact that users must explicitly tip means that they will often forget or neglect to do so, meaning that payment isn’t distributed fairly. Second, there’s a cost to running the centralized server; this cost will clearly need to be taken out of the incoming payments, reducing the amount that reaches the content providers (remember that 30 cents that goes to Papal). Third, there has to be a minimum buyin to the service, or Flattr won’t be able to support its centralized infrastructure. Finally, Flattr knows about all your tips. This seems likely to disturb some users who would otherwise be happy making donations. The lottery avoids these problems; it requires no centralized infrastructure be built or maintained and allows 100 percent of the funds to reach content creators without providing reader logs to anyone. And I trust the law of large numbers enough that I’m not worried about the minor income fluctuations introduced by the lottery randomness.
Instead, my biggest concern about Tipsy is whether people will play fair. Suppose you run your lottery and the winner is a site you don’t even remember visiting. Would you be tempted to change the outcome and decrease the amount you donate, or instead give your donation to a site you visit relatively often? If such behavior is widespread, Tipsy will fail. Sites that have many infrequent visitors will be penalized as nobody will pay them; instead, too much money will be directed towards the sites that people visit often. But my previously stated belief that people want to play fair holds here as well: I think most people will recognize that the holder of the winning ticket really should be paid. The key is to help them understand the fairness issue: a user may find it strange to pay a provider that they rarely use, but needs to remember that he is acting as a representative for all the other people who use that provider and want to see it paid. Those other users are willing to use the lottery and not pay most of their providers because they trust that someone else’s lottery is paying on their behalf; ignoring the lottery outcome is a violation of that trust.
Note that a different kind of tinkering is perfectly fair. The user can reapportion tickets however they like before running the lottery. This represents the user’s desire to reapportion their own contribution. At an extreme, the user might pick one provider and give them all the tickets, guaranteeing that they will win that user’s contribution. The key is that this happens before the lottery is run, which means that every provider’s income is, in expectation, the sum of what individual contributors would like it to receive. Giving all the tickets to one provider is simply an assertion that you don’t want to donate to anyone else. Users are welcome to express any allocation they desire for their own contribution, so long as they play fair on the lottery in order to materialize the collective intended donation allocation.
In summary, Tipsy aims to encourage voluntary micro-donations through a system that stays out of people’s way but still lets them allocate their donations fairly. Tipsy’s focus on voluntary donations means that there’s no need for the kind of sophisticated transaction tracking framework required by “real” micropayment frameworks. We can get by with no server at all, which simplifies deployment, lets money go to the providers instead of the infrastructure, and removes any concerns about surveillance. In balance, Tipsy does introduce minor random fluctuations in the amounts individual providers receive, and demands that users trust the law of large numbers enough to follow through on the lottery’s chosen payments.
Tipsy had been a hobby project for Adam Marcus and Oshani Seneviratne, two students at MIT. Foo Camp East 2009 served its bridging purpose by connecting me to Keith Hopper who thinks about supporting public radio. And Keith hooked us up with Doc Searls who’s been thinking hard about customer-vendor relationships. Doc liked the Tipsy idea and incorporated it into his bigger picture. Doc’s taken the initiative to bring in a Google Summer of Code hacker, Ahmed Bakhiet, to implement his “vendor relationship management” framework, and will be incorporating Tipsy as the payment mechanism. So hopefully we’ll see it surface sometime soon. If you’re a content provider who’d be interested in beta testing the system when it’s ready, please let me know.