(Another in the irregular "Common Misconceptions about Publishing" series of essays ...)
You already know I hate Microsoft Word. But it takes actual exposure to generate such a volume of bile, and you probably won't be surprised to learn that there's a copy of Microsoft Office 2011 for Mac on this laptop. Even though I don't use it for writing books, or even business correspondence (I've got Scrivener for the former task and Pages or LibreOffice for the latter) I can't get away from it.
It's all because of the workflow of the trade fiction publishing business.
A major publishing imprint in the USA produces hundreds of books per year. (Tor, who I publish through, produce over 300 titles; they're part of a larger group, Macmillan, whose output probably numbers in the thousands.) Publishing is not a terribly profitable business, so the payroll isn't padded with lots of spare pairs of hands: they get by with as few people as they can, and outsource jobs as piece work where possible. From my (or your) point of view, I am a special sparkly pony and my books are the only ones that matter to me. But from the point of view of a publisher, I'm one of a faceless army of small, erratic suppliers who pump meat into one end of a sausage machine, while they turn the handle.
Here's what happens inside the sausage machine. Pay special attention to steps 6, 7, 10, and 12: these are the steps where my sausage-machine metaphor breaks down, because at these stages in the production cycle of a book, the publisher needs to send little hunks of sausage meat to other chefs for special treatment (those chefs being the copy editor and the author and the typesetter). Which implies document exchange has to be possible.
Now, in principle I could send the manuscript of my latest and greatest novel to my editor on parchment, hand-scribed with a quill pen. Or I could use cuneiform on clay tablets. Or LaTeX. As long as my editor can read it, what's the problem?
The problem is that the MS then has to be sent to the copy-editor, to be marked up with changes for consistency/bug squishing. It then has to be sent to the author, who will confirm or countermand the CE's changes. It then has to be sent to the typesetter, who prepares camera-ready copy (or, these days, a PDF file with imposition suitable for feeding to a modern PDF-to-press system). The PDF then has to be checked by the author and, ideally, a proofreader (most authors make terrible proofreaders). Finally, the additional bugs that have come to light need to be fixed, and a final production file generated.
You can do this by snail mail. But this adds about a month of slack time to the production process for a book, not to mention the (sadly increasing) risk of the postal service losing a slab of paper that embodies a couple of months of valuable work. (This has happened to me in the past. Luckily I had a document scanner and am paranoid about postal whoopsies. Other authors I know were less lucky.) It also vastly increases the cost of typesetting, because someone has to copy-type, scan, OCR and proof, or somehow convert a random alien file type into something that a desktop publishing/layout program like Adobe InDesign can import. Typesetters charge by the hour, and it is vastly preferable to supply them with electronic copy in a format which InDesign or Quark can slurp in, leaving the human operator to merely add style tags and check the text for issues like rivers, orphans, and widows.
The simple answer is: Word is ubiquitous. For decades, just about every PC sold shipped with Windows and a demo version of Microsoft Office. It's available on the Mac. Corporate IT departments (and the major publishers all have them, because the major publishers have all the infrastructure of any other billion dollar corporation) can support it. Workable clones such as LibreOffice (descended from StarOffice by way of OpenOffice: I've been using it in one form or another since 1996) exist for minority platforms. Word supports change tracking, notes, and basic collaboration features. Because the workflow of a book is linear, there's no need for simultaneous collaboration and complex revision control; just tracking who deleted or inserted a given phrase is sufficient.
So trade fiction publishing, as it has migrated to electronic workflow (using email instead of postal mail to shave about 10% off their production cycle) relies on Microsoft Word documents. Not because anyone loves it (except corporate IT), but because it's an omnipresent miasma, like air pollution and second-hand cigarette smoke.
Novelists are not, for the most part, IT people. Much less computer science graduates. I used to write novels in vim, using rcs for revision control and a bastardized version of Perl's POD document macros for formatting, along with a hand-rolled toolchain of makefiles and perl scrips to generate output in a variety of formats. And it worked okay, back when publishers did everything on paper. But as they moved to electronic workflow everything converged on Word .doc files; and there was no escape, because proofing is an important part of the book production cycle but proofing is not the same as writing.
Yes, the author can write their book in other programs. I use Scrivener. Other folks I know use XyWrite or Protext or GNU Emacs (there's no accounting for taste). But we need to deliver something our publishers can process—at a minimum, that means RTF. Then we need to check the returned copy-edited manuscript. Which these days comes through the email as a .docx file, so we need a .docx compatible proofing tool.
LibreOffice will cope with Word change tracking. So will Apple's Pages. Alas, Scrivener can't and won't (Scrivener is not a word processor, and emits a .doc file (or an epub or PDF) as the end product of its process: there's no easy way to go in the other direction). And our publishers expect to get a .doc or .docx file back, with change tracking switched on and our own changes stacked on top of the copy editors, for editorial review before they hit the "accept all changes" button and forward the final product to the typesetter.
I try to avoid Microsoft Word like the plague, but I have my limits. For me, the requirement that finally made me crack and throw money at the Beast of Redmond was the need (in mid-2012) to edit, revise, and indeed redraft the first six books of the Merchant Princes series into three omnibus volumes in twelve weeks. There was no slack time in the proposed production cycle for those books: they were to come out at one month intervals in the UK in the spring and early summer of 2013. And I'd agreed with my editor that we'd use the original as-published American ebooks as a baseline and apply change tracking, so that we need only focus editorial attention on the changes I was going to make.
I could have trusted LibreOffice to do the job right. But we're talking about a corpus of, in the final version, 620,000 words: about the length of "War and Peace", 1.7 times as long as "The Lord of the Rings". I made something like 12,500 changes in total. The probability of LibreOffice being up to the task was high, but the risk if a hitherto-unsuspected bug surfaced and rendered my change-tracked files indigestible by Microsoft Word was that I'd have to throw out three months' hard work and re-do from scratch. (Imagine Microsoft Word as Clint Eastwood, and me staring up the barrel of a .44 magnum. "Are you feeling lucky, punk?") Let's also add that I had other deadlines, and a book to finish the same year after I redrafted that
trilogy six book series. Was retaining my ideological purity worth the risk of losing three months' work and screwing my next year?
I sometimes fantasize about Markdown taking off everywhere. It's not as if Markdown editors are thin on the ground; it's almost become a de-facto standard on the iPad due to iOS's lack of a rich text library prior to iOS 7. Markdown is expressive enough to write a novel (novels are structurally very simple). It's so lightweight that you can learn the basics in half an hour and print a crib sheet on the side of a coffee mug. There are powerful Markdown editing tools with syntax colourizing and folding and other features (Scrivener supports it; so do vim and emacs and BBEdit) and you can write it using any plain text editor. If we could just get everyone to use it, there are powerful proofing tools out there—it's a plain text based markup language, so the entire panoply of programmer's tools are available.
But it ain't gonna happen. Novelists are not only not IT people; they are on average quite old (it's rare to sell a first novel before you turn 30: most working novelists are middle-aged). They are emphatically not early adopters. And the corporate IT departments that support Microsoft applications across the organization will happily go on doing so, and go on ignoring newer and better alternatives that generate newer and more exciting management headaches, until change becomes not merely inevitable but overdue by about a decade and a half.