The Stakeholder Journey: From User to Contributor

This is the third post in a series on the tools we picked up during I-Corps training, part of the NSF's Pathways for Open-Source Ecosystems (POSE) program. The Open-Source Ecosystem Canvas and the Ecosystem and Stakeholder Map both ended on the same question—what does it actually take to keep a project alive?—and on the observation that the passive window we used to watch our communities through is narrowing. This tool is about looking on purpose instead.

What the journey is

The third tool is the Stakeholder Journey, taught to us by Betsy Peters as part of the go-to-market module of POSE. It maps the path a person takes from never having heard of your project to being one of the people who sustains and leads it:

Discovery → Acquisition → Activation → First Impact → Habit → Commitment → Ecosystem Leadership.

Most projects, when they think about onboarding at all, think about the left side. Discovery is whether your project shows up—in search, in a tutorial, in a coworker's recommendation, in an AI's suggested package. Acquisition is whether someone reaches it: installs it, opens the docs, clones the repo. Activation is whether they get past the first wall—the README works, the install command runs, the example does what it promised.

These are the things engineering teams instinctively optimize for. They're also where most projects stop. We made it easier to install. We rewrote the getting-started guide. We added a Colab badge. All of that work matters. It's not enough.

First Impact is the pinch point

The pinch point at the center is First Impact—the moment when a person can say this thing helped me achieve a goal I actually had. Not "I got it running," but "it did the thing I came here to do." Without First Impact, nobody moves any further to the right. Everything downstream is gated by it. A project can have a beautiful README and a flawless install and still fail at First Impact, because the person came looking for a result, not a successful build.

The right side of the journey is what you're actually building toward. The left—Discovery, Acquisition, Activation—is about volume and lowering friction. The right is about depth, repeat use, and the people who eventually keep the project alive. And the right side is where the open-source-specific problem hides.

Everything up to Habit used to be relational by accident. To get the install to work, the example to do the thing, the edge case to resolve, you had to look in someone's docs, read someone else's post about hitting the same wall, maybe venture into the somewhat hostile waters of Stack Overflow. None of that was billed as community engagement. It was the cost of getting the thing to work. But every step put you in proximity to other people's care—the maintainer who wrote the doc, the contributor who answered the question three years ago, the stranger who took your duplicate question seriously enough to point you somewhere. The community wasn't somewhere you went; it was somewhere you passed through to get to the thing you came for. AI dissolves the passage. The install still has to run, the example still has to do the thing—but you can now clear those walls without ever touching the artifacts of care that used to do the introducing. AI and the Invisible Newcomer in Open Source was about what we didn't know we were relying on until it was gone.

Habit is the territory of repeat use—the project becomes a default, a known quantity in someone's toolchain. This can still happen passively. People settle into tools because the tool works and they don't have to think about it. Someone finds your project, uses it, relies on it—and you may never know they exist. Habit users have never been fully visible—plenty went unseen even when public friction was the norm—but the passive window the Ecosystem and Stakeholder Map named used to make more of them visible than it does now, if not to maintainers then to each other. That visibility to each other matters: people who can see others engaged at the same stage recognize themselves as part of something larger, and what you help build feels worth more than what you just consume.^[1] AI absorbs the friction that produced that visibility, which means projects at the Habit stage increasingly have plenty of repeat users and no idea who they are.

Commitment is different. Commitment is a crossing—the moment a person stops being a user and starts being someone who tends to the project. They file the issue. They open the PR. They answer somebody else's question. They show up to the call. (Past it lies one more stage, Ecosystem Leadership—the people willing to help steward the whole thing—but Commitment is the crossing everything hinges on.) The transition from Habit to Commitment is the one that has never happened by itself, and it has gotten harder, not easier, as Habit has grown less visible.

The three conditions that have to be true for someone to make that crossing are uncomfortably soft to talk about, and they matter anyway: people have to feel seen and valued; they need an authentic connection inside the project, not just awareness of it; and they have to participate in creation, not just consumption—to feel like they helped shape something, not only consume it.

None of those happen on their own. Discovery through Habit can be a passive flow. Commitment isn't.

Who does the inviting

AI and the Invisible Newcomer in Open Source landed on invitation: that crossing into a community almost never happens by accident, and that there's usually a person with standing who reaches out and makes it personal. The journey is where you can see exactly what that act does. Invitation is the force at the Commitment crossing—the one transition no amount of passive flow will carry someone across.

Among the people we interviewed who'd already crossed that chasm—the maintainers, the stewards—the story came back the same shape. Nobody starts their open-source journey with a grand plan to maintain a project. You stumble in. You find something that works. You stick around because it keeps working. You read an issue, then another. You answer one question. Somewhere along the way, almost without noticing, you're doing it because the work itself matters to you. That shift—from user to contributor, from consumer to caretaker—doesn't happen by accident. There has to be someone with standing already inside the community who reaches out, who makes it personal, who says: we see you, and there's a place for you here.

So who does the inviting?

The people in the inner rings. The scaffold AI and the Invisible Newcomer in Open Source laid out—old-timers at the center, casual visitors at the outermost edge, a labeled trajectory pulling inward through intermediate roles—describes how any community works, and it pins down where the inviting has to come from. The people whose attention pulls that trajectory are the ones with the standing to do it. It's the same point the communities-of-practice literature has made for decades^[2]—that the journey from periphery to center is a social one, needing paths and people willing to guide—but the journey map is where you can finally put your finger on the step it happens at.

But "the inner rings do the inviting" hides a more specific mechanism. Invitation from the center—the maintainer who reaches out, the steward who notices—is rare and high-signal and doesn't scale. The daily work of pulling someone inward, the work that makes the next step look like a step rather than a leap, is done by the person one ring ahead of them. The trajectory the figure draws as a single arrow from edge to center is, in practice, a relay of short pulls. The near-peer who just crossed the same threshold is a better guide than the expert who crossed it years ago—not because they know more, but because they can still see where it was hard.^[3]

That mechanism needs density. A community where the next ring is visibly populated—where someone at Habit can see other people doing what Commitment looks like—can pull contributors along it. A community where the rings are sparse can't. The path doesn't close; it stops being visible from where most people are standing. Recent empirical work on aging OSS projects finds that sustained substantive engagement is what keeps the trajectory functioning over time, while passive attention loses its predictive power as a project ages.^[4] The failure mode is quiet: the dashboards stay green; the path just stops being navigable.

Invitation is how the trajectory begins. Belonging is what carries it forward. And belonging—not a tutorial, not your CONTRIBUTING.md—is what turns a user into a contributor.

Three questions for every project

If there's a single way to summarize what the canvas, the map, and the journey are for, it's that they make three questions impossible to leave unanswered.

1. Have you mapped your ecosystem—including the saboteurs? Or are you assuming you already know who's in your world? Most projects know their power users by name and their critics by reputation, but can't actually draw the network of incentives around them. The map exists because the people you haven't named are still acting on your project—funders, competitors, downstream maintainers, model providers, the people quietly recommending a different library in every Slack you can't see. If you can't see them, you can't steer around them, and they will steer anyway.
2. Are you designing your contributor pipeline—or assuming it will appear? It used to appear on its own—the byproduct of public friction that AI and the Invisible Newcomer in Open Source was about, and the one that's weakening. Designed programs help, but they aren't a substitute: even Google Summer of Code, about as structured an onramp as open source has, sees only around 45% of true newcomers^[5] who keep contributing after the program ends, and most never arrived intending to become maintainers in the first place.^[6] So, if you want a next generation of people who can run your project after you, the activities friction used to produce for free have to be built on purpose now: invitation, mentorship, and a path from user to contributor to maintainer with visible, named rungs that people know exist and can actually reach for. Mentorship in particular has more measurable shape than it usually gets credit for: in the most thorough study to date^[7] of mentors in Google Summer of Code, Tan and colleagues find that the heaviest load falls in proposal evaluation and the first weeks of onboarding—phases you can design around once you know they're the binding ones.
3. Is your community built for survivorship? Not just for how things worked before. The shape of the world a project's community grew up in is not the shape of the world the next one will. The question isn't whether the old onramps are still working; it's whether you've designed onramps that still work when the old ones don't.

The reason to ask these isn't to add another set of metrics to a dashboard. It's because the projects that will still matter in ten years—the ones that are still vibrant and alive—will be the ones where someone chose to tend to the community with the same rigor they brought to the code.

The code is the part that's easy to measure. The community is the part that decides whether the code still matters.

---

Mara Averick is a developer advocate at Quansight and contributor experience lead for stdlib.

---

stdlib is an open source software project dedicated to providing a comprehensive suite of robust, high-performance libraries to accelerate your project's development and give you peace of mind knowing that you're depending on expertly crafted, high-quality software.

If you've enjoyed this post, give us a star 🌟 on GitHub and consider supporting the project. Your contributions and continued support help ensure the project's long-term success and are greatly appreciated!

Acknowledgments

This work was supported in part by the National Science Foundation under Award No. 2449410.

Disclaimer: Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.

---

1. Strayhorn, T. L. (2018). College students' sense of belonging: A key to educational success for all students (2nd ed.). Routledge. https://doi.org/10.4324/9781315297293 ↩︎
2. Sholler, D., Steinmacher, I., Ford, D., Averick, M., Hoye, M., & Wilson, G. (2019). Ten simple rules for helping newcomers become contributors to open projects. PLOS Computational Biology, 15(9): e1007296. https://doi.org/10.1371/journal.pcbi.1007296 ↩︎
3. On the curse of expertise—the structural blind-spot experts develop about what was hard for them years ago: Hinds, P. J. (1999). The curse of expertise: The effects of expertise and debiasing methods on prediction of novice performance. Journal of Experimental Psychology: Applied, 5(2), 205–221. https://doi.org/10.1037/1076-898X.5.2.205. See also Nathan, M. J., & Petrosino, A. (2003). Expert blind spot among preservice teachers. American Educational Research Journal, 40(4), 905–928. https://doi.org/10.3102/00028312040004905. ↩︎
4. Kaushik, M., & Chahal, K. K. (2026). Community engagement and the lifespan of open-source software projects. Information and Software Technology. https://doi.org/10.1016/j.infsof.2025.107914 — sustained substantive participation keeps aging projects alive; passive attention loses predictive power as a project ages. Companion death-spiral dynamics paper: Kaushik, M., & Chahal, K. K. (2026). The death spiral of open source projects: A post-mortem analysis of pull request workflow dynamics. Journal of Systems and Software, 240, 112942. https://doi.org/10.1016/j.jss.2026.112942. ↩︎
5. Silva, J. O. dos, Wiese, I., German, D. M., Steinmacher, I., & Gerosa, M. A. (2017). How long and how much: What to expect from Summer of Code participants? ICSME 2017. https://doi.org/10.1109/ICSME.2017.81 ↩︎
6. Silva, J. O., Wiese, I., German, D. M., Treude, C., Gerosa, M. A., & Steinmacher, I. (2020). Google Summer of Code: Student motivations and contributions. Journal of Systems and Software, 162, 110487. https://doi.org/10.1016/j.jss.2019.110487 — surveys of 141 students and 53 mentors plus ten confirmatory interviews found most students enter GSoC seeking an enriching experience or skill development, not long-term project membership. ↩︎
7. Tan, X., Zhou, M., & Zhang, L. (2023). Understanding mentors' engagement in OSS communities via Google Summer of Code. IEEE Transactions on Software Engineering, 49(5), 3106–3130. https://doi.org/10.1109/TSE.2023.3242415; they catalog 41 distinct challenges and 52 strategies across all phases. ↩