Monday, June 22, 2015

Publishing Effective Modern C++, Part 2

In part 1, I divided technical publishing into four tasks (manuscript creation, production, distribution, and marketing), and I gave my perspective on publishing economics from a traditional technical publisher's point of view. In that post, my financial analysis was based on the assumption that most technical books sell no more than 5000 copies. For an author who's already been published, that assumption can be replaced with (or at least tempered by) the author's past performance. In my case, I have a history of five C++ books dating back to 1991. Each has sold more than 5000 copies.

If I wanted to impress you, I'd tell you that Effective C++, Third Edition, has sold over 225,000 copies, which, if my royalty statements are to believed and my spreadsheet summarizing them is accurate, it has. But then I'd worry that you'd think I light fires with 100-dollar bills and own an island in a tropical paradise. So I'd hasten to add that a great many of those sales took place in foreign countries, where my royalties are...well, let's put it this way: my most recent royalty statement has an entry for 10,000 books in Chinese, and my take was about 27 cents per book. That's not the kind of money that buys islands.

Still, if an author has sold well in the past, that suggests that a publisher is unlikely to lose money on a similar book project by the same author. (I say "similar" projects, because an author's success with topic X may say little about that author's success with topic Y. Donald Knuth is a legendary author in Computer Science, but I don't think his novel burned up the best-seller lists.)

For an established author, what's a reasonable approach to sharing book revenues with a publisher? I can think of three basic designs:
  • Flat rate: The author gets a flat percentage of the income produced by the book. Presumably this is a higher rate than an unproven author would receive.
  • Increasing tiers: The author gets a flat rate for the first n books, then a higher rate after that. The lower initial rate permits the publisher to quickly recover their up-front costs. There may be multiple tiers: the more you sell, the higher the rate. For example, Apress's default contract has five tiers, ranging from 10% to 20%.
  • Decreasing tiers: The author gets a flat rate for the first n books, then a lower rate after that. The higher initial rate acknowledges that the proven author can sell some books on his or her reputation alone. For such sales, the publisher brings little to the party. As sales rise, the role of the publisher in finding buyers increases, so the publisher deserves a greater share of the revenue.
I don't know anybody who's used a decreasing tiered royalty scheme, but I think it makes sense. The looks on the faces of the few authors and publishers I've mentioned it to suggest that I may be alone in this belief.

So here's where we stand, or, more accurately, where I stood in early 2014 when I started thinking about signing a publishing contract for Effective Modern C++:
  • Of the four tasks involved in publishing the book, I wanted to be responsible only for manuscript creation. However, I wanted a voice in some aspects of production (e.g., page layout, use of color, usability on mobile devices) and marketing (e.g., how the book is pitched to prospective buyers).
  • I believed that the publisher's distribution and marketing efforts would be an important factor in determining the success of the book, measured both in terms of revenue generated and programmers reached.
  • I understood that the publisher had to make a nontrivial investment to bring the book to market, but I felt that my track record as a C++ author (and my lack of a request for an advance) essentially guaranteed that the investment would be recouped.
Addison-Wesley and I undertook negotiations, and they offered generous terms. Compared to the deals most technical authors receive, I was offered more of everything: higher royalties, a bigger voice in production and marketing decisions, greater autonomy as an author--you name it. Had I signed, it would have been the most generous contract I'd had with AW in my nearly quarter century of working with them.


Unfortunately, I felt that what AW offered didn't embody a principle I had begun to realize was very important to me: fairness. I believed that the terms of the publishing agreement should fairly reflect our respective contributions to the success of the book. But how do you evaluate that? How do you disentangle the author's contribution to the book's success from that of the publisher?

Being an author, I felt that the component I was tackling--the writing--was the most important of the publishing tasks. Without a manuscript, the world's best production, distribution, and marketing teams have nothing to do. Given a good manuscript, however, anybody can produce PDF and sell it online. That is, they can produce, distribute, and market a book. They may not do it well, but they can do it. It's no longer that difficult to publish something on your own.

At the same time, professionals versed in production, distribution, and marketing could take my manuscript, make it available in multiple formats on multiple platforms, and sell a lot more copies than I could myself. Since 2010, for example, I've sold my annotated training materials through an arrangement with Artima that has me handle manuscript creation and production, while Artima is responsible for online sales and PDF downloads. Compared to "full service" publishing, production and distribution in this arrangement are quite limited (the materials are available only in PDF and at only one web site), and marketing barely exists. Feedback from readers indicates that the content of these publications is good, but sales have been underwhelming.

I conclude that it's not necessary to have skilled people working on production, distribution, and marketing to bring a book to market, but that doesn't mean those aspects of publishing aren't important. They are.

So what's fair? If a book bombs, the revenue involved isn't enough to make much difference to either party. The publisher loses money, and the author loses a chunk of his or her life. But if a book is successful--if it earns a zillion dollars over its lifetime--how much of that zillion should go to the author and how much should go to the publisher? What's a fair revenue split?

I ultimately decided that AW's offer, though generous, didn't reflect what I thought was fair. We tried to bridge the gap in various ways, but we weren't able to come to an accord. That's when I approached O'Reilly. I explained what I was looking for in a publishing agreement, i.e., what I considered a fair apportionment between author and publisher of the work to be done and the revenues ultimately received. We quickly agreed on terms, and that, in a nutshell, is why EMC++ is an O'Reilly book.

In my Advice to Prospective Book Authors, I say:
Given the uncertain financial return on your authoring effort, I suggest you figure out what's most important to you. When your book comes out, what will make you say, "I'm happy with the way things went, even if the book sells poorly"? Do you want to have designed your own cover? To have had complete editorial control? To have specified how the book would be marketed? To have made the text of the book available at your web site? If these things are important to you, you may want to trade them off against financial aspects of the contract. After all, even if the book sells zero copies, you'll still have designed your own cover, have exercised complete editorial control, have specified how the book would be marketed, etc. If those things have value to you, I encourage you to find agreement with your editor on them.
For EMC++, I ultimately decided that having contract terms I considered fair--not just generous--was important enough to warrant changing to a different publisher. I knew that such a shift was accompanied by a Pandora's box of unknowns, but I'm sincere in my advice above, so I decided to follow it myself.

I still work with AW, and I still enjoy doing it. It's still home for my three earlier C++ books, and I still act as consulting editor for the increasingly active Effective Software Development Series. (In the past nine months, we've published both Effective Python and Effective Ruby.) My decision to publish EMC++ with O'Reilly wasn't an expression of displeasure with AW. It was a reflection of the the fact that, taking everything into account, O'Reilly was a better match for the kind of arrangement I wanted to have with my publisher for Effective Modern C++.

Scott

12 comments:

Irfan said...

Hello Scott,

Although I now find elusive the vivid details concerning the layout choices either you made or the typesetter made on your behalf for your earlier books published by AWL, however, based on whatsoever I remember, in terms of font and font size, your books certainly used to stand out as much easier to read without exacting the reader’s visual system disproportionately. As any performer’s — whether it be a movie star, a sportsman, a designer, or a technical author — past performances and choices create a certain level of expectation and establish the presumed tone for the future works from the same performer, in your case, the author of works of scholarships aimed at a particular audience, I started reading one of your “Annotated Training Materials” with high expectations. However, I found the presentation quite discouraging and an instantaneous drain on the enthusiasm with which I had started to read that material. Considering that arrangement placed the burden of presentation and preparation on your shoulders, I would like to apologize for the choice of words used to convey the dismay I felt, which still remains the sole reason for leaving after reading just a couple of pages. However, I strongly believe that had the presentation of the material met the production quality of the books you published with AWL, then you would have not only succeeded in selling an extra few PDFs but also found at least a word-of-mouth promoter, or may be an extra few.

Once again, I would like to apologize for the choice of words; however, I wanted to convey the actual sentiment felt at the time, one which proved decisive, as well.

Irfan.

Scott Meyers said...

@Irfan: I'm sorry you didn't care for the layout of my annotated training materials. However, I think it's important to note that they're just that--annotated training materials. They're not books. If you were expecting them to look like books, you were bound to be disappointed. That's one of the reasons I made significant excerpts of the materials available for free: I wanted people to understand what they'd be buying.

Irfan said...

Hello Scott,

The tone of your response suggests that you believe in a resolute and considered manner that the chosen layout for the “Training Materials” perfectly suits the type of material based on its purpose. Regardless of the correctness of the aforementioned, I would, based on whatsoever I had written in my initial comment, like to reiterate that after setting a high standard — in my opinion, higher than most other authors — the author then carries the additional burden of managing his or her audiences’ expectations, as well. When I compare the formatting of the “Training Materials” with your books, I feel that when working with the two, you decided to operate on two extremes: high or very high quality formatting for the books, especially the ones you published with AWL; completely ignoring the formatting and its effect on audience in case of “Training Materials.” I firmly believe that despite their lower status, you still should have chosen a middle ground, if not better.

Nonetheless, thank you for making the excerpts available so to make it easier for the buyers to make an informed decision.

Irfan.

Scott Meyers said...

@Irfan: I'd be interested to know what you dislike about the formatting of the training materials. They are, after all, just PDF versions of what PowerPoint produces.

As for setting expectations, that's why I made significant excerpts of the materials available for free download: so prospective buyers would know exactly what they'd be getting.

Irfan said...

Hello Scott,

I am listing the factors and reasons, where applicable, that I found dissuading in the order of severity. Considering that I actually did read a few slides presenting some code samples, as well, I believe that the below mentioned factors had a cumulative effect on the desire to read further.

1. As a programmer, whenever I open a document pertaining to programming or in case of which I expect to come across at least some programming samples, I expect those samples written or presented using a fixed width font, preferably 'Courier New', or, although not my first preference, Consolas. In case of Consolas, I find that small font size also hinders the reading and comprehension part.

2. In case of programming or coding examples or samples, unless the use of colors other than the color used for body text remains limited to only the keywords of that programming language, that can — in my case, it certainly did — hamper the progress as well.

3. I found the blue that you have used in your examples too bright, and when you come across material, code samples in case of your slides, written in such a color often, then it probably buries the desire to read any further.

4. The use of the Arial font face, or the font face that strikingly resembles Arial font face, for links and email addresses, especially in larger font size than the surrounding text also proved effective in dampening the desire.

5. Narrow line spacing did not help much either.

6. I actually found the use of Red to write your name and occupation somewhat hilarious. As a programmer and web surfer, I usually come across such usage whenever the program designer or website author wants to indicate some sort of an error. Considering that you started programming even before I was born, I certainly have failed to fathom your reason for choosing that color to write your name and designation. I would like to add, however, that this probably did not play that huge a part in deciding to stop after perusing just a few slides.

I hope that I have conveyed all of the reasons that eventually brought to an immature end the perusal that I had started with some desire and enthusiasm. Before signing off, I would once again like to thank you for making significant number of pages available to potential buyers.

Sincerely,

Irfan.

Scott Meyers said...

@Irfan: Thanks for your comments.

Irfan said...

You are most welcome, and I would like to add that I sincerely hope that you did not find the critique offensive.

Irfan.

Scott Meyers said...

Of course not. I always welcome sincere feedback :-)

Javin said...

Thanks Scott, I really loved Effective C++ though I am a Java developer. I have most of Effective X title in my book shelf because they always open a new window of learning. Thanks a lot ..

Scott Meyers said...

@Javin: I'm glad you like the books!

Flo said...

Hello,
I want to learn C++(with datastructure). Is the effective modern c++ a good book to learn from -almost- scratch or is it only for those who have already a background ?
Thanks :)

Scott Meyers said...

@Flo: Effective Modern C++ assumes that you already know the basics of C++ programming, including the fundamental features of C++11. If you don't have this background, you'll probably find the book difficult to understand.

If you're unsure whether EMC++ is the book for you, I suggest you download the free sample chapter available here. That will show you exactly what the book is like.