[Osdc-edu-authors] Article ready: Three unspoken blockers that prevent professors from teaching open source community participation

[Karsten Wade]

That's a great conversation starter; this article articulates some
very important points that do not have immediately clear solutions.

- Karsten

On Thu, Nov 04, 2010 at 06:02:31PM -0400, Mel Chua wrote:
> 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. :)
>
> --Mel
>
> -----
>
> http://opensource.com/education/10/11/three-unspoken-blockers-prevent-professors-teaching-open-source-community-participat
>
> 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  
> 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.
>
> _______________________________________________
> Osdc-edu-authors mailing list
> Osdc-edu-authors at redhat.com
> https://www.redhat.com/mailman/listinfo/osdc-edu-authors

-- 
name:  Karsten 'quaid' Wade, Sr. Community Gardener
team:                Red Hat Community Architecture 
uri:               http://TheOpenSourceWay.org/wiki
gpg:                                       AD0E0C41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/osdc-edu-authors/attachments/20101104/7515dd5d/attachment.sig>