Monday, April 16, 2007

Three Elements of Internet-Driven Collaboration

Once again, at the risk of sounding like a complete suck-up, I must point out that today's post by my boss is full of insight:

I’ve long believed there’s a general phenomenon that underlies the free software movement. It’s “volunteer-driven, internet-powered collaboration”. I think it will ultimately touch every industry that has any digital workflow. Lets face it, that’s pretty much every industry.

The phenomenon has three key elements:

  1. Freedom-driven licensing. If you want the magic, you have to set it free, because it’s the possibility of doing things for themselves that motivates people to build on your work. Just exposing the “source” (whether that’s code or other content) isn’t as interesting. Microsoft will show you the source to Windows these days, but they won’t give you the freedom to remix it.
  2. Community. The net allows us to build a community of eyeballs and fingers based on personal interest rather than personal geography. It used to be that companies always had to do the best they could with local talent - or fly people in and deal with visa issues (that’s why Microsoft is a big proponent of greater H1-B visa allocations). Today we can find the best talent wherever it is, talent that is really personally interested in the underlying issue. And we call that talent pool “community”.
  3. Revision control. I’m much happier to give you read AND write access to my stuff, if I can know who changed what, when, and easily revert it. And if that revision control allows cheap branching, then there can be multiple, parallel efforts to solve a particular problem.

Consider wikipedia in this light: it clearly meets all three criteria. Its content has a license that gives you genuine freedom. There is a big community that takes a personal interest in that content (actually, multiple communities, one which I call “the librarians” wants to make sure the institution itself is healthy, the others are communities that form around specific content, given the nature of wikipedia as a repository of knowledge). And of course every change is logged with some level of identity associated with it.

Right now, lots of K-12 ed tech types understand community, few understand freedom-driven licensing, and even fewer understand revision control beyond the history tab on a wiki. These are our weak points; this is where we need to improve to make real progress (as opposed to, say, reading TechCrunch every morning).

2 comments:

Unknown said...

Any thoughts on how we can come to better appreciate point 3?

Curriki's phase 2 is due out tomorrow. I can't remember what the versioning capacities are in this release, but I think before long, they're going to be the ones to bring us some of these features (and also some of the semantic stuff you've talked about). Hopefully, using a tool like this would help teachers develop a flexible understanding.

Tom Hoffman said...

Um... yeah. That's a tough one. I guess the first one is knowing that it is an important issue and pricking up your ears whenever it comes up. Paying attention to what revision control you do use, like the history of a wiki. Ultimately teachers will need to have revision control integrated into the tools they use. Teachers aren't going to be doing 'bzr branch...' The most exciting thing is that it looks like bzr is going to be included on the XO and integrated at least initially into its kid-friendly programming environment, but hopefully it can also be leveraged for content creation. For that matter, the file store on the XO system might have some revision control features built in, but I'm not sure about that yet.