A number of folks from the 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 have students for a class "about FOSS" for only 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 careers? 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 a 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 end user 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 to 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:
- Be around and accountable for at least a semester, which is a long time when your project has six-month release cycles.
- 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.
Some helpful resources for those considering involving university-level students in open source projects
- 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 bug trackers.
- POSSE, a one-week workshop for college professors interested in incorporating FOSS community participation into their courses.
- A community characterization worksheet used 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.
- A blog post by Mel Chua illustrating how experienced FOSS contributors might think about projects 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.
1 Comment