BSDCan proposals and rejections

This year, BSDCan passed a critical threshold: we got too many good proposals. As a conference, this is an excellent problem to have. As a concom member, it kind of sucks. When your papers are mostly excellent, how do you decide which proposals to take and which to reject?

What follows is my highly personal take on BSDCan proposals and the evaluation procedure. It should not be taken as BSDCan concom gospel.

Generally speaking, a person who gets persuaded to present at BSDCan submits in later years. This is great–it means we don’t have to track them down again. It means we’re doing a good job at running an educational, friendly, fun, worthwhile event. Repeat attendees and speakers mean you’re doing something right.

In some previous years, we’ve had difficulty filling the conference. In prior years the convention committee did a lot of speaker hunting and trapping. So let’s talk about the committee.

When BSDCan started the BSD projects were fairly small. The handful of us could track what was happening everywhere. Over the last decade the BSD projects expanded. We needed people who keep up on the innards of these projects, and who could give perspective on papers from the project’s perspective. We have George Neville-Neil for FreeBSD, and Bob Beck for OpenBSD. We have Dru Lavigne, because she not only knows bloody everyone, she knows if people are decent speakers or not. David Maxwell originally gave us our NetBSD insight. He’s somewhat moved on from NetBSD, but he still works hard for the BSDCan committee, so we’re not about to let him go. The concom could use a leading NetBSD person to both judge NetBSD papers, and to help drag the NetBSD community into proposing more.

Dan Langille is the chairman, but most of his work is in the area of keeping the BSDCan servers and sites running, arranging physical space, and such. While he evaluates papers, he clearly expects the concom to make decisions on what gets included and what doesn’t.

There’s also this Lucas dude. I have no idea why they keep him around, as he’s far too self-centered to contribute much of any use.

Another part of each concom member’s role is to advocate for projects and proposals they believe in. I expect Bob to stand up for interesting OpenBSD papers. I expect George to pimp interesting FreeBSD papers. I expect both of them to be able to rank proposals from their posse, so that we can have a useful give-and-take and reach the best possible combination of presentations.

So how do we evaluate proposals? We use Pentabarf, which lets each concom member rate proposals, contacts submitters, and helps organize the schedule.

But the concom has to evaluate the papers. I’ve put some criteria that we use, in random order. Others apply them differently, or have additional criteria, but I think none of them actively disagree with mine.

  • We must evaluate proposals as they are given. We want to accept the best proposals. We know how well our repeat presenters speak, but we still have to look at what they send us. What are they going to talk about? What are they going to cover? How technical is this talk? How much detail is in the proposal? Is this well thought out?
  • When we have lots of proposals, one talk per presenter. I could easily fill two days of talking on various technical things, but that would turn into “Lucas is a Nutter Con.” Nobody wants to see that, and besides, I do that at Penguicon. (Penguicon has a whole hotel, though, so they just shove me in a room and let me get on with it.) One of the reasons that people come to BSD cons is to hang out with BSD developers, experts, and assorted related characters. The more of those we can get into the con, the better experience people will have.
  • I’m biased towards bringing new people into BSDCan. I’ll happily go see Henning Brauer, Kirk McKusick, or George Rosamond speak. The first two are technical, while George is as enthusiastic as a puppy who’s just discovered peanut butter. But I don’t want to go to a con that has the same people year after year. The BSD community is growing. BSDCan needs to grow with it.
  • Concom members can submit, but we recuse ourselves from voting on our own proposals. To eliminate ourselves would be foolish–for example, Bob Beck’s fantastic LibreSSL talk would not have happened if concom could not present. But we let the other concom members decide if we’re going to talk. And being a member of the concom is not a guarantee of acceptance. We rejected David Maxwell’s proposal this year, and he hasn’t stormed off the committee in disgust or anything.
  • Tracks. We want some sysadmin, some kernel, some hacking, some “I don’t know what this is but it sounds dang cool.”
  • Presenter. Why should you be the one to give this talk?
  • Originality. Has this talk been presented before? We don’t demand originality, but if a talk has appeared before that’s a mark against it.
  • New. Is this new tech? New processes? New software? And yes, there’s a difference between “here’s my new prototype that nobody but me has ever seen” and “here’s new, but in production in several environments” software. Your previously-unseen basement prototype had better be spectacular if you want us to take your talk.
  • Draw. BSDCan is a business, albeit a nonprofit one. We either break even or die. Everything costs more than you budget, which means that if you plan to break even you’ll lose money. Having “big names” means that people are more likely to attend, which means more registration fees and more sponsors.
  • Can you speak? We’ve attended talks that look great on paper but have an unintelligible speaker. Your reputation will precede you. If you can’t speak clearly and distinctly, we won’t ask you back. Learn to speak in public. If you have this problem, but you’ve done something to remediate it–say, Toastmasters, or the Dale Carnegie public speaking courses, or something–say so.
  • BSD diversity. I want many different BSDs at BSDCan.

    There’s more to it than this, of course. I dug around trying to get more women to submit. I wouldn’t upvote a proposal because of the submitter’s gender, but I want to at least see them submit. After my efforts to let women know they’re welcome to submit, I was really pleased to see two very good kernel-related proposals from women. Having to say “we want women, but not you” would have really sucked.

    So, after all that, let’s talk about proposals.

    Having too many good proposals means that the average proposal quality increased. Proposals that would have been accepted in previous years based solely on the speaker’s reputation suddenly didn’t look so good next to the others.

    I expect the proposals to continue to improve in the future. I’m writing this blog post so that some of our usual suspects have a useful model for writing good proposals.

    Ideally, I would present both accepted and rejected talks here, and talk about why each met their fate. There’s problems with that, though. BSDCan doesn’t say up front that rejected talks will be made public. Organizations like USENIX say “we will do anything we want with your proposal,” but BSDCan doesn’t do that. (Whether we should or not is a separate discussion, and one the concom will have.) I went so far as to ask several rejected contributors if I could use their rejected proposals as examples. I’ve decided to not do that in this article, however. For one, it’s already too long, and I really need to generate some words on the ZFS book today. For another, negative criticism is both easy and less useful. Anyone can kick a dead dog. It’s much more useful to say “This was a great proposal, and here’s why.”

    We have two separate sets of events: tutorials and presentations. On the tutorial side, we’ve learned the hard way that sysadmin tutorials attract more attendees than networking talks. The farther you go from a Unix command line, the fewer BSDCan people are interested. The attendance only supports 2 days of tutorials, in one room. This year, we got twice that many tutorial proposals. If you want to submit a tutorial, a half-day one is much more likely to fly than a full day one. We took Peter’s PF tutorial, because it’s well attended every year. Sysadmins do DNS, and DNSSEC is absolutely booming in some parts of the world. Despite my passionate argument against the doofus doing the FreeBSD storage tutorial, they took it. And Luigi’s netmap proposal was well done.

    So, what’s in a good proposal? Here’s a couple examples I really liked. The details are not yet posted, but these will be public soon.

    First, here’s “Expanding RDMA (Remote Direct Memory Access) capability over Ethernet in FreeBSD” by Shany Michaely. Mrs. Michaely has never presented at BSDCan before.

    RDMA (Remote Direct Memory Access) is growing in popularity in Linux and Windows systems as a way to transfer large amounts of data with low latency and minimal involvement from the CPU. However RDMA InfiniBand drivers in FreeBSD were not updated, requiring users to create or port their own implementation of RDMA, and RDMA over Ethernet was not available in FreeBSD. This talk will describe how RDMA works and review the new addition of RoCE (RDMA over Converged Ethernet) network drivers in FreeBSD, allowing easier implementation of rapid data transfers with low CPU utilization over Ethernet and InfiniBand. This also enables the use of iSCSI over RDMA via the iSER (iSCSI Extensions for RDMA) protocol.

    full description:

    One of InfiniBand’s valuable capabilities is its support for RDMA (Remote Direct Memory Access) operations across a network, which enable rapid data transfer without involvement of the host CPU in the data path, and data placement to the responder memory without requiring its CPU awareness.

    RoCE (RDMA over Converged Ethernet) is a standard for RDMA over Ethernet.

    It provides true RDMA semantics for Ethernet and allows InfiniBand transport applications to work over an Ethernet network.

    FreeBSD is frequently used for storage purposes and RDMA capability has a high potential of improving performance in such storage applications.

    A good example for that is iSER (iSCSI Extensions for RDMA), a module being developed nowadays for FreeBSD, which enables the use of iSCSI over RoCE.

    The main idea of this talk is a short overview of RDMA – Its principles, key components and its main advantages. Additionally, it will cover the use of RoCE – implementation architecture, obstacles we overcame in the development, and a quick browse of RoCE’s different capabilities and milestones.

    So, what’s in this?

  • This proposal clearly states its BSD connection, including which BSD it uses.
  • This proposal discusses implementing a new technology
  • This proposal says “we accomplished X. This is how. This went wrong. This is what we learned. Beware of these dragons.”

    For a second example, here’s Matt Ahren’s proposal for “New OpenZFS features supporting remote replication.” Again, this will be public soon. Mr. Ahrens is a BSD conference veteran.

    OpenZFS send and receive forms the core of remote replication products, allowing incremental changes between snapshots to be serialized and transmitted to remote systems. In the past year, we have implemented several new features and performance enhancements to ZFS send/receive, which I will describe in this talk.

    Full description:

    This talk will cover:
    – Resumable ZFS send/receive, which allows send/receive to pick up where it left off after a failed receive (e.g. due to network outage or machine reboot).
    – ZFS receive prefetch, which is especially helpful with objects that are updated by random writes (e.g. databases or zvols/VMDKs).
    – ZFS send “rebase”, which can send changes between arbitrary snapshots; the incremental source is not restricted to being an ancestor of the snapshot being sent.

    In this talk, I will cover the impact of these changes to users of ZFS send/receive, including how to integrate them into remote replication products. I will also give an overview of how zfs send/receive works, and how these enhancements fit into the ZFS codebase.

    What do we have here?

  • Detail on what will be discussed and newly implemented features. Anyone can look at this proposal and say “there is meat on this bone.”
  • ZFS is a draw, and will bring people into the con. That helps.
  • The proposal includes things like the impact of these changes and how these new features fit into the software.

    So, here’s two good proposals.

    While I don’t want to talk about specific rejected papers, I will touch on some mistakes people made.

  • One-sentence descriptions. We judge the talk’s merit based on what you tell us. Anyone can say “I will talk about foobar.” You’re going up against proposals like the two above. Give us detail. The concom cannot read your mind. I had no idea whatsoever RDMA over Ethernet was a thing before reading that proposal. Every fooBSD developer might know your name and work–but I don’t. Once upon a time I knew everyone, but that time is years past. And I’m rating your proposal.
  • Not being BSD-specific. We had a very nice proposal for a talk on a popular scripting language. The proposal did not mention BSD. If we have a surplus of talks, cutting non-BSD talks from a BSD con is the obvious route.
  • Not including BSD at all. We had a couple proposals from sysadmins who work in really interesting environments, where simply keeping hardware and people alive is a challenge. I truly adore those talks. But, if your proposal doesn’t mention which BSD you use, for all we know you’re running everything on Windows XP. Again, this is a BSD conference.
  • Secrecy. Every few years we get a proposal that says “Here’s my provocative talk title. I’m not telling you anything about the talk.” Uh, no. That gives the concom no basis to make a decision on, and we’re responsible for the content of the conference. (It also gives attendees no basis to decide if they want to see your talk, which is less of an issue depending on who the speaker is.)
  • Spelling and grammar are not pimple cream, to be dabbed on where needed. If you’re going to indulge in floccinaucinihilipilification, you’d better be able to spell it.
  • Speaking of floccinaucinihilipilification: don’t submit a proposal that consists of running down other people’s work. We’re not interested. You’re better off saying why your stuff is awesome as opposed to denigrating someone else.

    One annoyance I had was people giving us multiple proposals. Don’t get me wrong–multiple proposals are good. They let us pick the talk that fits best with the conference. But the people who write good proposals sent multiple good proposals. They’re a pain to pick between!

    I’m going to name Peter Hessler here, because he said I could.

    Peter offered a wickedly excellent tutorial proposal on OpenBSD routing daemons, plus two good OpenBSD talks. Routing daemons are interesting to me, but BSDCan has learned that the further you get from the system, the fewer people attend the talk. We turned him down. That disappointed me, because I would have heckledattended. I hereby officially encourage Peter to submit that tutorial to a more network-related conference.

    Of his talk proposals, we chose the most highly scored in Pentabarf. Now, Bob Beck is the OpenBSD rep on the concom. If he had said “No, we really want his other talk,” we’d probably go along with it. That’s a part of why Bob is on the concom.

    We don’t accept BSDCan talks solely on the proposal grade in Pentabarf. If we had just said “Accept the top 40 talks, as rated by the concom in Pentabarf,” this would have been a very different conference, and many people would have been extremely unhappy with the results. But a strong proposal with a lot of information makes it easy for the concom to rate your proposal highly. If you’re willing to spend four hours making slides for your talk, spend a little time making a solid proposal for those slides.

    I recommend creating an outline for your slides, and using that outline as the basis of your proposal. That’s what I do.

    I can also say that the committee will be having discussions on how to cope with the “too many good talks” problem. If we’re lucky, this problem will only grow worse every year. I look forward to the day that we get so many excellent talks that we have to tell Kirk McKusick that we’re turning him down.

    This post has gone on far longer than I intended. Thank you for reading this far, if you did. I hope that some of you who were rejected this year try again in 2016 and beyond, with proposals that make me say “oh, hell yes, we need this talk!”

  • Word doc placed in Indesign gets numbered headings

    This has bit me more than once, and according to Google it affects nobody else on the whole Internet. Do I feel special or what?

    I write books in Microsoft Word, using Styles. Paragraph and character styles are essential for producing electronic and print books.

    At random times, when I import a Word doc into Indesign for print layout, numbers appear before the headings. These numbers do not appear in the Word document. Resolving this problem drives me near to madness.

    InDesign and Word both have features to number chapters and sections. The “place document” process somehow tickles one of them just right to activate this behavior.

    To get rid of it:

  • Go into the Word doc.
  • Modify the problem Style.
  • Select Format
  • Go to Numbering
  • Select a numbering scheme, and immediately select “no numbering.”
  • Save the doc

    You can now import without numbered headings mysteriously appearing.

    Recording this for my future reference will hopefully vaccinate me against ever having this problem again. That’s what disaster preparations are for, after all!

  • New novel out: “Immortal Clay”

    Most of you follow me for nonfiction, but this book just came out, so I’m gonna tell you about it anyway.

    My SF novel, Immortal Clay, just hit Kobo and Amazon. It’s in process at other outlets like Barnes & Noble, iTunes, and so on, and print is forthcoming.

    I’d describe this book as an alien invasion tale like Invasion of the Body Snatchers or The Thing, set after we lose.

    You can read the opening on my web site. Or you can jump straight to Kobo or Amazon and buy it sight unseen. I’m good either way.

    And Ben Baldwin did an absolutely amazing cover. I mean… wow! Click on the preview and take a look. If you have a big screen, look at the high-res version.

    I’m changing careers

    My employer was just bought by another company. I find myself unemployed. This was not unexpected, so I’ve had time to think about what to do next.

    I could have another IT job by three PM by picking up the phone and calling my friend Pam. If Pam was out of town, I’d call half a dozen other people and have a job by noon tomorrow. I’d certainly get a raise over what I’m making now–actually, given that I specifically chose a lower-paying job with less stress, I could double my salary. That’s what monster.com tells me.

    But I don’t think I want to do that.

    Instead, after talking with my family and taking a hard look at our finances, I’ve decided to write full time.

    This is a big pay cut for me. Yes, even from my low-stress low-pay job. It means not going out to eat, hoping the car doesn’t drop a transmission, and mowing my own lawn instead of having Chuck the lawn guy do it for me. But it’s work I’ll far enjoy more than being paged at stupid o’clock because some beancounter decided we didn’t need to replace that faulty power supply. I’ll enjoy it a heck of a lot more than attending yet another pointless staff meeting.

    Based on my previous book sales, it appears that I can get my income up to what my recently-departed job paid in about 12-18 months of hard writing. It’ll be a spartan year, but that’s okay.

    Any number of things could derail this plan. I might wind up working at a big company in six months, regretting ever calling anyone a beancounter.

    Writing for a living means I must figure out how quickly I actually write and coming up with a real production schedule. My books have all been written in one-hour stretches, in a variety of inconvenient locations. I have no idea what my sustained output looks like, especially once I no longer have any threat of a phone call waking me up in the middle of the night. (It doesn’t matter how “low-stress” a job is, a faulty email server that taken ten days to get properly fixed means two weeks without writing.)

    Writing for a living means I need to write towards money like a hungry rat gnawing through the brick wall of the butcher shop. My family is supportive, but we do like to go out to eat now and then at a fancy place, like Qdoba. I’m going to try a bunch of different projects and see which take off. I have high hopes for the forthcoming FreeBSD Mastery books, and I have a list of thirty other titles to work on.

    Writing for a living means I need to be a lot more consistent about, say, mentioning that I have a tip jar at the bottom of technical blog posts. I must overcome my shame at saying “Hey, if I helped you, give me money.”

    This means that if you’re one of the organizations that owe me conference reimbursements, I’m gonna knock on your door with my hand out. I have lots of time to do that now.

    This means when my clothes wear out I shop at Salvation Army rather than Costco. That’s okay. Old Sal is more fun, even though you probably don’t want to eat any of the free samples.

    Speaking of Costco? Yeah… try the farmer’s market in downtown Detroit instead. What’s in season is cheap.

    On the other hand, I only have one full-time job now instead of two. I’ll have free time. I’m looking forward to it. I’ve studied the craft of writing for decades now, and given up a lot of things for it. Why, I hear they rebooted Star Trek a few years ago. I grew up watching that show, and I’d really enjoy catching up with it. I can’t see how they’ll have a bald French guy as captain of the Enterprise, but what the heck, I’ll give it a try.

    But am really going to miss the lawn guy.

    New autobiography chapter: The Thumbs

    Lots of people are sad today, it seemed a good time to put this up. And as I got yelled at by people the last time I didn’t mention this on the blog:

    There’s a new autobiography chapter up.

    Why am I writing an autobiography? I’m not. But these are stories I tell over and over again, so I put them up in a central place.

    Google Play notes

    A couple months ago, I put my Tilted Windmill Press books up on Google Play. I firmly believe that having your books widely available is a good thing. Google Play let me be DRM-free, and while their discounting system is a pain to work around, I’d like people to be able to get my books easily. I’ve sold six books through Google Play, which isn’t great but hey, it’s six readers I wouldn’t have otherwise.

    Amazon is overwhelmingly my biggest reseller. I get over 90% of my self-publishing income from them. They provide truly impressive analytical tools. While sites like Smashwords provide you with spreadsheets that you can dump into whatever analytics tools you want, Amazon gives you the spreadsheets and a bunch of graphs and charts and other cool stuff.

    This made it really obvious that a day after my books went live on Google Play, my Amazon sales plummeted by about a third and have remained there.

    This is weird. And I really would like my sales back up where they were.

    I can think of lots of explanations, most of them involving computer algorithms. No conspiracy is required here. I’m certain Amazon didn’t de-prioritize my books just because they’re available on Google Play. Book sales fluctuate naturally, and there usually is a dip during the summer. But the graphs (both Amazon’s and my own) makes it really clear that this is an unusual slump.

    As an experiment, I’ve disabled my books in Google Play. People who bought the book will still have access to it, but nobody can purchase it now.

    If my Amazon sales recover, the Google Play store will remain off. The few Play sales don’t make up for the lost Amazon sales.

    I will report back on the results. But, if you’re wondering where my Google Play store went, the answer is: away.

    Penguicon 2014 Schedule

    “Hey, where is Lucas? Why hasn’t he posted lately?”

    I’ve done nothing worth posting about. Most of this month I spent removing a per-millennial switch from the core of the network, which was painstaking and annoying but not noteworthy. I then spent nine days at a writing workshop, which was fascinating, educational, and utterly exhausting. I could argue that the workshop was worth blogging about, but I was too busy writing to waste time writing. If you’re interested in writing, though, and you have a chance to do any of Dean or Kris’ workshops, go.

    So:

    Next weekend, I’ll be at Penguicon, appearing on various panels. You can see me at the following one-hour events.

    Friday

  • 5PM: BSD Operating Systems, a Tour – What it says on the label
  • Saturday

  • 11AM: Sudo – You’re Doing It Wrong – Why your popular sudo configuration is incorrect, and how to do it safely
  • 1PM: Copyright versus Free Information – What happens when the concept of ‘information can’t be contained’ clashes with content creators who want monetary recompense for their hard work? Speakers include:Michael W. Lucas, Shetan Noir, Eva Galperin, Cory Doctorow
  • 6PM: SSH Key Authentication Tutorial – If you’re not doing SSH key authentication, show up here.
  • 8PM: Self-Publishing 101 – Do you? Should you? Various tools and techniques and recommendations.
  • Sunday

  • 2PM: DNSSEC in 50 minutes – How DNSSEC works, and why you should care

    Now if you’ll excuse me, I have a whole great big heap of slides to do…

  • 2013 Failures and 2014 Goals

    I set goals for 2013. And I failed to meet them. I promised three short nonfiction books, Absolute OpenBSD 2nd edition, and a novel. You got AO2e and two short nonfiction books, DNSSEC Mastery and Sudo Mastery.

    While setting goals is important, exploring why you fail to meet those goals is just as important. Driving factors behind these goals boil down to three things.

  • These were pretty ambitious goals
  • Traveled to EuroBSDCon in September
  • January’s emergency appendectomy
  • I knew this was ambitious beforehand, but decided to try for it anyway. So, the first I accept as my own inability to realistically predict what I can do.

    I spent two weeks in Europe, both for EuroBSDCon and meeting with other writers and publishers. If I had to fly for eight hours one way (which I detest), and shift my body clock (which I find very difficult), I was going to make the trip worthwhile. But between preparing for teaching at EuroBSDCon, physical preparations for the trip, and recovering from the trip (both physically and real life), that cost me at least a month.

    You cannot predict something like an appendolith. That’s life. I didn’t merely have an appendolith, though. I had fever and infection and all sorts of horrible ghastly things. Proper recovery took months. Plus, general anaesthesia is insidious. Even when you wake up, it muddles your brain for weeks or months afterwards.

    When life derails your goals, you get back up as soon as you can and get back on track. Maybe you can’t complete the entire goal, but you can sure do a whole bunch of it. Or maybe the deadline slips into the next year. Whatever you do, you don’t quit.

    So: I failed.

    With those things in mind, let me set some goals for 2014. I already let part of this out at NYCBSDCon, so the rest of you might as well know.

    1) I will write at least three short nonfiction books. At least one will be on OpenBSD, at least one will be on FreeBSD. At least two will see print by the end of the year.

    2) Last year’s novel will get out of my house. A couple of my author friends are encouraging me to run the novel through a publisher and have offered introductions. Their faith in my work is sincerely touching. I’m inclined to self-publish, but am keeping an open mind. We’ll see what happens. (I waited to publish this list until I finished the first draft, for those who wonder.)

    3) I’ll write at least 120,000 words of fiction. (See FAQ 9.)

    4) I will not change time zones for a conference. EuroBSDCon was great, and I’m sure that the Sofia conference will be just as grand, but that kind of travel messes me up too badly to write. I’ll be at BSDCan, but this year I’m taking the train. Because I really, really abhor flying.

    5) I’m a candidate for my dojo’s red sash test this year. If selected, I will do my best to pass. This means much practice and sweat, as the test lasts several hours. For example, my green sash test included over four hundred falls. The falling isn’t bad, but getting up again gets pretty rough. The red sash test is worse.

    My deadline for these goals in February 2015. Because my birthday is in February. Using my personal year for goals always feels better than using the calendar year.

    In a more general sense:

    I’m starting a series of short FreeBSD books, each dedicated to a single topic. Which topics will I cover? Whatever I’m working with at the moment, that’s holding still long enough for me to write about it. For example, at this moment it doesn’t make sense for me to write a book about pkgng, because pkgng is developing quickly.

    Eventually, I’ll create enough FreeBSD content to “remix” into a big FreeBSD book, probably a 3rd edition of Absolute FreeBSD.

    The small books will use the 6×9 form factor, and all be about the size of SSH Mastery. People have taken well to this size of book at the $10 ebook/$20 print price point.

    This will also let me judge which material should go into a big book. If nobody buys, say, a small FreeBSD virtualization book, it’s clear I shouldn’t put that topic into a big book, because nobody cares.

    Ideally, I’ll be able to produce a slipcase for a complete collection of small FreeBSD books. At this time, I’m planning to give them themed covers based on old pulp magazines, minus the blatant sexism and racism. (It’s been suggested by more than one person that I keep both elements but make them funny. It CAN be done, just as it is possible to make thoughtful, incisive, and honestly funny jokes about any other painful or horrifying topic. But it’s extraordinarily hard, especially for someone who looks utterly “privileged white male.” I choose to spend my energy elsewhere.) But Beastie as a hard-boiled private eye, Beastie swinging on a vine through the jungle, Beastie as the flying ace, and so on? I think that’s going to look fantastic.

    What will the OpenBSD book be? I have three ideas. I’ve caught wind of other OpenBSD books in progress, however. I need to meet with my fellow BSD authors at BSDCan 2014 and hash things out with them. It’s very important that we not step on each other’s else’s projects, especially when it’s simple enough to avoid with five minutes at the bar. That’s why I won’t do, say, a pfSense book — Chris and Jim have that territory covered quite well. I’m confident that at least one of my three ideas will be free, if for no other reason than we don’t have that many OpenBSD authors.

    I expect to let the FreeBSD Foundation have books at cost for PBS-style donation prizes. “Donate $100, and we’ll send you this $20 book!”

    I have a clever idea for using the OpenBSD book to support OpenBSD. Theo and I discussed it briefly at EuroBSDCon. I don’t know if it will actually work, mind you. But worst case, they’ll have my book in the OpenBSD bookstore, with proceeds going to OpenBSD. (For anyone who is wondering, Austin Hook is very very easy to work with. The hardest part of getting books to the OpenBSD bookstore is figuring out how to cram all the shipping information onto the CreateSpace web form, which is certainly not Austin’s fault.)

    So, is this a cynical scheme to get you to give me more money? No… and yes.

    You’ll have the option to give me any amount of money you wish, from zero up to over a hundred bucks. There’s a couple people that I suspect will buy every book, in every version. I suspect others will get a few of the small books. Others will wait for a big book. Some will buy all the small books just so they can fill a slipcase. This is about options. It’s about getting content into reader’s hands as quickly as possible.

    But if you want to give me money, I’m certainly not going to argue.

    The good news is, I now know exactly what an appendolith feels like. The next time my appendix blows up, I’ll jump on it at the earliest possible moment. Why, just today I’ve felt three twinges that might have been a faulty appendix. Catching these things early is the key to quick recovery, after all.

    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.