The Open-Source Ecosystem Canvas

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.<br>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.<br>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.<br>What the canvas is<br>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.<br>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.<br>What ours surfaced<br>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.<br>Two cells did most of the surfacing.<br>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.<br>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...