There's no progress to report on the short story collection this month, beyond a key lesson about being the writer and publisher of a book—when "the writer" goes on a book tour, "the publisher" doesn't get to do production work.
As I noted in last month's column, early time-line slips in the production process for With a Little Help pushed me into the time that I'd earmarked for a tour for my "real" publishers (Tor Teens and Harper U.K.) supporting my most recent novel, For the Win. Of course, that lesson is just the kind of thing I set out to learn when I started this project: which parts of the process can be handled by moderately business-savvy, productive writers, and which parts need publishers, packagers, managers, and other helpers for.
The broader premise of my experiment, of course, is that the Internet changes things. Specifically, the Internet makes it cheaper to coordinate complex tasks than ever before. This is the revolutionary thing about information technology: it can automate coordination, enabling things that used to be expensive and complex to be cheap and simple. The other thing technology makes cheap is experimentation. That's the special genius of IT-based projects: you can fail cheap.
Look at it this way: starting a magazine is hard. It costs money. Magazine founders mortgage their houses, convince their friends to quit their jobs and move across the country, print letterhead, fell trees, pulp them, and cover them with toxic, heavy metal–based inks. It's the kind of thing you want to be really sure about before you take it on. If 75% of the people who attempted to start a magazine abandoned the venture in a few weeks, it would represent a tremendous waste of time and money.
By contrast, most people who start blogger or Twitter accounts may very well abandon them. But starting up a blogger or Twitter account takes about five minutes. And they cost nothing. It's the kind of thing you can experiment with in your spare evenings, after the kids are in bed, and the kind you can fail at without losing anything.
Too Cheap to Fail
It's a good thing that IT makes failure so cheap, because IT also creates a range of possible futures so large that it's almost impossible to guess right about which direction to try first. Successful IT innovation is almost never a matter of accurately predicting the future and then building the business that future demands. Successful IT innovation looks more like this:
Once upon a time, two nice folks started a company that made Game Neverending, a whimsical, multiplayer Flash game. They got a bunch of interesting people on their advisory board and on their alpha and beta-test teams. A small squad of dedicated, in-house programmers avidly watched what their players did, around the clock, and they changed the game often, sometimes as often as every 30 minutes, adding, removing, or tweaking features, and watching the players' reactions.
One wildly popular feature right off the bat was an image-sharing system that let players show their friends pictures they took or found. Here's my claim to fame: I asked for this feature, because the woman I was dating lived in London, and I lived 9,000 miles away in San Francisco, and it was too cumbersome to share pictures from our days by email.
As the Game Neverending team kept tweaking that image-sharing feature, the players went nuts with it, creating a feedback loop that eventually led to the image-sharing feature taking over the game entirely. Game Neverending ended. But the product lived on, and it was renamed Flickr. (And, by the way, I'm now married to the woman, we have a daughter, and we live in London.)
Writers know how this process works, too. You start with an idea for a book. You roll it around in your mind. You "beta-test" it on your friends, pitch it to your editor and agent. And every time you describe it, it changes a little based on what you learned the last time you talked about it. It costs nothing to change the way you describe your nonexistent book. And, iteration by iteration, your kernel of an idea germinates into something that you'd never have predicted when you sat first sat down to write.
On the other hand, no sane writer would dream of recasting her book as a completely different project after it's been turned in, gone off for copyediting, and been put into production. That's when experimentation goes from cheap to expensive. That's when you start learning the hard way.
This marks a key difference between New York publishing and Silicon Valley. Unlike New York publishing, Silicon Valley's products remain experimental long after they reach the marketplace. Google can change its search layout in seconds flat, try it out on a million searchers, crunch the data, revise the experiment and do it again, a hundred times a day if they wish. And bad ideas can be just as interesting as good ideas, because when it doesn't cost anything to find out how bad an idea is, you can afford to be pleasantly and enormously surprised when it turns out that, say, people really do want to play Pac-Man on their search-results page.
I consider With a Little Help to be a Silicon Valley experiment. My upfront costs are minimal. I've spent $2256 getting into production, and taken in about $14,400 in payments. I'll probably spend another $200-$300 before I ship, and that's the last money I should have to spend without taking in money first: every time someone buys an on-demand book from Lulu, I'll get paid without expending any capital. I'm printing and binding my short-run hardcovers in lots of 20, after being paid for them. The audiobook CDs are also produced on-demand by a third party, which means no capital costs for me, either. Setting up the donation page took a few hours fiddling with PayPal, and even if I never take in a penny in donations, I'm not out a penny either.
The "Standard" Response
This is what Silicon Valley can teach New York: make experiments cheap. Don't hire a pricy, outsourced IT company to design a new, exciting book-service for your company. Why not hire your own developers and a visionary tech person and try something. Wait until it fails, learn from that failure, and try something else. Your outsource IT company will hate you if you call them every 30 minutes asking to try a new feature, or to tweak or remove an existing one. But your in-house people will love the challenge and freedom of being allowed to fail fast, iterate, and learn.
Here's what Silicon Valley can't teach New York publishers: how to prevent copying. Last month at BEA, publishing CEOs all but begged Silicon Valley to present them with a universal, interoperable DRM system that would prevent copying without locking books to one vendor's platform. "Our fondest wish is that all the devices become agnostic so that there aren't proprietary formats and you can read wherever you want to read," Penguin's David Shanks reportedly said.
If you ask a few big tech companies to "standardize" a format for your e-books that others can only implement with their permission, they'll happily start planning how to spend the money they're about to make off you. But DRM is incompatible with the idea of standardization—that's why Silicon Valley loves it. Because lurking in the heart of every entrepreneur is a monopolist hoping to shut out the competition.
On the other hand, formats don't matter when there's no DRM in the mix. Take for example the Publishers Weekly homepage. As of this moment, it contains embedded objects in six different formats, ranging from JPEG to HTML. As a reader, I don't have to know, or care, whether the PW logo is a GIF, a PNG or a BMP because there are practically no restrictions on renderers for any of these formats. Any programmer who wants to make a browser can go to a consortium's Web site, grab some reference code for displaying its format, and massage it into her software. She can tweak the code, refactor it completely, or just pay attention to the parts that she cares about.
That's how standards work. Just like standard-gauge rails opened the continent to trains because they never specified whose engines could run on them, or what kind of freight they could pull, universal standards for e-books developed by publishers could do the same for the reading landscape of e-book readers, tablets, and e-books.
Universal standards from real standardization bodies like ISO (International Organization for Standardization), the W3C (World Wide Web Consortium), the IETF (The Internet Engineering Task Force), or the IDPF (International Digital Publishing Forum) would still attract all the tech giants, but they would also attract everyone else, from zippy, ADD-addled startups to copyright holders and activists—everyone with a stake in the outcome. These organizations will make you a standard, like epub, for example. It might not be adopted the first time around. But that's OK. Because you'll make another, and then another. And without DRM, readers who bought your books in the first formats wouldn't have to worry if a standard dies and is replaced by another.
There is a lesson for publishers in how giants like Silicon Graphics, Altavista, and Commodore were beaten into the dirt by snot-nosed startups that used the low cost of experimentation to outcompete them. Publishers should take a page from those upstarts' playbooks. The cool thing about Silicon Valley's brand of experimentation is that failure is often just slow success. And as every good entrepreneur knows, the best way to double your success rate is to triple your failure rate.
