Originally published on kopecmartin.github.io. Presented with Lukáš Piwowarski at OpenInfra Summit Vancouver, June 2023.
The open source contribution problem is usually framed as a recruitment problem: how do we get more people interested in contributing? But after digging into the data and talking to contributors across the OpenStack community, Lukáš Piwowarski and I came to a different conclusion: the interested people are already there. What's blocking them is friction.
The numbers that reframed the question
71% of people who don't contribute upstream regularly said they would appreciate a pool of first-issue tasks. That's not a marginal finding: it's the majority. And at the OpenInfra Summit in Vancouver, roughly 45% of attendees were first-timers. The interest in contributing is clearly there. The gap is between wanting to contribute and actually knowing how to start.
When we asked people why they don't contribute more regularly, three answers kept coming up: not enough time, uncertainty about where to start, and difficulty finding suitable tasks. These aren't personality problems or lack of motivation. They're process problems. And process problems can be fixed.
The friction is the problem
A first contribution to a new project carries a disproportionate cost. You need to understand the codebase, the review process, the community norms, the tooling, and the scope of what's expected, all before you've written a single line. That's a lot of invisible overhead. If the first task is also poorly defined, or if nobody responds to your questions for two weeks, you're done before you started.
This is worth taking seriously because the cost of a bad first experience isn't just losing one contributor. It's losing everyone they might have told. And in a community where development activity has been declining, every missed contributor matters.
What actually helps: four requirements for a good first-issue pool
The solution we proposed is deceptively simple: a curated pool of lower-difficulty tasks, designed specifically to reduce the cost of a first contribution. But the curation part matters. Not every issue tagged "good first issue" actually is one. For a task to genuinely serve a new contributor, it needs to meet four criteria.
First, it needs to be well documented. The task description should include all the context a newcomer needs to understand what's required, with no assumed knowledge and no dependencies on institutional memory. If you need to have been around for two years to understand what the issue is asking, it doesn't belong in the pool.
Second, there needs to be a clear definition of done. Ambiguity about what "finished" looks like is a particular tax on first-time contributors, who don't have the experience to calibrate against community expectations. The task should specify exactly what a successful contribution looks like.
Third, a mentor should be assigned. Someone knowledgeable enough to answer questions and review the contribution, and who has committed to actually being available. A mentor in name only doesn't help anyone.
Fourth, response times need to be fast. This addresses the "no time" obstacle directly: if a contributor posts a question and hears nothing for ten days, the context is gone and so is the motivation. Quick feedback is what keeps the contribution moving.
The Atomic Habits angle
There's a principle from James Clear's Atomic Habits that's relevant here: the best way to build a habit is to reduce the friction of starting it. The same logic applies to open source contribution. If the first experience is smooth enough that someone wants to do it again, you haven't just gained a contributor. You've helped someone build a habit.
There's also something to be said for "puttering around": the low-stakes exploration of a codebase that doesn't have a clear deliverable. The research suggests this kind of engagement helps prevent contributor burnout. Not every interaction with a project needs to produce a merged patch. Sometimes just being around, reading the code, following the discussions, is part of how people become contributors at all.
The main takeaway
As little as decreasing friction with the contribution process can help significantly. You don't need a large programme or a complex onboarding system. A well-maintained pool of genuinely accessible first issues, with real mentors and fast response times, can move the needle. The people who want to contribute are already there. The question is whether you're making it easy enough for them to start.