“A Build System Only a Build Engineer Could Love”
09/20/2006
I presented my overview of Mozilla’s Build System to Seneca’s Topics in Open Source course this morning:
13:33 <vlad> how'd preed's talk go?
13:34 <Moe> vlad: he had an awesome sport jersey
13:34 <Moe> with a lizard
13:34 <Moe> thats all i took from the lecture
13:34 <Moe> oh and of course there was that whole build thing
Glad to know I made a positive pedagogical impression.
Prepping for the presentation was full of fun surprises.
I ended up mentioning this during the presentation because I think it’s important to point out to newcomers who may be working hard to integrate themselves into the community that even the more… seasoned among us still can have huge grey-to-black areas in our knowledge about parts of the project. That’s part of the project’s charm—its deep breadth of things to work on—and its curse.
Afterward, I had lunch with Dave Humphrey, the professor for the Topics on Open Source corse and Chris Tyler, another professor in the department. We had a very enjoyable conversation about objectives in the Topics on Open Source course, ideas for material as it relates to other courses, and how the experience has been going thus far, for both student and professor.
Seneca, through this course and others they’re working on developing, is trying to bring more open source material into the classroom. This has a number of benefits for both students in the course and the open source projects they choose to work with.
The benefit to the body of open source code is obvious. The benefit for students is more subtle, a point I had spent some time trying to convince professors at my alma mater of: quite simply, open source provides real world conditions that the classroom cannot.
When students go out into the workplace, the chances that their first job will entail designing and implementing software systems from scratch is very small. Rather, the “fresh meat” typically get all the bugs that no one else had time (or wanted to) fix. Most software jobs out of the gate are maintenance jobs.
Contributing, as part of a course, to an open source projects mimics this real-world condition in a way that is difficult, if possible at all, to re-create in a classroom setting. The one idea I had advocated was a sufficiently complex software system that was passed off from software development class to software development class, where each quarter, features were added and bugs were fixed, but… this implementation of that idea is better. Much better.
It’s heartening to see a college program that really understands this and is trying to directly address it.
I told Dave he has a good paper covering the academic aspects of using open source as a model for teaching waiting for the Journal of Higher Education.
After returning to the hotel, I was reading through some of the class documentation, and found out their first assignment today—a “simple” one of “Build Firefox”—was not only due, but worth 10% of their grade.
I asked in IRC how they were being graded on the assignment. The answer is a writeup and screenshot of their locally-built browser.
I started going through a few of the writeups, and found it very interesting. The lacking specificity of the assignment allowed prompted each student to think about it differently.
Some students grabbed the trunk from CVS and built that. Others used the source tarballs from a 1.5.0.7 release. All three major platforms were represented.
I think there’s a lot of feedback in those write-ups, detailing all the ways that we could make life easier for new contributors. And what great design for an assignment.
I had a lot of fun today.
Seneca students: I hope you do continue to wander into #build throughout and after the course! Thanks for having me today.