The potential for collaborative lesson development for college coursework

Last week we formally announced a semester long Data Carpentry course that Zack Brym and I have been building over the last year. One of the things I'm most excited about in this effort is our attempt to support collaborative lesson development for university/college coursework.

I've experience first hand the potential for this sort of collaborative lesson development though the development of workshop lessons in Software Carpentry and Data Carpentry over the last four years. Many of the workshop lessons developed by these two organizations now have 100+ contributors. As far as I'm aware, Software Carpentry was the first demonstration that large-scale open collaboration on lessons would work (but I'd love to hear of earlier examples if folks are aware of them).

Having seen this work so effectively for workshops, I'm now interested in seeing how well it can work for more traditional coursework, because I think there are a lot of important upsides to taking this approach. I like to call this "open course development" in homage to the "open source development" from which it has spawned.

Most college and university courses that I'm aware of start in one of three ways: 1) someone sits down and develops a course completely from scratch; 2) the course directly follows a text book; or 3) a new professor inherits a course from the person who taught it previously and adapts it.

Developing a course from scratch, even one following a text book fairly closely, is a huge time commitment. In contrast, with collaboratively developed courses new faculty, or faculty teaching new courses, wouldn't need to start from scratch. They would be able to pick up an existing course to adapt and improve it. I can't even begin to describe how much easier this would have made my first few years as a faculty member. More generally, if we are teaching similar courses across dozens or hundreds of universities, it is much more efficient to share the effort of building and improving those courses than to have each person who teaches them do so independently.

In addition to the time and energy, there are often a lot of things that don't work well the first time you teach a course and it typically takes a few rounds of teaching it to figure what works best. We are still make substantive changes and additions to the Data Carpentry Semester Course course in its second year at the University of Florida. One of the challenges of developing lessons in isolation is that you only teach a class every 1 or 2 years. This makes it hard/slow to learn what works and what doesn't. In contrast, a collaboratively developed course might be taught dozens or hundreds of times each year, allowing the course to be improved much more rapidly through large scale sampling and discussion of content and delivery. In addition to having more information, the fact that faculty are spending less time developing courses from scratch should leave them with more time for improving the materials. In combination this results in the potential for higher quality courses across universities.

By involving large numbers of lesson developers, collaborative development also has the potential to help make courses more accurate, more up-to-date, and more approachable by novices. More lesson developers means a greater chance of having an expert on any particular topic involved, thus making the material more accurate and reducing the amount of bad practice/knowledge that gets taught. New faculty with more recent training on the development team can help keep the material more up-to-date than the case when the same person teaches the same course for 20 years. More lesson developers also increases the likelihood that someone who isn't an expert in any given piece of material is also involved, which should help make sure that the lesson avoids issues with expert blindness, thus making the material more accessible to students.

Of course, collaborative college/university lesson development will not be without challenges. The skills required for collaborative lesson development in the style of Software and Data Carpentry require proficiency with computational approaches not familiar to many academics. The necessary skills include things like version control, developing materials in markdown, and working with static site generators like Jekyll. This means this approach is currently most accessible for those with some computational training and may initially work best for computing focused courses. In addition, organizing open collaborations takes time and energy, as does collectively deciding on how to design and update classes. Universities and colleges are not typically good at valuing time invested in non-traditional efforts and that would need to change to help support those managing development of courses with large numbers of faculty involved. More substantial may be the fact that faculty are not used to collaborating with other people on course development and are therefore not used to compromising and negotiating what should go into a course. This can be compensated for to some degree by making courses easy to modify and customize, as we've tried to do with the Data Carpentry Semester course, but ultimately there will still need to be a shift from prioritizing the personal desires of the faculty member to the best interests of the course more broadly. This also emphasizes that this approach will work best in cases where there are likely to be a number of departments/colleges/universities that all want/need to teach the same general material.

Is it time? When I built my first version of Programming for Biologists back in 2010 I was really excited about the potential for collaborative open course development. I built the course using Drupal, emailed a bunch of my friends who were teaching similar courses and said "Hey, we should work together on this stuff", and stuck some welcoming language on the homepage. Nothing happened. A couple of years ago I was on sabbatical at the University of North Carolina and got the opportunity to talk a fair bit with Elliot Hauser who was part of a team trying to encourage this through a start-up called Coursefork. I was somewhat skeptical that this approach would work broadly, but I thought it was really awesome that they were trying. They ended up pivoting to focus on helping computing education through a somewhat different route and became trinket.

So why might this work now? I think there are three things that increase the possibility of this becoming a bigger deal going forward. First, open source software development is becoming more frequent in academia. It still isn't rewarded anywhere close to sufficiently (link), but the ethos of using and contributing to collaboratively developed tools is growing. Second, the technical tools that make this kind of collaboration easier are becoming more widely used and easier to learn through training efforts like Software Carpentry. Third, more and more people are actively developing university courses using these tools and making them available under open source licenses. E.g., Jenny Bryan's Stat 545 and Karl Broman's Tools for Reproducible Research. Our course has certainly benefited from existing materials such as these and feedback from a broad range of instructors. I guess we'll see what happens next.