Some of you may know that I’ve been working on The Ruport Book, a free-content book about Ruby Reports. Mike Milner and I have really learned through trial by fire some of the pros and cons of DIY technical publishing in the last few months. I’d like to share some of my thoughts here in a mini-ramble in hopes of stirring up conversation and ideas.

The idea of open source books is certainly appealing. This is especially true when you’re talking about books that cover open source software. Unlike certain technologies that have reached some stable, rock solid point, most open source projects are in flux, and the same is true for their documentation. I’ve seen a couple examples I can think of as success stories, or at least as projects that really stand out as interesting from the reader’s perspective.

One especially well done book is Karl Fogel’s Producing Open Source Software, which is actually produced by O’Reilly under the Creative Commons Attribution-Sharealike License, with copyright retained by the author.

The other is The Django Book, published by Apress under the GNU FDL.

Of course, for two big publishers, both of which are quite friendly to open source and more progressive publishing models, this kind of work is still quite noticeably the exception and not the rule. I think the reason for this might be a pragmatic one: The resources that mainstream publishers are geared to provide are tuned for high-volume general audiences, and not even a majority of worthwhile open source projects fit in this category.

Still, it’s really exciting to see things in the Ruby community such as PeepCode Press which offers a really fair deal to authors, along with a generally hip feel that seems to jive great for a number of niche Rails topics. Nevertheless, an E-Book , no matter how well done, can’t quite address the same needs that a dead-tree copy of a book can. I mean… you can’t very well impress people with a large collection of PDFs, unless you’re a pirate, but a wall of books looks nice pretty much anywhere. Of course, there are also more practical reasons to have printed books, even for short works, but who needs those?

So we’ve got things like Lulu. Word on the street is that they don’t quite have the same feel of a mainstream publisher’s final product, and to be honest, anyone who says that is basically trying to tell you that a hang glider doesn’t quite have the same transportation merits as a 747. Though I haven’t heard this comment from O’Reilly, some other publishers use this to discourage authors from self publication, and my feelings on this attitude can be summed up in one word. Lame.

But you know what? We felt a little shaky at first deciding to go this approach with the Ruport Book because of that common criticism. Amazingly, _why rescued us without ever knowing it. Nobody Knows Shoes is awesome. If _why’s doing it… it must be cool.

Anyway, enough ranting and link-blogging, and a little more plotting and thinking and prodding.

Here are the things I absolutely love about the fact we decided to self publish the Ruport book:

• We own the book, and have the right to share it as we please with whoever we’d like, as well as allow direct community contributions to the content
• We can publish an extremely up to date book. Ruport 1.4 isn’t even out yet, and the Ruport Book covers it. Our first pre-orders will ship within a week of its release
• We are able to do whatever we want. Well… maybe not whatever we want, but close to it. Unfortunately, the idea of putting pacman ghosts on the front cover of the book were dashed by copyright violation concerns
• We decided to offer up 25% of our revenue to a nice charity called Engineers Without Borders. I doubt we could have made this fly with a major publisher
• No need to be secretive, our development has been transparent from the top down. You can even check the book content out of SVN
• By making the book available to our users as we’ve developed it, we’ve not only gotten some feedback about the work itself, our users have become more skilled with Ruport, and have made tons of interesting contributions. Questions that are answered in the book are becoming increasingly rare on our mailing lists, as well.

But those things come at a hefty price, one that makes us sometimes wonder if the seemingly small royalty percentage mainstream publishers offer is worth it after all:

• My friend Brad sent his chapters for Advanced Rails off to the ORA production department when he was ready for them to be formatted for print. The Ruport Book ‘production department’ is named Dinko, and he has a life outside of this book.
• We had to mooch from our friends, project sponsors, and from the community just to cover book expenses, let alone even think about advances to cover our time spent on the project
• We want to ship the book by the end of the year, and just decided to think about cover art, um… today
• Our editing department consisted of #ruport and the Ruby Reports mailing list, and numerous emails traded off-list.
• Our marketing department consisted of Mike and I mentioning the book at RubyConf and RubyEast

And this list could go on, but hopefully illustrates a point.

Now I’d like to leave you with the questions in my head as we prepare for this great experiment of publishing a book by ourselves. Maybe these will be interesting discussion points, or maybe you’ll think I’m crazy. Either way, I’d like to hear from you.

• Are developers willing to accept a work with a production quality of ‘as best as we can muster up’ in exchange for complete transparency, direct project involvement, and the willingness to improve the work over time?
• Are people sympathetic to the fact that print-on-demand services have some issues that you just wouldn’t see with a major publisher… such as $8 a pop production costs + revenue sharing cuts?
• To what extent is a ‘brand name’ important on a book? Do people buy on author name, publisher name, or a combination of both?
• Will the fact that the book is open source genuinely help people make the most out of the work? Can we hope to see translations, mashups, and derived works?
• How do we get the same benefit of a major publication in terms of reaching out to people who don’t already know about our project?
• What publishers can we lean on in hopes of eventually getting support from without changing the spirit of the project? Can maybe the Ruport book eventually have a nice animal on the front cover?

These questions are of course a little geared towards my project, but I think they apply to any reasonably popular but somewhat niche open source Ruby project out there. A dream of mine is that wherever it makes sense to do so, we could have free documentation. A hallucination of mine is that somehow we can make it so that authors, publishers, and readers can all benefit and get a fair deal, while still putting out bleeding edge content that looks and reads nice.

What are your thoughts?