[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: [Osdc-edu-authors] ARTICLE READY: Frontiers in Education TOS panel
- From: Jeffrey Mackanic <mackanic redhat com>
- To: Mel Chua <mel redhat com>
- Cc: OSDC Education authors <osdc-edu-authors redhat com>
- Subject: Re: [Osdc-edu-authors] ARTICLE READY: Frontiers in Education TOS panel
- Date: Thu, 11 Nov 2010 17:02:54 -0500
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
"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
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
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
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]