Skip to content

Open Source Capstone Course §

Pattern Summary §

Redesign the traditional computer science capstone into a professional open source development program, combining internships and layered mentorship to deliver real-world impact.

Problem / Challenge §

  • Undergraduate students do not have a 'real-world' experience of software development and delivery at scale.
  • Computer science students need to develop occupational skills and to demonstrate a level of experience as required by the tech sector.
  • Students completing traditional capstone courses may receive course credit but gain little authentic professional experience, limiting the value of the work to both students and external partners.
  • Promising capstone projects risk being abandoned after the course ends.

Context §

A university with a large and diverse research and instructional cohort.

There is a gap in internship programs for students that offer hands-on mentorship and experience in open source practices.

Forces §

The university, OSPO or relevant Department (e.g. College of Computing, School of Computer Science) has an existing relationship with potential open source communities or industry collaborators.

Tech Leads, Mentors and Partners have an in-depth understanding of open source projects.

Solution §

Redesign a computer science capstone course that offers authentic professional development experience while producing open source software that creates real and lasting value.

In this model, students are treated as professionals operating within a genuine open source ecosystem. Various types of mentorship are offered and students work with real clients.

The solution below outlines basic core activities to consider:

Outreach to potential partners §

  • Conduct outreach to potential partners across the university, industry and the open source ecosystem.
  • A consultation exercise with potential partners may be necessary to determine what kinds of projects are suitable and what level of engagement is realistic.
  • Establish clear expectations with partners about timelines, communication cadence, and the nature of the capstone development model.

Design of the program §

Program design should be based on existing knowledge of similar capstone and internship programs and should incorporate learning from consultation with partners and from relevant open source community practices. Key design considerations should include the following:

  • Hire students so that participation becomes a genuine professional experience rather than an academic exercise. This creates a firewall between course credit and paid work, with cash compensation provided in addition to any coursework.
  • Structure the semester based on software development practices: Schedule approximately six two-week sprints within a 16-week semester, with two weeks of onboarding at the start and a launch event (rather than a final exam) at the end.
  • Establish a clear distinction between the long-term product vision and the short-term project work of any given semester. This fosters an understanding that teams are contributing to a product that will outlast their own participation.
  • Require teams to produce handoff documentation (including a community strategy and a product strategy) to support continuity across student cohorts and enable multi-semester product development.
  • Diversify the types of projects available to reflect the breadth of student career interests. This includes client-driven products, internal services (e.g. CI/CD, infrastructure, cybersecurity), entrepreneurship-driven projects, and research-driven projects.

Create a structure of team management §

Engage and train graduate students as 'Tech Leads' to supervise projects and to support undergraduate development teams.

The Tech Leads will serve as ‘near-peer’ mentors who can provide support at scale without overburdening faculty.

  • Advertise and recruit graduate students on relevant courses.
  • Run pre-semester preparatory workshops (e.g. Building Open Leadership Toolsets) to ensure they are ready to begin on the first day of class with a deep understanding of their codebase and a clear product vision.

Additional ‘light touch’ mentoring supports §

  • Provide additional support for students by recruiting faculty and Industry Fellows as mentors.
  • This cohort can be engaged on a light-touch basis, for example, by being present in a shared Slack workspace and/or attending a minimum number of events per semester.

Advertising to student population §

  • A transparent selection process for candidates should be put in place.
  • Target the relevant student cohort to advertise the program.
  • Student referrals may also be a useful recruitment tool.

Team recruitment §

  • Use a structured team formation process (e.g. a career fair-style event on the first day of class) where tech leads pitch their projects and students interview for a place on a team, mirroring real-world hiring dynamics.
  • The career fair-style team formation event can itself serve as a motivating and visible signal to students that this is a professional experience.

IP considerations §

IP considerations can be complex where students are both receiving course credit and being paid for their work. All projects should carry an open source license and licensing should be an explicit part of student evaluation.

It is advisable to prepare a clear IP waiver and seek institutional approval in advance.

Where commercialization pathways are of interest, more information should be made available to students.

Grading and evaluating students §

The goal of the assessment process is not just to assign a grade but to provide students with strategic guidance for their career development.

Evaluation should be holistic rather than points-based. The evaluation also needs to account for the diversity of projects and the different requirements in terms of onboarding, learning, and contributions. All assignments and deadlines serve as evidence for the holistic assessment rather than being calculated into a final grade.

The holistic assessment draws on several streams of evidence:

  • Final outcomes and growth trajectory: The primary focus is on what students have achieved over the full arc of the program and how they have developed, rather than on individual assignment scores.
  • Assignments and checkpoint documents: All assignments, deadlines and associated points serve as evidence-based grounding for understanding what happened at various points throughout the 16-plus weeks of work. They are indirect influences on the holistic assessment rather than direct inputs to a final grade calculation.
  • Client and team feedback: The team provides feedback on all members including the client. The client's voice carries additional weight in the overall assessment.
  • Collaboration and communication patterns: Observational evidence of how students actually do the work (e.g. their engagement on Slack, their conduct in meetings, their responsiveness to peers and clients) is a vital part of the assessment.
  • Weekly delivery: How students deliver on a week-to-week basis (e.g. demo videos, merged pull requests, checkpoint documents) is an important indicator of their ability to stay on task and drive towards outcomes.
  • A 10% stretch component: This can be used to reward demonstrations of professional excellence and, for graduate students, public demonstrations of professional leadership such as conference presentations or contributions to major open source projects.

Resulting Context §

Students gain legitimate professional experience - not merely course credit - and develop the occupational, collaborative and communication skills needed to engage with open source ecosystems throughout their careers.

Real clients receive quality software that addresses their genuine needs.

The OSPO builds a sustainable pipeline of contributors and maintainers for products that persist across student cohorts through structured handoff processes and long-lived product documentation.

Additional Learning from Open Source with SLU §

Treating students as professionals by using real job titles, contingent employment contracts and professional communication norms proved transformative in shifting students' orientation from academic exercise to authentic work. The goal is not to tell students to put something on their resume but to ensure the experience genuinely merits being there.

The distinction between the long-term product vision and the short-term project work of any given semester was one of the most important conceptual clarifications in the program's evolution. Products are built for a wider community over time; projects are the semester-by-semester iterations that advance them.

Community does not emerge overnight. Even with the best intentions around open source and community engagement, it takes time for a user and contributor community to form around a product. Designing for community from the outset - through public Slack channels; open repositories; and community and product strategy documents; creates the conditions for community to emerge even if it is not immediately present.

Multi-semester product handoffs are achievable and highly valuable. As the program matured, structured handoff documentation allowed new tech leads to onboard without requiring an hour-long meeting with their predecessor. The value lies not just in the documents themselves but in the planning activity that produces them.

The program has grown to over 23 active products across more than three years, with an estimated value of over $500,000 in development work delivered. The program currently enrolls 62 undergraduate and 24 graduate students in a single semester.

Additional Learning from The GW Open Source Program Office §

We did a guest lecture in a data science capstone to teach students about project management. We have also worked with that professor to bring in projects from industry, government and other groups. Professor Amir Jafari has open sourced his capstone program which enables anyone to submit a project that students can opt to work on.

Known Instances §

Open Source with SLU, Saint Louis University

References §

Contributors & Acknowledgement §

A note on AI use: In addition to working from Deep Dive transcripts, capturing learning from our community discussions and other patterns from our members, this pattern was drafted with the help of AI. As a small organization, tools like this help us turn rich conversations into written resources without losing the ideas along the way. As always, there were plenty of human eyes reviewing, editing and improving the content before this pattern made it to publication. Thanks go to our community for the insights. If you do spot any errors, please let us know so we can correct them!