Forks vs. Knives

When you face a simple task and have all the capability and know-how necessary to accomplish it by yourself, there is really no reason for you to collaborate. And that's OK. 

But when achieving the goal is hard, and the tools you have are insufficient, there is room for collaboration. In some cases collective action will be a part of the task itself—meaning the mobilization of group collaboration is a part of the task. Often this mobilization is a by product of the principal objective.

We defined intentionality and coordination of contributions as key to collaboration. But both intention and coordination actually raise the cost of collaboration, and in some cases makes it not worth the trouble.

“Sometimes developers simply want to publish and share their work, not start a social movement.  Sometimes they want to contribute to a project without going through masonic hazing rituals.”

This quote from the Multiplicity and Social Coding chapter refers to Distributed Version Control Systems. The loose coordination enabled by these systems attempts to lower the cost of collaboration. By using these distributed collaborative tools the overhead inherent in establishing intention and coordination is reduced. In fact these system allow for a completely individualized practice. A Git user can work alone for years. By publishing her files online under a Free Software license she opens the door to a potential reappropriation or even future collaboration. She does not have to commit to contribute, she does not have to coordinate with anyone. She is not collaborating (yet). 

This approach is similar to the principles advocated by the Free Culture movement. Share first and maybe collaborate later, or have others use your work, be it in an individual or a collaborative manner. But while distributed sharing platforms are common, DVCS excels in constantly switching between a coordinated action and an individuated one.

At any point of the development process Alice, a Git user, can inspect Bob's code repository and choose to fork (essentially duplicate) his code base to work on it separately. No permission is required, no coordination needed. At any point, Bob can pull Alice's changes and merge them back into his own repository. 

This might seem trivial, but it's not. Centralized version control systems can make it technically easy to fork but are usually not sophisticated enough to make merging back easy. This has turned forking into a highly contested practice, as forking the code meant forking the project and dividing the community. DVCS makes forking and merging trivial and lowers the cost of collaboration. 

But whilst distributing and individuating the process minimizes the need for intent and coordination, it may result in deemphasizing the collaborative act. By ensuring that ‘you don’t have to start a social movement’, does it divorce itself from the social ideals of collaboration celebrated by many Free Software activists?

We argue it does not. You can still start a social movement if you like. You might actually have better tools to do so too, as the distributed process allow a larger autonomy for the individual members and less friction in governance and control.

From Splicing Code to Assembling Social Solidarities

We can already see early examples of these approaches outside of Free Software. One of them is the Twitter Vote Report used in the 2008 US presidential elections <twittervotereport.com> and its later incarnation as SwiftRiver, a tool for crowdsourcing situational awareness:

“Swift hopes to expand [Twitter Vote Report’s] approach into a general purpose toolkit for crowdsourcing the semantic structuring of data so that it can be reused in other applications and visualizations.  The developers of Swift are particularly interested in crisis reporting (Ushahidi) and international media criticism (Meedan), but by providing a general purpose crowdsourcing tool we hope to create a tool reusable in many contexts.  Swift engages self-interested teams of “citizen editors” who curate publicly available information about a crisis or any event or region as it happens”
—Swift Project, 2010 <http://github.com/unthinkingly/swiftriver_rails>

These activist hacker initiatives are realizing the potential of loosely coordinated distributed action. Its political power is entangled with its pragmatism, allowing the collaboration to fluidly shift between individual and collective action. In January 2010, as the horrors of the Haiti earthquake were unraveling, hackers around the world were mobilizing in unconference-style “CrisisCamps”. These hackathons gathered individuals in physical space to “create technological tools and resources for responders to use in mitigating disasters and crises around the world.” <crisiscommons.org/about-us>

Contesting the Shock Doctrines

This type of external interest and action was previously reserved to human rights organization, media companies, governments and multinational corporations—all organizations that work in a pretty hierarchical and centralized manner. Now we see a new model emerge—a distributed networked collaboration of interested individuals contributing digital labor, not just money.

The political vacuum presented by these natural or man made crises leave room for a strong active force that often enforces a new political and economic reality. In her book titled The Shock Doctrine, author Naomi Klein describes how governments and businesses have exploited instances of political and economic instabilities in recent decades to dictate a neo-liberal agenda. In each case the interested powers were the first on the scene, imposing rigid rules of engagement and coordination, and justifying enforcement by the need to restore order.

In contrast, the activists are providing the tools and the know how for data production and aggregation. They are then actively assembling them into actionable datasets:

“People on the ground need information, desperately. They need to know which symbols indicate that a house has already been searched, where the next food/water/medicine drop will be, and that the biscuits are good, and not expired.  They also need entertainment, and news—à la Good Morning Vietnam. And messages of consolation, emotional support, solidarity, and even song and laughter. ”

—Jonnah Bossowitch

The model of individual autonomy and free association that enables the hackers coding is embedded into the assistance they propose, empowering communities on the ground. One of the hackers from the NYC CrisisCamp jokingly declares: “Two sides get to play the shock doctrine game”. It is obviously a drop in the ocean in comparison to the scale of the disaster and the years it would take to heal. Nations and corporations have long term interests and the resources that will probably keep them in the picture long after the networked effort will evaporate.

These are brave yet very early experiments in new political association. They are widely informed by experiments in collaboration and control in information economies. Most of them will not automatically translate to meat space. Especially at times of natural disaster, when food and medicine shortage occupies much of the human rights debate.

Open Leaders Failing Forward

The abundance of information technologies have also lowered the price of failure and made it an inherent part of the process. It's not about whether you will fail, it's about how you will fail. What will you learn from failure? How will you do things differently next time. This is what some call “failing forward”. 

The lowering costs of failure in distributed networked production allows for a more open emergence of leadership. One may provide leadership for a while and then get stuck, lose the lead, and be replaced by another one forking and leading in a different direction. This algorithmic logic justifies open access to knowledge and distribution of power that favors merit over entitlement. This is not a democracy, but a meritocracy. A meritocracy that favors technical expertise, free time, persistence and social skills.  All traits that are definitely not evenly distributed.

Initiatives like FLOSS Manuals have acknowledged the importance of documentation for the collaborative process. To take real advantage of the network effect, we should learn to document failure, not only success.

In the past, experiments in alternative social organizations were hampered by limitations on the resources available within individual projects, and isolated by the costs of communication and coordination with kindred efforts. This was the case of the Cooperative movement, communes, the occupied factories in Argentina and other similar alternative social experiments. If we extend the notion of failing forward beyond the production of information, future results might look different.

New models of collaboration will continue to inform and alter our social relations. These political experiments are free for us to assess, free for us to fork and to try something different. Then, in the future after more development is done, and the commits have been tested, we will also be free to merge them back.