The organizers of the Publishing Hackathon got a lot of things right. The space was wonderful, the food was publisher-quality, and the publicity was excellent. (I admit that even the hype-laden website blurb that I criticized did its job well.) The variety of sponsors lent an open and collaborative atmosphere to the event. Even libraries were represented. It was a good decision to set a theme of "book discovery" for the event; this helped focus the participants and created a set of discussions that are likely to continue. Having the final presentations on the floor at BEA was brilliant. The party afterwards was fantastic.
The projects that were created at the hackathon won't solve the book discovery problem. The winning project, Evoke, won because it's both plausible and totally out of left field. But it's likely the knowledge gained by hackers and publishers during the process will advance the state of the art.
As with anything new, there are a number of things that could be improved on in future hackathons. Here's my list:
- Everyone is a VIP. During the presentations, three rows of chairs in the front were set aside for "VIPs". No one sat in them. Next time, make the hackers the VIPs.
- More prizes, more fun prizes. The gift economy of hacking and the cash economy of startups both need nurturing and cross-pollinating. Having one cash prize of $10,000 is less motivating than 5 $1000 prizes, and how do you split it if you have a big team? A prize consisting of dinner at a nice restaurant or some theater tickets might be a stronger motivation for participation.
- Hacker Judges. None of the 10 judges for the 2013 Publishing Hackathon actually do any hacking. Only 3 of the 10 qualify as technologists. None of them are designers. (As far as I know.) If you want to send a message that design, technology, and code are important to publishing, then build that dialogue into the judging process as well.
At first, I was seriously underwhelmed by the BookSmash challenge. It seemed to be a way for HarperCollins to prop up the sad, desolate ghost towns that are the OpenBook API and the OpenBook Content API. (The OpenBook API was launched in April of 2012 with the support of Mashery; the forums had attracted exactly one developer in the last year.)
But perhaps I judged prematurely. The competition website claims that a number of authors, including Peter Drucker, Eloisa James and C. S. Lewis, will be "making their full works available via the BookSmash Challenge version of the OpenBook API." This could be really exciting, but as far as I can tell, it seems to be a bit of an exaggeration. I checked James' Desperate Duchesses; the content API returns the first 20% of the work. I tried Prince Caspian and got this result:
epubFetch unable to display this book
Sorry, we have not loaded this book into the system as yet.
We are loading books on a regular schedule, so please check back.
Still, I can imagine some interesting things that might be done with this data.
Update June 18: Have been working with the friendly people at HarperCollins to iron out documentation issues that had been blocking my access. I'll put some hints in a new post.
/START RANT/ In 2013, Metadata APIs like Harper's are NOT enough. The metadata is not very good, and there's not enough of it. Why would a sane developer go to HarperCollins for product metadata when she could go to Amazon or Google Books and not have it limited to HarperCollins products, not have it limited by HarperCollins Terms and Conditions (which forbid any commercial use), AND have the selling price included, too??? Also Prince Caspian Movie Tie-in Edition (digest) is NOT the title of a book! If you want interesting things to happen with your metadata, let developers download THE WHOLE DATASET! That's how you get the data to Amazon and BN, and that's how you should get it to developers! /END RANT/
It's like Rick Joyce said. If you want people to build cool things, you have to give them lots of cool bricks.
0 comments:
Contribute a Comment
Note: Only a member of this blog may post a comment.