Federated publishing takes all of the concepts I have dealt with so far – ease of online book production, collaboration, reuse – and applies them to a new networked model of publishing.
In the social software circles, there is a movement that advocates a Federated Social Web. The main advocates are ostatus and the free software micro-blogging platform status.net. The Federated Social Web is a vision of inter-operable social network platforms enabling “people on different social networks connect with each other as friends and colleagues,” says Evan Prodromou.
Federation of this kind is not new to the web, and there are many online services which work like this. Email is a federated system – it doesn’t matter where you have your email account, you can still communicate with other people who have email accounts elsewhere. However, federation of this kind is not the architecture of choice for monopolistic social network enterprises like Facebook. Facebook will not enable you to install your own copy of Facebook for your business or school, nor does it enable communication between users on Facebook and users on other social networks.
What we need is a federated architecture for online book production and publishing. Anyone should be able to set up their own online book production/publishing service and share books with other book production/publishing networks, enabling anyone to reuse any book, anywhere.
Federated publishing supports traditional, established book production techniques while fueling radically different approaches. To achieve healthy federated publishing on the web, four key elements need to be built up:
Fee content
Federated book production platforms
People participating
Suitable economic models
There is currently no prolific exploration of this model. Federated publishing is currently only illustrated, I believe, by FLOSS Manuals. In FLOSS Manuals, anyone can clone or migrate a book to another platform, reuse and change the book without permission, and publish it wherever they like. That is federated publishing.
Federated publishing was anticipated by this astonishing passage from Marshall McLuhan in Predicting Communication via the Internet (1966), in an interview with Robert Fulford, 8 May 1966, on CBC’s This Hour Has Seven Days):
“Instead of going out and buying a packaged book of which there have been five thousand copies printed, you will go to the telephone, describe your interests, your needs, your problems, and they at once xerox with the help of computers from libraries all over the world, all the latest material for you personally, not as something to be put out on a bookshelf. They send you the package as a direct personal service. This is where we’re heading under electronic conditions. Products increasingly are becoming services.”
This passage is usually quoted as a prophecy of the Internet to come. However it is not a vision of the Internet, rather a vision of the book-as-service through federated publishing – an open network of book production platforms connecting people and books.
In contrast, proprietary publishing dominates the search for new distribution formats and economic models, reward systems for authors and others, and fuels an unwillingness to make content interoperable on a technical, legal, or social cultural level. It was this context McLuhan imagined we were escaping.
Through collaborative publishing projects, we have found that not only is federated publishing highly productive, exciting, and fun but there are also economies evolving around it – organisations and ‘crowds’ pay to have books produced this way, and they pay you to help them to do it.
Around 1460, the entrepreneur Johann Fust (commonly confused with Johann Faust) took some of the Gutenberg bibles to Paris to sell. Paris did not know of the printing press and rumours started. How could someone produce so many books so cheaply? How could they possibly be made so quickly and with the exact same rendering of all characters on all pages? The apparent ease and speed by which these books were produced had the feeling of witchcraft.
It’s a good story and a popular one, although it might actually be apocryphal. It seems, according to Elizabeth Eisenstein [see The Printing Press as Agent of Change, Cambridge University Press 1979, p50] that at that time, the “increase in output did strike contemporary observers as sufficiently remarkable to suggest supernatural intervention.” This story helps us imagine how Gutenberg’s Press changed the world forever, simply by making the production of books easier and faster. Before this, books were created by scribes copying the content by hand – a process which took tremendous time was prone to error and was very expensive. The newly invented printing press meant books could be made quick and cheaply. As a result intellectuals and artists were starting to work closely with printers, print shops became places where these people would meet and where knowledge started to cross disciplines, publishers eventually evolved, the economics surrounding knowledge changed, book production was made accessible to a vastly larger section of society, literacy increased, and knowledge was transmitted across societies and boundaries in ways previously unimaginable. Making books easier and faster to produce changed everything.
Because books are now web pages, book production again becomes easier. All the tools required to produce beautiful books can be accessed through a browser. ‘Web-based workflows’ for book production begin with an empty book and take you through the entire book production process without needing to leave the browser. Easy-to-use tools take you through this workflow and in so doing they change every part of book production. The book becomes something you can make, not something that publishers make for you.
This ease of production is assisted greatly by the development of online print-on-demand services and ebook distribution channels which integrate APIs. An API is an ‘Application Programming Interface’ – jargon for a technical process that enables websites and online services to integrate and work together. Using APIs, you can utilise the services from another website in your own webpage. For example Lulu.com – one of the world’s largest online print-on-demand services – allows you to upload books directly to their service from your own website. That makes web-to-new book production models and print workflows a whole lot easier and faster. Ebook distribution services are also offering APIs so platforms can push ebooks directly into their channel.
Book production coming online means new book production models can evolve and new kinds of publishing can emerge. Book production can become faster, publishing becomes something anyone can do, people from all over the world can share distributed workflows and work on the same content simultaneously. Book production is open to more people, and anyone can produce an array of books from best sellers to niche texts. Peer production markets of skills and knowledge can ben generated to enable the production of the books we want – faster, cheaper, and better than the current state of publishing.
Book production platforms to enable these advantages are just starting to appear. Wikis were, and still are for many, the default knowledge production platform and have been used many times to make books. But Wikis are not designed for making books. Not only do they do this badly but they do not foster a ‘book writing’ mindset. Wikis tend to be used for short form texts and often as a kind of textual mind map. Wikis do not deliver the ease of production we are looking for.
The same is true of blogging software. Blogs do seem to build a culture of slightly longer and more structured narrative forms which does help but blog software is not intended for producing books either. It is intended for producing another kind of text. It’s true that blogs like WordPress can be bent into many shapes and WordPress is often considered by many to be a Content Management Tool rather than a blog, but at the end of the day, building a non-blog becomes more work using WordPress than if you had chosen a tool built for that purpose.
Essentially Wikis, Blogs, and CMS all have very specific roles. Bending them to fit book production may work for a while, but they lack the possibility to richly explore online book production because they were not built to do this. They might be a useful shortcut for rapid prototyping but their inherent paradigm will soon get in the way. If you want to do something, then it’s usually more effective to use a tool built for that purpose. Additionally, it’s not just the tool’s purpose that counts: the culture surrounding how the tool is used is also important.
Having used a wiki to build a publishing system, I can say from experience that we soon ran up against core design principles of the tool that made it hard to make it do what we wanted. We could do all the basics but when we really started working in an immersive way with online book production, we found that there were many issues that a wiki could not handle without significant re-development of its architecture.
When building a software for book production there are some features and issues that need to be considered as part of the core paradigm. First – any platform operating in the world of open or federated publishing MUST be open source. Open content on a closed platform is a hypocritical position. You deserve to be skeptical of any platform like this and its relationship to you, your privacy, the ownership and control of content, the distribution paths open to you etc. Beyond the primary necessity that the platform must be open source there are 4 key features that should be easy to manage :
it’s easy to create a new book
it’s easy to add and edit content
it’s easy to manage the table of contents
it’s easy to export to a book format
These are the basic 4 necessary ingredients.
Beyond this, there are some very important issues that need to be managed, either in a second tier of interface or done ‘automagically’ using default settings or presets:
copyright license management
attribution
well designed output
That gets you to a basic ‘plain vanilla’ online book production environment. Of course it looks easy but it’s not. Realizing this simple vision is pretty easy if you wish to produce EPUBs. However, if you wish to support multiple output formats, it gets trickier. Paper books are especially tricky because you have to deal with the page – a real paper page. Paper pages need left and right margin control, page numbering, accurate linking of the page numbers to the table of contents, and not to forget bi-directional text rendering and widow and orphans control. Not only are these not very simple issues to resolve technically they are also offer very many questions about usability. How many of these options/parameters do you manage ‘by magic’ and how many (and how) do you expose to the user to control? This is when the going gets tough.
We are seeing a few online platforms evolve that are embracing some or all of these notions. The variety of feature sets and strategies is large but the following three online book production platforms are the ones I believe have the highest claim to having a stake in the game to date :
PressBooks – a service started by Canadian Hugh McGuire who had previously experimented with a book platform called the Book Oven (which is now closed). PressBooks is based on WordPress and has a good workflow if you are familiar with the popular blogging tool. Unfortunately the platform, while built on top of an open source software, is not open source software. It is a free (gratis) service but closed source. PressBooks does not currently hold high collaborative potential but it is very useful for writers who wish to work with an editor or editorial teams to compile anthologies. PressBooks is focused on extending the traditional publishing cycle online. The development team is spending a lot of time working on good formatting for book-formatted PDF. PressBooks also targets the web as a book output.
Inkling – a service which is free to use but all content must be sold through the Inkling sales channel. Inkling derives a royalty for each sale through this channel. It is closed source and targets the iPad and the web as output formats. Inkling is targeted at textbook publishers and sells content in the form of books and chapters. Inkling is not open source and is targeted at traditional (but distributed) online publishing workflows for traditional publishers.
Booktype – of the three listed here, Booktype has been around the longest – formerly known as Booki and originally developed by FLOSS Manuals, it has been around for almost 6 years in various functional prototypes. Booktype is now developed by Sourcefabric and is open source. Booktype has a very flexible workflow which is ‘native to the web’ and is designed for non-publishers and publishers alike. Booktype can be a highly collaborative environment and is the platform of choice for rapid development processes such as Book Sprints. Booktype outputs to web, iPad, Kindle, print-on-demand, text document formats, PDF and many other formats. (Disclaimer : I am the project lead for Booktype).
These three are the 3 best platforms on the radar for easy online book production right now. The web being what it is, means there will be more to enter the market and this will probably happen quickly. The iPad iBook Author is not mentioned here because although easy to use it is not an online tool and I believe this is a critical missing feature for reasons that will become clearer later.
I believe these three outlined above change the game and interestingly have their own distinct primary use cases and strategies. There will be more to come. If you believe Gutenberg’s efficiencies changed society forever then what effect will tools like these have? It’s a giddy question and from working with book production like this for 5 years now, I firmly believe making books in the browser is not just a matter of having an easy way of making books – it will have an enormous impact on society as a whole.
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 Bacon is one such person – he is the community manager for Ubuntu and wrote the excellent Art of Community Book 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 that will do so. 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 networks, 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 – this might seem an intangible ‘fun factor’ but it’s more likely that it’s 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 that redirection to them 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, so don’t be disappointed when they leave. Communities have natural cycles and, in addition, 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, so 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 that people involved in this kind of project generally like being productive. If they are talking, it’s usually a sign they are working.
First step towards managing the social fabric around a book, is to see the book as a community. It is a living body of text and people, and your job as a community manager is to keep it alive and help it flourish.
The vast majority of this role is managing the social processes surrounding the book. This means putting energy into people so they will put energy into the book. At the beginning, it is necessarily a 90% lossy conversion of energy! 90% of the energy you put in will see very little or no return. But that 10% that makes something happen is a foothold and that’s enough to help you build up a successful community around the book. These small successes build up and it is possible, in time, to walk away from the book and it will continue to grow by itself.
It might sound hard, and it’s not always this way, but it ismostly this way. The same is true for the development of open source code communities – simply putting the code in a source management repository does not mean an instant community will turn up and write the software for you. Source code repositories like Sourceforge and Github can be seen, to some large degree, as graveyards for thousands of projects that started and died quickly through the founder’s lack of a real understanding of how to build communities.
There are some ways, of course, that you can improve the odds. The first is by starting a book project that you just know there is a huge need for, or something people are justgoingto get excited about – then announce it through the available channels. If people are out there just waiting to contribute to that x factor project that gets them excited, then you can have success overnight. Of course the thing is – if you are starting a book project, you probably already believe that it has that x factor – but it might not! There is always the chance nobody sees it as being as exciting as you do.
Other factors that affect the initial uptake and contribution rate include your own profile within the sector you are addressing. Brad Pitt could probably start 1001 really boring books and get good starting contributions across a good percentage of them. That really helps a lot. You can act strategically on these issues of course – if you are not well known within the domain of the intended book, approach someone that is, and see if they will come on board early. Through strategic invitations you might end up with a good alliance of profiled contributors who may or may not do much work, but who will certainly attract others to the job.
Also of course, the actual offering itself affects the uptake. Send out an egocentric request to help *you* finish the book *you* always wanted to write, and you will probably get no takers. Send out a request for involvement that is friendly and open and which provides a good argument why the project would be a good project to get involved in – targeting your contributors own egocentrism (!) – is probably going to have a better effect.
That message should also go through the right channels too, of course. Think of the channels you need to get that message to, its tone and content – even design issues if necessary – and think about who that message should come from. In some cases, for example, its better to have someone with a reputation in the target contributor group to communicate the call to action.
This is your first step in community management – making your community an attractive prospect.
There is a lot of interesting stuff happening to the page right now. The page is changing in so many ways – time-based media is making its way into book pages, reactive content, scrollable space, and a multitude of differing display devices make designing pages pretty hard work these days. How to design for so many possibilities? How to understand so many possibilities?
Craig Mod of flipboard makes a very compelling argument for two forms of page in an article he wrote for Book: A Futurist’s Manifesto : formless content and definite content. (This was the first book to be produced by PressBooks.)
Craig’s argument in a nutshell and in his own words is:
The key difference between Formless and Definite Content is the interaction between the content and the page. Formless Content doesn’t see the page or its boundaries; Definite Content is not only aware of the page, but embraces it. It edits, shifts, and resizes itself to fit the page [...] Put very simply, Formless Content is unaware of the container. Definite Content embraces the container as a canvas.
Craig argues that most book content we know is formless – the text can reflow into other containers without affecting the meaning. It’s a really well-argued position and one that is in tension to the current design methodologies of book designers today. Book designers are taught to design contained space – books are a very definite context in which they work. Desktop publishing applications are built to meet this methodology and are designed to enable pixel-perfect manipulation within a strictly contained space. If the designed digital article does not exactly match the printed artifact then something went wrong. A lot of energy has gone into this process.
Formless design principles are uneasy to consider for traditional book designers – how can you design for a page that does not yet know its container? It is literally like asking a book designer to design a book without telling them the page dimensions.
As it happens, web designers have been thinking about page design too. For a long time now web designers have made pages that embrace differing containers – they have been working, at least in part, with formless content.
What is missing, however, are good tools for taking the web designer’s aptitude for working with formless content to enable them to produce books. A good tool set for designing formless books should not work with constrained page dimensions. It is tempting, for example, to think of working with a design environment with constrained page-like artifacts – think of Google Docs as an example. Could something like Google Docs with its digital, scrollable, yet fixed page size be a good starting point for some kind of design tool? Place layout and typographical controls on top of Google Docs and do we have the next book design environment?
I don’t think so, because it is exactly the kind of idea that is blinded by the media of the past and cannot accept that things have changed. We must design tools that enable book design for formless content. What those tools look like is a very interesting question and one which Aleksandar Erkalovic (Booktype lead dev) and I have been working on with students (Hannes Bernard and Aiwen Yin) from the Sandberg Institute in Amsterdam.
Our argument is that the design of formless content is really a partially constrained environment, since elements within the page have some kind of relationship to each other. This is an argument web designers are familiar with when using design tools like position:relative – a rule which sets a relative position relationships between objects. Relationships can be constrained or shaped by rules which will be at least partially preserved when displayed in different contexts. The meaning is preserved by the relationship between the elements, more than by their relationship to the constraints of a page.
This is the reasoning behind Cascading Style Sheets – the design language of the web. It is rule-based design and even partly conditional. It is possible to express conditions in CSS even though it is not done that often. A CSS rule such as :
h2+p {page-break-inside:avoid;}
is a conditional CSS rule which will apply the style only when a paragraph follows heading 2 (h2) element.
Web designers know this kind of thinking, but book designers are going to have to let go of pixel-perfect design and enjoy thinking and designing this way. It seems like a simple idea but it takes a lot to overcome legacy. The legacy is so strong that designers are pretending the issue does not exist. There are tools now appearing and sold as design environments for iPad books. They give near 1:1 page relationship between the design environment and the final result. However, we all know what happens to digital hardware – it changes. What is true now will not be true 5 years from now, so the idea that an ebook is a contained space is very appealing to traditional book designers but it will be a short-lived myth. iPads might keep the same form for 5 years, they might not but they certainly will not keep it over the next 5-10 years. Better to learn how to design in the new way than be fooled into thinking you can bring all the old methods to a new medium and get away with it for long.
What we are working on now, is a way to meet the designers half way – a visual design environment which is used for rule and condition based design. Can book designers accept a tool like like this? Will web designers just step in and take the role of book designers? Its an interesting question and one we hope to have some more experience with soon.
The new layout language for the book is HTML. It has never been easier to make web content using HTML, hence it has never been easier to make a book.
Generally speaking, HTML is frowned upon as a source file format for books because it is seen as worst practice. Best practices require complicated file formats like “docbook” or, worse, Latex. These file formats have been designed to contain and describe content so that beautiful books can be made. Unfortunately, the process of creating docbook and Latex is extremely complicated. Getting a new user to work with either of these formats is quite a process. On the other hand, WYSWYG editors which produce HTML work very much like simple text editors. It is trivial to create HTML with a WYSIWYG editor or similar tool and it can be done online.
HTML is a very established, very well used, and very well distributed format. There are already an enormous number of people using HTML, and an enormous amount of content already stored in HTML. That content and those people are networked, and HTML has a rich legacy of tools that enable transformations into other formats. HTML is the new source format for books.
CSS (Cascading Style Sheets) is the syntax that controls the look and feel of HTML. E-readers and web-browsers can read this syntax and present the content accordingly. Book production platforms such as Booktype enable the customisation of CSS for ebook output, but, more interestingly Booktype also enables CSS to control the look and feel of paper books. Designing in this way takes some thought since it is usually disorientating for book designers to ‘design in code’ and it is equally disorientating for web designers to use code to design material products.
The W3C CSS Working Group1(responsible for overseeing the standard) anticipated the intersection of the book and the web some time ago. In the latest drafts of the CSS standard, new additions are almost entirely focused on typography2 . As a consequence of this emphasis, this area is starting to blossom. There has also recently been a sharp rise in the websites offering tips on CSS typography3and an explosion of web fonts. (If you are interested in a very good insight about how fonts get to the web please watch the Unbound Book video presentation by Otmar Hoefer, the Director of Font Marketing at Linotype Library4 ).
There are also some very interesting JavaScript libraries available that are trying to make up for what is lacking in CSS typographical controls. Most are based on the well-used and prolifically distributed JQuery JavaScript libraries.
Of particular interest is the kerning.js library which combines the previously available lettering.js library. What these libraries do is to make each glyph (letter/number) into its own element, each of which can then be transformed by CSS-like rules. In plain speak, these code libraries allow you to change each letter individually in a paragraph or heading etc.
There are some nice demonstrations online about why this is interesting, of which the most interesting demo can be found at kern.js. Try visiting that page, double click the big blue circle, then click on and drag the letters individually.
If you then click ‘Finish Editing,’ you will get the CSS controls necessary to implement this effect (if you had kerning.js linked from your page).
There is also another interesting typographical library called colorfont which enables dual toned glyphs.
It is a pretty good trick they used to achieve this. Essentially they created two fonts from the same master font, each displaying just partial glyphs. When overlayed, they display the full glyph. Hence each ‘layer’ can be targeted with a different color.
With libraries like this, it is apparent that JavaScript has a future with web typography but maybe it doesn’t stop at that. These kind of tricks can also be implemented with ebooks and with more and more book designers entering the world of ebook design, I am sure we will see a growing need for more of these libraries.
Good nuanced control over font rendering is good enough at the moment and getting better quickly. However, many e-readers and all web-browsers do not support all of the CSS controls and most ebook readers do not currently support JavaScript. This will change in time, especially since ebooks are becoming a revenue stream for Apple, and Apple (together with Google) is behind the development of webkit – the rendering engine behind iBooks, Safari and Chrome. Good support of CSS typographical controls is on its way and we can expect more web designers to start designing books, and to see more book designers learning code.
What is dismaying, however, is the current trend of vendors like Apple to use non-standard CSS controls to layout the books. Baldur Bjarnasons has written some very good blog posts about this. The strategy by Apple is to make any book authored by the iBook Author software only work (or work well) when viewed with the iPad. I do not really understand this strategy – yes it is the typical platform / sales channel lock-in that Apple is known to perpetuate. However, it means that content creator content has limited distribution because of this. Apple might wave this away by saying that it is ‘innovating,’ but innovation like this cannot be seen without a degree of skepticism about the intended goals.
Nevertheless, it is possible to say with some confidence that CSS and JavaScript will come to be seen as an important development in the history of typography. Just as Gutenberg “was concerned only to imitate the book of his day – which was handwritten”5 but unintentionally gave birth to new aesthetics, we can imagine the new CSS typography to have similar consequences.
A very speculative model which we have yet so see emerge is the development of book production ‘content production markets’. Code development has had this for a long time with sites like freelancer.com where project managers can find freelance programmers. Project managers post specific jobs to freelancer.com and programmers make bids for the work. The project manager then evaluates the bidder’s experience and client feedback against the amount the bidder posted.
It is very easy to imagine that this kind of business could evolve for book production. There are many people in the world with skills relative to book production that can be executed online – editing, writing, illustration, research, fact checking – you name it. Development of a formalised and informal trading of these skills could create significant revenues for participants and could really explode the current book production model and the revenues available for producers.
The long tale
Lastly, The Long Tale. The long tail was popularised in the age of the net by Chris Anderson. It’s the familiar strategy of selling a large number of books to small niche markets. The idea being that a lot of sales of niche items adds up to a good profit or as he put it in the title Why the Future of Business Is Selling Less of More.
However there is another possible ‘long tale’ market here – instead of seeing a total inventory as having a ‘long tail,’ each book in itself can be customised for resale over a number of smaller markets. One book distributed over several markets, each with its very own version of the book. We have experimented with this a little in FLOSS Manuals – customising the same book for specific markets. Remixing books can be considered to be exactly this strategy but on a very small scale. Many workshop leaders use the remix feature of FLOSS Manuals to generate workbooks with content taken from several existing books. We have also encouraged consultants to take books from FLOSS Manuals, clone them, and customise the book to speak directly to their potential and existing customers. It is a powerful pre- and post-sales device. The long tale here has a market of 1 – the client. This is the very end of the long tale, but the return can be lucrative for the consultant that secures a sale or return sale because of their valued added services powered by customised documentation.
I believe there is a business here – either customising content as a service or providing the tools for people to customise heir own content. It is also very possible that one book could in itself provide a lucrative ‘long tale’ business if the tale was long enough.
Chapter Sales
Some are putting their money on the sale of book components – selling parts of a book, typically in chapter form. This necessitates closed copyright as a rule. O’Reilly have been experimenting with this for about 5 years and it seems to be their darling, the newest iteration being the Inkling project which is strongly backed by them. Inkling markets educational material in chapter form.
I think this is a very interesting strategy but I don’t like it because the sale of content like this always works against reuse and collaboration. If the bottom line is still in resale of the artefact, this will always work against free culture and movements like the Open Education Resources movement. From this perspective this process is flowing against new forms of education processes. I can’t help but be cynical to think Inkling will make more money from a single book through chapter sales than they would ever make from selling the book as a whole. If you look at some of Inkling’s titles and total up the price per chapter against the total number of chapters then it is apparent the cost to the buyer exceeds the cover price of the entire book. It’s a cynical move. Real innovation in this field would construct markets for chapter production with the contents being free to distribute and reuse as mentioned above. Unfortunately, chapter resale in the form that O’Reilly and Inkling pursue is going to have a successful market but it’s working against more enlightened approaches to education and the future of the book in the long term.
The vast majority of authors under the current dominant model of publishing don’t make any money. Authors do it for the chance to make money, and they do it for the advancement of their careers and their profile. There is no monster financial industry pouring money into culture and knowledge workers, instead they are pouring money into book production and distribution.
I mention this because one argument against free content is that people won’t get paid. However, people often don’t get paid for writing books anyway, so with free content, nothing has changed. Nevertheless, there are many profitable businesses that have for a very long time made a lot of money from the resale of free (in this case, out-of-copyright) material. Take Penguin Books, for example. They can’t stop competition with sales of out-of-copyright classics but seem to be doing all right nevertheless. You can get many of the same out-of-copyright books at Project Gutenberg for free, but that doesn’t stop Penguin Books and many other publishers selling the same material in both paper and digital form and making a good profit. In addition, I believe that free books have revenue models which are more open to content producers than are the existing publishing models.
There are some major changes in the industry that point to this. First, it is reported that ebook sales are going through the roof. Amazon has reported that ebooks are the most popular book format1. Ebooks have lower costs for production, in fact, you can more or less say that producing an EPUB (a very popular and open ‘almost standard’ for ebooks) costs nothing. Find the right software and it’s done in minutes. This puts very profitable publishing in the path of federated publishing.
Second, business models are changing. The biggest shift I see is to put the money at the front of the production cycle instead of at the end. There are platforms like Unbound (http://www.unbound.co.uk/) that are giving this a go, and many successful examples in Kickstarter, such as Robin Writes a Book2– a book project that raised $14,000 (USD) from crowdfunding. Robin Writes a Book by Robin Sloan is a fictional work funded before it was produced. In a blog post3 on Creative Commons the author states:
"I think the most important thing about a book is not actually the book. Instead, it’s the people who have assembled around it. It’s everyone who’s ever read it, and everyone who’s ever re- or misappropriated it. It’s everyone who’s ever pressed it into someone else’s hands [...] it’s that group of people that makes a book viable, both commercially and culturally. And without them — all alone, with only the author behind it — a book is D.O.A."
That’s a pretty good argument, from the inside of fringe cultural production, that it doesn’t need the current publishing industry to thrive. It also illustrates that social context is important for generating revenue. Sloan goes on to explain secondary economies he is trying to generate from the book.
There are many other examples of very well-funded books ($85,000 USD being the top earner4 for a book project on Kickstarter) that demonstrate a model we can all participate in as cultural and knowledge producers.
Kickstarter approaches have their issues, but they raise an interesting point – people are prepared to fund a book that they want before it is produced. That’s quite a reversal – the consumer is actively switching sides to become ‘part’ of the production team by helping finance the product. The advantage of this process is that if you can raise the funds for the project like this then you don’t have to rely on sales to recover your costs or make a profit. That means there is a better chance for the product to be a ‘no strings attached’ free product. The content can actually be free because no one is anxious to recover their costs from sales. That also means that the post-production phase can focus on distributing the content as far and wide as possible because at that stage the return is recognition through distribution. This can, if done well, help with the next project that needs funding… the better you are known for producing good quality free products, the easier it will be to convince people to help pay for their production. So getting the money before making the book is not only good sense, it is consistent with free culture values.
It is possible to consider at least two other ‘crowdfunding’ business opportunities for books – running a crowdfunding service as some kind of ‘Kickstarter for books’, and getting funding from crowds for your books. Clever publishing entrepreneurs might do both.
Kickstarter.com has taken up this concept of crowdfunding with what seems to be significant initial success. The premise is simple: an individual defines a project that needs funding, defines rewards for different levels of contribution, and sets a funding goal. If that pledges meet the funding goal, the money is collected from pledgers, distributed to the project creator, who uses the funding to make the project. If the project does not reach the funding goal by the deadline, no money is transferred. Most projects aim for between $2,000 and $10,000.
Kickstarter pledges are not donations, as most of the contributions are associated with tangible rewards, nor are they a form of micro-venture capital, as funders retain no equity in the funded project. While crowdfunding need not be limited in topic, Kickstarter is focused almost exclusively on funding creative and community-focused projects. Part of their goal is to create a lively community of makers who support each other. At the end of their first year, Kickstarter gave out a number of awards, including one to the project with the most contributors, the project that raised the most money, and the project that reached their goal the fastest. The award that might be most telling is for the “Most Prolific Backer”:
This model is catching on and we can expect more nuanced and sector-driven approaches to financing book production this way. One such possibility, is finding organisations to sponsor book production and making the argument in business terms.
A while ago I worked with a Dutch organisation by the name of Greenhost.nl. They are a small hosting provider based in Amsterdam with a staff list of about 8. The boss wanted to bring the Greenhost crew to Berlin to make a book on Basic Internet Security and he wanted me to facilitate a Book Sprint to produce it. So we organised a Book Sprint, invited some locals to come and help, and sprinted the book over four days. In total, around 6 people were in attendance (including myself as facilitator) and we started on Thursday and finished the following Sunday, one day earlier than expected. The book is a great guide to the topic and quite comprehensive – 45,000 words or so in 4 days with lots of nice illustrations.
The following morning, the book went to the printers and then was presented in print form, 2 days later, at the International Press Freedom Day in Amsterdam.
The presentation at International Press Freedom Day was complimented by a PR campaign driven by Greenhost. The attention worked very well as the online version of the book received thousands of visits within a few hours (slowing our server down considerably at one point) and there was also a lot of very nice international and national (Dutch) press attention. This worked very well for Greenhost as this is the kind of promotional coverage that is otherwise very hard to generate. That makes sponsoring a Book Sprint a very good marketing opportunity for organisations.
There are some organisations that have taken this principle into their business. The President5 is a South Africa (Capetown)-based organisation that has won a lot of awards for their designs. They place great emphasis on book/content design as a more engaging and potent form of marketing for their clients.
There are of course some issues raised here the first being that this will only work for the sponsor if they keep their marketing-speak out of the book itself. If they put marketing texts into the book they sponsor, they are making marketing brochures, not books and they stand to look very bad. Let the book do what it has to do and get the kudos by saying you made it happen.
This kind of press is not only good for the organisations involved and good for the reader but it is good for the book itself because it raises the profile of the book, putting it in front of people that need it and can help improve it. This can, for example, raise the probability that a book will be voluntarily translated. A high-profile book can be an attractive prospect to voluntary translators. Not many people want to spend the hours translating a book that won’t be read, but if it’s a book with an established high profile then it’s a better proposition. To demonstrate this by example, Basic Internet Security (the book made by Greenhost) immediately had two groups start the German and Farsi translations voluntarily.
In addition to this, we also had unforeseen re-distribution channels open up for the book. In the case of this book, someone had gone to the trouble of creating a torrent (a peer-to-peer sharing method) and listed it on Pirate Bay. We didn’t create this torrent – someone noticed the book, downloaded it, and made the torrent themselves. It’s legal sharing and it works in favour of the book and the book’s producers.
Think about what kind of book your organisation may want to bring into the world. Think of a great book that would help make the world a better place. For example, are you a design or typography company? Want to make a book about How to Make Fonts? Are you a law firm? Want to make a book about basic rights in your country? Then design a PR strategy around the book that will justify the expense of its production.
Of course, this approach does not come without its issues. If people pay money to have something produced, then they generally do not like it if the thing produced disagrees or takes issue with them. Worse is the mindset that this can produce in the producers. Anticipating and avoiding disagreement is in effect a kind of self-policing that can stifle creativity especially when you are working collaboratively. Get a good facilitator!
FLOSS Manuals is changing the license of all material in the repository from the Free Documentation License to the GNU General Public License (GPL). Why? Well… the issue of licenses and documentation is a frustrating road to travel. There are many ‘free licenses’ in the world, but none of them work well as documentation licenses if you have the following prerequisites:
compatibility with the GPL
ease of use
Those are pretty simple parameters, but alas there is nothing out there that fulfills our criteria. The Free Documentation License, which we started with, has a number of issues and, unfortunately, the redraft for the license does not make any steps to improve the situation (http://gplv3.fsf.org/doclic-dd1-guide.html).
Problems with the FDL
In particular :
the FDL does not allow for easy duplication and modification (an absolute necessity in this day and age)
it does not allow for the easy inclusion of documentation in the software itself
it appears to be written for hard copy books and does not engage issues of digital documentation very well
it is difficult to know how to implement
These issues emanate from the founding rationale of the license. There are two particular assumptions that lead to problematic clauses:
1. The FDL seems to assume that technical writing should contain embedded free software political editorial. I refer to this statement (amongst others):
"Our manuals also include sections that state our political position about free software. We mark these as "invariant", so that they cannot be changed or removed. The GFDL makes provisions for these "invariant sections".
http://www.gnu.org/licenses/gpl-faq.html#WhyNotGPLForManuals
Political editorial is not a prerequisite (nor, in my opinion, desired) for good technical writing.
2. the FDL assumes documentation writing is a book business. I refer to :
‘Free Licenses’ should not shy away from the commercial use of the substance it is applied to. That is the principle of freedom – to use the software or documentation as you wish, as long as you preserve the same freedoms for others. However, the focus should be about preserving freedom, not preserving particular business models. This rationale is troublesome, especially when you want to distribute free documentation and the license actually makes it harder to do that.
The above are just the main concerns with the rationale of the FDL. These two issues have consequences in the license that make it very difficult to use if you wish to write free documentation for free software.
What FDL clauses cause problems?
There are many references in the FDL that indicate that the writers could only imagine documentation in the form of a book. There are constant references to ‘Title Pages’, ‘Covers’ etc. One particular clause that is hard to maintain is this section which stipulates that a modified version of a work must:
"A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission."
There are so many issues with this statement that it’s hard to know where to begin. What, for example, is the role of a ‘History Section’ in documentation that might be one ‘page’ long? The main problem with this clause, however, is that digital documentation, in the FLOSS Manuals world at least, should flow like water from one author to the other with as much flexibility to add, alter, delete, and remix as much as possible. Requiring a ‘traceback’ to the original author so you can use the same title is cumbersome, stifles re-use of material, and logistically hard to maintain in this age of free-flowing digital document distribution.
Here is another ‘book’ issue which limits freedom:
" If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects."
Well, FLOSS Manuals doesn’t care how many documents you might publish. Go ahead, print as many as you like, however you like (well, with a quick read of how to apply the GPL)… as free documentation writers we don’t want to get involved in complex clauses involving ‘Cover Texts’ and ‘Front-Cover Texts’ which are going to limit your freedom to use the documentation as you want.
Can the GPL be used for documentation?
So is the GPL really applicable to documentation? This statement is interesting:
“It is possible to use the GPL for a manual, but the GNU Free Documentation License (GFDL) is much better for manuals.” http://www.gnu.org/licenses/gpl-faq.html#WhyNotGPLForManuals
The FSF further states the GPL can be used for documentation,
“You can apply the GPL to any kind of work, as long as it is clear what constitutes the “source code” for the work. The GPL defines this as the preferred form of the work for making changes in it.” http://www.gnu.org/licenses/gpl-faq.html#GPLOtherThanSoftware
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 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.
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.
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.
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.
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, 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.
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!
