Open Source Educator (Part Two: Academia)

<polyachka> what is difficult about open source culture?

<mchua> Things like “release early, release often” – in academia, you keep your paper private until it’s *completely* polished, you don’t want to show it to anyone before then.

<mchua> So it’s hard sometimes to break professors of that habit.

<polyachka> what else?

<mchua> Or the “ask forgiveness, not permission” mentality – people are so used to being assigned work, asking what to do, that it’s weird for them (professors and students both, sometimes) to realize that they’re supposed to come up with their own ideas and just start *doing* them.

<mchua> The radical transparency is a big shift. “Begin with the finishing touches,” as well. Oftentimes in academia you get credit for 100% original work – so you always, always start from scratch… instead of finding the existing code someone else has written that will do 90% of what you want, and then tweaking it until it does the rest.

<polyachka> don’t they want to get credit for their work, and in open source it is not that clear who created what?

<mchua> Oh, in open source it’s *extremely* clear who created what. Every single commit, every line I change in a wiki, every sentence I say in a meeting – all that is logged, and it’s clear *I* said it.

<mchua> Professors have reported that it’s actually easier to grade open source work. For instance… there was a group of co-op students at RIT making a math game Activity. And their professor asked me to grade their work, as an external evaluator.

<mchua> Now, I’ve done grading before… I was a TA throughout college, and it’s usually this horrible tedious messy thing. But these students had done their work right on git.sugarlabs.org, they’d kept their documentation on the Sugar Labs wiki. So all I did was pop into the git logs – http://git.sugarlabs.org/project-xavier – and poof, there was *every* line of code every student had written… I could go in and look at coding style, cleanness, difficulty of the modifications, etc.

<polyachka> so you do get to interact with students too, not just professors

<mchua> Yeah, sometimes I’ll go visit classrooms. One of the perks of the job. 🙂

<polyachka> tell me about that project with Remy

<mchua> That project wasn’t with Remy – I think he had just started at RIT back then.

<polyachka> is it a big open source community at RIT?

<mchua> It’s pretty big compared to most other schools. Seneca and OSU have larger open source groups (in terms of professors who specifically teach open source participation and students actively working on getting involved in projects – open source as an explicit aim there) but they’ve also been doing it for a bit longer.

<polyachka> how many students participate in open source projects there?

<mchua> I… don’t know how many students, you’d have to ask Remy or Steve Jacobs or Dave Shein (or one of the other professors) for that.

<mchua> The neat thing about the Teaching Open Source community, though, is that you find these professors all over the place. There are these little pockets of open source activity – oftentimes just one professor thinking it’s the right thing to do – and it’s amazing to introduce them to each other because all of a sudden, “aha! oh, I’ve handled that before in my class, let me tell you how…”

<polyachka> so what other open source projects do you get professors involved into, besides Sugar

<mchua> Other than Sugar, it’s largely Fedora – or the intersection between Sugar and Fedora.

<mchua> Those are the two I spend most of my time in, and therefore the ones I’m best at getting others into… but we stress that we’re teaching general skills and tools and cultural principles, that the aim is for them to be able to get students into *any* open source project.

<mchua> So they might leave the workshop and think “okay, I want to get involved in GNOME because they do some great accessibility work that’s an interest of mine.” Or “well, I’m more of a hardware person, maybe I’ll do some beagleboard stuff with my students.” And that’s great – we don’t want to limit people to just two projects!