Moderator's note on Hadrien Gardeur: Years ago I urged Project Gutenberg to come up with a truly slick program to download, manage and display Gutenberg books. "A book tuner," I called the idea with radio in mind. Hadrien at Feedbooks had similar dreams and acted on them.
Hadrien's technology now helps various e-reading apps serve in effect as book tuners. These include such programs as Stanza (the iPhone reader shown at left) and FBReader (a possible candidate for official use on the next OLPC laptop). From within those apps, his technology lets you directly search and call up items from Feedbooks' collection of public domain classics and contemporary works. Stanza also lets you enjoy other collections, including, yes, Gutenberg's. In another publishing area, Hadrien and colleagues are striving to greatly simply the publishing process for houses wanting ePub output. He is well qualified for such tasks, as the holder of a computer science engineering degree from Ecole supérieure d'Informatique, Electronique et Automatique.
Below is Kat Meyer's Q&A with Hadrien, the latest in her Digitizers series for TeleRead---for which she also interviewed Neeland Choksi, COO at Lexcycle, the company behind Stanza. Also see Mac Slocum's Gardeur interview, done during O'Reilly's Tools of Change conference. - D.R.KM: Tell me about Feedbooks and its unique technology.
HG: First of all let's describe Feedbooks as a technology rather than Feedbooks as a service. Usually, you'll notice two kind of workflows for digital publishing:
1. Self-publishing services such as Amazon DTP or Smashwords use direct conversions, which are very easy to use from a user perspective but provide low-quality e-books and very limited possibilities.
2. XML-based workflows let you create the source based on a certain DTD (TEI, DocBook, DTBook) and generate the different end-formats using XSL.
The second choice is much better if you'd like to create e-books in multiple formats and generate good-looking e-books, but it requires some specific technical skills.
'Workflow everywhere' philosophy
What we're building with Feedbooks is a third way---we apply the main principles of an XML workflow but use standard Web technologies to potentially integrate our workflow anywhere.
Our goal is to create something completely seamless that any user can use to create and distribute high-quality e-books. Currently, publishing on Feedbooks is strictly limited to our Web publishing interface, but in the upcoming weeks we'll open our workflow. Since we're using standard Web publishing technology, a lot of tools will be directly compatible with our workflow from the start and any developer will be able to create new ways to interact with us.
Feedbooks built as a Web service rather than a Web site
The other important technical component is the fact that Feedbooks was built from scratch as a Web service rather than as a Web site. That's the reason why we were the first service to distribute e-books through Stanza on the iPhone; and that's also why we're also distributing content through Goodreads or FBReader.
Lexcycle did a tremendous job with Stanza to create a standard way of distributing e-books, using Atom as their catalog format. But if we want to create a real market for e-books on mobile devices, and compete with Amazon (the Kindle is a "cloud retailer," unlike other traditional e-book retailers and that's why Amazon can provide such a great shopping experience), we need to constantly innovate in this field.
For shoppers: A one-click process in time, from Feedbooks and friends
Aside from a catalog format, we need a standard way to authenticate users if we’d like to turn shopping into a one-click process, to improve how we can browse through the content available, to make sure that subscriptions can be automatically delivered to a device or to create a social layer to the reading experience (sharing current reading position, bookmarks and annotation).
We’re constantly improving our technology on the distribution side, to make sure that we can create such an experience.
KM: Do your plans to provide a great shopping service (similar to the Kindle’s) include plans to partner with publishers? I understood that you had long-term plans of seeking partnerships with publishers to provide content for sale. Have you got any closer to this goal?
HG: Our main focus right now is on opening our digital publishing workflow. We’ll discuss the rest of our plans once we’ve reached that goal.
KM: As Feedbooks is an “international” company (you are based in France, but have a web-based, international market), have you begun to consider territorial rights and distribution issues? Is it a concern at all with any discussions you may be having currently with publishers? Do you think copyright laws need to be changed to address the global digital world?
HG: In a purely digital market, territorial rights do not make much sense and can be very confusing for the consumer. We’re stuck with these territorial rights because of the paper market, and it’ll take some time to resolve this issue. It’s not just books: try to access Hulu or Pandora outside of the U.S., for example (and even more recently, Last.fm).
KM: In terms of opening up Feedbooks’ workflow to developers—is this something you hope will become more standardized—in other words, do you hope to see developers creating new and better ways of working with Feedbooks that other Feedbooks users will be able to benefit from? (Is this a goal?)
HG: It’ll be fully based on standard technologies from the start, which means that existing software will be capable of publishing content to Feedbooks. We’ll have to extend it though to support things that are specific to digital book publishing.
Potentially anything is possible: we could for example have integration into desktop applications, blogs, social networks… We can reproduce the ability for an author to directly use a Word or an HTML file as a source, except that we would give him the ability to do some post-processing rather than relying purely on conversions.
It’s hard to guess how exactly it might be used by developers but that’s the point of having an API too: take a look at Twitter, most best practices and innovations were introduced by users or developers that are not affiliated to Twitter as a company.
In favor of Social DRM
KM: I simply must bring up the wonderful world of DRM. In prior discussions, you have brought up the idea of “Social DRM,” which I think is really great term and an even better concept. Can you briefly describe for our readers what you mean by social DRM, and why you are an advocate for it? [Bill McCoy at Adobe or perhaps the Pragmatic Programmers may have been the first to use the actual term. – D.R.]
Have your broached the subject of DRM and/or Social DRM as a solution with potential publishing partners? What has their response been?
HG: Watermarking is what’s most commonly described as “Social DRM.”
Actually, the more I work with e-books, the more I think that we’ll need to add identifiers that were not included in the file in the first place. A lot of e-books do not use unique identifiers or rely on identifiers that you cannot link to the rest of the cloud. If we want to offer services such as annotations or shared bookmarks in the future, and link content/reading system to the rest of the Web (social networks in particular), we’ll need to add reliable identifiers in e-books.
In this case, we might as well also add an identifier for the consumer and the consumer’s name.
Better than traditional DRM even with negatives
It does raise some concerns over privacy, as someone might steal your device and distribute the content that you bought, but overall social DRM is a much better alternative than traditional DRM. With traditional DRM, you never really own an e-book; you’re renting the e-book for as long as the specific DRM technology is in production. Once the company behind the DRM technology decides to pull the plug (and they often do, as we’ve seen in the past) the consumer is left with useless files.
This type of DRM does make sense for libraries where you’re not supposed to ever own the content, but it is a lot more problematic for retailers.
The first step for the industry would be to have DRM-free, Social DRM and DRM available as options for content producers. I really believe that traditional DRM should be more of an opt-in than an opt-out system for any content producer.
KM: What has reader feedback to Feedbooks been? Has it changed as you have evolved as a service, er, I mean—technology?
Feedbooks’ Kindle download guide
HG: Interesting question. For example, right after the release of the Kindle I found an easy way to distribute content to the Kindle, through what I called a download guide. We immediately had excellent feedback about this feature and I quickly realized that mobile distribution would be very important in the future.
That’s the reason why I immediately focused on creating a mobile Web site, and released an updated API right before the release of the iPhone 3G. It was an excellent timing as we were basically at this point the only service distributing ePub files and with a proper API: that’s why we were the first content provider to deliver content on Stanza.
The “guts” decision to favor ePub
On the other hand, if I had constantly listened to user feedback I would’ve also littered Feedbooks with support for dozens of legacy formats. I remember when we decided to add ePub support: a lot of people on MobileRead were asking for Sony proprietary LRF format instead, and did not understood why ePub was so important from our point of view. Supporting ePub before everyone did was one of the best strategic decisions that we took so far, but that’s exactly the sort of evolution that didn’t come at all from user feedback.
I believe that user feedback is very important for iterative improvements, and that’s the main reason why I try to interact as much with our user base through Twitter, blogs or forums. But for certain breakthrough features, you need to rely on your own guts. [Moderator’s note: Although we gave a Linkedin link very early in this post, to document “well qualified,” you’re much more likely to find Hadrien on Twitter these days. – D.R.]
KM: Correct me if I’m misstating this, but Adam Hodgkin at the Exact Editions blog recently posted about the e-book strategies of Apple, Amazon, and Google concluding that, by staying out of the proprietary e-book wars and just be a middleman between publishers and readers, Apple might win the game. And in a great post responding to this, Mike Shatzkin has noted that there are arguably many more players in the game then those three, and that “the e-book thing is just going to get more complicated.” Do you consider Feedbooks one of the other players? And what is your take on this game—complicated/simple/as yet unknown?
The risks of Apple’s 30 percent solution
HG: It’s far from simple, and I agree with most of what Mike Shatzkin said.
Apple in-app transaction system isn’t suited for e-books at all. You cannot create a sustainable business with Apple taking 30 percent of the revenue for something basically equivalent to PayPal.
It is possible (and necessary for platforms such as Android or Blackberry) to create an experience as nice as their in-app transactions but I’m afraid that Apple might ban applications using a different payment method. It’s a tough situation for companies such as Lexcycle that entirely rely on the iPhone platform at this point: Apple as a platform provider can be very unreliable and completely disrupt your business model.
Their subscription system on the other hand might work for things such as newspaper subscriptions, or manga (released as individual chapters every week like in Japan).
Mobipocket as a “complete mess”
Amazon built a fantastic cloud retailer with their Whispernet service, but using Mobipocket as their core format was a horrible decision. Mobipocket is a complete mess (HTML tag soup with all sorts of undocumented proprietary extensions) that I unfortunately have to support because of the Kindle. They do behave a lot more like Apple than themselves on this project, with this fully vertical and proprietary approach.
Google’s strategy is “as yet unknown” from my point of view. Their 500k ePub files were more of a PR trick than anything else. Google is a very smart company that can build top notch technology but I’m rather unimpressed so far by their barely OCR’d files. I guess that we’ll have to wait a little longer before we fully understand what Google will do.
Of course there are a lot more players in this industry and Adobe is one of the most important ones. They were instrumental to the success of the ePub standard so far, and with Digital Editions available soon on a large number of devices, everyone should keep an eye on Adobe.
With millions of files distributed and the technology that we’re working on, I guess that Feedbooks is in a way one of those “other players”. So far the whole game is already complicated and it’s going to get even more complicated very soon. Adam Hodkin’s conclusions are too simplistic, it’s too early to predict anything.
What and how Hadrien is reading right now
KM: Well, since we’ve covered the complicated stuff, let me ask something very cut and dry (and fun for those of use who want to know more about you). What are you reading right now, Hadrien? And how are you reading it?