Platforms

This post originally appeared on the Software Carpentry website.

After Thursday's post-mortem on the latest offering of Software Carpentry at the Universitiy of Toronto, I had a chance to talk further with Jon Pipitone, who was one of the tutors (and who is just wrapping up an M.Sc. looking at code quality in climate models). We got onto the topic of infrastructure for Version 4, which needs to be settled quickly.

1. a way to deliver content to students, including text and images, audio/video, exercises (with solutions), sample data sets, and useful software;
2. a way for students to feed questions back to the course organizers (asynchronously through email and bulletin boards and/or synchronously through VoIP and desktop sharing);
3. a way for instructors (who may or may not be contributors) to respond to students;
4. a way for lay contributors (who may also be students) to offer new content, from pointing out typos to providing exercises or whole new lectures; and
5. a way for core contributors to manage and edit contributions, create some of their own, et cetera.

This description implies some social infrastructure, including:

1. some core contributors who are creating lots of course content, and probably teaching the course as well;
2. a second tier of instructors who are creating less content but also interacting with students; and
3. students, who may be registered in a course of some kind or working through the material on their own (and who may eventually move up to answering others' questions and eventually to creating content).

This sounds like what you'd find in an open source project (regular users, occasional testers or bug reporters, and contributors) at least as much as it sounds like a traditional college course (students, teaching assistants, and professors). The most important difference is that the divisions between the latter three roles are sharper and deeper than the divisions in open source projects: some undergrad students eventually go to grad school and become TAs, and some of those eventually become faculty, but it's almost unheard of for someone to be in two of those categories at once, or to "bubble up" from one to the next based solely on ability and enthusiasm. That must happen if Software Carpentry is to become self-sustaining: while over 140,000 people have looked at the existing material in the past five years, only three dozen have ever sent bug reports, and only four of those have contributed any substantial content. Whatever we use to accomplish tasks 1-5 above must therefore draw people in and make it easy for them to use, ask, answer, and contribute.

With that out of the way, here are a few options for discussion:

• Project: use SourceForge or Google Code as a host.
• Retro: a classic turn-of-the-century web site with static HTML for content, bulletin boards and/or mailing lists for discussion, Trac with Subversion for project management.
• Social: a WordPress blog with lectures and other content as posts (updated several times, with threaded comments for feedback).
• Turnkey: a fully-fledged learning management system such as Moodle.
• Wiki: like Retro, but with the content in a wiki.

So how do they stack up?

A bit of explanation:

• Project hosting services require little or no setup, but would force us to manage this as a software development project, rather than as a writing project: self-tests and "try this at home" examples aren't built in, and neither of the big open source project hosting sites would be happy if we used them as a video server.
• The "retro" option would require us to "roll our own" on a lot of things, which would be fun (I like to program) but wouldn't directly deliver value to scientists.
• WordPress is easy to set up, but doesn't have very many development-oriented or education-oriented plugins, and isn't designed to host video snippets or live examples. I think that building the course as a blog is a neat idea, but the novelty would soon wear off...
• Learning management systems like Moodle have a lot we don't need (recording grades, for example), but a lot that we do (managing course bundles). I gave this category -1 for ease of setup because I'm unfamiliar with it, and 0 for "easy for people to contribute" because the LMSes I've looked at (ATutor, OLAT, Moodle, and Sakai) all seem to have significant learning overheads for creating content—they're a bigger hammer than I (think I) need. Of course, that could just be unfamiliarity again...
• A wiki would be easy to set up and maintain, but in my experience, editing large volumes of material in a browser is unpleasant, and there's little support for managing updates, particularly by concurrent authors.

As always, I'd welcome your thoughts...