Date: Sun, 8 Aug 1999 23:47:33 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: jkh@zippy.cdrom.com (Jordan K. Hubbard) Cc: BMCGROARTY@high-voltage.com, jooji@webnology.com, freebsd-advocacy@FreeBSD.ORG Subject: Authors notes for FreeBSD books Message-ID: <199908082347.QAA05404@usr08.primenet.com> In-Reply-To: <1080.933972482@localhost> from "Jordan K. Hubbard" at Aug 6, 99 01:48:02 pm
next in thread | previous in thread | raw e-mail | index | archive | help
I've changed the subject to be more accurate. I was going to call it "Jordan's call for FreeBSD books", but I find the current subject line more fitting. Jordan Hubbard writes: > > I think that there are already so many more obvious and clearly > detrimental shortcomings in FreeBSD's advocacy (lack of books, > magazines, trade shows and other press coverage) that anyone looking > at the mascot as an "issue" is a) barking up the wrong tree and > b) focusing their time and energy in the wrong direction. Jordan, I would like to address, in depth, the "books issue" you have raised. I would be more than happy to write a FreeBSD book (or two) *IFF* it would settle down from its moving target status long enough for there to be sufficient sales. For an internals book, this would mean: 1) Define standard interfaces in the kernel. 2) Commit to them for a (relatively) long time (e.g. 1.5 years, otherwise known as 3 full FreeBSD releases). The same goes for a "writing device drivers" book, or even something describing how to do any API-intensive user space work, using FreeBSD as a platform. The people who have never done a technical edit on a book, edited a book, or written a book (in increasing order of difficulty), seem to assume that books "just pop out". They don't. If they did, I have several requests currently outstanding from publishing companies that I would be able to accept, e.g. a book on configuring an IPv6 network (shame that couldn't also be a FreeBSD book, since I would find it more tempting to accept the offer, but FreeBSD is not sufficiently married to a particular IPv6 to allow this). I have done technical editing for Prentice Hall on several books, (you may have seen me specifically credited in the preface of one of them, "UNIX Internals: the new frontiers" by Vahalia) and even that light load was over three weeks (~130 hours) of work. I have eleven books in progress (none FreeBSD), and I have actually completed four books: two fiction (both looking for a non-vanity publisher), one technical about writing applications to use serial ports portably across many UNIX platforms (obsoleted before publication by the SVR4 convergence), and one technical about programming -- "C for Race Car Drivers" -- which was obsoleted while pending publication (it had been scheduled) by compiler technology removing the need to write C in certain ways to get faster and smaller executables (bad timing for the PC compiler war: another reason to hate Microsoft). I'm not willing to take on a book (again) that will be obsolete before its publication, and thus my works in progress are all either fiction (four), or topics which won't be easily obsoleted. Right now, that translates to "nothing with any technical depth for FreeBSD in the near future, unless the ground rules change". What it takes to write a book: ------------------------------ A book, even some of the small O'Reilly books, generally takes approximately 2000 hours of work to complete. This is one man year. [ Contrary to popular opinion, writing a book is not so simple as writing prose to a mailing list ] For it to be worthwhile for an author to engage in a book project, the project has to have an expected pay-out of at least one year's salary (and my salary is much higher than it was when I wrote the previous two), preferrably more, since writing is more draining, at least for me, than other work, and after a year of it, I would need a very long vacation. I think that anyone (who isn't naieve, or isn't writing a puff-piece to "compete" with the litter of Linux puff-pieces) will require some type of warrant that the target won't move, and make the book lose all value for the work invested. Even a typical puff-piece faces a currently uncertain future, e.g. with the threat of "The New Install System, Real Soon Now", and so on. On the plus side, a puff-piece can be done in ~6 man months, but this still makes it one release out of date, unless you hold it and reedit it very quickly following the release. A publisher is unlikely to agree to this without a hard/fast FreeBSD release date, since they need to schedule presses, channel identification, shipping, and any publicity, to coincide with a book held in abeyance for a final edit. The only way I can see where this would not be the case would be for a book that was a collaborative effort, to shorten the time to market to avoid the book getting stale. In general, collaborative efforts can't be too technical, and the overall editing pass to fix the tone of a multi-author book to a single tone (an irritating read will get terrible reviews) still must be done by a single person, and that can't be parallelized away (minimum, 160 hours: ~4 weeks). For a technical collaborative work, you will need ~120 hours of technical editing by at least three different people (more is better), and double the editing pass (a brief one before the technical edits are applied, a longer one, with reference to the authors, afterward, to integrate the various authors fixes). Note: collaborative works generally require the same (or a higher, given editing overhead) expected payout as individual works, and this means that you can only modify the time-to-market requirement, but the shelf-life requirement (time to obsolescence) can not be bypassed. Also, as a heads up: having many Linux distributions is actually a plus, both for the available fodder for puff-pieces, and for packing a CDROM in the plastic envelope in the back of the book. An author can rewrite the same book four (or more) times, under different pen names, choosing a different Linux each time, and reorganising, retitling, and reindexing chapters (I know of at least three Linux books that were produced from a single original manuscript using this formula; I've considered writing a Linux puff-piece to cash in, myself). Sort of the "Harlequin Romance" approach to technical writing... Too, you might consider getting rough translation of the Japanese FreeBSD books, in conjunction with an English editor, as one way to attack this problem. The downside to this is the fee split with the original author takes most of the incentive away for the translators and editor, and the international publication rights licensing issues can be thorny. Jordan is actually in the best position of anyone to exercise on this approach. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908082347.QAA05404>