I recently read Chris Tyler‘s paper, “A Model for Sustainable Student Involvement in Community Open Source”. Chris writes:
To effectively teach Open Source, it’s necessary to move each student into the role of contributor. At first blush this appears straightforward, but it ultimately proves to be an enormous challenge because Open Source is as much a social movement as a technical one and because many Open Source practices are the exact opposite of traditional development practices.
I like this paragraph, but something struck me as not quite right about it. Open Source practices don’t really feel like the opposite of traditional development practices to me. What I think they’re the opposite of, actually, is homework.
If your programming experience is limited to homework assignments, working on a real-world software project is going to be overwhelming for you, whether it’s open source or proprietary—and for the same reasons. You’re used to writing small programs, individually, completely from scratch. The software companies I’ve worked for all had teams of developers working cooperatively on a large, existing codebase, with version control, complex build systems, not enough tests, bug trackers, thousands of known bugs, good code, bad code, and way too much of the stuff for any one person to understand.
Did I mention working cooperatively? Traditional software development really is supposed to be done that way, I promise. Well, maybe it depends on where you work.
Later, Chris writes, “[E]ven students who don’t continue working with Open Source take an understanding of Open Source into their career, along with an understanding of how to work at scale — which is applicable even in closed-source projects.” That’s the stuff! Open source development is different. But it’s not that different.