what we've learned from building basie
DESCRIPTION
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.TRANSCRIPT
What We’ve LearnedFrom Building Basie
and lots of other software
using student labor
over the course of eight years
Greg Wilson http://third-bit.com Feb 2010
I Beg To Differ
“…student projects,while laudatory,frequently fail todeliver anything
useful.”
http://joelonsoftware.com/items/2009/10/26.html
About a quarter of the student projects I’ve helpedsupervise since 2002 have delivered software thatclients actually used, and the rest have produced
something just as useful: experience.
The Big Picture
368 people, 136 projects, 35 countries of origin
How We Got To Basie
2002
2003 2004
2005 2006
20082007
2009 2010
Start running directed studiesprojects at University of Toronto
First attempt tobuild portal(using Java)
UCOSP
Join U of T fulltime
Why Another Portal?
1) Self-hosting2) Simple3) Batch operations4) Sustainable
SourceForge and Trac already exist; why build another portal?
Cabot & Wilson: “Tools for Teams: A Survey of Web-BasedSoftware Project Management Portals”. Doctor Dobb’s Journal,October 2009.
We’ve Been Busy!
https://basieproject.org/stable/basie/
We Have Tickets!
https://basieproject.org/stable/basie/
To Make a Long Story Short
1) You have realistic expectations
2) You’re patient
3) You realize that “how” matters more than “what”
Undergraduate students can builda lot of great software
If:
1) Realistic Expectations
Most students are doingfive 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 doin their first three weeks on the job?
Realistic Expectations (cont.)
Most faculty are working evenharder 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 doingwhat they’ve been trained to do, either
2) Patience
Your project may be the first timestudents have written somethingthat isn’t just going to be markedand thrown away
And the first time that 90% rightisn’t good enough
You must not make students feel like failuresfor working the way they have been trained to
Even (especially) if those ways are wrong
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
3) How, Not What
Q: What was the most valuablelesson you learned fromyour project?
Nobody said “technology”
What they did say was:
• Teamwork• Prioritization• Code review
• Presentation skills• Negotiating with real users• Building their network and portfolio
By the way, our project students are 28.5% female
There’s A Textbook For That
Karl Fogel:Producing Open Source Software:How to Run a SuccessfulFree Software ProjectO’Reilly, 2005http://producingoss.com
The same skills students need to succeed in grad school
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 Reidfor this list (and much else)
Help Us to Help You
http://ucosp.wordpress.com
BasieEclipse4EduElmCityDC FlightSimIngresMarkUsMercurialPony-BuildRoboCupThunderbirdWikiDev
Thank You
http://ucosp.wordpress.com