I've co-authored a book that did OK (Pro VB 6 & XML), and was about halfway through a book (Beginning Ruby) before the publisher (Wrox) went bankrupt and I got

I've co-authored a book that did OK (Pro VB 6 & XML), and was about halfway through a book (Beginning Ruby) before the publisher (Wrox) went bankrupt and I got next to nothing for my efforts. I've also been paid to write book chapters that never saw the light of day, and assorted articles for magazines, Web and dead-tree. Basically, the money is often poor when predictable, but can be OK if a book does well. Overall, if money is the goal, get a job as a waiter; it will probably pay better. OTOH if your book is among the first on a topic of current interest and doesn't suck you can do alright. It can be a lot of work. For the VB book I needed to spend some time researching some W3C specs and making sure I had some technical details correct, but much of what else I wrote came from an application I had already written, so it was fairly easy to write about. For better or worse it gave me a falsely rosy picture of book writing. :) The Ruby book, though, ended up being more work than I expected; documenting a language's behavior is more detailed than describing an app in that language. (Sadly, many language tech books suck because the authors don't actually know how the language works and fall back on loose, often incorrect, assumptions and analogies.) A book can help build a reputation, get you speaking gigs, and in assorted ways contribute indirectly to income, so book sales alone may not tell the whole story. But it's pretty unpredictable. Books get canceled; hot topics fade away. Maybe you or a coauthor really cannot write. If you're not innately excited about the idea, or don't feel confident in your tech writing skills, you might do well to hold off. Maybe write some blog posts, gauge reader interest, and test market the idea of a book.