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?


Well, I dunno about Real Publishers, but I'd say that Lulu products fall firmly into the Good Enough category. I'm planning to use it for an ultra-small product (likely run about 50) next year and ordered several books of differing sizes and forms to evaluate. While I might hesitate to use it for something as hefty as the Pickaxe book, say, I'd happily use it for less.
I buy on author name or review. It's extremely rare I'd buy because of the publisher. Even good publishers have some poor books come out of their stable. No-one is exempt from that, even O'Reilly.
I don't care about production quality in terms of the paper or the binding as much as I do about the layout and pedagogy. O'Reilly's Head First books are a good example of where a unique style can do wonders for sales. I seem to recall New Riders were quite laissez-faire and creative in terms of publishing tech books at one point, but they were swallowed up.
As an author, on the other hand, I'm glad I went with a "real" publisher for "Beginning Ruby" even if it means I've made far less money than I could have (per unit), because.. you don't really write books for the money. It's all about having books on shelves, name recognition, and reaching a bigger audience than you can alone.
Oh, and another publisher worth mentioning is Geoffrey Grosenbach's Peepcode (peepcode.com). I hope he really makes it fly as the production quality is great but it's very small and independent, as you know.
It looks like your text in SVN is in Textile format. Quite a few of the self-publishing companies I've seen want PDFs (PDFs actually make sense for a printed book). I was wondering about your planned workflow. Textile -> PDF? Textile -> DocBook -> PDF? Something else?
I'm just getting started on a small-audience technical book myself, and was planning on using OpenOffice to write the text, followed by Scribus for page layout, illustrations, and conversion to PDF. I'm intrigued by the idea of doing the draft in Textile (for one, writing the text in TextMate using Textile would be much more pleasant than doing it in Ooo :-)). I'm only one chapter in, so it wouldn't be hard to change now if there's a better way.
It seems that one advantage of CreateSpace (owned by Amazon) over Lulu and some of the others is that your book goes right into the Amazon system and is available for immediate order (as opposed to merely being "available through" the Amazon system, with a multi-week shipping time). They also charge less up front than some of the others (zero, if you use one of their ISBNs). On the other hand, they seem to take a larger bite of the retail price (this is hard to judge in general, as the methods the different companies use for pricing don't fully overlap).
First let me say that this is really interesting topic and I'm glad you decided to blog about it. It's interesting to see how the publishing business is changing, and to hear first-hand about your experience with writing and publishing an open source book.
I don't claim to speak for other software developers, but I'm willing to accept a "good enough" work as long as it's only game in town. If however I wanted to read up on Ruport and I had a variety of books to choose from, I'd probably pick the one with the best writing, editing, etc. regardless of whether the book's content was open source or not.
I don't believe that most self-publishers can realistically expect to compete with larger publishing companies in terms of publicity and reaching out to people who don't already know about the project. But if you're talking about subjects that are already niche interests, is that really a problem? What I mean is, the people who are interested in learning about Ruport are going to be actively searching for your book, and will find it regardless of the fact that it's not on the bookshelves at Barnes & Noble. This isn't the kind of book that someone's going to stumble on by accident and pick up on a whim to read at the beach. Well, *I* might, but not most people. ;)
I've had great success with Lulu personally for the Humble Little Ruby Book. Their products have gotten a lot better in the past year or two, and now I'd say their binding isn't far from what the "big guys" are using.
It's too bad I couldn't get my publishing project out the door before you got this article up; I think you'd be really interested in it.
@Tony,
We actually manually jump from textile to LaTeX for the PDF typesetting and print-ready book. Those sources are really only available to translators and other people who have special needs for them. The textile is the stuff that Mike and I actually write the book in, and is reasonably easy to strip down to plain text, which is why we chose this work flow. Not very efficient, but seems to work in a practical sense.
@Lyle
Good points. To be honest, the goal isn't to wish away any sort of mainstream competition. If there is a better book out there on a subject, I don't think that whether or not the work is open source really weighs in heavily for many. Still, I defy any publisher to consistently make a book about Ruport better in the long run than what we can do with the help of our community. I can actually say that I've written some Ruport content for a 'real' publisher that you won't see until long after the Ruport book is in print, and that although the code will still run and work good enough, it certainly won't be up to date. I tend to value up to date, relevant content over editing quality, but then again, that's what put me on this path in the first place. :)
@mike, peter thanks for your comments, they're encouraging.
@Jeremy. Darn, I can't believe I forgot to mention the Humble Little Ruby Book. It's one of the things that I thought about when beginning work on the Ruport Book.
Hmm, a manual publishing pipeline is about as agile as manual testing. How do you plan to keep the content current?
(About the book: I want one.)
anon -
By automating it as soon as possible. We just didn't have the time to investigate just yet. :)
Gregory, thanks for the comment. I hadn't considered LaTeX, mainly because my LaTeX skills are pretty rusty and the thought of writing a whole book in it gives me the heebiejeebies. After spending some time with Scribus this weekend I've decided that it's overkill for my needs (awesome software, though). I'm going to give LyX a try instead -- it appears to be slightly kinder than raw LaTeX for those without mad skilz.
On your questions:
I don't expect a tech book to look like a fine art book. As long as it's well-written, legible, and doesn't fall apart in my hands, it's fine.
Although O'Reilly has broken a lot of ground in providing tech books at a reasonable price, I don't think any of us expect them to be as cheap as mass-market books. $8.00/copy production costs shouldn't be a killer, even after a healthy markup.
I make purchasing decisions based on (roughly in order of weight) actual samples from the book, word of mouth, author reputation, and publisher reputation. Given no other information, I'd buy a (say) COBOL on Cogs book from O'Reilly over one from an unknown publisher, but having no other information is a rare situation these days. The publisher name isn't nearly as important as actual text/code samples, seeing that all the cool CoC sites are recommending a particular book, or knowing that the book was written by (say) Chad Fowler. There are a few cases where the publisher's reputation gives me the confidence to buy sight unseen, but that's pretty rare (basically, just O'Reilly and Pragmatic Programmers).
I'd say you're doing a pretty good job of getting the word out, actually. :-)
Thanks so much for the nice words about my book. O'Reilly was completely open to the idea of a free license, by the way; I didn't have to twist their arms.
It sounded like you were debunking those who knock Lulu, rather than knocking Lulu yourself. If so, I completely agree with you: I've held Lulu-printed books in my hands, and not known the difference until someone pointed it out to me. A Lulu paperback is indistinguishable from a trade paperback of similar size and format. It really points out how the whole notion of "being published" is ceasing to mean anything, now that we have an Internet. Along with "out of print" and "rare book", "being published" will be a phrase we have to explain to our puzzled grandchildren one day.
The service that publishers now provide to readers is selection -- that is, filtering. There's no reason that function can't be performed on books self-printed by authors; there are even business models that could make it profitable. For "publisher", just read "endorser".
@Karl,
Thanks for the insight. I think the one time we met, I mentioned to you the point that I made here, and I don't remember your answer.
It is basically that I don't see publishers having a problem with a book having an open license, providing they are sufficiently general. To be fair, in the limited talks I've had with O'Reilly with respect to the Ruport Book, I've felt no need to twist arms, the limitation there was primarily how quickly we wanted to get the book out the door.
At any rate, perhaps Lulu-first is a good idea for niche books. I could only hope that some day, publishers will openly embrace this so that it goes from "Oh, free documents sometimes get picked up for distribution by mainstream publiushers" to "Write a book via DIY and if it shows promise, you;ll get picked up."
Maybe even more lofty of a goal is the notion of publishers offering seed funds to authors, basically small advances to help them get their book of the ground, with the expectation that if the book ends up selling more than N copies, the publisher will pick them up. With this, there might be some incentive to offer things such as basic editorial and production services, or at least share some resources.
Ultimately, what I want is shared risk. Lately it seems that with publishers working with such a horizontal approach to the market, their model tries to push all of the risk onto the author. This isn't because publishers are evil but because within that model, it seems to be about the only way to make a profit.
I'd like to see some middle of the road between someone wearing all hats at once and struggling to get a book out on their own, and say, an O'Reilly publication. To the best of my knowledge, this doesn't quite exist yet, and I'm wondering if there are reasons why not.
Tony -- one possible useful feature of OOo is its XSLT output filters. While I've not tried, I've long thought that could allow a workflow where you author in OOo (using an appropriate template with styles) and output to whatever format you need (say LaTeX). In an ideal world, then, you get the ease-of-authoring of the traditional word-processor, plus the high-quality (PDF) output of TeX.
@Bruce,
Though that'd be awesome for the folks who find authoring in OoO natural, it'd be hell for those of us who don't even have a word processor installed. :)
Neat idea though, for sure.
I agree a lot with you. We are developing a program that might be interesting to you. You can write as you get feedback like in Django book, but I think you can revise more easily.
For more details, see 'What is paragraphr?'.