Networked_Performance — [iDC] Recursive Publics and Forking

[iDC] Recursive Publics and Forking

Tags:: conversation; forking; labor; open source; p2p; public

[Image: Garden of Forking Paths by wasabicube] Nate Tkacz wrote: Hi all,

I would like to add to the discussion about recursive publics*, consensus and forking. Anna briefly mentioned Christoph Spehr’s discussion of “withdrawal” in Free Cooperation. Her point, as I understand it, was to emphasise dissensus rather than consensus as the aspect of recursive publics that makes it significant as a political structure. Chris Kelty (from now on CK to avoid confusion) pointed to the practice of forking as an instance of productive dissensus. Through the practice of forking people can leave a project, taking the (non-exclusive) source code or whatever other materials that constitute the public with them and continue in a different direction. The fact that forking is a possibility, writes CK, keeps contributors responsive to each other and this presumably also works to legitimize the recursive public:

One aspect of this are the debates around “forking” a project. Linux is, quite remarkably, a *single* project with a now nearly 20 year coherence… but there is no legal or technical reason why it must be so, anyone can fork the code and create their own version… and people have tried… so there is no absolute consensus here other than one that says “we agree there can never be any absolute consensus, but will make do with the best we can put together. The option to fork is always in the consciousness of those who contribute to a real free software project, and those that are successful have to deal with it as a perpetual danger.

While forking is “legally and technically” possible, it is often highly unrealistic and I think this complicates the notion of consensus. Part of Spehr’s idea in Free Cooperation is that not only must contributors be free to quit the collaboration, but importantly the cost of leaving for all members must similar and bearable. This is clearly not the case with the projects CK describes as recursive publics. There is always more at stake for some members than others; more important contributors and less important ones. Further, the modular or ‘granular’ structure of many of these projects means that the people who want to fork will not be able to continue alone (as they do not have the diverse set of knowledges and skills required). This would leave the option to exit, but not of forking, or the option of remaining, but not of consensus. A possible third option might be to leave and seek new allies (in the Latourian sense, of gaining allies - new members, converts, new software etc. - to increase the ‘reality’ or in this case feasibility of the fork). Once again though, the position of the fork-initiator in the original project would, I imagine, greatly impact the chances of success here. (That is, the asymmetries in the original project would carry over. For example, Larry Sanger might be able to fork Wikipedia, but the chances that I would be able to do it are much smaller. I would say zero! The chances of Jim Wales starting a fork might be greater again. The point however, is that each person is in a different position in relation to the project.) I should also note that this is as much a critique of Spehr’s thought here, as I’m yet to find a situation where his “similar and bearable cost” have been satisfied or could even be worked out. (Admittedly, Free Cooperation is more a manifesto than a mapping of the present.)

It seems obvious that open projects become less malleable as they persist and increase scale. They produce their own structural asymmetries and often their own celebrities (Linus, Jimbo). As complexity and scale increase, and new political structures emerge, forking becomes harder to achieve and the chances of success are unevenly distributed among members. Forking, then, is not a solution to dissensus (that also reaffirms the legitimacy of the recursive public) nor is it necessarily about justice. Instead, a close consideration of the conditions in which the desire to fork emerges, together with the success or failure of the fork itself, might be a good place to get a grip on the political dynamics of open projects.

Best
Nate

Sam Rose wrote:

I have to say that I don’t think forking is always based on oppositional detachment.

A few examples (some of which I participate in directly) include:

http://communitywiki.org which was a “friendly” fork of Meatball wiki http://www.usemod.com/cgi-bin/mb.pl which was in turn a “friendly” fork of the original wiki http://c2.com/cgi/wiki?

The actual software that runs community wiki (OddMuse) is *also* a fork of the software that runs Meatball wiki (UseMod wiki engine) which in turn is a *also* a fork of the original software that runs
http://c2.com/cgi/wiki?

By the time you get to the OddMuse branch of lineage, OddMuse software itself actually contains the infrastructure to make fast forking within the wiki community almost effortless see:
http://communitywiki.org/odd OddWiki hive, which makes the creation of a new wiki instantaneous. Forking of the wiki community is encouraged. Another fork of original wiki software is http://prowiki.org which has built in affordances for Wiki fractility (see:
http://www.usemod.com/cgi-bin/mb.pl?WikiFractality)

Why would a wiki community want to encourage forking? And, doesn’t this damage the original wiki community? The fact is that communities change over time, and encouraging fractility and “friendly” or amicable “forking” creates space for natural adaptation, growth, and innovation. Once the software creates a set of standards for interoperability between forks, then it really does not matter how many forks exist, nor how granular breakdowns become, since it is also possible to keep the repositories of data connected in ways that are meaningful and useful to the forked communities (combined recent changes, “near linking” of wiki words, “interwiki links” etc)

This actually resonates with Nate’s point above. When the cost for leaving is similar and bearable, as it is in the examples in wiki communities above, when friendly forking and systemic amicable fractility are encouraged and built into the software mediums, you see the emergence of more rapid innovation that is *still* usable by the majority of the community.

Sam Rose

Christopher Kelty wrote:

nate,

I would put a finer point on this: what matters is not the ability to fork, but the ability to make your fork become The One. Hundreds (thousands) of companies around the world have “forked” Linux or BSD in the minor sense of customizing it for their own purposes in house — none of them have tried to make their version beat Linux at its own game. What’s more, there is a strong social pressure to join rather than fight, as it were — to argue your case within the Linux (or Wikipedia) community rather than trying to compete with your better idea. Is this social pressure good or bad? Good because it keeps people and communities together, bad because it doesn’t allow people to leave a collaboration and start anew as easily as we might like.

A related issue is that something like Wikipedia becomes impossible to fork at the infrastructural level, since it relies on a huge investment in servers and staff to run them. *Media Wiki* is much easier to fork than Wikipedia, and this is what I was getting at by wondering to what extent the principles of free software work in the era of web services.

thanks for these thoughts
ck

:*p2P Foundation — From Christopher Kelty’s book, Two Bits, http://twobits.net/discuss/chapter1/15:

“A recursive public is a public that is vitally concerned with the material and practical maintenance and modification of the technical, legal, practical, and conceptual means of its own existence as a public; it is a collective independent of other forms of constituted power and is capable of speaking to existing forms of power through the production of actually existing alternatives. Free Software is one instance of this concept, both as it has emerged in the recent past and as it undergoes transformation and differentiation in the near future. There are other instances, including those that emerge from the practices of Free Software, such as Creative Commons, the Connexions project, and the Open Access movement in science. These latter instances may or may not be Free Software, or even “software” projects per se, but they are connected through the same practices, and what makes them significant is that they may also be “recursive publics” in the sense I explore in this book. Recursive publics, and publics generally, differ from interest groups, corporations, unions, professions, churches, and other forms of organization because of their focus on the radical technological modifiability of their own terms of existence. In any public there inevitably arises a moment when the question of how things are said, who controls the means of communication, or whether each and everyone is being properly heard becomes an issue. A legitimate public sphere is one that gives outsiders a way in: they may or may not be heard, but they do not have to appeal to any authority (inside or outside the organization) in order to have a voice.3 Such publics are not inherently modifiable, but are made so—and maintained—through the practices of participants. It is possible for Free Software as we know it to cease to be public, or to become just one more settled form of power, but my focus is on the recent past and near future of something that is (for the time being) public in a radical and novel way.

The concept of a recursive public is not meant to apply to any and every instance of a public — it is not a replacement for the concept of a “public sphere” — but is intended rather to give readers a specific and detailed sense of the non-obvious, but persistent threads that form the warp and weft of Free Software and to analyze similar and related projects that continue to emerge from it as novel and unprecedented forms of publicity and political action.

iDC — mailing list of the Institute for Distributed Creativity
iDC [at] mailman.thing.net
https://mailman.thing.net/mailman/listinfo/idc

List Archive:
http://mailman.thing.net/pipermail/idc/

iDC Photo Stream:
http://www.flickr.com/photos/tags/idcnetwork/

RSS feed:
http://rss.gmane.org/gmane.culture.media.idc

iDC Chat on Facebook:
http://www.facebook.com/group.php?gid=2457237647

Share relevant URLs on Del.icio.us by adding the tag iDCref

Jul 11, 17:12
Trackback URL