If You Build It, They Will Build

Publishing Hackathon logo

As the book industry focuses on reaching web-enabled readers, there’s an increasing need for technologies, like apps and APIs, that can be built quickly and altered often. This is why last month, a week before BookExpo America, New York played host to a significant publishing event: the Publishing Hackathon!

Contestants were given 36 hours to form teams, build a demo for a digital book discovery tool using the APIs made accessible to them, and pitch it to a panel of judges that included Richard Nash of Small Demons, Jennifer Rudolph Walsh of William Morris Endeavor, and Reddit co-founder Alexis Ohanian. Thirty teams were narrowed down to six teams who were given two weeks to polish their demos with the help of industry mentors. They presented their demos on stage at BEA and a winning team was chosen that won $10,000 and a pitch meeting with Hollywood agent Ari Emanuel.

The winning project, Evoke, attempts to connect readers with characters by evaluating the emotional response that a book seeker is drawn toward. It allows readers to “find new characters based on ones they already know and love.” Evoke also won the Children’s/Literacy and Pearson API mini-challenges. The judges also awarded a second prize to Captiv, which mines your Twitter feed to give you book recommendations. Also among the finalists were two location-aware apps that use geolocation to deliver book recommendations: LibraryAtlas and BookCity. It would be amazing to see apps like these have access to retail stock data so that retailer discovery, too, can become easier.

While hackathons are commonly held in development-drivencommunities and companies—British Airways even had one in the sky—the Publishing Hackathon is the first one of its size that I’ve seen in the publishing industry, and it’s getting great feedback (from The New Yorker and The Atlantic, no less). Competitive collaboration under a time limit—and sleep deprivation—can do wonders for producing functional prototypes of creative ideas. Publishers are in a unique position to entice this kind of development from programmers, data engineers, designers, project managers, and people with an interest in solving a specific problem because these folks are also book consumers. All they needed is a solid API, a way of exposing internal data so that it can be used externally.

Fast on the heels of the Publishing Hackathon, HarperCollins announced its BookSmash Challenge, which is an open call for developers and development teams to create functioning apps using their OpenBook API. The winner gets a cool $25,000 and HarperCollins gets to offload some of their R&D. Smart!

I have a lot of conversations with publishers about how they can standardize their bibliographic data to meet retailer expectations, but the conversations that I hope we’ll all be having more of soon are about how they can meet developer expectations too. HarperCollins’ API was launched last year and I think they’ve set a great example in making their book and author data programmatically accessible. The type of data you can get from it extends even to non-bibliographic stuff like author tour data for specific titles, which is a very cool building block.

If making your data accessible through an API isn’t immediately feasible resource-wise, then the cost-saving option is to use and promote external web services that already house your data and make it available for programmers. Our BiblioShare Web Services do just that and they’re totally free to use. We’ve even built a WordPress tool that can easily help even the n00biest user make use of all the awesome data that we collect in your ONIX feeds.

For publishers faced with the task of differentiating their brand, their books and their authors in a crowded market, APIs, web services and full and open data sets should be essential tools in their marketing and publicity tool box. I suspect we’ll be seeing more Hackathons, incubators and open calls like HarperCollins’ in the near future.