An oft-repeated theme in yesterday's discussion was helping students choose an appropriate problem to work on. "One thing in the community space is figuring out what the proper on-ramps are, not just for students, but for all new participators," said Greg. "Stuff that isn't on the critical path, but which is important enough to spend real cycles on." In other words, legitimate peripheral participation. Building legitimate peripheral participation opportunities is, in itself, a good meta-project for students, who have repeated opportunities to improve the new contributor experience as they hit new aspects of projects when their classes change each semester.

Paul Jones happened to be visiting at the time, and brought up a conversation on reaching out through other disciplines, citing journalism and translation as good examples. (Humph promptly showed us bloggingheads.tv to demonstrate what journalism students could do.) Technical writing is a particular areat that we really need to look at more. Cam Seay, a business professor, echoed the sentiment of needing to make sure that non-code contributors can join the conversation and know that there's a place for them. "We see OSS as the hardcore coders," he explained. "We need to broaden that perception." In the real world, if your shiny technology doesn't solve anybody's problem, it is useless.

[caption id="attachment_1341" align="alignnone" width="300" caption="POSSE Monday: (left to right) Christian Jacobsen, Cam Seay, and Dave Humphrey discuss nontechnical contributions to OSS."]POSSE Monday[/caption]

We also need to look at the stereotpyes that students have about themselves. As Greg noted, "there's this stereotype that coders are socially awkward... that's not true. Ok, some are that way, but there are a ton of engineers who are exceptionally good at communicating. The communication skills and the ability to work with other people - those are valuable, and OSS provides an opportunity to pick that up. Your coding skills are not central to what makes your community work; your communication skills are."

Chris provided an alternate perspective. "One problem in OSS communities is that we have a tendency to make everything become code. It all beceomes docbook, or spec files, or whatever." "Code can be written," Dave added. "When you lose community cohesiveness, that isn't as easily replaced. In open source, unlike almost anywhere else, the stuff that goes around the code is more important. To get my code accepted, I have to convince you that you should take it; I have to be reliable and get stuff done." In a society with no bosses, no corporate structure, and where you can't be fired, things work differently.

One key part of helping students find their own projects is teaching them how to interact appropriately with the community. Some students come in and all they do is ask questions, but people quickly tire of answering questions when their time investment shows no returns in the same people offering help. Perhaps a student can't write code that's needed, but they can test it. There's always a way to contribute; those that only take from the community don't succeed. We still have a currency in free software - it's called relationship capital. The easiest way of building it that always works for anybody is this:

Whosoever asketh for help, verily they ought offer to document that help.  And whosoever offers help, they ought require the help to be documented.  Thus do newbies become contributors.

It is also important to make sure students know there are people with different working styles than the super-über hardcore h4x0rs. This sometimes partially correlates to gender or discipline, though it need not - the key part is exposing students to as many options out there as possible. OSS is so much more than just the code, it's how it gets deployed - releng (release engineering), QA, docs, wikis, everything. Check out OSBR (Open Source Business Resource) and their July 2009 issue on collaboration, as well as their June 2009 issue on Women in Open Source.

What's under the surface of what people know about OSS communities? How do we teach our students that it's not just code, and help them find - with that broader perspective - what they should work on? This is what I gathered from the conversation:

Don't ask what the world needs. Ask what makes you come alive, and go do it. Because what the world needs is people who have come alive. --Howard Thurman