http://sandal.github.com/rbp-book/pdfs/rbp_1-0.pdf
(But please read the article, it provides context :)
So... here's the tl;dr; for the book itself:
"Ruby provides many ways to do things, many of them decent. But some are usually better than others, depending on the context."
Marketing-wise, it was a gamble, because the open source release date wasn't contingent on sales or anything like that. We launched the book and gave a 9 month exclusive rights period to O'Reilly.
This at least takes into account the fact that most books sell the majority of their copies in the first month or two, but I didn't have like a minimum sales number before I could open source the book or anything like that. In fact, the print book says right in the front cover that it'd be open sourced in March.
The book did okay sales wise, not great, but not horrible. It definitely did worse than it should given that (at least from the looks of it) people really, really like it. But this isn't really up to the readers, it's up to the distributor. Basically, much of our sales come from wholesale, and with paper book stores on the decline, and the saturation of the market with Ruby books over the last couple years, it was hard to convince them to pick up a lot of copies of the book.
As of right now, I am just about at the point of clearing my advance. I will share specific numbers at some point, but let's just say that the advance probably works out to minimum wage or less when compared to the amount of effort put in.
Interestingly enough, the gradual week by week release of chapters really led to a nice spike in sales, coming from what was essentially a steady decline except for a spike around the holidays. So actually, I think open sourcing the book was good for sales in that regard. Since it might be hard to find the book on the shelves in a book store, this gives people a chance to "try before they buy".
Unfortunately, because my book was selling above average as an ebook, I've probably effectively killed those sales today. Then again, maybe people will still buy the Kindle and Iphone editions, who knows.
At the end of the day, I think neither O'Reilly nor myself expected this book to be a big bread winner. I love the book because it embodies the most interesting things I've learned from the smartest people I know, and I think that comes through in the writing. I wrote the book because the idea popped into my head fully formed and demanded to be put out on paper. So that was my biggest win.
But from an authors perspective, RBP has given me a great boost in exposure. I already had name recognition in the inner circles of Ruby community, but after writing the book, I find more opportunities from folks I probably wouldn't have been able to reach otherwise. This has been good for my open source projects, and good for my work.
I'm glad I did this, and it worked out well. I'd recommend it to others, for sure. Of course, buying the book will make O'Reilly happy, so go ahead and do that if you want :)
I've talked to a few people who did things along this line, and they are of two minds. One camp says it kills sales. The other says it boosts sales, but in the latter case I don't think there was a PDF version even offered, and they made the book available as a Web site.
I encourage people who think this book is valuable to pay for it in some form, to encourage publishers to do more of the same, and to reward the author.
Even though you may not have been paid a "fair wage" for the work that you put into this book, it sounds like you are very happy with the outcome and the experience and the future benefits that you will undoubtedly reap from this project.
Congratulations and thanks again!
I think there was a post here on HN about that recently, but I can't remember the link. The author who wrote it described pretty much the exact process I went through, even though I think he was working with another publisher...
If you're just looking to get your ideas across, you'll almost certainly get more mileage out of writing articles, doing talks, etc.
And if you're looking to make money, unless you get very lucky, you won't make it directly off your book. It will almost certainly lead you towards other opportunities, but really all it creates is potential, things won't fall into your lap.
Still not discouraged? Then you might really, really want to write a book. That alone is what got me through the two I wrote. So then, go for it!
Here are some rough tips:
0) Get to know publishers a bit before submitting a proposal. I've had friends who got their book accepted cold, but really, there's little to differentiate you from the giant stack of proposals publishers receive daily if you come in without them knowing who you are first. This will also help you quickly identify the sort of people you don't want to work with. :)
1) Have a vision for your book. Get a sense of what you want it to be before you start writing it. This can be something very flexible, and doesn't need to button down any specifics, but know what the structure will be and test it out by attempting to write a chapter against it. If that doesn't work, reiterate. If you are working with a publisher that enforces a particular style, make sure you love it. But avoid those sort of restrictions if at all possible. I've written chapters on books where I was forced to write in a way I didn't like, and it was terrible.
2) Get together a good advisory group. Find the people you look up to in your topic area and ask them to discuss your chapters as you write them. We had a private mailing list for this in RBP, and it was amazingly effective. While tech reviewers can turn up a lot in isolation, you uncover the core issues when you ask them to discuss things as a group.
3) Expect your topics to change somewhat. If you find a chapter extremely hard to write, but there is a suitable replacement, consider introducing it. Completeness is a virtue, but I rather leave something out than cover it poorly. Some chapters will be hard due to necessary complexity, and that's okay. But there are others that are hard just because there is no reasonable way to write about them given your resources. Avoid those.
4) Write steadily, and try to make sure you're producing new content every week. Don't obsess over individual chapters, keep the whole of the book in mind. Leave yourself time to go back and breathe life into your more anemic content, but be sure to keep on rolling, even if its against your better judgment.
5) When forming a chapter, write out a bunch of code and examples first. When you think you have a cohesive set, sit down and write as if you're explaining the code you wrote to a friend or co-worker. Make sure your examples can flow together nicely, where possible. I found this approach to work well with RBP. If I couldn't come up with a great set of examples that went well together, I went back to the drawing board without ever writing a line of prose.
6) Ignore all of the above, and find a flow that works for you.
This stuff is hard, it's okay for it to be hard, and really, all you need to keep in mind is pretty much every other published author has been through the same hell that you'll find yourself in.
But you get a big reward in the end. You (eventually) get your sanity back.
Using positional arguments for more than two or so things creates connascence of position, which quickly becomes annoying.
Using block based DSLs so that you can break things down into small functions that each do their part is a good way around this, but these tend to be hard to extend dynamically.
Typically well designed Ruby systems provide both: Pseudo keyword arguments for dynamic needs, and some DSL-type syntax for pleasing the eyes.
Yes, it sucks that we don't have real keyword arguments. But no, it's not nearly as bad as you think.
positional arguments for more than two or so things creates connascence of position
Which is precisely the reason that you shouldn't pass more than two arguments to a method (unless you are creating a list or hash for their intended purpose). If you have more than two arguments to a method, it's a sign that you should reify them into an object.
Using block based DSLs so that you can break things down into small functions that each do their part is a good way around this
Why do people love making things complicated by misusing blocks. Just create an object and set slots on it. Blocks are best used for delaying computation, not setting up state.
I think that Zed Shaw's essay on the "Master" and the "Expert" is applicable here: http://www.zedshaw.com/essays/master_and_expert.html
Context is king, and what you've done is taken a single point from my book, ripped out its context, strawmanned it to death, and used it to bolster you're own "Top 100 rails" status.
I encourage readers to actually see what I had to say in the book by downloading the PDF before taking these arguments too seriously. If there are some constructive examples to be shown that seem promising and pass peer review, they'll definitely make it into the open source version.
It might even be worth it to write up a section describing the tradeoffs that richcollins has pointed out, but it's definitely not something as universal as he makes it sound.
Remember you don't need to destructure the hash. You've got a local one initialized to sensible defaults, and you .merge! it with the param one, and then just use the hash values as your local vars.
That gives the book some extra credibility in my eyes.
EDIT: OK, now that I've read the foreward, I see Matz himself mentions Gregory's work on Prawn. Doh.
I'm still active in the project as a maintainer. But really, these days you have Brad Ediger, James Healy, and Daniel Nelson, along with about 60+ contributors to thank for where Prawn is heading.
My job is mostly to sit around naming things, and warning people about the fragility of the early code I wrote. But we will have a 1.0 plan soon, and no matter who does the work, that'll be good for everybody.
Maybe this will keep RBP moving forward, and keep it alive.
http://wiki.github.com/sandal/rbp-book/questions-for-gregory
https://docs.google.com/fileview?id=0B8mB_WI1jRkCMzgyZWY5MzY...
Looks like it loses some quality on translation to Google docs, though...
