1. A Call To Arms.
In 2006, David A. Patterson wrote an article for entitled Computer science education in the 21st century. In this article (which, sadly, you cannot read unless you are an ACM member), he advocated a few fundamental changes to computer science education — one of which was the inclusion of open source as a fundamental part of the computer science curriculum. David A. Patterson was, at the time, the president of the Association for Computer Machinery, the world’s largest educational and scientific computing society. One might think that such a clarion call, made by someone of such obvious influence, would generate a groundswell of enthusiasm. He also bears an uncanny resemblance to a certain starship captain, which couldn’t hurt, right? When Locutus of Borg says “teach open source,” the world of academia must certainly follow, yes?
To quote George and Ira Gershwin… it ain’t necessarily so.
I’ve spent a lot of time over the past two years talking to professors. Mostly I’ve been asking lots of questions. Actually, I’ve been asking the same few questions over and over.
1. Do you use open source software in your classes? (Increasingly.)
2. Are your students interested in open source? (Increasingly.)
3. Do you or your students participate in open source software? (Rarely.)
4. Do you teach open source development practices? (Almost never.)
For these last two, the follow-up question is, invariably, why not?
And the answer is, invariably, because it’s really hard.
There are good reasons why professors don’t teach the practice of open source. It’s easy for an open source advocate to write these reasons off as excuses, which is precisely what I did for a while. But at a certain point one must accept the idea that most professors are not actually lazy, but bound by institutional restrictions that make it frustratingly difficult to teach open source — or, perhaps, to teach innovatively in any way at all.
When viewed in this light, Google’s Summer of Code really is a bit of genius. Chris DiBona and crew clearly realized very early in the game that, for their purposes, going around the educational system was going to be more effective than going through it. What’s more, they had cash to invest, infrastructure to support the program, and the ability to hire the best participants. Summer of Code is a brilliant recruiting mechanism for Google that also happens to be good for open source.
Unfortunately, there’s a limit to what these kinds of guerilla tactics can ultimately accomplish. For every open source developer that Summer of Code produces, universities produce hundreds of allegedly educated graduates who have never seen a version control client, a makefile, or a bug tracking system.
That can change. Universities can be influenced. It’s been done before, as Sun demonstrated; Java didn’t become the predominant language in universities without some significant help. But in order to affect such changes, we must understand the obstacles.
2. The Lay of the Land.
The advantages to teaching students how to participate in open source projects seem obvious. First, people learn more by trying to accomplish real tasks. They just do. It’s the reason that almost every computer science degree program has some sort of capstone project: to expose their students to real world problems. Second, it’s allegedly the mission of institutions of higher education to extend the commons of knowledge — go read some university mission statements if you doubt it — and it seems as though these missions would align perfectly with open source development work, which is fundamentally about extending the commons of knowledge. Getting university students to contribute to open source projects in structured ways seems like a huge win-win for everybody.
I have yet to meet a professor anywhere who disagrees with these assertions. To an individual, every CS/CE/CSE professor with whom I’ve spoken would love to be able to incorporate open source into their classes. So why don’t they?
Answering this precise question was, in large part, what our time at Seneca College last week was about. A lot of smart people got into a room together and asked a bunch of questions. For me, the key question was this: what are the key differences between the small number of institutions that are successfully engaging in open source, and the much larger number of institutions that are not?
Why was the question asked at Seneca College? Because Seneca is clearly Doing It Right. They are successfully building strong relationships between their students and the broader open source community, with the professors mediating brilliantly. Mozilla blazed the trail at Seneca, Fedora was next, and others will surely follow.
It was a day of lively discussion, with insights coming from every perspective: students, professors, institutions, industry, and community. You can review the notes from our brainstorming session on the Seneca wiki.
Back to the question, though: why don’t professors teach students how to participate in open source, despite the obvious potential advantages? Seems to me like there are two big reasons.
The first big reason, and in retrospect it seems pretty obvious, but it bears emphasis: the vast majority of professors out there have no idea how open source projects work, and don’t even know where to begin to learn, even if they had the time to learn (which they don’t). Those of us who live our lives immersed in the open source world don’t understand how steep the learning curve really is.
The second big reason has to do with motivation. Sad to say, but most professors aren’t rewarded for teaching to nearly the same degree as they are rewarded for research and publication. Which helps to explain why Seneca has been such a success story for open source; Seneca has a strong teaching mission, and the work that David Humphrey and Chris Tyler do in Mozilla and Fedora can be tied directly to their goal of making Seneca students more valuable in the workforce.
From these observations, I draw two inferences.
The first: there is no one-size-fits-all approach. The challenges faced by large universities are very different from the challenges faced by small colleges. An institution that is primarily research-based works very differently than an institution that is primarily teaching-based.
The second: somehow, despite the many obstacles, some professors are successfully bringing students into the broader open course community. These professors “get it,” and they can help other professors “get it” as well. They can serve as the models for the next generation of professors. But how will these professors find one another?
3. What now?
Well, um… we have a wiki.
Yes, I know. Yet another wiki. It’s not much, but it’s something, and right now, from what I can tell, there’s nothing.
So let’s start with a wiki.
What we actually need is a directory of professors who are Doing It Right. It will take a while to build it, but hey, Rome was not built in a day and all that. So please, if you are a professor who is teaching open source, or if you know a professor who is teaching open source, make sure that professor gets on the list.
We’re building the coalition of the willing here. Everyone matters. Tell two professor friends, and they’ll tell two friends, and so on, and so on, and so on. It’s important. Seriously. Students all over the world are writing throwaway code, right now. We can do so much better.