My role as an educator revolves around group processes. Essentially, I facilitate groups of people working together intensely in one room over a short period of time to produce a book. The book is made, from start to finish, in five days (or less). This process is known as a Book Sprint. Book Sprints start with a group of five-ten people, a facilitator, and an idea or a title for a book, and wrap up five days later, culminating in the production of a finished book. It is an infant methodology, just over three years old, and practiced predominantly within the community of FLOSS Manuals, an online community of 3000 people dedicated to developing free manuals about free software. While the methodology is still being defined and refined, it has proven that it can produce outstanding material within the realm of Free Software documentation. I am also pushing the Book Sprint into other content areas and narrative forms to see what, if any, its limits are. The most recent experiment is “An Open Web” a book written in five days speculating on what an “Open Web” might be.
Book Sprints utilize collaborative online and offline environments. The only Book Sprint I know of before I did them used word processing documents, which were passed around via email between collaborators, and a Wiki for collecting the articles (Zenarro et al. 3). Part way through the process, collaborators gathered in person to develop the outline in a one week intensive “Outline Sprint” and then proceeded to collaborate via email and Wiki over a period of four to six months. After the material was complete, the group passed the documents through several editing stages. The process cut the standard industry timeline down by thirty to fifty percent. Making a book from start to finish in four to six months is still pretty good in the publishing industry.
For the “Free, Libre and Open Source Software” (FLOSS) Manuals, however, four to six months was too long. We wanted to finish these in five days, so we needed a methodology for a faster turnaround and a more suitable tool set. Wikis might come to your mind immediately as a solution, as they did to us; we realized, however, that Wikis were not built with the right paradigm. Books are very structured and Wikis are not. That is the essence of it—I don’t want to get into “future of the book” discussions. Although books can be many things, I am referring here to what most people mean by “book:” an object with a one-piece cover; several hundred pages; a table of contents; structured, readable and comprehensive content; self-contained material with very few references to other parts of the document; and careful use of outside references instead of a welter of back-and-forth hyperlinks. We built a system that could produce this kind of book (a paper book) in a Book Sprint environment. Zero to book in five days—plus about three minutes at the end to produce a book-formatted PDF ready to upload to a print-on-demand service or send to the local printer.
The first generation was built on T-Wiki and we pushed it to its outer limits with extensions built by Aleksandar Erkalovic and a PDF renderer built by Luka Frelih. Now we are onto the second generation—Booki (a Book-Wiki, if you will). It does the same job as the first tool set, but does it better; it’s easier to use, more flexible, and it supports a greater number of possible output formats and types. Booki is built with online book production as its core paradigm. It is not a hack of a Wiki. As such it is immensely more powerful than our previous toolset, and it is fair to say it is opening our eyes to many new possibilities for book production and publishing.
While Booki is also built to assist Book Sprints, and it is hard to imagine a Book Sprint without it, there are limits to working digitally in a Book Sprint. Although we sometimes experience the highs of surprising networked collaboration—one sprint (“Introduction to the Command Line”) was written almost entirely remotely in 2 days (Mako Hill, Free Software Foundation Board member and renown hacker, said it was the best book on its topic)—there are also limits to digital media and digital networks. I believe that there is less knowledge passed through digital media communication channels when collaborating. I firmly believe this. If this were not the case, all of our Book Sprints would be remote, because this would cut down on logistics and costs. Text-based chat does not convey enough information, VOIP is terrible for more than two people at a time (and even then I wonder at its real usefulness in intensive collaboration), and email is too slow. Microblogging is as good as IRC in this instance (i.e. barely useful). Sneaker networks are not only faster but more fluid; they enable better shared understandings more quickly.
The end result of a Book Sprint is a book. Booki generates the book-formatted PDF in minutes and it can be immediately sent to a printer or uploaded to a print-on-demand service. That is a great thing to have at the end of a sprint, but it is also a living book that can be continually edited and improved, remixed, translated and recontextualised. That sounds too easy. While there is a lot of potential for reuse, the most important issue is the mandate to change the book. Books do not live by free licenses alone; they need help. They need the original collaborators to find avenues to keep the content alive and to pass on the mandate to change. It is possible to ignore this issue and try to encourage the original contributors to maintain the content themselves, but, despite good will, this seldom continues beyond some initial edits made immediately after the sprint ends. The book’s original collaborators need to pass on the mandate to others; this is critical for the life of the book. As such, I discourage the use of terms like “authors” that denote legacies of ownership and do not encourage new contributors to take up the mandate to improve the book. Instead, strategies revolve around keeping the participation threshold low (minimizing social filters, using open language, making Booki simpler and simpler to use) and welcoming new contributions. We also welcome forking books: taking a book and making it one’s own in whatever way feels best.
Occasionally, however, sprinters caught up in the fervor of intensive production get worried about misappropriation or unethical use and erect barriers that do nothing to help and a lot to harm. They ask themselves questions like “What if someone takes the content and makes money? What if contributors spam the book? What if someone changes the tone of the book? Could contributions ruin it?” This is the ethical quandary put at the foot of freedom largely by the fears and protective necessities of the proprietary publishing industry. This is a common concern. My response is always, “Let it go. Let the content be free and you will be happily surprised by the results.” The irony is that once sprinters are convinced of this idea, they find themselves “fighting” the default attitude; standard attitudes towards publishing and authorship mean it’s hard work to get people to take up the freedoms of free content. Book Sprint collaborators (and free content developers in general) often need to put a lot of energy into reaching out to others to get them to take ownership of the material and make changes, but it can be done with the right approach.
“Booki and Book Sprints in Action” FLOSS Manuals is a library of cost-free manuals about free software. At least, that is the entry point for most people. They come to read comprehensive, clear manuals about how to use free software. The manuals are available online to read and also available to download as screen-formatted PDF. Many of the manuals can be bought as books from the print-on-demand service Lulu. Over fifty manuals are available on the English site. There are five main FLOSS Manuals language sites: English, French, Farsi, Dutch, and Finnish, and there is a translation zone hosting many of these manuals in Burmese, Hindi, Russian, simplified Chinese, Spanish, and many other languages.
As well as the manuals, there are the people who produce the manuals: the FLOSS Manuals community. Numbering about 2500 people in total, the community works away in the background creating these manuals and updating, improving and translating them. Almost all of the work is voluntary, with only a few people being paid. Of those who are paid, very few are paid directly by FLOSS Manuals but garner resources through organizations that need specific content. It works very much like an ecology of open-source development except with “content” producers instead of developers.
FLOSS Manuals was established to solve the lack of quality documentation about free software. Many have tried to solve this problem with varying degrees of success. The Linux Documentation Project was probably the most successful attempt. It hosts a large amount of very useful and very technical documents. FLOSS Manuals, however, are aimed at “the user.” That person (it could be you) works on the desktop and has a problem to solve that they would prefer to solve with free software if only they knew how. That’s the target audience, and the manuals are generally written with a very friendly approach, holding the hand of the “newbie” and walking them through everything from “What is this software and what does it do?” to background concepts, installation and simple and advanced use.
The manuals are comprehensive and self-contained. They are generally written by “interested users” who wish to pass on their knowledge, but also occasionally involve the developers of the software. In some circumstances, the development of the manual has led to improvements in the software as a consequence of discussions between the developers and the documentation crew.
FLOSS Manuals’ contributor community revolves around Booki for the isolated individual and collaborative development of books and Book Sprints. Both have proven to be very effective tools and hence we are pushing Book Sprints into other areas and we have also installed Booki on another domain for anyone to use for any type of content.
Booki is being used a lot in both these contexts and hosts a lot of fantastic material. Many of the manuals in FLOSS Manuals are used in educational environments either as recommended or required texts.
The new domain, Booki.cc, is also seeing an increasing amount of content being developed within its domain. Betahaus, the world’s largest co-working space (based in Berlin) recently used it to sprint a book about co-working. The “Arctic Perspectives Initiative” is using it to produce a book on Arctic technologies to be published by the well-respected German publishing House Hatje Cantz. Albany University (New York State) is using it to develop text books. There are numerous other excellent examples of Booki’s utility, but at the same time it is a long way from achieving its potential.
One of the most exciting areas for potential is OER – Open Educational Resources. I hope we will soon see the formal integration of Book Sprints and Booki into curricula to create and improve textbooks. Although it is an uncommon practice, most people who ask for and participate in a sprint see it as a book production methodology. However, while we do produce books, a Book Sprint is as much as about learning as it is about writing. I would argue that in all circumstances the collaborators walk away having learned a great deal about the subject they have just created a book about.
There has been one such investigation of this with students lead by Kieran Nolan, a teacher at DkIT in Ireland. Kieran asked students to create a book together using Booki. The project is for a module called “User Theories,” which Kieran leads for fourth-year students in the BA (Honors) program in Communications and Creative Multimedia. The course looks at different interactive media types, different user groups and the creative ways in which people repurpose and reuse all the digital creation and distribution. In Kieran’s words:
The topic we had last week in class was ‘Emotive Design’ and trying to reduce user frustration with interactive media. In other words, looking at ideas of giving interactive products personality (for instance, avatars) so that users feel some sort of connection and less alienated to the product. So the students are being asked to reflect on the readings and come up with their own idea for an ‘emotive interface.’ (Booki Blog)
Rather than create the content individually, Kieran’s students are to create a book collaboratively. Kieran likes the idea of Booki because the class can share their ideas, learn from each other, and practice using a collaborative online tool. The fact that students can produce a book from the result adds another dimension for Kieran: “It bridges the gap between digital and print media and produces a tangible product” (Booki Blog).
Kieran utilized the history feature of Booki to track a student’s contribution to the project. The work will count for 15% of the final mark.
The students collaboratively produced a book called ‘Emotive Design’ using the Booki platform. Over the space of two weeks the class collaborated through Booki both together in the lab and individually at home to create a compendium book of 21 original design concepts.
The final push on the project was made during a lab at the end of the December, when Ireland was hit with an unseasonably cold snap. More than half the class were stranded at home due to the snow but this was no obstacle to completing our project on time. Through Booki’s live discussion function everyone could communicate effectively whilst piecing together the final chapters of our book, learning from each other’s contributions and providing valuable peer feedback.
The students I teach are well accustomed to using the online space as a learning environment. While a lot of material can be covered in the space of a single lecture, extra time is often needed to help students absorb and reach a deeper understanding of their source material. Online discussion of in class topics helps facilitate this. So too experiential learning is essential for reaching deep understanding of a subject. By allowing collaborative building and communication facilities, Booki addresses both of these concerns robustly. (Booki Blog)
This is a great initiative and a great first step. I hope to see more students writing their own textbooks with Booki, learning as they write and passing on the free textbook to the next year’s students to improve. I am also eagerly awaiting for an enlightened institution to be the first to take on a Book Sprint to create textbooks. I am sure they would be positively surprised by the results, both by the quality of book produced and by what students learn in terms of content and collaboration.
Booki Blog. 24 November 2010. Web. 15 February 2011. <http://blog.booki.cc/2010/11/students-use-booki-to-write-their-own-textbook/>.
Zennaro, Marco, E. Canessa, C. Fonda, M. Belcher and R. Flickenger. “Book Sprint.” The International Journal of the Book. 2.4 (2006). <http://users.ictp.it/~mzennaro/BookSprint.pdf>.
 See <http://openweb.flossmanuals.net>.