Frances Pinter and David Percy have made an excellent documentary film about business models in the publishing world that use Creative Commons licenses.

Frances has been heading a CC-based publishing project in Africa. It is the Publishing and Alternative Licensing Model of Africa (PALM Africa), is based in Uganda, and South Africa, and she tells me the Ugunda project is going especially well. She also tells me she’ll be soon expanding this idea into other publishing spheres, which is very exciting.

Percy is an award-winning film-maker, and so the production quality of the film is quite high. The film is 30 minutes long, with three 10 minute interviews (to fit into Youtube’s ten minute max).

The interview with me covers a wide range of my background, from Lyris (which went fairly big, and I sold 2 years ago) to Magnatune and BookMooch.

Here is the interview with me:

and the other two interviews…

With Tom Reynolds, the author of Random Acts of Reality:

with Timo Hannay of Nature Magazine:

A very nice story about BookMooch in the newspaper New York Daily News.


My thanks to fellow moocher Norana, for being in the photograph!

I find it interesting that the one fact they got wrong, is that the article believes BookMooch requires members to send out two books for every one they receive. I think the point system is a bit too complicated to explain, as articles are frequently making factual mistakes about it. I’m not sure how to improve it, though.

Several people suggested in my previous blog post that the newly introduced system for “ask me first” has too many clicks.

Instead, they’d like to see it be possible for someone to mooch immediately from an “ask me” person, and the book owner is able to reject the mooch without any penalty.

That would definitely work, and be a less complicated workflow. It also has the advantage of removing books from circulation that are in an “ask first” stage so that others aren’t frustrated by being told they’re there, but not being able to mooch them since they’re reserved.

What do other people think of this alternative?

To recap, this would mean that the current “ask first” workflow would go away, and instead anyone would be able to mooch from an “ask first” person. People with “ask first” would get a slightly different “someone has mooched from you” email, that would make it clear that they can reject the mooch without any penalty.

Despite having put a bunch of time into programming the new “ask first” mechanism, I am open to switching over to this different way of doing things, esp if people think it’s better.

I do think this alternative idea has merit, so I’m opening it up for discussion. My opinions on this topic are not well formed yet, which is why I’m not expressing them. I really want to hear what others think.


On your member profile page, you have the option to indicate whether you are willing to send your books to other countries.

The choices are:


Until today, the “ask me” option wasn’t enforced by BookMooch, it relied on people doing the right thing themselves.

There were two big problems with the old system:

1) if you were honest and asked first, someone else might mooch the book while you were waiting for the book owner to read their email and give you permission.

2) people could (and did) ignore the “ask me” setting and would mooch a book right away, without asking. This left the giver in the awkward position of rejecting the mooch request, and having the rejection as part of their permanent record, even though they did nothing wrong. Some people felt it was legitimate to mooch-without-asking, because of the problem above (someone mooching your book while you wait for permission).

As of today, BookMooch:
* enforces the “ask me” setting
* allows the book giver to say “no” without penalty
* reserves the book for 7 days for the requester
* provides workflow tools to make the process easier.

Here is how this all works.

When you go to mooch a book, if the only copy available is from someone who says “ask me first”, then the page will look like this:


Notice how the other fields normally displayed on the mooch page are not displayed, since the only real option you have at this point is to ask for the book.

If there are several copies of the book available, the “ask first” sources will be placed at the bottom of the page.

The next step is to send your request. You can include a comment if you like, but this isn’t required.


your request is confirmed:


The book is automatically reserved for 7 days for you, so that someone else can’t mooch the book while you are waiting for a response.

The book owner receives an email that looks like this:

Subject:  BookMooch: (United Kingdom) will you send to my country?
Date:     June 11, 2008 3:39:28 PM BST

Are you willing to send this book to my country? (United Kingdom)

Title:  The Total Money Makeover: A Proven Plan for Financial Fitness
Author: Dave Ramsey

Please click this URL to let me know:

Note that this email request is sent From: the requester’s email address, so that the book owner can reply by email to the request.

When the book giver clicks on the URL in the email, they will see this page:


notice how the YES choice is the much bigger button, to make it easy to differentiate between the two.

After the book owner clicks YES or NO, an email is sent to the requester.

The YES email looks like this:

From:     BookMooch <>
Subject:  BookMooch: yes! (The Total Money Makeover: A Proven Plan for Financial Fitness)
Date:     June 11, 2008 3:39:28 PM BST

Yes! I am willing to send my book to your country!

You should mooch it now:

Title:  The Total Money Makeover: A Proven Plan for Financial Fitness
Author: Dave Ramsey

and the NO email looks like this:

From:     BookMooch <>
Subject:  BookMooch: sorry (The Total Money Makeover: A Proven Plan for Financial Fitness)
Date:     June 11, 2008 3:39:28 PM BST

Sorry, but I have decided not to send this book to your country.

Thank you for asking, though!

Title:  The Total Money Makeover: A Proven Plan for Financial Fitness
Author: Dave Ramsey

Notice that the email address of the book giver is *not* given in the automatically-generated replies. This is on purpose, so that if the book giver chooses not to give out their email address, they don’t have to. Also, it might make people nervous to refuse to send a book when the requester has their email address, out of a fear of retaliation.

If you deny the request, the 7 day reservation is removed, and anyone can once again mooch the book. If the book giver doesn’t respond within 7 days, the reservation will expire on its own.

There is an element of trust in this process, that I want to describe now.

When you request a book in this way, your own email address is the From: on the request, so that the book owner can easily correspond with you. For example, they might simply reply “sure, no problem!” and not bother clicking the URL. Or, a dialogue between moocher and owner may ensue, such as the book owner looking up the postal costs to mail the book, and replying later.

To support this informal dialogue, I decided to let the requester mooch the book once they have asked first, even if the book owner has not clicked YES or NO yet. The reason I did this, is because I tend to not like computer systems that require people to do everything their way, and which don’t support the reality of human interaction.

In other words, after you send an “ask first” request, if you get an email back from the book owner saying “sure, go ahead and mooch it!” you can go and mooch and the system won’t stop you, because you’ve asked for permission, and BookMooch assumes that if you’re mooching after asking for permission, it must be because you’ve obtained permission.

The downside to this approach is that someone could click “ask me”, and then 5 minutes later, mooch the book, even though the book owner hasn’t yet replied. In that case, the book owner would simply reject the mooch, and give negative feedback to the moocher, as well as (possibly) reporting them for abuse.

I’d like to give this “loose and friendly” approach in place for now. It would be fairly simple for me to require the book owner to click YES before the international-mooch is allowed, and if it turns out that needs to happen, I’ll do that.


June 11, 2008

A new feature was added today to BookMooch, which allows you to reserve a book for your friends, or for a specific member. The reservation can be set to automatically expire.

The motivation for adding this “reservation” feature was the following scenarios:

1) Libraries: many of the people I’ve spoken to at Libraries have indicated a preference for giving other libraries first-choice at the books they’re giving away. This has been a “must have” for many of the libraries I’ve spoken to.

2) Friends: lots of people want to offer an in-demand book to a friend. That friend may be a real-world friend, or one you made in BookMooch. I’m often having dinner with a (real world) friend, and the conversation turns to books we’ve recently read. For example, my friend Victor had just visited Canada and picked up the not-yet-released-in-the-USA new book by Salman Rushdie. He wanted me to get it next. In this case, he just listed it and I mooched it before anyone else, but a reservation system would have been nice.

3) Privacy: I’ve encountered many people who don’t want to use BookMooch because they don’t want to give their postal address out to strangers. These people can initially choose to trade books with people they know, and slowly build out their trust-relationship with others on BookMooch.

4) International requests: when you ask someone from another country, if they’re willing to send you a book, it’s a common sight to have the book mooched by someone else while that email request gets answered. I’ll say more about this scenario in the next blog posting.

5) International exceptions: if you set yourself to “I will only send books to my own country” you can make individual exceptions to this by reserving a book for someone. They’ll be able to mooch it, no matter what country they live in.

6) Already occurs: people already reserve books for each other on BookMooch, by putting a condition note on the book like “please don’t mooch this, it’s for my friend XYZ”

Reserve: when adding a book

When you add a book to your inventory, there is a new “reserve” button. This is what the page looks like:


Also note that I’ve reorganized this page, because previously all the buttons appeared on the bottom, and this was visually very confusing. Now, things you want to do to the book you just added are to the right, and the two most common next steps (undo/add-another) are on the bottom.

Reserve: from the book details page

A “reserve” button appears on the book details page, when the book is in your inventory:


Reserve book for…

After you click the “reserve” button, you can choose who to reserve the book for:


You can reserve the book for your friends. This is the first time the friends feature has been used at BookMooch, but when I created the friends feature two years ago, this was specifically one of the uses I had in mind. I know that some people would prefer to separate the “friends who I want to reserve books for” from “people I am friendly with”, and perhaps have two kinds of friends, but I thought it’d be better to keep the friends feature simple, even if it meant friends could mean slightly different things in different contexts.

You can also reserve a book for a specific member, or several members. You type in their usernames, or their email address, or their display names. For example, I have two accounts (one for when I’m in California, one for when I’m in London) so if you type “John Buckman” in as who to reserve the book for, you get this page:


FYI, this is also how the “give points to a member” feature works on the charity page.

One techie note: if you enter several names in, and one of them is ambiguous (such as if their name applies to several members) then BookMooch will tell you that person is not a member, and refuse the reservation. If you enter just that one name in for the reservation, then BookMooch acts as you’d expect, and lets you click on the list of which member you actually meant. The reason for this, is that if several names are ok, but several are not, it would be a complicated user interface to let you fix some of those members, but retain the others, and this is probably an infrequent case anyway.

BM Admin Mark W thinks that the label for this field, being the plural (“reserve it for these members”) may confuse people, who may (erroneously) believe that they can’t reserve the book for just one person. I’d like to hear if other people agree with that. Alternatives could be “reserve it for:” (simple, but perhaps too short) or the clumsy-but-clear: “reserve it for this member (or these members)”

How long?

By default, a reservation lasts 7 days. Until that time expires, nobody can mooch this book from you, unless the book was reserved for them. The BookMooch software enforces this. After the reservation expires, anyone can mooch it. The reservation expiration date is shown when someone tries to mooch a book.


You can simply change the reservation from 1 day, to forever:


There is bound to be some controversy about books reserved forever, and I acknowledge that. However, there may be some reasonable uses for that, such as some books that Libraries only want to trade with other Libraries. I’ll be watching how the reservation system is used, and listening to what the BM community has to say about it.

Recommend the book

Once you’ve reserved the book, you have the option of sending an email recommending it. Click on “recommend” and the To: field is filled out with who-ever you reserved the book for, including recommending it to all your friends.


While some people may irritate their BookMooch friends by recommending books too often, note that only confirmed friends will receive these emails. In other words, someone has to invite you as a friend, and you have to accept their invitation, before you get these emails. And, it’s very easy to “delete” a friend relationship, especially if that person is sending you way too many book recommendations.

Changing your mind

The reservation you made appears on the book details page. You can cancel the reservation or replace it with a different one:


Mooching from friends

When a book is reserved for someone else, and you try to mooch it, the book is displayed, but a “Reserved for:” field is displayed, as well as “Reserved until”


note that the word “friends” is linked, so you can click on it, see who this person’s friends are, and ask to add this person as a friend.


If they approve you as a friend, you’ll be able to mooch from them:


If a book is available from multiple people, if any of the copies are reserved for you, it will be displayed as the first choice.

Overcoming Xenophobia

Many people set the BookMooch Profile to “I only send books to my country”.

Until now, there hasn’t been a way to make exceptions. Maybe you are willing to send books to your friends in other countries?

If you reserve a book for someone, they can mooch it, even if your profile says “I only send books to my country” and that person lives in another country.

If you reserve a book for someone, they can mooch it, no matter where they live.

In the graphic above, if you look carefully you’ll see that my own profile in the UK is set to “I only send books to my country”, yet the person who is mooching from me (though I hid their address) is in the USA.

Wishlist notifications

One area that could be improved is the interaction between emailed wishlist notifications and the reservation system.

Currently, reservations have no effect on wishlist notifications. That means you might get a wishlist notification for a book that you can’t mooch right away, because it’s reserved.

I decided on this course of action for a few reasons:

1) it was easy. All the other choices were really damned complicated. I spent 1/2 a day trying to program another approach before giving up on it.

2) it isn’t clear what the right thing to do is. Should no notifications be sent out on reserved books? Or just to those who are on the wishlist notification list, but who the books are reserved for? What should happen when the reservation expires? Should notifications start from scratch at that point?

So for now, no change to how wishlist notifications work, but if it becomes a common source of complaints, I’ll revisit this.

For programmers

The “userbook” API function now lets you set a reservation on a book (and reservation expiration date) when you add the book to your inventory. Also, mooches of reserved books will be declined, unless they’re reserved for you or the reservation has expired.

The “userid” API call will display any reservation that user has placed on their book.


Note that reservations, like condition notes, are stored in our database with the member record, not with the asin (book), since they’re not a permanent attribute of the book, and only apply to one user’s copy, and so reservations (like condition notes) should vanish when the book is mooched. The “expires” date field, like all other dates in the API, is expressed in standard “epochal time” (seconds since 1970).

Phew, that was a long blog entry.

I’ll be blogging separately (after lunch) about a new system for “ask me, I might be willing to send my book to your country”, which also uses the reservation system.

I’m experimenting with some changes on BookMooch, in order to deal with some of the growth the site has experienced.

That means BookMooch might be a bit slow for the next 48 hours, while I try a few experiments, enabling and disabling various technologies.

Update on Tuesday, June 3rd: I’m done with my tests, and BookMooch should be fast again now.

An aside: I received an email from the New York Daily News today, and they asked me how many mooches there are per month.

I wrote her:
In the past 30 days, 65,263 books have been swapped. We’ve grown a lot recently: on January 1st, the past 30 days yielded 38,948 swaps, so that we’ve grown 67% in the past 6 months.

Notes for techies…

The rest of this blog entry is only interesting to sysadmins and programmers, for those interested in the tech details of what I’m up to…


Pretty much every page at BookMooch needs to alphabetically sort a list of books. Sometimes, like with an inventory, it’s a small list, but other times, such as a search for “science” or look at a topic like “fiction”, there are a half-million books to sort.

I have to use a custom sort algorithm, because people want books sorted by “Author’s last name, Author’s first name, then book title”, and it can be tricky to figure out what an author’s last name is. Hence, a custom sort.

To speed up the sorting, I maintain a database table, which for each ISBN, has the pre-built “sort key” for each book (author’s last name, etc…). I then load that up into memory.

Nonetheless, sorting a half-million books just for one user’s page request is pretty time-consuming.

So, what I do is save the sorted results in a disk cache, so that if the same unsorted list of books is wanted, presto! it’s already there, all sorted.

However, if that sorted list changes even by just one book (which it would frequently if it were a search for “science”) then that cached, sorted list of books isn’t of any help.

Also, that’s a lot of writing to the disk, especially if a lot of those cached results aren’t useful.

This “sort cache” gets pretty big, about 10gb in a week’s time. Big enough, that using the cache isn’t nearly as fast after a few weeks as when we started, which is why sundays (when we backup) get slower after a few weeks.

Tomorrow, I will try a relatively small (100mb) in-memory sort cache, to see what the performance characteristics of that are. I’ll use an MRU cache algorithm, and that should speed up common searches and “next/previous” page requests, while not causing disk writes and having to delete old cache entries.

slow drive reads

Web site usage of BookMooch is currently at 400,000 page requests per day, of which 75,000 of those are searches. This is a 50% increase since the new year, and I have no reason to think the growth will stop.

The BookMooch database, at 14gb, is getting a bit large to hold in memory, and a I foresee a time, soon, when most of the database won’t fit in memory. Putting the database in memory is what I’ve been doing thus far to increase performance, and that technique has worked well.

Unfortunately, disk read speeds are pathetic, at around 1200k/second (peaking at 6mb/sec). They’re this slow, despite my using the newest, highest-speed server-class hard drives. I believe they’re this slow because the database mostly does small random-access reads, which are notoriously inefficient.

If I restart BookMooch, I generally pre-load the entire database into memory before letting the public at the site. However, this now takes almost an hour, which is a long time to be down. Today, I just put the site up without preloading the database into memory, so that it runs slowly, but it’s available right away, and the database loads into memory over the course of a few hours.

I’m thinking that a possible solution to my performance problems is to use a solid-state-drive (SSD). The random-access read times are amazingly fast, but random writes are not so fast.

My experiment today was to turn off the on-disk sort cache, in order to lower the number of disk-drive-write operations I need to perform. That’s why BookMooch is running slowly right now. I want to see, however, once the memory cache is filled, how much of a performance hit this causes.

I’m looking at the drives from Mtron and this SSD drive in particular. This blog by the CTO of Spinn3r has many postings about SSDs in server environments, and the results are encouraging.

Over the next few weeks, I’m going to try tweaking some things, and will likely switch to an SSD as the main BookMooch drive.

Update the next day: disabling the disk cache caused too big a performance hit. So, I tried using a 1GB in-memory cache instead of the on-disk cache, and that seems to work well, so that’s what I’ll stick with for now. Speed is good, though the server-load is higher than usual, but this may be due to the fact that I’m recalculating “recommended books” for each book as people visit them, whereas previously the recommendations never changed. I won’t know for sure for a few days. The web site feels very responsive, though.