Collaborative Lesson Development - Why Not?

This post originally appeared on the Software Carpentry website.

A few weeks ago, Greg Wilson asked me:

Why is there so little open, collaborative development of lesson plans and curricula? Is there something that makes teaching different from coding (e.g., open source software) and from writing (e.g., Wikipedia)?

A dozen emails later, I can't claim that we're much closer to a definitive answer, but we have come up with a working hypothesis. We'd be very interested in feedback.

Three key ingredients appear to be required for collaborative development of any sort of material:

1. a host who provides the infrastructure for the project,
2. lead developers and maintainers who integrate and manage contributions, and
3. contributors who create the actual materials themselves.

For example, the continued development of IPython requires GitHub, the core development team (especially Fernando Pérez and Brian Granger), and scientists/coders who understand pull requests. The growth of Wikipedia required the Wikimedia Foundation, the core admins, and interested readers who understand how to use a browser-based Wiki editor.

The non-existence of open, collaborative lessons could be caused by any of these three factors being absent. Greg believes that the biggest limitation is #2: while lots of people in education can write and edit lesson plans, they appear not to have taken on the broader role of managing the development of collaborative materials. However, the existence of edited books suggests that this shouldn't seem like a strange activity.

My vote is that the biggest limitation is #3: potential contributors need a certain level of familiarity and comfort with the tools that enable contributions (such as version control or a browser-based Wiki editor). I suspect that these skills may be lacking among educators, whereas they're not lacking to the same extent among coders or even among Wikipedia readers.

An interesting exception is the lesson materials Software Carpentry is developing. Software Carpentry arguably works because of GitHub, Greg and other topic editors, and instructors who understand pull requests. The first and third of these are possible largely because the contributors to the Software Carpentry lessons are, by design, also scientists and coders.

Importantly, the intervention required to promote collaborative lesson development will depend on where the bottleneck lies:

1. If the shortcoming is in hosting and infrastructure, somebody needs to fund, maintain, and (most importantly) advertise a central website for open curriculum development. Curriki appears to be having a go at this (although Greg notes that many similar efforts have failed in the past). An important design consideration should be to make the skill level required for contribution as low as possible (think Wiki editor rather than fork/pull).
2. If the shortcoming is in developers/maintainers, a set of current leaders in education need to volunteer or be offered incentives to play a lead role in developing and managing a set of materials for their areas of expertise. This role could and should be recognized as equivalent to being the editor of a published book.
3. If the shortcoming is in the contributors, training in collaborative web tools should be provided to educators who express interest in the ideas of open lesson development. While incentives could also be useful here, contributors to open source software and Wikipedia generally receive no direct compensation for their work.

Or maybe all of this is a work in progress and we just need to wait for the next generation of tech-savvy educators (and students).

So, that's about as far as we've gotten. What do you think?