[iDC] recursive publics and forking

[Samuel Rose]

Nate writes:

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*.


-----


Sam replies:

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
Social Synergy
Tel:+1(517) 639-1552
Cel: +1-(517)-974-6451
skype: samuelrose
email: samuel.rose at gmail.com
http://socialsynergyweb.com
http://socialsynergyweb.org/culturing
http://flowsbook.panarchy.com/
http://socialmediaclassroom.com
http://localfoodsystems.org
http://openfarmtech.org
http://notanemployee.net
http://communitywiki.org

"Long ago, we brought you all this fire.
Do not imagine we are still chained to that rock...."

http://notanemployee.net/