Three unspoken blockers that prevent professors from teaching open source community participation

No readers like this yet.
unspoken blockers

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."

Download Free eBookAt 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.

User profile image.
Mel Chua is a contagiously enthusiastic hacker, writer, and educator with over a decade of teaching and curriculum development experience and a solid track record in leadership positions at Red Hat, One Laptop Per Child, Sugar Labs, Fedora, and other Free, Libre, and Open Source Software (FLOSS) communities.


Blocker 1 is appalling to me. I understand that it costs money to run an educational institution, but this seems too extreme.

Regarding physical IT resources: how about <a href="">GuruPlugs</a> or even AWS free usage tier accounts? The GuruPlugs would still require internet service from somewhere, but I'm guessing this would be possible with a little troubleshooting. AWS would be good, except for that you need to provide a credit card to get running (and if you aren't careful, you'll rack up charges).

Another option might be to organize decommissioned old govt boxes to be relayed in batches to student organizations or classes that are doing work. I'm sure this would take some work and a lot of paperwork, but most of them are old Dell/HP machines that will barely run XP anymore. They would be more than enough to install Linux and run applications for development and web browsing. And if one gets fubar'd, it's not of great consequence.

As I am an IT admin in academia, I see first hand many of the problems you mention. Here are some of the "why"s that should give you a better picture of the problems.

Blocker #1: Varies from institute to institute. This mainly applies to graduate students. The reason is that most graduate students get tuition waviers and/or are paid to work on a research project. The university is trading an education for work. At my university, undergrads own all the work they do for classes. If they get a grade, its 100% their property. If its a project outside of class, then the school only has a claim if you use school resources to work on the project. Also, most universities split the revenue from anything that is created with the creator.

Blocker #2: Personally, I have a problem with any class that dictates that a student give away his work. Any class that is required (non-elective) should provide options for both open source and closed source projects to fit the wants of the students. Remember, they are the customers in this situation. Student's rights have to come first. There is some legal precedent though in classes that require this. The whole debate of revolves around the fact that students have to sign over rights to the service when the turn in a paper. Many professors require this as a way of curbing cheating.

Blocker #3: This is the biggest headache I deal with in my job. I agree it is very frustrating. There are problems with providing these services though. First, most faculty are NOT system administrators. Putting a box on the school network is akin to jumping into shark infested waters. Schools are highly visible targets because they usually have highly developed networks and thousands of nodes. Getting the machine to use is usually not a problem. Hardware is cheap. What isn't cheap is finding a place to store and cool all this equipment. It costs hundreds of thousands of dollars to equip a mid size room with air to cool all the equipment. Usually it comes down to hosting the equipment in the same space as infrastructure. But then you face the dilemma of providing access of this equipment to students/faculty who are not trained IT admins. And if a machine is compromised, it may endanger the rest of the infrastructure. Most universities do not have the resources to provide hosting facilities for what they see as non critical projects.

Thank you for your perspective. I too have spent a lot of time at universities and have administered machines for a small department. Please help eliminate you local "IP Office" and liberate your local network.

Blocker number one is a power grab, pure and simple, that should be eliminated at its root. Please do not call the copyrights, patents, trademarks and other things that universities are trying to claim "<a href="">intellectual property</a>" because the term is misleading and helps to justify the grab. Professors used to own these things for themselves and any wealth and prestige they brought was good for the university prestige and budget. Demanding the same from students, paid or unpaid, is simply outrageous. Universities are not, usually, for profit corporations and professors and their grad students are not equivalents to corporate researchers and cubicle slaves. The purpose of the institutions and the reason people are there are different, but new "IP Offices" have planted themselves in Universities to enrich themselves by this power grab and create these confusions. The stronger the grip these offices have over their professors, the more isolated and less published a university will be. This is especially true for computer science but it also applies to other fields the office would like to own and control.

You can argue that Universities need money, but "IP Offices" are probably not the way to make it. Patents, for example, are very expensive to obtain and non practicing entities have not done well in court with them. The primary promoters of patents as a business method, such as Paul Allen and Nathan Myhrvold, have been described as <a href="">patent trolls, and their businesses are arguably pyramid schemes</a>. It is even sadder to consider the revenue stream and results that might arise from university ownership of all paperback novels and poems that the English department might produce.

Blocker number three has new problems that are entirely Microsoft Windows driven. Deciding what people can do with the computers on a public network is analogous to telling people what they can say on their university phone line. Getting rid of Microsoft Windows will make any network a saner place, but policies put in place discriminate against free software on Microsoft's behalf. Please work to undo this problem at your university because it is entirely based on ignorance.

Blocker number two is truly perverse. Preventing students from working together and with the larger community does nothing for student privacy. No grades need be shared for students to use and contribute to free software. The issue is a strawman that is more applicable to the IP Office's greedy schemes where raw notes are kept as evidence of invention.

Twitter: You seem to have a single sided view of how universities work. I have worked and attended both research and non research based universities. You seem to be missing a few key points. First, the universities pay for themselves in one of three ways. State funding, tuition driven, and research dollars. No matter which method a university uses, almost all have a, "IP Office". If a university is in the research business, you can almost guarantee they do NOT own the research exclusively. These universities get paid by grants or private funding to conduct the research for someone. This research money is used to pay graduate students, build labs, and pay for the faculty's time. Most universities don't care about undergrad research as it is fairly limited in volume.

As for the power grab, the university spends millions of dollars building the labs that students work in. If someone is going to make money using the labs, the school wants (and deserves) to get some payback from its investment. Nothing is free. The amount they want is usually proportional to the investment. Many universities are also very accommodating to projects that are not for profit or open source. They are not all out to try and gouge their students.

As for your opinion on security, as much as I hate Microsoft, you can't blame them. My Linux servers get attacked just as much as any Windows servers on our networks. SSH attacks are quite common. Being a university means that you are a target rich environment. We see well planned attacks coming in from all over the world. I have never experienced security as a means of a power grab to control people. Our university allows our students to put whatever they want up on the network in the residences. And in fact, many of them run servers hosting all kinds of stuff, legal and not so legal. The problem is when you want a consistent server presence. That takes resources: cooling, power, network jacks, personnel to manage said server. Those get expensive very quickly.

IP policies vary by campus. I've seen some faculty members copyright their materials with other colleagues from a *different* campus. That way, the IP isn't dictated by one campus policy only.

Luckily, we don't have to deal with this on our campus. My materials are my copyright.

As for blocker #2, we insist that our students retain their copyright. All their thesis work, for instance, is their copyright. I know that some CS courses on our campus will encourage the student to release their work under a CC style license or GPL, etc. but its still a new concept.

IT support? That's a tough one. On our campus, we have regular labs running a proprietary software stack, but they allow some of us to run our own stack in the lab for specific coursework. I still have to run the LTSP servers myself, but at least they don't get in the way and are quite helpful.

Sameer Verma
San Francisco State University

<h3>History of Intellectual property rights in schools</h3>
Back in the 1980s, many universities were getting federal grants from organizations like DARPA, the National Science Foundation, NASA, and other government agencies, for a variety of research projects.

<h3>Federally Funded Projects were Public Domain</h3>
Any software created by the University, faculty or students, automatically became public domain. Most of the fruit of these projects were stored in a government server known as SIMTEL20. Tens of thousands of programs, ranging from simple utilities and one-liner shell programs to complex programs containing thousands of lines of code - were deposited into this server.

<h4>Plowing up the National Parks</h4>
Unfortunately, one of the down-sides of public domain is that a commercial vendor can add a few lines to free software, even simple cosmetic changes and trademarks - and it suddenly becomes commercial proprietary software protected by copyright law and licenses.

Richard Stallman created the first Open Source license designed to protect ALL of the CONTRIBUTORS from a corporate "take-over" of the software after Ed Gosling (of Java fame) added a simple printer driver to Richard Stallman's free EMACS program and then attempted to sell it to corporations for $300 PER SEAT.

What Ed didn't seem to understand was that thousands of contributors at MIT, Carnagie Mellon, Berkely, and a number of other universities, as well as many system administrators, had contributed hundreds of hours each to designing code, writing code, testing new functionality, fixing bugs, writing documentation, and promoting EMACS. Many of these contributors didn't know that Gosling hadn't even asked Stallman for permission to create the derivative work. They assumed that Stallman was getting profit too, and started threatening lawsuits, even acts of violence. Some contributors even started damaging his property, and response mail was coming back attached to cinder-blocks - which resulted in huge postal bills because the cards said "Return postage guaranteed".

To protect <em>HIS CONTRIBUTORS</em> Richard went to the group on usenet and asked if there was a way to protect the software, to make it free to distribute, but to keep a pirate from stealing it and turning it into an expensive commercial product - without paying any of the contributors.

<h3>The General Public License is born</h3>
About 50 people began participating in the thread, and very quickly came up with a license agreement that would protect the contributors, and assure that the source would be available, and at the same time, would allow the software to be distributed at little or no cost. Initially this license was called the <em>General Public License</em>. Later, Richard started a project to help many of those hundreds of people who had written software for BSD, and decided to call it GNU (GNU is Not Unix), and the license was changed to the GNU Public License.

To publish works under the GNU, there was only one requirement. You had to be the original author of the work, and you had to publish the source. If you tried to pirate somebody else's work, it would be trivial to convict you, because you had provided all the evidence when you contributed to GNU. And since most of the contributors were individuals with limited resources, it was pretty clear that attempting to publish pirated software would mean goiing to jail for 5 years or more.

Several companies, including IBM, HP, DEC, and Apollo were impressed with the efforts of GNU, and decided to see if the approach would work for graphics on UNIX. They funded a project called Project Athena. Athena used a different license called the MIT License. It wasn't quite as strict as the GPL, but was still considerate of both contributors and the companies providing the funding.

Athena ended up bringing in MIT, Carnagie Mellon, Harvard, and a number of other universities. Some of the projects included X11 - the graphics toolkit and system used on Linux and UNIX Workstations like Solaris. They also enhanced IBM's GML parser to create SGML. The Andrew Toolkit made it possible to combine various types of SGML document elements, including graphics, spreadsheets, and enhanced text, into a single document. While Microsoft was still trying to get Microsoft Word to run on Windows 3.0, the Athena project was releasing X11R4 - complete with 3D looking displays, complex applications, support for fully preemptive multitasking, and even the ability to coordinate multiple displays - back in 1990. Many of the features of X11R4 wouldn't be available in Windows until 2007. Many are STILL not available, such as virtual desktops - contributed by Xerox and NOT licensed to Microsoft. Athena even had support for 3D graphics on the X11 Graphics terminals (PHIGS), way back there in 1991.
X11R5 and X11R6 established some standards and toolkits that made it possible for applications written in one toolkit to run with applications written in another toolkit. For example, an Athena application could run on Motif, or an OLIT Application could run on an Athena window nanager such as TWM, and Motif Applications could run on Open Look Virtual Window Manager (the one used on Solaris - but with Virtual desktops added to make up for the low resolution of some PCs).

To get Athena applications to run on Windows, they had to be "Dumbed Down" - SGML had to be reduced to a strict subset known as HTML, what we use on web browsers and servers today.

<h3>NCSA License</h3>
Later, the National Center for Supercomputing Architecture decided that putting source code in public domain was driving away many students. They created a license that was very similar to the GNU Public license. Many great projects, including Mosaic and the NCSA Web Server were published as NCSA licensed software.

<h4>Microsoft Hijacks NCSA</h4>
When web browsers started to get more popular, the NCSA decided to grant Spyglass permission to sell "Branding Rights" to companies like AOL, Prodigy, and others. However, many of the contributors got upset when Prodigy tried to create a branded browser with no address bar. Prodigy wanted to keep the users of their browser "captive" but such a restriction violated the terms of the NCSA license.

When Spyglass sold these "Branding Rights" to Microsoft, after long and difficult negotiations, at the last minute, Microsoft managed to get Spyglass to give them permission to make any modifications they wanted without having to release the source code to the derivative works. Rather than pull the plug on the deal, the NCSA decided to unilaterally rewrite the NCSA license, without even getting the permission of those who had contributed under the old license. The new license gave the NCSA permission to license software to other companies under any terms it wanted - but the NCSA version could still be available in source, just not the dervative works. Shortly after this, Microsoft released it's Internet Explorer - with a number of proprietary features.

NCSA contributors got so upset with the NCSA that they started releasing patches under GPL. Eventually, there were so many patches that the enhanced server was simply referred to as "A Patchy" server. Some marketing types found that this was hard to sell to corporations, so they changed the spelling to "Apache". A new copyright license was created, which was more pragmatic than GPL, because it made it possible commercial interests and developers to add "plug-ins", allowing users to call shared libraries from the web server. Later, the same features were added to the NCSA browser, which also got a new name.

<h3>Patrons, Partners, and Pirates</h3>
Many universities have now begun to take a more pragmatic approach to open source licenses. They have found that Open Source Projects attract students, alumni contributions, and corporate contributions.

At the same time, Microsoft especially, has been trying to protect their monopoly by very aggressively pushing an "All Microsoft" curriculum in these colleges. In many cases, only engineering students actually get to learn how computers actually do what they do. Even basic C programming is taught using Visual C++ and Visual Studio. The student versions of the software runs about $100, but the push is to get a job where you get MSDN, at a cost of $1500 per programmer per year.

Rather than understanding the fundamentals of databases, data structures, data-flow, and collaboration technologies, colleges now have REQUIRED classes in how to USE Word, Excel, and PowerPoint. The students are "taught to the test" to pass the MCSE certification tests for Microsoft's current version of Windows. This will assure employers that graduates of the college will know which buttons to push on the GUI to configure a TCP connection, or to back up the hard drive. They may not know what's in a TCP/IP frame, and they may not know how to prevent a virus embedded in an ActiveX control called by VBScript during e-mail preview from attacking the corporate network, but at least they will know how to start and update the Microsoft antivirus software. They will know how to look at the registry, but they won't be able to reliably make any changes to it.

There are "Computer Science" students who don't know as much about a computer as a Mechanic knows about cars. At least the mechanic knows how the engine works, what the critical parts are, where they are, and how to replace them. Some "Computer Science" students can't even assemble their own computer using cards, hard drives, and a motherboard - and install a working version of Windows on their custom built PC, let alone install and configure Linux on that PC. Many "technical schools" charge huge amounts for tuition to train kids in how to do things they should have learned in high school. At the same time, they will punish kids who show the initiative of bringing a laptop configured with Ubuntu or Fedora Linux, some schools will even expel the students.

<h3>A school that DOESN'T support open source isn't worth attending</h3>

A school that has a policy which forbids the use of OpenSource in the curriculum, or forbids students and faculty from publishing the "best work" under Open Source licenses, is probably not a school worth attending. At best, you would be learning secretarial skills, and at worst, you might actually be obsolete before you graduated. You got certified for Windows XP and Windows 2003, but by the time you were a senior, you needed Vista and Windows 2008. But by the time you graduated, you already need to be recertified for Windows 7 and Office 2010 - at least according to the school.

The problem is that when you graduate from a school like that, and the employers start asking about your J2EE and Linux experience, and ask you how to setup iptables to isolate two VLANS, you suddenly realize that you just spent 4 years and as much as $40,000 getting an education that won't even get you a minimum wage job.

Meanwhile, in India, China, and South America, the kids have been using Linux since they were about 12 years old. Their schools got the computers that American corporations were throwing away to be "Recycled". In many cases, this recycling consisted of formatting the hard drive, installing a basic Linux system, and shipping it to these other countries.

The result is that these kids know HOW a computer works, know HOW to actually program practical applications, and now HOW to manage large networks of Linux, Windows, and UNIX systems, using primarily Open Source software.

<h3>Killing the Patent Killers</h3>
A common practice, since the 1970s, was for a teacher to give assignments based on published specifications such as the DARPA RFC, POSIX specification, X/Open Specification, or an IETF specification. In a class of 30 kids, you might get 20 nicely functional implementations, each slightly different from the others in various ways.

But when the laws were changed to permit companies to patent software, these kids and their class assignments became a serious problem. If a teacher gave ONLY the claim as the specification for the assignment, and the kids came up with 20 different "machines" that worked as well or better than your patented version - without ever looking at the patented code - your patent could become obsolete - or worse, be nullified because the college kids had proven that your "device" could be "Intuitively derived" by someone with even the most basic knowledge - such as a freshman undergraduate taking his first college level programming course.

This ability to nullify patents of companies like Microsoft and others who hope to make millions by demanding royalties for patents on algorythms used by Open Source applications such as Linux, is a real problem for these companies. After all, if a plantiff wins a lawsuit for $180 million over patent infringement, and 4 weeks after paying the settlement, a college freshman comes up with an even better implementation - and publishes it under GPL as a submission to the Linux kernel team - how can Microsoft compete?

Microsoft claims that Linux violates over 200 patents filed by Microsoft. The irony is that many of the Microsoft patents were filed on code that was protected by strict nondisclosure agreements, only viewed by a hand-ful of people, and were only submitted as patent applications when Microsoft realized that Linux had something similar.

Meanwhile, the Linux code existed prior to the patent application, the code had been published under Open Source licenses which assured that ANYBODY could see it in source code form. Furhermore, the person submitting the code was either a student who had permission to submit, or a corporate employee who had permission to submit the code under his own name (to keep anybody from trying to sue the employer).

The amazing thing is that many patent holders didn't even list the existing prior art when they filed their patent applications. But now they are trying to claim that the colleges that taught the students the basic fundamentals should not be allowed to teach their students how to right practical software - that might compete with their patented implementation.

How much longer before programmers are burned at the stake for Witchcraft? And then the engineers, and then the chemists, and finally the physicists.

They burned the library at Alexandria, and a century or two later, even simple biology was now forbidden science. Priests "cured" diseases by performing exorcisms. The patient died, but that was OK because they went to heaven. And rather than getting read of the flea infested rats - they took the ugly janitors and cleaners and burned them at the stake.

Copernicus recanted and confessed that he was wrong, the earth didn't revolve around the sun, but the sun, stars, and planets all rotated around the Earth - to avoid being burned alive over a slow fire.

Even as late as the 1800s, George Washington was "cured" of a flu - by bleeding. Of course he died, but the treatment was not considered part of the problem at the time.

"..and keeps the cash"

AUTM (Association of University Technology Managers) publishes an annual survey of University license income from patents. Last time I looked, a handful do make a lot of money - which is shared with the inventors - but most barely break even in terms of paying for their technology transfer offices.

I was going to point the same thing out. For most universities having a patent portfolio does not make them money. It is yet another tulip festival where universities are trying to push for greater IP protection of "their" (read students and staff) ideas in the off chance they will make money.

There are also social and professional barriers. Senior faculty in many departments view FOSS as second class. Most of these faculty have experience with Microsoft only (particularly in non tech depts). So any faculty member pushing FOSS is viewed as being really out there.

Depending on the institution students may also view FOSS as being pretty pointless, particularly older non traditional students. They have Microsoft at home and at work and FOSS is just one more extraneous thing for them to pick up.

Unless FOSS directly ties into the course subject matter its hard to get students to bite.

You brought up some very interesting points which are indeed blockers when you look at the entire spectrum of universities. There are exceptions to each blocker, but those are merely exceptions.

Here's one:

But you rarely hear about things like these, and it's always long term goals that make OSS viable.

<a href="">My Open Source Bridge session earlier this year addressed a similar topic.</a> Very short version: a company does not upstream its patches, even though it should for long-term practical reasons, because of problems in four general categories. The company might lack a FLOSS culture. There might be legal confusion about what employees are allowed to do, and how to get permission. The project management workflow and timelines might not allow time for proper engineering. And the external project might have a terrible UI for new contributors.

Once you abstract these categories away from the specific problem of accidentally hoarded code rotting away, you see that they also apply to other problems of the type "I really know I should be doing $foo but haven't gotten around to it." I'm glad Mel and her colleagues are chipping away at these problems and helping develop solutions!

... run on tax payers' money. Whatever IP come up belongs to the public, not to greedy corporations who charge the public back by using inventories/IP that the public invested money into.

I'd first go after the professional sports teams that get stadiums built by taxpayer incentives and loans and then have the audacity to only show the games to people subscribing to ESPN or NFL while the loan is outstanding.

I'd add another "block" to the list above and that is much of a University's research is partnered/funded by a business with similar interests. This private funding is likely the reason behind the majority of research conducted by schools. It's convenient to forget about that elephant in the room and start screaming for more open source projects.

Oh yeah, as a graduate school graduate with published papers containing the professor's name prominently listed first, most schools and professors will choose to create commercial products any day over contributing to open source. Some may want to contribute the project and hope it grows but it doesn't take much to look at selling it and, only if there is no commercial interest, contribute it. Obviously, little projects (hey, look at this parser I wrote) are the exception.

In general, I don't think this is really much of an issue in practice. Education is about the process and learning how to learn. Doing is for training. You don't need to participate in something to learn about it, and if you're interested enough you will train yourself. And you have to be pretty interested to make any useful go of it.

If people are interested in free software they will investigate and contribute on their own time. The last thing any project wants is some inexperienced people poking around projects because they are required to for their course and only for that reason.

And although there is some graduate work that might dovetail certain projects in general there is more often a science vs engineering barrier which has different demands and requirements. e.g. scientists usually make poor programmers.

For teaching purposes there is little required to set-up `internal free software projects' beyond the sort of facilities needed for software engineering already - email, compilers/languages, 'cvs' and maybe a web server to run a simple bug tracking tool.

And for the motivated professor who wants an external project, a good approach would be to start and foster a single specific university-based project, such as with Minix. This way also the school would know what they're 'giving up' (i.e. nothing). You don't want to hassle existing projects with uninterested, inexperienced students trying to earn school credits - even google summer of code is a bit overwhelming for many projects and presumably the students there are the cream of the crop.

The problems described are general and can be used to create all sorts of barriers. It is difficult to teach computer programming, for example, if you can't set up a compiler for students to use and this is something that all three blocks can be used to prevent. Teaching is just one of the things that can and will be hindered by "IP Offices" and foolish policies created around IP and "security". Idiotic network administrators can make problems for researchers and would be publishers who can't plug computers into networks to share their data. The general issues are of freedom and control. "IP" and "security" are often excuses to extend control and unjust policies should be protested and eliminated as they occur.

"Blocker #3: IT support, or the lack thereof"

"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. "

The solution is either use VM ware, MS Virtual PC, or some (other) VM product you can download for free. This way you tell your students to back up at every change. If they kill a virtual machine they just go back to a copy of a previous version.

Simple, effective, and it allows for VMs to be built and distributed by the professor.

I have always felt that the University paid me a good salary to have ideas and "create content", so I had no right to "double-dip" by trying to sell the copyright of books I wrote at work (for instance). On the other hand, no one has the right to keep me from giving away my creations. So, many years ago, I beefed up my home server (out of my own pocket) and put up my own website on it (ditto), where I posted everything I wrote, along with a GPL notice, BEFORE ever moving it to a University-owned server. Thus I am using public domain sources in my teaching and no one can lay claim to it, since it was all created on my own hardware in my own free time. If you really believe in Open Source, you need to make some commitments!

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.