Book updates, August 2011

I completed a first draft of the OpenSSH book last night around 10:30PM EDT. It’s out for tech edit now. At this point, I’m going systematically through the tech edits and making sure I’ve corrected the earlier chapters. After that, the manuscript goes to copyediting. Once copyedit is complete, I’ll release the ebook and start contracting out the POD version.

I normally write both nonfiction and fiction simultaneously. When I get frustrated with one project, I switch to the other. The context switch clears my brain. When I return to the vexing project, I can approach the problem fresh and work through it quickly.

I decided to do two nonfiction projects simultaneously this summer. In retrospect, this was a mistake. When I got frustrated with one project, I switched to the other… and found myself still frustrated. Perhaps I can do two nonfiction projects simultaneously, but OpenSSH and OpenBSD have a lot in common. One is just a subset of the other. My frustrations would probably be reduced if I knew what I was doing, but if I knew what I was doing, I wouldn’t write the book.

Lesson learned. If I want to write two nonfiction books simultaneously, they must be wildly diverse.

The OpenBSD book has therefore moved slowly. It’s further complicated by moving over the next couple weeks. I’ll be full-out cranking on the OpenBSD book this fall, however.

I predicted that the OpenSSH book would be 30,000 words. The first draft came in at 29,977 words. I am amazed; usually my books come in at 25-50% over the predicted word count. Perhaps I’m learning. But I’m probably just lucky.

Colin Harvey, RIP

This is off my usual track, but it’s my blog, so I’m free to do so.

Science fiction writer Colin Harvey died Monday, 15 August 2011, of an unexpected stroke, at age 50. He’d published several hard SF novels and edited a variety of anthologies.

I was lucky enough to have Colin in my writing critique group.

One of the ways to improve your writing is to exchange manuscripts with other people. By critiquing others’ work, and getting critiques on your own, you see what works and what doesn’t. (Strictly speaking, I should mention that the purpose of the critiques is not to improve the manuscript you just submitted, but to improve what you write in the future. You can’t do a huge amount to fix what you’ve already written.)

A good critique group is a weird thing. You want your critiquers to like what you’ve written. But you want them to assault your work with everything they have, point out every deficiency, and push you to make you better. The closest comparison I can make is to a martial arts school, where you help your partners improve even as you smack the crap out of them, being friendly and kind and forceful simultaneously. In a successful writing group, you develop unique friendships, even with people you don’t know. Colin was one of those friends.

I joined my current writing group at the beginning of 2007. Colin was a member. In the years since, Colin simultaneously beat the living crap out of my work and supported me as a writer. My work dramatically improved, thanks in large part to his efforts. (Not to discount the other crit group members; they’ve all been invaluable. Even Rob.)

I still have a copy of every message that has passed through the writing group since I joined. Rather than just say what a tragedy his loss is, I thought it might be more meaningful to extract some of what he said about writing and offer it here. It’s gauche to repost semi-private conversations, of course. I don’t believe Colin would mind these particular clips. He had a fantastic sense of humor, openly documented his life on his blog, and said all of this about my work on a mailing list archived on Yahoo Groups.

  • (On his well-deserved critiques of the first piece I submitted): “I’m aware that this mail reads like a thorough kicking, and I’m trying hard to find some positives”
  • (On receiving harsh critiques): “I’ll take this opportunity to thank you and all the others for the comments…”
  • (On theme in writing): I believe that the themes that a writer writes about come from within. So duplicity and betrayal feature largely in mine for reasons that even I don’t understand. I believe that if someone has enough belief and talent to write, then themes can’t be imposed. Topics or subjects can, but not theme.
  • (On any crit group member making a sale): “Congratulations”
  • (On synopsis): I think the whole point of the synopsis discussion is that various elements of the group have recognized that their work –as it stands– is already of publishable quality, but that there are barriers to that work being published. One of the barriers is the synopsis, or –as in most submissions generally– an inadequate synopsis. Yes, an agent / publisher will look at your first one, two or three chapters and it may be that the extract is sufficiently good to off-set an inferior synopsis. But many agents just don’t have or want to spend the time if they don’t have to. It’s all about shortening the odds.
  • (On scenes): Scenes should -for me- serve one of three purposes
    i ) To move the plot along
    ii) To set a scene or to
    iii) Illuminate the character(s) in it
  • (On advice from non-writers): Why are you letting a failed writer tell you what to write? And before you argue that — how many best-sellers has xxxxxx WRITTEN? How many awards has he won for his fiction? (Those are all rhetorical questions, btw. I know about lack of confidence – honest!)
  • (On research): I read as I go along. I never know what I need to read up on.
  • (On critiques): The whole point of crits is not to tell you what you do know, but to smack you in the side of the head from a completely unexpected direction.
  • (Whenever anybody said anything nice about his successes): Thank you,
  • (On vocabulary): recuperance? What sort of word is that? Did you just make it up?
  • (On getting published): Persistence, persistence, persistence.
  • (On future technology): I don’t see shaving disappearing anytime soon….
  • (On the Star Trek reboot): You went expecting a storyline? You’re clearly an optimist.
  • (on someone on the critique group mailing list whinging about the publishing industry): Rant on as much as you need to, as far as I’m concerned.
  • (after two years of discussing outlining novels versus winging the story, during which he converted me from a hard-core winger to a hard-core outliner, and I espouse the benefits of outlines to other group members): Oh, I am *so* enjoying the poacher-turned-gamekeeper aspect of this e-mail….
  • (On writing rules): The only ‘rule’ is if it works, do it.
  • (On the last piece of mine he critiqued): This is a very, very good story.
  • I could go on, and on, and on, but I’ve spent hours on this. And Colin would tell me to get back to writing my own work.

    Colin never stopped improving his work. And he never stopped improving mine, either. He recently wrote novels that he hadn’t had time to finish marketing. I want to see both Black Death and Ultramassive in print. The latter is cool SF, and the former scared the crap out of me.

    Colin left the writing group earlier this year, but he and I agreed to continue exchanging manuscripts in a less public forum. By sheer chance, we agreed to take a hiatus in August — we both had big family projects underway. If he’d spent the last month of his life reviewing my sewage work instead of spending time with his family, I’d feel pretty bad. If I’d still owed him a crit when he passed, I’d feel ghastly.

    Colin spent his last days with people more important to him than myself. And that’s how it should have been.

    Practical Packet Analysis, 2nd Edition

    The second edition of Chris SandersPractical Packet Analysis is about twice as large as the first edition and twice as useful.

    I learned Wireshark in the traditional manner: got annoyed with tcpdump, installed Wireshark, and started poking menus and buttons until I got a result. Chapters 1-5 of PPA takes you through the important menus and buttons. There’s not much you can do to make descriptions of software options interesting, but Sanders demonstrates real-world uses as he goes along. Demonstrating how to use round-trip-time graphing with real data, for example, gives the buttons and menus relevance to our work. Chapters 6 and 7 cover a few basic network protocols, from ICMP to HTTP to social media logins and DHCP and so on, to ground you in what traffic should look like.

    The really interesting part of the book is the second half. Starting in Chapter 8, Sanders dives into real-world problems and shows how to investigate them with Wireshark. He covers topics from difficult developers to network latency to security. What does a worm look like on the network? How about wireless?

    The book organization invites me to keep it at hand for troubleshooting. The next time I investigate a slow network, I’ll turn to PPA2e chapter 9. And that’s perhaps the best praise I can offer on any technical book.

    Practical Packet Analysis invites comparison with my own Network Flow Analysis. As you might guess, I consider network awareness skills absolutely vital for any network engineer. Where my work is about broad-scale network flows, however, Sanders’ work lets you dig deep into individual packets. Jitter, latency, loss, and all the details of protocol transactions are resistant to flow analysis, whereas packet analysis will lay them bare. I know my readers have already bought and devoured my book, but you really need to master both tools.

    Plus, the author proceeds from Practical Packet Analysis are all being donated to the Rural Technology Fund. The narrator of NFA recommends using flow analysis to blackmail your coworker into washing and waxing your car. I am forced to conclude that Sanders is probably a better human being than I am.

    Buy this book.

    Disclaimer: No Starch Press also publishes books by yours truly. I have no problem calling them out if I disagree with them. Watch, I’ll demonstrate:

    “Hey, guys, I really liked the color text boxes we did in PGP & GPG. I know they were more expensive than plain black and white pages, and I know that book sold fewer copies than anything else I’ve written, but it looked really cool. Why don’t we do that everywhere?”

    OK, maybe that’s me being an entitled prima donna rather than disagreeing with them, but still, I wouldn’t write a positive review on a book I didn’t like.

    SSH Book Title

    I’m at a publishing workshop, learning how to write pitches, blurbs, and promotions. That drove home that my SSH book title might not be the best choice.

    I’ve been planning to use the title “OpenSSH: Your Next Steps.” The book will take you to SSH competence, making sure that you use basic security precautions, master using keys for authentication, SSH tunneling, and so on. That title’s fine. As far as it goes.

    But I think I can do better. I’m pondering calling it “SSH with OpenSSH and PuTTY” instead. The first title, I’d have to rely on keyword search to bring up SSH. This title brings all the key words into plain sight.

    I learned with PGP and GPG that a title is important. If I had called that book “Email Encryption for Everyone,” I would have sold a lot more copies.

    So, what do you lot think?

    Full up on OpenSSH reviewers

    I now have all the reviewers I can manage, and am not looking for more. I’d make an exception if you’re, say, an OpenSSH or PuTTY developer, but other than I’m not accepting any more. I’d like to thank everyone who has volunteered to review this book.

    OpenSSH community reviewers wanted

    UPDATE: I have all the reviewers I can handle.

    I have about half of the OpenSSH book written. I can start getting feedback on the manuscript. If you’re interested in providing feedback, first read the review process article on my web site.

    If you’re still interested after reading that article, send me an email with the subject “OpenSSH review” and tell me that a) you won’t share the review manuscript, and b) why you’d be a good reviewer. I can only manage so many reviewers, so I try to pick readers of every experience level. My email address is m w lucas at black helicopters dot org.

    And before you ask: four chapters of the OpenBSD book are finished. Not enough to solicit reviewers. It is proceeding apace, though. I usually work on multiple projects simultaneously, so this is not unusual.

    How Community Tech Review Works

    I’ve received quite a few questions about how I do community-based tech reviews on forthcoming books, as well as offers for one or both of the projects I have underway. I’ve put up a public Web page about the process I follow. I expect to request community reviewers for one book later this week.

    Realistically, my brain is limited. I can only manage about 20 prepub reviewers for a given project. I choose the best people from the pool of volunteers.

    I hope that all of them will return useful comments. I expect that about 10 of them will return nothing. Another 5 will drop out halfway through.

    So, if you volunteer and I don’t pick you, you can feel superior in knowing that you would have been one of the 25% to stay all the way through, except that I wasn’t smart enough to know that beforehand.

    Summer 2011 nonfiction project: OpenSSH

    I have a problem with Absolute OpenBSD, 2nd edition. It’s too big. The outline is 26 chapters. This brings the book close to 300,000 words, well over a thousand pages. I don’t want to write books that I don’t like. I don’t like huge books that I cannot comfortably read in the bathtub.

    One component of OpenBSD is OpenSSH. People have written books about OpenSSH, but they contain more information than most people need. (Not all, but most.) I write for the most common user, which means that those books are perhaps 2x-3x the size of what I would write. And OpenSSH is widely used outside OpenBSD: I could argue that it’s their most widely deployed component. Lots of people who will never use OpenBSD need a swift sharp smack with the OpenSSH clue-by-four.

    AO2e book needs some OpenSSH stuff in it, of course. But I have about 30,000 words of OpenSSH. For comparison, the smallest nonfiction book I’ve written is about 60,000 words. It’s too small for a traditional publisher.

    So I’m removing the intermediate-level OpenSSH material from AO2e, and doing a small independent book tentatively titled “OpenSSH: Your Next Steps.” It will cover the OpenSSH server, and the OpenSSH and PuTTY clients.

    Many people believe they know how to use SSH: they download PuTTY, enter a hostname, username, and password, and “poof!” — they’re secure. It’s not that simple. If you search for documentation and articles about using OpenSSH, you’ll find years and years of accumulated cruft. Many of the most visible articles and posts are obsolete. A single source of up-to-date information at an inexpensive price would find readers, and would let me satisfy my self-publishing curiosity. I’ve contemplated independent publishing for some time now, and this looks like a realistic opportunity.

    I’ll have to pay for copyediting, design, and so on. And I’ll have to manage the whole project. Worst case, I lose a lot of time and money, but develop a new appreciation for my publisher. (I still cannot see leaving them for major books like AO2e, however; it’s just too much work.)

    I believe that there’s a market for inexpensive, small, single-topic books, as Cisco Routers for the Desperate is one of my best-selling books on Kindle. Not bad for a two-year-old book. I could also make the case that if you want a book called “Cisco Routers for the Desperate,” you want it NOW. (The publisher could probably double the price without impacting Kindle sales, but that would be gauche.)

    I will do a community-based tech review. I’ll announce here when I’m looking for reviewers.

    Finally: at Austin Hook’s request, I’ll also do a print-on-demand version. (I’m not terribly interested in distribution of physical copies of such a short book, but the expense and annoyance of setting up POD isn’t that great, so why not?) Austin handles the sale and distribution of the various OpenBSD merchandise, so I have confidence he can manage this.

    As an independent, I cannot do pre-orders for books that don’t yet exist. There are Web sites that manage this for authors, but I really don’t want to bother. But Austin does that all the time, and he’s a trusted community figure. He will be the official source for pre-orders. While POD books need to be paid for in advance, the money doesn’t come to me until the books are ready to print and ship. This will get some extra cash in the hands of the folks who develop OpenSSH, which is a good thing.

    No, I don’t have numbers or prices yet. I’m taking a course on this stuff, as well as POD, though, so I’m not even trying to figure that out yet. I can assure you that the paper version will be more expensive than the electronic version, however.

    Will this succeed? There’s only one way to find out.

    UPDATE: I’m not shelving AO2e for the summer. I normally work on multiple projects simultaneously. When I’m sick of one, I work on the other.

    Absolute OpenBSD, 2nd Edition

    I promised I’d announce the title of my next No Starch Press book in my BSDCan talk. That happened. The rest of you had to wait until now to hear that I’m rewriting Absolute OpenBSD. The technical reviewer is Peter Hansteen, author of The Book of PF.

    Most of the book does not exist yet. Best guess for a release date is some time in 2012.

    Why did a second edition take so long?

    I will only write books about tools I use in production, out in the real world. (Desktop use does not count.) In my previous job, senior network engineer at a global automotive supplier, I had no opportunity to use OpenBSD. That meant I couldn’t offer advice about using OpenBSD, or discuss how it fit into my infrastructure. I could have written the book, but it would have sucked.

    I’m also working on a second nonfiction project, but I’ll announce that separately.

    Agents for Tech Authors

    I know several tech authors who use an agent to sell their books license their copyright to publishers. Tech authors don’t need agents. You can sell to a tech publisher yourself, and hire a lawyer to evaluate any contract offered. I’ve never used an agent for my nonfiction.

    Pimping yourself is work, yes. And it takes time, and you must educate yourself. But it’s not hard, or authors couldn’t do it. Before you decide to hire an agent to place your work, I suggest you read this. Some agents are transforming into publishers.

    Are there good tech author agents? Certainly. Don’t ask me, I’ve never had an agent. I can’t even say what percentage of agents are good… could be 99%, could be 1%. But no profession is all good, or all bad. (Except, perhaps, clowns. But that’s a separate issue.)

    If you really want an agent, if you’re convinced that you need an agent, you should know the signs of a bad agent. An agent must be your advocate. Not the publisher’s. And certainly not the agent’s. The agent’s job is to maximize your income so as to maximize his percentage, not to pay you a percent of his take from your work.

    In publishing, money always flows towards the author. Any deviation from this is a danger sign.