Writing a Technical Book for Manning

- Manning has a high quality review process and generally puts out high quality books

- Manning's current production phase (what happens after content is done) and production timeline leave a lot to be desired; I know they have had some turnover in the department and they are self-aware and working on it to be fair

- Manning's main tooling (aka Word templates) leaves a lot to be desired as well. You have the choice to work with AsciiDoc (I did my first with them in Asciidoc and the second in Word) but their tooling for that is even less mature.

- You don't write technical books for the money. You do it for the career advancement and/or satisfaction. You read blog posts about the outliers (people who made a lot and people who made a little) because they're the loudest voices, but generally even a good technical book sells around 2000 copies because the audience of paying readers is so niche.

- He's right about the royalty negotiation. First-time, unknown authors have almost no leverage. After you have successfully completed a book you can negotiate a higher royalty rate/advance.

I'll add a few more points (hopefully they're not pissed at me for writing publicly about this):

- They do a very good job marketing to their own existing audience. They do less of a good job marketing to external audiences, although this has improved in the last couple of years.

- So much of how high quality the process is depends on who you randomly get as a development editor/technical editor/technical reviewer/copy editor. You don't have much say in the matter. So, it's a total crapshoot.

- It's better if you come to them than they come to you. I came to publishers with all three of my topics, not the other way around. You can then shop around. I submitted my proposals to multiple publishers and got multiple offers.

I disagree with another author who posted in this comment section—books, even by traditional publishers, are not always a team effort. 90% of the content of my three books is the same as would've existed if I had self-published. Of course being receptive to feedback is very important, but how valuable it is really depends on how good a writer/explainer you are to begin with and how good the people giving that feedback are.

Was offered the Word Doc or Docbook-based XML format w/ Java validator + validating xsd, and others. Went with the XML, but built my own tooling for injecting runnable code (what is available in my git repository for the book) into the book, using code comments to define figures so I didn't have to copy / paste / update / etc., along with figure, and other convenient "macros" to save from typing the XML. Call it 85%-90% XML, 10% other stuff.

The major challenge I faced was that the validator provided to me was not the same as what was used by the publisher when I uploaded my xml for automatic generation for editing, leaving me in a situation where I didn't even know that my xml wasn't valid until I get a crappy message after `svn commit` and having to submit a build to their system (typically 1-3 minute delay to find out your pdf generation didn't work, try to find what weird xml edgecase you missed that your validator doesn't care about, and submit again). About 2-3 months before finishing with final edits, I found an XML editor that would validate with the xsd directly, finally getting my document validated (but breaking all of my formatting, requiring extra steps in my build process, ...), and allowing me to eliminate 30-40 minutes of the typical "find out what's wrong with my hand-written XML tonight" when editing.

They had a forum for discussing ongoing author issues, and I remember there was an author who was using his own Asciidoc -> docbook tool. Looks like they may have imported it more recently if OP was using that and there was no docbook option. I had started early on with a reStructuredText equivalent, but then realized that I didn't want to write / maintain a tool to write a book (and to maintain that tool for others going forward), and ended up with what I used - less than 150 total lines, no external libraries, and no maintenance going forward. :)