Origins

In the first chapter of this book, we considered the definition of Lean Publishing at length. In this second chapter, we consider its origins.

The present reality of authors writing finished books which publishers then publish is neither natural nor inevitable. Despite how inescapable it seems today, the notion of selling a finished book is very much a recent, and almost reactionary, phenomenon. The natural way that stories are told is in serial. This has been true since humans first told stories around a campfire.

But in terms of Lean Publishing, the place to look first for origins is the 1800s.

Serial fiction was first popularized in Victorian England by Charles Dickens .

Dickens wrote everything but his Christmas stories in serial. His first work was Sketches by “Boz”, which he started writing in 1833 when he was only 21. Dickens published them in various newspapers and periodicals while he wrote them. Completed in 1836, these sketches were works of fiction and non-fiction describing London life.

The primary importance of Sketches by “Boz” was that it led to Dickens being involved in The Pickwick Papers. The Pickwick Papers was a monthly serial which was started when Dickens was 24. It was published in serial from March 1836 - October 1837.

The Pickwick Papers began as an idea by famous illustrator Robert Seymour for a series of sketches about a club of cockney hunters and fishermen. Seymour proposed the idea to his publisher. All that was needed was a writer to fill in some text around the pictures.

Enter Dickens.

However, Dickens didn’t know much about hunting or fishing, so he helpfully proposed that he write his own story and the drawings be adapted to match his story. (Talk about a pivot!) Thus, The Pickwick Papers began. (Well, actually, the title was: The Posthumous Papers of the Pickwick Club, Containing a Faithful Record of the Perambulations, Perils, Travels, Adventures and Sporting Transactions of the Corresponding Members. But we’ll call it The Pickwick Papers, for obvious reasons.)

Needless to say, Robert Seymour was unhappy. Shortly after the project began, he had an argument over drinks with Charles Dickens. The next night, Robert Seymour completed this illustration for The Pickwick Papers, entitled “The Dying Clown”.

He then killed himself with a shotgun.

The Pickwick Papers was only on chapter 2 at that point, and it was doing badly. However, like all great writers and anyone who has done anything worth remembering, Dickens persisted—and in chapter 10 invented the humorous cockney character of Sam Weller, who was to Mr. Pickwick what Sancho Panza was to Don Quixote .

The Pickwick Papers became a publishing phenomenon. Whereas the first monthly instalment had only sold about 400 copies, the last monthly instalment sold about 40,000 copies.

Dickens’ combination of popularity and critical acclaim (well, from most critics) established serial fiction as the way that books should be first published in the 1800s. Books, split into volumes, were where successful serials were reprinted once completed. The serial was how you built traction for the book. The finished book was a predictable way of earning extra profit afterward.

Dickens published all his novels in serial, except the Christmas books. You may have heard of some of them:

• The Adventures of Oliver Twist, Bentley’s Miscellany, Monthly serial, February 1837 - April 1839
• The Life and Adventures of Nicholas Nickleby, Monthly Serial, February 1838 - April 1839
• The Old Curiosity Shop, Monthly Serial, Master Humphrey’s Clock, February 1840 - April 1841
• Barnaby Rudge: A Tale of the Riots of ’Eighty, Weekly serial, February - November 1841
• The Life and Adventures of Martin Chuzzlewit, Monthly serial, January 1843 - July 1844
• Dombey and Son, Monthly serial, October 1846 - April 1848
• David Copperfield, Monthly serial, May 1849 - November 1850
• Bleak House, Monthly serial, March 1852 - September 1853
• Hard Times: For These Times, Weekly serial, April - August 1854
• Little Dorrit, Monthly serial, December 1855 - June 1857
• A Tale of Two Cities, Weekly serial, April - November 1859
• Great Expectations, Weekly serial, December 1860 - August 1861
• Our Mutual Friend, Monthly serial, May 1864 - November 1865
• The Mystery of Edwin Drood, Monthly serial, April - September 1870

One reason that Dickens preferred to publish in serial was that he could use cliffhangers to build buzz. For example, there were scenes such as crowds at docks shouting “Is Little Nell dead?” at passing ships from England during the serialization of The Old Curiosity Shop . The release of the last volume of The Old Curiosity Shop in 1841 was comparable to the excitement surrounding the 2007 release of the final Harry Potter instalment, Harry Potter and the Deathly Hallows . (Imagine what could have been, however, if the final Harry Potter instalment had been serialized in the New York Times Magazine, one chapter per issue.)

Dickens didn’t just write serial fiction, he also published it. From March 1850 to May 1859, Dickens was the half-owner and full editor of Household Words , which proudly proclaimed itself to be “Conducted By Charles Dickens”.

Household Words published serials including Dickens’ own Hard Times . Dickens wanted complete control, however, and moved on to create his own serial publication, All the Year Round , which was founded, owned and edited by him.

All the Year Round was published from 1859 to 1895. Among the works it published were Dickens’ own A Tale of Two Cities in 1859 and Great Expectations from 1860 to 1861. All the Year Round also published seminal works by Wilkie Collins , as we’ll see next.

Two of Wilkie Collins’ most important works were published in All the Year Round: The Woman in White from 1859 to 1860 and The Moonstone in 1868. The Woman in White was the first “Sensation Novel”. In the 1860s in Victorian England, there was a craze for serialized, exciting, melodramatic fiction which was critically labeled as “sensation fiction” . This was started by The Woman in White. Wilkie Collins also wrote and published The Moonstone in serial in All The Year Round. The Moonstone was the first—and according to T. S. Eliot , the best—English detective novel .

The notion of “sensation fiction” is extremely hard to understand today, since we live in a time in which fiction is split into literature and the type of fiction people buy at the airport—and in which very few books occupy both camps, and are mistrusted if they do. Literary fiction is hipster fiction. However, as T. S. Eliot wrote in his essay “Wilkie Collins and Dickens” , before the 1860s there was no distinction:

But there are many living who are not too young to remember the melodramatic stage before the cinema replaced it … and who are not too old to have observed with curious interest the replacement of dramatic melodrama by cinematographic melodrama, and the dissociation of the elements of the old three-volume melodramatic novel into the various types of the modern 300-page novel. Those who have lived before such terms as “highbrow fiction,” “thrillers” and “detective fiction” were invented realize that melodrama is perennial and that the craving for it is perennial and must be satisfied. If we cannot get this satisfaction out of what the publishers present as “literature,” then we will read—with less and less pretence of concealment—what we call “thrillers.” But in the golden age of melodramatic fiction there was no such distinction. The best novels were thrilling…

Later, Eliot discusses the distinction between melodrama and drama {i: “melodrama” and “drama”}:

But the frontier of drama and melodrama is vague; the difference is largely a matter of emphasis; perhaps no drama has ever been greatly and permanently successful without a large melodramatic element.

Eliot concludes his essay as follows:

We cannot afford to forget that the first—and not one of the least difficult—requirements of either prose or verse is that it should be interesting.

Wilkie Collins’ writing and life was certainly interesting. He was a close friend of Dickens, and through their friendship Dickens got better at writing plots , while Collins got better at writing characters. Collins also led a tumultuous personal life, living two separate lives with two partners (Caroline Graves and Martha Rudd ). And if this wasn’t enough, he also predicted the idea of Mutually Assured Destruction , in 1870:

“I begin to believe in only one civilising influence—the discovery one of these days of a destructive agent so terrible that War shall mean annihilation and men’s fears will force them to keep the peace.”

But before we veer too off-topic, the dangers of which have been chronicled in xkcd 214 , we return to Wilkie Collins and his experiences with writing and publishing The Moonstone .

Collins published it in serial, and his recounting of what happened shows how publishing in-progress enables authors to complete works they may otherwise have abandoned. While Collins was writing The Moonstone, he was afflicted by a severe case of gout. But having already started writing and publishing instalments of the work, he persisted, not wanting to disappoint his readers. In the “Preface to a New Edition” which followed the completion of The Moonstone, Collins described his experience as follows:

While this work was still in course of periodical publication in England and in the United States, and when not more than one-third of it was completed, the bitterest affliction of my life and the severest illness from which I have ever suffered fell on me together. At the time when my mother lay dying in her little cottage in the country, I was struck prostrate, in London—crippled in every limb by the torture of rheumatic gout. Under the weight of this double calamity, I had my duty to the public still to bear in mind. My good readers in England and in America, whom I had never yet disappointed, were expecting their regular weekly instalments of the new story. I held to the story—for my own sake as well as for theirs. In the intervals of grief, in the occasional remissions of pain, I dictated from my bed that portion of The Moonstone which has since proved most successful in amusing the public—the “Narrative of Miss Clack.” Of the physical sacrifice which the effort cost me I shall say nothing. I only look back now at the blessed relief which my occupation (forced as it was) brought to my mind. The Art which had been always the pride and the pleasure of my life became now more than ever ‘its own exceeding great reward.’ I doubt if I should have lived to write another book, if the responsibility of the weekly publication of this story had not forced me to rally my sinking energies of body and mind—to dry my useless tears, and to conquer my merciless pains.

The novel completed, I awaited its reception by the public with an eagerness of anxiety which I have never felt before or since for the fate of any other writings of mine. If The Moonstone had failed, my mortification would have been bitter indeed. As it was, the welcome accorded to the story in England, in America, and on the Continent of Europe was instantly and universally favourable. Never have I had better reason than this work has given me to feel gratefully to novel-readers of all nations. Everywhere my characters made friends, and my story roused interest. Everywhere the public favour looked over my faults—and repaid me a hundredfold for the hard toil which these pages cost me in the dark time of sickness and grief.

I have only to add that the present edition has had the benefit of my careful revision. All that I can do towards making the book worthy of the reader’s continued approval has now been done.

W.C. May, 1871.

The benefits of writing and publishing in-progress books have never been explained better.

While Wilkie Collins wrote the first Sensation Novel, the star author of the genre was Mary Elizabeth Braddon .

Mary Elizabeth Braddon became famous for writing Lady Audley’s Secret , published in serial from 1861-1862. Lady Audley’s Secret was the most popular Sensation Novel of Victorian England. It’s a fun read, featuring themes of manipulation, murder, bigamy, arson and insanity¹. (Who said Victorian England was boring?)

Lady Audley’s Secret was very much in the style of The Woman in White, according to Braddon herself, years later:

“I always say I owe ‘Lady Audley’s Secret’ to the ‘Woman in White’. Wilkie Collins is assuredly my literary father.”

On the other hand, this could just be the polite modesty of successful people—Henry James claimed that Braddon invented the sensation novel in Lady Audley’s Secret .

Lady Audley’s Secret was Mary Elizabeth Braddon ’s second published novel, and her first real hit. But it almost didn’t happen. She was living with John Maxwell , a publisher with 5 kids and a wife in a lunatic asylum, to use the technical 1860s term. John Maxwell was launching a new magazine entitled Robin Goodfellow . Just before launch, the lead serial failed to be delivered. (If you’re a publisher, I’m sure you’ve never had an author miss a deadline!)

Naturally, Mary Elizabeth Braddon volunteered to John Maxwell that she could write the lead serial.

His reply was as follows:

“But even if you were strong enough to fill the position, there is no time.”

Yes, that was a direct quote. Here’s the rest of the conversation, as described by Mary Elizabeth Braddon:

“How long could you give me?”

“Until tomorrow morning.”

“At what time tomorrow morning?”

“If the first instalment were on my breakfast table tomorrow morning, it would be in time.”

The next morning John Maxwell found the opening chapters of Lady Audley’s Secret on his breakfast table.

So, Lady Audley’s Secret launched the Robin Goodfellow magazine in June 1861. Robin Goodfellow then folded in September 1861, after a few issues. (Back then, even the magazines themselves led melodramatic lives!) This could have killed Lady Audley’s Secret. But it had fans hooked, including a famous actor who wrote and urged her to keep writing. The serialization resumed in The Sixpenny Magazine (whose strapline was ‘QUALITY, QUANTITY AND CHEAPNESS’—who knew Victorian England was awesome?) and the novel was completed. As Braddon described it:

“It was written from hand to mouth, as a serial, wherever I happened to be when the time of publication drew near…”

Lady Audley’s Secret was published extremely early and often. It was a massive success, the Fifty Shades of Grey of the 1860s.

Mary Elizabeth Braddon was extremely prolific, completing 80 novels in her lifetime. In the 1860s, she wrote 2 or 3 novels per year, published in serial, of course. If that’s not enough, from 1861 to 1870 she also managed to produce 6 children (with John Maxwell providing occasional assistance in the matter), edit Belgravia magazine (created by John Maxwell for her) and help raise the 5 children he already had. Some people are more productive than others, but Mary Elizabeth Braddon was on another level.

In the 1800s, serial fiction wasn’t just popular in Victorian England. Around the world, important and popular literature was originally published in serial form. Besides being a worldwide phenomenon, it was the defacto standard for quality: in 1878, a piece in Scribner’s Monthly stated that only the “second and third rate novelist who could not get published in a magazine and is obliged to publish in a volume, and it is in a magazine that the best novelists always appear first.”²

In Russia, Dostoyevsky’s The Brothers Karamazov was published as a serial in The Russian Messenger . So was Tolstoy’s Anna Karenina . Oh yeah, War and Peace —you guessed it, The Russian Messenger. (Well, sort of. An earlier version of parts of it were published as a serial in The Russian Messenger as The Year 1805. It’s a big book.)

In France, Madame Bovary was published in serial in La Revue de Paris (no, not The Russian Messenger).

In the United States, Uncle Tom’s Cabin is a particularly interesting case. It was published in the US as a 40 week serial in National Era , starting in June 1851. Afterward, its author Harriet Beecher Stowe was approached by a publisher to make it a book. However, she didn’t think people would read it in book form.

300,000 copies of Uncle Tom’s Cabin were sold.

In the first year.

(So much for the idea that publishing in serial first is something that can harm a book launch!)

Within a few years, millions of copies of Uncle Tom’s Cabin were sold and pirated, in the US and Britain. It was the bestselling novel of the 1800s, and the number two bestselling book in the US in the 1800s, second only to the Bible. It was also a prominent abolitionist event; one of many contributing factors leading to the US civil war.

The need for recurring fiction is, like melodrama, an essential human need. Book series such as Harry Potter , Twilight , and The Hunger Games have all benefited, as have movie series such as Star Wars . However, while modern attention spans are typically held to be shorter than in days before Twitter and Facebook, the way that most people consume serial fiction is typically in novel-size chunks, unlike in the 1800s. However, this is just the result of historical accident, because the way that people consume print books is affected by how print books are produced.

When freed from the constraints of print books, instalments get naturally shorter. Nowhere is this more obvious than in one of the more interesting recent origins of Lean Publishing : fan fiction . Fan fiction involves authors, typically amateur authors, writing stories set in a universe created by another author, such as Harry Potter or Twilight. To say that fan fiction is popular for writers is a spectacular understatement: the following screenshot of FanFiction.net shows the most popular works, ranked by works of fan fiction:

To be clear: this is not some metric like “page views of fan fiction”: this is the number of unique works of fan fiction set in that universe. Yes, there are hundreds of thousands of works of fan fiction about Harry Potter and Twilight. There are so many works of fan fiction that there are elaborate subgenres, just within Twilight fan fiction (or “Twific”).

Since the fan fiction genre is so massively popular, sexually focused and varied in quality, most people overlook one of the most interesting things about fan fiction:

It is almost entirely written and published in serial.

Most fan fiction is serial fiction, and there’s so much fan fiction written, that fan fiction is the dominant form of serial fiction .

Not only is fan fiction published in serial, it’s typically published in-progress, using a Lean Publishing approach.

Recall the definition of Lean Publishing:

Lean Publishing is the act of publishing an in-progress book using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do.

This pretty much defines fan fiction. Sites such as FanFiction.net and Wattpad are certainly lightweight tools focused on getting reader feedback!

To understand the impact of fan fiction and serial fiction, let’s consider one high-profile example: Fifty Shades of Grey.

Fifty Shades of Grey started on FanFiction.net as Twilight Fan Fiction called Master of the Universe by “Snowqueens Icedragon”, the pen name that author Erika Leonard chose.

Since FanFiction.net is really good for getting reader feedback and a community around your book, it’s obviously the best place to first publish Twilight fan fiction. So, Master of the Universe was published on the fan fiction website FanFiction.net. It was massively popular, garnering over 37,000 reviews and countless more readers: if you use the typical 90/10 ratio of reader to reviewer, you can assume over 300,000 readers.

After gaining a massive fan base, Master of the Universe was then removed from FanFiction.net website for Terms of Service issues regarding the sexual content of the book. So, Erika Leonard moved the work to 50Shades.com . The following screenshot of 50Shades.com in December 2010 from a Galleycat article is fascinating:

Here are some of the features of the website from the screenshot:

• an indication that “Snowqueens Icedragon” is an “Author of Twilight FanFiction”
• images of Edward and Bella from Twilight with the Master of the Universe title
• a spot for a featured YouTube video
• a spot for Twitter updates
• some sort of mailing list or RSS feed (the subscribe link)
• an indication of the most recent update

There was an active reader community, as you can see from the following screenshots of two different installments.

This instalment had 433 comments.

This instalment, posted two weeks later, had 671 comments.

You don’t get feedback and buzz like this with an astroturfed social media campaign once a work is done; you only get it if the work is built using a Lean Publishing approach , with real, authentic interaction between the author (whatever her pseudonym) and her readers.

After building this authentic community of readers and establishing product/market fit and traction, it was time to cash in.

Erika Leonard rewrote Master of the Universe as Fifty Shades of Grey by “E L James” and published it with The Writer’s Coffee Shop, a small press based in Australia. Even more success followed, along with the obligatory bidding war by major publishers.

As an aside, by “rewrote” I mean “rewrote at least 11% of it.” The website Dear Author did a fantastic textual comparison of Master of the Universe and Fifty Shades of Grey to determine how similar they were. They also submitted the works to the student paper plagiarism detector Turnitin and got the following similarity score: 89%. This is interesting because since Master of the Universe is a derivative work of Twilight , and if being derivative is transitive, than Twilight author Stephenie Meyer is being very magnanimous here given the huge financial success of Fifty Shades of Grey. I didn’t start this book expecting to admire Stephenie Meyer, but I do.

Anyway, regardless of how much of Fifty Shades of Grey was essentially unchanged from Master of the Universe, the important fact is less subtle: The Fifty Shades Trilogy occupied #1, #2, #3 and #4 on the Amazon.com bestseller list last year.

From a Lean Publishing perspective, however, the most interesting thing is that not only did Fifty Shades of Grey begin life as fan fiction, but, like most of fan fiction, that it was published in-progress and in serial . The success of Fifty Shades of Grey shows what product/market fit and massive advance buzz from serial fiction can do for you. To be clear:

Serial fiction is not something that is coming soon. It’s here now. And if you expand the definition to include book series such as Harry Potter and Twilight where the size of the instalments is a novel, you’ll realize that it has been dominant for a while. All that is happening now is that the instalments are getting shorter, and reaching their natural size of one sitting.

Erika Leonard is the modern equivalent of Mary Elizabeth Braddon . Both are/were bestelling authors, with millions of readers each. Both women first published their novels in serial and in-progress. Both wrote their novels very quickly, both were hated by critics and both profited handsomely from their efforts.

Let’s look back at the definition of Lean Publishing again to see how close to it Fifty Shades of Grey stayed:

Lean Publishing is the act of publishing an in-progress book using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do.

In-progress? Check. Ebook? Check. Lightweight tools? FanFiction.net is as lightweight a tool as it gets. Check. Many iterations? The screenshots above imply over a hundred iterations, just for part 2. Check. Reader feedback? Check. Pivot? Well, she pivoted as she wrote Master of the Universe, and then pivoted again, changing at least 11% of the book to create Fifty Shades of Grey. Check. Build traction? You saw the screenshot of Amazon.com, right? Check, please!

In considering the origins of Lean Publishing, next we turn our attention from the serious world of Fifty Shades of Grey to the salacious world of computer programming books.

The Technology Adoption Lifecycle is a very famous bell curve describing how new technology spreads. For disruptive innovation , such as a revolutionary new technology product, author Geoffrey Moore has argued in Crossing the Chasm that there is a gap between the early adopters and the early majority. This curve looks like this:

The Technology Adoption Lifecycle has profound consequences for publishing. Currently, ebook readers such as iPad and Kindle have recently crossed the chasm from early adopters into the early majority. PDF has already reached the late majority in terms of distribution of programs that can read and write the format, but the suitability of PDFs for books still has an image problem for everything but technical books.

For the past five years, even before the Kindle and iPad were created, PDF sales have been steadily growing for technical books. Why technical books and not, say, novels?

The key is something I call the Technology Adoption and Information Distribution Lifecycle . The name is a mouthful, but what the concept refers to is the ways that information about a given technology can be distributed as that technology moves through the Technology Adoption Lifecycle.

One of the main drivers of this is that the speed of technological change is increasing, so the length of time that the x axis of the Technology Adoption Lifecycle exists for a given technology is being compressed. Whereas in decades past, a book about a given technology could be relevant for 5 (or 10!) years, now you’re lucky if that’s true for 2 years. Since it takes time for a book to get written, this often means that by the time the book is written, copy edited, typeset, printed, put on trucks and shipped to stores, parts of it are obsolete. It is possible for entire books to become obsolete before they are even finished!

One consequence of this is that there is a pressure to start early, building and shipping print books based on beta versions of software, and hoping that the information will still be correct when the final version is released. Sometimes this works, other times it does not. As I discussed in the introduction to this book, my book Hello! Flex 4 had the latter outcome. Even in circumstances that aren’t as extreme as that, different methods of information distribution apply to different parts of the Technology Adoption Lifecycle. We’ll consider how this applies to various methods of information distribution, including blogs, in-progress ebooks, completed ebooks and print books.

First, we’ll see what this looks like for print books. Since print books take a while to get written, edited, copy-edited, printed, put on trucks and shipped, the curve looks like this:

There are two very interesting consequences here.

First, due to the time required to produce a print book, print books completely miss the innovators and early adopters! These people represent a minority of the total addressable market, but by their nature as enthusiasts they are the most passionate customers. They are the evangelists of a technology, and the exact people that you want to promote your book. Choosing print means you will miss them completely. By the time your book is on a shelf, these customers will already know what you are saying, and won’t be in the market for your book.

Second, since shelf space is worth money, print books currently don’t go all the way to the end of the curve. Over time this will be changed by print-on-demand and Amazon for distribution, but today print books still do go out of print.

Next, completed ebooks. This curve resembles the curve for print books, since it takes time to write, edit, copy-edit and typeset an ebook. The curve starts a bit sooner, however, since the bits in an ebook don’t need to be shipped in trucks and sit on shelves, the way that print books do.

Three notable publishers, The Pragmatic Programmers , Manning and O’Reilly have realized this. So, they have long offered in-progress ebook versions of their books, in order to publish at least some of the content in their books in some format before it becomes obsolete. The Pragmatic Programmers call their program “Beta Books”; O’Reilly calls theirs “Rough Cuts”; Manning calls theirs “MEAPs”, for “Manning Early Access Program.” In all cases the point is the same: publishing in-progress ebooks.

It is no surprise that all three of these publishers sell computer programming books : computer technology changes make books obsolete quickly . So, it was inevitable that three of the best computer book publishers would publish in-progress books : the market demanded it.

Note that as a technology matures and starts to wane, no new books are started about it. This is why the In-Progress Ebooks curve stops before the technology itself dies: for essentially every technology , there is a point when no new books about it are being started.

Taken together, when you combine in-progress ebooks and completed ebooks , they cover the whole Technology Adoption Lifecycle curve :

Finally, blogs. People start blogging about something new and shiny right away . So, blogs reach the innovators (or are written by the innovators) and the early adopters . Once a technology reaches the mainstream, however, it’s less blog-worthy. So blogs also cover the entire area under the curve, even the laggards who are served by obsolete blog archives. Dead technology gets dead blogs.

The big point here is that not only do blogs and ebooks address the whole Technology Adoption Lifecycle , but that only blogs and in-progress ebooks address the passionate innovators and early adopters who will be effective evangelists for a given technology or book.

Before moving on, I want to take a closer look at the in-progress book programs. Publishing in-progress books is one thing; using a lightweight, semi- or fully-automated toolchain is another. Lean Publishing does not refer to the process of making in-progress books by typesetting Word documents: if the process adds enough friction, you can’t iterate fast enough. In this regard, publishers like the Pragmatic Programmers and O’Reilly have constructed their own toolchains for producing books. These toolchains have historically been a bit heavy or obnoxious—any toolchain involving the author writing in DocBook, which is XML, counts as the latter—but they are improving. O’Reilly is probably the most forward-thinking of these publishers. Not only have they added AsciiDoc as an alternative to DocBook, but in February 2011 they announced a program called Realtime Publishing whose values align closely with the Lean Publishing values.

The page which describes O’Reilly’s Realtime Publishing program makes an excellent case for Lean Publishing, so I’m going to quote it at length³ here.

Realtime Publishing

If you’ve been following the publishing industry at all, you’ve no doubt heard the screams of pain. When the tech bubble burst in 2000, book sales went into free fall. And although the rest of the technical industry has recovered and thrived in the past decade, at best publishing has performed only slightly worse than the previous year. The bloodbath has ended, but the wounds are still oozing.

It’s easy to point to reasons, but most of those reasons are at best half-right. It’s easy to look at the shrinking shelf space allocated to computing in the retail chains—but that’s surely an effect, rather than a cause. If readers were buying the books, the bookstores would be selling them.

I actually hadn’t noticed this . But that’s kind of the point: I didn’t go into bookstores to buy print books any more! But it’s true: in 2012, when I visited Bolen Books in Victoria to hear Cory Doctorow speak, I couldn’t even find their computer book section anymore! This section used to be primarily why I went to Bolen, and where I had spent hundreds of dollars as a poor university student just over a decade earlier.

…

Here are the issues that really face publishing, and what O’Reilly is doing to address them—for our good and for our authors’. First, the pace of technical change: if anything it’s gotten faster over the past decade. A 400-page book takes roughly a year to write, particularly for the kind of author O’Reilly usually works with: technical experts who have other jobs. A print book that takes a year to write, and 3 months in production, is bound to be six months out of date by the time it hits the shelves. That’s really not a service for anyone.

Hearing O’Reilly state this, just as I had in “The Technology Adoption Lifecycle and Computer Programming Books” ⁴, was shocking in its candour.

Second, in an open source world, technologies tend to fragment. Developers have a host of alternatives—but no alternatives have enough users to make a book profitable. A few years ago, Ian Darwin counted over 80 Java web frameworks. If this was just a peculiarity of the Java world, we could perhaps laugh. But there are many Python frameworks; many Javascript frameworks (I’ve been told “hundreds”, but I haven’t tried to count); over two dozen NoSQL databases; many new programming languages. Books like Head First Java that cover very general topics are still profitable, but it’s hard to justify publishing on Wicket. Or Sinatra. Or Apache Jackrabbit. Publishers either have to pick winners early on, or they have to sign books on everything and benignly neglect the books on technologies that don’t thrive. Neither strategy is a recipe for publishing success.

The interesting point here is that benign neglect is essentially what we do at Leanpub : we provide the toolchain, and it’s up to the authors to do the writing and marketing. A book which is not a publishing success by traditional publisher’s standards (over 5000 copies) can still be a publishing success by the author’s standards, especially at Leanpub’s royalty rates of 80%: a $20 book earns the author $16.00, so if that book sells 5000 copies this is $80,000 to the author. Many computer programming book authors would be happy with this type of failure, especially since their books earn them consulting leads and let them raise their consulting rates.

That’s the real problem: not Google, not retail, but the rate of technical change and the tendency of technologies—particularly open source technologies—to fragment into hundreds of competing implementations. How do we address these issues, so that we and our authors can prosper in the coming years?

I 100% agree. I couldn’t have said it better myself!

O’Reilly is introducing a new model for publishing. We’re calling it “realtime publishing” . It’s enabled by ebooks, which enable us to answer a question we’ve been asking for a few years: why can’t we publish books the way developers release software?

Yes! Yes! Yes!

First, the demands of a physical book require a certain heft. A print book that’s too small gets lost on bookshelves. With ebooks, size ceases to be an issue. And this has important ramifications. It’s possible to write on smaller, more specific topics: instead of 1200 pages on Javascript, 70 pages on working with Canvas, plus 70 pages on the class system, etc. All of these can be separate publications. By replacing 1200 pages of print with a collection of shorter ebooks, we can drastically reduce the time it takes to bring content to market. Instead of a year or years, we’re talking about a month, a couple of months at the outside.

This seems to be creating a false dichotomy between “really short < 100 pages books which are suitable for Realtime Publishing” and “traditional length books that are not”. O’Reilly should take the next leap and open this up to books of all lengths and topics.

Furthermore, not only are print books out of date as soon as they hit the market, it’s a year or more before they can be updated. There’s retail inventory that has to be sold, or it will be returned and destroyed. It’s not good to tell a retail bookstore manager that the stock he bought two months ago, or even 9 or 12 months ago, is out of date. Ebooks don’t have this problem: they can be updated real-time. Whenever the author fixes a bug, describes a new feature, updates the book for a new release, all she has to do is request a new release.

Yes!

Our production staff pushes the build out to the servers and notifies customers so they can download a new copy. O’Reilly is already doing that with our ebook products. Eventually, books will update themselves, the same way mobile apps do: you’ll open your ebook reader to see a message saying “update 3 books now?” I don’t know when that feature will appear in Kindle, iBooks, and Google Reader, but I believe it will be sooner rather than later. The difference between “early access” and “first edition” is disappearing: ebooks can be, and will be, release-early, release-often products.

Yes!

Realtime publishing also addresses the fragmentation problem. Many factors contribute to the cost of the book: printing is less than most people think, editorial and production much more. There’s also inventory cost, and the risk associated with producing books that don’t sell. Ebooks aren’t necessarily less expensive to publish, but they are certainly less risky. There’s no inventory, and because they can be shorter (books under 200 or so pages “disappear” on bookshelves), they don’t require as big an investment to develop. If producing a 500-page print book costs $40,000, producing a 50-page ebook should cost $4000. That difference directly affects our ability to take risks on new technologies that don’t have large, well-defined audiences. The net result is that we can take publish on many more technologies. We can afford to build a series of short ebooks around technologies that might not otherwise make the cut. That also means that we can start ebooks earlier, without waiting to see whether any given project is a “winner.”

Producing a 50-page ebook costs the author nothing but time when using the Lean Publishing approach on Leanpub . So, the costs O’Reilly describe must essentially be all labor costs. So, this brings up the question of risk: At what point should a publisher like O’Reilly start an ebook project using this approach?

Well, if the project began with almost no expense, it could be “as soon as there was a willing author”. This would imply that as much of the work that makes up the $4000 of cost get shifted to the end of the process, so that it can only be spent on books that look like they will earn it back. But then if this was done, it would imply that some authors will be essentially kicked out: they’d go into a project expecting a fancy production process at the end and not get it. So to use this kind of approach requires a phased approach where something starts out essentially self-published and then the publisher has an option to pick it up and polish it if it shows traction.

There’s a really simple way to put this, in kind of a Zen koan style:

Q. How does a publisher succeed in 2013? A. Don’t publish failed books.

The full publishing process could act as a force-multiplier on successful books that are first published by their authors with either little or no help from their publisher.

Why do we believe in this strategy? There’s no shortage of pundits who will tell you that 2011 is the year of the ebook. But we don’t have to look at pundits. We can look at our own sales: in the past year, O’Reilly has come to expect at least 35% of the dollar sales on new titles to come from ebooks (including Safari), and we expect that percentage to grow. That growth is driven by the need to get information now: you can click and have the book on your device in seconds, rather than waiting for Amazon to ship it, or for you to take a trip to the local bookstore. And ebooks are available as soon as the book finishes our production process—several weeks before they’ve been printed and percolated out from the printer to the warehouse to the bookstore. So the need for information, for ideas, is already driving the increase in ebook sales, even before we’ve implemented realtime publishing.

…

Authors need to work in DocBook or AsciiDoc . These formats integrate smoothly into our toolchain, and let us pump out new releases without extended production processes.

…

So close! AsciiDoc isn’t as good as Markdown in my opinion, but it’s a hell of a lot better than DocBook .

…

We’re increasing author royalties to 25% for all ebook products in this real-time program. That holds both for books that are initially planned as ebooks, and ebooks that are extracts from other books. For customers who want print, books will be available through print-on-demand; a 10% royalty applies to POD sales. There will be no advances.

This is less than 1/3 of what Leanpub pays for a $10 or $20 book—our 85% royalty rate means a $10 Leanpub book earns $8.50 and a $20 Leanpub book earns $17.00—but it’s more than double the 10% that most publishers pay. So it’s a huge step in the right direction.

We expect authors to stick with their ebooks post-publication, as they would with any other project: we want the books kept up-to-date. Releasing an update will be as simple (for you and for us) as committing changes to an O’Reilly SVN archive . We realize that authors don’t want to be wedded to their books for the rest of their careers, but we would like authors to be responsible about finding someone to carry on the work when they move on.

This is, in my opinion, completely unreasonable and totally counterproductive. Books have to have a “done” point, otherwise authors will go insane. And authors shouldn’t feel the need to “appoint a maintainer” the way open source project leaders do. Only a very, very small minority of books are constantly-updated “living” books. In most cases, a book gets to a done point and then stops. Then, after the book becomes obsolete, the author considers writing a new edition about the new version of whatever he or she is writing about.

If the author had to appoint a maintainer, then when the book became obsolete, he or she would be competing against the maintainer: the author with a new edition, and the maintainer who was keeping the original book current for longer than expected.

…

This is just the beginning of the ebook story . We will see many innovations in the coming year—some from us, and certainly some from other publishers. These are exciting times: we’re re-inventing publishing in terms that are meaningful for the computing industry.

…

Yes! At Leanpub we’re happy to be part of this process.

Lean Publishing also draws heavily on lessons from blogs . We’ve discussed blogs in the section on the Technology Adoption Lifecycle , and we’ve discussed serial fiction at length. In a sense, blogs are just serial non-fiction. Now, blogs typically don’t make much money for their authors. However, if the blog leads to lucrative books, then this low monetization is just deferred monetization.

It’s important to recognize that the writing (I hate the word “content”) in a good blog is often easily turned into a good book. Examples of books based on repurposed blog posts include 37signals’ Getting Real and Rework , Paul Graham’s Hackers and Painters , Eric Ries’ Startup Lessons Learned and The Lean Startup and Joel Spolsky’s many books . This is a fantastic thing. These successful blogs have built authentic communities around the author, and the community is happy to support the books that result from the blog. This often leads to very good and very successful books.

Let’s look more closely at two examples now.

37signals is a Chicago-based software company that, in their words, makes “frustration-free web-based apps for collaboration, sharing information and making decisions.” Their most famous products are Basecamp (a project management tool) and Highrise (a contact manager) . Besides these innovative products, they are also known for their extremely popular Signal vs. Noise blog and for employing David Heinemeier Hansson , creator of the Ruby on Rails web application framework . (Ruby on Rails was extracted from Basecamp.)

Besides these accomplishments, Jason Fried and David Heinemeier Hansson of 37signals are also bestselling authors . They wrote a book called Getting Real about the software development process they use to create web applications. The most innovative thing about Getting Real, however, was the following: it was essentially an edited version of what 37signals had been saying on Signal vs. Noise for years. Yet, with a little curation and editing, they managed to sell over 20,000 PDFs directly from their website—which, at $19 each, represented over $380,000 in profit—in the process. And good for them: Getting Real was worth the $19, even to people like myself who were already regular readers of Signal vs. Noise. It was especially worth it, however, to people who had not followed the blog and wanted a heavily curated and edited version of it, to catch up to 37signals’ way of thinking.

In 37signals’ terms, what they were doing was to “sell your waste products.” They framed their innovative ideas as the waste products of creating innovative software, like sawdust is a waste product at a lumber mill.

Now, what’s better than making one bestselling book out of your blog? Making two, of course! The second book was Rework , a New York Times bestseller which sold over 300,000 copies. Essentially, Rework takes the Getting Real ideas about how to develop web applications and applies them to business in general.

What’s better than getting two bestselling books out of your blog? Three, of course! They’re working on a new book, called Remote , about telecommuting . (This is why there have been posts about telecommuting on Signal vs. Noise recently, of course. Where better to get product/market fit, beta test ideas and build advance buzz than on an extremely popular blog?) With the recent debate about telecommuting at Yahoo! , their timing is pretty good. So chances are they’ll have a third bestselling book in a year from now.

Next, we consider Eric Ries . He created the notion of The Lean Startup , based on his experiences and the Customer Development teaching of Steve Blank .

But the process that Eric has followed in developing his Lean Startup ideas in writing is interesting, as it is, unsurprisingly, very much a Lean Publishing process.

First, Eric developed his voice by blogging. One of his earliest posts, from September 18, 2008 was entitled “Lo, my 5 subscribers, who are you?”. In this post, which is essential reading, he explains the benefit of being small, in that you can get to know your early customers better than you can when you have thousands of them. So, he conducted an email survey, and got feedback from these early readers, who he considered his early customers or “earlyvangelists”.

In that post, written when he only had 5 subscribers, Eric wrote:

And since I have a blog, I have a way to ask questions directly to you. If you have a minute, post your answers in a comment, or email me. Here’s what I want to know:

1. First of all, the NPS question: On a scale of 1-10 (where 10 is most likely), how likely is it that you you would recommend this blog to a friend or colleague?
2. How did you hear about it?
3. What led you to become a subscriber, versus just reading an article and leaving like everybody else? (or, if you’re not a subscriber, what would it take to convince you?)
4. What do you hope to see here in the future?

Thanks, you loyal few. I am grateful for your time and feedback.

He used the lessons he learned well, as shown in the subscriber count on his two subsequent surveys: on January 24, 2010, his survey was entitled “Lo, my 18891 subscribers, who are you?”; on September 6, 2010, his survey was entitled “Lo, my 57692 subscribers, who are you?”. Yes, those post titles read like a victory lap, but like most victory laps, they are well deserved.

The natural evolution of the ideas in Eric’s blog was, of course, a book. Eric’s blog became Startup Lessons Learned, which was the very first Leanpub book .

Now, unlike Getting Real , this was not a curated and edited book. Instead, it was a verbatim export of Eric’s blog, automatically generated and organized by month chapters. It’s currently about a thousand pages, and it’s actually a decent read, even though it’s just a verbatim export.

However, if Eric had put the level of effort into it that Jason Fried and David Heinemeier Hansson had, he would have been many orders of magnitude more successful than he was. Now, this experience helped us launch Leanpub, so I am eternally grateful to Eric. But to this day I’m convinced that Eric cost himself hundreds of thousands of dollars in direct revenue by not just doing the extra bit of curation needed to make Startup Lessons Learned more of a real thing.

Eric did do this work, however. That work produced his second book, The Lean Startup, which I consider to really be his first real book. The Lean Startup was created with a traditional publisher, not that it actually matters that much—it would have been massively successful regardless of who published it. It became a New York Times bestseller , much like Rework did for Jason Fried and David Heinemeier Hansson after their Getting Real blog book.

Now, obviously, not every print book that is written after a blog and a blog book will become a New York Times bestselling print book. But the Lean Publishing process did help, as it ensured that the ideas would have product-market fit. For Eric, this process was his blogging; Startup Lessons Learned, the book version, was just an interesting experiment along the way.

The main point is that Eric Ries developed his ideas by blogging, and then by publishing a book version of his blog before producing a traditionally-published book with a publisher. Eric’s bestselling book had already benefitted two years of feedback from an engaged community of blog readers. He had created a community around his book that was so engaged that it even had its own conference, the Startup Lessons Learned conference, before the book was written. Eric is every publisher’s dream; of course his first “real book” would be a bestseller! (The Lean Startup was timed to go along with the second annual Startup Lessons Learned conference . We were at the first one, selling printed copies of Startup Lessons Learned.)

From looking at the historical precedents and immediate precursors to Lean Publishing, I now turn my attention inward, to the event which began my journey to Lean Publishing. It began almost accidentally, in 2006, as a side effect of the way I began writing Flexible Rails.

I’m now sitting here 7 years later, digging through the digital pieces, and realizing that I almost had Lean Publishing figured out back then—but that I missed the point for a few reasons.

1. Much of the core Lean Publishing approach was so obvious to me that I didn’t ever recognize it as an idea. It was just the right way to do things.
2. I was so distracted by the specific idea I was working on (Flexible Rails) that I didn’t question whether the approach could be systematized (in Lean Publishing) and productized (in Leanpub ). In fact, even when I had flickers of that idea I shied away from thinking it through for some reason. It could be that I had what Paul Graham has called “schlep blindness” —the act of productizing Lean Publishing into Leanpub has definitely been a schlep.
3. I had not yet suffered enough. To recognize the profound importance of lightweight tools and processes you need to suffer through heavyweight tools and processes. Since I’m a stubborn masochist, this took me two books worth of suffering to fully grasp.

I alluded to all this in the introduction to this book, of course. I’m now going to tell the story of Flexible Rails, as it relates to the evolution of the Lean Publishing ideas. First, however, I need to give a bit of background about Flexible Rails itself, so that you have a clue what I’m talking about.

Flexible Rails was a book about how to combine two technologies, Adobe Flex and Ruby on Rails , to build dynamic web applications called “Rich Internet Applications” . Like many things, it seemed like a good idea at the time (2006-2007).

In this section, I’m going to analyze what I wrote in 2006 in the “Acknowledgments for the Alpha Version” section in the first release⁵ of Flexible Rails, to get a sense of what I was thinking about both the technology combination and the path I had chosen for the book:

On January 31, 2006, after over a year and a half of working with Flex and over six months of playing with Rails (building toy apps, reading Agile Web Development with Rails, etc) I finally realized that for many applications Rails was the perfect server-side technology to complement Flex—and on the flip- side, that Flex offered capabilities that were either difficult, impossible, buggy or merely annoying to do on with JavaScript / AJAX / DHTML on the client side. (Especially if, like me, you’re not a JavaScript guru like Thomas Fuchs .) Furthermore, while RJS templates are very promising, at the end of the day you are still dealing with the joy of HTML, JavaScript , CSS and browser compatibility issues.

Now, back in 2006, what did I do when I had a really good idea? Procrastinate, usually:

So, I did what I always do whenever I have a Really Great Idea: I registered a domain name. I wanted a name which would be good name for promoting a possible book5 about using Flex and Rails together, so the natural choice was flexiblerails.com . I also got flexiblerails.net and .org since I was so sure of how good an idea this was.

I then did what I also typically do whenever I have a Really Great Idea:

Nothing.

Between the demands of my job and my two-year-old son, I was too busy, too tired, etc. Besides, I had a lot of Really Great Ideas (and domain names to go with them!), and I wasn’t acting on any of them— what made this one worth doing? So, time passed.

Wow, I sound a lot like Hugo Lindgren did! For a software developer, I think that domain names and half-baked prototypes are the equivalent of a shoebox of unfinished manuscripts. When I try explaining what I do to people like my son or my father, I think I finally know how to do it.

I then carried on, explaining how I finally got going, and the process that led me to ship the first version:

So, here we are. I hope that this book is useful to you. I’m releasing it in early alpha form , with many revisions to come in the evenings and weekends over the months ahead.

When I launched Flexible Rails , I described it as an “Alpha Book”. Here’s what I meant:

Almost everything in “Web 2.0” (which seems to have been reduced to meaning “2006”) is being released in “Beta”. In fact, the Pragmatic Programmers originated and popularized the concept of a Beta Book . (Unlike most betas, their Beta Books are actually very useful.) The concept of a Beta Book is that of a book which is mostly complete, but contains of errors, typos etc. A reader who purchases a Beta Book gets regular upgrades until the final version. However, future editions must be purchased again.

This book is being released as an Alpha book. Why Alpha? Well, not only is it going to be full of errors, typos, etc, but it is also rather incomplete. (My guess is that it’s about 20% to 40% complete.)

I explained my rationale for launching early as follows:

I am releasing it at a slightly earlier stage than the typical Beta Book for the following reasons:

• The code in it is at the point where it would be useful for someone who is getting started on a project like this (even if it saves them only an hour, the book is worth it).
• Since I have no technical or copy editor, the earlier I get feedback from the community the better focused the book can be. For example: Are code examples in a table with the explanation beside them readable, or should I just list all the code with a number in an explanation column (and then provide numbered explanations at the end)?

It turns out the answer to this question about the code formatting was an emphatic “NO”. Based on feedback, I completely reformatted the over-200 page book. (Had I released the book earlier, I would have saved many hours of time!)

Are the long code examples understandable, or are they too long?

The answer to this was that they were understandable, and probably the best feature of Flexible Rails. I believed that readers should be able to fully follow along based solely on the material in the book, and build a non-trivial code example. In this regard, Flexible Rails helped set a bit of a trend, as most code books beforehand had much shorter code examples, and the “build a non-trivial thing as part of reading the book” approach became popular after it. I really don’t know how much of an impact Flexible Rails had in this regard; I do know that I belabored the point about the superiority of long form code samples at length to Manning, like I belabor most points to everyone about everything.

I also had questions about the shorter code samples :

Are the short “add three lines of code here” examples easy to follow, or do readers have problems figuring out where to put the code? These are the types of questions which will be better answered if I release the book as early as possible.

Here was how I described my audience for the book:

• This book has three potential audiences that I am aware of: (1) Flex developers who are possibly interested in Rails, (2) Rails developers who are possibly interested in Flex, and (3) developers without significant Rails or Flex experience who are considering doing a project in either or both. I have no idea right now about the distribution of what my actual audience will be—i.e. which type of developer the topic of this book will appeal to the most. (For example, it could be that most Rails developers hate the idea of Flex—or of using a Windows PC for a few months until Flex Builder is released for Mac—so fully that this book is only interesting to Flex developers choosing a server-side technology to integrate with.)

Releasing the book early let me test these assumptions and see what type of developer was really reading the book.

Finally, I had realized I wanted to build a community:

• I want this book to be the starting point for a lively discussion at the http://www.flexiblerails.com blog. Getting a first draft released which gives a hint about the possibilities in the combination of the technologies is essential for this.

This idea of getting early feedback and building community is a core part of the Lean Publishing ideas.

However, you need to do more than just publish early to build community . You also need to publish often, and put effort into the community itself. Doing this can have good results, while the book is in-progress and for the book launch itself.

I released 25 self-published versions of Flexible Rails in the period from September 9, 2006 to September 16, 2007.

To give you a sense of the process, these were the releases by release date, page count (8.5x11 pages), reader count and total revenue before the next release.

By the end of this process in September 2007, Flexible Rails the #73 all-time book on Lulu by revenue, as an unfinished PDF.

Releasing really early lets you gauge demand: when I released Flexible Rails , I considered the very real possibility that only 5 people in the world would care. If this happened, I could have just sent them their money back (or even double their money back), and I wouldn’t have wasted the time writing a book nobody wanted. But in the first 6 days I had 30 readers, and I knew that I was committed. At that point, I had no choice but to finish writing the book. This is essential, since the whole process took about 1000 hours. Without public commitment, it would have been easy to stop.

Throughout the process of writing and self-publishing Flexible Rails , the total number of readers remained fairly small: under 1000. However, I still earned more than many authors did at the time from technical books—before the book was even done.

Furthermore, the buzz I had built ensured that when it went over to Manning it did well for me:

• In Q4 2007 , the last 3 months that Flexible Rails was in-progress, I earned $3,528 in ebook royalties alone
• In Q4 2008 , the quarter that Flexible Rails launched, I earned $9,976 in ebook royalties and $18,173.59 in total royalties

The exact details of those two quarters are shown in my royalty statements below:

Publishing in-progress helps build buzz for finished book launches, a fact that is overlooked even today. And yes: Launches matter.

All told, Flexible Rails earned me about $50,000. Also, it was translated into German and Japanese, which was personally gratifying. More importantly, it also helped me launch my consulting company, Ruboss , about 5 years ago and gave us enough credibility to attract our first customers. Furthermore, Ruboss went on to build Leanpub as a result of these experiences. So, while the royalties were nice, more importantly, writing Flexible Rails changed my life.

In short, with Flexible Rails , I published early, published often, listened to my readers, built a strong community around the book and had a successful book launch of the finished book.

Before moving on, I want to look more closely at the community dynamics around the book, as this went even better than planned.

One of the most interesting things about Flexible Rails was the process of writing with an active community. This is interesting since it shows how social the writing of a computer programming book can be—and I’m normally not a social person in small groups.

Right at the beginning with Flexible Rails I created a Google Group for it.

Why?

There were two main reasons:

1. I wanted there to be a place for people to discuss the book, with me and with each other.
2. I needed a way to distribute updates, and uploading files to a Google Group seemed like a nice low-effort approach.

The second reason was actually because of limitations of Lulu . I was self-publishing Flexible Rails on Lulu as a PDF. Lulu is a fantastic website for selling completed print books. However, the process of selling an in-progress book on Lulu was cumbersome.

For example, Lulu did not tell you who bought your book, or provide any way for you to contact them. So, how do you give them free updates to your book?

The way that I solved this was as follows: Lulu allows you to include a “thank you note” with a purchase, which is included in the confirmation email which is sent to the reader when they purchase the book. This thank you note was something that had to be the same for all books you had published. Luckily for me, that number was 1, so I could use the thank you note as a way of providing instructions to people who had purchased Flexible Rails .

So, that’s what I did. In the thank you note, I provided instructions for how to download the book from a secret URL (http://www.flexiblerails.com/Rumpelstiltskin/SecurityThroughObscurity.html, which I still consider to be one of my best jokes), and also from the Google Group .

I actually had two Google Groups , one for announcements and discussion and another for announcements only. That may have been overkill. I posted every release of Flexible Rails to the “files” sections of both Google Groups, and then sent an email to both groups.

Here’s what I said about this process in my thank you note:

Yes, this is terribly inefficient. However, I’m actually going to argue that this is a feature, not a bug:

The way Lulu is set up, ALL of your order information is kept private from me. This ensures that your privacy is protected. However, it does mean that it is impossible for me to automatically add your email address to the Google group when you purchase the book—I do not have access to it! With privacy comes inconvenience, I guess.

Ironically, with Leanpub , we’ve had to weigh similar issues as we’ve built our feature set.

The process I set up clearly wasn’t easy! I needed secret URLs , two Google Groups and a lot of email! However, even though it took a lot of effort, it worked.

The first message I sent to the Flexible Rails Google Group was the following:

Aug 18, 2006: Test message to Google Group.

I sent this message a few weeks before first publishing the book (on September 9), but even this content-free message got a reply after the book was released and a few people were on the list:

ignore this reply to your test message - i, too, am testing that i can test messages to the group.

planning to read the alpha over the w/end so hopefully will be able to add something constructive next week.

btw peter i’ve read a few chapters and i like your dry sense of humour - are you by chance a fellow brit?

For me, this reader encouragement was really helpful. Somebody from Britain was reading my book, and they liked it!

Besides encouragement, I got lots of meaningful information about how to improve the book. This was both in terms of spontaneous feedback and in responses to questions I asked.

For example, when I launched the book I was using a 2-column code + explanation format that looked like this:

This seemed like a good idea when I started, but as the book writing progressed it got tedious and I started to question the format. Some readers had criticized it, and it was annoying to deal with while writing, since it meant my explanations needed to roughly match the length of the code.

So I sent an email to the Google Group with the subject of “POLL: code example format change”.

Hi all,

The code samples in the 2-column Code + Example format have been the subject of some well-deserved criticism: they are frustrating to copy and paste out of, and are also fairly ugly and hard to read.

So, before I do a bunch of reformatting, I want to get a sense of how people feel so far…

Poll:

Should the code samples in the 2-column table Code + Explanation format be:

a) left alone

b) one column of code only, with numbers placed in code comments which refer to explanations after the code sample

c) two columns, the first column code (but a lot wider) and the second column an extremely narrow column which contains just numbers which refer to explanations after the code sample

For b and c, the explanations after the code sample would be a numbered list.

I’m a bit on the fence between (b) and (c). The (b) choice gives you an explicit pointer from the code (when you’re looking at it in Flex Builder or TextMate) to the explanation in the book (which might be helpful), but it might just be a bunch of clutter. However, even if it is clutter, it would be easier to copy and paste out of than choice (c). Note that both (b) and (c) would definitely make the code more readable, however due to the length of some of the code examples there would be definitely some flipping back and forth between code and explanation. Is this a good tradeoff?

If you have an opinion about this, please reply either to the list or to me at peterarmstrong@gmail.com.

Thanks!

Peter

I got lots of meaningful feedback about this, from people living all over the world. Someone in The Netherlands (!) liked option (b). But this was my favorite response:

Hi Peter, et. al.,

I think this is a pretty important subject - I thought I was the only one that disliked the current format!

I’m happy to go with option 2. I’ve tried to visualise it here:

http://www.ipauland.com/layout2.jpg

I did flirt with boxed inline explanations

http://www.ipauland.com/layout.jpg, but now favour option 2.

It’s a great book and importantly for you, it’s currently the only book, so you have a good opportunity here. One of the really interesting things about the book is that you show us what goes wrong and why, when people do the ‘obvious’ thing. I like that, but it may age this book very quickly if the RoR software changes that behaviour.

Paul

To emphasize what happened here: a reader of my in-progress book cared enough about it to create mockups of what it could look like with a better layout.

Here was one of Paul’s mockups:

I liked it so much I basically went something similar in the next version.

Incorporating reader feedback meant that I could get even better reader feedback. For example, at one point I was trying to figure out a few things:

• How experienced with Flex and Rails was the typical reader?
• How familiar with REST (a software architecture approach) was the typical reader?
• What version of Rails should I use? (Writing about Rails was writing about a rapidly moving target.)

So, since I had a Google Group full of readers, guess what I could do?

Ask them!

(I sound like Eric Ries here. Hooray for me!)

I sent out an email with the following poll in it, which consisted of 9 multiple choice questions:

1. Do you already have or plan to buy the second edition of Agile Web Development with Rails ?

• [] yes
• [] maybe
• [] no

2. Before this book, what was your Flex experience?

• [] none
• [] beginner
• [] intermediate
• [] expert

3. Before this book, what was your Rails experience?

• [] none
• [] beginner (read some tutorials online)
• [] intermediate (read AWDwR and built at least one complete Rails app)
• [] expert

4. Have you already read the first edition of AWDwR?

• [] yes
• [] no

5. What is your knowledge of REST?

• [] none
• [] only what I read in AWDwR 2nd ed.
• [] I’ve read about it in AWDwR 2nd ed. and in online tutorials and used it in a Rails app already

6. Do you have any interest in seeing RESTful Rails controllers talking to Flex?

• [] yes
• [] no
• [] what the heck are you talking about?

7. When Rails 1.2 comes out, when will you upgrade to it?

• [] not for 6 months or so until it’s well-tested
• [] within a week
• [] I’m already using it to follow along with AWDwR 2nd. ed.
• [] I’ve been on Edge Rails for over a year and only read this book for the Flex stuff

8. Regarding basic Rails stuff (e.g. has_many, belongs_to) that does not get affected in any way by using Flex with Rails, do you want me to…

• [] assume you already know it
• [] give a 1-2 sentence summary and refer to AWDwR
• [] explain it briefly
• [] explain it as though you will never buy another Rails book

9. Do you use

• [] Flex Builder 2 with Windows
• [] Flex Builder 2 Beta with Mac
• [] Flex Framework SDK with Windows
• [] Flex Framework SDK with Mac

Once again, I got invaluable reader feedback, with many readers filling in the poll answers and emailing me or the Google Group. This changed the entire direction of the book, and ensured that the book would be relevant for about a year longer than it would have been.

More importantly from the perspective of Lean Publishing , it showed me how engaged a community of readers can be. If you make the effort to reach out to your readers and include them in your creative process (especially for a technical book!), the benefit you get is astounding.

As I wrote Flexible Rails in public, I was approached by a few publishers, who I turned down. (I had made a few promises, such as discounts on the print book, which the publishers could not easily keep. Also, I was making a great royalty percentage, and decent money as-is.) I then wrote an email to the Google Group explaining my reasoning about turning down a book deal. The subject was “Flexible Rails is staying independent: BaaS”. And in the email, I started realizing that the process which had been created was something new.

…

One thing that a couple of readers have said to me is that they saw this book as more of a service and community than “just a book”. I agree: this is something that just kind of evolved accidentally over the last 10 (!) months, but which I’m really happy about. I have felt that this book is as much a group conversation as anything else, and there is no reason to change that now.

So, I am starting to see Flexible Rails as an example of a new model in publishing: BaaS (Books as a Service). [I couldn’t help parodying SaaS .] Since PDF books, like software, have essentially zero variable cost, they should also have a proper upgrade process—just like software. (This is especially true with a topic which is as fast-moving as the Flex + Rails combination.)

In my opinion, this is the next step in the evolution of the “Beta Book” process pioneered by the Pragmatic Programmers . I am not saying that it is right for every book—a book like Getting Real probably wouldn’t have benefited from it as much. However, I think that the BaaS model is the right model for this book and potentially for many others. The excellent royalty rates and control to the author that Lulu offers enables a lot more creativity in this regard.

Anyway, that’s enough navel-gazing for now—back to working on the WebORB iteration :)

…

Then a funny thing happened: people pushed back, arguing that when my book was done, that I should take a book deal since it would grow the community, and that I deserved it. I ended up doing so, with Manning . Not wanting a deal gave me the negotiating power to get a really good one. Plus, Manning enabled me to keep my promises, and the people I interacted with at Manning were first-class. Finally, the book that resulted was much better for their efforts. But, compared to my subsequent two attempts at Manning books , the book that resulted was also better because I started the traditional publishing process later, after I had product/market fit and traction .