DEV Community: stdlib

The Stakeholder Journey: From User to Contributor

Athan — Wed, 08 Jul 2026 09:34:49 +0000

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.¹ 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²—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.³

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.⁴ 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.

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.
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⁵ who keep contributing after the program ends, and most never arrived intending to become maintainers in the first place.⁶ 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⁷ 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.
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.

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 ↩
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 ↩
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. ↩
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. ↩
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 ↩
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. ↩
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. ↩

Mapping Your Ecosystem (and Its Saboteurs)

Athan — Sat, 27 Jun 2026 08:26:42 +0000

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"¹—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 substance²; a friend whose approval costs them nothing isn't really a friend³. 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 ⁴. 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 ⁵. 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.

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.

The Open-Source Ecosystem Canvas

Athan — Wed, 17 Jun 2026 15:00:00 +0000

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's Secondhand Time we 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.

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.

What We're No Longer Seeing: AI and the Invisible Newcomer in Open Source

Athan — Mon, 08 Jun 2026 15:00:00 +0000

How AI is absorbing the visible friction that open-source communities have always relied on to see—and welcome—newcomers.

Last winter, our team went through I-Corps training as part of the NSF's POSE—Pathways to Enable Open-Source Ecosystems—program. I-Corps is the National Science Foundation's customer-discovery training, and POSE adapts it for open-source projects. For us, that meant seven weeks and more than a hundred interviews with stakeholders in and around our ecosystem. (The "us" here is stdlib, an open-source standard library for JavaScript and Node.js, with an emphasis on numerical and scientific computing.)

These ecosystem-discovery interviews had one hard and fast rule: you don't pitch. No explaining what stdlib does, no defending decisions, no selling.

You ask, and you listen.

So that's what we did. The curriculum taught us how open-source ecosystems are supposed to be sustained—the frameworks, the canvases, the interview discipline. The interviews taught us something nobody had put on the syllabus. Talking with maintainers, contributors, and users, the same theme kept surfacing: AI was changing how people found projects, got help, and contributed. And we weren't just hearing it in the interviews. At conferences and in hallway conversations, in blog posts and LinkedIn threads, peers who do developer relations and community work for a living were describing the same shift from their own angles.

We went to learn about our ecosystem. While we were looking, the ecosystem was changing around us.

This post is about what we were seeing. It's also about what we weren't.

For a long time, open-source communities have depended on a specific kind of visible friction. People got stuck and they showed up—on Stack Overflow, in GitHub issues, on mailing lists, in forum threads. That first act of asking for help in public was itself a form of participation. It was the way you found the edge of someone else's community, and the way they found you.

There's an old model from Charles Vogl's The Art of Community—the idea that any community has concentric rings around it. People start as visitors. They find their footing. They ask, in one way or another, what am I doing here? The journey from the outer ring inward—visitor to member to elder—isn't automatic. It requires visible pathways. It requires people willing to guide. And, crucially, it requires that the path be known to others.

That model isn't unique to Vogl, or to open source. The figure below comes from a study of a community most readers have no skin in: recreational scuba divers in the early 1990s. Edouard Lagache, building on legitimate peripheral participation (a term coined by Jean Lave and Étienne Wenger), mapped the same geometry—old-timers at the center, casual sightseers at the outermost ring, a labeled trajectory pulling inward. People become members of a community by doing low-risk things at its edges—things that exist because there's a structure around them that makes them visible. Early 90s scuba diving is just an example, but the same dynamic and shape exists in open source, in sports, in fandoms, in any community you can name. The details differ, but the geometry is the same.

What made it work in open source, structurally speaking, was friction—visible friction. Someone got stuck, showed up, and both sides could see each other. That first public question was a form of initiation, and it was also legitimate peripheral participation in action: a low-risk, visible way of taking part from the edge. That dynamic is woven through decades of open-source community-building practice—it's underneath Ten simple rules for helping newcomers become contributors to open projects, among others. The public question made the newcomer visible, and it created the opportunity for someone already inside to respond.

It also made the community visible to the newcomer. Oh—there's a there here. There are people. There's a way in.

For a while, the shift we kept hearing about was a vibe more than a finding—something you could feel in the conversations before you could point to it on a chart. But it kept turning out to be tangible. At FOSDEM this year, David Allen, who leads developer relations at Grafana, showed everyone his numbers, describing a moment some maintainers haven't had yet but many will.

He'd gotten comfortable expecting community growth of 8 to 18 percent a quarter, almost automatically—I could fall asleep, he said, and the community would grow. Then one quarter the number dropped 27 percent. They checked the data, ran it again, and it wasn't a measurement error: the number of people entering the community had collapsed, even though overall user growth was still going up. The mechanism wasn't mysterious, either. Organic traffic to community spaces was down roughly 30 percent, traceable to question-and-answer behavior moving to LLMs.

And it's not a one-project story. A 2024 study in PNAS Nexus found a clean way to isolate the effect: compare Stack Overflow activity in English (where ChatGPT was available) with Russian- and Chinese-language counterparts (where it wasn't), and with mathematics forums (where LLMs are weaker). Within six months of ChatGPT's release, English-language activity had dropped 25 percent relative to those controls—and the authors call that a lower bound. The decline wasn't limited to beginners or to duplicate questions. Experienced and inexperienced users alike posted less.

And that was 2024. You don't need a natural experiment to know what's happened since: LLM-assisted development has gone from novelty to default, and more of the questions that used to be asked in public are answered in private.

Allen and his co-presenter, Amanda Wagner, offered a framing I keep coming back to: AI isn't the cause of this. It's an accelerant, exposing foundations that were already fragile.

Here's where the argument I want to make sharpens.

The surface loss is signal. Questions that used to surface as GitHub issues or forum threads are now answered privately. That's real, and it's measurable, and it's not nothing. But it understates what's actually happening.

When AI handles the initial friction, the newcomer gets unblocked. They get functional value. They make progress; they solve the problem. But they get it without connection—without anyone seeing them, without a moment of initiation. This isn't inherently bad. It's just different. However, the friction that we've always addressed as a "bug"—the thing we wanted to smooth out—was also doing work we didn't understand until it was gone.

Think about what deepens anyone's engagement with a community—what turns getting an answer into the start of a journey: they choose it, they're making progress in it, and they feel some connection to the people in it. AI delivers choice and progress with remarkable efficiency, but it doesn't replicate connection.

And here's the part that doesn't get said enough:

The blindness goes both ways.

The newcomer doesn't know they're at the edge of your community. They're using your software through an AI intermediary, and they may not think of themselves as being in relationship with a project at all—only with a tool. They don't know you exist as a community. They only know you exist as a dependency. They have no idea that they're already part of your ecosystem.

And you don't know they're there.

Vogl's inner-rings model depends on visibility in both directions. People can only be invited inward if they can be seen. They can only begin the journey if they know there's a path. When the first interaction with a project happens through an AI layer, neither condition is reliably met.

This is a different problem than the old problem of lurkers. Lurkers were quiet, but they were present. They were in your spaces. They could see you, even when you couldn't see them. The observer who finds your library through an AI assistant may never visit your spaces at all.

To be clear: not everyone wants to move inward, and that's fine. Vogl writes about this directly—most members of any community stay in the outer rings, and a healthy community makes room for them. Users don't owe a project anything. But open-source ecosystems aren't sustained by everyone; they're sustained by the few who do make the journey inward. And that's the real cost of the outer rings going invisible. It's not that every unseen user is a lost contributor. It's that we no longer know who's out there—which means we no longer know whom to invite.

What's actually being lost, then, is not support traffic or page views or the other surface metrics. It's the early moments of maturation—the activities that mark a new member, signal arrival, and begin the process of belonging. The public question used to be one of those moments, almost without anyone meaning it that way. It made someone visible, opened a door, created the conditions for response.

And we kept hearing versions of this from people working entirely different corners of the problem. Abigail Cabunoc Mayes, talking about mentorship at FOSDEM, put it plainly: "the volume of contributions is going up, but the signal-to-noise ratio is really going down." A community can look alive by the surface metrics—commits, PRs, downloads—while the substrate of belonging is hollowing out underneath.

The months since haven't quieted any of this. Maintainers are sharing their experiences—Daniel Stenberg has been chronicling what the AI era looks like from inside curl, and Franck Nijhof recently described Home Assistant's version of it: contributions arriving faster than anyone can review them, because "contributors are being amplified, but maintainers are still the verification bottleneck." Projects across the ecosystem are rethinking their contribution policies in response. The particulars differ; the shape is the same.

And here's the uncomfortable realization underneath all of it: we were relying on a friction we didn't even know we needed. The playbook for building and sustaining open-source communities—accumulated over decades by a lot of people who took the question seriously—assumed newcomers would keep becoming visible on their own. Nobody wrote that assumption down, because nobody had to. Now that it's failing, the playbook has to change.

This is a design problem, not a crisis

The instinct, when something erodes, is to mourn it or try to restore it. The more useful response is to ask: what has to be built intentionally that used to happen as a byproduct?

Everything we were learning—from the program on one track, from our interviews and our peers on the other—kept converging on the same few answers.

The communities that come through this in shape will be the ones oriented around relationships and narrative—not tooling, not clever onboarding flows, not any one platform. The technology stack underneath a community is replaceable. What isn't replaceable is whether the people in it are in real relationship with each other and with the project, and whether the project has a story about itself that someone can find their way into. That sounds soft. It is the hard part.

A piece of that is what Allen and Wagner call proof of effort. When the cost of producing surface-level engagement falls—an issue that reads as plausible, a PR that compiles, a comment that sounds informed—the signal that someone is actually here, actually paying attention, actually committed, has to come from somewhere else. Getting prospective contributors to demonstrate investment becomes more important, not less. Not as a gatekeeping move. As a way of making real participation visible again. Communities that ask people to do something on the project's terms—show up to a call, take a small responsibility, write the doc nobody wants to write—are not being precious. They are reconstructing the legibility the old friction used to provide.

The other shift—one we heard named, in almost the same words, by different people in different rooms—is from extractive to contributive: communities oriented around what someone can give to the project, not just what they can get from it. That's not a new idea either. What's new is that the default has flipped. If you don't say anything, the default relationship a person now has with your project is consumption with an AI in the middle. The contributive frame has to be made explicit because the extractive one is no longer being challenged by the structure of how people find you.

The structural argument follows directly from this. If the passive onramps are narrowing—and the evidence is now plural enough that this is no longer a hunch—then the active ones have to be designed. If the outer ring of the community is becoming invisible, you have to go looking for the people in it; they will not show up on your dashboard. If initiation no longer happens by accident, the project has to create the conditions for it on purpose. None of this is a return to a previous state. It's a different posture toward maintenance: looking, naming, inviting, and following up are now first-order work, not extracurricular.

Which lands the section, and the post, in one specific place.

Invitation. Invitation has to come from someone already inside the community—someone with standing, someone whose attention means something—saying out loud to a particular person: we see you, and there's a place for you here. That isn't new advice. The communities of practice literature has been making this argument, in one form or another, for thirty years. What's new is that it used to be advice. Now it's structural. The friction that used to put newcomers in front of us is thinner. The work of putting them in front of us, on purpose, is the work.

What you might not be seeing—and what's next

So: what signals are you still relying on that may no longer be reaching you? What onramps did you assume would always be there? Whose first contact with your project this year went through a layer you can't see into—and what would it take to find out?

In subsequent posts, I want to talk about the tools I-Corps handed us for actually looking at these questions honestly. A canvas, a map, a journey—they aren't the answer, but they can help you take a realistic look at your ecosystem and figure out where the gaps are.

Sources

Allen, D., & Wagner, A. V. (2026). The AI Shockwave in Open Source Communities: How AI Is Reshaping the Foundations of Open Source Communities. FOSDEM 2026, Brussels. https://fosdem.org/2026/schedule/event/KXPSTQ-the_ai_shockwave_in_open_source_communities_how_ai_is_reshaping_the_foundations_/
Cabunoc Mayes, A. (2026). The Synthetic Senior: Rethinking Free Software Mentorship in the AI Era. FOSDEM 2026, Brussels. https://fosdem.org/2026/schedule/event/AJGB73-the_synthetic_senior_rethinking_free_software_mentorship_in_the_ai_era/
del Rio-Chanona, R. M., Laurentsyeva, N., & Wachs, J. (2024). Large language models reduce public knowledge sharing on online Q&A platforms. PNAS Nexus, 3(9): pgae400. https://doi.org/10.1093/pnasnexus/pgae400
Lagache, E. (1993). "Diving" into Communities of Practice: Examining Learning as Legitimate Peripheral Participation in an Everyday Setting. Paper presented at the American Educational Research Association annual meeting, Atlanta, GA. ERIC ED 360 387. https://eric.ed.gov/?id=ED360387
Lave, J., & Wenger, E. (1991). Situated Learning: Legitimate Peripheral Participation. Cambridge University Press.
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
Vogl, C. H. (2025). The Art of Community: 7 Principles for Belonging (2nd ed.). Berrett-Koehler.

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

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.

GSoC 2026 Selected Projects

Athan — Sat, 09 May 2026 03:21:40 +0000

We're excited to share that Google Summer of Code 2026 is officially underway and that stdlib has been awarded five contributor slots for this year's program.

This is our third year participating in GSoC, and every year the program has gotten bigger, more competitive, and more energizing for the project.

What continues to stand out most is not just the number of proposals we receive, but the level of engagement contributors bring before applications even open. Increasingly, contributors are showing up months in advance: opening pull requests, participating in discussions, helping with reviews, fixing bugs, improving documentation, and steadily becoming part of the community long before proposal season begins.

And that matters.

Open source is not built over the course of a single summer. It is built through consistency, trust, curiosity, and sustained collaboration over time. GSoC works best when it amplifies an existing trajectory rather than starting from zero.

This year's application season was the most competitive we've seen so far.

From January 1 through April 21 of this year, prospective GSoC contributors were busy ramping up on stdlib's development practices, refining their proposals, and contributing across the project. During that time, the stdlib community:

open more than 2,000 PRs, with 1,452 of those being successfully merged.
added 2,209 commits and 146 new packages.
welcomed contributions from 89 different contributors.

During the official proposal period alone (February 19 – April 21), contributors opened 1,250 pull requests and authored 1,421 commits across the project.

In total, we received 75 proposals for just 5 slots.

That level of participation says a lot about the momentum behind scientific computing on the web and about the community that continues to grow around stdlib.

The 2026 Cohort

This year's accepted projects span numerical computing, machine learning, visualization, and low-level linear algebra infrastructure, all areas which are foundational to stdlib's long-term vision for scientific computing on the web.

Over the next several months, contributors will be working closely with mentors across the project, participating in design discussions, iterating on implementations, writing documentation, and helping shape the future direction of stdlib.

One thing we emphasize heavily within stdlib is that open source is not just about writing code. Good engineering requires communication, design thinking, documentation, review discipline, testing rigor, and an ability to collaborate effectively with others. GSoC gives contributors exposure to all of those dimensions.

With that, on to the projects!

BLAS Bindings and Implementations for Linear Algebra

Contributor: Kaustubh Patange

This project focuses on expanding stdlib's BLAS support by adding missing Level 2 and 3 BLAS routines. The work continues stdlib's broader effort to bring high-performance numerical computing primitives to the JavaScript ecosystem while maintaining API consistency and portability across runtimes.

More broadly, the project will strengthen one of the most important foundational layers for scientific computing: fast and reliable linear algebra operations.

Batch Machine Learning Algorithms in JavaScript and C

Contributor: Nakul Krishnakumar

This project aims to introduce a new set of foundational machine learning algorithms to stdlib, implemented in both JavaScript and C. The focus is on building reusable low-level primitives which can serve as the basis for a broader machine learning ecosystem within stdlib over time.

Machine learning infrastructure on the web is still relatively immature compared to other ecosystems. One of stdlib's goals is to help close that gap by providing robust, modular, and composable numerical tooling that works across Node.js, browsers, edge runtimes, and beyond.

Singular Value Decomposition (SVD) via LAPACK

Contributor: Prajjwal Bajpai

This project will add LAPACK bindings and JavaScript implementations for singular value decomposition (SVD), centered around LAPACK's dgesvd routine.

SVD is one of the most important algorithms in numerical linear algebra and underpins a wide range of applications, including dimensionality reduction, least-squares optimization, signal processing, recommendation systems, and machine learning.

Adding robust SVD support will significantly expand stdlib's growing linear algebra capabilities and move the project closer toward providing a comprehensive numerical computing stack for the web.

Linear System Solvers and Factorization Workflows

Contributor: Pratik Bhagwat

This project focuses on enabling factorization-to-solution workflows within stdlib by integrating matrix factorizations and linear system solvers into a more cohesive numerical linear algebra pipeline.

In practice, scientific computing is rarely about isolated kernels. Real-world workflows often involve composing lower-level primitives into larger computational pipelines. This project will help bridge that gap by improving interoperability between routines and strengthening stdlib's higher-level numerical computing ergonomics.

Plotting Infrastructure and Chart Creation

Contributor: Sachin Pangal

This project will extend stdlib's plotting infrastructure by implementing missing components needed for end-to-end chart generation using Vega.

Visualization is a critical part of scientific computing workflows, yet the JavaScript ecosystem still lacks cohesive, low-level scientific visualization tooling designed around composability and modularity. This work will help move stdlib toward a more complete data analysis and visualization stack capable of supporting exploratory analysis, diagnostics, dashboards, and educational tooling directly in the browser and in server-side runtimes such as Node.js.

More Than a Summer Program

One of the most rewarding aspects of GSoC has been seeing contributors continue participating well after the program ends.

Several former GSoC contributors are still active members of the stdlib community today, continuing to review code, mentor newer contributors, and help drive development across the project. That long-term continuity is enormously valuable and is ultimately what makes programs such as GSoC successful.

For stdlib specifically, GSoC has also helped accelerate an important broader goal: building a sustainable ecosystem for scientific computing in JavaScript and bringing more contributors into that ecosystem.

The web platform has become one of the most important computing environments in the world. Scientific computing tools should exist there as first-class citizens.

That means performant numerical primitives. It means robust infrastructure. It means approachable tooling. It means strong documentation. And it means building a healthy contributor community capable of sustaining all of that over the long term.

Programs like GSoC help make that possible.

Thank You

A huge thank you to everyone who submitted a proposal this year.

We know how much time and effort goes into preparing applications, contributing beforehand, engaging with mentors, and refining project ideas. The selection process was very difficult this year, and there were many strong proposals we simply did not have enough slots to support.

We also want to thank all of the mentors and community members who continue investing time into reviewing pull requests, answering questions, helping contributors onboard, and supporting the project day to day. Open source communities only work because people choose to show up for one another.

We're excited to get started and are looking forward to seeing what this year's contributors build.

Zen of stdlib

Athan — Sat, 09 May 2026 00:42:41 +0000

A philosophy of simplicity, modularity, consistency, and craft.

Over the past several years, stdlib has grown from a small collection of utilities into a large, highly modular system for scientific computing in JavaScript and on the web. Along the way, we've made thousands of small decisions about APIs, naming, performance, package boundaries, and implementation strategies.

Individually, those decisions may seem minor. Collectively, they define the character of the project.

As the project has grown, it's become increasingly important to make those underlying principles explicit not just for maintainers, but for contributors and users who want to understand how and why stdlib is the way it is.

Today, we're introducing the Zen of stdlib: a set of guiding principles that capture the philosophy behind the project.

Why a "Zen"?

This is not a style guide.

It's not a checklist.

And it's not meant to be followed dogmatically.

Instead, the Zen is a distillation of experience: what has worked, what hasn't, and what tends to scale as a codebase and community grow. It exists to guide decisions, especially in ambiguous situations where there is no obviously "correct" answer.

If you've ever asked questions like:

Should this be a new package or part of an existing one?
Is this API too general?
Should we add another option or compose existing functionality?
Is this abstraction worth it?

The Zen is meant to help answer those questions.

The Zen of stdlib

Do one thing. Do it well.
Embrace radical modularity.
Favor composition over configuration.
Stability is a feature.

Make it obvious and predictable.
Don't be clever.

Complexity kills.
Push complexity up the stack.

If it's hard to explain, it's a bad idea.
If it's hard to test, it's a bad design.

Failure should be easy to diagnose.

Value consistency above all else.
Except when correctness, safety, or clarity demands otherwise.

Write it like C.
Be explicit. Avoid polymorphism by default.

Automate where it scales; stop where it obscures.

Code is read more than it is written.
Be kind to your future self.

Code is craft.
Tend to the garden.

Mistakes are infectious.
Fix them early.

Simple is beautiful.

What this means in practice

A few themes show up repeatedly throughout stdlib.

Radical modularity

If something can stand on its own, it should.

stdlib is intentionally composed of many small packages rather than a few large ones. This enables reuse, makes testing easier, and allows consumers to include only what they need. It also forces discipline, as each package must have a clear purpose and boundary.

Composition over configuration

We prefer simple building blocks over highly configurable interfaces.

Instead of adding more flags, options, and modes, we aim to provide small primitives that can be composed. This keeps individual APIs predictable and avoids combinatorial complexity.

Pushing complexity up the stack

Lower-level APIs should be simple, predictable, and easy to reason about.

More complex behavior, such as branching logic, multiple modes of operation, and orchestration, belongs in higher-level utilities built on top of those primitives. This separation is critical for both performance and maintainability.

Predictability and consistency

Users should not have to guess what an API does.

Naming conventions, argument ordering, and error behavior should be consistent across the entire project. Consistency reduces cognitive load and makes the system easier to learn and use.

Performance by design

"Write it like C" is less about language and more about mindset.

We favor predictable performance characteristics, monomorphic code paths, and explicit behavior. Hidden allocations, excessive polymorphism, and implicit work tend to introduce both performance and debugging challenges.

Maintainability as a first-class concern

Code is read far more often than it is written.

That reality drives many of the principles in the Zen: clarity over cleverness, simplicity over abstraction, and documentation that explains not just what the code does, but why.

A living document

The Zen of stdlib is not fixed.

As the project evolves, so will our understanding of what works and what doesn't. The Zen may change over time, but changes should be rare, deliberate, and grounded in experience.

For contributors

If you're contributing to stdlib, the Zen is a useful reference point when designing APIs or reviewing code.

It won't answer every question, but it should help you reason about trade-offs and make decisions that align with the broader direction of the project.

When in doubt: prefer simplicity, clarity, and consistency.

Closing

stdlib is an ongoing experiment in what scientific computing in JavaScript and on the web looks like when built around strong principles.

The Zen is an attempt to capture those principles so that the project can continue to grow without losing what makes it coherent.

As always, feedback is welcome.

Connect with the stdlib community on Zulip

Athan — Wed, 17 Dec 2025 05:45:04 +0000

As the stdlib community continues to grow and evolve, so has our need for new ways to connect and collaborate (see, for example, our announcement of office hours and a public events calendar). While Gitter's simple, single-channel interface worked well in the early days, it no longer scales with the range of conversations happening around the project. Today we're excited to announce our new Zulip chat, which provides a more full-featured, structured, and searchable space for us to interact.

Why Zulip?

Zulip is open source and generously supports open-source projects like ours with a free cloud plan. Its channel-and-topic model makes it easier to keep discussions focused, follow ongoing threads, and resurface past knowledge through powerful search features.

Anyone can browse the web-public channels of stdlib's Zulip without an account, and you can sign up at any time to join the conversation.

Join and get started

The stdlib Zulip chat is open to all. A welcome bot will greet you when you first join and share some tips specific to stdlib about how to participate effectively. If you're new to Zulip, their getting started guide is an invaluable resource. If you're already familiar with applications such as Slack or Discord, much of the experience will be familiar.

We encourage you to come say hello in the #introductions channel and take some time to explore other channels and topics that may be of interest to you. If you have any questions about Zulip itself, we've got a channel for that too (#zulip).

The stdlib team is active in the chat, and public messages are the best way to get timely help—no need for routine @-mentions. Asking questions in public is the fastest way to get a response, as more people can help, plus it's likely that someone else will benefit from finding out the answer to your question. The stdlib Code of Conduct applies to all community spaces, including stdlib's Zulip. Should you encounter an issue, Zulip's reporting tools and our moderation team are available.

See you there!

We're looking forward to seeing you in the stdlib Zulip instance! We welcome questions and suggestions as we continue shaping a space that is useful, inclusive, and genuinely supportive for everyone who wants to learn, build, or contribute.

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

Using AI in the development of stdlib

Philipp Burckhardt — Thu, 17 Jul 2025 19:18:41 +0000

Feeling fast, but working slow? A reflection on stdlib's participation in the recent METR study on AI's impact on open-source developer productivity.

I read the results of the recent METR study on "Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" with great interest for two reasons. Firstly, I have been an early adopter of LLM tools. In 2020, I was lucky enough to get access to the private beta of the OpenAI API from then CTO Greg Brockman and explored the use of AI for education at Carnegie Mellon University. Secondly, because stdlib participated in the METR study, I was personally involved and contributed by working on randomized issues over several months, being allowed to use AI for some tasks and forbidden for others.

Given that stdlib's involvement is central to my perspective, it's worth providing some context on the project. stdlib is a comprehensive open-source standard library for JavaScript and Node.js, with a specific and ambitious goal: to be the fundamental library for numerical and scientific computing on the web. It is a large-scale project with well over 5 million source lines of JavaScript, C, Fortran, and WebAssembly, and composed of thousands of independently consumable packages, bringing the rigor of high-performance mathematics, statistics, and machine learning to the JavaScript ecosystem. Think of it as a foundational layer for data-intensive applications similar to the roles NumPy and SciPy serve in the Python ecosystem. In short, stdlib isn't your average JavaScript project.

A Word of Thanks

Before diving into my reflection, I want to take the opportunity to thank the METR team and especially Nate Rush for giving stdlib the chance to participate in this study with two core stdlib developers, Muhammad Haris and myself. It was a great experience to work with the METR team, and I am eager to see any future studies they will conduct. It is my conviction that, with the entire tech industry being gripped by an AI gold rush, it is incredibly valuable to have a non-profit research institute like METR conduct studies that cut through the noise with actual data.

The Slowdown

The results of the METR study are surprising, clashing with some previously published and very optimistic study results on the impact of generative AI (e.g., see GitHub and Accenture's 2023 study on the impact of Copilot on developer productivity). Citing from the Core Result section of the METR study page:

When developers are allowed to use AI tools, they take 19% longer to complete issues—a significant slowdown that goes against developer beliefs and expert forecasts. This gap between perception and reality is striking: developers expected AI to speed them up by 24%, and even after experiencing the slowdown, they still believed AI had sped them up by 20%.

Rather predictably, the results have led to a lot of discussion on Hacker News and other social channels, with parties on both sides lining up with their pitchforks.

The Perception Gap

I am part of the group of developers who estimated that they were sped up 20%-30% during the study's exit interview. While I like to believe that my productivity didn't suffer while using AI for my tasks, it's not unlikely that it might not have helped me as much as I anticipated or maybe even hampered my efforts.

But how can that be? Daily, we are reading about how AI is already revolutionizing the workplace or making software engineers redundant, with companies like Salesforce announcing that they won't be hiring for software engineering positions anymore or online lender Klarna announcing that they were shuttering their entire human customer support in favor of AI.

Many of these stories have turned out to be more hyperbole than reality. Klarna still has human support, and Salesforce still has many engineering job listings. Sadly, some of these stories appear influenced by ulterior motives, such as Klarna's strategic positioning as an "AI-native" company to capture premium valuations ahead of its IPO amid the current AI wave.

However, I have been using AI tools daily for the past three years, both at work and outside, and find them immensely useful. How do I square these benefits with the study results?

On Study Design

When confronted with results that go counter to one's expectations, it is a natural instinct to try to attack the study and identify holes to explain away the result. For example, one could point to the small sample size of 16 developers. There is also the argument that the study was conducted in a very specific context, with experienced developers working on projects they are intimately familiar with.

There might also have been a subtle selection effect in the tasks themselves: since project maintainers proposed their own task lists, it is possible that those more experienced with AI subconsciously selected issues they believed were more amenable to an agentic workflow. One could also argue that the developers were subject to the Hawthorne effect, altering their behavior simply because they knew they were being video-recorded, perhaps over-relying on the AI tools for the sake of the experiment.

Finally, and perhaps most importantly, the experimental setup of requiring screen recordings and active time tracking for a single task enforced a synchronous workflow. This effectively locked developers into what I call "supervision mode", where they had to watch the agent work rather than being free to context-switch to another problem.

Some of these critiques, particularly the enforced "supervision" workflow, could directly contribute to the observed slowdown. But others, such as selecting "AI-friendly" tasks or over-relying on the tool to impress researchers, should have biased the results toward a speedup. This makes the final outcome even more notable. The direction of various potential biases is ambiguous at best, which is why we must look at the study's core design.

As a randomized control trial, the study follows the gold standard experimental design for detecting causality. By randomizing individual tasks to "AI-allowed" or "AI-disallowed", the study isolates the effect of AI tooling. Instead of comparing one group of developers against a control group (where differences in skill could skew the results), it compares each developer against themselves. This "within-subjects" design controls for individual characteristics, from typing speed to experience with the project. With such a study design, results are harder to write off as mere statistical noise, even with a smaller sample size.

Crucially, the tasks were defined before this randomization. This avoids a common pitfall where AI might simply produce more verbose code or encourage developers to break tasks into smaller pull requests, which can inflate some productivity metrics without representing more work getting done.

16 developers from several open-source projects might not sound like much, but, in total, we completed 246 tasks. To give a sense of the work involved, the tasks Haris and I worked on were not trivial, while still being hand scoped to be completed in a few hours or less. They were a mix of core feature development (such as adding new array, string, and BLAS functions), creating custom ESLint rules to enforce project-specific coding standards, enhancing our CI/CD pipelines with new automation, and fixing bugs from our issue tracker.

And while a single developer's performance on one task is likely correlated with their performance on another and the precision of the estimates thus larger than otherwise, it is quite notable that the effect was in the opposite direction from what economists, ML experts, and the developers themselves predicted (with the former two groups being more in the range of a 40% speedup). Moreover, the effect is quite large in magnitude. A quick back-of-the-envelope calculation reveals that if the true effect were a 40% speedup, the probability of observing a result this far in the opposite direction is astronomically low.

In light of this, I have no reason to doubt the internal validity of the study and would venture that the effect measured is real within the context of the experiment. If one believed the chatter on social media and the hype merchants who two years ago were all shilling cryptocurrency (and maybe still are!) but have meanwhile all switched over to extolling the amazing speedup AI offers, then increases of 100%, 5x, or even 10x should have been in the cards. But this is definitively not what the study observed.

Embracing Agentic Development

The more important consideration for squaring my own experience with these results is external validity: how generalizable are the study's findings? The paper is a great read and touches on many possible criticisms and threats to external validity, and I won't belabor any of the points raised therein.

Instead, I will solely focus on my experience as a study participant and how I have been leveraging AI with success. I will also share my own hypotheses for why the performance of the developers in this sample was overall negatively affected by the use of AI.

To give some context, my main way of incorporating LLMs into my work before participating in this study was twofold. As something of an early adopter, I had used GitHub Copilot for auto-completion and inline suggestions and made heavy use of ChatGPT and Anthropic Claude web apps by assembling relevant context, writing detailed prompts, and copying results back into my editor. Tools such as Repomix helped streamline the process of incorporating LLMs into my daily development workflow. This general approach allowed me to review changes quickly, iterate on them by asking questions, and have the LLM make follow-up edits directly in a chat interface.

The METR study subsequently provided an excuse for me to delve into agentic programming and make Cursor an integral part of my workflow. I had used it briefly some time before but didn't find the AI-generated results compelling enough to let it loose on any codebase I was working on. But Claude Sonnet 3.7 had come out, which is still one of the most powerful models for coding tasks. Due to some very encouraging results during early testing, I was eager to put it to work on a backlog of tooling that we wanted to build for stdlib, alongside various refactoring and bug fixes.

One of my first impressions with Cursor this time around was the underlying LLM's rather impressive ability to follow the very specific coding standards and conventions of the project and, when placed in agent mode, to automatically and reliably fix lint errors and attempt to iteratively resolve errors in unit tests. This felt like another step change in capabilities, just like when OpenAI released GPT-3 Davinci in June 2020, which made a lot of use cases suddenly feasible that before would break down in any realistic scenario.

While I no longer use Cursor and have meanwhile switched to Claude Code (more on that later), I found Cursor straightforward to use, especially given that it is a fork of VSCode, which has been my IDE of choice for many years. I heavily doubt that inexperience with Cursor, which I shared with roughly a half of the developers in the study, played a major role in the results. While I didn't have an extensive .cursorrules setup (which has since been deprecated in favor of project rules), I did add basic instructions and context about the project and made sure to index the stdlib codebase. Aside from that, further customization was neither possible nor necessary, as the Cursor Agent was able to automatically pull in other files, look up function call signatures, and perform other operations for assembling context.

My experience of Cursor was largely positive during the study. As an example, I ended up working on several Bash scripts for our CI/CD pipeline, and Cursor definitely sped up my development workflow by not having to look up the man page of jq for the eleventh time given that I only use this command-line tool for manipulating JSON once in a blue moon. With the AI agent's help, I could quickly generate a function like this one to check if a GitHub issue has a specific label:

# Check if an issue has the "Tracking Issue" label.
#
# $1 - Issue number
is_tracking_issue() {
    local issue_number="$1"
    local response

    debug_log "Checking if issue #${issue_number} is a tracking issue"
    # Get the issue:
    if ! response=$(github_api "GET" "/repos/${repo_owner}/${repo_name}/issues/${issue_number}"); then
        echo "Warning: Failed to fetch issue #${issue_number}" >&2
        return 1
    fi

    # ...

    # Check if the issue has the "Tracking Issue" label:
    if echo "$response" | jq -r '.labels[].name' 2>/dev/null | grep -q "Tracking Issue"; then
        debug_log "Issue #${issue_number} is a tracking issue"
        return 0
    else
        debug_log "Issue #${issue_number} is not a tracking issue"
        return 1
    fi
}

The agent correctly assembled the jq -r '.labels[].name' filter to extract the label names from the JSON response—something that would have sent me to a documentation page for a few minutes. While a small speed bump, these moments add up. The AI handled the rote task of recalling obscure syntax, letting me focus on the actual logic.

My first takeaway is this: current LLMs are very powerful for tasks in domains that you are not intimately familiar with, allowing you to move much more quickly. Agentic tools such as Cursor and Claude Code are also very helpful to quickly navigate and learn your way around a large codebase, allowing you to ask questions and explore the codebase in a natural way. Leveraging "deep research" provides another means to more exhaustively explore a problem space in a way that the search engines of old simply cannot match.

On the other hand, some tasks were very frustrating. For example, the Cursor agent wrote one ESLint rule almost fully in one shot, but for another one, the Cursor agent was running in circles and unable to figure out the correct algorithm. Trying to prompt it to fix the bug was unsuccessful multiple times. It would have been better to not fall prey to the sunk cost fallacy and instead throw away the code and then either give the agent another shot or write it myself.

Cursor does have a neat feature of breakpoints which allow you to stop the agent at any time and revert to a prior state, something I wholeheartedly recommend using. It is a great way to avoid getting stuck in a loop of the agent trying to fix a bug that it cannot figure out.

I freely admit that I may have been a bit overeager about using AI for all of the AI-enabled tasks, partly due to my desire to learn to use Cursor productively but also due to my general amazement of what these new technologies unlock. However, maybe the METR study suggests that the question of whether a task can be more efficiently completed by AI, or whether one would be better off completing it by hand, is far from settled.

The Blank Slate Problem

Aside from occasional inefficiencies and outright mistakes in the generated code, coding agents do not have access to all the implicit knowledge and conventions of a large, mature project, which often might not be written down. In his reflections on the study, John Whiles identifies a core conflict: an expert engineer's primary value isn't just writing code; it's holding a complete, evolving mental model of the entire system in their head. The agent does not have such a mental model. Every interaction starts from a blank slate.

It is possible that some of this can be mitigated with better, more targeted instructions. As usual, there is no free lunch. One has to actively invest in making one's codebase more accessible to coding agents. And more generally, memory and learning is an unsolved problem with transformer-based LLMs, and changing that will likely require fundamental architectural advancements.

The necessity of auditing the agent's code for mistakes created two major sources of friction: the cognitive drain of 'babysitting' the AI and the time spent waiting for and reviewing its output. For every minute the agent spent running in circles on that ESLint rule, I was blocked, my attention monopolized by the need to supervise its flawed process. This synchronous, blocking workflow is exhausting and inefficient. It's the digital equivalent of shoulder-surfing an overconfident junior developer who has memorized everything there is to know about programming but cannot be trusted and who will make subtle mistakes that are hard to spot.

My advice: stay in the driver's seat during such pair programming and use the AI as a sparring partner to bounce ideas back and forth instead of yielding agency.

Delegate, Don't Supervise

Partly based on my experiences in the study, my workflow has evolved, and I have subsequently switched to using Anthropic's Claude Code. This has changed my interaction model from synchronous supervision to asynchronous delegation. I can now define a complex task via Claude Code's planning mode and then have the agent work on the task in the background. I can then turn my full attention elsewhere, be it attending a meeting, reviewing a colleague's code, or simply thinking through the next problem without interruption. Claude's work happens in parallel and is not a blocker to my own. The cognitive cost of babysitting is replaced by the much lower cost of reviewing a completed proposal later; if it didn't work out, I might just throw away the code and have the model try again, instead of engaging in a fruitless back and forth.

Claude Sonnet 4 and Opus 4 were not released at the time the METR study was conducted, and, while they mark another improvement, especially with regard to tool use by the model, the dynamics haven't fundamentally changed. The models still make mistakes and do not always implement things in an optimal or sound way, but they are now much better at following instructions and can work uninterrupted for longer periods of time.

At least for me, in contrast to those who frame coding agents as mere "stochastic parrots", I find myself absolutely amazed that, despite its warts and hiccups, we have now a technology that, given a set of instructions, is able to generate a fully-formed pull request that correctly implements logic, adheres to style guidelines, and has a passing test suite. And, in the best cases, this can happen without any human intervention.

The First 80 Percent

We still need to reconcile the observed performance decrease with how many developers, including myself, have now been leveraging AI to get tasks done in a fraction of the time, tasks that would have taken them hours or days previously. I believe that the Pareto Principle is a helpful yardstick. Named after Italian economist Vilfredo Pareto, it is commonly referred to as the 80/20 rule and posits that roughly 80% of effects come from 20% of the causes. Coding agents can now generate working code that mostly works but that might fall short if the goal is 100%.

In many instances, coding agents can easily accomplish the first 80% of a programming task, generating boilerplate, scaffolding logic, implementing core functionality, and writing a test suite. However, the final 20% of the task, from handling tricky edge cases, adhering to unwritten architectural conventions, ensuring optimal performance, and avoiding code duplication by reusing existing utilities is where the complexity lies. This last mile still requires the developer's deep, stateful mental model of the project. The rub here is that, by using the AI agent, one may bypass all the little steps which are necessary in the process of building that mental model.

But does it matter? When working on a crucial piece of a larger, complex system, it definitely does, and I would be hesitant with generative AI. But when working on a well-defined, isolated piece of code with expected behavior for inputs and outputs, why bother? The marginal cost of writing code (long recognized as only a small part of software engineering) is going to zero. In the event that there is a problem with the code, it can simply be thrown away and rewritten. The code that AI agents now generate is of decent quality, well-documented, and capable of adhering to one's coding conventions.

This brings to mind the following quote by Kent Beck.

The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x. I need to recalibrate.

AI as a force multiplier is why I am long on AI, even though the METR study is a good reminder that we all can easily fall prey to cognitive biases.

In Thinking, Fast and Slow, Daniel Kahneman gives a classic example for biases driven by the availability heuristic: people overestimate plane crash risks due to vivid media coverage, making such events more "available" to memory than statistically riskier, yet routine, car crashes. Our judgment is swayed not by data, but by the ease of recall. In the case of working with AI agents, observing them build fully-functioning tools in seconds is a very memorable and visceral experience. On the other hand, the slow, frustrating "death by a thousand cuts" experience of auditing, debugging, and correcting the AI's subtle mistakes is the equivalent of the mundane car crash. It's a distributed cost with no single dramatic moment.

Nevertheless, I have no reason to believe that this technology will not continue to improve, and I, for one, am excited about the possibilities. For any big and ambitious project, the amount of tickets to be completed, features to be implemented, and bugs to fix vastly outstrips the available amount of time and human bandwidth to work on them.

What Future Studies Should Tell Us

It remains to be seen whether the results of the METR study can be replicated. However, the study clearly demonstrated that experts and developers were overly optimistic about the impact of AI on productivity. This is an important insight that should inform future research.

In some ways, the study raises more new questions than it answers. It looked at a very particular situation: seasoned experts working in the familiar territory of their own large, mature projects. Future studies by METR and others could vary these conditions. What happens when we throw developers into unfamiliar codebases, where, at least per my anecdotal experience, AI agents shine? Or what about junior developers or new contributors to an established open-source codebase? Under what conditions can AI act as a great equalizer, compressing the skill gap and providing a speed boost rather than slowdown?

Furthermore, the current study centered on completion time, but faster isn't always better. One possible follow-up would be a blinded study where human experts review pull requests without knowing if AI was involved. We could then measure things like the number of review cycles, the time spent in review, and the long-term maintainability of the code. This might shed light on when and how AI-assisted development may impact trading short-term speed for long-term technical debt.

Finally, the field of AI is still evolving at a rapid pace. The synchronous workflow that the study's setup encouraged could be fundamentally suboptimal. Exploring different interaction models, such as the asynchronous delegation workflow that I've moved to, could yield very different results.

How to Work With AI Now

What follows are my current recommendations for using AI in your daily workflow based on my experiences and the METR study.

Adopt an Asynchronous Workflow

The biggest drain from using AI is the cognitive load of "babysitting" it. Instead of watching the agent work, adopt an asynchronous model:

Define one or more tasks (e.g., running a set of commands to audit a codebase for lint errors and documentation mistakes) and then let AI agents work on them in the background (e.g., in separate Git worktrees of your repository), and turn your attention elsewhere.
Review the completed task(s) later. If the output is flawed, it's often better to discard it and have the model try again with a better prompt rather than engaging in a frustrating back-and-forth.

Know What to Delegate

AI can now handle the first 80% of many programming tasks, but the final 20% often requires deep context. The key is to choose the right tasks for AI:

"Vibe Code" and Prototypes: use AI for mock-ups or small, isolated tools that can be thrown away. This is where the technology's speed offers a distinct advantage.
Verifiable Code: AI is excellent for tasks that can be fully verified against an existing, robust test suite. The tests act as a safety net to catch the subtle mistakes the AI might make.
Boilerplate Code: AI can quickly generate boilerplate code, such as REST API endpoints or form validation, and can do so in a way that follows project conventions.
Learning and Navigation: use AI to quickly learn your way around a large codebase, document previously undocumented code, or to get help with tools you use infrequently. Asking LLMs questions can be much faster than hunting through documentation, particularly if that documentation is split across multiple resources.

Use and Customize Claude Code

For tools such as Claude Code, customization is a helpful means of writing down any implicit knowledge about the project that is not readily accessible from the code alone.

Provide Proper Context: drag and drop relevant files (this can include images!) into the Claude Code window for the model to use as context for the task at hand. One approach I have found useful is to add TODO comments in the codebase with the required changes, and then have Claude Code work on them. Use the planning mode to have the model think through the task and generate a plan that can be approved before immediately jumping into implementation.
Use Project Memory: use CLAUDE.md files to give the model project-specific memory, specifically on its architecture and unwritten knowledge. You can have multiple CLAUDE.md files in different project sub-directories, and the model will intelligently pick up the most relevant one based on your current context.

Automate Repetitive Actions: create custom slash commands for frequent tasks performing routine work. Below is an example stdlib:review-changed-packages command that I run to flag any possible errors in PRs that were recently merged to our development branch:

- Pull down the latest changes from the develop branch of the stdlib repository.
- Get all commits from the past $ARGUMENTS day(s) that were merged to the develop branch
- Extract a list of @stdlib packages touched by those commits
- Review the packages for any typos, bugs, violations of the stdlib style guidelines, or inconsistencies introduced by the changes.
- Fix any issues found during the review.

Build Custom Tooling: use the Claude CLI to build small, automated tools, such as a review bot that flags typos as a daily CRON job. For fuzzy tasks such as pointing out typos or inconsistencies in a PR, it's best to let Claude generate output that can be verified by a human. For well-defined tasks that can be fully automated, it is better to have Claude produce code that deterministically runs and can be verified.
Set up Hooks to Automate Actions: hooks are a powerful new feature of Claude Code that allows you to run scripts and commands at different points in Claude's agentic lifecycle.

Final Thoughts

It's natural to attack a study whose results you don't like. A better response is to ask what they might be telling you. For me, it tells me there is still a lot to learn about how to use this new, powerful, but often deeply weird and unpredictable technology. One mistake is treating it as the driver in a pair programming session that requires your constant attention. Instead, treat it like a batch process for grunt work, freeing you to focus on the problems that actually require a human brain.

GSoC 2025 Projects Announced

Philipp Burckhardt — Fri, 09 May 2025 02:30:04 +0000

Today, we are grateful to announce that stdlib, the fundamental numerical library for JavaScript, was awarded five slots in this year's Google's Summer of Code (GSoC). We participated in the program last year for the first time, and had four talented students working on a variety of projects. It was a resounding success, which we hope to surpass this year given all that we have learned over the past year and a half.

This achievement comes after a tremendously productive start to 2025. Since January 1st of this year, the stdlib community has:

Opened two thousand PRs with 1,377 successfully merged.
Welcomed contributions from 88 different contributors.
Added 3,452 commits to the repository.

For GSoC, we received 99 excellent applications from enthusiastic students. Ranking proposals was a tough decision, and we would have loved for a few more projects to be accepted. We are grateful to everyone who applied and encourage those not selected this year to stay connected, continue to contribute to the project, and to apply again next year! In fact, one of this year's accepted contributors was a repeat applicant, demonstrating how persistence and continued engagement can pay off.

The accepted projects are listed below. Each project addresses key areas that will expand JavaScript's potential for technical and scientific applications.

Add LAPACK bindings and implementations for linear algebra
Contributor: Aayush Khanna

The goal of Aayush's project is to develop JavaScript and C implementations of LAPACK (Linear Algebra Package) routines. This project aims to extend conventional LAPACK APIs by borrowing ideas from BLIS, thus ensuring easy compatibility with stdlib ndarrays and adding support for both row-major (C-style) and column-major (Fortran-style) storage layouts. This work will help overcome the LAPACK's column-major limitation and thus make advanced linear algebra operations more accessible and efficient in JavaScript environments.

Expanding array-based statistical computation in stdlib
Contributor: Gururaj Gurram

Gururaj will advance statistical operations in stdlib by introducing convenience array wrappers for all existing strided APIs, thus improving developer ergonomics for common use cases. Additionally, he will develop specialized ndarray statistical kernels with the aim of facilitating efficient statistical reductions across multi-dimensional data.

Implement base special mathematical functions in JavaScript and C
Contributor: Karan Anand

Karan will implement and enhance lower-level scalar kernels for special mathematical functions in stdlib. The goal is to complete missing C implementations for existing double-precision packages, develop new single-precision versions, and ensure consistency, accuracy, and IEEE 754 compliance. These enhancements will provide developers with the most comprehensive set of high-precision mathematical tools for scientific computing in JavaScript.

Achieve ndarray API parity with built-in JavaScript arrays
Contributor: Muhammad Haris

Haris will extend stdlib's ndarray capabilities by implementing familiar JavaScript array methods like concat, find, flat, includes, indexOf, reduce, and sort for multi-dimensional arrays. The project will develop high-performance C implementations with Node.js native add-ons for compute-intensive operations. These enhancements will allow JavaScript developers to work with multi-dimensional arrays as easily as built-in arrays, significantly expanding JavaScript's capabilities for scientific and numerical computing.

Add BLAS bindings and implementations for linear algebra
Contributor: Shabareesh Shetty

Shabareesh will expand stdlib's BLAS (Basic Linear Algebra Subprograms) support by implementing missing Level 2 (vector-matrix) and Level 3 (matrix-matrix) operations in JavaScript, C, Fortran, and WebAssembly. The project will focus on key dependencies for LAPACK routines and create performance-optimized APIs that work in both browser and server environments. These enhancements will provide essential building blocks for developing high-performance machine learning and statistical analysis applications on the web.

We're excited to see these projects develop over the coming months. Each contribution will significantly enhance stdlib's capabilities and make advanced mathematical and statistical operations more accessible to the JavaScript community. The work done by these talented contributors will help bridge the gap between traditional scientific computing environments and JavaScript, furthering our mission to create a comprehensive, high-performance standard library for JavaScript.

We'd like to extend thanks to Google for their continued support of open-source development through the Summer of Code program, and we look forward to sharing updates as the above projects progress over the course of this summer. In addition to watching for more posts on this blog, you can follow development by joining our community chat. We also hold regular office hours over video conferencing, which is a great opportunity to ask questions, share ideas, and engage directly with the stdlib team.

We hope that you'll join us in our mission to advance cutting-edge scientific computation in JavaScript. Start by showing your support and starring the project on GitHub today: https://github.com/stdlib-js/stdlib.

Google Summer of Code 2025

Athan — Thu, 27 Feb 2025 18:22:14 +0000

We're thrilled to announce that stdlib was accepted as a Google Summer of Code mentoring organization for 2025!

We are beyond excited to share that stdlib has once again been accepted as a mentoring organization for Google Summer of Code 2025! This marks our second consecutive year participating in this incredible program, and we cannot wait to work alongside aspiring open source contributors to push the boundaries of scientific computing on the web.

Google Summer of Code (GSoC) is a global initiative that introduces new contributors to open source software by offering mentorship and funding for meaningful, long-term projects. Over the years, GSoC has been instrumental in helping open source projects like stdlib grow, while also giving participants valuable real-world software development experience. With our acceptance into GSoC 2025, we are looking forward to welcoming a new wave of enthusiastic contributors who share our vision of making JavaScript and the extended ecosystem of TypeScript, Node.js, Deno, and other JavaScript runtimes first-class environments for numerical and scientific computing.

Reflecting on GSoC 2024: A Year of Growth

Last year marked our first time participating in GSoC, and we could not have asked for a better experience. We had the privilege of mentoring four incredibly talented contributors, each of whom made substantial contributions to the stdlib ecosystem.

From integrating BLAS bindings and optimizing special mathematical functions to enhancing support for boolean arrays and improving our interactive REPL experience, their work strengthened the foundation of stdlib and paved the way for even greater advancements. Beyond just code, their contributions sparked deeper engagement within our community, leading to over 2,000 pull requests from more than 100 contributors and 3,000+ new commits to stdlib since February 2024.

If you missed our retrospective on last year's program, be sure to check out our blog post: Reflecting on GSoC 2024.

What's in Store for GSoC 2025?

As we gear up for GSoC 2025, we have a range of exciting project ideas that we hope will inspire potential contributors. Whether you're passionate about numerical computing, statistical modeling, performance optimization, or developer tooling, there's something for you. Some areas we're particularly excited about include:

BLAS/LAPACK: continuing to expand stdlib's coverage of BLAS and LAPACK operations to provide a robust foundation for linear algebra and machine learning in JavaScript and Node.js.
WebAssembly: compiling BLAS and statistical kernels to WebAssembly with support for ergonomic inter-operation between WebAssembly and JavaScript.
ndarray kernels: implementing lower-level ndarray kernels for efficient element-wise iteration and reduction to improve performance.
Improving developer tooling: improving the stdlib development experience by creating better tools for automation, publishing, and managing the stdlib package ecosystem.
Expanding statistical distributions: building on previous efforts to provide C implementations for special mathematical functions, thus unlocking a wider range of probability distributions and making stdlib a comparable alternative to SciPy for statistical computing in JavaScript.

These ideas, however, are just the beginning. We believe that innovation comes from collaboration, and we welcome fresh ideas from prospective contributors. If you have a project concept that aligns with our mission and a clear plan for execution, we would love to hear about it. Our current list of ideas is available on our GSoC repository, but don't feel constrained by it—great ideas come from all directions!

How to Get Involved

If you're interested in contributing to stdlib for GSoC 2025, now is the perfect time to get started. Here's how you can begin your journey:

Explore stdlib: familiarize yourself with the project by browsing the project's GitHub repository and reading our documentation.
Join the conversation: engage with the stdlib community on Element to discuss project ideas, ask questions, and connect with mentors.
Review our guidelines: carefully read our GSoC Application Guidelines to understand what we're looking for in a proposal.
Start contributing: we strongly encourage all applicants to contribute to stdlib before submitting their application. This can be in the form of a bug fix, new feature, performance improvement, or some other enhancement to stdlib's capabilities.

The official GSoC timeline is as follows:

February 27 – March 24: prospective contributors discuss project ideas with mentoring organizations.
March 24 – April 8: application period (final deadline: April 8 at 18:00 UTC).
May 8: accepted proposals announced.
May 8 – June 1: community bonding period.
June 2 – September 1: standard 12-week coding period.

For the full timeline, visit the GSoC 2025 Timeline.

Looking Ahead

As we embark on another exciting GSoC season, we want to extend our deepest gratitude to Google for this opportunity. We are incredibly excited to meet new contributors, explore new ideas, and continue building an open source ecosystem where JavaScript thrives as a language for scientific computing.

If you're passionate about building high-quality software and eager to make an impact, we invite you to join us. We can't wait to see your ideas and begin working together to advance scientific computing in JavaScript. Let's make this year's GSoC program one to remember!

New ways to engage with the stdlib community!

Athan — Tue, 14 Jan 2025 00:47:48 +0000

Fostering a vibrant and inclusive community is crucial for ensuring the long-term success of open-source software, and stdlib is no exception. We believe that collaboration and open communication are key to driving innovation and making scientific computing on the web accessible to everyone. To that end, we're thrilled to announce two new initiatives designed to make it easier than ever for contributors, users, and maintainers to connect, collaborate, and grow together!

Weekly Office Hours

As part of our efforts to enhance transparency and collaboration, we're proud to announce weekly office hours! We've been running these informally for the past few months, and they've been a wonderful success, providing high-bandwidth opportunities to connect with project maintainers, users, and new and existing stdlib contributors.

To facilitate the coordination of office hours and other public project meetings, we've created a public GitHub repository to serve as a centralized hub where community members can propose agenda topics, review discussion points, and participate in shaping the direction of stdlib. Each week in advance of the next office hours, we'll create a new dedicated agenda issue, where you can link issues and pull requests you want to discuss, post questions in advance, and share any pre-reads. Thus far, agendas have run the gamut, from project overviews to live code reviews to discussions about the project roadmap to upcoming events and community announcements.

In short, if you have questions about stdlib or if you need help fixing a bug, figuring out what to do next, or are just looking for feedback, this is your time to shine! Please join our weekly office hours to connect with project maintainers, stay updated on the latest project news, and chat with other community members. This is a great opportunity to ask questions, share ideas, and engage directly with the stdlib team.

Everyone is welcome—drop in and say hello!

Public Community Calendar

Second, we're excited to introduce our new public community calendar, where you can stay up-to-date with all stdlib events, including office hours, project orientations, development meetings, and other important happenings.

With this calendar, you can:

Find the dates and times of upcoming office hours and meetings.
Add our events to your own calendar for easy reminders.
Stay informed about new opportunities to engage with the stdlib team and community.

How You Can Get Involved

Here are a few ways you can make the most of these new resources:

Bookmark the community calendar or add it to your own. Be on the lookout for upcoming events, and mark your calendar to join us.
Engage on GitHub. Visit our meetings repository to propose agenda topics or contribute to ongoing discussions.
Attend Office Hours. Whether you're stuck on a problem or curious about the latest project updates, office hours are an excellent opportunity to connect and learn.
Spread the Word. Help us grow the stdlib community by sharing these updates with anyone who might be interested.

Let's Build Together!

We're committed to creating a supportive and inspiring environment for everyone in the scientific computing ecosystem, and we're excited to see how these new initiatives will help our community thrive. Needless to say, we can't wait to connect with you at our next office hours!

Together, we're building the future of scientific computing on the web! 🚀

2024 Retrospective

Athan — Sat, 04 Jan 2025 21:16:29 +0000

A look back at 2024 and a preview of the year ahead.

2024 was a landmark year for stdlib, packed with progress, innovation, and community growth. Looking back, I am struck by the amount of time and effort members of the stdlib community spent refining existing APIs, crafting new functionality, and laying the groundwork for an exciting road ahead. I feel incredibly fortunate to be part of a community that is actively shaping the future of scientific computing on the web, and I am bullish on our continued success in the months to come.

In this post, I'll provide a recap of some key highlights and foreshadow what's in store for 2025. While I'll be making various shoutouts to individual contributors, none of what we accomplished this year could have happened without the entire stdlib community. The community was instrumental in doing the hard work necessary to make stdlib a success, from finding and patching bugs to reviewing pull requests and triaging issues to diving deep into the weeds of numerical algorithms and software design. If I don't mention you by name, please be sure to know that your efforts are recognized and greatly appreciated. A big thank you to everyone involved and to everyone who's helped out along the way, in ways both big and small. ❤️

TL;DR

This past year was transformative for stdlib, marked by significant growth, innovation, and community contributions. Some key highlights include:

Community Growth: 84 new contributors joined stdlib, tripling the size of our developer community and driving over 4,000 commits, 2,200 pull requests, and the release of 500+ new packages.
Google Summer of Code: four exceptional contributors helped advance critical projects, including enhanced REPL capabilities, expanded BLAS support, and new mathematical APIs.
Enhanced Developer Tools: major strides in automation included automated changelog generation, improved CI workflows, and better test coverage tracking.
Technical Milestones: significant progress was made in linear algebra (BLAS and LAPACK), fancy indexing, WebAssembly integrations, and C implementations of mathematical functions, all aimed at making JavaScript a first-class language for scientific computing.
Future Vision: looking ahead to 2025, we aim to expand our math libraries, improve REPL interactivity, explore WebGPU, and continue building tools to make scientific computing on the web more powerful and accessible.

With stdlib’s rapid growth and the collective efforts of our global community, we're shaping the future of scientific computing on the web. Join us as we take the next steps in this exciting journey!

Stats

To kick things off, some high-level year-end statistics. This year,

84 new contributors from across the world joined stdlib, tripling our developer community size and bringing new life and fresh perspectives to the project.
Together, we made over 4000 commits to the main development branch.
We opened nearly 2200 pull requests, with over 1600 of those pull requests merged.
And we shipped over 500 new packages in the project, ranging from new linear algebra routines to specialized math functions to foundational infrastructure for multi-dimensional arrays to APIs supporting WebAssembly and other accelerated environments.

These accomplishments reflect the hard work and dedication of our community. It was a busy year, and we were forced to think critically about how we can effectively scale the project and our community as both continue to grow. This meant investing in tooling and automation, improving our review and release processes, and figuring out ways to quickly identify and upskill new contributors.

Google Summer of Code

The one event which really set things in motion for stdlib in 2024 was our acceptance into Google Summer of Code (GSoC). We had previously applied in 2023, but were rejected. So when we applied in 2024, we didn't think we had much of a chance. Much to our surprise and delight, stdlib was accepted, thus setting off a mad dash to get our affairs together so that we could handle the influx of contributors to come.

GSoC ended up being a transformative experience for stdlib, bringing in talented contributors and pushing forward critical projects. As we detailed in our GSoC reflection, the road was bumpy, but we learned a lot and came out the other side. Needless to say, we were extremely lucky to have four truly excellent GSoC contributors: Aman Bhansali, Gunj Joshi, Jaysukh Makvana, and Snehil Shah. I'll have a bit more to say about their work in the sections below.

REPL

The Node.js read-eval-print loop (REPL) is often something of an afterthought in the JavaScript world, both underutilized and underappreciated. From stdlib's earliest days, we wanted to create a better REPL experience, with integrated support for stdlib's scientific computing and data processing functionality. Development of the stdlib REPL has come in fits and starts, but there's always been a goal of matching the power and feature set of Python's IPython in order to facilitate interactive exploratory data analysis in JavaScript. We were thus quite excited when Snehil Shah expressed interest in working on the stdlib REPL as part of GSoC.

Snehil already covered some of his work in a previous blog post on "Welcoming colors to the REPL!", but his and others' work covered so much more. A few highlights:

Preview completions: when typing characters matching a known symbol in the REPL, a completion preview is now displayed, helping facilitate auto-completion and saving developers precious keystrokes. Shoutout to Tudor Pagu, in particular, for adding this!
Multi-line editing: prior to adding support for multi-line editing, the REPL supported multi-line inputs, but did not support editing previously entered lines, often leading to a frustrating user experience. Now, the REPL supports multi-line editing within the terminal similar to dedicated editor applications.
Pagination of long outputs: a longstanding feature request has been to add support for something like less/more to the stdlib REPL. Previously, if a command generated a long output, a user could be confronted with a wall of text. This has now been addressed, with the hope of adding more advanced less-like search functionality in the months ahead.
Bracketed-paste: pasting multi-line input into the REPL used to execute the input line-by-line, instead of pasting it as a single prompt. While useful in some cases, this is often not the desired intent, especially when a user wishes to paste and edit multi-line input before execution.
Custom syntax-highlighting themes: developers who are used to developing in IDEs can often feel adrift when moving to a terminal lacking some of the niceties of their favorite editor. One of those niceties is syntax-highlighting. Accordingly, we worked to add support for custom theming, as detailed in Snehil's blog post.
Auto-pairing: another common IDE nicety is the automatic closing of brackets and quotation marks, helping save keystrokes and mitigate the dreaded missing bracket. Never one to shy away from a difficult task, Snehil implemented support for auto-pairing as one of his first pull requests leading up to GSoC.

Largely thanks to Snehil's work, we moved much closer to IPython parity in 2024, thus transforming the JavaScript experience for scientific computing. And we're not done yet. We still have pull requests working their way through the queue, and one thing I am particularly excited about is that we've recently started exploring adding support for the Jupyter protocol. Stay tuned for additional REPL news in 2025!

BLAS

Another area of focus has been the continued development of stdlib's BLAS (Basic Linear Algebra Subprograms) support, which provides fundamental APIs for common linear algebra operations, such as vector addition, scalar multiplication, dot products, linear combinations, and matrix multiplication. Coming into 2024, BLAS support in stdlib was rather incomplete, particularly in terms of its support for complex-valued floating-point data types. The tide began to change with Jaysukh Makvana's efforts to achieve feature parity of stdlib's Complex64Array and Complex128Array data structures with built-in JavaScript typed arrays.

These efforts subsequently paved the way for adding Level 1 BLAS support for complex-valued typed array data types and the work of Aman Bhansali, who set out to further Level 2 and Level 3 BLAS support in stdlib. After focusing initially on lower-level BLAS strided array interfaces, Aman expanded his scope by adding WebAssembly implementations and by adding support for applying BLAS operations to stacks of matrices and vectors via higher-level multi-dimensional array (a.k.a., ndarray) APIs.

In addition to conventional BLAS routines, stdlib includes BLAS-like routines which are not a part of reference BLAS. These routines include APIs for alternative scalar and cumulative summation algorithms, sorting strided arrays, filling and manipulating strided array elements, explicit handling of NaN values, and other operations which don't fall neatly under the banner of linear algebra, but are common when working with data.

During Aman's BLAS work, we cleaned up and refactored BLAS implementations, and Muhammad Haris volunteered to extend those efforts to our extended BLAS routines. His efforts entailed migrating Node.js native add-ons to pure C in order to reduce boilerplate and leverage our extensive collection of C macros for authoring of native add-ons and further entailed adding dedicated C APIs to facilitate interfacing with stdlib's ndarrays.

These developments ensure that stdlib continues to lead the way in linear algebra support for JavaScript developers, offering powerful tools for numerical computing. While much has been completed, more work remains, and BLAS will continue to be a focal point in 2025.

LAPACK

Building on the BLAS work as part of an internship at Quansight Labs, Pranav Goswami worked to lay the foundations for LAPACK (Linear Algebra Package) support in stdlib in order to provide higher order linear algebra routines for solving systems of linear equations, eigenvalue problems, matrix factorization, and singular value decomposition. Detailed more fully in his post-internship blog post, Pranav sought to establish an approach for testing and documentation of added implementations and to leverage the ideas of BLIS to create LAPACK interfaces which facilitated interfacing with stdlib's ndarrays and thus minimize data movement and storage requirements. While a good chunk of time was spent working out the kinks and iterating on API design, Pranav made significant headway in adding various implementation utilities and nearly 30 commonly used LAPACK routines. Given the enormity of LAPACK (~1700 routines), this work will continue into the foreseeable future, so be on the lookout for more updates in the months ahead!

As a quick aside, if you're interested in learning more about how stdlib approaches interfacing with Fortran libraries, many of which still form the bedrock of modern numerical computing, be sure to check out Pranav's blog post on calling Fortran routines from JavaScript using Node.js.

C implementations of special math functions

One of stdlib's longstanding priorities is continued development of its vectorized routines for common mathematical and statistical operations. While all scalar mathematical kernels (e.g., transcendental functions, such as sin, cos, erf, gamma, etc, and statistical distribution density functions) have JavaScript implementations, many of the kernels lacked corresponding C implementations, which are needed for unlocking faster performance in Node.js and other server-side JavaScript runtimes supporting native bindings.

Gunj Joshi and others sought to fill this gap and opened over 160 pull requests adding dedicated C implementations. At this point, only a few of the most heavily used double-precision transcendental functions remain (looking at you betainc!). Efforts have now turned to completing single-precision support and adding C implementations for statistical distribution functions. We expect this work to continue for the first half of 2025 before turning our attention to higher-level strided array and ndarray APIs, with implementations for both WebAssembly and Node.js native add-ons.

Fancy indexing

Another area where we made significant progress is in improving slicing and array manipulation ergonomics. Users of numerical programming languages, such as MATLAB and Julia, and dedicated numerical computing libraries, such as NumPy, have long enjoyed the benefit of concise syntax for expressing operations affecting only a subset of array elements. For example, the following snippet demonstrates setting every other element in an array to zero with NumPy.

import numpy as np

# Create an array of ones:
x = np.ones(10)

# Set every other element to zero:
x[::2] = 0.0

As a language, JavaScript does not provide such convenient syntax, forcing users to either use more verbose object methods or manual for loops. We thus sought to address this gap by leveraging Proxy objects to support "fancy indexing". While the use of Proxy objects does incur some performance overhead due to property indirection, you now need only install and import a single package to get all the benefits of Python-style slicing in JavaScript, thus obviating the need for verbose for loops and making array manipulation significantly more ergonomic.

import array2fancy from '@stdlib/array-to-fancy';

// Create a plain array:
const x = [ 1, 2, 3, 4, 5, 6, 7, 8 ];

// Turn the plain array into a "fancy" array:
const y = array2fancy( x );

// Select the first three elements:
const v = y[ ':3' ];
// returns [ 1, 2, 3 ]

// Select every other element, starting from the second element:
v = y[ '1::2' ];
// returns [ 2, 4, 6, 8 ]

// Select every other element, in reverse order, starting with the last element:
v = y[ '::-2' ];
// returns [ 8, 6, 4, 2 ]

// Set all elements to the same value:
y[ ':' ] = 9;

// Create a shallow copy by selecting all elements:
v = y[ ':' ];
// returns [ 9, 9, 9, 9, 9, 9, 9, 9 ]

In addition to slice semantics, Jaysukh added support to stdlib for boolean arrays, thus laying the groundwork for boolean array masking.

import BooleanArray from '@stdlib/array-bool';
import array2fancy from '@stdlib/array-to-fancy';

// Create a plain array:
const x = [ 1, 2, 3, 4, 5, 6, 7, 8 ];

// Turn the plain array into a "fancy" array:
const y = array2fancy( x );

// Create a shorthand alias for creating an array "index" object:
const idx = array2fancy.idx;

// Create a boolean mask array:
const mask = new BooleanArray( [ true, false, false, true, true, true, false, false ] );

// Retrieve elements according to the mask:
const z = x[ idx( mask ) ];
// returns [ 1, 4, 5, 6 ]

We subsequently applied our learnings when adding support for boolean array masking to add support for integer array indexing.

import Int32Array from '@stdlib/array-int32';
import array2fancy from '@stdlib/array-to-fancy';

// Create a plain array:
const x = [ 1, 2, 3, 4, 5, 6, 7, 8 ];

// Turn the plain array into a "fancy" array:
const y = array2fancy( x );

// Create a shorthand alias for creating an array "index" object:
const idx = array2fancy.idx;

// Create an integer array:
const indices = new Int32Array( [ 0, 3, 4, 5 ] );

// Retrieve selected elements:
const z = x[ idx( indices ) ];
// returns [ 1, 4, 5, 6 ]

While the above demonstrates fancy indexing with built-in JavaScript array objects, we've recently extended the concept of fancy indexing to stdlib ndarrays, a topic we'll have more to say about in a future blog post.

Needless to say, we are particularly excited about these developments because we believe they will significantly improve the user experience of interactive computing and exploratory data analysis in JavaScript.

Test and build

Lastly, 2024 was a year of automation, and I would be remiss if I didn't mention the efforts of Philipp Burckhardt. Philipp was instrumental in improving our CI build and test infrastructure and improving the overall scalability of the project. His work was prolific, but there are a few key highlights I want to bring to the fore.

Automatic changelog generation: Philipp shepherded the project toward using conventional commits, which is a standardized way for adding human and machine readable meaning to commit messages, and subsequently built a robust set of tools for performing automatic releases, generating comprehensive changelogs, and coordinating the publishing of stdlib's ever-growing ecosystem of over 4000 standalone packages. What was once a manual release process can now be done by running a single GitHub workflow.
stdlib bot: Philipp created a GitHub pull request bot for automating pull request review tasks, posting helpful messages, and improving the overall maintainer development experience. In the months ahead, we're particularly keen to extend the bot's functionality to help with new contributor onboarding and flagging common contribution issues.
Test coverage automation: with a project of stdlib's size, running the entire test suite on each commit and for each pull request is simply not possible. It can thus be challenging to stitch together individual package test coverage reports in order to obtain a global view of overall test coverage. Philipp worked to address this problem by creating an automation pipeline for uploading individual test coverage reports to a dedicated repository, with support for tracking coverage metrics over time and creating expected test coverage changes for each submitted pull request. Needless to say, this has drastically improved our visibility into test coverage metrics and helped improve our confidence in tests accompanying submitted pull requests.

While we've made considerable strides in our project automation tooling, we never seem to be short of ideas for further automation and tooling improvements. Expect more to come in 2025! 🤖

Look ahead

So what's in store for 2025?! Glad you asked!

We've already alluded to various initiatives in the sections above, but, at a high level, here's where we're planning to focus our efforts in the year ahead:

GSoC 2025: assuming Google runs its annual Google Summer of Code program and we're fortunate enough to be accepted again, we'd love to continue supporting the next generation of open source contributors.
Math and stats C implementations: expanding our library of scalar math and statistics kernels and ensuring double- and single-precision parity.
BLAS: completing our WebAssembly distribution and higher-level APIs for operating on stacks of matrices and vectors.
LAPACK: continuing to chip away at the ~1700 LAPACK routines (!).
FFTs: adding initial Fast Fourier Transform (FFT) support to stdlib to help unlock algorithms for signal processing.
Vectorized operations: automating package creation for vectorized operations over scalar math and statistics kernels.
ndarray API parity: expanding the usability and familiarity of ndarrays by achieving API parity with built-in JavaScript arrays and typed arrays.
REPL: adding Jupyter-protocol support and various user-ergonomics improvements.
WebGPU: while we haven't formally committed to any specific approach, we're keen on at least exploring support for WebGPU, an emerging web standard that enables webpages to use a device's graphics processing unit (GPU) efficiently, including for general-purpose GPU computation, in order to provide APIs for accelerated scientific computing on the web.
Project funding: exploring and hopefully securing project funding to accelerate development efforts and support the continued growth of the stdlib community.

That's definitely a lot, and it's going to take a village—a community of people dedicated to our mission of making the web a first-class platform for numerical and scientific computing. If you're ready to join us in building the future of scientific computing on the web, we'd love for you to join us. Check out our contributing guide to see how you can get involved.

A personal note

As we look ahead, I'd like to share a personal reflection on what this year has meant to me. Given our growth this year, I often felt like I was drinking from a fire hose. And, honestly, it can be hard not to get burned out when you wake up day-after-day to over 100 new notifications and messages from folks wanting guidance, answers to questions, and pull requests reviewed. But, when reflecting on this past year, I am awfully proud of what we've accomplished, and I am especially heartened when I see contributors new to open source grow and flourish, sometimes using the lessons they've learned contributing as a springboard to dream jobs and opportunities. Having the fortune to see that is a driving motivation and a privilege within the greater world of open source that I do my best to not take for granted.

And with that, this concludes the 2024 retrospective. Looking back on all we've achieved together, the future of scientific computing on the web has never been brighter! Thank you again to everyone involved who's helped out along the way. The road ahead is filled with exciting opportunities, and we can't wait to see what we will achieve together in 2025. Onward and upward! 🚀