Since 2008, over 100 students from 16 universities have worked in distributed teams on open source projects for course credit. Using Basie (http://basieproject.org) as an example, this talk explains how we have made that work. This talk was given at PyCon 2010 in Atlanta on February 20, 2010.

1. What We’ve Learned
From Building Basie
and lots of other software
using student labor
over the course of eight years
Greg Wilson http://third-bit.com Feb 2010

2. I Beg To Differ
“…student projects,
while laudatory,
frequently fail to
deliver anything
useful.”
http://joelonsoftware.com/items/2009/10/26.html
About a quarter of the student projects I’ve helped
supervise since 2002 have delivered software that
clients actually used, and the rest have produced
something just as useful: experience.

3. The Big Picture
368 people, 136 projects, 35 countries of origin

4. How We Got To Basie
Start running directed studies
2002 projects at University of Toronto
2003 2004
First attempt to 2005 2006
build portal Join U of T fulltime
(using Java)
2007 2008
UCOSP
2009 2010

5. Why Another Portal?
SourceForge and Trac already exist;
why build another portal?
1) Self-hosting
2) Simple
3) Batch operations
4) Sustainable
Cabot & Wilson: “Tools for Teams: A Survey of Web-Based
Software Project Management Portals”. Doctor Dobb’s Journal,
October 2009.

6. We’ve Been Busy!
https://basieproject.org/stable/basie/

7. We Have Tickets!
https://basieproject.org/stable/basie/

8. To Make a Long Story Short
Undergraduate students can build
a lot of great software
If:
1) You have realistic expectations
2) You’re patient
3) You realize that “how” matters more than “what”

9. 1) Realistic Expectations
Most students are doing
five courses at once
Which leaves them 8-10 hours/week for your project
A 13-week term is equivalent to 3 full-time weeks
How much do you expect a new (junior) hire to do
in their first three weeks on the job?

10. Realistic Expectations (cont.)
Most faculty are working even
harder than their students
“We’re here to do research,
they pay us to teach,
we spend our time on admin.”
They care about computer science,
which is not the same thing as programming
You can’t blame them for doing
what they’ve been trained to do, either

11. 2) Patience
Your project may be the first time
students have written something
that isn’t just going to be marked
and thrown away
And the first time that 90% right
isn’t good enough
You must not make students feel like failures
for working the way they have been trained to
Even (especially) if those ways are wrong

12. Patience (cont.)
“Why don’t schools teach students
[Git | Haskell | GPUs | cloud]?”
Because the curriculum is full
4 years × 2 terms/year × 13 weeks
= 4800 hours
The hard part isn’t figuring out what should be in there
The hard part is getting agreement on what to take out

13. 3) How, Not What
Q: What was the most valuable
lesson you learned from
your project?
Nobody said “technology”
What they did say was:
• Teamwork • Presentation skills
• Prioritization • Negotiating with real users
• Code review • Building their network and portfolio
By the way, our project students are 28.5% female

14. There’s A Textbook For That
Karl Fogel:
Producing Open Source Software:
How to Run a Successful
Free Software Project
O’Reilly, 2005
http://producingoss.com
The same skills students need to succeed in grad school

15. Other Lessons Learned
• How to run meetings
• How to teach students how to do code reviews
• What level of tooling is appropriate/feasible
• Accountability
• How to accelerate ramp-up
• Carry-overs from previous terms
• Importance of full-time summer work (yay GSoC!)
• Industry support
• Presentations, presentations, presentations
• Scoping and re-scoping deliverables
• Recruiting students and faculty
• Grading
Thanks to Prof. Karen Reid
for this list (and much else)

16. Help Us to Help You
Basie
Eclipse4Edu
ElmCity
DC FlightSim
Ingres
MarkUs
Mercurial
Pony-Build
RoboCup
Thunderbird
WikiDev
http://ucosp.wordpress.com

17. Thank You
http://ucosp.wordpress.com