[Date Prev][Date Next] [Thread Prev][Thread Next]
[Osdc-edu-authors] ARTICLE READY: Frontiers in Education TOS panel
- From: Mel Chua <mel redhat com>
- To: OSDC Education authors <osdc-edu-authors redhat com>
- Subject: [Osdc-edu-authors] ARTICLE READY: Frontiers in Education TOS panel
- Date: Thu, 04 Nov 2010 18:15:37 -0400
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
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
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
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
4. A blog post by Mel Chua illustrating how an experienced FOSS
contributor might think about a projec they are encountering for the
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.
[Date Prev][Date Next] [Thread Prev][Thread Next]