[iDC] recursive publics and forking

[Christopher Kelty]

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
priniciples of free software work in the era of web services.

thanks for these thoughts
ck

On Sat, Jul 11, 2009 at 9:43 AM, nathaniel tkacz
<nathanieltkacz at gmail.com>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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.thing.net/pipermail/idc/attachments/20090711/e084d12c/attachment.htm