Diving into open source communities: Students' need to knows | Opensource.com
Diving into open source communities: Students' need to knows
One of the talks at POSSCON's education track was John "maddog" Hall's presentation titled "FOSS Teaches You Twice or Three Times." A 42-year veteran of the computer industry, maddog has seen it all. He's since turned his attention to the field of education and the work of creating a nation of thinkers and self-directed lifelong learners.
I'll jump ahead to my favorite part of the talk: if we want students to be able to learn "the open source way" and participate in FOSS communities, what skills do we need to teach them? Here's maddog's list of the how-to's they need to know:
- Do distributed development
- License software
- Develop formal standards
- Write code to standards
- Motivate software developers
- Locate and engage the community of users and developers
- Innovate everywhere, always
- Evaluate and size customer needs
- Compare multiple programs that perform the same function
All right. Rewind a bit. Where does this list comes from?
It started many years ago, when maddog himself was a teenager in college. All software was what we'd call "open source" today--the code was passed around from developer to developer in a friendly atmosphere where tinkering and modification was encouraged. Many of the developers maddog worked with were amateurs--they didn't write software for a living, or at least didn't start out that way. And they could be, because the culture of sharing meant that amateurs had access to the same resources professionals did, so amateurs could therefore easily match or even surpass professionals in learning and skill.
This is a stark contrast to the world of software development students today are faced with. Most of their information is locked up in proprietary textbooks. They're trained to use proprietary software that takes a lot of money, a professor with industry connections, or access to an underground student pirating network. (This is nothing new; in 1976, when AT&T blocked a professor named John Lions from the University of New South Wales from publishing his annotations on the UNIX source code, amateurs did it themselves, passing photocopies of photocopies of photocopies of the pirated book from one hand to the other.) They're asked to create programs from scratch for many individual assignments, but it's hard to create interesting software on your own. Most software projects nowadays are complex creatures, shepherded through their evolution by large teams over long periods of time. That's the world students graduate into--but they're not prepared for it after four years of "throwaway" projects.
Companies know this, and the smart ones find ways other than resumes and grades to screen new hires. Maddog recounted the story of Mark Shuttleworth's first round of Canonical hires. Rather than screening resumes, Shuttleworth sat down with the Debian mailing list archives, analyzing conversations to determine which developers he wanted to hire. Shuttleworth ended up hiring developers from all over the world. This makes sense; why should good software development be the exclusive province of a few countries? Instead of using their ingenuity and talent to pirate American software, shouldn't students all over the world be creating programs of their own to address local needs?
That's where the list comes in. Clearly, learning specific algorithms, languages, and tools aren't enough; instead of simply being trained as technicians, students need to be educated as service providers who solve the problems of their community by working on living projects, just as surgeons learn how to work their art of healing on living bodies.
Once students know these basic skills, it's possible for them to take advantage of a multitude of living examples for any topic they encounter in class. Kernels and operating systems, multithreading, concurrency, or programming languages? There are multiple thriving open source projects used in production for each of these. Doing a special topics course on telephony? Check out VoIP, Asterisk, and Android. Studying electrical engineering? There's SPICE, the Arduino, and a host of circuit simulators and board layout tools. Law, English, Philosophy? Check out Creative Commons and Project Gutenberg.
Of course, this doesn't tell us how we can teach these skills, or how to develop programs to teach and assess them consistently--but that's a topic for another article.