Tag: FLOSS Manuals

“Collaboration on a book is the ultimate unnatural act.” 
—Tom Clancy

One of the most obvious opportunities open to online  book production is collaboration. Of course, collaborative writing actually has a somewhat (unfairly) tainted name. During the first wave of wiki-mania, Penguin books conducted an experiment called A Million Penguins1, a collaborative writing project using a wiki. By all accounts, it was more successful as a social experiment than a literary experiment. I think most people think of this kind of thing when they think about collaborative writing. It's an interesting experiment, the thinking goes, but possibly it is not able to produce the same quality as a single-authored work.

However, let’s not forget that ALL books are produced collaboratively. Books generally carry the name of a single author but this is because the publishing industry trades on this. Publishing is a star system and its bottom line relies on it. It is better for a publisher to build up one star than distribute the glory over the 2,5, or 10 who were actually involved in producing the book. As a general rule acknowledging collaborative production is not good for business.

Rather than deny collaboration occurs, it is better to consider whether the character of the collaboration is weak or strong.  Borrowing from a list of continuum sets outlined for collaboration in the book Collaborative Futures²  we could characterise it something like this:

1. Weak – A single writer completes a work and secondary collaborators discuss or change elements with little or no interaction. For example, a friend reads and discusses elements or a proofreader is commissioned to clean the work up. In the case of the proofreader, little or no interaction occurs between the original creator and the proofreader although they are both aware of the proof reader’s role and changes in the text. The text is monolithic and attribution is solely to ‘the author’. An example would be any Tom Clancy work.
2. Stronger – A single writer works with an editor, colleague, family member or friend to shape the text throughout the writing process. It is in part a form of mentor – writer relationship with the boundaries negotiated in a fluent and ongoing nature. The collaborator will make direct changes as challenges and suggestions. The text is monolithic but possibly with shared notes, and attribution is to ‘the author’ with thanks  in an additional credit note to those that helped. This is a very typical methodology for publishers but also many works embrace this process informally. Mary Shelley’s Frankenstein is an example where many have argued that Mary Shelley formed a collaboration like this with her husband Percy Shelly.
3. Strong – A multi-authored work where multiple collaborators share various levels of authority to act on the text in a highly modular and seemingly autonomous fashion. Although there is something of an over-reliance on the Wikipedia as an example, its unusually evolved structure makes it a salient case. Collaboration is remote but a coordinating and shared goal is clear: construction of an encyclopedia capable of superseding one of the classical reference books of history. The highly modular format affords endless scope for self-selected involvement on subjects of a user’s choice. Ease of amendment combined with preservation of previous versions (the key qualities of wikis in general) enable both highly granular levels of participation and an effective self-defense mechanism against destructive users who defect from the goal. Attribution is shared.
4. Intense – A multi-authored work where the collaborators decide on the scope and character of the book in close and intense discourse throughout the production process. It is generally a very egalitarian environment and permission is not sought or needed to change a colleague’s work. FLOSS Manuals, originally established to produce documentation for free software projects, is a good example. Their method usually involves the assembly of a core group of collaborators who meet face- to-face for a number of days and produce a book during their time together. Composition generally takes place on an online collective writing platform, integrating wiki-like version history and a chat channel. In addition to those physically present, remote participation is solicited. It is necessary to come to an agreed basic understanding between collaborators through discussion of the scope and purpose of the book. Once underway both content and structure are continually edited, discussed and revised. The text is modular with granularity on the chapter level. Attribution is shared and often not as important as other forms of collaboration.

Producing books online obviously opens up some very interesting possibilities for collaboration. First, unlike a typical writer’s room, the net is a public space. That multiplies the possibility of making connections and working with people you may not know. It also means that you could box yourself in and open the door just to those you want to let in. The point is that you have the choice.

In addition to this continuum, there are open and closed collaborations. Open collaboration is an open door policy where anyone can come in and participate. A closed collaboration is where the boundaries of participation are set by social or technical means. Open and closed is a continuum characterised by the strong or weak porous nature of the boundaries. Closed collaboration is the default for the production of almost all books at the moment but some of the most amazing results can come from opening yourself up to open collaboration. My experiences working 5 years like this with a repository of 300 books and 4000 collaborators can recount many stories regarding this as the repository is completely open. Anyone can register and edit any book. As a result of these experiences, I find the case for ‘open collaboration’ extremely compelling. Interestingly, however, the more intensive the collaboration is the more difficult it is to sustain openness. New contributors may have missed formative discussions regarding the book and struggle to find a ‘way in’ to the content, additionally, new contributors may find it hard to enter the close-knit social fabric that is created as people work intensely together over time.

The following are two examples of collaborative workflows enabled by online book production. They investigate different points along the collaborative continuum. The first example is from James Simmons. James wrote several books online in a manner he calls a ‘Book Slog’ or ‘collaborating without co-authors’ – you might think of it as ‘the normal way’ to make books. The second example is of accelerated book production using a collaborative process known as a Book Sprint.

The normal way…

From the words of James Simmons:

A “Book Slog” is pretty much the normal way of writing a book. It is what most publishers would nail (attribute) to a single author. The long road to producing a book.  For example: The book will, of necessity, take more than a week to write.  More than likely it will take months, and will involve much research.  The main author will end up knowing much more after finishing the book than he did when he began it. The book will have one main author, who will do most of the actual writing. The book may or may not have other contributors.The contributions of others may be informal. Other contributors will not be as highly motivated as the main author, or may have their own motivations that are not the same as the main author.The contributors will likely never meet face to face.

The question is, does online production have anything to offer the Slogger? Based on my own experiences, I would have to say it does. I used Booki (now Booktype) for my books. The main reason to use Booki rather than a word processor to write a book is to effectively collaborate with other authors.  I have completed two books this way (and the Spanish translation of my first FLOSS Manual would definitely qualify as a third), so my opinions on this might be worth something.

Some might not think of these books as a collaborative effort, since I wrote every word, but in a very real sense they are collaborative works. I got lots of feedback from other developers, help in debugging my examples, help resolving problems with the test environments, and many useful suggestions. Writing the book on the web made that kind of collaboration much easier.

There were a couple of people who offered to write chapters, but this did not come to pass. In the end, this didn’t matter; the books ended up doing what they needed to do.

After the first book was published, there was interest in creating a Spanish version. Some of the most successful OLPC projects have been in South America, so I definitely wanted there to be a Spanish version.  Unfortunately, I don’t speak any Spanish, so I didn’t feel qualified to do it. After the translation project got set up, a couple of people got accounts and looked over the book, and one of them translated a few paragraphs. Several of the people who had offered to help were concerned that they did not have the technical knowledge to translate the book, and for several days it looked like nobody was going to work on it.

A friend suggested using Google translate to create a base translation that native speakers could correct. I ended up using Babel Fish instead because the HTML generated by Google Translate had a lot of extra stuff in it like JavaScript and the original English text being translated. After I started doing this, a retired teacher who was fluent in Spanish started to correct the text, and I went through it and untranslated things that should not be translated, like code examples. It really needed native speakers to get it into shape.  The retired teacher sent out an email on some lists explaining that we had a translation going that needed to be corrected. After that, several native speakers got accounts on the site and started to correct the text.

What I learned from this, is that starting a book from nothing is intimidating. However, once the book reaches a critical mass and there is no doubt that there will be a finished book, you’ll find that getting help and feedback is easier, almost inevitable.

The best motivation to collaborate on writing a book is a desire for the book to exist. To quote Antoine de Saint-Exupery:

“If you want to build a ship, don't drum up people together to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea”

If you can sell people on the idea of the book, you’ll get collaborators. That’s another reason you may have to write a substantial chunk of the book before collaborators show up. A partial book is easier to sell than an idea for a book.

With the book “E-book Enlightenment,” I collaborated with some people from an organization in Oregon called the Rural Design Collective. This is a group that has done work for both the Internet Archive and the One Laptop Per Child project. They have a summer mentoring program where talented students get involved with an Internet project and learn skills that may lead to a future career.

When I announced that Make Your Own Sugar Activities! was finished, I got an email from Rebecca Malamud of the RDC congratulating me. I told her about my plans for a new book and asked if she’d like to contribute.

At that point, the RDC was contemplating what to do for their summer mentoring program and they decided that working on my book might be just what they were looking for.

We all wanted the book to exist, but for different reasons. The RDC is focused on training young people to create websites, and so they chose to focus on the graphic design of the book more than the content.

The RDC found a talented young artist who did some terrific cover and interior illustrations (the small ones at the top of each chapter). The cover illustration that everyone liked didn’t really go with the title I had proposed, so I ended up changing the title.  (The same artist also did new cover art for the printed Make Your Own Sugar Activities!) Another of their mentees created stylesheets which they used to create a really beautiful bound and printed edition of the book.

In addition to the RDC’s work, I also got much help and encouragement from the forums of DIY Book Scanning and Distributed Proofreaders. Again, this is not collaboration in the way the word is normally used, but it was a vital contribution to the book. I would post a link to the book on the FLOSS Manuals website and ask for comments. The comments I got often contained valuable information and suggestions.

So, in summary, I’d say that online production is a good way to collaborate on writing a book!

Book Sprints

A more radical action for online book production is the Book Sprint³.

“I have written basic introductions to the command line in three different technical books on GNU/Linux and read dozens of others. FLOSS Manual’s Introduction to the Command Line is at least as clear, complete, and accurate as any I’ve read or written. But while there are countless correct reference works on the subject, FLOSS’s book speaks to an audience of absolute beginners more effectively, and is ultimately more useful, than any other I have seen.”

1. http://thepenguinblog.typepad.com/the_penguin_blog/2007/03/a_million_pengu.html^{^}
2. http://www.booki.cc/collaborativefutures/continuum/^{^}
3. http://www.booksprints.net^{^}