Print on Demand vs Demanding Printers

I have been experiencing quite a strange phenomenon recently. On several occasions, I have found myself looking for printers that can print perfect bound books quickly. A ‘perfect bound’ book is a book that is normally called a ‘paperback’  – black and white interior colour cover, and a nice thick one piece cover that tightly hugs the outside of the book and is creased and folded along the spine.

print_on_demand_booksPerfect Bound books printed in less than 20 hours

I have needed these services after a Book Sprint – typically I have spent 5 days in a room with half a dozen others and we have written a book of 300 pages or so. We output the content to book-formatted PDF with Objavi, and next, to make it a real party, we want to see the book the same day we finished it, or the next morning. It is entirely possible to do this, and I have done it many times. However, the one thing that might catch you out is actually finding the right type of printer that can make perfect bound books fast. This is not easy, and sometimes is made harder if you are in a non-English speaking country as the English term ‘perfect bound’ does not easily translate.

What I have found, is that most large cities have these services. In Berlin, for example, there is a service about 5 blocks away from my house. In Paris, you need to travel out to the suburbs to find a service but there is one. In Palo Alto, Kinkos does it (but doesn’t do it well)…etc….

While these services are relatively common, what I have found, time and time again, is that these services are very hard to find. The first issue is that they have no standard way of marketing their services. It is sometimes advertised as ‘print on demand’, sometimes ‘books on demand’ and sometimes they just don’t let people know they have these services until you ask. Hence trying to find a business that does this via a search engine, a phone book, or asking a local, just gets you nowhere. You have to call every printer one by one, carefully explaining exactly what you want. Sometimes this is also difficult since the operators might not be printers and so they don’t actually know the terminology, and I have found myself trying to explain what ‘perfect binding’ is to a ‘printer’.

The other issue, and this is the one that I find strange and has tripped me up so many times, is that often the locals – printers and non-printers alike – do not think this kind of service exists at all. That is, they think its impossible. This frustrates me the most.

Essentially there are two typical responses from printers that do not provide this kind of service. The first is from your typical ‘copy shop’ – they will tell you they provide these services and then, when you turn up to look at the samples, you find they are talking about spiral or tape binding. Ugh. After explaining this is not ‘perfect binding’ the normal response is a blank stare and a comment that ‘it is not possible’ and furthermore, if they acknowledge that maybe it is possible, the copy shop assistants, not usually knowing the printing industry very well, will have no idea who might be able to do this.

The next kind of response comes from your traditional offset printer. They will tell you they can make a book but you have to get 200 done, it will take a week, and it will cost you a lot per book and expensive set-up costs. When explained that this is not what you want, they will understand what perfect binding is, and they do know the local print industry, but they will not think doing this is possible or have any idea who might be able to give more information about where to find such a service.

I have been through this process many times. My advice is – it can be done. You can find, in most large cities, printers that will print a book in hours and print it cheaply. Recently in Paris, we had 50 books (300 pages) printed for 6 Euros each, no setup costs, and delivered in less than 20 hours. It could have been faster if we had less printed. Often 1 book can be done ‘on the spot’. So don’t give up. It’s perfectly possible to get the job done: the hardest part is finding the people who can do it…

 

What is Booki… no, really?

At some point, we have to lay down the vision for Booki. Now might be as good a time as any… Booki is a new approach to publishing. It is in simple terms, a kind of social network for publishing. Actually, I find the analogy of the social network fits quite well when trying to communicate what Booki does. Take a well known social networking site… take your pick… you probably use one or more. In these environments, people gather and share information about themselves. They chat with each other, keep each other ‘posted’ on what they are up to, share opinions and communicate what they are interested in etc.

All in all it’s great fun. Social networks are after all very social – however, mostly that’s all they are. Isn’t that a little sad? Wouldn’t it be nice if all that energy was put towards something useful…something that might change the world?

Imagine taking all that energy in a social network, putting it into an environment that is just as much fun, just as social, but directing the energy towards something productive. Imagine an environment where you chatted with others, met new people, kept them up to date with what you are up to, discussed opinions, had fun… except all this activity was focused on and around making and publishing books. Real books, ones that you could show your friends and tell them you helped create. Imagine spending all that time you currently spend on a social network, except that you find yourself helping someone write a free text book for kids who can’t afford books, or working to improve someone’s novel, or helping write a cook book on Mexican cooking, or a book on fixing Schwalbes.

That is exciting, that is the new world of publishing, that is what a social network can do, but none did… until Booki…

This is the environment we  are building. We have come a long way towards our goal – Booki is functional and pretty stable – but we still have a long way to go. The Booki development team is making fantastic progress and the good news is – it’s free software and that means you can help us get there faster. If you would like to help us revolutionise the world by bringing social networking to publishing… then welcome aboard 🙂

 

Booki, OLPC and OER

You may be familiar with the One Laptop Per Child (OLPC) project. It’s pretty well known and aims to provide free laptops to children all over the world who otherwise could not afford them.

The OLPC is also a pretty good ebook reader, as demonstrated here:

eBook on the OLPC

The above image is taken from Reading and Sugar – an excellent manual by James Simmons about working with ebooks on the OLPC. The image shows a book taken from Archive.org and imported into Booki – Booki then exported this to an ePub and this was opened on the OLPC as shown.

In the same manual, James talks about using Booki on the OLPC to author ebooks. To quote James:

“Booki is one of the best tools available for Sugar users to create e-books.  It can be used on the XO or from Sugar on a Stick.  It supports many authors collaborating on a single book.  It supports translating books into many languages.  It can create PDFs and EPUBs.  It can create books formatted for print-on-demand services.  It can create documents in Open Office ODT format (which Open Office can convert to MS Word format).  It can even be used to download, proofread, and correct EPUBs created by the Internet Archive.

Booki is an excellent option for teachers preparing textbooks, but it can be used by students for their own projects too.”

Below is an image from the same manual showing Booki being used in the Browse activity (the OLPC browser).

Booki on the OLPC

We are hoping the good work James has been doing will help raise the awareness of Booki as a platform for book authoring on the OLPC which would open up the world of publishing considerably and (we hope) open up exciting possibilities for OER (Open Educational Resources)…

 

Collaborative workflows in online book production – some case studies

“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 Futures2  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 Sprint3.

A Book Sprint is a facilitated process that brings together a group of people to produce a book in 3-5 days (although it has been done in shorter time). While the group meet in person, the books are produced collaboratively using networked (online) end-to-end book production tools. Often remote participants also join in. Usually, there is no pre-production and the group is guided by a facilitator from zero to published book. The books produced are high-quality content and are made available immediately at the end of the sprint in printed (using print-on-demand services) and e-book formats. Book Sprints produce great books and they are a great community and team building process.

The quality of these books is exceptional, for example, Free Software Foundation Board Member Benjamin Mako Hill said of the 280 page Introduction to the Command Line manual produced in a two-day 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.”

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? It’s not, its very possible, fun, and extremely rewarding in terms of output (a book!) and the team building that occurs during the process.

There are three common reasons to do Book Sprints:

  1. Producing a book that will be ready at the end of the Sprint drives the process and helps to justify the effort.
  2. Producing knowledge in a short period of time forces the participants to master the issues related to their subject. They will work intensely on content together, share and reshape their understanding of a collective question.
  3. Reinforcing or creating social links. Mobilizing a community to produce a book or text forges and solidifies a sense of belonging among participants.

As a result, I have experimented a lot with this format. To understand the many facets of collaboration in this process let’s look at the second case study – Collaborative Futures.

This book was first written over 5 days (Jan 18-22, 2010) during a Book Sprint in Berlin. 7 people (5 writers, 1 programmer and 1 facilitator) gathered to collaborate and produce a book in 5 days with no prior preparation and with the only guiding light being the title ‘Collaborative Futures’. These collaborators were: Mushon Zer-Aviv, Michael Mandiberg, Mike Linksvayer, Marta Peirano, Alan Toner, Aleksandar Erkalovic (programmer) and Adam Hyde (facilitator).

The event was part of the 2010 Transmediale Festival . 200 copies were printed the same week through a local print on demand service and distributed at the festival in Berlin. 100 copies were printed in New York later that month.

The book was revised, partially rewritten, and added to over three days in June 2010 during a second book sprint in New York, NY, at the Eyebeam Center for Art & Technology as part of the show Re:Group Beyond Models of Consensus and presented in conjunction with Not An Alternative and Upgrade NYC.

developed_collabfutures

Collaborative Futures – Second Edition cover by Galia Offri

Day one of the first sprint consisted of presentations and discussions.

During this first day we relied heavily on traditional ‘unconference’ technologies—namely colored sticky notes. With reference to unconferences we always need to tip the hat to Allen Gunn and Aspiration for their inspirational execution of this format. We took many ideas from Aspiration’s Unconferences during the process of this sprint and we also brought much of what had been learned from previous Book Sprints to the table.

First, before the introductions, we each wrote as many notes as we could about what we thought this book was going to be about. The list consists of the following:

  • When Collaboration Breaks.
  • Collaboration (super) Models.
  • Plausible near- and long-term development of collaboration tech, methods, etc. Social impact of the same. How social impact can be made positive. Dangers to look out for.
  • Licenses cannot go two ways.
  • Incriminating Collaborations.
  • In the future, much of what is valuable will be made by communities. What type of thing will they be? What rules will they have for participation? What can the social political consequences be?
  • Sharing vs Collaboration.
  • How to reconstruct and reassemble publishing?
  • Collaboration and its relationship to FLOSS and GIT communities.
  • What is collaboration? How does it differ from cooperation?
  • What is the role of ego in collaboration?
  • Attribution can kill collaboration as attribution = ownership.
  • Sublimation of authorship and ego.
  • Models of collaboration. Historical framework of collaboration. Influence of technology enabling collaboration.
  • Successful free culture economic models.

Then each participant presented who they were and their ideas and projects as they are related to free culture, free software, and collaboration. The process was open to discussion and everyone was encouraged to write as many points, questions, statements, on sticky notes and put them on the wall. During this first day we wrote about 100 sticky notes with short statements like:

  • “Art vs Collaboration”
  • “Free Culture does not require maintenance”
  • “Transparent premises”
  • “Autonomy: better term than free/open?”
  • “Centralized silos vs community”
  • “Free Culture posturing”

…and other cryptic references to the thoughts of the day. We stuck these notes on a wall and after all of the presentations (and dinner) we grouped them under titles that seemed to act as appropriate meta tags. We then drew from these groups the 6 major themes. We finished at midnight.

Day two—10.00 kick off and we simply each chose a sticky note from one of the major themes and started writing. It was important for us to just ‘get in the flow’ and hence we wrote for the rest of the day until dinner. Then we went to the Turkish markets for burek, coffee and fresh pomegranates.

The rest of the evening we re-aligned the index, smoothed it out, and identified a more linear structure. We finished up at about 23.00.

Day three—At 10.00 we started with a brief recap of the new index structure and then we also welcomed two new collaborators in the real-space: Mirko Lindner and Michelle Thorne. Later in the day, when Booki had been debugged a lot by Aco, we welcomed our first remote collaborator, Sophie Kampfrath. Then we wrote, and wrote a bit more. At the end of the day we restructured the first two sections, did a word count (17,000 words) and made sushi.

After sushi, we argued about attribution and almost finished the first two sections. Closing time around midnight.

Day four—A late start (11.00) and we are also joined by Ela Kagel, one of the curators from Transmediale. Ela presented about herself and Transmediale and then we discussed possible ways Ela could contribute and we also discussed the larger structure of the book. Later Sophie joined us in real space to help edit and also Jon Cohrs came at dinner time to see how he could contribute. Word count at sleep time (22.00): 27,000.

Day five—The last day. We arrived at 10.00 and discussed the structure. Andrea Goetzke and Jon Cohrs joined us. We identified areas to be addressed, slightly altered the order of chapters, addressed the (now non-existent) processes section, and forged ahead. We finished at 2200 on the button. Objavi, the publishing engine for Booktype, generated a book-formatted PDF in 2 minutes. Done. Word count ~33,000.

Some months later the book was ‘re-sprinted’ in New York with another group of people. The following contains excerpts from the experiences and voices of those involved:

Over the course of the second Book Sprint, we often paused to reflect on the fact that editing and altering an existing book (one originally written five months prior by a mostly different group of people) is a completely different challenge than the one tackled by the original sprinters. While the first author group began with nothing but two words -Collaborative Futures- words that could not be changed but were chosen to inspire. This second time we started with 33,000 words that we needed to read, understand, interpret, position ourselves in relationship to, edit, transform, replace, expand upon, and refine.

Coming to a book that was already written, the second group’s ability to intervene in the text was clearly constrained. The book had a logic of its own, one relatively foreign to the new authors. We grappled with it, argued with it, chipped at it, and then began to add bits of ourselves. On the first day, the new authors spent hours conversing with some of the original team. This continued on the second day, with collaborators challenging the original text and arguing with the new contributions

If this book is a conversation, then reading it could be described as entering a particular state of this exchange of thoughts and ideas. Audience might be a word, a possibility and potential to describe this readership; an audience as in a performance setting where the script is rather loose and does not aim for a clear and definite ending. (It is open-ended by nature); an audience that shares a certain moment in the process from a variable distance. The actual book certainly indicates a precise moment, thereby it IS also a document, manifesting some kind of history in/of open source and counter-movements, media environments, active sites, less active sites, interpassivity (Robert Pfaller), residues of thought, semi-public space; history of knowledge assemblages (writers talked about an endless stitching over…) and formations of conversations.

The book as it is processed in a Sprint, is a statement about and of time. The reader or audience will probably encounter the book not as a “speedy material”. Imaginary Readers, Imaginary Audience. We came to recognize, however, that the point was not to change the book so that it reflected our personal perspectives (whoever we are), but to collaborate with people who each have their own site of practice, ideology, speech, tools, agency. In service of a larger aim, none of us deleted the original text and replaced it to reflect our distinct point of view. Instead, we came to conceive of Collaborative Futures as a conversation. Since the text is designed to be malleable and modifiable, it aims to be an ongoing one. That said, at some point this iteration of the conversation has to stop if a book is to be generated and printed. A book can contain a documented conversation, but can it be a dynamic conversation? Or does the form we have chosen demand it become static and monolithic?

In the end, despite our differences, we agreed to contribute to the common cause, to become part of the multi-headed author. Whether that is a challenge to the book or a surrendering to it, remains unclear.

  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^

Booki Development Ecology

We are a small team working to change publishing together. Think of an environment where social networking features are brought to bear on the publishing industry. Social Publishing of sorts. That’s us…. Imagine the application for this kind of environment within Schools, NGOs, government, publishing etc. The possibilities are enormous. Now think of an organisation with no employees doing this for love while looking for ways to pay the rent…that’s us!

So we are looking to build a sustainable open source ecology around Booki. This means that we are interested in building relationships with organisations that have a need for Booki, either at http://www.booki.cc or as their own installation. We would like to work with these organisations through either :

  1. contracted programming to extend Booki
  2. consulting on technical issues
  3. consulting on Booki best practices or what the possibilities are for using Booki

In this way we hope to build an ecology of projects working around one code base and helping us pay the rent, buy food, pay for our early retirement plan 😉  In the past we have worked with Archive.org (for extending Booki to proof Archive.org ePubs) and Sesawe.net (for building bi-directional text output for book formatted PDF) in this way (contracted work to extend Booki).

If you see a need for Booki and would like to use it and contribute to the ongoing development of the platform, then please consider one of these possibilities and let us know.

Additionally, we are also seeking funding to help extend Booki, if you know of funding that might be appropriate then please also tell us!

Google Sponsors Book Sprint

FLOSS Manuals فارسی

Google is to sponsor the second FLOSS Manuals Book Sprint.

The event will focus on bringing four free documentation writers together in Paris in July to write a manual on Inkscape, the popular vector graphics software. The team comes from France, The Netherlands and the USA to work together for a week at the Paris Cité des Sciences.

The Book Sprint will also be open to remote (IRC) involvement and the team is especially interested in French – English translators as much of the original content will be written in French. If you would like to participate please contact Adam Hyde (adam@flossmanuals.net).

Pure Data Book Sprint

FLOSS Manuals فارسی

In the first week of April, Luka Prinčič and Derek Holzer have been participating in the first FLOSS Manuals Book Sprint. The Sprint took Derek and Luka away to the beautiful island of Korcula to write a manual on Pure Data.

The idea stems from discussions with Tomas Krag from WNDW, and is based on ‘Code Sprints’. Code Sprints are gatherings organised by free software projects. At these gatherings, programmers spend time working together in an intensive working period to write as much code as possible. The important element is that it is a short intensive burst designed to be fun and productive.

The Pure Data Book Sprint is our first trial of this process and will be soon followed up by an Inkscape Book Sprint to be held in Paris in July

Wireless Networking Book

FLOSS Manuals فارسی

This is a very good book: Wireless Networking for the Developing World

It’s open and free, developed by some people at WSFII.

I met Tomas Krag, one of the writers, at the Open Translation conference over the last few days. The book is very inspiring as a model for the type of sophistication of content achievable in free documentation, and also I found the model they used for creating the content very interesting.

Essentially, Tomas and the other authors met in London for an event. They paid a friend to go on vacation for a week and used their apartment. As I understand it, everyone stayed in the apartment and they spent the week designing the structure of the book and began writing it. The book was then completed with individual chapters written remotely by each other and submitted for editing and layout.

I think it’s a very interesting model, and perhaps one FLOSS Manuals should think about employing for creating material…

At the moment, the book they produced is not being maintained and I asked Tomas if he would consider hosting it on FLOSS Manuals.

Why You Should Love Free Documentation

FLOSS Manuals فارسی

First draft of an article for publication:

Free software has enjoyed many years of support from the cultural sector. Artists and activists have often been active in promoting free technologies. Artists also often make a living through teaching and workshops centred on free technologies they use in their practice. Curators of exhibitions, symposiums and festivals have followed these themes and brought these issues into the public arena. Theorists have published and lectured about the need to use and develop software and hardware which is free. The support has often risen to the point of hyperbole. There were many years when every event seemed to be ‘open’ this or ‘free’ that.

However, it seems that the uptake of free software, despite the efforts, is very slow. Although most of the internet runs on free software (60% of web servers run Apache and 90% of Domain Name Servers run BIND), if we look at operating systems the share is somewhere under 2%  (1).

Free software, as opposed to free operating systems, does a little better with the current estimate for Firefox usage across all platforms coming in at something between 20-30% (2).

Still, this is very small. The user penetration of Firefox is an impressive achievement, but why haven’t other fine tools such as the Gimp or Audacity taken a similar “market” share?

And why, given that we all know how good free software is, that a wide variety is available and that it is free, as in gratis as well as libre, is the uptake so low?

The Free Software Foundation thinks the answer is quite simple :
“The biggest deficiency in free operating systems is not in the software—it is the lack of good free manuals” (3).

Many years teaching free tools (mostly streaming) have taken me to the same conclusion.

It’s not that there is no documentation. Often you can find something, if not on a developer’s site, or in a bookstore, then perhaps comments in a forum, mailing list, or maybe in a wiki somewhere. This seems to satisfy most geeks. Many ‘advanced’ users tell me this is enough. Google is their index, and they know how to use it to find solutions. The thinking is that when it comes to solving a problem in software, you aren’t the first to have the problem and someone somewhere has written down a solution to it. This is often true. If it isn’t true, then either you solve the problem yourself (by hitting your head against the wall until it works), or you find the appropriate IRC channel and quiz the developers. Even better…you’re using open source, right!? READ THE SOURCE CODE!

Well, I don’t know about you, but perhaps my brain isn’t big enough or I maybe don’t have enough time, or maybe, just maybe, I feel that I should not have to be a programmer to work out how to use software. Perhaps this threshold is a little too high and might be deterring users… y’think?

Free software should be well documented. You should be easily able to find out what a software does, what it doesn’t do, how it fits into the software universe, what the interface looks like, how to install it, how to set the most basic necessary configuration, and how to use its main functions. These things should be well explained and kept in a place that is easy to find.

The easier it is to access well-written documentation the larger the potential user base.

I have also often heard that it is simply not the case that there is a lack of documentation. There is a manual for $X! (replace ‘$X’ with your favourite free software). What do you mean!? $X has a great manual!

Well, I admire the effort put into the documentation of some free software. Unfortunately, however, it is seldom adequate.  The most common flaws include :

  • assumptions about the user’s knowledge are set too high
  • bad navigation
  • unexplained jargon
  • no visual component
  • proprietary (‘closed’) material
  • unreadable design
  • steps missing or unexplained
  • documentation is out of date
  • documentation is not easily re-usable
  • documentation is not easily modifiable

These mistakes are very common, and the situation is so bad it amounts to a crisis in the world of free software. I have made my own efforts to combat this situation butmore contributions are needed. Perhaps a clear summary of the basic issues would encourage others to contribute to free documentation projects.

Free documentation for free software

I sometimes feel this is too obvious a point to make. Documentation which is freely available and so ideologically aligned with the [free] software,  seems to me to me to be a natural match.

Practically, however, there are a few hiccups with this idea. Free software has developed a methodology and economy which free documentation lacks. The traditional method of making money in the manual business is to write a manual and sell it. To protect your interests, you use a standard ‘closed’ copyright notice. This is the ruling publishing model. Outside of this circle, you do the best you can voluntarily, and put the content online for others to access, where ever you can.

The Free Software sector has much better resources and models. Free software projects have a number of management tools available including sites like Savannah and SourceForge, and they have established working models. The financial model is much clearer too. Most obviously if you need to make money working on a free software project you get good at it and find a company that will pay you to work on it in-house or by contract.

Free documentation lacks all these components – there is no standard technical tool set, very few ‘communities’ of free documentation writers ,and less chances of being able to pay the rent if you choose to do create such documentation full time.

Finding a way to build these elements is critical to the evolution of a healthy free documentation sector, and, I would argue, to achieving the widespread adoption of free software. It is imperative that we find these models and tools, as closed documentation for free software contains a ideological paradox.

On another point – less ideologically and more practically speaking – free documentation is better argument than closed documentation.   The closed nature of proprietary documentation is a disadvantage: the ability  to update documentation at the same time as the software is updated is a huge advantage. It can thus be updated, modified, improved a la ‘many eyes make bugs shallow’, translated into your own language, or re-contextualised to better suit individual or organisational needs. Free documentation on these terms alone is a better argument than closed documentation, and when done well can be a tremendous asset to the uptake of free software.

Free documentation should be easy to access and easy to improve

If something can be improved then it should be able to be easily improved. Many free documentation projects inherit their technology strategy from free software development methods. These projects store their content in a CVS which means that you need to be pretty technically competent to be able to access the source material and contribute to it.

What this overlooks is that writers are not programmers. Writers have a different tool set, usually word processors, and do not have a familiarity with the typical programming tool set. To expect a free documentation writer to access content via CVS or similar tools is to make the same mistake as assuming the audience for your documentation knows more than they do. Setting the threshold for contributions so high means that many people that could contribute won’t contribute.

There is no need to trap content in CVS. All we are dealing with is text and images and there are plenty of tools that are easier to use.  I recommend a wiki with WYSIWG (What You See Is What Yo Get) editing – these are online tools that look and work like word processors except they are available anywhere you can get online via your browser. I personally don’t recommend using mark-up languages as even wiki mark-up is harder to use than WYSIWYG editors and a barrier to contributions.

Well structured
Many projects are now setting up unstructured wikis for their developers and users to use for writing documentation. Often MediaWiki is used (although the wiki used depends on the winds of software fashion). These resources can be extremely good, however, I believe unstructured wiki content with a contextual navigation system, is a poor substitute for well-structured content with a clear top-level index. Unstructured content is a good secondary documentation strategy, and certainly good for documenting the ‘nooks and cranies’ of sometimes archaic interface issues or strange hardware-specific conflicts, however, it doesn’t replace content that is designed to document the software thoroughly with a clear and structured flow.

Tell it as it is
I have found that documentation written by developers makes the simple mistake of writing how the software should work and not how it does work. Writing free documentation should not be done from memory or by those that cannot see the problems. Telling the user what is wrong with the software, what does not work, what could be improved, is absolutely necessary. It’s not bad-mouthing a free software to point out a quirk that should not be a quirk. It is far worse for potential users of that software if the user reads documentation that is inaccurate or which glosses over these issues.

Make it look good
Documentation should be attractive to read. Free software developers have discovered over the years that in order to interface with humans, software must look nice and allow the eye to easily engage with it. The same is true for documentation. Black text with blue links on a white background is not enticing. Embrace a layout than enhances readability but makes sure it also looks good.

Quality
Now we come to the bugbear. Quality. What is good quality documentation? Well, there are some mechanical benchmarks :

  1. no spelling mistakes
  2. set a style guide and stick to it
  3. make sure no steps are glossed over
  4. make sure the documentation is accurate

However, beyond the mechanical there is the subjective issue of quality. There is no solid rule: the best you can do is to get people to read the content and tell you if it makes sense. If you belong to a community of contributors then look to peer reviews.

FLOSS Manuals and the Pursuit of Funky Docs

It is easy enough to point out what is wrong with something and harp on about how it should be. It’s another issue to actually do something about it.

To resolve this, I am involved in a not-for-profit foundation called FLOSS Manuals. We are a community of free documentation writers committed to writing excellent documentation about free software. Anyone can join FLOSS Manuals and anyone can edit the material we publish. All content is licensed under a free license (the GPL).

When we started (the actual point of genesis is hard to determine but we officially launched in October 2007), there was, and still is, no good publication platform for collaborative authoring. Some may say that there are too many Content Management Systems already and surely, SURELY, there must be a CMS to meet our needs?

Well, no. The closer you get to identifying the needs of collaborative publishing systems, the further you stray from the functionality of most Content Management Systems. So we have hacked our way into the wonderful TWiki and developed our own set of plugins. TWiki has proven to be a very good platform for online publication. It has all the structured content features and user administration that make it a good shell for authoring collaborative content. What was missing, and what is missing from other CMSes is good copyright and credit tracking, easy ways to build indexes, and a nifty way to remix content.

However, we have remedied that now with our own custom plugins (which are available through the TWiki repository). There are still some things we need, in fact it’s quite a long list, but piece by piece we are turning TWiki into a publication engine. Currently, we are working on translation workflow features (also in plugin form).

Remixing
So, the word ‘remix’ may have caught your eye and you may have fleetingly thought ‘remixing manuals?!’. It might not seem intuitive at first glance but there are a lot of very good reasons why manuals are excellent material for remixing. I don’t mean remix in the William S Burroughs sense of cut-up… we do cherish linearity in the world of free documentation. I mean remix as in “re-combining multiple chapters from multiple disparate manuals to form one document.” Doing this enables you to create manuals specific to your needs whether they be for self-learning, teaching, in-house training or whatever purpose.

The FLOSS manuals remix feature (http://www.flossmanuals.net/remix) enables the remixing of content into indexed-PDF and downloadable-HTML (in zip or tar compressed form) with your own look and feel (CSS). Now we have also added a Remix API. This means that you can remix manuals and include them in your website by cutting and pasting a few lines of HTML – no messy ftp necessary…

This part of FLOSS Manuals is new and in test form, but it works very well and the possibility for combining remix with print-on-demand is an obvious next step. It can be done now as print-on-demand services use PDF as their source material, but the trick is in getting it to look nice in print form…

Print on Demand
In addition to the free online manuals FLOSS Manuals material is also turned into books via a print-on-demand service. The books look very nice, having been tweaked to look good in print, and they are available at cost price (we don’t put any mark-up on the books so they cost what the print-on-demand company charge to produce and send to the buyer). This is pretty exciting and I hope that we will soon see FLOSS Manuals on the bookshelves of retailers: bookshops after-all are a very important promotional venue for free software.

I find that the books themselves actually get the idea of what FLOSS Manuals is doing very effectively to most people I talk to. Imagining a website is one thing, but handing over a book sparks the understanding and gets people excited. So books are an excellent promotional medium for FLOSS Manuals as much as for the software (it’s a symbiotic relationship after-all).

I imagine print-on-demand will play a bigger role in the future of FLOSS Manuals. There are many possible paths, but, in the end, it comes down to capacity and we are this stage a very small organisation. If you wish to get involved with this (exciting) part of our evolution then let me know…

Quality Control
Lastly, a word on quality. The manuals aim to be better than any available documentation (sometimes this is not hard as there is often no other available documentation!) Keeping this level of quality has some interesting issues when working with an open system. Anyone can contribute to FLOSS Manuals – it is completely open. You need to register but this is not a method for gating contributions, it is there so we can abide by the license requirements of the GPL to credit authorship. Additionally, credit should be given where contributions have been made so we also credit modifications in the manuals.

SPAM is an obvious issue with an open system, as is the possibility of malicious content. Incorrect or malicious information in Wikipedia might lead you to quote the wrong King of Scotland or may misinform yo7u about the origins of potatoes, but incorrect information in documentation might lead you to wipe out your operating system. So we separate the ‘back end’ – where you can write manuals – from the ‘front end’ – where you can read manuals.

Manuals in the ‘WRITE’ section (http://www.flossmanuals.net/write) are in constant development. However, the same manual linked from the front page will be in the ‘stable’ form. This is managed by some existing TWiki tools that we twisted together to form a simple one-step publishing system. It works like this – every manual has a Maintainer. A Maintainer is a person – a volunteer – that keeps an eye on that particular manual. Edits and updates carry on through the WRITE section by anyone that wishes to contribute. When the Maintainer thinks the manual is in good form and an update is appropriate, they push the ‘publish’ button and all the material is copied to the ‘front  end’ version of the manual.

This way, the reader gets stable reliable documentation, and the writers can continue working on those docs without the reader being confronted by half-finished content etc. It’s a simple and effective system.

How you can help
Good free documentation is a necessary component of all good free software. If you can’t program or don’t want to, but you love free software and want to help, then help make free documentation!

Knowing where to contribute is now easy! You can :
read manuals – http://www.flossmanuals.net
write manuals – http://www.flossmanuals.net/write
or remix manuals – http://www.flossmanuals.net/remix

We have a growing number of very talented contributors and Maintainers and good manuals available online, but we need more manuals and more contributors. Contributing is pretty easy, and if you would like to be a part of helping create good manuals, then register with the project (http://www.flossmanuals.net/register) and read our manual on FLOSS Manuals (http://www.flossmanual.net/flossmanuals).

Anyone can contribute. You can spell-check documents, tidy up the layout, suggest ways of improving docs, test/review material, design icons, write or improve any material. Contribute in any way that you can and you will be helping not only to make the documentation better, but you will be assisting in the development and spread of free culture and free software.