Open Source Writing: Part I: A Few Problems with Publishing...

If you are just tuning in, Common Java Cookbook is an experiment in transparent, open writing. I'm trying to develop this book and make frequent releases every one to three days. The idea behind this book is that open source writing should be no different than open source software. This is the first post in series that explores some of the reasons why I've decided to commit myself to open, transparent writing. This post focuses on the problem. What is wrong with the current approach to computer "books"? What is wrong with the current relationship between the author and the publisher? This post focused on some of the problems with the current approach to books about computer programming.

Problem: Driven by the Physical Artifact

While most writing projects are governed by the limitations of the book as a physical artifact, books like Maven: The Definitive Guide and Common Java Cookbook choose to fully embrace the idea that a book is an electronic documentation unaffected by the constraints introduced by the printing process. Most programming books you encounter today have to have a practical deadline after which no changes are introduced. In other words, if you are writing a book that needs to be printed in lots of five thousand and shipped to book stores, your process is always affected by the idea of the book as a static, physical object. You have to "finish" the book by a set deadline. Updating and radical changes to a book which has already been printed tend to decrease book, and (quite often) the original authors retain no rights for redistribution online. This attachment to the physical object is driven by the economic realities of the publishing industry, but it creates an odd situation when you are writing about a rapidly moving open source project. There is a large disconnect between how we develop open source software and how we write books about open source software. Successful open source projects usually don't have a set release date, software like Maven is released when it is ready. Imagine how awful open source would be if everyone had to run around like headless chickens to cut a CD for something like Apache HTTPD. Imagine if a Maven release vote were predicated by "People, if we don't send the Maven ZIP file to the CD factory by next week, they might cancel our contract. Can I get three +1 votes, now." It just seems odd that we have to dance around publisher deadlines when we are writing books about collaborative, unpredictable, schedule-less open source projects.

Problem: Deteriorating Economic Model

Take, as an example, the Jakarta Commons Cookbook. I wrote this book between 2002 and 2003, and I probably invested about an entire year in the effort. It was my first book, so progress was very, very slow. The book was published, I felt great about the process. I think every first-time author has this initial excitement about having published a book. I didn't write the book for acclaim, I wrote it because it was my way of giving back to the community. A year passes, and you get the sales figures back and you, the naive author, are impressed that five thousand people bought the book. You get a flood of email from people who have read the book, maybe 10% are fuming mad at typos and the other 90% is just happy to have read the book. The publisher has a totally different view, 5,000 copies is actually viewed as a quarter success, the publisher would have liked to sell 10,000. While you feel great about the idea of a community of 5,000, the publisher is lukewarm about the idea of printing a second edition. Right right right, 5,000 is a loser? Visualize 5,000 people in a line all holding $20.... If that's a failure, if that doesn't justify a second printing, then something is wrong with the model. These days, publishers don't like to commit to books that are not going to move a significant number of copies. It is becoming more and more difficult to sell a good book to a publisher because as the open source world continues to evolve every topic becomes a niche topic with a limited audience.

Problem: Where's my community....

When you sell 5,000 copies of a book, you certainly get feedback both good and bad... But, you don't get the customer relationships. You don't get a chance to interact, and you certainly don't establish any sort of persistent HTTP 1.1 connection with your readership. Publishers provide some tools to enable this support: forums, blogs, etc. If you've grown used to the "intimacy" and unstructured creative anarchy of open source communities, you'll feel a bit stifled. Efforts like Jono Bacon's The Art of Community are an attempt to address this, and publishers like Pragmatic have done a good job of creating that sense of community... But, as an author, you will want to either create that community yourself or (better yet) integrate that community with the community that has already developed around the project you are supporting. Publishers serve an important curation function they provide the necessary work to ensure that the book meets production standards has come to be expected in a book, but they often don't do a great job organizing a community. Just like an open source project manages software production, I think authors and open source projects should manage a community of readers. Publishers used to be a necessary intermediary, but as the importance of the book as a physical artifact continues to decrease, I think we're going to see authors take more initiative and publish works online.