DEV Community: Athan

Why another plotting library?

Athan — Sat, 08 Aug 2026 22:44:43 +0000

JavaScript has no shortage of plotting libraries. But scientific computing needs more than a way to render charts, so we're building a plotting system designed around the entire workflow.

JavaScript does not suffer from a shortage of ways to draw a chart. There are mature libraries for quick statistical graphics, dashboards, bespoke data-driven documents, publication-quality figures, and nearly every use case in between. Some are small and focused. Others are entire ecosystems in their own right.

So, naturally, stdlib is building another one.

At first glance, this may look like a textbook case of not-invented-here. It is not. We are not building a plotting library because we think the existing libraries are bad. Quite the opposite: JavaScript has some of the best visualization tooling of any programming ecosystem. We are building one because stdlib is trying to solve a different problem.

The gap we care about is not at the level of pixels. Current JavaScript charting libraries can draw lines, symbols, axes, legends, and tooltips just fine. The gap is at the level of workflow: how plotting fits into numerical computation across the browser, the REPL, the command line, on the server, and in desktop windows.

That is the problem we have not seen addressed as one coherent system.

TL;DR

We are not building another rendering engine.

We are building a plotting layer for scientific JavaScript: one which understands n-dimensional arrays (a.k.a., ndarrays), works naturally in the Node.js REPL, can render to an Electron-powered desktop window, participates in command-line workflows, can be embedded in a browser, exposes a programmatic event model, and provides a path from exploratory analysis to publication-quality graphics.

For rendering and interaction, we are building on Vega, a declarative visualization grammar and runtime which produces canvas and SVG output in the browser, and supports static rendering on the server. Vega gives us a robust target specification and rendering backend. stdlib provides the scientific data model, ergonomic plotting APIs, runtime integrations, object model, viewers, editing tools, documentation, testing, and long-term compatibility layer around it.

Put another way: Vega handles the pixels. We are building the workflow.

Start where the computation happens

Most JavaScript visualization libraries treat the browser as the center of the universe. That makes sense. JavaScript was born in the browser, and the browser provides a rich environment for interaction, layout, animation, and graphical output. For many applications, targeting a DOM element on a web page is the right abstraction.

But stdlib does not live only in the browser.

It also lives in Node.js scripts, REPL sessions, command-line programs, batch jobs, data pipelines, web services, and other server-side environments. If plotting is going to be a first-class part of scientific computing in JavaScript, it needs to feel at home in all of those places.

When I am exploring a dataset, I do not want to create a browser application just to see whether two variables are correlated. I do not want to scaffold a project, write HTML, start a development server, move my data across an application boundary, and attach a chart to a DOM node. I want to start the stdlib REPL, load my data, create a plot, and keep working.

That should not be a radical request.

The plotting work currently underway in stdlib deliberately separates a chart from how that chart is viewed. The same chart can target stdout, a browser, or an Electron-powered desktop window. A browser remains a first-class destination, but it is not assumed to be the only destination.

This matters for exploratory data analysis. Plotting is not merely a final presentation step. It is part of the feedback loop through which we inspect data, question assumptions, identify structure, discover errors, and decide what to compute next. A plotting library for scientific computing should begin where the computation happens, not require users to move the computation somewhere else.

Numerical data is not always a JSON table

A great deal of JavaScript visualization is organized around arrays of objects (often referred to as "tidy datasets"; e.g., see Vega and Observable Plot):

[
    { 'x': 1.0, 'y': 3.2 },
    { 'x': 2.0, 'y': 4.8 },
    { 'x': 3.0, 'y': 4.1 }
]

That is a perfectly reasonable interchange format centered on JSON. It is readable, flexible, and maps naturally to rows and fields. It is not, however, necessarily the data model used by a numerical program.

Scientific code routinely works with typed arrays, multi-dimensional arrays, strided views, non-contiguous memory layouts, stacks of matrices, and arrays with explicit shape and data type information. Those objects are not incidental implementation details. They are fundamental abstractions around which numerical software is built.

In stdlib, we want users to be able to provide the same ndarray objects they use for statistics, linear algebra, simulation, and signal processing directly to plotting APIs. Users should not need to manually flatten, reshape, transpose, copy, or serialize their data just to look at it.

Our work-in-progress line-chart implementation already accepts ndarray-like inputs, determines how to organize those inputs as chart data, and lowers the result into Vega datasets, scales, axes, and marks.

const uniform = require( '@stdlib/random/uniform' );
const Float64Vector = require( '@stdlib/ndarray/vector/float64' );
const LineChart = require( './../lib' );

// Define minimum lower and upper bounds for uniformly distributed random numbers:
const a = new Float64Vector( [ 10, 20, 30, 40, 50 ] );
const b = new Float64Vector( [ 20, 30, 40, 50, 60 ] );

// Generate 5 datasets containing 100 rows of data:
const y = uniform( [ 100, 5 ], a, b );

// Create a new chart instance:
const chart = new LineChart( y );

This is not the sort of feature which produces a flashy landing-page demo. But it is foundational.

A plotting library within stdlib should understand the data structures produced by the rest of stdlib. Anything less would make plotting feel like an attached application rather than an integrated part of the numerical computing environment.

A plot should be a live computational object

A plot is often treated as a terminal artifact: provide some data and options, create an SVG or canvas element, and move on. That model is useful, but incomplete.

Plots change. Data arrives. Parameters are updated. Axes are rescaled. Themes are switched. A server may need to notify a connected client. A host application may need to export an image after a computation finishes. A stream may need to trigger an update without any DOM event occurring.

Vega signals provide an excellent reactive model within the visualization runtime. Signal values can respond to input events, external API calls, and upstream changes, with updated values propagating through the visualization dataflow. But signals inside a visualization runtime are not a replacement for a general-purpose event model across a JavaScript object graph.

In our current work, stdlib plotting objects use event emitters throughout the programmatic API. Changes to child objects propagate upward, allowing a chart, server, viewer, logger, or another consumer to respond. A change can result in a visual update, but it could just as readily result in writing a file, emitting a message over a socket, recording an audit log, or initiating some other non-DOM action. This is particularly important on the server, where there may be no user-interface element to bind and no mouse or keyboard event to observe.

It is also why we are investing in debug logging throughout the plotting stack. Once a visualization becomes reactive, understanding what changed, where that change originated, and why a render occurred becomes essential. Plotting should not be a black box which mysteriously redraws itself. Failure should be easy to diagnose.

In other words, we are treating a plot as a live computational object, not just a picture.

Code and GUI should meet in the middle

There is a longstanding tension in scientific plotting between code and graphical editing. Code is reproducible. It can be reviewed, versioned, rerun, tested, and applied consistently across many figures. A graphical interface, however, can be much more efficient for the final stages of figure creation: adjusting padding, changing font sizes, refining tick marks, moving a legend, modifying line styles, and making the dozens of small visual decisions which turn a serviceable plot into a publication-quality graphic.

Most tools force users to choose. Either every visual detail must be expressed in code, even when direct manipulation would be faster, or a figure is edited in a graphical application and the relationship between the resulting artifact and the code which produced it is severed.

We want both.

The current in-progress plotting work contains an early graphical editor which reads from a visualization schema, exposes controls for chart properties, and posts changes back to a server-side plot. The underlying schema remains the source of truth. Programmatic changes can update the editor, and editor changes can update the programmatic object.

This work is still early, but the direction is important. The goal is not to replace code with a GUI. It is to make the GUI another frontend to the same underlying representation.

Knowing when to stop building everything ourselves

At this point, an obvious question arises. If we are building so much custom plotting infrastructure, why build on Vega at all? Why not implement the renderer ourselves?

We tried.

stdlib has a strong bias toward building foundational infrastructure in-house. That tendency has served us well. It gives us control over API design, behavior, performance, portability, testing, documentation, and release cadence.

Our original plotting implementation followed that instinct. We built SVG components, virtual-DOM infrastructure, scales, axes, marks, layout logic, and rendering machinery. It worked. It also made increasingly clear just how much work remained.

A serious visualization renderer needs to handle scenegraphs, data joins, text measurement, clipping, layout, rendering order, incremental updates, animation, browser differences, event handling, image export, accessibility, canvas, SVG, server-side rendering, and a seemingly endless collection of edge cases. We could keep investing in all of that. But doing so would mean spending an enormous amount of time reproducing infrastructure which already exists and is maintained by people who have devoted years to solving those exact problems.

At some point, persistence becomes stubbornness. So we folded that hand.

The pull request containing the current work explicitly removes the previous virtual-DOM plotting implementation and replaces it with packages for constructing and generating Vega specifications. That does not mean the previous work was wasted. Quite the opposite. It taught us where the correct abstraction boundary should be.

We do not need to own every pixel in order to own the user experience. Rendering is not where stdlib can add the most value. Integrating plotting into scientific JavaScript is.

Why Vega?

Vega is described as a visualization grammar. Rather than directly issuing imperative drawing commands, a Vega visualization is described using a JSON specification containing data, scales, axes, legends, marks, signals, and other components. The specification is then parsed into a reactive dataflow and rendered by the Vega runtime.

That distinction makes Vega a particularly good fit for what we are building.

A portable intermediate representation

We treat a Vega specification as an intermediate representation, which is one of the stated goals of Vega: namely, to provide a "target language" in which computer programs can dynamically generate visualizations.

Conceptually, the architecture looks something like this:

 high-level chart   future plotting
    constructors       DSLs
            \       /
             \     /
        low-level builders     GUI editor
                 \               /
                  \             /
                Vega specification
                         |
                    Vega runtime
                         |
            SVG / Canvas / other renderers

A high-level line-chart constructor does not need to know how to create SVG paths, draw onto a canvas context, or generate shaders. It needs to know how to translate the user's intent and data into a valid visualization specification. Similarly, a graphical editor does not need its own rendering engine. It can modify the same specification generated by a programmatic API.

This is not an untested architectural model. Vega-Lite is itself a higher-level grammar which compiles to Vega. Lyra was an initial attempt at a graphical environment for custom visualization design without writing any code. We are applying a similar separation, but building a different frontend, one which is shaped around JavaScript numerical computing, stdlib conventions, and direct integration with stdlib data structures, such as ndarrays.

Vega specifications also give us portable artifacts which can be inspected, serialized, stored, shared, transformed, and handed to other tools. Because Vega and Vega-Lite sit underneath tools in other ecosystems, including Altair and VegaFusion in Python, the specification provides a natural bridge beyond JavaScript as well.

The schema becomes a boundary rather than a burden.

Multiple rendering environments

Vega supports canvas and SVG rendering in the browser and static SVG and PNG export on the server. Server-side SVG generation does not require constructing a server-side DOM. Vega provides multi-view layout machinery, configuration-based theming, and explicit accessibility properties for SVG output. Third-party work has additionally demonstrated a WebGL renderer for the Vega scenegraph.

Those capabilities would each represent substantial projects in their own right. By building on Vega, we inherit a rendering foundation which already spans the environments stdlib cares about. We can then spend our time on the problems which are specific to scientific computing: data adapters, chart semantics, numerical types, server integration, REPL workflows, command-line composition, and user-facing APIs.

Reactive behavior on the client

Vega's signals and reactive dataflow allow many updates to be resolved directly within the client-side runtime. Not every change should require sending an entirely new specification from a server. A line color, tick size, font weight, or opacity can often be updated without rebuilding the world.

The current in-progress stdlib view implementation already distinguishes between properties which can be updated dynamically and structural changes which require the specification to be re-parsed. This gives us a useful division of labor. stdlib can own the server-side object model and change propagation, while Vega can handle reactive visual updates close to where rendering occurs and facilitate a more responsive and snappier user experience.

An ecosystem rather than an island

Depending on a rendering backend is not a decision we take lightly. Visualization libraries are expensive dependencies. They have large surface areas, and choosing one means placing a certain amount of trust in its architecture, maintainers, and continued development. Vega has continued to evolve, remains actively maintained, and supports a broader ecosystem including Vega-Lite, Altair, VegaFusion, Vega-Embed, Vega Themes, and the Vega Editor.

That matters.

We are not tying stdlib to an isolated renderer which only we depend upon. We are aligning with a specification and runtime already shared across languages, applications, and communities.

Vega is the backend, not the user-facing API

One might reasonably ask: why not simply tell users to write Vega specifications directly? Our answer is that, while powerful, Vega is also low-level.

Creating even a conventional chart can require thinking about datasets, scales, domains, ranges, axes, marks, encoding sets, value references, signals, and layout, and then trying to encode that in JSON. That level of control is invaluable when building novel visualizations. It is unnecessary ceremony when someone simply wants to plot x against y. A scientist should not need to learn a visualization grammar before inspecting an array.

stdlib's role is to provide ergonomic plotting APIs inspired by established numerical environments such as MATLAB and matplotlib, while retaining the ability to reach for the full expressive power of Vega when needed. At the highest level, that may mean static chart constructors which make common plots easy. At a lower level, it means programmatic objects corresponding to Vega concepts such as data sources, scales, axes, marks, and encoding sets. Those objects provide validation, defaults, property accessors, change events, debug logs, and predictable serialization. And, at the bottom, the generated Vega specification remains available as an escape hatch and interoperability format.

The work-in-progress implementation already reflects this layering: high-level quantitative and line-chart objects are composed from lower-level Vega dataset, scale, axis, mark, encoding, and value objects before serializing to a standard specification.

This is not intended to be a thin wrapper which renames a few Vega properties. What we are building is a frontend and integration layer.

The value is in the continuity

To be clear, we are not claiming that every individual feature we want is unprecedented. That would be both false and unhelpful.

Vega already renders on the server. Other libraries can be made to work with Node.js. Command-line visualization tools exist. Graphical chart editors exist. Some libraries accept typed arrays or can be used inside Electron.

The individual pieces are out there. What we have not found is a coherent system which brings those pieces together around scientific computing in JavaScript.

Consider the workflow we are working toward:

Load an ndarray. Create a chart without manually reshaping the data. Open the chart in a desktop window directly from the REPL. Update a property and see the view react. Listen for changes from another server-side object. Inspect debug logs to understand why the plot updated. Fine-tune the figure in a graphical editor. Serialize the same underlying specification to stdout. Embed the same visualization in a browser application. Hand the specification to a tool in another ecosystem.

No single step is the point. The continuity is.

Building it the stdlib way

The plotting work is also being built according to the same principles which guide the rest of stdlib. Low-level components are modular and independently usable. Higher-level behavior is composed from those components. Complexity is pushed upward into APIs which can provide convenience without compromising the predictability of the foundations underneath.

Yes, this results in more packages than placing everything inside a single plot function. It also gives each concept a clear boundary. Components can be tested in isolation, documented independently, benchmarked where appropriate, reused by other packages, and replaced without rewriting the entire plotting system.

Just as importantly, stdlib owns the user-facing compatibility boundary.

Vega may evolve. Renderers may change. New specification versions may be released. By placing stdlib APIs in front of that machinery, we can absorb upstream changes, maintain consistent conventions across the rest of the project, and release plotting functionality according to the needs of stdlib users.

Depending on Vega does not mean surrendering control. It means focusing our control at the layer where we can add the most value.

Where things stand

This is not a launch announcement. The plotting work currently lives in a long-running draft pull request, and it is not ready for general use. API names may change. Package boundaries may move. Some features are incomplete, and many details remain to be worked out. But we have made significant progress.

The branch now contains a programmatic Vega object model, data conversion utilities, scales, axes, marks, encoding objects, high-level chart constructors, direct ndarray support, multiple view targets, server-side change propagation, and an early graphical editor. Enough of the architecture is now working that the direction is no longer hypothetical.

We are sharing the rationale before the software is finished because we think the motivation matters. From the outside, another plotting library can look like duplication for duplication's sake. From inside stdlib, it is an important missing piece in our effort to provide a comprehensive environment for scientific computing and data analysis in JavaScript.

We welcome initial feedback, especially from those whose workflows move between the REPL, scripts, servers, browsers, command-line tools, and publication systems. Those are precisely the boundaries we want to make disappear.

Closing

JavaScript does not need another plotting library in the abstract. stdlib does need a plotting system designed around scientific JavaScript.

A scientific computing environment is incomplete if it can perform a computation but cannot help you inspect, explore, understand, and communicate the result. Visualization is not an accessory to data analysis. It is part of the process by which analysis happens.

We are not trying to replace every existing visualization library, nor are we trying to win a chart-library arms race. We are trying to make scientific computing in JavaScript feel whole.

That means starting where the data lives. It means supporting the runtime the user is already working in. It means understanding numerical data structures. It means treating plots as live computational objects. And it means knowing when to build our own infrastructure and when to rely on excellent work already available in the broader ecosystem.

Yes, data visualization in JavaScript is a rather frothy and noisy space.

And yet, here we are.

That is why we are building another plotting library.

Athan Reines is a software engineer at Quansight and core developer of 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.

Build for Inheritance

Athan — Thu, 06 Aug 2026 10:36:37 +0000

What if the best measure of your impact in open source isn't being needed, but making yourself unnecessary?

We are often rewarded for becoming indispensable, both in our professional and our personal relationships. There is satisfaction in being the person who understands the obscure subsystem, who remembers the history behind a difficult decision, or who can step in and solve the problem that no one else can solve. Being needed can feel like evidence that our work matters, that we matter. But in open source, indispensability is often another name for fragility.

A release process that only one person understands is not really a process. It is a dependency. A project whose history lives entirely in one person's memory does not yet possess shared knowledge. And a community that can survive only through the continued sacrifice of a handful of exhausted people is not yet sustainable, no matter how many stars the repository has or how green its dashboards remain.

This is not a criticism of those people. In fact, if I'm being honest, I'm one of them. More often, it is a testament to how much they have invested and how much they have quietly carried. But it does suggest that good stewardship asks us to do something somewhat counter-intuitive: to care deeply enough about something that it eventually no longer depends on us.

We care deeply enough whenever we explain not only what we did, but why we did it.

We do it when we turn an answer we have given ten times into documentation that means no one has to ask the same question an eleventh.

We do it when we write tests that preserve knowledge of the behavior we intended, when we simplify something clever so another person can understand it, and when we record the context behind a decision rather than allowing that context to disappear into an old chat thread or someone's memory.

And perhaps most importantly, we do it when we invite another person into the work before we desperately need their help. When we give someone room to make a decision, to own a release, to lead a conversation, or even to make a mistake without immediately taking the work back from them.

These actions can be easy to dismiss as overhead. They rarely have the drama of solving the hardest technical problem or shipping the long-awaited feature. There may be no benchmark that captures their value and no release note that gives them proper credit. But they are the actions that turn individual expertise into collective capacity. They are what transform a project from something held together by heroes into something genuinely held in common.

And this is an important part of what it means for open source to be community-driven.

It does not mean that everyone must participate in every decision, or that expertise and leadership no longer matter. It means that knowledge, trust, context, and authority are distributed widely enough that the work can be carried by more than a few people and that there is a visible path for someone new to become one of those people. In open source, we are always building an inheritance.

Someone we may never meet will eventually read the documentation we wrote, encounter the interface we designed, puzzle over the test we left behind, or search through an old issue to understand why the software behaves as it does. That person may never know our name, particularly now in the age of AI. But they will encounter our judgment. They will discover whether we anticipated their confusion, whether we respected their time, and whether we left enough of a trail for them to understand the work and make it their own.

As open-source maintainers in a globally distributed world, so much of our shared life exists in code reviews, chat messages, meeting notes, and the moments when one person takes the time to bring another person into context. A shared purpose is not sustained by a mission statement alone. It is sustained by the small, repeated choices through which we make our knowledge available, make room for others to lead, and ensure that no one has to carry important work entirely alone.

As engineers, maintainers, designers, project leads, and community leaders, our value is not measured only by what we can accomplish ourselves. It is also measured by what others become able to accomplish because we were here.

Every project will eventually pass from our hands. Code will be rewritten. Interfaces will change. Roles will change. New people will arrive with ideas that we didn't anticipate.

That is not a failure of our stewardship. That is its purpose.

We should strive to build things worth inheriting and to do the quieter work that makes inheritance possible.

Because the best proof that we mattered may not be that the work still needs us. It may be that, because of how we cared for it, others can carry it farther than we ever could carry it alone.

Athan Reines is a software engineer at Quansight and core developer of 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 Browser Is the Largest Compute Platform on Earth

Athan — Mon, 20 Jul 2026 15:22:00 +0000

Modern browsers can run numerical computing, machine learning, and GPU-accelerated workloads locally. Here's why that changes everything.

Billions of browsers are already deployed. We just haven't been using them that way. Think about how most web applications work today: a user interacts with a webpage, that interaction triggers a request to a server somewhere in a data center, the server does the computation, and then the result travels back over the network to display in the browser. This architecture makes sense for many applications, but it introduces latency, requires server infrastructure, and means your data has to leave your device to get anything done.

There's another approach: modern browsers have become powerful enough to handle serious computational work right on your device. At HPSFCon 2026, I demonstrated what this looks like in practice: real-time object detection processing webcam feeds, gesture recognition identifying hand signals, and numerical computing operations on large datasets. All of it running entirely in the browser. No servers involved. No network requests. Data never leaves the device.

This represents a fundamental shift in how we think about computation on the web. For decades, the pattern has been to centralize computation on servers and treat browsers as thin clients that just display results. The early days of computing followed a similar centralization pattern with mainframes like the Z3 and ENIAC. Then came Fortran in the 1950s, which made these machines programmable for scientific work. The development of optimized libraries, such as BLAS in the 1970s and LAPACK in the 1980s, established the foundation for numerical computing that we still use today. Fast forward to now, and we're seeing browsers gain capabilities that were previously only available on servers: the ability to run compiled code efficiently, to leverage graphics hardware for computation, and to execute machine-learning models locally.

The Deployment Problem

Traditional deployment follows a simple pattern: client devices send requests over a network to servers, which compute results and send them back. As computations scale, the architecture explodes in complexity. Load balancers, caching layers, cloud storage, and dozens of other components pile on. The infrastructure becomes more sophisticated than the computation itself.

Consider calculating the absolute value of all elements in an array. The computation is trivial. But, in a client-server architecture, you route it through this entire complex infrastructure. The network round-trip time dwarfs the actual computation time by orders of magnitude.

This pattern dominates high-performance computing, as well. Supercomputers, GPU clusters, HPC facilities all centralize computation. Users submit jobs through schedulers and wait for results. It works, but centralization is a choice, not a requirement.

Distributed Computing Works, Deployment Friction Doesn't

Folding@home and SETI@home proved that volunteer computing works at scale. These projects harnessed idle capacity across millions of devices to run molecular simulations and signal analysis. The core insight holds: massive amounts of idle compute capacity sit in devices on desks and in pockets.

The problem was deployment friction. Users had to explicitly install software, configure their systems, and opt in. That barrier limited adoption to enthusiasts and prevented mainstream use.

Browsers Are Already Everywhere

Web browsers exist on billions of devices. They require no installation, no external setup, and run on virtually every computing device made in the last decade. The distributed compute platform already exists.

Browser-based computation solves real problems. When computation happens locally, data never leaves the device. For medical data, financial analysis, or any sensitive information, this is the only acceptable model. Network round-trips are eliminated, so interactive applications respond immediately instead of waiting on network calls. Each browser instance is a compute node, and the infrastructure is already deployed and maintained. Users don't need to install anything, set up environments, or deal with compatibility issues. They click a URL and the application runs.

Modern browsers can handle complex computation. The technical foundation is already built.

The Technical Foundation

So, what makes browsers capable of running complex computations? Several key technologies have matured over the past few years, transforming browsers from simple document viewers into powerful computing platforms. Let's discuss a few of them.

WebAssembly: Running High-Performance Code in the Browser

For years, JavaScript was the only language you could run in a browser. If you had existing code written in C, C++, or Rust—especially performance-critical scientific computing libraries—you couldn't use them on the web. WebAssembly changed that. It's a portable compilation target that lets you take code written in these languages and run it in the browser at speeds approaching what you'd get running natively on your machine.

The workflow is straightforward. You start with your source code in C, C++, or Rust, which gets compiled to an intermediate representation (typically LLVM IR, which is a common format many compilers use). That intermediate representation then gets converted to WebAssembly's binary format. The browser downloads this binary and executes it directly. What's particularly powerful here is that the browser handles all the platform-specific details. Whether your user is on an Intel laptop, an ARM-based smartphone, or an Apple Silicon Mac, the same WebAssembly binary works across all of them.

WebGPU: Tapping Into Graphics Hardware for Computation

GPUs (graphics processing units) are exceptionally good at certain types of computation, particularly anything that can be parallelized across many small operations. That's why they're used for graphics rendering, but it's also why they're powerful for scientific computing and machine learning. The problem has always been that GPU programming is vendor-specific. Code you write for an NVIDIA GPU won't work on an Intel GPU or an Apple GPU. Each vendor has their own APIs, their own optimization techniques, their own quirks. This makes it incredibly difficult to write portable GPU-accelerated code.

WebGPU solves this problem for the web. It provides a single, unified API that works across all GPU vendors. Your application code talks to what WebGPU calls a "logical device," which is an abstraction. The browser then maps that logical device to an adapter for whatever physical GPU the user actually has. That adapter translates your WebGPU calls into the native GPU API (e.g., DirectX, Metal, or Vulkan) and communicates with the driver for that specific hardware. As a developer, you write your code once and it runs on any GPU.

Web Workers: Using Multiple CPU Cores

Modern computers have multiple CPU cores, but JavaScript in the browser traditionally runs on a single thread. That means, even if your laptop has eight cores, your JavaScript code can only use one of them. Web Workers fix this limitation. They let you spawn independent threads that can run computation in parallel across multiple cores. Your main JavaScript thread can hand off computationally intensive work to these workers, which means heavy computation doesn't freeze the user interface. The user can still interact with your application while complex calculations happen in the background.

Web Neural Networks: Running AI Models Locally

Most AI-powered applications today work the same way: you send your data to a server, the server runs inference on a machine learning model, and the result comes back. Every query requires a network round-trip. The Web Neural Network API enables a different approach: running the model directly in the user's browser.

This works through a stack of abstractions. Your web application uses a framework such as ONNX Runtime Web, which provides a high-level interface for loading and running models. That framework talks to the WebNN API, which is the browser's standardized interface for neural-network operations. WebNN then routes those operations to whatever hardware acceleration is available on the device. On Windows, that might be DirectML. On macOS or iOS, it's Metal Performance Shaders. On devices with specialized neural processing units (NPUs), WebNN can use those directly. If no hardware acceleration is available, it falls back to running on the CPU or even to cloud-based inference.

What makes this powerful is privacy. When the model runs locally, your queries never leave your device. If you're using an AI-powered photo editor, your photos stay on your machine. If you're using a language model for text editing, your documents stay private. Chrome has built an entire infrastructure around this concept, with APIs specifically designed for common AI tasks and pre-loaded models such as Gemini Nano that applications can use without downloading anything.

Building the Software Foundation

Having powerful browser capabilities is one thing. Having the software libraries to make those capabilities accessible is another. This is where the ecosystem comes in.

Think about how scientific computing works in languages such as Python, R, or MATLAB. Researchers don't typically write their own matrix multiplication routines or Fourier transform algorithms. They use high-level functions that hide the complexity. When you call numpy.matmul() in Python to multiply two matrices, you're not executing Python code for the actual multiplication. NumPy calls down to highly optimized libraries such as BLAS (Basic Linear Algebra Subprograms) and LAPACK (Linear Algebra Package), which are written in Fortran and C and have been optimized over decades. The high-level language provides the interface, the low-level libraries provide the performance.

This layered architecture is what makes scientific computing practical. Researchers work at a high level of abstraction, but get performance from heavily optimized low-level code. For browser-based computation to be viable for real work, we need the same kind of ecosystem.

That ecosystem is emerging. TensorFlow.js pioneered deep learning on the web by bringing machine learning to the browser with APIs that felt familiar to anyone who's used TensorFlow in Python. Transformers.js builds on the success of TensorFlow.js and leverages the ONNX Runtime to let you load pre-trained language models and run inference locally. LiteRT.js brings Google's cross-platform edge AI runtime to the web, delivering high-performance model inference with WebGPU and WebNN acceleration. stdlib provides the numerical computing foundation: multidimensional arrays, linear algebra routines, statistical functions, and more.

The Python ecosystem shows how this works at scale. NumPy sits at the foundation, providing arrays and basic operations. On top of NumPy, you have SciPy for more advanced scientific computing, Matplotlib for visualization, pandas for data analysis, scikit-learn for machine learning. Then on top of those, you have domain-specific libraries for astronomy (AstroPy), biology (BioPython), image processing (scikit-image), and countless other fields. Each layer builds on the layer below.

JavaScript is following the same pattern. stdlib provides the foundational layer: the basic data structures (e.g., ndarrays for multidimensional arrays), the core numerical algorithms, and bindings to optimized libraries such as BLAS and LAPACK. Above that foundation, you can build technique-specific libraries for particular methods such as optimization or signal processing, domain-specific libraries for particular fields such as finance or biology, and application-specific tools for particular use cases. The structure is remarkably similar to Python's approach, which makes sense because both are solving the same problem: how to build a productive scientific computing environment on top of a high-level language.

Seeing It Work

All of this technology is real and shipping today. At the conference, I ran several live demonstrations to show what browser-based computation actually looks like in practice.

Object Detection with MediaPipe

The first demo used Google's MediaPipe for real-time object detection. I pointed my webcam at the audience, and the browser identified objects in the video feed in real-time. The entire machine learning model was running locally in the browser. No data was being sent to any server. The webcam feed went directly into the model, the model processed each frame, and the browser drew bounding boxes around detected objects. Zero network requests after the initial page load.

This isn't a toy demo. MediaPipe is a production-quality framework used in real applications. Running it entirely in the browser means instant feedback (no network latency) and complete privacy (your webcam feed never leaves your device).

Gesture Recognition

The second demo was gesture recognition. The browser watched my hands through the webcam and identified specific gestures: thumbs up, peace signs, open palms. Again, everything ran locally. The model loaded once when the page opened, and then all the inference happened on my machine. No API calls. No external services. Just a machine-learning model executing in the browser, processing video frames in real-time.

These demonstrations matter because they're not hypothetical. These are production-quality models running at production-quality speeds, entirely client-side. The technology works today.

Performance Benchmarks

Demonstrations are one thing, but quantitative comparisons tell a clearer story. To make the comparison tangible, I built three separate live demos, one for each implementation approach. Each demo takes the same input image and inverts its colors, running the operation 10 times to measure consistent performance. The first implementation uses traditional client-server architecture: send the image to a server, it processes the image, and then returns the result. The second runs Python with NumPy in the browser via Pyodide, which compiles the entire Python runtime to WebAssembly. The third uses stdlib for native JavaScript computation. The performance difference is immediately visible: the client-server implementation takes over 2 seconds for 10 iterations, while the browser-based approaches finish in milliseconds.

I tested each implementation across different image sizes, from small 100×100 pixel images up to larger 3200×3200 images. The pattern holds across all sizes.

The client-server approach isn't slow because the server is slow. Network round-trip time dwarfs the actual computation time. For a trivial operation, such as inverting image colors, the time spent moving data over the network completely dominates the time spent actually computing. The infrastructure overhead exceeds the computation itself by 300×.

Pyodide and stdlib both run in the browser, which eliminates network overhead entirely. But even between these two browser-based approaches, there's a significant difference. Native JavaScript (stdlib) outperforms Python-via-WebAssembly (Pyodide) by 4.6×. This makes sense: Pyodide has to run the entire Python interpreter compiled to WebAssembly, which adds overhead. Cross-compiling existing ecosystems to the browser works, and projects such as Pyodide and WebR bring valuable tools to the web. But native browser-based libraries deliver better performance by avoiding that interpreter overhead.

The chart shows another important pattern: as image dimensions increase, the performance gap between client-server and browser-based approaches widens. For small images, network overhead is a fixed cost. For larger images, you're paying both the network cost and the cost of moving more data. Browser-based computation scales better because there's no network involved.

Python and R in the Browser

Python and R now run in browsers through impressive engineering efforts. Pyodide brings Python, including NumPy and SciPy, to the browser by compiling the entire Python runtime to WebAssembly. WebR does the same for R. These projects make established ecosystems available on the web, which means researchers can use familiar tools without changing their workflow.

The tradeoff is performance. These projects compile interpreters to WebAssembly and run them in the browser, which adds overhead. The alternative is writing directly in JavaScript using libraries like stdlib that provide the same numerical primitives as NumPy or SciPy. Both approaches work. Compiled runtimes leverage decades of existing code and let people use tools they already know. Native JavaScript avoids interpreter overhead and delivers better performance for new projects.

AI Deployment Shifts to the Browser

AI model deployment changes fundamentally when you move inference to the browser. The training pipeline stays exactly the same: train on GPU clusters, supercomputers, wherever you train today. But deployment changes completely. Instead of deploying models to cloud servers where users send queries over the network, you load the model into the user's browser once. After that initial load, users query a local model, not a remote API.

This shift delivers concrete benefits. Queries never leave the device, which means complete data privacy. There's no network round-trip, which means low latency for every inference. You don't need to run massive inference servers, which means reduced infrastructure costs. Training infrastructure stays the same, but deployment becomes radically simpler and completely privacy-preserving.

Where This Goes

JavaScript has closed the gap for numerical computing. WebAssembly brings near-native performance for compiled languages. WebGPU provides hardware-agnostic GPU acceleration. Web Workers enable true parallelism across CPU cores. WebAI and the Web Neural Network API make on-device inference practical. These aren't experimental features. They're shipping in production browsers today.

The ecosystem is developing rapidly. stdlib provides the numerical computing foundation. Higher-level, domain-specific libraries will follow the same pattern we've seen in Python, building on these foundational tools to solve specific problems.

Browsers will become the default platform for privacy-sensitive applications where data cannot leave the device. They're ideal for interactive tools where latency matters and network round-trips kill the user experience. Educational platforms benefit from zero-friction deployment: students click a link and the application runs, no installation required. Edge computing scenarios where connectivity is intermittent or expensive make browser-based computation the obvious choice.

Computation is moving from servers to browsers. Not as a replacement for all server-side compute, but as the superior model for specific use cases. The infrastructure is already deployed. Billions of browsers are waiting to compute. You can explore stdlib on GitHub, join the conversation on Zulip, or watch the full HPSFCon 2026 talk for more details on browser-based scientific computing.

Gunj Joshi is a core developer of stdlib, a JavaScript library for numerical and scientific computing.

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.

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!

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! 🚀