How Foss is finding its way into the University

It can be argued that the most revolutionary change in the field of computer science in the past decade has been the growth of the open source movement. Yet, for the most part, computer science curriculum has been slow to capitalize on this opportunity. Programming continues to be taught as it has been for most of the past half century, as if each new problem began with a blank sheet of paper. Historically, students were seldom, if ever, exposed to large, running, real-world (commercial or otherwise) working software. Twenty years ago this attitude was understandable, as most organizations treated software as intellectual property or trade secrets. This attitude has been described by Dick Gabriel:

The effect of ownership imperatives has caused there to be no body of software as literature. It is as if all writers had their own private companies and only people in the Melville Company could read Moby-Dick, and only those in Hemingway’s could read The Sun Also Rises. Can you imagine developing a rich literature under these circumstances? Under such conditions, there could be neither a curriculum in literature nor a way of teaching writing. And we expect people to learn to program in this fashion?

Dave Patterson, former president of the ACM, has in a letter printed in the flagship journal of that organization listed a course in open source development as the number one course he would like to go back to college and take. Despite this ringing recommendation, courses in the academic world in open source development are not common. In another column I will discuss a bit about why I think this is so. But in this column I want to discuss a few of the ways that open source projects are being used in academia. Much of this grows out of an inventory that my group, the Open Source Educational Lab, gathered concerning courses being taught at Oregon State University. However, the general trends are applicable to most universities.

Using open source applications. Students and professors tend to like open source applications because the price tends to be right. Nothing beats free. At Oregon State University, Eclipse is now the recommended IDE for the first year programming courses. Many higher level and specialized courses use applications that are open source, although often this means that they are pet projects of the professors, perhaps shared with two or three other institutions.

Teaching about the open source development model/business model. In beginning courses students are learning much more than mere programming. In our first year courses at OSU students discuss software design, the development process, testing, ethics, and a host of other topics. A discussion of the open source versus closed source debate fits nicely into this framework. Several courses in the college of business at OSU also discuss the open source model.

Examination of open source software. This is the example that most closely approximates the Gabriel quote. A good example of this occurs in the data structures course, which in most programs is the second or third programming course a student takes. Here students learn about common programming abstractions, from the simple, such such as stacks and queues, to the more complex, such as hash tables and AVL trees. After learning the basic ideas using the typical toy examples, I then give our students at OSU an assignment to look at actual working code using the same abstractions from various sources, such as BSD Linux, X window tools, and so on.

Courses where students do open source development. There are an increasing number of these. In former years our senior level operating systems course used to train on a simulator; now, students gain their experience by writing components such as device drivers for Linux. This past winter term I taught a special topics course on open source development. We read papers to learn a little bit about the philosophy and ideas, and heard from outside speakers. But there was also a practical aspect. Students had to research and join at least one working open source community. Every two weeks they were responsible for either a “paper or patch”. Either they had to write a paper on an open source topic, or submit a patch to an existing project (along the way submitting to the class a paper describing the process as well as the patch). This is the category of course that I believe needs to be much more common in the university curriculum.

Undergraduate capstone projects, masters projects, and other project experience. At OSU, as at many other universities, undergraduate students must have a “capstone experience” in their senior year. This is intended to be a nontrivial project that forces the student, or students, since they often work in groups, to integrate and apply all that they have learned in their previous courses. This year we have started a number of open source projects using this framework. Similarly, masters students must complete a project that shows, naturally, their mastery of some aspect of software development. In another article I will return to this topic, and discuss a minor culture clash that occurs between the typical academic model of student support and the open source world. Despite this, many open source projects have aspects that are large enough to be considered as masters projects. I believe much more could be done to develop this resource.

At the topmost level we have PhD student projects. Unlike masters projects, which only have to be big and not necessarily original, a PhD project must examine something new or original. Fortunately, there are many open questions that are out their ripe for picking. Figuring out how to pay for PhD students during their studies is another topic, but that will be taken in up a later column.

There you have it. That is the range of ways that we have found at Oregon State University to integrate open source into our curriculum. I don't think there is anything particularly notable about our program, and I suspect any university could do the same.