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
Kussmaul's "use/study/add/build/leverage" framework was something I found surprisingly useful, especially in its simplicity. One thing I appreciate more and more about academia is how it actually deliberately structures in time for reflection and evaluation (although I don't always agree with the usefulness of the evaluations). How are we doing things, how well are we doing them compared to where we thought we'd be, and how can we recalibrate and improve?
I was surprised by the number of people we got to attend the panel (maybe 20 or so?) and how (1) willing they were to listen to these ideas, but also (2) how discouraged they felt about implementing them in their own institutions. The general sense I got was "wow, that's great - but that would never work in my school." Which... is a bit discouraging. Teaching open source has worked for big schools, small schools, engineering schools, liberal arts schools...
I wonder what we could do - more case studies by type of institution? More outreach? More school visits? More academic conference presence? - to show that it's possible.
Oh boy. I have a million questions, and should write them down and start posting them in comments on your articles. Right now, only a few coherent ones come out (it's been a long week).
From the first link you posted: "...I did not choose an academic life to “get tenure.” I went academic because I wanted to be around eager young people, mentor students, and conduct research on questions in which I had a burning interest. Nam’s advice was that if I do that then tenure should take care of itself." I agree with this motivation for entering academia - but how idealistic is Nam's advice? How important is tenure anyhow, and what options exist for those who want to be academics but don't think that the job security of tenure is important? What privileges (if any) are denied to those who take non-tenure-track positions, and would any of them affect a faculty member's ability to bring open source to their institutions?
As a faculty member, how can you make the contributions, relationships, networks, and general "karma" (to misuse the term somewhat) you build within an open source community you're working with count towards your professional evaluation?
What are the different factors that might make it easier or harder for a faculty member to bring open source participation into their classes? Pre-tenure vs post-tenure, large research institution vs small teaching institution, scholarly discipline - do those matter, or is it much more about individual background/FOSS-fluency/inclination/interest? (In other words, if I want to teach my students open source participation, what sort of institution and position should I seek as an academic, or does that choice not really matter?)
More later. :)