Why is it hard to get students into open source? Here are some thoughts that came up while working with students from my alma mater on an XO deployment. Thankfully, I'd typed this post weeks ago, before the RSI set in.

  1. no time to introduce - When you work side-by-side with classmates on short-term projects that you build from scratch, you don't need to learn about release cycles, bug tracking, modular designs for reusability. Why should you? You sit down, you make something together, you move on.
  2. no time to engage - The constant flux of new projects and work, and the presence of an on-campus community mean that there's less incentive to stay on top of the goings-on of a remote software project you can't constantly contribute to anyway. Why constantly incur the  new-person start-up cost when you can only sprint once every couple months (and might be interested in different things by then)?
  3. no time to maintain - The project is done, you handed it in, you've moved on to a new semester with new classes and new projects... nobody's using what you made anyway, so why keep it up? Why struggle through setting up your first repository when nobody is ever going to commit a patch?

There have been exceptions to all three of these - I've had classmates attending GNOME summits, maintaining libraries, etc - but that's something they already did on their own prior to attending college, not something the culture of the school itself inspired them to do. The secret sauce, as best as I can tell, is customers.

  1. Upstream projects require introduction to OSS practices. When you need to get something working for a bunch of 6th graders, you can't always code it from scratch. Using OLPC, Fedora, Sugar, Moodle's, etc. codebases for the XO mandated that student teams learn how to work with the tools and norms of those communities. The importance of code  readability/maintainability, active QA, documentation, and support resources quickly become (sometimes painfully) apparent. Like when Elsa spent over 2 hours trying to install sugar-jhbuild and was met with a series of (for her - and me) bewilderingly  context-free error messages.
  2. Ongoing deployments require engagement with upstream communities. Since the student teams are providing upstream communities with the deployments that they wanted to serve, those upstream communities have been amazingly patient, helpful, and willing to teach them. They're learning what release cycles are and why they matter when projects have to be viable for years rather than demoable in weeks, and why you sometimes want to freeze things - like when Yifan found that she had to relearn how to make Activities every few months.
  3. Customers force you to maintain stuff for them. With every maintenance request, they're also saying "hey, we want to keep using this stuff you made for us. Please help us use your work! We think it's useful."

I think that pretty much everyone reading this post already knows and has experienced these sorts of things, but when you're a student,  this stuff is really weird. I've had programmers write me after meeting a group of high-school students I'd been working with, surprised the students had thanked them for being a real coder! talking to them! Just for that. Until the age of 18 or so, most students spend their
days surrounded by... other students. Teachers. Their parents. Talking, as colleagues (not as a "maybe when you grow up you'll be cool like me" guest speaker) with professionals making actual products for real people? Wow. Right up there with learning to hail a taxi for the first time instead of riding the school bus, even.