The third way
First, an apology. I have taken an unintended holiday from blogging. There are various reasons: I have converted my writing-as-blog time to writing-as-programmer, and written more and better code than at any time in my career (I'll talk about these another time); I have been surprisingly affected by the loss of a blog peer; and I have been balancing too many amazing projects, and spending the rest of my time on family. However, I have not abandoned my blog, and now is as good a time as any for a new post. So here it is...
I'm into my seventh iteration of the Mozilla Open Source course at Seneca. I've got a good group of students, and we're at the point where I'm throwing them mercilessly into the fray and asking them each to find a project to work on using technologies they don't know, and with people they've never met. Sounds fun, right? It's the only way I can really tell who is serious and who is looking for an easy way out (luckily many students respond well to the challenge).
One of the first questions I hear at this stage is whether or not students can work in groups. My answer is almost always 'no,' and I thought I should say something about why I take this stance. Most student work is done in one of two ways. Either the student is expected to work on his/her own, or they are asked to form a small group. Both methods are well understood, and a great deal has been written about how an when to leverage each.
I prefer a third way. I ask students to become part of global, distributed development teams, and to do so as individuals. I want them to become part of communities individually. I want participation in a community of developers to be the default mode of work, with online communication taking the place of pure face-to-face communication.
This third way of working demands new skills. Students have to learn to rely on themselves and the community at the same time. Rather than dividing work among a small team, which is prone to isolating people and sub-projects, a community shares more responsibility. The code is "ours," so are the bugs, so are the failures, so are the successes. "We'll help you" says the community, which means that "I'll do this part" flows naturally.
The third way of working is hard at first, but incredibly liberating once adopted. The students aren't one-to-many with me, but many-to-many in the community. I'm there too, another individual in the community, another resource, but not the most significant.