Amazon, Shelfari, and LibraryThing
Aug 27th, 2008 | Posted in Writing | By Eric Hoefler
Amazon just acquired Shelfari along with used and rare book company Abe Books. Abe Books has been a long-time partner with and 40% investor in LibraryThing, a Shelfari competitor, so the Abe Books acquisition also gives Amazon a 40% stake in LibraryThing. A crowded shelf indeed. Details covered by Publishers Weekly and TechCrunch.
I’ve never been a fan of Shelfari: the UI is gaudy, the site is slow, there’s no way to make edits on large numbers of books quickly, and there’s very little room for user input or modifications. As for organizing your collection, Shelfari’s use of tags is so secondary that it’s nearly useless. Plus, if Amazon isn’t selling it, good luck getting it onto your shelf.
Tim Spalding, founder and CEO of LibraryThing, has more serious issues with Shelfari that I think are worth repeating:
As I’ve said before, I have respect for LibraryThing’s 40+ competitors, but withhold it for Shelfari. They were rather famously called out by me and by others in a series of blog posts exposing a program of spamming and of “astroturfing” (paid employees posing as excited users in blog comments). They apologized on both occasions, but I have, quite frankly, the greatest contempt for them, and for what book-based social networking will become if they beat out LibraryThing.
Picture a boot stomping on a human face forever. Well, okay, not that. But picture the book social network wars ending with a site created by music people who probably wouldn’t get that allusion, with advertising all over, with “community managers” “managing” conversations between book lovers, and under the shadow of what will sell books and not books’ other, greater values. In short, I believe there’s something “to” the idea of book-based social networking which they don’t get, and to which they are a danger. Yes, I’ve drunk my own Kool-Aid.
I’ve been a long-time user of LibraryThing. It’s quick, allows users to contribute to book details, has active and thoughtful discussions that revolve around the books, and is great at allowing users to organize their books easily in a variety of ways. I tend to think of Shelfari as the choice for people who like to look at shiny book covers sitting on their shelf and LibraryThing as the choice for people who like what’s between those covers.
I do have two gripes with LibraryThing, though. While the UI is faster and more useful than Shelfari, and allows for lots of great ways to organize and benefit from the information surrounding the books, the actual look of the site could be improved, particularly if it hopes to compete with Shelfari.
More importantly, LibraryThing, after a long series of promises, discussions, and flip-flopping, decided not to create an official Facebook application. This was a serious mistake, in my opinion. While many of my friends are book-lovers, only a few have that combination of book-lover and web-geek that would compel them to enter, tag, and discuss their book collections on a books-only social network. However, many of my friends will happily share what they’re reading with others on Facebook, and since LibraryThing doesn’t have an app through which I can do that, I have to use another service if I want to join in on that sharing. That’s a lot of word-of-mouth support for LibraryThing that just ain’t happening.
[Update: As noted in the comments below, LT still plans to develop a Facebook app at some point.]
| Print Post (Text Only)
Hello, Eric,
Your post illustrates — perfectly — why “free” solutions aren’t worth the price: your data is locked within a system where you have no control; these “success” of these systems are driven more by the ability to make the right business partnerships than the actual quality of the service; and, if your ability to alter the system is limited by the system itself.
Taken together, these factors point out the need to build this type of system using open source tools. If we wait for the corporate world to deliver these tools, we’ll be waiting a looooong time.
And, fwiw, Library Thing plus Facebook equals embedding one content silo inside another, as the advertisers/data miners benefit — we can do better with open source tools.
Hi Bill,
As always, thanks for your insights. I’m just a front-end user, so I really appreciate your perspective.
I take it you see Amazon, Shelfari, and LibraryThing as all closed systems, is that right? My impression is that LT is the most open to open-sourcing both its code and its data, though I don’t think that’s the present reality. I do appreciate that LT allows users to add and edit book information, and that the data isn’t limited to Amazon’s warehouse. I also like that LT tries to work with libraries. But, my background isn’t strong enough to see the flaws in what they’re doing in terms of open/closed systems. An area for research, when I find the time …
Thanks again!
Quick note/comment: As a fan of LibraryThing, books, and your blog I want to invite you to add me on LibraryThing, so I can take a look at your books.
http://www.librarything.com/home/intrepidflame
Hey Jabiz … and thanks.
And for anyone else on LT, you can find me here (username: sicheiiyazhi).
Wait! That’s not true. We didn’t decide not to create a Facebook app. We decided to create one, and it got hung up. We certainly plan to bring one out, and are sorry it’s taking a while. We have three coders, with one devoted exclusively to our library projects, so not everything is possible at once.
Ah … thanks for clarifying, Tim. It’s sometimes hard to keep the “official” decisions separate from the sometimes-lengthy discussions and debates in the LT forums. Of course, it’s the open-ness and engagement in those debates that makes LT’s community so strong!
Sorry for any misrepresentation.
And PS Tim … if you check back … any response to the concerns Bill Fitzgerald raises above?
Well, I’m unclear on what the criticism *is* exactly. LibraryThing allows you to export your data. The same cannot be said for the FB sites, although both our non-FB rivals allow it. We offer a host of APIs to our data—far more than our rivals. We are most strong limited by the Amazon terms of use, which is why our APIs don’t allow searching of our bibliographic data—because that would amount to an API to their API, expressly forbidden in the term of use we agreed to there. We do guard (and sell) two sets of aggregate data—tags and recommendations. We don’t feel that sorry to be doing so.
Oh, and we just released 1,000,000 covers free to the world for both commercial and noncommercial use. I think that will decimate the business of selling covers to libraires within a few years. So, we’re doing some good..
More generally, I think there’s an interesting discussion to be held about when open source hits large database systems. Even if LibraryThing were open source in software, it would still need a series of honking database servers to power it. We have more bibliographic data than the Library of Congress, after all. Someone has to pay for that.
Further, you need a lot of it the data before the service itself is valuable. It’s like Google. Even if Google were open-source, you wouldn’t have Google if you had the software. You’d need the data–and the hundreds of thousands of machines that find it.
Opening the data isn’t the answer either. Most of our data is user data. You couldn’t make dumps of that available, because some users are private and most would never consent to their data being moved around by others. We’ve had competitors spider our members and rebuild their accounts elsewhere—users went through the f-ing roof! 25% users may be into data portability, but 100% are against involuntary portability.
So, while open-source software would be nice, and obviously a system should allow export—as ours does and always did, you can’t get away from all of the logic of a silo.
Hello, Tim,
RE: “obviously a system should allow export—as ours does and always did” — Your system doesn’t allow export — your API’s, as described on the LibraryThing API page here: http://www.librarything.com/wiki/index.php/LibraryThing_APIs — allow for json embed, and/or querying the LibraryThing database. This is NOT export — this is querying the data contained within your silo. It’s nice, and handy, and all that, but it should not be confused with export. Also, the terms of your JSON apis explicitly forbid storing the data, with the unavoidable exception of browser caching. Your precise terms read: “Must be run as Javascript on user’s browser, not fetched by a server; cannot be stored, except for browser caching. Commercial use requires a hard (non-JS) link to LibraryThing on every page that returns results.”
This is a far cry from export. While it’s great that LT exposes an API, to claim that your data is open and exportable is a BIG stretch. Personally, I’m not that flexible.
RE: “25% users may be into data portability, but 100% are against involuntary portability.” — this is a complete red herring. User privacy, and the ability to export lists of books we like, and our recommendations of these books, are two entirely separate things. And the ability to export book data is easy to manage; while I understand the necessity in your business plan to hold that data close, and to manage its reuse via your api’s, claiming that there are technical limitations is just not accurate.
RE: “More generally, I think there’s an interesting discussion to be held about when open source hits large database systems. ” — What does this mean? Do you mean when large databases are accessible via open API’s? Or do you mean when large amounts of data are truly open and accessible via open standards, and content can be easily moved and recontextualized? Are there databases complaining that they have been struck, glove to cheek, by marauding open source code? Seriously, though, I don’t know what you’re referring to here.
Cheers,
Bill
Hey. You’re expecting the export to be on the API page. It’s not. It’s on the tools page. It exports as TSV and CSV. Our competitors have the same.
We don’t have an API to the same information for the reasons provided. To get the export you need to be signed in and it needs to be your account. Having an *API* to the Amazon data is expressly forbidden by the Amazon license.
The rest of your comment stems from that misunderstanding.
Hello, Tim,
I just joined LT to see the export functionality — thanks for pointing that out. You are right, I did expect to see that on the api page –
RE: “The rest of your comment stems from that misunderstanding.” — yeah, not so much. I missed the csv export of book titles because that is not something you are exposing via an api — fwiw, allowing the same data people can export via csv to be grabbed and exported using your API’s would be more useful, and would possibly work to increase LT’s exposure. As LT currently works, I would never recommend using it — however, if I could set something up where users on a site could import their LT lists, and update those lists in real time, and have those personalized lists be searchable *within another site*, that would be useful.
But that would effectively break down your content silo — In very general terms, content silos exist because they are required by a business plan, not because of any valid technical reason.
As things stand, I’d much rather see services built up around OpenLibrary — http://openlibrary.org/ — This resource feels more useful when it comes to building tools that are freely available, and replicable. Although their apis are a work in progress, it’s already a powerful tool, and has none of the usage limitations of the LT api.
So, yes, I was definitely wrong about csv export. And, that’s a nice feature, and, as you point out, one that is shared by your competitors. But the rest of what I said still holds: users are better off avoiding the silo.
Cheers,
Bill
We’re not connecting, and, I’m sorry, you’re not hearing. We *cannot* give out the bibliographic data via and API because doing that is forbidden by the Amazon API. It is a judgement call whether we can do the JSON-y widget or the export, but others have done it, and we think there’s wiggle room. But there’s no question that there’s no wiggle room about a straight-up API to the data.
As it stands, users can—and do—leave for other services. An API would, frankly, be less subject to that effect. People don’t use APIs to flee a service; they use them because they like it and want to use the data elsewhere. So your line of argument about the business case is just backward. I’d be happy giving that stuff out. But I signed a license agreeing not to. And Amazon’s remedy is to demand that all the data we retrieved from them be deleted. You want me to risk that by breaking their terms straight out?
One of the questions I raised in my original post was whether LT should move to non-Amazon data. We have a lot of other sources. But coverage would suffer a lot. Libraries have books, but not so many paperbacks. And nobody—but us!—has free covers; we’d have to buy them from Bowker or Baker and Taylor if we didn’t get them from Amazon, and under worse terms than Amazon has.
I too like OpenLibrary. It might give you some context to know that I was either the first or the second person to think of the idea, and start pushing for it. (Casey Bisson and I aren’t sure, but we were trying to get others interested in it before any of the current people got involved.) But OpenLibrary’s data is a fraction of what LT gets access to now through Z39.50 connections—and again doesn’t have paperbacks in great numbers. Like it as you do, have you tried to use it for a regular personal library? It’s not there. Not there by miles.
Hello, Eric,
I just came across this: http://drupal.org/project/bookpost
This is a nice piece that makes the process of building your own book site. From the project description: “The Book Post module makes it easy to post information about books. Any 10 or 13-digit ISBN placed between double curly braces in a post will convert into the book cover, title, author and publication info. All data comes from the Open Library Project, an open source catalog that allows users to add books and edit metadata. If there is no cover available for the book you want to post, go on the Open Library and add one!”
According to the description, the module also includes support for getting data from WorldCat, LibraryThing, and Google Books.
I’m still not entirely clear what Tim is saying in his comments above, but it’s nice to see that open source options are maturing.
Cheers,
Bill
[...] verschillende webapplicaties (in het Nederlands) hoef ik niet maken, die is er al. Nadat ik ook wat andere entries heb gelezen en zelf beide applicaties uitgeprobeerd heb, besluit ik Librarything te [...]