Tuesday, June 5, 2007

A Clash of Cultures

Graduate students at most universities can be divided into two categories. There are masters students, and there are PhD students. Each undergoes a period of study and training, and each must complete a substantial project, but there are important differences. A typical masters student project is simply a vehicle to demonstrate the students “mastery” of the topic. It must usually be large enough to require several months work, force the student to integrate and illustrate what they have learned in their coursework, but need not be greatly original. A PhD project, on the other hand, must by definition have some element of originality or individuality.

In an earlier column I suggested that many open source projects would be eminently suitable for masters work. Such projects must be large enough to require some project management skills, software engineering, working with large communities, and so on. However, there is another thread that comes from the academic tradition that complicates matters. This is that graduate students are typically paid. Some students are paid for teaching or assisting in grading courses. These are termed GTAs, or Graduate Teaching Assistants. But the more coveted title is GRA, or Graduate Research Assistant. Most students, and certainly the best ones, are drawn towards those programs that can provide a stipend. Problem is, these are expensive. At our institution, Oregon State University, a GRA can easily cost around fifty thousand dollars a year, because in addition to paying the student wages you must also pay tutition and fees, as well as providing a computer for the students desk.

When I discussed with various companies (I won't name names) the idea of using FOSS projects for graduate student projects I received an interesting response. Why should we pay fifty thousand dollars for a graduate student when the FOSS model is built on hoards of free, often undergraduate, free labor? Why indeed, other than that is the way graduate school has always been run. It is a difficult position to rebut, particularly as the FOSS model has been so successful. But until we find a solution this will be one of several issues that keep FOSS from becoming academically respectable. But I will have more to say on that topic in a later column.

Monday, June 4, 2007

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.

Wednesday, May 30, 2007

Introduction to Oss in the University

Hello. My name is Tim Budd. I'm an associate professor of Computer Science at Oregon State University. Some of you may know my name from my textbooks on programming languages, object-oriented programming, and data structures. But at heart I'm an academic, and my thoughts continually turn to trying to figure out what I can do to help prepare my students for the world they will face after graduation. Lately I've become interested in open-source development, and open source communities.

There are many ways that participation in open source development projects is useful to the college student. Too much of college computer science is focused on the code, and on individual development. FOSS projects help students learn about working in a community (both physically and temporally distributed), finding how their small bit of the project fits into a larger whole, and generally working well with others. FOSS projects also scale well. Students can begin by simply reading code, contributing small minor bug fixes (kernel janitor type projects). As their confidence level increases, they can move on to increasingly larger and more substantial projects. In a future column I will discuss the various ways that FOSS is finding its way into the university. My chairman has a term for this sort of scalability, she calls it a “Platform for Learning” (tm). Dave Patterson, the former president of the Association for Computing Machinery, 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 the obvious (to me, at least) advantages of giving students experience in open source development in the academic setting, such experience has been surprisingly slow to take hold. I believe there are a number of reasons for this, on both sides of the industry/academic divide. I will take up this topic in future columns.

In the meantime, I would really like to make connections with anybody with similar experiences. If you are an academic who has tried integrating FOSS into your curriculum, drop me a note and tell me about your experiences. Hopefully we can share ideas (and horror stories), and help improve things for the benefit of both our students and the field as whole.

You can reach me via this blog, or write directly at budd-at-acm.org