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 cash.
If you're a school, this arrangement works out in your favor, so you put policies in place specifically preventing students and professors from 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 ten-week class, you can't afford to spend all ten 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) . 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? Can you do your comments and evaluations there? Can you require them to list their names? 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 children's private data.
Blocker #3: IT support, or 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 web server.
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 first:
1. Ask IT for an internally hosted box.
2. Wait a while.
3. Try asking, "When can my TA and I have an account on a server? Any server! Any server at all!"
4. Offer, "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 computers, 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 who 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.
17 Comments