Mapping Your Ecosystem (and Its Saboteurs)
Naming everyone in your open-source ecosystem—both competitors and colleagues—and following where value flows.
This is the second post in a series on the tools we picked up during I-Corps training, part of the NSF's POSE (Pathways to Enable Open-Source Ecosystems) program. The first post covered the Open-Source Ecosystem Canvas—who you're building for, what it takes, and how you sustain it. This one is about drawing the network those answers live inside.
The map changes as you learn. Like the canvas, it surfaces the assumptions you didn't know you were making.
What the map is
The tool is the Ecosystem and Stakeholder Map. Your project doesn't operate in a silo; the map simplifies the world around it enough to look at. The first thing it asks you to do is something surprisingly difficult: name everyone who is in your world.
Not just your users.
Not just your contributors.
Everyone.
Our map has a box labeled "Saboteurs"—a category the I-Corps program asks every team to fill in. The label is sharper than the function. In the framing, "saboteurs" is one of six stakeholder categories (among them competitors, partners, users, contributors, and influencers), not a class of villains.
Many of the people in it are friends and colleagues whose work is good and valuable, and we're not trying to deny that. The point of the box is closer to what else is around here that could take our place. These are the projects and people who inform what we do—who could plausibly substitute for us, who is shaping the conversation around what we build. Knowing how you fit in that competitive landscape is how you figure out where your project adds value. Leave the box blank and you lose your read on where you stand, and on what it will take to keep standing there. And the box isn't hypothetical: of our hundred-odd interviews, fourteen were with people who belonged in it—alongside industry and academic users, contributors, downstream adopters, and funders.
And not every saboteur is a competitor. One of this year's CHI papers names a different kind—"Invisible Saboteurs"1—high-sycophancy LLMs that made users less likely to correct their misconceptions, with a majority unable to detect that AI was being agreeable. The most consequential saboteur in your ecosystem may not be another project at all. It may be a tool that agrees with everyone, including your newest contributor, at the moment they're forming the wrong mental model.
One small discipline that pays off here: map people before organizations, and notice your blind spots. The world your project sits in is bigger than the people you already know to name. The segments where you can only name one or two—or none—are where your understanding is thinnest and your confidence is least earned. They're also where opportunities tend to hide.
The arrows matter as much as the nodes
The map isn't only a roster of who's there. It's a steering tool: arrows show how value flows. Where it comes from, where it goes, where it leaks.
We tend to talk about open-source value in concrete terms. The software is free. The tooling saves time. The license costs nothing. Those are real, and they belong on the map. But there's a less tangible current, too: reputation and belonging. Standing. The regard of people whose regard means something.
That's always mattered. It matters more now. As AI makes writing code faster and cheaper, the thing that doesn't get cheaper is trust—because trust requires a real other with the standing to withhold it. A system engineered to validate you can satisfy the form of recognition without the substance2; a friend whose approval costs them nothing isn't really a friend3. When you weigh in on a decision, people listen—not because of your commit count, but because of what you've earned in the community over time. That is a value proposition. It belongs on your map alongside the funding arrows.
What the canvas and the map are both asking
Both are asking the same question.
What does it actually take to keep an open-source community alive?
Part of the answer turns on a distinction that's easy to miss. Your code can be copied, distributed, and shared without being depleted—if anything, it grows in value the more it's shared. Your community is the opposite. Time, attention, and trust are finite, spent in the giving, and not replenished automatically—which is why burnout is a resource-depletion problem. The code can largely sustain itself. The community has to be designed. The code is free; the community isn't.
That's why the honest answer to what it takes has three levels, and most projects only think seriously about the first one.
Level 1 is code. Does it run. Does it build. Are the tests green. Is the dependency graph manageable. This is the level that maintainers are trained to think about, that funders understand, that GitHub measures for you. Almost every "sustainability" conversation in open source starts and ends here.
Level 2 is governance. Who decides. How decisions get made. What happens when the founder steps back, or burns out, or moves on. Whether there's a process for contention that doesn't depend on a single person being in the room. Some projects take this seriously; many don't, and by the time they need to, the people who would have done the work have already left.
Level 3 is community. Who actually shows up. Whether new people are arriving, and whether the people already there are staying. Whether the project has a story about itself that someone could find their way into. This is where projects die—not when the code breaks, but when nobody's left who cares enough to fix it. The empirical record on project abandonment bears this out. A post-mortem of 104 deprecated GitHub projects found the recurring failure modes were community-side, not code-side: loss of the lead maintainer, lack of time or interest from main contributors, displacement by a competitor 4. The live-project picture mirrors this: in a study of nearly 34,000 active GitHub repos, what predicted longevity wasn't stars, watchers, or workflow efficiency but active community engagement on issues—and that predictive power intensifies as projects age 5. Both are proxies—measuring issue activity and deprecation events, not the sense of belonging that actually keeps a community alive. But anyone who's worked in one knows the research is pointing at the right wall.
The asymmetry matters here. AI is good at producing the artifact and bad at producing the attachment, because attachment is a byproduct of the labor AI removes. The merged PR, the answered question, the completed exercise can all look identical whether a person grew through them or skipped them—and the difference, invisible on the artifact graph, is the entire ballgame for whether your community has a next generation.
For a long time, Level 3 had a window we could look through without thinking about it. Stack Overflow. GitHub issues. Mailing lists. Forum threads. We could see—passively, almost automatically—whether the community was still there, because people kept showing up to ask questions in public.
That's the window AI and the Invisible Newcomer in Open Source was about. It's narrowing.
The point of what comes next isn't to mourn the window. It's to notice that if the passive view is gone, the active one has to be designed. What used to happen by accident is now deliberate work. That's the Stakeholder Journey, which I will discuss in the next post in this series.
Notes
1. Bo, J. Y., Kazemitabaar, M., Deng, M., Inzlicht, M., & Anderson, A. (2026). Invisible saboteurs: Sycophantic LLMs mislead novices in problem-solving tasks. In CHI '26: Proceedings of the 2026 CHI Conference on Human Factors in Computing Systems. https://doi.org/10.1145/3772318.3791365
2. Jacobs, K. A. (2024). Digital loneliness—Changes of social recognition through AI companions. Frontiers in Digital Health, 6, 1281037. https://doi.org/10.3389/fdgth.2024.1281037
3. Sparrow, R., & Brown, J. (2026). Against imaginary friends: Why digital companions are no solution to social isolation. Communications of the ACM, 69(2), 60–68. https://doi.org/10.1145/3750037
4. Coelho, J., & Valente, M. T. (2017). Why modern open source projects fail. In Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2017) (pp. 186–196). https://doi.org/10.1145/3106237.3106246
5. 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
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.