POSSE Worcester State begins tomorrow, with 8 brave professors learning how to dive into open source communities for the entire week - say hello on #teachingopensource in irc.freenode.net if you're interested. We'll be working on Sugar on a Stick for the week, and Peter Robinson and Walter Bender are here in town co-teaching with me; should be good times. Here are some of my notes from dinner today:
Professors generally seem surprised (or amused?) that open source community members don't know "basic" things about academia, like "course schedules get planned over a year in advance" or "we can't just install new software on lab machines, we need to tell IT what to load for us for the whole school year in advance, and we can't really change it for a whole year once it's on." Similarly, open source community members seem surprised academics don't know things we consider basic, like "release early release often," or how to use IRC. We need to find ways to draw out this tacit knowledge from both sets of brains.
One issue when teaching more than a few students at a time is basic infrastructure - what computers do the students use, what's on them, and who controls/administers them? If students use their own laptops, they get distracted during class, have to administer their own machines (and 10 students installing the same thing will make 10 different mistakes to debug), and so froth. If lab machines are used, faculty can't necessarily control the software on it either - for instance, if they can only update the software once a year, they could only try every other Fedora version, since Fedora comes out with a new release every 6 months.
Enrollment numbers; they're a problem. Or rather, their downward slide has been a problem - but academia takes years to react to this sort of thing, so the effects from the past decade have been felt fairly recently - and even if enrollment numbers immediately improve, it'll take a while for the academic environment to adjust back up to having numbers at that level.
Sometimes new folks get intimidated by not knowing the process by which they can contribute to FOSS, and one common reaction is trying (and failing) how to reduce that indimidation via sheer increase in technical skill. In other words, "if only I could CODE BETTER I could contribute!" mindset which leads to someone going off and reading C textbooks for 5 years in order to become "ready to start contributing" - instead of simply starting to talk to people. However, talking in the way open source communities are used to conversing is a difficult thing to figure out if you're new to it.
Some professors are serious about pedagogical design - Peter and Karl started talking about an education research paper on whether it's easier to learn imperative languages before object-oriented ones or vice versa (according to the paper, the latter). This research and their discussions aren't abstract meaningless stuff - for instance, it settles the question (for hundreds of students) as to whether they learn Java (object-oriented) or C (imperative) first in classes. But this (scholarly articles on educational techniques) is a resource stream that FOSS communities often don't draw from.