The OpenBooks Project
Author John R. Sheets compares the process of publishing books about commercial software with publishing books about free software, and suggests the OpenBooks project as a way to solve these problems.
The free software world is full of projects involving source code. Volunteers around the world donate countless hours of their own time to work on these projects, helping to build totally free operating systems, compilers, desktop environments, games, and so on. Most of these project are free software, which means that anyone can download the source code, make changes or fix bugs, and release a new version back to the world.
This process inevitably creates a huge pool of half-baked products that never catch on and thus never mature enough to be widely useful; however, the software that does spark people's attention and is used by many can quickly become mature, stable products. When a thousand people are using a text editor, bugs are quickly spotted. Assuming the software is actively maintained, these bugs can be fixed and a new release of the software cut and put back on the Internet. Without pricing and distribution to worry about, the new version can "hit the streets" literally overnight. In the free software world, it's not uncommon for a bug fix to come out within hours of the initial bug report.
The computer book publishing world is historically similar to the commercial software world. Because the publisher must worry about pricing structures, marketing concerns, and physical distribution, it must sometimes struggle to publish a cutting-edge book quickly, before the material is out of date. As long as published books follow commercial software, with its slow, steady release schedules, the 12 months it takes to get a new book out the door is fairly safe, especially if the author is working with an advance preview of the software.
The recent surge in popularity of free software like Linux and GNOME has put a new spin on the process of publishing books. While commercial software tends to have solid, official releases at long intervals, free software is released in more of an organic fashion, as a steady stream of micro-releases occasionally punctuated by a major release. Free software continually improves and develops. Narrowing down a specific release upon which to base a book can be a tricky endeavor, prone to last-minute revisions and sliding schedules as the author struggles to finish the book as close to the release date as possible. If the author finishes too soon, some last-minute changes in the software may lead to errors in the book; too late and the next version of the software may come out before the book reaches the consumers' hands.
To deal with this conundrum, publishers may have to adapt their publishing processes to more closely match the habits of the free software world. By keeping the authoring process more open, and encouraging users (i.e., readers) to make use of the book while it is still being written, authors can benefit from the "thousand eyes" that help debug free software so well. Mailing lists and Web sites can provide a medium for early readers to supply feedback about the author's coverage of the constantly mutating free software products.
This new openness does not come without problems and potential dangers. Authors must be diligent and focused, and avoid the temptation to dilute the writing process by turning the book entirely over to the community of users; without a strong, consistent vision, a book can quickly decay into a rambling series of disconnected essays. In free software terms, the book should have a strong maintainer to keep the vision clear.
Putting a half-baked book up on the Internet and soliciting reader impressions of it adds a peculiar new twist to the publishing process. The publisher loses any semblance of a surprise release, and may have to worry about sales impact if the book is released under an OpenContent-style license, as is popular with free software documentation. If anyone can legally download and publish the book, the publisher loses exclusive rights to it, and may theoretically have to compete for sales against its own book! However, these fears may be unfounded; OpenContent books have already started to appear, and seem to be doing very wellin particular, Havoc Pennington's book, GTK+/GNOME Application Development.
The OpenBooks project attempts to bring these problems to light and solve them in the same style that has made free software such an unmitigated success. On its Web site, OpenBooks will display professional-quality books released under OpenContent-style licenses, such as Havoc's book, and my own Writing GNOME Applications book.
OpenBooks will encourage authors to maintain their own books as part of the project, and discuss them on the OpenBooks mailing lists. OpenBooks will also supply mailing lists and forums to help publishers interface better with the free software community. Publishers can meet and court potential new authors, and learn about the needs and peculiarities of the community. In essence, the OpenBooks project hopes to encourage an open dialogue between professional book publishers and the free software world. In doing this, we can hopefully solve the problem of publishing books about free software in a manner that's good for publishers, authors, and readers alike.
John R. Sheets has been following the GNOME project on a day-to-day basis for more than two years, since GNOME was only six months old. He is a software developer for CodeWeavers, Inc., where he works on Wine and GNOME. In his free time, he is helping the WorldForge Project to create a free online multiplayer gaming environment. John is the author of Writing GNOME Applications (Addison-Wesley, 2001), and the maintainer of the OpenBooks Web site.