Book Sprints offer an exciting and fun process to work with others to make that book you always felt the world needed. It is a fast process – zero to book in 5 days. Seem impossible? Its not, its very possible, fun, and extremely rewarding in terms of output (a book!) and the team building that occurs during the process.
Collaborative Futures Book Sprint, January 2010
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 this is really an enhanced book slog - short collaborative bursts of activity to aid a more traditional book production strategy - which is becoming more popular as a strategy to accelerate the production of books.
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 it 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 of 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 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 third generation – Booktype. It does more or less the same job as the first tool set, but does it better – its easier to use, more flexible, and it supports a greater number of possible output formats and types.
While Booktype does a lot and its 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 renown 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 – otherwise 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. Thats 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, 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 its 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…
Reusable content is a huge asset to a Book Sprint. In a recent Book Sprint on Basic Internet Security and we were able to import about 9 chapters from 3 other manuals totaling approximately 15,000 words that we did not have to create fresh. Of course the material needed some work to fit the new context but it was still a substantial time saver and extended the scope of the book well beyond what we could have produced had we not had the material.
This was really quite amazing for me to see. The idea was imagined from the moment FLOSS Manuals was built but, 3 years later, this was the first real case of substantial re-use. It takes time to build up the materials to make sense of re-use in this way however after 3 or so years waiting for the moment I took a great deal of pleasure in seeing it happen for the first time.
The term ‘Book Sprint’ was coined by Tomas Krag . In the first sprints held under this term Tomas and the Wireless Networking for the Developing World crew came together for a week to plan the outline for a book and then later work remotely on developing and editing the contents. The books took 6-9 months to produce but the one week meeting period was innovative and critical.
I met Tomas at an event organised by Aspiration and was inspired to try it with FLOSS Manuals. Adam experimented with the format with the aim not just to outline a book in one week but to outline, write, illustrate, proof and illustrate the entire book and publish it in 5 days. Zero to book in 5 days. This rapid development of a book in 5 days is now what most people have come to think of as a Book Sprint.
Since this time (2008) FLOSS Manuals has produced over 40 books though Book Sprints about Free Software. Some have been produced with sprinters working almost entirely remotely. Others have been produced in just 2 short days. There have been sprints to translate books and sprints to translate books into other contexts. There has also been Book Sprints to rewrite the books created in previous sprints.
Recently there have been experiments to push the Book Sprint into areas other than its very technical origin. There have been a number of these Book Sprints including a book about co-working spaces, books about translation, and books about abstract ideas like ‘collaboration’ and ‘the open web’.