Anil Dash just published an interesting post looking at the social implications of the code fork, and how it has changed from a huge contested point to a feature of the collaborated process:
“While Linus Torvalds is best known as the creator of Linux, it’s one of his more geeky creations, and the social implications of its design, that may well end up being his greatest legacy. Because Linus has, in just a few short years, changed the social dynamic around forking, turning the idea of multiple versions of a work from a cultural weakness into a cultural strength. Perhaps the technologies that let us easily collaborate together online have finally matured enough to let our work reflect the reality that some problems are better solved with lots of different efforts instead of one committee-built compromise.”
This is something we touched upon in the Collaborative Futures book, both in the Multiplicity and Social Coding and the Forks vs. Knives chapters. Anil goes on to suggest a distributed collaborative model that encourages forking might reinvigorate Wikipedia, which follows the more traditional centralized collaborative model:
“Most importantly, the new culture of ubiquitous forking can have profound impacts on lots of other categories of software. There have been recent rumblings that participation in Wikipedia editing has plateaued, or even begun to decline. Aside from the (frankly, absurd) idea that “everything’s already been documented!” one of the best ways for Wikipedia to reinvigorate itself, and to break away from the stultifying and arcane editing discussions that are its worst feature, could be to embrace the idea that there’s not One True Version of every Wikipedia article.”
Extending the distributed model beyond code and leveraging forking in other collaborative processes have interested me for quite some time. In commenting on Anil’s post, I realized something about the inherent difference between Wikipedia and software. Instead of rewriting it, I’ll just quote my comment in its entirety:
I’m happy that both the merging and the network view issues were addressed on the previous comments. I have been interested in extending the git&github models beyond software myself. I understand the interest in considering Wikipedia as the next logical step for networked collaboration right after code, but I think there is a fundamental difference between the two. While software code contains a set of rules that would operate a system, Wikipedia’s model is almost opposite – it documents a system that is already happening or has happened. Wikipedia attempts to document a monolithic past while software attempts to imagine the multiplicity of the future(s).
If there is room for the distributed model to be extended beyond software, I believe we should try to find other creative processes that are aimed at the future. One of these fields which I am very interested in these days (and I know you Anil are to) is legislation.
We’ve already established that “Code is Law”, but we have not realized that it also means we can/should fork it and hack it, and then possibly merge it too. Most Open Gov initiatives have been focused on government transparency – making the past activity of the gov’t more accessible hoping this would make representatives more accountable in the future. We’re often use software to mashup the past data rather than to help create it.
I say, rather than just promote or fight a bill (traditional pre-Internet models of engagement) we should fork it. Don’t send me tiring petitions about why this is wrong, send me a “diff” highlighting your proposed patches (then we can fight together for a “pull request”).
While there will only be one “build” we’ll be able to “execute” together, the git model is not just about forking. It’s about mitigating individual creativity and autonomy with the collective production. In software projects, you can fork and follow your own individual trajectory at the possible high price of losing the benifits of a community. The same can be said about democracy. It’s about open leadership… People largely choose to engage rather than live in the hills, so I believe we should encourage them to fork and trust that they will have enough incentive to merge.
Anil, or anyone else interested in further developing these ideas, I’d love to hear your thoughts here or @Mushon(.com)
So yeah, definitely let me know your thoughts & join the discussion there or here.
Ha, Anil learned too late!