My role as âan educatorâ revolves around group processes â namely, Book Sprints. Essentially I facilitate groups of 5-10 people working together in one room over an intensive 3-5 days to produce a book. Zero to book in 5 days (or less). This process is known as a Book Sprint and although it is an uncommon practice, most people who ask for and participate in a Sprint see it as a Book Production methodology. However, 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.
I also believe that this process can be used by students to write their own textbooks, learning what they write and passing the free textbook onto the next year’s students to improve. I am eagerly awaiting the first enlightened institution that would take this on, and I am sure they would be positively surprised by the results â both in the quality of books produced and by what the students learn in terms of content and collaboration.
Book Sprints utilise collaborative environments. The only Book Sprint (1) I know of before we did them (2) used word processing documents â passing these around via email between collaborators â and a wiki for collecting the articles. Part way through the process, they gathered in person to develop the outline in a one week intensive âOutline Sprintâ and then proceeded to collaborate via email and a wiki over a period of 4-6 months. After the material was complete, the group passed the documents through several editing stages. The process cut the standard industry timeline down by about 30-50%. Zero to book in 4-6 months is still pretty good in the publishing industry.
However, for FLOSS Manuals, 4-6 months was too long. We wanted to do it in 5 days and so we needed a quicker methodology and a better tool set. Wikis might come to your mind immediately as they did to us. However, we had already realised 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. Books can be many things, so I am talking here about what âmostâ people mean by a book. A one piece cover, several hundred pages, table of contents, structured readable and comprehensive content, self-contained 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 â paper books â in a Book Sprint environment. Zero to book in 5 days â that leaves about 3 minutes at the end to produce book-formatted PDF ready to upload to a PoD service or send to the local printer. That is what we needed, and wikis donât enable you to do that. So we hand rolled our own. The first generation was built on TWiki 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.
While Booki does a lot, and it’s hard to imagine a Book Sprint without it, there are limits to working digitally in a Book Sprint. Certainly, we also experience the highs of surprising networked collaboration. One Sprint (âIntroduction to the Command Lineâ) was written almost entirely remotely and written in 2 days (Mako Hill, FSF Board member and renowned hacker said it was the best book on its topic). However, 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 â other wise we would have all of our Book Sprints remote â it would cut down on logistics and costs. However text-based chat does not convey enough information, VOIP is terrible for more than 2 people at a time and even then I wonder at its real usefulness in intensive collaboration, and email is just too slow and the âunthreadedâ nature of email will soon drive you crazy in this kind of environment. Microblogging is as good as IRC in this instance â ie. barely useful. Sneaker networks are not only faster but more fluid and they enable better-shared understandings, quicker.
In addition, I find it is often good to push people out of the screen and into the book. Since we work fast in Sprints we sometimes realise we need to clean up structural issues. This often occurs when 2 or more people are working on content that needs to fit together â and it doesnât. Often we print out the necessary chapters, sit on the floor, and (gasp) cut-and-paste the chapters into each other until they work. Same process as a digital text editor, just with a physical tool set â the result is that it gets better results quicker.
The end result of a Book Sprint is a book. That’s a great thing to have. However there is also a mandate to take care of, and content to take care of. How do you enable this content to live? Books do not live by licenses alone â they need help. They need the original collaborators to find the avenues to keep the content alive. One strategy is to maintain this content themselves although, despite good will, this seldom continues beyond some initial edits immediately after the Sprint ends. The original collaborators need to pass on the mandate to others and this is critical for the life of the book. As such I discourage the use of terms like âauthorsâ as this denotes legacies of ownership and does not encourage new contributors to take the mandate to improve the book. Instead, the strategies revolve around keeping the participation threshold low (minimising social filters, using open language, making Booki simpler and simpler to use) and welcoming in new contributions. We also welcome forking books. Take a book â make it your own whichever way you feel is best.
However occasionally Sprinters, caught up in the fervor of intensive production, often get worried about misappropriation or unethical use and erect barriers that do nothing to help and a lot to hurt. 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 quandry put at the foot of freedom largely by the fears and protective necessities of the proprietary publishing industry, We all carry this a little bit and 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 are left âfightingâ the default â standard attitudes towards publishing and authorship means it’s hard work to get people to uptake 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. I am hoping soon we see will the integration of Book Sprints into curriculum to create and improve textbooks as another way to explicitly pass on the mandate to change,and Iâm very much looking forward to seeing this strategy developâŚ
Notes:
(1) The idea of a Book Sprint as outlined in the article by Marco Zennaro et al was the brainchild of Tomas Krag
(2) Marco Zennaro, Enrique Canessa, Carlo Fonda, Martin Belcher, Rob Flickenger, âBook Sprintâ in The International Journal of the Book (Melbourne, Australia, Common Ground Publishing, 2006) Vol 2 Number 4.
written by Adam Hyde, founder of FLOSS Manuals.
