Book: Collaborative Futures. Floss Manuals, 2010.
"In this book we attempt to articulate what constitutes a collaboration. We argue that rules for participation, established guidelines for attribution, organizational structure and leadership, and clear goals are necessary for collaboration. In most cases, when we think of these attributes, we think of manifestos of artist and activist groups, attempts to govern attribution by formal licenses like the Free Culture and Free Software licenses, Debian's formal decision making process, or Eric Raymond's notion of a Benevolent Dictator that characterizes Linus Torvald's governance over Linux." (http://en.flossmanuals.net/collaborative-futures/)
The Book Sprint methodology
"The Book Sprint concept was devised by Tomas Krag. Tomas conceived of book production as a collaborative activity involving substantial donations of volunteer time.
Tomas pioneered the development of the Book Sprint as a 4 month+ production cycle, while Adam Hyde, founder of FLOSS Manuals, was keen to continue with the idea of an "extreme book sprint," which compressed the authoring and production of a print-ready book into a week-long process.
During the first year of the Book Sprint concept FLOSS Manuals experimented with several models of sprint. So far about 16 books have been produced by FLOSS Manuals sprints, some of these were 5 day sprints, but there have also been very successful 2 and 3 day events.
Because Book Sprints involve open contributions (people can contribute remotely as well as by joining the sprint physically) the process is ideally matched to open/free content. Indeed, the goal of FLOSS Manuals embodies this freedom in a two-fold manner: it makes the resulting books free online, and focuses its efforts on free software.
The difference between the Collaborative Futures and other Book Sprints is that this is the first sprint to make a marked deviation from creating books which are primarily procedural documentation. FLOSS Manuals has produced many fantastic manuals in 2-5 day Book Sprints. The quality of these books is exceptional, for example Free Software Foundation Board Member Benjamin Mako Hill said of the 280 page Introduction to the Command Line manual (produced in a two day Book Sprint):
"I have written basic introductions to the command line in three different technical books on GNU/Linux and read dozens of others. FLOSS Manual's "Introduction to the Command Line" is at least as clear, complete, and accurate as any I've read or written. But while there are countless correct reference works on the subject, FLOSS's book speaks to an audience of absolute beginners more effectively, and is ultimately more useful, than any other I have seen."
But Collaborative Futures is markedly different. To ask 5 people who don't know each other to come to Berlin and write a speculative narrative in 5 days when all they have is the title is a scary proposition. To clearly define the challenge we did no discussion before everyone entered the room on day 1. Nothing discussed over email, no background reading. Nothing.
Would we succeed? It was hard to consider this question because it was hard to know what might constitute success. What consituted failure was clearer - if those involved thought it was a waste of time at the end of the 5 days this would be clear failure. All involved had discussed with the facilitor the possibility that the project might fail (transmediale also discussed this with the facilitor).
Additionally, as if this was not hard enough, we decided to use the alpha version of a new platform 'Booki' <www.booki.cc> that we had created specifically for Book Sprints and collaborative book production. One of the Booki developers (there are two) – Aleksandar Erkalovic – joined the team in Berlin to bug fix and extend the platform as we wrote.
It is difficult to over-state how difficult this could potentially be for all involved. It would be like living in a house, trying to sleep, get the kids off to school, have quiet conversations with your partner while all the time there are builders moving around you putting up walls and nailing down the floorboards under your feet. Not easy for all parties.
Last but not least, while this sprint built on much that had been learned in previous Book Sprints we had to develop new methodologies for this type of content. So during the week we tried new things out, tested ideas and reviewed their effectiveness.
All in 5 days.
As a result we have a book, a vastly improved (free) software platform, happy participants, and clear ideas on what new methods worked and what didn't. We look forward to your thoughts and contributions..." (http://en.flossmanuals.net/CollaborativeFutures/Three - some time in 2009 or 2010)
(relevant URL at Sept 19 2012 = http://en.flossmanuals.net/collaborative-futures/ch002_how-this-book-is-written/)
"Participation and Process
Our conceptions of what constitutes fair treatment vary according to context, as do our reactions to being treated unfairly. If someone jumps the queue in front of us in a shop, it's annoying but is quickly forgotten. But if we contribute time or money to establishing a collective enterprise, and instead it is subverted for other ends, then we feel angry, betrayed.
So our expectations and emotional intensity varies according to the degree we feel ourselves invested in, and part of, a shared project. As the intensity rises so does a need for procedural guarantees, transparency, fairness in terms of the division of benefits and acknowledgment.
Where participation is limited to small or occasional contributions, we may not even want to be drawn into time-consuming discussions about goals and methods. Likewise where our involvement is driven purely by the personal pleasure rather than any desire to attain distant objectives. NASA's Clickworkers project asks users to identify and count craters on Mars, and the combined inputs allow them to ratonalise use of their internal research resources. While it is impossible to guess all the motivations which drive people to contribute, it is obvious that no one expects to be able to actively influence NASA's overall agenda by contributing, nor to control the organization directly.
Sustained involvement requiring a substantial expenditure of effort, or active engagement to create or promote something deemed of worth or importance, demands a more careful framework. Care is required because participation implicates our sense of identity. Defection by others, a sense of betrayal, anger at manipulation or exploitation are destructive not only to the immediate project but to willingness to collaborate in the future. On the other hand every collaboration needs room also to change, and a breathing space which acknowledges the different levels of commitment of its participants, which themselves will vary over time.
While an explicit process is no panacea to the problems that arise when we deal and work with others, it can anticipate and mitigate the most damaging consequences when things go awry, whilst protecting the flexibility necessary to adapt. Decision Making and Authority in Distributed Creation
"We reject: kings, presidents and voting. We believe in: rough consensus and running code." "A Cloudy Crystal Ball -- Visions of the Future" David Clark, 1992.
Online communities are not organized as democracies. The most accountable of them substitute a deliberative process of discussion for majority-based voting. This derives from the fact that the original initiative emanated from one or a couple of people, and because participants are there of their own volition. Majority rule is not seen as inherently good or useful. The unevenness of contributions highlights the fact that a disproportionate part of the work in a project is done by a smaller sub-group. Within a political sphere that privileges production this trends towards the valuing of ability and commitment, sometimes phrased in the language of 'meritocracy'.
Founders particularly have considerable power, derived from the prestige accruing from a successful project, recognised ability, and their network centrality - having had most opportunity to forge relations with newcomers, and an overview of the technical structures and history of the project. These factors give them authority. This hierarchical element is nonetheless diffused by the modular nature of productive organization: sensible structures devolve authority over their parts so as to maximise the benefits of voluntary contribution.
This architectural enabling of autonomy extends also to newer users, who can take initiative free from having to continuously seek permission and endorsement. However their contributions may not be incorporated if considered substandard or unnecessary, but such decisions arise out of a dialogue which must have some basis in efficiency, aesthetics or logic. Arbitrary dismissal of others in a community environment risks alienating others, which if generalised and persistent may place the whole edifice under strain, or even spark a fork or split.
Longstanding projects have also tended to give themselves defined legal forms at some point, thus the prevalence of foundations behind everything from Wikipedia to Apache. These structures often have charters, and sometimes hold elections to decide on the entry of the new members or appoint totemic figures. Reputation and Trust
Influence derives from reputation - a substitute for trust in the online environment - which is accumulated and assessed through the use of persistent avatars, user names or real names. In addition to demonstrated aptitude, quantitative measures of commitment are also relied upon. Initial promotion of an editor's status on wikipedia, for example, relies upon the length of time since the first edit, and the number of edits effected. Thereafter advancement also entails a qualitative evaluation of an editor's performance by their peers.
Higher user status allows the individual greater power over the technical tools that co-ordinate the system, and require confidence on the part of others that access will not abused. This threat is higher in software projects where hostile infiltration poses a real security risk given that the code will be publicly distributed. A variety of methods for vouching for each other are thus cultivated, new developers may require sponsors. In the case of Debian physical encounters between developers are used to sign each others' encryption keys, which are then used to authenticate the package management process, adding a further layer of robustness." (http://en.flossmanuals.net/CollaborativeFutures/Thirteen - some time in 2009 or 2010)
(relevant current URL = http://en.flossmanuals.net/collaborative-futures/ch010_participation-and-process)