Mel Chua is a contagiously enthusiastic hacker, writer, and educator with over a decade of teaching and curriculum development experience and a solid track record in leadership positions at Red Hat, One Laptop Per Child, Sugar Labs, Fedora, and other Free, Libre, and Open Source Software (FLOSS) communities. A graduate student at Purdue University, Mel bridges academic research on successful communities with deep personal experience getting her hands dirty building them.
These days, Mel spends most of her time with on open source in education, teaching professors how to teach open source and otherwise working to push patches of successful open source cultural habits around learning and teaching "upstream" to classrooms in academia. In her hypothetically existent amounts of free time, she collects quirky textbooks, works on undergraduate engineering education reform, and plays piano, occasionally at the same time.
Authored Comments
I think that it's a great idea to offer opportunities to learn these sorts of tools, and to become comfortable exploring, tinkering on, and experimenting with the sort of unbridled playfulness computing on an open source software stack can offer.
However, I wouldn't call these courses "remedial" - that implies the expectation that, say, emacs knowledge is a prerequisite and that if you didn't recompile your kernel in high school you're somehow deficient - which is certainly not the case. Students, especially pre-college students, have had different opportunities to be exposed to - and interested in pursuing - these sorts of things. (Some of us got yelled at by our parents for dual-booting the only computer in the house with Fedora Core 1. This tends to stifle exploration somewhat.)
And I'd emphasize the mindset just as much as the specific "can use software package X" skills. I can rote-train a monkey to use vim, but encouraging someone to ask questions about what's out there, explore repositories, crawl websites, ask friends what sorts of tools they use, ask upstreams for those tools how to tweak them... that's a different skill and mindset entirely, and given how rapidly the software landscape changes, it's the mindset students will need to keep their toolboxes sharp.
As someone from the open source community who's looking at walking down the long road of becoming a professor myself someday, thank you for the preview. Two (somewhat-related) thoughts came up in my mind while reading, and I'll attempt to articulate them here.
One of the things that many - not all, but a pretty good portion, in my experience - people in the open source community take for granted is an environment where abundance is the default. Try things out, toss ideas around... computing power is cheap, the software is free, and you've pretty much got nothing to lose except the small amount of time you've invested. But the process of becoming an academic takes a long time and comes at a high cost to the grad student or new professor (time-wise, financially, and in terms of career opportunity and mobility), and that probably changes the perception of risk.
When a newcomer enters the world of open source, failure is expected - even encouraged as a way of learning. The same happens in good classrooms, I'd argue. The difference I've noticed (and had pointed out to me) while working with your class at Allegheny is that classrooms have a timeout for success - by the end of term, that failure must have turned into learning, and for every single student in the class (ideally). In the open source world, individuals can keep running down a path as long as you have the interest and the inclination; there's no need to stop and pause for an exam, because you're on your own learning timeline and going for a task you've set rather than a degree that someone else has written the requirements for. So the assumptions we have about the kinds of learners that come into FOSS communities, the rate at which they'll enter (individually, rather than 40 all at once) and the sort of scaffolding they need in order to hit what they define as "success" within the timeframe they're looking for... may need to be reexamined when working with classrooms.
I'm still forming these thoughts in my head - my thinking here is not yet clear - but these were the first two things that came to mind.