Chapter 2: The Proposal
In some respects, the proposal is the most important and difficult phase of the entire project. Once you have done the work of identifying your audience and clearly conceiving a purpose for your book--incarnating that purpose in a detailed outline and formulating a realistic schedule for the work--there is nothing left but straightforward execution. And that execution will be much simpler for the fact that you have thought through the issues in advance. It is no longer a matter of worrying about broad questions of content or approach, but simply of capturing preconceived content in the best words possible.
A complete proposal includes several things:
We aren't asking for statements of high formality. But we do look for evidence of good writing ability, attention to detail, and mastery of both subject and context--as well as a realistic appreciation of the task's challenges.
What Will the Book Be Good For?
When people buy your book, it will be with some purpose in mind. Your book must, above all, be useful. Books simply describing a particular technology tend to be superseded by other, more practical books. O'Reilly excels in the "how to" market, and sells well to it. If you can really tell people things that save them time and trouble, the book itself is cheap.
One of our editors recalls the time when he was writing the RS-232 chapter in Managing UUCP. He bought an expensive hardback that was supposed to be the authoritative guide to RS-232--and it was. It was chock-full of detailed technical information about signal degradation, voltages on various signals, and so on. But he found it surprisingly free of practical, useful information for anyone but RS-232 interface designers.
There is, of course, room for books offering nothing more than technical reference, and people certainly do buy books just to be up on the latest technology. But we always look for the "something more." Here's an editor's comment on the first draft of a proposal for an FDDI book:
Know precisely what you want to achieve, and why your readers will be interested in it. Your proposal to us should summarize the audience and purpose of the book clearly.
Here's an introduction to the FDDI proposal after these comments:
The discussion of audience is informal and direct. We're not looking for detailed analysis of audience with supporting statistics--just a sense of exactly who it is you think you're writing for. Note also that the proposal doesn't just talk about the audience in the abstract, but about how the subject matter of the book will address their needs. Ideally, the purpose statement from the proposal could be used in the preface of the finished book, to help the reader figure out if the book is for him or her.
The Market for the Book
In one sense, the market for the book is implicit in its purpose and audience. If there's a real need for the book, and you do a good job of addressing that need, the book will sell. However, there are often ancillary factors, such as competing works, industry trends, or size of user base, that may have bearing on just how successful the book will be.
Needless to say, we have our own understanding of the market potential in various areas. If you think you have a good idea, but don't feel you have the resources to demonstrate its marketability, feel free to contact us and discuss the matter. Perhaps we can help you through this stage.
Of course, if you do have statistics for the size of the market for the book, they'd be more than welcome. Similarly, if you know that several companies are planning to adopt or promote a given technology, this might be an important point to make about your audience.
If there are competitive books now on the market or foreseen, briefly describe them and explain their relation to your book. View yourself as "selling" us on the likely success of the undertaking.
You should be aware that if there's a really good book on a topic from another publisher, we typically will not want to publish a competing book. However, there are often other books that overlap somewhat in subject matter or in style but do not compete directly. A discussion of these books may help us to evaluate the market for your book, or may help to clarify the approach you plan to take.
For example, you might point out that there are three books currently available on Unix system administration, but that each has certain drawbacks that you hope to remedy in your own effort. Or you might point out that a particular book has been extremely successful, and that you plan to do a similar book for another subject.
As noted in the previous chapter, we like best to do books on subjects that are poorly documented elsewhere. In that case, the statement of the competition (or lack thereof) is likely to be implicit in the description of the purpose and audience for the book.
Make your outline as detailed as possible. Until we can envision your book in exceedingly concrete terms, we cannot know whether to sign up for it. The outline should include:
The outline need not consist of bulleted lists. In fact, we prefer a "talking" outline. This is a chapter-by-chapter summary, in paragraph form, explaining what each chapter will cover, and why. Such a paragraph may be followed by lists to show the structure of the chapter, but the talking part is most important.
Here's an example of one chapter's outline in the original proposal for our sendmail book:
In this case, the author didn't even use full paragraphs, but a telegraphic style relying on sentence fragments. Nonetheless, one gets the feeling of a running commentary on the content and flow of the chapter.
Be sure to provide us with an estimate of the size of the book. We aren't wedded to any number you provide, but it will help us to evaluate whether your treatment will be appropriately detailed, and whether your schedule is realistic. It will also help us to estimate the price of the book (and thus calculate the size of the advance we're willing to offer).
Some authors like to start at the beginning of their outline and work steadily, chapter by chapter, to the end. Others jump around, developing several chapters simultaneously, perhaps moving material back and forth between them, and iteratively improving them until they are ready to submit. We are flexible when it comes to different approaches to writing. However, we are going to want some evidence that you have thought through the actual process of putting your words down on paper.
Be realistic in your planning. In particular, you shouldn't plan to submit a complete draft, but rather, to send the book, chapter by chapter (or block by block, if you work in larger or smaller units than chapters) to your editor. This will allow the editor to make helpful comments as you go, and will save everyone a lot of work later on. (We'll return to this subject in Chapter 4.)
Ideally, your proposal should include a chapter-by-chapter schedule for the submission of first drafts. In arriving at dates for later chapters, you should reckon with the need to assimilate editorial comments on earlier chapters. Allow time for specifying and creating at least rough sketches of your illustrations--these will need to be there for both the editorial and technical reviewers.
Be sure to factor in the effects of such things as vacation time and competing demands of other work. Very often the success of a book depends, in substantial part, upon the timing of its publication. If your schedule is not accurate, we lose control of this crucial element. Plan on giving us prompt notification of changes in your schedule as you work on the book.
The schedule culminates in a completed first draft. If you've submitted chapters religiously to your editor and incorporated his or her comments, your book should by now be substantially complete. Nonetheless, there is a wild card: it is at this point that we will submit your book for technical review by a collection of your peers (as well as by other editors on the ORA staff). If the material has already been sent out for technical review on a chapter-by-chapter basis and you've incorporated those review comments, there shouldn't be any surprises at this point. But we are still going to get the entire draft reviewed, as there are certain kinds of issues that don't become apparent until the reviewers are looking at the whole manuscript. If you've done a good job, technical review comments might be incorporated in only a few weeks. But it is equally likely that reviewers might point out major topics that have been left out, or errors in approach that might require more major rewriting.
For purposes of establishing the delivery date in the contract (see Chapter 3), you should allow two weeks to a month from the time you submit the completed first draft for the reviewers to perform their technical review, and another month to incorporate the review comments. The final date in your schedule is the turnover of your manuscript for production. Typically, we allow two to three months for final production (copyediting, setting page breaks, making sure that conventions are followed consistently, and producing camera-ready copy) and printing.
Your Writing Sample
If we have not worked with you before, we need to see a sample of your writing. Preferably, this will be a type of writing similar to the book you are proposing, although that certainly is not absolutely necessary. We can probably make the necessary judgments based on any extended piece of writing you provide us. This should be your writing (at least 99.44%)--not the partial work of an editor. If you have provided a "talking outline" as described above, that may prove an adequate writing sample, although it is better if you actually write a section of text from the book you are proposing. If we aren't satisfied with the writing sample you provide, we may ask you to do just that: write a chapter for the proposed book before we sign the contract.
It is not that we are looking for Pulitzer prize-winning authors. Probably the single most important requirement is for you to have a thorough understanding of what you are writing about. But the writing sample will help us gauge the overall process more accurately: for example, our scheduling will be affected by the time we estimate is required for editorial support.
Your proposal should indicate the tools that you plan to use to write the book.
To allow your book to move through our production process as efficiently and accurately as possible, we need electronic source files that use paragraph and inline style tags, or semantic markup tags. If you format the source in a word processor by inserting a tab for a new paragraph and printing different levels of headers in gradations of point sizes and in special fonts, etc., so that text prints appropriately during manuscript development, it will be necessary for us to clean up and reformat your manuscript, causing delays and possibly introducing errors. We need electronically marked-up paragraph and inline style tags, not font and point and space specifications.
Concretely, this means that any of the following formats for source files will optimize the production process for a given O'Reilly book:
We realize you want to spend your time and effort on writing your book, not wrestling with formatting issues. Therefore, we want to be able to allow you to work in an environment where you feel productive and comfortable. However, you are strongly discouraged from providing files in the following formats because they will definitely slow down a book's passage through production. With these formats, we may hire freelancers to convert the files to an acceptable format, or your editor may be required to do substantial work on the files. All this means not just delays but also the increased possibility of screw-ups and hassles for all concerned. Use of any of the following formats requires the explicit permission of your editor:
For more information about formats and templates, please contact O'Reilly's Content Services team at
Who Are You?Obviously, a brief description of your qualifications can help us to evaluate your ability to deliver the manuscript you're proposing. But we're looking for more than a resume.
You see, we publish books with personality. Too many technical books read like a speech given in a monotone, with the speaker never looking up from the lectern. Personality in a book isn't funny stories (though they can be appropriate at times), or interjection of personal opinion (though that too can be appropriate): it is simply a matter of making "eye contact" with the reader.
Keep in mind that although an "audience" is a class of readers, your book is only read by one person at a time, and so your book is truly a one-on-one between you and that reader.
Despite what most of us learned in school, writing is above all communication--that is, the transfer of information between two parties. Just as we want to see that you've clearly identified your audience, we want to understand how not only your background but who you are will lend itself to the job.
Here's an example of an effective personal statement:
Obviously, a statement like this might occur in a cover letter, or at the start of a proposal rather than in a little "biographical section" at the end. We don't look for a particular proposal format: we just want you to convince us that the book is worth doing, that you've thought it through, and that you're the person to do it. Exactly how you do that convincing is up to you.
Don't Hesitate to Ask Questions
While we will ask you to provide us, one way or another, with all of the elements described in this chapter, do feel free to contact us with questions and informal proposals at any time. We've signed books on the strength of a one-page e-mail message or a brief phone conversation. At the very least, we can let you know whether we like your book idea before you commit a lot of work to the proposal. Mail to will reach the editorial coordinator.