Avoiding the Pitfalls of Open Education

Open source is unfamiliar ground for professors. Not the software, which is well-known at this point. But professors aren't accustomed to open development. They treat open source projects like busy work or an easy way to assign homework. Participating in FOSS projects takes work and time, maybe even six months, which is a big commitment for someone who wants to use it in a one-semester course. A student being sent in to a project without involvement from a professor is a recipe for failure.

First, professors need to choose the right projects for their students--not all projects are suited or equipped for an influx of students. And some simply don't want to. Some are not welcoming to newcomers--the kernel is a good example. Projects that have participated in a program for the purpose of welcoming students and newcomers, like Google Summer of Code or OpenHatch, are a good place to start. They're the ones who know how to accept inexperienced contributors.

Ironically, sometimes the problem is that open source communities are too helpful. We understand failure as part of the learning process, and give inexperienced contributors the benefit of the doubt. In a meritocracy, people don't stop you from doing things--they support individuals in their pursuit of a goal, regardless of how wise that end goal might be. If a student says "I want to shoot myself in the foot!" the community is likely to say "Ok! We'll help you aim!" Newcomers have a hard time discerning how much work and skill a project will take, and how big an impact it's likely to have on the users of their code, and helping them constrain themselves to workable problems is particularly important within the tight constraints of a semester schedule...