A while ago I gave a talk at the “Frankfurt Digital Night” at this year’s Frankfurt Book fair, making essentially three points: first, publishing requires – and has always required – to create and court communities of readers. Second, there are new digital tools emerging for creating and courting these communities. Third, in this context, openness in terms of APIs is becoming a feature.
Even long before the advent of the internet, probably even before the invention of the printing press with movable type, publishing was essentially a social network business, with strong network effects. The Matthew Principle lies at the heart of the dynamics leading to bestsellers: „For unto every one that hath shall be given.” – what is popular becomes even more popular. And the reason is that the utility – the reading pleasure – of the individual reader not only depends on how well written a book is, but also on whether he or she is able to share this experience with others.
Paradoxically, reading books combines solipstic and social practices. From a publisher‘s perspective, the social aspect is probably much more important than the solipsistic one. Because sharing the joy of reading a certain book makes others buy and read the book as well. And all bestsellers in the history – from the Gutenberg Bible over Harry Potter to Shades of Grey – were to some degree viral, rooting in social practices related to reading a book.
These examples of bestsellers teach us basically three things: first, literary quality is at best an only modest predictor of a book‘s success. Second, bestsellers are very difficult to predict. And third, it is the connections between readers and potential readers that matter most. The root cause for network effects is fact that the number of potential connections between individuals increases disproportionally with community size. As Clay Shirky (2008) has laid out in explaining the “birthday paradox“, a group of five readers allows up to ten different connections. In a group of 10 readers, there are already 45 potential connections. And adding another five readers increases the number of connections over a hundred. Creating communities of readers means turning potential connections into actual connections. And thus making them valuable for readers. But how can you do that?
What we can observe is a growing number of startups and businesses devoted to social reading, social publishing and, thus, to create and court communities of readers. One of the pioneers in Germany was Lovely Books, which allows its users to comment on and to recommend books to others, thereby offering the possibility for authors, publishers or shops to reach certain groups of readers. However, the majority of members of Lovelybooks still comments on deadwood books. The Berlin-based startup Readmill, in turn, totally focuses on interconnecting e-book readers. And one of the main features of Readmill is to foster sharing annotations and to allow collaborative highlighting in books. This collaborative highlighting is of particular interest because highlighting is something many people do anyway when reading books. Enabling to automatically and publicly share such underlines and annotations is the basis for topically connected communities of readers.
While lovely books and readmill focus on readers when harvesting reading data, another startup called Hiptype focuses on offering publishers real-time analysis of reading progress, demographics and so on. Hiptype even paints the picture of a new era of data-driven publishing, where books are literally re-written according to instant reader feedbacks. I have to admit, I don‘t know where exactly the path of data-driven publishing is leading us or whether it is a dead end. But what I am quite sure about is that all these cases – and there are many more outside – need access to real-time reading-data, provided by application programming interfaces – APIs: of reader apps, of online-stores, of social-networks, of other social reading platforms. Reporting on Readmill, Felix Knoke from Spiegel Online gets to the core of the matter: „Readmill gets interesting when as many other e-book reading programs and devices as possible feed the Readmill central server with data.“
For new services such as Readmill or Hiptype to thrive, openness in terms of APIs is necessary. When we are looking at today‘s Internet, what we see is a web that is turning more and more into a set of walled gardens. We have few platform providers, creating new borders and new rules in the digital sphere. These platform providers derive their power from, again, network effects. The huge installed base of users makes the platforms attractive for both users themselves and third parties – publishers, software developers and so on, who want to cater to those users.
And while the walls between these paltforms may have advantages in terms of security, they may also bear severe consequences for decentralized innovation in general and for bringing together communities of readers in particular. It is annoying that I can read my Kindle-eBooks only in the Kindle-Universe and not on any reading device I want. In the iOS-Universe I cannot even read books I bought on my MacBook Air. But when I want to share annotations and want to collaboratively highlight, openness in terms APIs really becomes a feature: I want to share my comments with others interested in the same topics, same authors or same books – independent of the reading device or book store they are using. The same is true for publishers wanting to experiment with data-driven publishing. They need data from as many readers as possible – independent of reading devices or online store they are using.
What we have right now is a battle of different, proprietary programming interfaces. With open programming interfaces that allow for data exchange among different platforms, the whole game would be transformed into a competition of service providers. For the small and creative startups, this means to open up their APIs and not make the mistake to engage in a battle of APIs they can only lose. Opening up APIs, however, requires coordination. Either, to make each other‘s APIs compatible and to agree on standards. Or to put pressure on the new Giants Google, Amazon and Apple to open up their APIs. In the best case, by making open APIs a feature, we may end up creating communities of readers that allow also smaller or medium-sized service providers to survive in the age of amazon.
The slides of my talk are embedded below: