[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Osdc-edu-authors] ARTICLE READY: Frontiers in Education TOS panel

Hi Mel:
This article is edited and ready to go - it is just missing the image from Heidi for the panel.

thank you, Jeff

Mel Chua wrote:
Here's the article by Sebastian, I uploaded it to Drupal and filled in the appropriate links. I'll get a photo of the panel from Heidi Ellis hopefully tonight and put that in, and then it'll need final editing, a header image, and then the final publishing push.

Mary et al, how's this look? Anything else Sebastian (or I, with my Magical OSDC/edu Editorship Privs) need to do?



A number of folks from the Teaching Open Source Teaching Open Source community had a panel at the Frontiers in Education 2010 conference, which is attended by college and university professors interested in improving engineering education. The panel's main thesis was that participating in FOSS communities was one way to give students a better educational experience.

Matthew Burke, George Washington University

First up was Matthew Burke on the topic of "open source across the curriculum." When you only have students for a class "about FOSS" for one semester, how do you get into their heads that they're not "done with FOSS" after the class ends, but should be using these skills and tools and methods for the rest of their academic and professional career? One way is to build extracurricular activities for followup, such as internships or activities with on-campus clubs. Another way is integrating little bits of FOSS into the rest of the curriculum. Even if a class doesn't focus specifically on FOSS, it can use FOSS tools, delve into FOSS history, and use FOSS code examples to illuminate concepts.

"You get better at writing lots of software by looking and working with lots of software," said Burke, who also has a background in consulting for industry. "[We should] look at development techniques in open source projects... and incoporate these into our courses." Burke himself makes his students submit their homework assignments using the git version control system, and says his biggest challenge is that "open source projects aren't like textbooks." You can't just tell your class to "complete assignment 2.1" - problems in those communities are not the well-formed, fully-scaffolded guided learning experiences that students may be used to.

Heidi Ellis, Western New England College

Ellis teaches a class of 11 senior undergraduates working on GNOME Caribou, a virtual keyboard for those with special accessibility needs. "Students working on open source are highly motivated," she explained, because they're surrounded by a community full of intrinsically motivated individuals. Her own involvement in FOSS began when a former student went abroad and came back talking about a project called Sahana that they had gotten involved with. Ellis encouraged the student to continue, offering to mentor an independent study so other undergraduates could become involved; the group demoed a volunteer management model to the Sahana community at the end of the summer. Fast forward several semesters, and Ellis now has her students working on a range of Humanitarian FOSS projects, with more experienced students returning to mentor the next round of undergraduate contributors.

One thing she pointed out was the issue of grading. Since the FOSS world is highly improvisational, it's hard to specify what needs to happen at the end of the semester product-wise in order to achieve an 'A' - a student could do excellent work but not have a "finished product" because (for instance) the maintainer was on vacation and didn't accept their patch in time. Ellis therefore grades students on process rather than product, since community participation in a large-scale distributed project is specifically what she is trying to teach her class of software engineers.

Clif Kussmaul, Muhlenberg College

"FOSS projects and communities vary dramatically," said Kussmaul as he displayed a slide of various FOSS projects arranged by number of contributors and the degree to which the project was decentralized. Kussmaul tries to step his students through the process of becoming open source contributors in an accelerated manner, with a "use / study / add / build / leverage" framework.

First he has them use the software - just download it, try it out, see what it's like from the enduser point of view. Next they crack the hood and study what the code looks like and what it works. Once they've gotten their bearings, they add minor enhancements to the code to get used to the workflow of contribution. When that feels comfortable, they start to build and own their own components for the codebase, and also work on deploying the software they're developing, which teaches them how to leverage their software work to solve the actual problems of end-users.

Greg Hislop, Drexel University

"It can be rewarding for an instructor to work in FOSS," said Hislop. This immediately reminded me of something community guru Greg DeKoenigsberg blogged months ago: "[FOSS participation] must, however, always be rewarding." Hislop told the story of how his own participation in the Teaching Open Source community led him into the SoftHum (Software for Humanitarian Purposes) and FOSS Learning Center projects. Stop thinking about code and start thinking about community," he advised.

Hislop emphasized that teaching open source was not a trivial or easy thing to begin doing, but that the payoff could be tremendous. He described dealing with the undependability of people joining and leaving projects, which is something I had heard professors in the Teaching Open Source community discuss before. To teach open source community work is to give your students freedom to explore... and to give up control of the classroom. Giving up this control is risky - will they succeed? will they learn what you're require to teach? - and the level of risk, and how to balance that with the potential of FOSS community participation to give students a better learning experience, is something that every educator who is teaching open source is struggling to find their own balance for.

Mel Chua, Red Hat

Academic communties and FOSS communties - and communities of all sorts - are places where people come together to work on common problems, explained Chua as she walked around handing out scribbled notes. Professors already know how to work within the rules of academia; the trick to bridging that world and the FOSS one is figuring out the parallel structures within them - how do you ask questions, where do people gather to talk, what is considered a "valid contribution" in each world? "Professors can help open source communities as much as vice versa," explained Chua. "We're terrible at scaffolding and recruiting new contributors... you [professors] know how to get large numbers of people new to an area quickly up to speed in it. Please teach us how!"

At this point, I stepped in and explained to the listening professors exactly why FOSS community members would be motivated to help them. When we see things like Allegheny College professor Matt Jadud's offer to have his class do interface design, we think "ooh, new contributors!" but also have the added reassurance that these contributors will:

1. Be around and accountable for at least a semester, which is a long time when your project has 6-month release cycles, and... 2. Have a professor to help them navigate the process of learning about the project, so we don't have to answer the same question about wikis 20 times in a row.

<picture of panel, which we can get from Heidi Ellis>

Some helpful resources for those considering involving university-level students in open source projects

1. The Teaching Open Source Textbook, an open content resource intended to be a supplementary resource for professors getting their students started with FOSS development; it has exercises and assignments that teach fundamental FOSS participation tools such as version control systems and bugtrackers. 2. POSSE, a one-week workshop for college professors interested in incorporating FOSS community participation into their courses. 3. A community characterization worksheet sed as a class assignment at Rochester Institute of Technology to get students thinking critically about the structure of FOSS communties they are encountering for the first time. 4. A blog post by Mel Chua illustrating how an experienced FOSS contributor might think about a projec they are encountering for the first time.

If you want to "view source" for this article, my notes for it come in part from my Twitter stream starting here, and in part from Steve Jacobs from RIT who also liveblogged the sessions.

Osdc-edu-authors mailing list
Osdc-edu-authors redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]