In the commercial world, adapting to Linux and Open Source has been disruptive, since it upset many cherished ideas about the value and secrecy of source code. Universities, on the other hand, have long used Unix and encouraged open sharing of ideas and source code, so adapting to Linux and Open Source should come somewhat more naturally.
The collaborative methods used to develop Linux and many Open Source projects are fascinating in their own rights. Everybody on Earth who is interested in a project and has a reasonable Internet connection can instantly plug in to a social network of people working on that project, read or search through their past discussions, ask new questions of them, fix bugs or add new code, and try out the contributions of others. Each contribution adds irreversibly to the richness of the project. It is an exhilarating bazaar of ideas and progress. This phenomenon is one of the key reasons Open Source has become vital to the practice of software engineering: it lets engineers (and companies) ride on the shoulders of a giant growing by leaps and bounds.
As part of the interview process, I ask the students to take a short quiz about a few tools commonly used in Open Source development, namely Make and the Bourne Shell. The quiz is open book and take-home, and most of the answers can be readily looked up in the on-line help or tested by running the commands in question, yet very few applicants get even half the answers right. I conclude that the students are not being exposed to these important topics. And unfortunately, these are not topics that can be picked up trivially at the start of an internship; if someone has never used Make or a shell, it's unrealistic to expect them to be able to deal with real-world shell scripts or Makefiles during a short internship.
Applicants that do manage to answer half the questions on the quiz are then asked to do some simple programming task, e.g. reversing a string. Amazingly, a fair percentage of CS students are unable to handle even these simple programming tasks.
Finally, students often seem flummoxed by techniques commonly used in Open Source development (e.g. diff and patch), and don't bother to test their changes the first few times they try to submit changes back to an Open Source project.
There seem to be three problems here:
Motivated incoming students interested in CS should be given an incentive of some sort to learn on their own pace at home during the summer before starting college, perhaps by offering an online version of CS101; students that take that course during the prefrosh summer, and who pass a placement exam, should be given credit. This would free them to take more interesting courses on arrival at school, and would help take better advantage of the plasticity of young minds.
This bias could be mitigated by switching one of the first-year CS courses to use Open Source tools instead of Microsoft tools. There are many open source-friendly compilers/interpreters to choose from, e.g. C/C++, python, java. Likewise, there are many Open Source IDEs to choose from, e.g. Anjuta (similar to Microsoft's Visual C++), Eclipse (for Java), etc.
Many Linux applications can be run on Windows by installing Cygwin. Installing Cygwin on existing Windows lab computers would have the benefit of giving access to Linux tools whether or not actual Linux was installed. This would allow students using those labs to freely choose between Open Source and proprietary environments. (Linux GUIs are just now being added to Cygwin; see e.g. this note on the Cygnome mailing list.)
Likewise, Fink is a free port of the same Open Source tools to the Mac OS X environment; a school with a mix of Windows, Linux, and Mac OS X computers can run the same Open Source applications on all its computers easily with the help of Cygwin and Fink.
I have found that very few students applying for programming internships have been exposed to open source development communities. This is sad because the peer review involved in making contributions to busy open source projects is educational; even pros learn constantly in such an environment because there are so many experts around to give useful feedback.
Therefore I'd like to see Open Source development techniques become a small part of the upper division CS curriculum. This should be a new elective course. Students would be introduced to a few basic collaborative tools required to participate in distributed open source development, would practice using them in local groups, and then would spend a few weeks making a small contribution to an existing real-world open source project with a significant user base, under the supervision of the class lab assistants. Many projects maintain To-Do lists for new volunteers; students would pick such a project and try to take care of one very simple item on the To-Do list (e.g. "Convert these 10 macros to inline functions"), have a lab assistant review the change briefly, then contribute their changes to the project, and iterate until the change was accepted (and then perhaps repeat with a more challenging contribution, once they're gotten a feel for the tools and the culture). The level of the course would determine the scope of the contributions; a course for 1st or 2nd year students would expect small contributions, but a capstone course for seniors might expect contribution of an interesting chunk of functionality.
I have put together a mini-tutorial which illustrates what the beginning of such a course might cover; it's online at kegel.com/academy/opensource.html.
Here are a few classes along the lines I'm proposing: