A few months ago, opensource.com ran a story on a textbook for college students learning programming (Can Professors Teach Open Source?, Greg DeKoenigsberg, Apr 6 2010). The textbook, "Practical Open Source Software Exploration," was created the open source way on the Teaching Open Source wiki. (Read Greg's article for more on what we mean by creating the textbook "the open source way".)
Although the textbook was written with students in mind, it turns out that professors are pretty important when it comes to teaching, too.
Late July, I sat in on a conversation between primary authors of the textbook on my team at Red Hat and Timothy Budd, associate professor at Oregon State University's School of Electrical Engineering and Computer Science. Budd used "Practical Open Source Software Exploration" in an introduction to free and open source software course in the spring 2010 semester. He reported that the book has potential, but that there are a few major things to get fixed.
Budd told us that the textbook had about enough content for two weeks of class. We all felt like we had forgotten what a college textbook looked like. And even though we just released version 0.8 of the textbook, it should still be somewhere around version 0.2. That's fine, right? Open source moves fast — we can have contributors working on the textbook and we can pump out a lot more real-world examples and example labs in a few months. Even better, we can use existing, free and open content as source for chapters on licensing, governance models and so forth.
Here's where we again saw the gap between the release cycles of open source and those in academia. The open source release cycle is "release early, release often"—even though your goals are known, milestones are often unknown, and it's possible that even the end result is unknown. Professors know when every milestone—every semester—begins and ends, and students know exactly what they're going to learn in a given semester, but they don't always know what the end goal is.
The team I work on found a great representation of this: picture the academic "release cycle" as a straight line with milestones equally spread out. Add another line that goes up, down, in, out and squiggles around with randomly placed milestones and you have the open source release cycle. (A picture of this is at the top of this article.)
Recently, we've started adding a line between the two, represented by TeachingOpenSource.org. We're building a community around drawing bridges between academic release cycles and open source release cycles so that students can work on open source as part of their academic studies—and so professors can teach it.
For those of us working on the textbook, finding a common line between the two is going to be key to pushing this out to as many CS departments as we can. As for me? I've learned a ton about how college works, and I haven't even started my first day yet.
Comments are closed.