As I was preparing to do a second interview with the writers of Relax with CouchDB, I decided to approach the community that's already reading the book (even though only 4 chapters have been released so far). Chris, Jan, and Noah are writing this book in a very open fashion to try to improve the final product and to build a community around it before it hits the shelves. I thought it would be interesting to see what some of the readers thought. I was lucky enough to get Rich Morin, @rdmorin, to respond (I've been a fan of his since the Prime Time Freeware days, see below). Rich has been participating in the Freeware community for a long time, and I think he brings some real wisdom to the table.
What attracted you to CouchDB?
Rich I've been looking around for a while for a way to handle the mixture of unstructured, semi-structured, and formally structured data that I encounter in mechanized documentation projects. I've designed a few schemas that make my DBM friends grow pale, but none that looked very easy to use, given that I'd have to encode my queries in SQL.
Ontiki is the current incarnation of a long-term mechanized documentation project. I'm planning to use CouchDB for it, along with Erubis, Git, and Merb. It should stretch the traditional notions of wikis quite a bit.
I heard about CouchDB in a talk by Ezra Zygmuntowicz (of Engine Yard and Merb fame) and decided to look into it. Although it's still a Work In Progress, CouchDB looks extremely promising. I particularly like the fact that it uses Ruby-friendly data structures (eg, lists, hashes, and scalars) and that it should scale extremely well.
Why are you participating in this kind of open review/development of Relax with CouchDB?
Rich As a frequent buyer of technical books, I generally look for books on topics of interest. I've bought WIP books before and have no problem with seeing material that still needs work. In fact, I like the fact that I can help to influence which questions get answered, etc.
What value do you think this level of openness will do for the book, good or bad?
Rich Several years ago, I was a small-scale publisher of book/CD combinations (Prime Time Freeware, for anyone who remembers :). When we did the book on MacPerl, we actively solicited user input and review (though we didn't charge for access to the PDFs). The responses ranged from nitpicking to well-reasoned arguments about pedagogical style. Almost all of them were useful (sometimes extremely so) in improving the book.