On asking me to write for you

[posted for later reference]

In the first eleven days of December 2013, I have received eight requests for me to write for a periodical such as a web site or a magazine. This is nice. I struggled for many years to get published. To have publishers knock on my door and ask for my work gives me a certain warm fuzzy feeling. They’re trying to fill in their 2014 editorial calendars, and want me to be part of it? That’s kind of cool.

There’s only one problem: they want to pay me with a subscription. The more generous ones offer advertising space. I address this in my FAQ, but it seems these people either don’t read the answer, don’t comprehend the answer, or think the answer doesn’t apply to them.

Here’s an explanation with more detail.

My writing time is completely occupied, either with work that I expect will return financial rewards or “writing of the heart” — projects that I really want to do, but that I accept will not pay.

Generally speaking, if you’re contacting me with a request to write for you, you expect to make money off of my writing. That makes this a business transaction. This means I expect to get paid an amount that is roughly equivalent to the amount I would make if I expend that amount of effort on other paying channels. A thousand-word article is almost certainly more than $50 of my time.

But it’s also important to not be a jerk. The world is a small place.

From now on, I’ll answer these requests with a form letter.

Hi,

Thanks for your interest.

At this time, I am completely occupied with paying writing work, so I cannot take your offer. But thanks for thinking of me.

Regards,
==ml

I’m not a total mercenary. I put a fair amount of technology content up in this blog, free for anyone who can use a search engine. But: I have a day job. My writing time is taken away from family and friends. I might choose to give up some of that time for someone. But that “someone” will be a person, not a business.

I know other people will write for these periodicals. Someone always will. But that’s their choice. I choose otherwise.

Sudo Mastery off to copyeditor

I just shipped the tech-reviewed copy of Sudo Mastery off to the copyeditor. She’ll have it back to me in a few days, and the book will move into production immediately thereafter.

This means that the pre-order discount will expire soon. How soon is soon? It’s soon.

Now I’m off to work on one of my other 2013 goals. Thanks to my appendix’s untimely detonation at the beginning of the year and my Europe trip I won’t accomplish everything on that list, but that’s no reason to not get as many of them finished as possible.

EuroBSDCon, and Sudo Mastery

How’s that for diverse topics in one post?

I just got back from EuroBSDCon 2013 on Malta. The EuroBSDCon Foundation and Andre Opperman did a great job with the conference, and presented one of the best sets of talks and keynotes and related programs I’ve seen in years. It’s motivated me to try to improve BSDCan, but I’ll babble about that in another post.

I followed EuroBSDCon with a few days in Paris, to talk to other authors, network, and figure out some “business of writing” stuff. Plus see the Eiffel Tower and the catacombs, of course.

Now that I’m home, I’m diving into the technical reviews of Sudo Mastery.

Normally when I have a book out for tech review, I post a variety of reminders during the time people should be reviewing. “Two weeks to get comments back to me!” “One week!” “Six hours and three minutes!” I didn’t do that this time, instead focusing on things like distributing blacklists via BGP and automated deployment of FreeBSD and Bhyve and relayd and and and and…

In a weird coincidence, I haven’t received as many tech reviews as I usually do.

Why do people nag? Because it works.

If you’re one of the folks who volunteered to review the manuscript, you have a couple days left to send me comments. I would really like to get the book to the copyeditor by next Monday.

“Sudo Mastery” tech reviewers wanted

Thursday night, I finished the first draft of Sudo Mastery. Today, I went through the manuscript, removed my known tics, discovered a few more tics that needed killing, cleaned up bits and pieces, and now have a work ready for technical review.

Which is where you lot come in. I’m looking for people with sudo experience to read the book and tell me where I’ve screwed up. My screw-ups usually come in two flavors:

1) I’m technically wrong.
2) I use something in a way other people don’t
3) I don’t include something important, because I’ve never used it.

The goal of Sudo Mastery is not to get 100% of my readers to 100% sudo expertise, but instead to get 90% of my readers everything they will need. The remaining 10% will get a solid grounding in sudo and pointers on solving their particularly pernicious edge cases. The idea is roughly similar to my other Mastery books or Cisco Routers for the Desperate.

The contents of Sudo Mastery are:

  1. Introduction
  2. sudo and sudoers
  3. editing and testing sudoers
  4. lists and aliases
  5. options and defaults
  6. shell escapes, editors, and sudoers policies
  7. configuring sudo
  8. user environments versus sudo
  9. sudo for intrusion detection
  10. sudoers distribution and complex policies
  11. security policies in ldap
  12. logging & debugging
  13. authentication

Most of these chapters are short. And much of the writing needs rewriting. But there’s no point in rewriting until I know the content is technically correct.

If you know sudo, if you consider yourself a sudo master already, this is your chance to spread your wisdom. Read my general notes for tech reviewers, and email me at mwlucas at michael w lucas dotcom. (The W is vastly important… you might get a response from the domain without one, but it won’t be what you expected.)

I plan to send out manuscripts over the next week. I’m asking for people to return their comments on or before 5 October. I plan to revise the manuscript the week of 6 October and get it to the copyeditor before the 15th.

With anything resembling luck, the completed book will be available before Thanksgiving. I’d really like to have the holidays off this year.

First draft of “Sudo Mastery” complete

I just typed the last words of the first draft of Sudo Mastery.

The completed first draft is available for early purchasers. As it’s no longer an incomplete draft, I’ve raised the early purchase price to $8.99. That’s more than the really early buyers paid, but less than the final price. (Selling the early drafts from my own bookstore lets me experiment, so I’m ratcheting up the price to see what happens.)

What happens now?

First, I take a couple days and do something else. Anything else. This is vital, as I need some distance from the manuscript. I know it’s a big steaming pile of bodily waste, sure. But I need to be able to see the details of how, exactly, that pile is arranged.

Then: go over the manuscript from beginning to end, looking for obvious technical and writing problems.

Then spellcheck the book. (The purpose of an as-you-type spellchecker is to slow down the writing process. Note that a grammar checker never enters into this process.)

Then solicit technical reviewers. (Don’t volunteer yet: if you do, I’ll put you on my list of people who can’t follow directions.)

Then I go to EuroBSDCon. When I return, I integrate the comments into the book in another round of testing and fact-checking and rewriting.

Off to copyeditor.

Fix what the copyeditor finds.

Then the book comes out.

Book Review: The Practice of Network Security Monitoring

Most computer books are badly written. The information in the book is fine (usually, hopefully), but the actual craft of writing is poor. They read like computer programs. This isn’t surprising, as most computer books are written by computer professionals. By the time you’re good enough at a computing topic to write a book about it, your brain automatically arranged things in machine-friendly order. That’s human nature. The downside of this, however, is that most computing books lack the things that make books interesting to human beings. We readers grit our teeth and plow through them because we need the information.

I’m pleased to say that Richard Bejtlich’s The Practice of Network Security Monitoring is not one of those books. The damn thing is actually readable. By normal people.

That’s a vague assertion. How about a metric? Season 6 of Burn Notice just hit Netflix streaming. I watched a few episodes Saturday. They ended on a tense cliffhanger, but I finally had to go to bed. Sunday, I finished reading this book before seeing how Westin and company got out of their fix. (Okay, that’s not exactly a metric, but it’s a good sign.)

Bejtlich graduated from Harvard and the Air Force Academy graduate. He led CIRT teams in the Air Force, built a security team at General Electric, and is now Chief Security Officer at Mandiant. He’s on television as an electronic security guru. And for the last decade-plus, he’s been beating the drum about intelligent attackers and the need for a holistic approach to security. When everybody else was going on about firewalls and antivirus and access controls and penetration testing, he wrote books like The Tao of Network Security Monitoring arguing that we need to think about network defense as an ongoing activity. He made absurd claims like “prevention eventually fails” and “there are smart people slowly breaking into your network,” lumping these into an overall practice called Network Security Monitoring.

Time has proved that he was right.

Books like Tao and Extrusion Detection had a lot about the business process of security. They had specific examples of how to respond to security incidents. Other books, like my own Network Flow Analysis, cover using a specific tool that’s usable in a NSM context. But there hasn’t been a good book on how to deploy real security monitoring in your organization, across all tools — and, just as importantly, how to get buy-in from the business side on this.

The Practice of Network Security Monitoring does all that and more.

The book starts with an overview of the NSM philosophy and practice, and what makes it different from the conventional “we respond to intrusions” perspective. He spends some time going over the Security Onion toolkit. For those readers not familiar with SO Security Onion is to security monitoring what PfSense is for firewalls — an integrated toolkit built atop a free operating system. You can build everything you need for NSM without Security Onion, but like PfSense, why bother?

Richard gives a brief overview of the various tools in SO, from Sguil to Bro to Snort to Xplico and on and on and on. While you can hook these tools together yourself so they operate more or less seamlessly, again, SO has done all the work for you.

The best part of the book, however, is where Bejtlich takes us through two security incidents. He uses various Security Onion tools to dissect the data from an intrusion response system alert. He backtracks both a client-side and a server-side intrusion, and shows how to accurately scope the intrusion. Was only one server broken into? What data was stolen? What action can you take in response?

What really makes this book work is that he humanizes the security events. Computing professionals think that their job is taking care of the machine. That’s incorrect. Their main job is to interface between human beings and the computer. Sometimes this takes the form of implementing a specification from a written document, or solving a bug, or figuring out why your SSL web site is running slowly. Maybe most of your professional skill lies in running the debugger. That’s fine, and your skill is admirable. But the reason you get paid is because you interact with other human beings.

Bejtlich pays attention to this human interface. The security incidents happen because people screw up. And they screw up in believable ways — I read the server compromise walkthrough and thought “This could be me.” (Actually, it probably has been me, I just didn’t know it.) Deploying network security monitoring takes hardware, which means you need money and staff. Bejtlich advises the reader on how to approach this conversation, using metrics that competent managers understand. His scenarios include discouragement and even fear. If you’ve ever worked in intrusion response, you know those emotions are very much a part of cleaning up.

But he shows you how to deal with those problems and the attendant emotions: with data.

He even demonstrates practical, real-world examples in how to get that data when the tools fail.

Humanizing a tech book is no easy task. Most authors fail, or don’t even try. But Bejtlich pulls it off. He applies “prevention eventually fails” to both the people and the software, and the result is both readable and useful.

Is this book perfect for me? No. The sections on how to install Security Onion are written so that Windows administrators can use them. I don’t need that level of detail. But the end result is that tPoNSM is usable by people unfamiliar with Unix-like systems, so I can’t really fault him for that.

I should add a caveat here. Richard Bejtlich likes my books. He’s said so. At very great length. Repeatedly. Even though I’ve misspelled his name. More than once. And now I’m reviewing one of his books. I am predisposed to like his work because it’s hard to dislike someone who likes you. But if this book wasn’t good, I wouldn’t bother to review it. I read far more books than I review, and I would much rather not write a review than write a negative review. And anyone familiar with my work can assure you that I do not suck up.

tPoNSM is useful for anyone interested in the security of their own network. Many of the tools can actually be used outside of a security context, to troubleshoot network and system problems. Deploying NSM not only means you can quickly identify, contain, and remediate intrusions, it gives you insight into the network as a whole. You might start off looking for intrusions, but you’ll end up with a more stable network as a side effect.

You can buy the book at any bookstore. If you want to reward the author, buy it directly from No Starch Press and use coupon code NSM101. You’ll get both the print and electronic versions, and Richard will get a couple extra dollars.

Now if you’ll excuse me, there’s another dozen or so episodes of Burn Notice that need watching.

next tech book: Sudo Mastery

Last weekend I amused myself by tweeting:

Stupid contest: give the title of the tech book I’ve just started writing. If correct, you get to make me a sandwich.

The answer is Sudo Mastery. Obviously. Although there were some amusing and hopeful alternative suggestions.

As with DNSSEC Mastery, I’m making the in-progress draft available for purchase. I did this with DNSSEC Mastery, and people seemed pleased. So, let’s try this again.

You can buy Sudo Mastery now for $7.99. You get access to the early drafts of the book, the version sent for tech review, and the final version. Incomplete drafts are in PDF format, because I can’t see anyone loading an incomplete book onto their e-reader. The finished book will be in PDF, epub, and mobi.

The in-progress version also includes various markup and reserved pages for physical layout, as well as whatever notes I make during the writing process. The version currently on the site includes the outline for the part of Chapter 3 that I haven’t written yet.

When the book is complete, I will raise the price to $9.99. Buying early gets you a 20% discount.

You can also choose to overpay for the book (or any title on the site) if you desire. Because some of you want to. If you’re trying to make a go of being a writer, rule number 1 is: when someone puts money in your hand, you take it and say “Thank you.” There’s even an option to just give me money without getting anything, because people have said that they want to do that.

I will announce new versions of the book via Twitter. You’ll get an update every few chapters. As it’s a Mastery book, they’re short chapters. I’ll announce major milestones, just as a complete manuscript or completed tech edits, here.

I’m doing this for a couple reasons. One, people liked it last time. I get paid early, which is always nice. Feedback is good. And I expect that, once again, only my hardcore fans will buy an incomplete book. Some people will look at this as a 20% discount for preorders, which is fine too.

When you buy the book doesn’t matter to me. Sales made via third-party ebookstores are better for my career. They book the book’s sales rank and increase the book’s visibility. But the only people who will be interested in this offer are those interested enough in my work to stalk me via my blog or Twitter and, frankly, there’s not really enough of you to directly impact my Amazon sales rank.

You all do impact my sales, mind you, but indirectly. Every time you tell someone that they need to read one of my books, every time you leave a positive review on a book, every time you slap your boss and say “Dammit, make the support guys read this book so they leave me alone,” you help me a great deal. And that support drives bookstore rankings.

But as far as my stupid contest went: the best answer by far came from Darrin Chandler, who said:

Liked Absolut OpenBSD, but have since switched to Svedka. The morning afterboot still hurts.

I’m still in pain from that one.

“DNSSEC Mastery” business numbers

When SSH Mastery came out, I published the initial sales figures and a followup a month later. The results of publishing one book is not really data, however. It’s one data point.

A second data point is also not data. But it’s twice as close to data as one data point.

Let’s compare and contrast SSH Mastery with the book I just published a couple months ago, DNSSEC Mastery.

DNSSEC Mastery was pre-released via LeanPub, so that my hard-core fans could get copies of the incomplete draft. This was also an experiment. Now that the book is out on mainstream platforms such as Amazon and Kobo, LeanPub sales have basically gone to zero. (I still make an occasional sale thanks to LeanPub not requiring a PayPal account and being platform agnostic.) I’ve sold a total of 61 copies on LeanPub, most for the list price of $9.99.

The ebook was published 17 April 2013. Here are sales for the trailing end of April.

Here’s April’s DNSSEC Mastery sales:

  • Amazon Kindle: 13 books sold (7 US, 1 UK, 2 DE, 2 FR, 1 BR)
  • Barnes & Noble: 1 book sold
  • Smashwords: 1 book sold
  • Total sales: 15 books

    In May, the book had been out for a while. Also, the print book came out near the end of the month. What happened to sales?

  • Amazon Kindle: 32 books sold (26 US, 4 DE, 1 CA, 1 ES)
  • Barnes & Noble: 2 books sold
  • Smashwords: 4 books sold
  • TWP (direct from me): 4 books sold
  • Print: 23 books
  • Total sales: 42 ebooks, 23 print

    Then there’s June. Where did sales go:

  • Amazon Kindle: 17 books sold (11 US, 1 UK, 2 DE, 1 FR, 1 CA, 1 BR)
  • Barnes & Noble: zero
  • Smashwords: 1 book sold
  • TWP (direct from me): 6 ebooks sold
  • Print: 28 books sold, most at the beginning of the month
  • Total sales: 24 ebooks, 28 print

    June’s sales are down across all platforms.

  • Total total sales for first 3 months: 81 ebook, 51 print. Compared to the initial 2 months of sales on SSH Mastery, that’s pretty pathetic.

    What conclusions can I draw from these numbers?

    First, let’s talk about “fan base.” The story is, you need a fan base to pimp your book for you. Word of mouth is a powerful thing, true. But the key here is the word “need.” You can certainly be successful at self-publishing without an existing fan base.

    My fans are awesome. All of the LeanPub and TWP sales are from my devoted readers who specifically want books from me and want to support my writing. I appreciate every one of you. (I also think that you’re slightly daft for buying an incomplete book that hasn’t undergone any review whatsoever and might well be chock-full of dangerous advice, but that’s a separate issue.) Some of my fans waited until the book was officially released to purchase. I certainly don’t begrudge them this. Buying a book from your preferred cloud provider has distinct advantages, and that’s my personal preference as well. These readers are responsible for May’s surge of ebook sales and June’s higher print sales.

    Over 60 people bought copies of the book from LeanPub or TWP before the book was even complete. These hard-core fans would have presumably bought the book on a big-name commercial ebook platform instead. Selling the book through alternative channels deprived me of that initial “big sales burst” that so many self-publishing authors covet. That big initial sales burst doesn’t matter. The book is selling better than I expected. Less than I hoped, mind you, but better than I expected.

    I’m now done selling to the hard-core fans who stalk me on Twitter. Extra posts on Facebook and Twitter and whatever will not get me more readers. Instead, I’m selling to the public. And the public is buying.

    Would I like every single DNS administrator to deploy DNSSEC, using my book? Sure.

    But here’s the thing: if I continue to sell roughly 50 books a month to the general public, I will have more sales to the public than to my hard-core fans. I’m not discounting the fans, mind you — the initial influx of cash certainly helps, and their encouragement keeps me writing technology books. But in the long run, the book itself is the thing.

    What about “breaking even?” The expenses for SSH Mastery were very high, but I broke even in the first few months. What about breaking even on DNSSEC Mastery?

    Total expenses were about $650, between cover art, layout, editing, more editing, proof shipping, and such. (This does not include the various beers I owe assorted people.) I haven’t totaled all of the income across all the platforms, and I have no intention of doing that until the end of the year, but it’s pretty clear that this book has broken even with expenses. The only thing I need to get paid for is my time in writing the book. If the book continues to sell, then I’ll be okay on that front.

    The obvious question people will have is, “If you expected sales to be mediocre, why not write something with wider appeal?”

    I wrote DNSSEC Mastery as another test.

    At a technical level, SSH Mastery was very easy to write. I tested absolutely everything with my OpenBSD desktop, my Windows laptop, and a remote virtual machine. Nothing required interacting with anything outside my little world. Also, it’s very easy to see if my documentation worked. My usual testing methods of “capricious malicious play” work well with SSH.

    DNSSEC is different. It demands interacting with the entire world. This makes DNSSEC actually somewhat dangerous to play with. You can make your domains disappear from the Internet. You can make your users unable to reach the Internet. It’s an ugly, hairy thing to capriciously and maliciously play with.

    Additionally, DNSSEC is hard. My DNS knowledge dates from the mid-1990s. I was aware it had changed over the years, but I didn’t know exactly how or why. Writing this book meant updating my knowledge base.

    The community knowledge base on DNSSEC is spotty, unreliable, incoherent, and actively wrong. While folks started working on DNSSEC in the last century, it was only really finished in 2006. The years between generated a whole bunch of obsolete documentation on weird problems that no longer have any bearing on reality.

    Finally, DNSSEC has a really bad reputation. “It’s hard!” It’s another layer of complexity! It’s a whole chain of failures waiting to happen!” “There’s better ways to do this!”

    I don’t write books about torturing yourself. With the latest version of BIND, it’s entirely possible for your average overworked network administrator to deploy DNSSEC in the real world, without relying on overcomplicated third-party add-ons and scripts and random hacks. The software now handles the tedious and constant maintenance. This means that I could write a book about it in clear conscience.

    So: can I write and self-publish a technologically challenging book and have it be useful and correct? Can such a book solve problems for the reader and actually improve their organization?

    In that regard, DNSSEC Mastery is an unqualified success.

  • DNSSEC Mastery release

    I had hoped to get DNSSEC Mastery out before my trip next week. That’s not going to happen, thanks to the copyeditor. (And I do mean “thanks” in a completely non-sarcastic way.)

    Most of her comments are easily fixable. But she goes into detail on one point that is utterly, completely, compellingly damning. “The thing I worry about is that while this book may be perfectly acceptable, if people open it up really eager to get some more good clean Lucas (strange people), then there’s not a lot of that there.”

    All the knowledge is in there. But the writing needs more life.

    I really wanted to have this book in print before BSDCan 2013. I tried to keep that deadline, despite my surprise appendectomy in January. I’ve felt kind of uneasy about this book, but it was technically finished, so I sent it on.

    As I’m self-publishing, I both have the freedom to make the book correct and no excuse for not doing so. There’s no offset press scheduled for a feeding.

    So, the book will be delayed a couple weeks. And it will be better for it.

    And if you need a copyeditor who isn’t afraid to tell you in detail exactly why you suck, I have one.

    Tech Book Contracts

    Several tech authors recently contacted me for advice about problems with their publishers. (No publisher in particular, mind you.) Apparently I’ve been doing this long enough that I’m considered an expert. I’m writing this post so I can point these people at it later.

    If you’re a tech author thinking of asking for my wisdom: this is basically it.

    None of this is anything against any particular publisher or any particular writer.

    This is not legal advice. I am not a lawyer, nor do I play one on TV, nor do I write stories involving lawyers.

    No, I will not look at your publishing contract.

    I’ll point you to resources for fiction authors. Genre authors have been bludgeoned over the head repeatedly with this stuff. Tech book authors? Not so much. Most tech authors are technologists first, gamers second, have another hobby or a family or something, and write books as a distant fourth or fifth. Fiction writers who make a living writing have been forced to defend themselves against predatory practices. (“Fool me once, shame on me. Fool me and all of my peers for years, we will gang up on you and burn down your house.”)

    Now that the disclaimers are done:

    So, you’ve written a tech book. Or you want to write a tech book. You’ve found a publisher. They express interest, and send you a contract. Hurrah! You’re going to be published! An antload of fame and a soupcon of fortune will be yours!

    STOP.

    Do not sign the contract.

    Techies in particular have a disdain for paperwork, but the wrong contract can ruin your life. Even if you know the publisher. Even if the publisher is your best friend, like, ever. Even if you’ve been trained to automatically click on “I accept the license terms.” Overcome that disdain.

    READ THE DANGED CONTRACT.

    Maybe Microsoft isn’t going to come after you for that extra copy of Windows 95, but your publishing contract is much more personal. It’s aimed at you. And contracts tend to favor the side that writes the contract. Even the most scrupulously even-handed contract by the most good-hearted publisher in the world includes provisions where you agree to do stuff. It’s not as simple as “you write the book, you get paid.”

    By signing the contract, you’re agreeing to do what the contract says. The written contract overrides anything verbal. That handshake deal? Utterly worthless. The email paper trail? Also worthless in the face of the contract. Mutual understandings? Nonexistent.

    A publishing contract exists between you and the publishing company. The publishing company is not the nice acquisitions editor you’ve been talking to. It’s a legal entity owned by someone. That legal entity can be sold to another entity at any time. The new owner can fire the nice editor and assign you one with a ninth grade diploma and a deeply rooted, highly personal distaste for your work, your subject, your family, your religion, your college, and your personal aroma, who wants to know what button to push to make Microsoft Word do this FECN thing you’re talking about.

    I agree that the publisher’s attitude and reputation are important. I work with No Starch Press because they’re awesome to work with. They focus on making the best book possible. That’s great. But:

    The only binding agreement is the contract.

    Read it. Understand it. Print it out. Highlight anything you don’t understand. Highlight anything that might be a legal term of art. Highlight anything that could be used against you.

    What sorts of things should you look for? There are things that real publishers include in their contracts. The exact terms differ, but the bones are there. If any of these things are missing from a contract, the publisher is not a real publisher. Run away. Run away quickly. Put their gmail address in your spam bucket and blacklist their IP address at your network border.

  • Real publishers offer advances against royalties. No Starch has an interesting model where they offer a large advance and a small royalty, a middling advance and a middling royalty, or no advance and a great big freaking royalty. I’m playing a long game, so I take the big royalty — but the important thing is, they offered me an advance and I chose not to take it. (An advance is an interest-free loan against future royalties; you don’t get any more money until your royalties exceed the advance.) A publisher that does not offer a royalty is not a real publisher.
  • Real publishers say what rights they’re buying. This is frequently World English Rights. Some, such as NSP, also buy world rights, sell translation rights, and share the proceeds with the author. Whatever those rights are, they’re spelled out. Authors do not sell books. They license copyright.
  • How long does the contract last? For technology books, “life of copyright” is not uncommon. But tech books have a shelf life. The rights to Windows 2.0 Unleashed for Complete Dummies are basically worthless now. Still, the contract should give a length. It should also include conditions under which the contract can be terminated early, and you get those rights back.
  • Due dates. Can you really fulfill everything in the contract in the stated time? Are you assuming everything goes correctly? What about when things go wrong? What if your appendix ruptures a week before the contract is due? The publisher is signing contracts for printing, distribution, and marketing based on your commitments. If a contract doesn’t include a due date, someone could take an advance and never write the book. I’ve seen a tech book contract without a due date.
  • How will the publisher request changes and/or reject the manuscript? How long will you have to do revisions?
  • When will they publish? They should say they will publish within X days/months/years of manuscript delivery. If they don’t publish, you never get royalties.
  • Will they promote the book? If it’s not in the contract, it doesn’t have to happen.
  • When do you get paid? Publishing has a baroque distribution system, including things like “rolling reserves against returns.” It’s an infuriating system. Any engineer or business person could design better, but the system was built by people who love books. You will get paid… eventually.
  • Then there’s warrants and indemnifications. It’s reasonable to warrant that you are the author of the book, and that you have the rights for all content. It’s not reasonable to warrant your book against any and all possible damages that might be caused by it. If one of my books mortally and morally offends someone and they decide to sue the publisher, too bad.
  • How many copies do you get? They’ll go quick.
  • How can YOU terminate the contract? Under what circumstances? I’ve seen tech publishing contracts without termination clauses.
  • How can THEY terminate the contract?

    You might see other things. NSP has a nice “artistic control” section where they enumerate the various decisions that they’ll consult me on. They won’t guarantee to follow my desires, which is why my books don’t come with a glossy cover featuring an extreme close-up of my smiling face, but being asked gives me warm fuzzies. While NSP takes my input seriously, it won’t help me get my way against Ninth-Grade Diploma Editor.

    Lots of details in publishing contracts can bite you. Some of these seem harmless at first glance. My favorite example is the “right of first refusal,” where the publisher says they get first dibs on your next book, under the same contract terms. This seems like it’s to your advantage, but it’s not. The proper form for the publisher to express interest in your next book is by saying “Hey, what are you writing next? We’d really like a look.” If your first book is a smash hit at Wal-Mart, you want freedom to negotiate your next contract. If your publisher totally screws up your first book, you want freedom to work with a different publisher next time. If the publisher treats you well, follows their own terms, and produces a good book, you will want to stick with them — they don’t need this clause. There are really good reasons why I’ve stuck with NSP for over a decade, despite being repeatedly courted by editors for other publishers.

    Publishers have all kinds of tricks. They’ve been in the business longer than you. They have better lawyers. Don’t fear them. Do respect the crap out of them.

    If you really want to get into how contracts can abuse you, check out genre writer resources like Writer Beware. And you should really read Kris Rusch’s Business Rusch blog every Thursday. They’re for fiction, but Rusch has been a writer long enough to have suffered every abuse and indignity a publisher or agent can perpetrate. Learn from her mistakes, as you don’t have time to make them all yourself.

    Now that you have your marked-up contract, talk to someone about it — not your buddy, and not an experienced author. Hire a lawyer, preferably one with publishing experience. A couple hours of a lawyer’s time to explain the contract to you might save you years of grief. And yes, I mean years.

    Most publishing contracts include at least one objectionable clause. If a publishing contract includes no objectionable clauses, you do not understand the contract. Group the problems into “things you’d like changed” and “things that I will not accept.” This is where that lawyer comes in really handy, especially a lawyer experienced in publishing.

    Talk with the publisher about the problem terms. Some terms cannot be changed — the publisher pays all their royalties at the same time, so you’ll get paid quarterly or twice a year or once a leap decade along with every other author. Some terms can change. Ask. See what you can get.

    If one of your deal-breakers can’t change?

    Walk away. That’s what a deal-breaker means.

    Or accept what follows.