[Date Prev][Date Next] [Thread Prev][Thread Next]
[Osdc-edu-authors] Article ready: Three unspoken blockers that prevent professors from teaching open source community participation
- From: Mel Chua <mel redhat com>
- To: OSDC Education authors <osdc-edu-authors redhat com>
- Subject: [Osdc-edu-authors] Article ready: Three unspoken blockers that prevent professors from teaching open source community participation
- Date: Thu, 04 Nov 2010 18:02:31 -0400
Article from FIE, final draft from me, ready for editing, image
insertion, and publishing. Mary et al, how does this look? (text pasted
below for those who don't have author access to osdc yet)
Just got text from another article by Sebastian Dziallas (who was also
at the conference), I'll upload it to Drupal and send that link to the
list in just a moment. We're sorta racing to see who can write the most
articles from that conference fastest. :)
One of the hardest things about trying to bridge two worlds - for
instance, open source communities and academic institutions - is all the
stuff you don't hear on a daily basis when you're working remotely.
Sometimes it takes several rounds of garlic bread and pasta for people
to begin articulating what's blocking them from teaching their students
how to participate in FOSS communities. Sebastian Dziallas and I sat
down last weekend at the 2010 Frontiers in Education conference with a
group of professors from the Teaching Open Source community. "What are
the biggest blockers that you're facing in doing this," we asked, "that
people in the open source world just don't know about or understand?"
Here are their answers.
Blocker #1: Intellectual Property Policies, aka "no, you can't release
that under an open license."
At some schools, if you make it on campus, for campus, or with resources
from campus - guess who owns it? Yep: campus. One way colleges and
universities make money is "technology transfer," a form of intellectual
serfhood - if you're a professor, a student, or a lab, you get resources
(students, classes, space, equipment) from the school, but all the IP
you produce is owned by the school, so the school takes care of
licensing that IP out to companies that want to use it... and keeps the
If you're a school, this arrangement works out in your favor - so you
put policies in place specifically preventing students and professors
for giving away their "schoolwork" for free, because... well, that's how
you make money. The concept of open licensing as a benefit (free
marketing!) to the university instead of a drain (giving away precious
IP we'd otherwise sell at a profit!) is new to many places, and when
you're trying to get a project started for a 10-semester class, you
can't afford to spend all 10 weeks patiently educating university
administration about the benefits of licensing (while you simultaneously
try to learn data structures in Java).
So that's one bug.
Blocker #2: Student Privacy, aka "we're going to make your students fill
out forms now before they can release their work for class."
Even if professors (and students) think it would be beneficial for
student work and professor feedback on that work to be out "in the open"
where more people can see and comment on and benefit from it, clearance
has to be specifically sought because of federal regulations like the
United States' Family Educational Rights and Privacy Act (FERPA,
http://www2.ed.gov/policy/gen/guid/fpco/ferpa/index.html). These are
designed to keep sensitive data about students (read: grades) under
their own control. But it's a fine line to walk - can you require people
to upload graded classwork to a public server? Do your comments and
evaluations there? Can you require them to list their name? To work and
interact with a community they may not want to work with (for instance,
if your class is a requirement and students aren't there voluntarily)?
Different institutions have different policies, and some professors may
not have the time, the legal expertise, the political capital, or the
ability to take the risk and step forth for the advocacy this might take
at their particular school. When you're at a school to teach students,
you want to spend time teaching them, not responding to letters from
administrators concerned about families complaining that you're
"broadcasting their child's private data."
Blocker #3: IT support, - or really, the lack thereof.
People from the open source world are used to the following workflow
when they want to show others a new piece of (open source) software:
1. Go to the computer sitting on your desk.
2. Download and install the software.
3. Email your friend the link to your webserver.
Professors can do the same thing, but once they want to make that
resource available to the students in their classes, they may have to...
1. Ask IT for an internally hosted box
2. Wait a while
3. "When can my TA and I have an account on a server? Any server!
Any server at all!"
4. "Yes, yes, I'll administer it myself (in my nonexistent free time)."
5. Fill out more forms
6. Worry that half the semester is already over
7. Wonder how much longer this is going to take
8. ...and so on.
Even if you get IT's permission to try out something, or persuade your
students to try out some open source applications on their own, the
question then becomes one of support. If your students install Linux and
tinker around and crash their computer, IT isn't going to fix it.
Students know this, and often don't want to take the risk. If they do,
and things break, they'll come to you - and so in addition to being a
professor, you now get to provide technical support for your entire
class for applications you are probably not familiar with debugging.
How can we help?
Remember, these comments came from professors who have already fought
through whatever they needed to figure out in order to start getting
their students involved. These are the people who are already clearing
out these blockers - often working for several years to even be able to
start to teach their students about FOSS. These professors are still few
in number, and the first of their kind, oftentimes standing as the only
faculty member in their institution that doesn't think the idea of
teaching FOSS is crazy. These people are our allies. How can we help
them get past the "community participation bugs" that are stumping them?
Thanks to Heidi Ellis (Western New England College), Matthew Burke
(George Washington University), Clif Kussmaul (Muhlenberg College), Greg
Hislop (Drexel University), Mihaela Sabin (University of New Hampshire),
and Steve Jacobs (Rochester Institute of Technology) - for the
discussion that led to these notes, and to Sebastian Dziallas (Olin
College) for helping me write them up into this article.
[Date Prev][Date Next] [Thread Prev][Thread Next]