Introduction

Internships offer a highly effective pathway to employment, giving students the professional credibility and hands-on experience that study alone cannot provide. Yet across the tech sector, the supply of internship programs is not meeting demand. Too few structured opportunities exist for the number of students who need them and the opportunities that do exist are often disconnected from the day-to-day work students will actually do once they graduate.

Open source internships are a particularly powerful response to this gap. Unlike the academic exercises designed to award grades, open source internships place students inside a real codebase, working with real clients, real deadlines and a real community of maintainers and collaborators. Students learn not just how to write code, but how to manage a project, communicate with stakeholders, navigate ambiguity and deliver something that has to keep working after they leave. Internships are a genuine rehearsal for a job in the ‘real world’.

Academic Open Source Program Offices (OSPOs) are emerging as ideal experts to design and manage open source internships.

As centers of competency for open source enablement, OSPOs bring together the technical credibility, the institutional relationships and the community connections needed to run these programs well. They are typically the central point of contact for open source activity happening across a university with a knowledge of projects that would otherwise be scattered and invisible. In addition to enabling open source activity within their institutions, OSPOs are inherently outward facing: proactively building relationships with industry, open source communities and external partners in a way that few other university functions can match.

This article draws on a selection of new CURIOSS patterns*; conversations with CURIOSS members actively running internship programs; and a CURIOSS Deep Dive ** to share learning and to highlight the essential information required for any institution interested in setting up a similar program.

Designing the Program: From Capstone to Career Pipeline

Before an OSPO can advertise a single position, it needs a program worth advertising. CURIOSS members have converged on a small number of structural models, each suited to slightly different institutional contexts.

The Open Source Capstone Course pattern captures how a traditional computer science capstone can be redesigned into an authentic professional development experience. At Saint Louis University, Open Source with SLU’s evolution of its own capstone offers a vivid illustration of what this looks like in practice. Program director Daniel Shown described how the original course had all the familiar pain points of a traditional capstone with participants treated as student developers rather than professionals; mentorship being limited to instructor oversight; recurring code quality issues; and promising projects that were shelved the moment the semester ended.

The program’s response was to treat students as professionals from day one — giving them real clients with genuine requirements and building in layered mentorship through graduate “Tech Leads” and industry volunteers.

The redesign of the open source capstone did not happen all at once. It moved through several iterations - from graduate Research Assistants acting as Tech Leads to a dedicated graduate training for Leads before the semester even begins. The current program also requires every team to produce both a community and a product strategy so that the work outlasts any individual cohort.

The program now runs 23 active products, an estimated $500,000 worth of development work, and enrolls 62 undergraduate and 24 graduate students in a single semester.

The Open Research Community Accelerator (ORCA) pattern, developed at the University of Vermont’s (UVM’s) VERSO OSPO, offers a related but distinct model. Rather than a single capstone course, ORCA blends paid internships, volunteering and for-credit work into one pipeline with students themselves defining tasks and negotiating with stakeholders rather than faculty doing it for them. VERSO reports that students have progressed from not knowing what open source is to founding their own open source student club. Graduates have progressed on to roles at UVM’s IT department and at partner organisations they interned with.

For OSPOs building a dedicated summer offering rather than a semester-long course, the Summer Internship Program pattern draws on the experience of Carnegie Mellon University OSPO’s Summer of Code program and the Georgia Tech OSPO’s Virtual Summer Internship Program (VSIP). Both emphasise placing students in teams rather than as solo contributors, mirroring the intra-team communication of real software engineering work and easing the load on any one mentor. At CMU, mentors from Red Hat, the Eclipse Foundation and local startups were reportedly keen to offer the majority of a 15-student cohort not just further internships, but full job offers on graduation.

The University of Texas at Austin (UT Austin) OSPO runs a dedicated research matching program that connects researchers using open source software with a pool of roughly 3,000 students studying computer science, data science and information science. Rather than posting open positions itself, the office works through UT’s Career and Life Design office, running two recruiting seasons a year (Fall and Spring) that cover both in-study and post-study placements. The current program was adapted from an existing program, Connect, run by the university’s RGK Center and availed of a ready-made intake form, resumé acceptance process and skills-test framework, along with staff already trained in matching student skills to project requirements.

Sourcing a Steady Pipeline of Projects

A well-designed program needs a reliable supply of suitable projects and this is where many OSPOs hit their first real capacity constraint.

The Sourcing Projects for Open Source Internships pattern lays out several complementary approaches: issuing an open call for proposals, direct outreach to faculty and researchers, developing internal OSPO-led projects and cultivating external partnerships over time.

Members’ experiences show these approaches work in combination rather than isolation. Syracuse University’s OSPO sources some projects internally (often at the direction of university leadership) and the rest through a standing, rolling call for proposals hosted on its website.

The University of Wisconsin-Madison OSPO takes a more actively curated approach. Alongside a formal call for proposals distributed through mailing lists and newsletters, the OSPO’s Director and staff use opportunities to informally advertise the internship program through attendance at events, participation in networks and ad hoc meetings with researchers on campus.

Research matching programs deliver particular value for research institutes and centers that sit outside any single academic school or department. These groups often have no built-in pipeline to student talent, so the OSPO’s role is to act as a “friend of a friend,” connecting them to student interns or graduate student workers they wouldn’t otherwise have access to. This also enables the program to pull from across the whole university rather than one school. Projects submitted to the program must meet a minimum bar before they’re matched with a student: at least a semester in duration (a full year is preferred), ideally funded by a major government agency, and always a paid position - whether that’s a student intern role or, where possible, a fully funded graduate assistantship.

External partnerships take time to mature but can be transformative once established. Internship placements with the company Open Teams grew out of a long-standing sponsorship relationship built through the George Washington University OSPO’s (GW OSPO) conference sponsorship rather than a formal proposal process. GW OSPO has also built a relationship with Code for GovTech, an external program that manages its own one-to-one matching between maintainers and interns.

Advertising to Reach the Right Students

Even the best-designed program with a strong pipeline of projects will fall short of its potential if students never hear about it. The Advertise for Open Source Interns pattern stresses that no single communication channel reaches every relevant student, and that OSPOs need a deliberate, multi-channel approach: a clear program page, listings on the university’s student jobs portal, targeted departmental newsletters, direct outreach to faculty and relationships built through career fairs, student clubs and information sessions.

CURIOSS members’ practice bears this out. The University of Wisconsin-Madison OSPO advertises through its own website, the university jobs portal, its Data Science Institute newsletter, targeted outreach to other campus newsletters (including the medical school and engineering) and career fairs, where staff collect the contact details of interested students even before positions go live.

Syracuse relies primarily on Handshake, the university’s student job platform, alongside its own mailing list. However, referral networks matter just as much as formal channels. When a Syracuse project mentor already has someone in mind or receives a strong recommendation from a colleague, a trusted referral often produces a better match than an open call.

Streamlining Recruitment under real constraints

The gap between supply and demand shows up most sharply at the recruitment stage. With too few open source internship opportunities relative to student interest, popular postings can attract well over 100 applications for a single role - a volume that quickly overwhelms time-poor mentors who are already stretched across research, teaching and their own advising loads.

CURIOSS members noted that a subset of students essentially ‘live’ on student job portals, applying to almost anything that appears there.

The rise of AI-generated application material has also added a new layer of difficulty to screening. Members described an increase in applications that claim skills or experience that turn out, at interview or once work begins, not to be genuine.

Experiences shared by CURIOSS members show how this plays out under real time pressure. The GW OSPO advertised new internship opportunities through its newsletter. It reviewed 70 applications and forwarded five applications on to the company for interviews, two of whom were ultimately hired. In the early stages of UW-Madison’s internship program, it received 150 to 200 applications within a matter of days.

The Streamlining Recruitment for Open Source Internships pattern addresses this challenge directly, recommending structured application requirements, an initial screening pass, and clear scoring criteria developed in consultation with mentors - all designed to filter for genuine interest and fit before a mentor ever opens a folder of resumes.

The UW-Madison OSPO moved from a single checkbox where students could tick every project of interest to requiring individual applications for each project. This change cut the volume of applications roughly in half, with the remaining applicants showing a noticeably better fit. The office also actively monitors submissions as they arrive, removing obvious mismatches (e.g. graduate students applying to undergraduate-only roles).

Syracuse OSPO requires applicants to rank their preferred projects in a cover letter and explain their reasoning. The OSPO does not always assess the content of that reasoning closely on a first pass. Simply checking whether the required text is present at all is enough to distinguish attentive applicants from generic or recycled submissions. This process filters out a third to half of the applicant pool before a mentor is involved.

To manage application volume and screen out AI-generated submissions, the UT Austin OSPO uses an hour-long skills assessment form. The form also captures the extra information needed to determine eligibility and tuition/visa implications for international students - a significant source of administrative complexity given the varied U.S. graduate tuition structures.

The GW OSPO observed that the Code for GovTech program requires applicants to submit a full implementation plan and project schedule - a level of upfront rigor that produces a highly motivated, internationally diverse applicant pool.

Members are also leaning more heavily on structured interviews, technical questions designed to expose surface-level familiarity, and (where mentor time allows), a second interviewer to strengthen both the quality of decision-making and its consistency.

Involvement in the interview process itself varies: Syracuse OSPO is directly involved in shortlisting and joint interviewing, while the UW-Madison OSPO mentors generally run interviews independently, with OSPO staff stepping in only where a mentor’s own schedule genuinely does not allow for a timely review.

Consistent, timely communication with applicants - successful or not - was raised by multiple members as a small investment that pays off. A standard notification sent to unsuccessful applicants, even a brief, semi-automated one, was described as far preferable to leaving a position to simply close, which several members noted generates a steady stream of follow-up emails asking about application status.

Onboarding: From Enrolment to Genuine Contribution

Getting the right students into the program is only half the challenge. Once selected, students need to become productive contributors quickly, within a fixed and often short timeframe.

The Onboarding Students for Open Source Internship Programs pattern recommends pre-program preparation; a structured onboarding period covering both tools and professional norms; project and team orientation; and clear reference documentation that reduces students’ dependence on staff for routine questions.

Open Source with SLU’s approach to team formation illustrates this well. On the first day of class, students take part in an event modelled deliberately on a career fair, where tech leads pitch their projects and students effectively interview for a place on a team.

This immediately establishes a professional dynamic, giving students a genuine sense of agency in choosing work that matches their interests and skills, rather than simply being assigned.

The ORCA pattern shows what onboarding looks like when it is fully documented and made public. VERSO’s ORCA onboarding wiki starts with the unglamorous administrative groundwork that has to happen before a student can be productive at all: from setting up a GitHub account and requesting access to the organisation to registering on the university’s payroll system.

ORCA also spreads onboarding across the program’s first four weeks and ties it directly to the sprint cycle itself. Each week pairs a short learning resource with a brief written reflection due to the program director, alongside concrete team milestones such as holding the first sprint planning and review sessions and the first in-person co-working session. Onboarding and productive work are not sequential; they happen side by side from day one. The wider ORCA wiki documents the program’s “Pods” structure of four-to-five person student teams, its performance evaluation approach and its full set of program policies publicly.

Graduate students stepping into Tech Lead roles also need their own dedicated preparation, which is where the Onboarding Graduate Leads for Open Source Internship Programs pattern comes in. Open Source with SLU’s Building Open Leadership Toolsets (BOLT) workshop runs over the summer, giving incoming leads time to develop a deep understanding of the codebase and begin planning before day one of class. By the time the semester starts, leads are ready to onboard their own teams immediately rather than spending the first weeks finding their feet themselves.

VERSO’s ORCA program treats the shift into a lead role as requiring dedicated support in its own right rather than assuming it follows naturally from standard program induction. Its onboarding materials for team leads sets out a concrete sequence of activities to help new Leads adjust: getting to know team members’ individual strengths; motivations and support needs; goal setting; planning and timelines; task delegation; monitoring progress and providing feedback along the way; and deliberately celebrating the team’s successes to keep momentum and morale high. This guidance sits alongside broader support for Leads in managing stakeholder relationships and navigating the particular challenges of leading open source research translation projects.

As detailed in the pattern itself, one of the program’s clearest insights is that Leads benefit as much from each other as from any formal material. Creating dedicated space for Leads to share challenges and learn from one another builds a community of practice that strengthens the program as a whole - not just the individual leading a given team.

A Light-Touch Model for Mentorship

Students benefit enormously from exposure to people working in the field but few OSPOs have the staff capacity to manage a large roster of formal, high-commitment mentors. The Industry Fellows: A Light-Touch Volunteer Model pattern offers a solution that scales.

Open Source with SLU’s Industry Fellows program asks for a genuinely minimal baseline commitment: that mentors are present in the program’s Slack workspace and attend two events per semester. Anything beyond that e.g. reviewing code, joining a team channel or mentoring directly is entirely self-directed. Fellows are hired as contingent university employees despite receiving no financial compensation. This confers a handful of meaningful soft perks (a university email address, library access, co-working space access) and ensures they undergo a background check, giving them a genuine and formal connection to the institution. This model has proven particularly effective at attracting busy professionals who would likely be deterred by a heavier, more formal mentorship commitment.

Holistic Assessment for Real-World Work

Grading students on open source internship work poses a genuine challenge. Projects vary enormously in scope and complexity. A narrow focus on technical output risks undervaluing the collaborative and soft skills that are just as central to professional open source practice.

The Assessing Students on Open Source Internship Programs pattern recommends a holistic, evidence-based approach that draws on multiple sources to capture students’ technical, collaborative and communicative contributions - not just a single grade.

Georgia Tech OSPO’s Virtual Summer Internship Program (VSIP) recognises that not every project will reach a finished state within the internship window and prioritises developing engagement with open source practices over strict completion metrics. The program has also explored developing a micro-badging framework to recognise and share student achievements.

At Carnegie Mellon University OSPO, the Summer of Code program leaned on a different but complementary form of evidence: mentor reviews from industry partners including Red Hat, the Eclipse Foundation and local Pittsburgh startups. The strength of student contributions was reflected in just how eager these mentors were to offer participants not just further internships but full-time jobs on graduation - a powerful, real-world validation of student performance that formal assessment processes alone could not have captured.

Open Source with SLU’s practice reflects the pattern’s holistic approach closely: assignments, checkpoints and deadlines serve as evidence for a holistic judgement of a student’s overall growth trajectory, rather than being calculated directly into a grade. The team and client provide feedback on every member. Observational evidence such as how students engage on Slack, their conduct in meetings and how responsive they are to peers and clients is also treated as a vital part of the picture. A 10% ‘stretch’ component rewards professional excellence that goes beyond the baseline. Examples have included conference presentations or substantive contributions to major open source projects.

VERSO’s ORCA program explicitly designs assessments to account for the diversity of projects and the different onboarding, learning and contribution requirements for each of them. Similar to Georgia Tech’s program, it recognises that completing a project may simply not be possible within the program’s timeframe. Assessment draws on a comparably wide evidence base: customer and stakeholder feedback; mentor reviews; learning journals; self-evaluation and for student teams: 360-degree reviews.

Building for Continuity: Designing Internships for Sustainability

A recurring risk in any open source internship model is that the code, once written, does not outlive the semester. Student cohorts are transient by nature and even the most promising projects can be shelved the moment a course ends or a contract expires.

The Open Research Community Accelerator (ORCA) pattern names this problem directly: a significant amount of research software is open source ‘in name only’ and abandoned after its initial release because academic funding structures and faculty incentives rarely reward the ongoing maintenance work that keeps a project alive. Left unaddressed, this turnover disrupts the very pipeline of experienced contributors and maintainers that open source projects depend on.

The Open Source Capstone Course pattern responds to this with a conceptual distinction that serves as one of the most important clarifications in Open Source with SLU’s evolution as a program: the difference between a product and a project.

Products are the long-term vision - something built for a wider community over time. Projects are the short-term, semester-by-semester iterations that advance that vision. Framed this way, a team is never just completing a course assignment; it is contributing one iteration to something intended to outlast its own participation.

To make that continuity real rather than aspirational, Tech Leads are required to produce two handoff documents at the end of each cycle: a community strategy and a product strategy. This structured handoff documentation enables a new Tech Lead to carry the context forward. The value is not only in the finished strategy. The activity of producing it is where much of the real learning about what needs to happen next actually takes place.

Documentation practices are designed with the same continuity in mind on a day-to-day level. Open Source with SLU treats Slack as ephemeral and GitHub issues and pull request comments as the more permanent record of both the work and the reasoning behind it - a distinction that students are explicitly coached to understand as they shift from thinking like a student to thinking like a professional maintainer.

The Industry Fellows: A Light-Touch Volunteer Model pattern reinforces this at the community level: keeping product-specific Slack channels public and long-lived (rather than closing them at the end of a semester) allows knowledge to pass from one generation of student developers to the next and gives new mentors a space to stay engaged with the work that interests them.

None of this guarantees that an active user and contributor community will simply appear. Even with the best of intentions, community does not form overnight. Designing for community from the outset, through public repositories, long-lived channels and explicit community strategy documents does not eliminate that gap. However, it does create the conditions under which a community can eventually emerge rather than ‘closing the door’ at the end of an internship cycle.

Open Source with SLU has more recently begun supporting community-driven products with no client at all but are built instead around meeting a genuine need in the wider open source ecosystem.

Continuity between cohorts is not just a documentation problem; it is also a people problem. The Onboarding Graduate Leads for Open Source Internship Programs pattern notes that creating space for Tech Leads to learn from one another, not just from formal onboarding material, builds a community of practice among leads that strengthens the program as a whole over time. Taken together, these practices reflect a simple but easily overlooked principle: sustainability in a student-run open source program has to be designed in from the start. It cannot be left to whichever cohort happens to be in the room when the funding runs out.

Funding a Program that outlasts its first Grant

Behind all of this design and delivery work sits a persistent, practical question: who pays for an internship program and for how long?

The strategies members are pursuing are varied and, in most cases, still evolving. The University of Wisconsin-Madison OSPO has worked to diversify its funding base by securing an ongoing contribution from AmFam Insurance, a partner of its Data Science Institute, alongside funds from its home department tied to a campus AI research initiative.

OSPOs are also building intern funding directly into research grant proposals - working with mentors who are pursuing sub-awards specifically to support interns as part of their own funding applications.

CURIOSS members also raised a further, often overlooked dimension of this challenge: funding needs to cover not just the interns themselves but the OSPO staff time required to administer the program. External partners are often willing to fund a stipend for an intern but may be reluctant to fund the coordination work behind it, leaving OSPOs to find other ways to cover that overhead. UW-Madison, for instance, builds an additional allocation into its funding proposals specifically to resource staff time.

The Payoff: Real Careers, not just Credit

The effort involved in running open source internship programs is considerable. However, members were clear that the payoff for students is real and measurable.

At the UT Austin OSPO, career development support continues after the program ends. Students participate in two ‘Open to Work’ industry career days a year, which include structured interview coaching, a mock technical interview run in partnership with Microsoft and dedicated resumé support.

More broadly, members reported that recruiters are consistently interested when candidates can point to genuine, visible open source contributions - work that a candidate can actually show, rather than simply describe.

The UW-Madison OSPO described how one of its earliest interns was later identified in AmFam Insurance’s own hiring system as a former OSPO intern when applying for a job, prompting AmFam to reach back to the program director directly.

GW OSPO’s reflections echo a similar pattern. Mentors from established open source organisations have offered not just internships but full-time roles to participating students, providing a level of real-world validation that no formal assessment process could replicate on its own.

Conclusion

Managing an open source internship program is administratively heavy work. It involves designing a program that balances academic structure with professional authenticity; building and maintaining a pipeline of suitable projects; targeting advertising to reach the right students without drowning mentors in unsuitable applications; onboarding both students and graduate leads under tight timelines; and finding a sustainable funding model that outlasts any single grant.

However, CURIOSS members undertaking this work are also unambiguous about why it matters. When the number of tech internship opportunities is not keeping pace with student demand and while AI-generated applications are making it harder than ever to distinguish real skill from a well-worded CV, open source internships offer something a simulated coursework project cannot: a real codebase, a real client, a real community, and a body of visible, verifiable work that follows a student well beyond graduation.

Because of their position at the intersection of faculty, students, industry and the wider open source community, academic OSPOs are uniquely positioned to facilitate internship and ultimately, employment opportunities for students.

As this growing body of CURIOSS patterns shows, that position is exactly what makes them so effective at closing the internship gap.


Acknowledgements

This article draws on CURIOSS patterns, discussions with CURIOSS members and a CURIOSS Deep Dive

Photo by Mushvig Niftaliyev on Unsplash.

Many thanks to:

Angela Newell (University of Texas at Austin OSPO, Texas-OSPO), Bethany Philbrick (University of Wisconsin-Madison OSPO), Collin Capano and Will Gearty (Syracuse University OSPO), David Lippert (George Washington University OSPO), Daniel Shown (Open Source with SLU), Fang Liu and Jeffrey Young (GT-OSPO), Kendall Fortney (VERSO OSPO), Megan Forbes (Johns Hopkins University OSPO), Sayeed Choudhury and Tom Hughes (Carnegie Mellon University OSPO) along with the wider CURIOSS community whose patterns underpin this piece.

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 article 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 article 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!

*Knowledge sharing is at the heart of the CURIOSS community. Our members develop ‘patterns’ to record how they resolve problems facing academic OSPOs in university and research institutions. We categorize the patterns based on the common themes, priorities or challenges identified by members.

** CURIOSS hosts regular talks to support knowledge exchange and to accelerate the advancement of academic open source throughout the ecosystem. At our monthly Deep Dives, we invite an expert in the field of open science, open research or academic open source to speak to CURIOSS members and participate in a Q&A session under Chatham House Rule.