I wrote my own web-based editor to write Closure: The Definitive Guide (O'Reilly): http://docbookeditor.appspot.com/ Unfortunately, it's in a bit of a state of disarray because in Google's process of migrating from Docs 1.0 to Docs 2.0, they basically screwed over all the GData users in the process, which broke my tool. But as explained on the site, I made it possible to write in a Wiki-like language that looked something like the final product (using HTML/CSS rather than plaintext, saving a lot of TeX compilation and context switching to look at the generated DVI).

My editor can export to either DocBook XML or HTML, so I used the former to publish my book and the latter to publish essays on my web site. I also added support for slurping in source code from my repository so that I could be sure that the code samples in my writing actually worked. This was a bit of a pain, but definitely paid off, as readers are often infuriated by code samples that don't work. So far, no errata for code samples have been reported: http://oreilly.com/catalog/errata.csp?isbn=0636920001416

Wow! Writing an editor to write a book. You're in good company. Someone else commented to just keep it simple and focus on the writing which is the traditional advice.

Did you find that by creating an editor while writing your book, you were able to stay more engaged that if you had simply used a text editor and pushed off formatting until the content was done?

Absolutely: it's easier for me to think about my own work when I see it in context (i.e., with the formatting). If I had to mouse around and select "Courier New" and the color green every time I wanted to format a code sample to get an idea of whether it looked right, I would have never finished. I had just enough formatting to tell whether things "felt right," but not so much that configuring it became a distraction.

Though what _was_ a distraction was having to stop writing to switch contents and fix bugs or add features to my editor. This was still happening when I was in the final stages of the book because any time I context-switched, I tried to spend as little time on it as possible so I could get back to work. In retrospect, maybe I should have just taken a day or two to focus on the editor and then never go back.

Fortunately, I'm still using NJEdit for other things now that the book is done, so it seems to have been worth the investment. I've also open-sourced it so others can use it or fork it for their own needs, so hopefully others can find a way to benefit from it.

write it in markdown of some flavor and make it as simple as you possibly can. then you can convert it to any target format you want.

start simply, use as little markdown or markup as you can get away with, and just start writing. futzing with the package or syntax or style or layout or anything else is a great way never to get actually writing.

For my first dance with .mobi and .epub I used a mix of tools like Mobipocket Creator to export my .epub format to .mobi for the Kindle. That took a lot of patience, adjustments, and fine tuned settings to get the appearance correct on the device. There is also an emulator built-in. Having the Kindle in hand is far better.

Calibre was also a big help. Calibre is more ebook management? It does have some helpful conversion tools for the .epub to .mobi process.

Also during .epub development. I used threepress, http://threepress.org/document/epub-validate, to validate the .epub files as I went.

Focus on the content first not the format was my big lesson. In the end I made the .epub (DRM free) by hand using Notepad++. Just gave me far more control in the look, feel, layout, and fonts. Web developer by trade so it was not difficult to get a handle on.

Checkout http://authoringebooks.com/ it's $50, but it's by jeremy mcanally and he wrote http://www.railsupgradehandbook.com/ making $40k in a year.

So I think it covers a little about what tools to use etc..

Took a bit of searching, but here's a previous discussion which you may find helpful. Someone is writing a book and using ruby and git to handle the formatting:

http://chrismdp.github.com/2010/11/how-im-writing-my-book-us...

HN discussion:

http://apps.ycombinator.com/item?id=1861133

I wrote The Little MongoDB Book in Markdown and used Pandoc to convert it to PDF. Others have converted it to epub.

You can see the work at: https://github.com/karlseguin/the-little-mongodb-book

I blogged a bit about the process: http://openmymind.net/2011/4/5/Markdown-and-Me

I've written and edited books in a format called PseudoPOD for many years now. My company has several tools to validate and emit other formats, including XHTML, LaTeX, ePub, and PDF. This works very well for us.

Many of these tools are available from the Modern Perl repository on Github: http://github.com/chromatic/modern_perl_book