Xerography—every man’s brainpicker—heralds the times of instant publishing. Anybody can now become both author and publisher. Take any books on any subject and custom-make your own book by simply xeroxing a chapter from this one, a chapter from that one—instant steal!"   Marshall McLuhan, The Medium is the MESSAGE

This vision from McLuhan is of an analogue future. A future of analogue media and analogue networks. It would take digital media to realize his vision. Webpages being the networked document of our time enable the kind of instant steal that McLuhan foresaw. With free content licenses and simple tools for importing content from other books or other libraries, we can borrow enormous amounts of rich information to help us build the books we want. 

In a recent Book Sprint on Basic Internet Security, 9 chapters from 3 existing manuals were reused – that was 15,000 words that we did not have to create afresh. 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 in the time we had.

This was really quite amazing for me to see. The idea of reusing content was envisioned 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 waiting 3 years, I took a great deal of pleasure in seeing it happen for the first time.

Re-use is not just a time saver, however, there are many other exciting possibilities enabled by re-use. Re-use is also about translation and recontextualisation. Re-use is about updating books and improving them. Re-use is about taking content and making it work in your language. Re-use is about enabling anyone to get your content to their audience and in the form they need it. Re-use is also about allowing you to re-use your own work, since often publishers hold the copyright and do not permit authors to update, re-use, or improve their own work.

Re-use helps you make the books you want to make faster and get them to the people you want to have them in a form that suits them best. 

Re-use, despite its attractive opportunities, is an issue that existing publishing models are going to find very hard to work with. This is because full engagement with re-use leads to the federation of content and the inevitable possibility that anyone can publish any book you have made. Taking a book, not changing a word, marketing it and selling it, is re-use. It is going to be difficult for publishers to agree to this consequence while tapping into the many opportunities for new business models around this idea. But that is not our problem. We want books to be freely re-used and we should find the most open channels to do that. 

The core of re-use is primarily about extending the usefulness and life of a book. 

One of the differences between a book and a newspaper, is that we expect longevity from a book1. We expect a book to have value beyond the date printed at the top of the page. 

The web offers enormous opportunity for the life of a book to be increased further than it is now. The Open Educational Resources (OER) movement is alive to this idea. They imagine you could take a mathematics text book and update it for the following year’s curriculum, or combine it with another book to better suit your students’ needs. Or correct it if you found a mistake, or translate it. Major advantages in all sectors, not just education, can be attained by keeping books alive. 

Books currently have too long a life as a static object. They have become too static as a result of Gutenberg’s invention. ‘Static-ness’ is now a part of a book’s genetics. ‘Readers’ find it even hard to pick up a pen and write notes in the margin of books. Margin notes are frowned upon by libraries. We have forgotten that notes like this (‘marginalia’) were once very common. When paper was hard to come by, the margin notes were often where books were written.

So books did not always have a static genetic code. They once were places for lively discourse and for book production itself. 

Interestingly, there is a kind of slow historical regression taking place because of digitally-networked media. There are a few projects (notably commentpress2and the yet to be released Social Book by Bob Stein, and some ebook readers) that enable types of margin notes in digital books. In the case of Commentpress these notes are the point of the book – a place to start discourse (almost literally) around the book.

However, we still cannot seem to embrace changing the book itself.  It is one thing to allow ourselves to leave margin notes in this new era of digital documents, since we know the source will not be affected. We can easily spray comments around the book as the book itself stays intact. Can’t we allow ourselves to change the book too?

Books have always been changed over time. Ben Fry did a very nice visualisation3 of the changes Darwin made to his Origin of the Species over 6 editions. It is a nice work showing substantial changes, including the addition of an entire new section in the last edition. The Origin of Species was an evolving thesis and the book was kept alive over the period of Darwin’s life. The book’s ’life’ ended with Darwin’s. 

But why must a book die with the author? Why can’t anyone contribute to a book to keep it alive, even during the life of its author? We feel somehow that this is breaking some kind of moral law (as well as copyright law). Forgetting copyright for now – why not improve the original? Why can’t we take a book, any book, and improve it, perhaps even while the author is still alive? Why is that idea so difficult for us to engage with?

Leaving copyright licensing aside for the moment  – one part of the puzzle involves the overly rarefied respect for the authoritative version. The version born from the author. We (you or I) are not that author and so we cannot know the author’s intent with all its nuances. We should not meddle with a work because we would be breaking our unspoken contract to preserve the author’s intent. It would not be considered an appropriate thing to do. We do not have the authority to do it. The authority is inherent in the author alone – so much so, that the role of the author to the book is analogue to the role of ‘god’ to its creation. The author is the creator.

Sound like I am overstating the cultural value of the author? In William Golding’s Lord of the Flies, the children use Piggy’s glasses as a magnifying glass to start a fire. However Piggy was short-sighted and hence starting fires with his glasses would be impossible as they are concave, and concave lenses disperse light4 . You cannot start a fire with concave lenses. Would we allow anyone to alter the book to correct this rather trivial fact? No. No, because the book is Golding’s world and in Golding’s world concave lenses start fires. Golding is the creator. He has the authority to change his creation and we do not.

I think that is a very deeply ingrained principle.

For this reason, many recoil in horror with the prospect of changing great works of art. We are in some way tampering with the mind of the creator – a kind of god. However, we must remember that if we change a book, we change nothing in the original. Books, unlike paintings, are not one-of-a-kind pieces. That is precisely why the age of Gutenberg has such an impact – books could be duplicated. So when we change a book (I’m not talking about historical paper artifacts, just the abstracted contents) we don’t destroy anything, and this is particularly true in the digital age. In fact, the digital age gives us more tools to take care of the provenance of a work. Hence we can easily have Pride and Prejudice by Jane Austen and Pride and Prejudice and Zombies by Jane Austin and Sethe Grahame-Smith5 . 

How to we develop a culture where it is OK to change a book? Free Licenses are meant to change that but in my experience it is still difficult to get people to take hold of explicit free license clauses that enable derivative works and improve a work. They feel they lack the mandate to change. Many people still ask if they can improve a free/open book work even though the mandate to change a work is loudly passed on and articulated by ‘the creators’ to anyone.

In fact, it is difficult to pass on the mandate to change. It doesn’t help that large projects like Wikipedia are working against this mandate. Wikis and Wikipedia have managed to introduce ideas of participative knowledge creation, but as Lawerence Liang6  has argued, Wikipedia is possibly trying to establish itself as an authoritative knowledge base which also has the effect of revoking the mandate to chang,e as has been experienced by many new contributors that find their edits reversed.

I think we will leave this all behind in time, but it’s going to be a long time.

All books can be improved – even the most sacrosanct literary works. However we live with the notion of the authority of the creator. The only thing that can change that, is to take the rights afforded to us by free licenses and experience and value the possibilities open to us if we act differently.

We need living books, and under copyright we have to fight very hard to keep them alive. The first step it to take someone else’s book and improve it.

  1. Daniel James^
  2. ^

Community Building and FLOSS Manuals

FLOSS Manuals community in action.
FLOSS Manuals community in action.

In 2006 or so I started FLOSS Manuals (FM – the old www archive is here). Essentially I got back from Antarctica and wanted to give up the art world. I didn’t really know what I wanted to do but I wanted it to be a challenge. I also wanted it to be something I built from the ground up. So, I imagined that making the biggest collection of freely licensed manuals for free software would be a good challenge, and along with that a comminty of software documentors. At the time, the state of free documentation was pretty poor with individual projects generally having little or no docs (with a few exceptions).  There were also some old school approaches around, such as the Linux Documentation Project, and proprietary approaches like O’Reilly Media. I respected both but wanted to see free quality manuals out there.



FLOSS Manuals icons.
FLOSS Manuals icons by Lotte Meijer.

This was actually a strange time for documentation. Books still reigned and docs were those things you did when you got time. This created very strange dynamics at times. For example, being ‘the author’ of a book about software that was published (particularly) by O’Reilly made you crown prince(ss) of that project. You were then a star. Many projects, believe it or not, saw this as the only way to make money. They saw publishing as the revenue model. The result of this was that I was often chased away from projects because there was some self-appointed guru who had not yet written the book and they didn’t want FLOSS to steal their fame and thunder. This was really frustrating. I found it particularly frustrating because  I knew that authors who were published generally made little or nothing unless the publication was a blockbuster (which was very rare).

We were patient with these projects. As the years wore on, some software producers acclimatized to the new state of docs on the web and came to be ok with FLOSS Manuals writing (much needed) docs for their projects.

I had some material I had written during a period when as an artist I led workshops about free software t (I traveled the world teaching free software, particularly those softwares related to streaming and sound).  I needed somewhere to house the material, and then I needed to build a community of contributors who would add more docs as well as improve the existing ones.

Hence I started FLOSS Manuals. The first thing I did was build the technology, as I have explained elsewhere. I then put the docs on the new platform and waited for the hordes to come. Of course, they didn’t come. Ah…. I thought, someone forgot to tell me you have to build community. So I went about promoting FLOSS Manuals. Still they didn’t come. Not one. Then I started making more docs to make the site look active. Still no one. Then I registered accounts under many aliases on the site so it looked like there were more people than me at work. Then I waited.

It took quite a while. I don’t actually remember how long, maybe 6 months or so, before I got my first ‘anonymous’ bite. Some nice chap registered on FLOSS Manuals and made some improvements to a manual on Pure Data (Pd). I remember being so crazy excited. At last! I did some homework, trying to find out who this person was. I was so excited, I wrote to them and gushed. Of course, that scared them away and I never heard from them again. Ha!

FLOSS Manuals icons in felt.
FLOSS Manuals icons in felt.

I went back to writing and promoting. Slowly, slowly, the community built up. I can’t remember that period well enough to suggest much secret sauce for the initial moments. These are the most critical moments as each little bit contributes to bringing a community to life. I remember some key characters that got in early and helped bring in others.  The wonderful Mancunian, Mick Fuzz, was one such person – he was the first guy I met that thought documentation had as much potential power as I did. That was liberating and validating for me and I was excited to meet him.

Mick Fuzz far left.
Mick Fuzz far left.

I remember Anne Gentle, a technical writer from Texas who was always looking to discover new ways to make docs. Also Andy Oram from the O’Reilly Boston office gave me lots of encouragement and promoted FM. Janet Swisher (now at Mozilla) helped spread the word a great deal too, and there were many others. These were central characters that formed the basis of a community, the fundamental roots of the organisation. I should say that most likely I didn’t find them, they found me, which speaks of the need to be out there and be seen but also, in order to be taken seriously I think you have to have something to show. A starting point that others can build on.

Andy Oram second from right.
Andy Oram second from right.

At the time I was very sold on the benevolent dictator model. I didn’t have any other models to play with really. I did have community building experience fro my time as a manager of radio in NZ, and from my time as an artist. But I wasn’t sure what I could use from past experiences.

I think I was probably a little over zealous at first. We had a common mailing list and I think I moderated it well but probably I was more focused and engaged than necessary at times.

Janet Swisher, far right.
Janet Swisher, far right.

I learned a lot quickly, however. For example, I became very good at redirecting noisy, distracting, traffic.

Several issues came up over the years that were just a sinkhole for wasting community energy. One such issue was the ongoing blahblah about licensing of the material. FLOSS Manuals required all contributors to agree to licensing under the GPL. For those that don’t know, the GPL is actually a content license, worded to look a little software-specific. Don’t trust my reading of this, but do trust me when I say I talked to many many lawyers and experts on this and they all agreed. The only people that I found that didn’t agree were those that knew little about licensing and those were, unfortunately, the people that ended up on the list. The other problem people had, was to do with the Free Documentation Licence, which is one of the most unfree and ridiculous licenses ever made. FM first used the FDL, as after all, it was made by the Free Software Foundation – the same people that brought us the GPL. So, if it comes from the FSF and has the words free documentation in it, then it must be all right, right? Wrong. As I later discovered, the FDL was written by the FSF when they thought their business model was going to be selling books. Those were the days. The FSF also thought that O’Reilly had stolen their business model and they were pretty annoyed so they made their FDL a very very defensive license. It effectively stops any reuse of the material. It is a terrible license (which is why Wikipedia also got out of using it, but that is someone else’s story to tell).

At first, I used to be very dismissive of these license conversations. I was so sick of following them on the list, I tried to ignore them or stop them. Then I wrote an article about it. Eventually, I set up an additional licensing mailing list just for FM license discussions. I would encourage anyone that jumped into the main FM list talking licensing, to join that other list. I wasn’t subscribed to the FM license list, so it went on its own merry way and it didn’t slow the rest of us down. That was pretty effective.

Another issue that had the real potential for overriding community energy and tiring everyone out was the topic of One Laptop Per Child. At this moment OLPC was more like a religous movement than a technical endeavor. FM had done all their docs and they were distributed via an FM app on the OLPC. That was pretty cool really, and there were a lot of great people in the OLPC family. But the OLPC movement had the ability to also attract real Class A zealots. These were well meaning people, people who actually wanted to change the world. But they could go a ‘little’ too far down that road to the exclusion of all other concerns. This had the effect of derailing any conversation and was a major factor in lowering community energy. I had to work on the sidelines to corral those folk. There weren’t many, but they took some work. Staying positive and constructive was key.

Still, we did write a lot of material about the OLPC. We even had a number of pretty awesome Book Sprints about how to use the open source Sugar operating system it ran on.

Writing the OLPC docs in Texas. Anne Gentle far right.
Writing the OLPC docs in Texas. Anne Gentle, documentation guru, far right.

At the time, I read as much as I could about community building. However there wasn’t that much I found useful. I liked Karl Fogel’s Producing Open Source, and Jono Bacon’s The Art of Community. But much of what I read was about software development, not content development. It helped but not a great deal. I also mined the MIT archive on research about open source-related topics. At the time I think it was maintained by a buddy (Mako Hill) and it contained a lot of material about Wikipedia since that was the hot topic of the time. Still, not much helped. I also attended Wikimania a few times as the Wikipedia community seemed to be the most obvious source of information about how to build open content communities. The Wikimanias I went to were awesome and I learned a great deal talking to people. Of particular help was Brianna Laugher, Erik Möller and a few others. I also loved many of the presentations including one of my all time favorite presentations by Lawrence Liang on the authority of knowledge vs collaboration (which he later repeated at an Amsterdam conference and which is available here).

In short, I was hungry for information and tried to become the expert on building community. Any tool I could use, I wanted to know about.

As it happens, things worked out and FLOSS Manuals became a thriving community. The English community spawned a French community and both are still active. There was also (briefly) Finnish, Farsi, and Dutch communities. We did actually have a lot of material translated into (if I remember) about 30 languages but these were all ‘one offs’ and no language communities other than those mentioned above got off the ground.

French FLOSS Manuals crew.
French FLOSS Manuals crew.

I think I learned a lot from this period of my career. So what remains with me? Well, in terms of suggestions about what is important in building community this is what I have left off the top of my head, I hope it might be of use to someone:

  • have a starting point. Something others can join.
  • make the mission clear and simple. Make sure you feel that there is the possibility others will share the same point of view (even if you have to go out and find them).
  • don’t be a benevolent dictator. The longevity of a project means that there must be shared leadership. Otherwise, if you leave, it will fall apart.
  • take all the hard tasks away from the community and leave the easy, fun, stuff for the community to do.
  • do what you can to keep the community focused on the mission. Don’t allow distracting energies to override the community.
  • celebrate individuals in the community in public as much as you can
  • jump in to help as quickly as possible if a community member needs you.
  • work shoulder-to-shoulder with the community as much as you can.
  • find your protagonists, these people are in themselves community-building catalysts. Bring them in and make them feel at home.
  • make the efforts of the community as visible as possible to those it is trying to benefit.
  • be generous in attribution, including attribution for projects that are competitive to yours.
  • get out there and present the project in as many forums as you can.
  • internal energy is a product of engagement with others on the same mission, perceived momentum, and utility in this kind of community. You have to make these later two visible (momentum and utility) to your community to generate the former (engagement).
  • be careful not to overload people with your own enthusiasm.
  • as one of the leaders, it is all about you, and it is not at all about you.
  • communicate loudly and clearly the pride you have for the project and the pride you expect others to have in the project.
  • be careful with extrinsic incentives, they might not get you what you want.
  • don’t hold ‘what you have’ too close. Let it go and let it have its own life in the world.
  • don’t get discouraged if other projects, especially bad ones, get funding and support when you don’t. Stick it out.
  • forget about the competition, just do what you do well.

And as a happy coincidence, I found this advice I wrote somewhere between 2010 and 2012, which seems pretty right-on. It’s written from the perspective of managing a community of contributors for a book but it is obviously deeply informed by my experience building the FLOSS Manuals community. From:

Once you are up and running, energy needs to be put into the ongoing growth of the contributor base (assuming you haven't hit capacity) and energy needs to put into keeping the current contributors active and involved. Again, drawing a parallel between book development and code development - many open source projects have fulltime community managers. Jono Bacon1 is one such person - he is the community manager for Ubuntu and wrote the excellent Art of Community Book2 which is well worth reading -  but please keep in mind that book community management doesn't map directly onto free software community management.
Keeping the contributors involved can be a great job but it also has some gnarly issues. The vast majority of the work is social and some logistics - making sure that the technology for contributing is working and is not a burden for example. You might not have to do any tech work yourself in these cases but you will need to find the person who will. One thing that has almost universal value in this role is the ability to keep a one-to-one interaction feeling with active members of your community. You are a central pin in the entire mechanism and people like to be close to the action. Keep communicating with people, keep them talking, put them in contact with others working on similar issues, expand their network, in other words - keep it social.
In addition to this, another secret ingredient is fun. Don't make the mistake of taking things too seriously, and if you do, make sure that others don't see it. It's ok to blow your top occasionally - its actually good to be seen to be fallible -  however you should apologise as soon as possible and get the good feeling back in the air. For the most part, however, it is very important that the community enjoys the ambiance - it might seem an intangible 'fun factor' but its more likely that its carefully engineered by you than it 'just happens'.
Another very important issue is learning when and when not to channel attention and requests to members of the community. Those that are active will become natural pivots on the center of your community and it can turn into a burden for those core individuals if not managed with care. Make sure you are keeping an eye on their frustration levels - if you see they're getting too much of a load, put on them by normal community processes then you may need to step in and redirect or take on some of that traffic.
These core members are very important to the health of the project but don't be disappointed when they leave. Communities have natural cycles and, additionally, community members have other lives. When they inevitably move on, make sure you acknowledge them in front of the community - this is not only a good thing to do, it will relieve any disappointment you may feel and it will signal to the community that everyone is respected and valued as individuals - not just as production engines.
Also keep in mind that although natural hierarchies will evolve, it is quite important to keep the community in an egalitarian mindset. All contributions should be valued and all contributors should be valued. That also means that you must keep the balance of power even. Core contributors will naturally get more say in how things go but ensure that channels are open for all voices in the community to have their say. It is also for this reason that it is not a good idea to bring any publishing world hierarchical structures to community management. Don't think of editors and writers, think of collaborators and facilitators.

If people are enjoying themselves and enjoying the social environment, they are of course not necessarily being productive. My experience is, however, that people involved in this kind of project generally like being productive. If they are talking its usually a sign they are working.


Crazily, you can still buy the manual on FLOSS Manuals we wrote in 2008, here!