Software Carpentry

Helping scientists make better software since 1997


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.

There are two kinds of infrastructure: technical and social. Each shapes the other, so decisions about them have to be made together. On the technical side, Software Carpentry must have:

  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?

Project Retro Social Turnkey Wiki
Easy to set up/administer/maintain? +1 0 0 0 +1
Easy for people to contribute? -1 -1 0 -1 0
Comes with everything? 0 -1 0 +1 0
Flexible content delivery? -1 0 -1 +1 -1
Overall -1 -1 -1 -1 -1

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…


Written by Greg Wilson

2010/04/08 at 02:27

Posted in Tooling, Version 4

5 Responses

Subscribe to comments with RSS.

  1. Check out BuddyPress ( – it adds a bunch of “social media” features to WordPress.

    Irving Reid

    2010/04/08 at 12:57

  2. I’ve worked with Moodle, and it is approximately a pain in the ass.

    It might be worth having a look at two examples: cs193p (videos on iTunes, a wordpress blog to distribute assignments and sample code, and take public questions. The other example is what Philip Greenspun’s SEIA course or his sort-of spin-off, OpenACS, have been up to. Their chosen focus appears to be knowledge management.

    Stephen van Egmond

    2010/04/08 at 13:51

  3. I think you should bias yourself as much as possible towards systems which produce vanilla HTML which can be simply copied from machine to machine without any webserver configuration. With dynamic content this is usually impossible to do *completely*, but even being able to do it mostly would be a win.

    Peter Boothe

    2010/04/09 at 02:36

  4. Greg, I’ve been using Moodle for years and it is a breeze to administer and really easy to produce content in. Of all the LMS systems we have used over the last 10 years at ITESM, this one has the vote of both students AND faculty in terms of ease of use.

    Ken Bauer

    2010/04/09 at 04:31

  5. A fifth option somewhere between WordPress and Moodle would be one of the big content management systems. I’ve been using Drupal for my sites and I really like it. It’s a little more work to setup and maintain than WordPress, but also more powerful and extensible. Versioning is built in and there are strong contributed modules for handling things like video. Integrated role based permissions would also make your 3 tiers of contributors easy to manage securely. There is also a new Classroom Module, but I haven’t tried it out yet. I’m sure that the other major systems (Joomla, etc.) are pretty equivalent in these regards.

    Ethan White

    2010/04/09 at 21:56

Comments are closed.

%d bloggers like this: