UCOSP brings together students from coast to coast to work together on joint capstone projects. Students learn first-hand what distributed development is like. Each team has students from two or three schools, and uses a mix of agile and open source processes under the supervision of a faculty or industry lead.
NOTE: UCOSP is currently only accepting students from Canadian universities.
Why are we doing this?
Software development is no longer bound by time zones or national borders. Projects of all kinds—academic, commercial, and open source—may have their GUI designers in Boston, their database team in Bangalore, and their testers in Budapest and Buenos Aires. Working effectively in such teams is challenging: it requires strong communication skills, and makes proper use of coordination tools such as version control and ticketing systems more important than ever. But it is also an opportunity for students to build ties with peers across the country and around the world, and for instructors to breathe new life into old courses.
What we’re looking for right now:
- Students: Work on an open-source project with other students from across the country—for credit! What could be better? Find out how to apply.
- Faculty mentors: We’re looking to expand the number of schools participating this year. Find out how your university can get involved.
- Open source project mentors: Are you involved in an open source project? Help a team of students make a contribution.
- Sponsors: We need your help to bring students together for a code sprint. And—hint, hint—UCOSP participants will be looking for employment.
Fall semester timelines
- Mid-August: finalize which open source projects will be participating
- Mid-August: start matching student with projects
- Early September: teams have their first online meeting and start work
- September 24-25: code sprint in Toronto for all participating students
- Early December: work on projects wraps up
We’ll be finalizing exact dates shortly.
Some more information
What are the learning objectives of this program?
For students to gain hands-on experience with real-world development practices in a realistic environment while simultaneously learning and applying some core concepts of computer science.
What projects are available?
See the projects page.
How are tasks within a project allocated?
This varies from team to team. In general, though, there’s enough work for everyone to spend most of their time working on something they find interesting.
What skills do students need?
The programming skills required vary widely from project to project: students are more likely to succeed in a Java-based project if they already speak Java, and more likely to do well on a cellphone project if they have some previous experience with handheld devices or wireless networks. Students should also be familiar with, or willing to learn, version control, bug tracking, and other coordination tools. Keep in mind, though, that being able to set their own goals, manage their own time, and communicate with others is at least as important as knowing any particular programming language or operating system.
What do students find challenging about these projects?
Cooperation, communication, and commitment. For many students, this is the first time they have had to set their own goals and deadlines, and some struggle with that freedom during the first few weeks.
What are the benefits to the students?
Experience working in a distributed team on a meaningful project; peer contacts (social/professional networking); something cool to demo in interviews for jobs and graduate school.
Do potential employers and graduate supervisors actually look at these projects?
How much effort is expected from students?
The same as any other course, i.e., about 8-10 hours/week.
Can I do this course at the same time as a co-op job or other industry placement?
Unfortunately, we are only able to accept full-time students who are not currently on a co-op term into the UCOSP program.
How are projects managed?
The organizers take care of week-by-week project management, though other faculty are very welcome to get involved as well.
How are projects graded?
Grades are awarded jointly by the local faculty organizer in consultation with the project lead. Grading schemes are tailored to individual teams and projects, and take into account the requirements of the courses in which students are officially registered. (For example, a student who is registered in a senior course on Software Architecture may spend more time on design and documentation than on coding.) In many projects, students themselves propose grading schemes once they are familiar with the project. There is usually not a midterm or final exam, but some schools require students to do an end-of-term presentation and/or create a screencast to show what they have accomplished.
What development process do teams use?
Standard software development processes are not well-suited to students’ realities: unlike professionals in industry, students usually have to work on several projects at once, and are almost always new to the technologies they’re using and the problem domain they’re working in. Based on past experience, the best fit is a mix of open source practices and Scrum:
- Every project keeps its work in a version control repository, uses tickets to track work items, etc. Teams are strongly encouraged to do code reviews.
- Each team has an hour-long online meeting each week to review progress, set goals, answer questions, and resolve outstanding issues.
- Work is usually done in two-week iterations. At the end of each iteration, each team member sets their goals for the next one, so that students have a chance to develop planning and estimation skills.
- Each team is required to produce a five-minute screencast demo of their work at the end of the term.
What kind of work do students do?
All the things that real software projects need, including design, construction, testing, packaging, and documentation.
Do teams get to meet each other and their project leads?
Yes—there is a three-day code sprint in Toronto near the start of term at which teams meet in person to discuss the strategies for the term, attend team-building social events, and write lots of code.
How do team members communicate?
Via the usual online tools, such as blogs, chat, mailing lists, and Skype. Team members may agree on something else new and trendy, such as Twitter or Google Wave.
What level of work is expected?
(Almost) all of these projects are producting software for real-world use, so standards are high. Remember, “95% correct” may be an ‘A’ academically, but if 5% of an application is buggy, users aren’t going to be happy.
Do students get help from students who have worked on the same project in previous terms?
Yes, where possible. Unlike most university courses, we strongly encourage students to communicate with each other and their predecessors.
How do code reviews work?
Students post finished work (including tests) to their team’s code review site. Another team member then reads it through and gives the author on what needs to be fixed before it can be committed. Once the author has made all the fixes suggested, and the reviewer gives the ok, the code is put into the version control repository for others to use.
A brief history
Since September 2008, undergraduates from several schools in North America have been taking part in joint capstone projects in order to learn first-hand what distributed development is like. Previously run as a pilot project, UCOSP has emerged into a truly national program.
Information about previous years is available here.
Get in touch!
For more information about the program, please get in touch!