An ecosystem canvas makes an open-source project say who it's really for. Here's what ours surfaced about stdlib's value propositions for contributors and users—and why they're not the same.
This is the first in a series of posts on the tools we picked up during I-Corps training—part of the NSF's POSE (Pathways to Enable Open-Source Ecosystems) program—and what each one showed us about stdlib's ecosystem. It picks up where AI and the Invisible Newcomer in Open Source left off: that post was the diagnosis—the visible friction open-source communities have always relied on is being absorbed by AI, and what's eroding underneath is how newcomers get seen. It closed on a question—
what signals are you still relying on that may no longer be reaching you?—and a promise to come back to the tools we've been using to ask it.
One discipline ran through the whole program, and it's worth stating up front because it decides whether these tools work or just flatter you: you don't pitch—you examine. You're there to learn what's true about your project, not to sell anyone on what it already is. A canvas you fill in to feel good about yourself is worthless.
How you do the examining is on a sliding scale. The program ran on roughly 100 interviews in seven weeks—brutal, and not what most teams will (or should) try to repeat. The canvas works at lower fidelity too: a team running its own prompts honestly, a handful of conversations with people in your orbit, even one careful pass with the people already in the room. The discipline is what travels; the interview count scales to whatever you can get.
What the canvas is #
The program led with the Open-Source Ecosystem Canvas: a grid of cells you fill in, one per facet of the project—who it's for, what value they get, how you reach them, what it costs, how it's funded. It's adapted from the Business Model Canvas, and the adaptation is the interesting part. An open-source project doesn't have customers in the SaaS sense, and the people who use it, build it, and fund it are often three different groups. So the canvas makes you account for value role by role, instead of letting you collapse everyone into a single "user." Most of what follows came from that one move.
What makes the canvas different from a plan is that nothing on it is a promise. Every cell is a hypothesis—what you suspect is true, written down where you can look at it, not what you've committed to deliver. That's a strange kind of freedom: a canvas is a place to be tentatively wrong on purpose. A blank brainstorm follows your attention—you end up circling the parts of the project you already think about. The canvas fixes the prompts in advance, so it asks about the cells you'd never have raised yourself. Those are usually the ones worth lingering on.
What ours surfaced #
So here's ours. We've worked on it and it's still unfinished—which is what a canvas is supposed to be: some cells are firmer than others, and a few are mostly still questions. Doing it turned up things we'd been quietly avoiding: about sustainability, about the gap between who we were building for and who we said we were building for, about what the next ten years of stdlib look like if we change nothing.
Two cells did most of the surfacing.
Value Propositions. This cell asks you to think beyond the fact that you're shipping "free" code, and name what value each kind of person gets from the project—and the moment we took that seriously, one answer split into several. Contribution as a résumé line and a career stepping-stone? Numerical computing that runs on anything with a browser, no server or back end required? Familiar data tooling for people arriving from Python or R? These don't reduce to a single pitch, and forcing them into one would have buried the actual finding: some of these are reasons people use stdlib, some are reasons people contribute to it, and those turned out not to be the same people.
Community Members. This cell asks you to list who's actually there. We wrote down the obvious roles—core maintainers, Google Summer of Code (GSoC) alumni who stuck around, ecosystem package authors, industry users, the JavaScript developers who'd steered clear of statistics because the tools weren't there—and a handful more. Then we noticed a phrase we'd typed almost without thinking, parenthetical, next to casual contributors: usually non-users. That aside was doing more work than the rest of the list. For a lot of open-source projects, contributors are a subset of users—they show up because they hit a limitation in something they depend on. For stdlib, that's frequently not the case. A large share of the people opening pull requests aren't people using JavaScript for numerical computing in their own work; many arrive through GSoC and other on-ramps, and they're building the thing more than using it. Once that's written down, you can't un-see it—and you can't describe both groups honestly on one grid. We ended up needing two canvases, one per community, because the questions that matter for the people who build stdlib aren't the questions that matter for the people who depend on it. A project where contributors and users overlap heavily might never need that split—the canvas surfaces what's true for you, not a particular answer. And the canvas keeps asking for more precision than its grid can hold—"users" isn't one group either, which is where the rest of the series picks up.
It's worth saying why an exercise like this earns its discomfort. The ground under open source is moving fast enough that the honest reactions are either to keep shipping and trust it'll sort itself out, or to decide the whole thing isn't worth the trouble anymore. Both are real, and both can be self-protective if left unexamined. A canvas is the examination—stopping to look at what you're actually doing and who it's for, before you decide. And if you decide parts of it aren't worth sustaining, that's a decision made on purpose rather than by default—different from throwing up your hands. And if you decide it is worth sustaining, it shows you where the work has to change by design—the note the last post ended on: the on-ramps that used to happen by accident increasingly have to be built.
You don't need ours, though—you need yours. That's the whole point: filling one in surfaces the choices you'd otherwise leave implicit.
What to ask once it's filled in #
A filled canvas isn't the deliverable—the conversations it forces are. The useful questions read across cells, not down a single column—for us, that means questions that straddle the split between non-user contributors and the users they build for. The best of them are the ones you can't answer without going and asking someone. A few we're sitting with:
Do our operations actually deliver the value we promise contributors? Our Operations-and-Activities cell lists GSoC as the contributor pipeline, with monthly newcomer sessions and office hours as the mentorship structure. Our Value Propositions include mentorship and recognition, and contribution as a career stepping-stone. Do those activities close that loop—does a GSoC contributor leave having gotten what we say they'll get?Do users' value propositions match the ones we think we're offering? Our Value-Propositions cell mixes contributor value (résumé-builder, mentorship) with user value (browser-native results, familiar tooling for Python/R developers, no back end). This is the one you pair with interviews. What you think you're building and what your users think you're building are not necessarily the same thing.Are our go-to-market activities still pointed at the people we want? Our Go-to-Market cell was built for a pre-AI world: Bluesky posts, conference talks, SEO, cross-posting, video onboarding. If AI is absorbing those accidental on-ramps, which of those activities still land—and which need to be jettisoned and replaced with something else? One channel is sliding into gatekeeper territory: AI-mediated discovery is increasingly how developers find their way to a numerical library, and the canvas' flat Community Members cell can't see it. Another tool from the program—Ecosystem Segmentation, which we'll get to later in this series—splits User from Decision Maker from Gatekeeper, and that split is what makes the gatekeeper visible.Are the resources keeping this alive still going to be there? Open-source projects run on time, money, and effort that someone commits to them—written down by name in the canvas' Funding-Sources, In-Kind Support, and Costs cells. For us right now, that's an NSF POSE grant, in-kind labor from sponsoring companies, and recurring donations. AI has already changed the shape of open-source communities, not just for newcomers—and the labor that goes into the code itself isn't immune. There's a physics teacher's line in Svetlana Alexievich'sSecondhand Timewe keep returning to: money solves all problems, even differential equations. Particularly sharp when the differential equations are the product.
Some of those questions gesture at something the canvas does quietly. It captures not just who's in your world—builders and users—but the gap between the state you're in and the state you want. The discipline that exposes that gap is to work the canvas right to left: start with who you want your Community Members to be and what Impact you want to have, then ask whether your current Value Propositions match the community you've actually got. If they don't, the cells you've written down are describing a project pointed somewhere other than the future you want. The cells that earn their keep aren't the ones describing what you do now; they're the ones that make you decide what to carry forward and what to stop.
Run it yourself #
No special software, no template, nothing that has to look like ours: a canvas is just as happily done on paper, in a shared doc, on a whiteboard, or vibe-coded in an hour. The format matters less than the honesty.
Next in the series, we move from who's in your world to how value flows through it: the Ecosystem and Stakeholder Map—including the people who aren't rooting for you.
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!