[Osdc-edu-authors] ARTICLE READY TO GO: Maddog's List: What do students need to know in order to dive into open source communities?
Mel Chua
mel at redhat.com
Mon Mar 28 20:02:34 UTC 2011
Please edit and push without blocking/asking me further - I'm liable to
be a bottleneck on that since I'm heads-down cranking out a lot of
content this week. Some sort of generic "event report" image would
probably be alright.
Thanks!
--Mel
----------
Maddog's List: What do students need to know in order to dive into open
source communities?
----------
One of the talks at <a href="http://posscon.org">POSSCON</a> education
twice 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:
<ul>
<li> how to do distributed development</li>
<li> how to license software </li>
<li> how to develop formal standards </li>
<li> how to write code to standards </li>
<li> how to motivate software developers </li>
<li> how to locate and engage the community of users and developers </li>
<li> how to innovate everywhere, always </li>
<li> how to evaluate and size customer needs </li>
<li> how to compare multiple programs that perform the same function </li>
<li> how to share </li>
</ul>
All right. Rewind a bit. Where does this list comes from?
It starts many years ago, when maddog himself was a teenager in college.
<em>All</em> 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 <em>could</em>
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 <a
href="http://debian.org">Debian</a> 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 <em>service providers</em>
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, <a
href="http://www.asterisk.org">Asterisk</a>, and <a
href="http://android.com">Android</a>. Studying electrical engineering?
There's <a href="http://en.wikipedia.org/wiki/SPICE">SPICE</a>, the <a
href="http://arduino.cc">Arduino</a>, and a host of circuit simulators
and board layout tools. Law, English, Philosophy? Check out <a
href="http://creativecommons.org">Creative Commons</a> and <a
href="http://gutenberg.org">Project Gutenberg.</a>
Of course, this doesn't tell us <em>how</em> we can teach these skills,
or how to develop programs to teach and assess them consistently - but
that's a topic for another article.
More information about the Osdc-edu-authors
mailing list