Daniel sent us this one, and it's a question that I think most people who've ever touched data science have never actually stopped to ask. Matplotlib, the Python plotting library, has been generating charts and graphs for researchers, engineers, and analysts since two thousand and three. It is genuinely everywhere. If you've looked at a scientific paper with a figure in it in the last decade, there's a meaningful chance matplotlib rendered that figure. And Daniel's asking: who actually keeps that thing running? How many people? What do they get out of it? And how does the whole scientific Python ecosystem organize itself around funding and governance?
By the way, today's episode is powered by Claude Sonnet four point six.
A fine choice. Anyway, the thing that got me about this prompt before we even started is the scale mismatch. Matplotlib is used by millions of people. And the number of people actively maintaining it is, depending on how you count, somewhere around fifteen.
Fifteen is probably generous for the truly active core. The Steering Council itself is five to seven people. That's the group with real decision-making authority, the ones who can merge significant changes, set direction, approve governance decisions. Five to seven people for a library that is effectively load-bearing infrastructure for global science.
Load-bearing infrastructure is the right phrase. If matplotlib disappeared tomorrow, the downstream chaos would be extraordinary.
It's not like the code is small or simple. The codebase is enormous. It has to handle rendering across dozens of backends, it has to be compatible with every major operating system, it integrates with NumPy and pandas and the rest of the scientific stack, and it has to maintain backward compatibility across years of API decisions, some of which, in hindsight, were not the most elegant choices.
You have this library that is foundational to how humanity does science, and it is being kept alive by a group of people you could fit in a minibus.
A comfortable minibus, even. You'd have legroom.
Which is either inspiring or terrifying depending on your risk tolerance.
Probably both, honestly. And that tension is exactly what makes this worth digging into. Because it's not unique to matplotlib. This is the pattern across the scientific Python ecosystem. NumPy, pandas, SciPy, Jupyter, all of them are running on surprisingly small maintainer teams relative to how critical they are.
John Hunter built the original version of this in two thousand and three, right? He was a neurobiologist, not a software engineer by training, working with brain wave data and needing to replicate the kind of plotting he'd been doing in MATLAB. And he just, built it.
That origin story matters a lot. He needed a tool, the tool didn't exist, so he wrote it. And then other people needed the same tool, and it grew. Hunter passed away in two thousand and twelve, and by that point matplotlib had already taken on a life of its own, but his absence was a real moment for the project in terms of thinking about what governance and succession actually look like.
The library kept going, which is itself a remarkable thing. A lot of projects don't survive the loss of their founder.
The ones that do tend to have built enough community infrastructure that the project isn't entirely dependent on any one person's motivation or availability. Matplotlib had gotten there, barely, but it had gotten there.
Let's actually get into who these people are. Because I think the image most people have of an open source maintainer is either a lone genius coding in a basement or some kind of Google engineer doing it on company time. And the reality is more complicated than either of those.
Much more complicated. The maintainer population for something like matplotlib is heterogeneous. You have academics, people who are postdocs or professors or researchers at national labs, who contribute because the library is directly relevant to their work and they have some institutional flexibility to spend time on it. You have software engineers at companies like Anaconda or Quansight, which are companies whose entire business model is built around the scientific Python ecosystem, so paying engineers to maintain upstream libraries is directly in their interest. And then you have a third category which is harder to characterize: people who just care deeply about the project and find time to contribute around the edges of their regular jobs.
Scott Shambaugh falls into that last category, if I'm remembering correctly.
He does, yeah. He's a good example of the volunteer maintainer who ends up doing substantial work not because anyone is paying him to, but because he's invested in the library's quality and direction. And he's had to navigate some interesting situations, including, and this is a bit of a strange one, an AI agent that apparently published what he described as a hit piece on him based on misread contributions. He wrote about it on his blog. Which is its own commentary on the current moment.
The AI ecosystem giveth and the AI ecosystem taketh away.
But his situation illustrates something important about the volunteer maintainer: there's no HR department, there's no manager, there's no formal accountability structure if something goes wrong. You're operating on reputation and good faith within a community.
What does the Steering Council actually do day to day? Because governance documents are one thing, but the lived reality of a five-to-seven person council overseeing a library this size must be something else.
The Steering Council in matplotlib's case handles things like major API decisions, release management, accepting or rejecting significant pull requests, and setting the overall technical direction. But the day-to-day maintenance, the reviewing of smaller pull requests, the triaging of issues, the answering of questions from users, that falls to a broader group of contributors who don't necessarily have Steering Council status but who are trusted enough to do significant work.
The Steering Council has a Project Lead position within it.
Right, there's a Project Lead role, which carries specific responsibilities around coordination and external representation. It's not a dictatorship, it's more like a first among equals, but someone has to be the one who sends the email to NumFOCUS or shows up to the conference.
NumFOCUS being the nonprofit that fiscally sponsors matplotlib and a bunch of other projects in this space.
NumFOCUS is central to how this ecosystem sustains itself. They sponsor over thirty scientific computing projects, matplotlib and NumPy and pandas and Jupyter among them. What fiscal sponsorship means practically is that NumFOCUS handles the nonprofit infrastructure: accepting donations, managing grants, providing legal standing, doing the financial administration that a bunch of volunteer researchers are not equipped to do themselves. A research team can get a grant from the Chan Zuckerberg Initiative or the Sloan Foundation and have it flow through NumFOCUS rather than having to incorporate their own nonprofit.
Which would be a significant overhead for a project that's already running on limited capacity.
And grants from CZI and Sloan have been important for the scientific Python ecosystem. The Chan Zuckerberg Initiative in particular has funded multiple cycles of work on core scientific Python infrastructure, including matplotlib, NumPy, and SciPy. These aren't tiny grants either, they fund significant portions of developer time.
When you hear "open source, volunteer-driven project," that's not the full picture for something at matplotlib's level.
It's a partial picture. The volunteer contribution is real and essential, but for a library this critical, pure volunteerism isn't sufficient and everyone in the ecosystem knows it. The institutional partners, which in matplotlib's governance document refers to organizations that fund at least six person-months per year of paid work, are a recognized and formalized part of the governance structure. It's written into how the project is run.
Six person-months per year. So that's half a full-time engineer, roughly.
And that's the threshold for being recognized as an institutional partner, which comes with certain standing in the governance process. Some organizations contribute significantly more than that.
Anaconda and Quansight are the two corporate names that come up most in this context.
Anaconda has been in the scientific Python space since basically the beginning of the commercial ecosystem around it. They built their business on making Python data science accessible, and funding upstream library maintenance has been part of their model. Quansight is more recent but has become significant, they're a consulting and open source services company founded by Travis Oliphant, who was one of the key figures in NumPy's early development, and they employ a number of people who spend meaningful portions of their time on upstream maintenance.
Travis Oliphant is also one of the founders of Anaconda, originally, so there's a lot of institutional continuity in this small world.
It is a small world. The scientific Python ecosystem at the maintainer level is a community where most of the key people know each other, have collaborated, have sometimes had significant disagreements, and are going to keep running into each other at conferences and on mailing lists for years. That social dimension is not separate from the technical and governance questions, it's deeply intertwined.
Which brings us to the governance structures beyond the individual project level. Because matplotlib has its Steering Council, but there are also ecosystem-wide coordination mechanisms.
The SPECs are worth understanding here. Scientific Python Ecosystem Coordination proposals, they're the mechanism for cross-project coordination in the scientific Python stack. The idea is that decisions affecting multiple projects, things like minimum supported Python versions, deprecation timelines, shared tooling, benefit from a coordinated approach rather than each project making independent choices that may or may not align. A SPEC goes through a process where the scientific Python community, meaning representatives from the major projects, can discuss and reach consensus.
Which is different from PEPs.
PEPs, Python Enhancement Proposals, are the mechanism for changes to the Python language itself and to CPython, the reference implementation. They go through the Python Steering Council, which was established by PEP thirteen and is elected by Python core developers. SPECs are downstream of that, they're about the scientific Python ecosystem specifically, not the language itself.
Then there's a whole separate governance conversation happening around Python packaging.
Packaging governance is its own fascinating mess. For a long time, the Python Packaging Authority, PyPA, operated in a fairly ad hoc way, and there's been growing recognition that packaging infrastructure, PyPI, pip, the whole distribution system, has become critical enough that it needs more formal governance. PEP seven seventy-two, which is a recent proposal, suggests establishing a dedicated Packaging Council separate from the language Steering Council. The argument being that packaging decisions are technical enough to need their own specialized governance body.
Packaging security is increasingly a real concern.
Supply chain attacks on PyPI have been a recurring problem. When anyone can publish a package with a name similar to a popular library, and those packages get automatically installed by millions of pipelines, the attack surface is significant. The governance conversation around packaging is partly about technical standards and partly about who has the authority and responsibility to respond when something goes wrong.
You have this layered governance picture: the Python Steering Council at the language level, project-specific governance like matplotlib's Steering Council, cross-project coordination through SPECs, and now potentially a Packaging Council layer being proposed. Each layer with its own legitimacy questions and its own community dynamics.
All of it running on a combination of grant funding, corporate sponsorship, volunteer labor, and the social capital that builds up when people work together on hard problems over years. It's complex, and I think most users of these libraries have essentially no visibility into it.
The abstraction is so complete that you just import matplotlib dot pyplot and the entire social and economic infrastructure behind that import is invisible.
And that invisibility is arguably a success: the library works, the API is stable, you don't have to think about it. But it also means the people doing the work are largely unrecognized by the population benefiting from it, which has real consequences for funding and for the sustainability of the whole thing.
We're going to get into the funding models in more detail and what the sustainability picture actually looks like. But I want to stay on the maintainer side for another moment, because the burnout question is one that I think is underappreciated. What does it actually feel like to be one of fifteen people responsible for a library that millions of people depend on?
The pressure is asymmetric in a way that's hard to describe if you haven't experienced it. The number of people who can file a bug report or express frustration in a GitHub issue is essentially unlimited. The number of people who can meaningfully help fix the underlying problem is tiny. And the ratio of demanding interactions to rewarding ones can get very bad very quickly on a popular library.
There's no real way to hire your way out of it. You can't just bring on more maintainers the way a company would hire more engineers, because becoming a trusted maintainer on a project like matplotlib takes years of demonstrated judgment and community trust.
The onboarding problem is real. New contributors are welcomed, but the path from "occasional contributor" to "someone the Steering Council trusts to make significant decisions" is long. Which makes sense: you're giving someone authority over infrastructure that millions of people depend on. You want to know them. But it means the supply of capable maintainers can't expand quickly to meet demand.
The demand only goes up as Python's adoption continues to grow.
The scientific Python stack is being used in contexts that would have seemed extraordinary even ten years ago. Machine learning pipelines, bioinformatics at scale, climate modeling, pharmaceutical research. Matplotlib is in all of it, at least at the visualization layer. The user base keeps growing, the issue volume keeps growing, and the maintainer team grows much more slowly if it grows at all.
Let's dig into the funding side of this, because I think the picture of how money actually flows into these projects is more complicated and more interesting than most people assume.
The origin of all this is worth a minute, because matplotlib's history explains a lot about why the ecosystem looks the way it does now. John Hunter created it in 2003, and the context matters: he was a neurologist doing electrocorticography research, he needed to visualize brain signal data, and the tools available to him were either expensive proprietary software or not quite right for what he needed. So he built matplotlib to replicate the kind of plotting environment MATLAB offered, but in Python, and made it free.
Not a software engineer, not a computer scientist.
Which is the pattern you see repeatedly in scientific Python. The people who built the foundational tools were domain scientists who needed something that didn't exist. NumPy came out of the astronomy and physics communities. The scientific need drove the software, and then the software took on a life of its own far beyond the original domain.
Then suddenly you have a neuroscientist's plotting library running inside pharmaceutical pipelines and climate models and machine learning infrastructure at scale.
The scope of what matplotlib ended up covering is remarkable. Two-dimensional plotting, publication-quality figures, an enormous range of chart types, tight integration with NumPy arrays as the data primitive. It became the baseline that everything else in the Python visualization space either builds on or defines itself against. Libraries like seaborn are essentially higher-level APIs sitting on top of matplotlib. Even tools that compete with it often export to it.
That's what foundational actually means in practice. Not just widely used, but structurally load-bearing for things built on top of it.
That load-bearing quality is exactly why the maintainer and funding questions get complicated. When a library is optional, its maintenance is optional. When half the scientific Python ecosystem depends on your stable API, the stakes of getting it wrong are much higher.
Who are the fifteen people actually doing this?
It's a mix that I think would surprise most users. You have academics who started contributing as graduate students or postdocs and never really stopped, even as their careers moved in other directions. You have engineers at companies like Anaconda and Quansight whose job descriptions explicitly include upstream maintenance time. And then you have people like Scott Shambaugh, who is essentially a volunteer in the traditional sense: contributing out of genuine investment in the project, not because an employer is paying them to.
What does Shambaugh's situation look like specifically?
He's become one of the more active contributors in recent years, and his blog has been unusually candid about what that experience is actually like. The thing that stands out is the sheer volume of incoming work. Pull requests to review, issues to triage, questions to answer, deprecations to manage. It accumulates in ways that don't respect the fact that you also have a life outside the repository.
He's not drawing a salary for any of it.
Not from matplotlib. Which raises the question of what the incentive actually is, and I think the honest answer is that it's multiple things layered together. There's genuine intellectual satisfaction in the work. Matplotlib is technically interesting: the renderer architecture, the artist model, the way transforms are handled, these are non-trivial problems. For someone who finds that kind of systems design engaging, it's not boring work.
There's also the reputational dimension.
Being a recognized maintainer on a library with matplotlib's profile carries real weight in the scientific Python world and in the broader software engineering community. It opens doors. It's the kind of credential that doesn't show up on a resume in an obvious way but that people who know the field recognize immediately.
The implicit CV line.
And then there's something harder to quantify, which is the sense of being part of something that actually matters. When your library is being used in research that ends up in Nature or Cell, or in the pipelines at major research hospitals, or in the tools that climate scientists use to communicate findings to policymakers, that's not nothing. The impact is real and it's large and most maintainers are aware of it.
Which makes the burnout, when it comes, particularly brutal. Because you're not burning out on something trivial.
Hunter himself is the cautionary case. He died in 2012, at thirty-seven, from cancer, and at the time of his death matplotlib was already the dominant Python visualization library. He never saw the full scale of what he'd built. The project had to figure out how to continue without its founder, which is its own kind of stress test for governance and community resilience.
It did continue, which says something.
It says something important. The community had built enough structure and enough distributed expertise that it wasn't solely dependent on one person. That's not automatic, it's the result of deliberate choices about how to document, how to onboard, how to distribute decision-making authority. But the vulnerability is always there. Fifteen people is not many when the dependency graph runs into the millions.
Where does it actually come from?
NumFOCUS is the structural answer for most of the scientific Python stack. It's a nonprofit that provides fiscal sponsorship, which in practice means it handles the administrative infrastructure that a volunteer-run project can't realistically manage on its own: tax-exempt status, financial administration, grant management, legal support. Matplotlib is a sponsored project, NumPy is, pandas is, Jupyter is. Thirty-one-plus projects at this point, with more joining. MDAnalysis came on recently.
NumFOCUS is essentially the back-office for scientific Python.
That's a fair way to put it. And what it unlocks is the ability to receive institutional funding. Without a nonprofit home, a grant from the Chan Zuckerberg Initiative or the Sloan Foundation has nowhere to go. With NumFOCUS as the fiscal sponsor, the money can flow to actual paid maintainer time.
How significant are those grants in practice?
They're meaningful but not transformative on their own. The CZI grants in particular have funded substantial work on NumPy and matplotlib: accessibility improvements, documentation overhauls, specific feature development. The Sloan Foundation has been involved in Jupyter and the broader scientific Python ecosystem. But these are project-specific, time-limited grants. You get funding for eighteen months to do a defined piece of work, and then you need to find the next grant.
Which is its own kind of precarity. You're not building a sustainable institution, you're writing grants.
The grant-writing itself takes time that isn't going toward maintaining the library. There's a real overhead cost to the funding model that I don't think gets discussed enough. The people best positioned to write a compelling grant for matplotlib are the people who understand matplotlib deeply, which are the same people whose time is most valuable for actually maintaining it.
Then you have the corporate side. Anaconda and Quansight are the names that come up most often.
Both have made upstream maintenance a genuine part of their business model, which is unusual and worth recognizing. Anaconda's commercial interests are aligned with the health of the scientific Python stack: if NumPy or matplotlib degrades, their products degrade. So funding engineers to work upstream is rational. Quansight was founded explicitly around that model, with open-source sustainability as a stated mission rather than a side effect.
Is that stable though? Corporate priorities shift.
That's the tension. When a company decides its engineers should spend thirty percent of their time on upstream work, that's a policy decision that can be reversed in the next budget cycle. The library doesn't get a vote. And there have been cases across the open-source ecosystem where corporate backing disappeared quickly when business conditions changed, leaving projects suddenly under-resourced.
GitHub Sponsors is the other piece.
More of a long tail mechanism. Individual contributors getting direct financial support from users who want to say thank you or keep them going. It's meaningful for individual sustainability, less meaningful at the scale of a project like matplotlib. A maintainer getting five thousand dollars a year through GitHub Sponsors is better than nothing, but it doesn't replace a funded position.
The actual picture is: grants that are time-limited, corporate backing that can evaporate, volunteer labor that runs on passion and reputation, and small individual donations at the margins.
Which is why the governance structures matter as much as they do. SPECs, the Steering Council model, the cross-project coordination mechanisms: these aren't just bureaucracy. They're how a resource-constrained ecosystem makes decisions without burning through the social capital that holds it together. When you can't pay people enough to make the hard calls professionally, you need community norms strong enough that people make them anyway.
When those norms break down, you get the kind of public disputes that occasionally surface in the Python packaging world.
Packaging governance has been contentious precisely because the incentives are misaligned in complicated ways. PyPI, pip, setuptools, wheel: these are critical infrastructure maintained by different groups with overlapping but not identical interests. PEP seven seventy-two, the proposed Packaging Council, is an attempt to formalize authority in a space that has historically operated on a kind of ad hoc consensus that doesn't scale well.
The deeper issue being that consensus is cheap when the stakes are low and very expensive when they're not.
And the stakes in packaging are high because that's the attack surface. Supply chain vulnerabilities on PyPI are a real and recurring problem. When the governance of who can make security decisions is unclear, the response time suffers. A Packaging Council with explicit authority is a different thing from a mailing list reaching rough consensus.
The abstraction that makes this all invisible to users is doing a lot of work—but it’s not self-sustaining.
Which is why the practical question of what users can actually do matters more than it might seem. That abstraction hides a lot of complexity, but it’s not magic.
What can someone do? If you're a researcher who uses matplotlib every week and has never thought about any of this.
The lowest-friction entry point is financial. NumFOCUS takes direct donations, and they're a legitimate nonprofit, so depending on where you live there may be tax implications worth knowing about. Donating to NumFOCUS rather than to a specific project means the organization can allocate where the need is greatest, which is actually more useful than most people realize.
GitHub Sponsors for individual maintainers if you want to be more targeted.
If Scott Shambaugh's work specifically has saved you hours, there's now a reasonably direct mechanism to say so in a way that has some material weight.
Bug reports, done well, are valuable. Not "this doesn't work," but a minimal reproducible example, the version numbers, the expected versus actual behavior. A well-written issue can save a maintainer an hour of detective work. That's real.
Documentation contributions are underrated for this.
Most projects have issues tagged "good first issue" or "documentation" specifically because they need help there and it's accessible to people who aren't deep in the codebase. You don't need to understand the renderer architecture to fix a confusing docstring.
If someone wants to go deeper, the SPECs process and the governance discussions are public.
The scientific Python ecosystem does its decision-making in the open. Reading those discussions, understanding where the tensions are, eventually contributing to them, that's how people move from users to community members. It's not a fast process, but it's a real one.
The thing I keep coming back to is that the libraries feel permanent because they're everywhere. But they're not. They're maintained by people who could, and sometimes do, step back.
Which is the honest framing. Using these tools without any awareness of that is fine, most of the time. But the ecosystem is healthier when more of its users are aware enough to occasionally act on it. And that awareness ties directly into the broader sustainability question, doesn’t it?
The sustainability question doesn’t resolve cleanly, does it? There’s no version of this where the problem is solved and everyone goes home.
The closest thing to a hopeful trajectory is institutional normalization, the idea that funding upstream maintenance becomes a standard line item for universities, research institutions, and companies that depend on this stack, rather than something that happens when someone makes a compelling case in a grant application. A few universities have started treating it that way.
The governance structures maturing alongside that.
The Packaging Council proposal, the SPEC process, the Steering Council models, these are all attempts to build institutions that outlast individual contributors. Which is hard in a volunteer ecosystem. Institutions require maintenance too.
The meta-problem.
You need people to maintain the structures that allow people to maintain the libraries.
The open question I keep landing on is whether the scale of dependency has outrun the funding model entirely. Matplotlib is in the critical path for an enormous fraction of scientific computing. The funding it receives is not commensurate with that.
That gap is the real sustainability risk. Not any individual maintainer burning out, though that's real. The structural mismatch between how much the world relies on this infrastructure and how it's resourced. That's the thing worth watching.
Worth watching and, if you're a user, worth doing something about. Even something small.
Even something small.
Thanks to Hilbert Flumingtop for producing, and to Modal for the serverless infrastructure keeping this whole operation running. This has been My Weird Prompts. If you've got a minute, a review on Spotify helps more people find the show.
Until next time.
