SciPy 2026

One Problem, Many Projects: How Scientific Needs Built an Ecosystem
2026-07-15 , Memorial Hall

In 2004, Matthew Brett asked me a provocative question born of frustration with existing fMRI tools: "Why don't we rewrite them in Python?" That question led to a 2005 meeting that brought together a small group of core Scientific Python tool builders from astronomy, neuroscience, physics, and statistics, and then to a series of follow-up meetings alternating between Berkeley, Enthought's offices, and other locations. This talk traces how that ground-up, cross-disciplinary collaboration helped turn SciPy from a workshop curiosity into the backbone of today's ecosystem, and how the same people and patterns later shaped the Scientific Python project.


This talk tells the story of Scientific Python's growth through the lens of one institution and one fateful question. It follows how a small, domain-driven collaboration at UC Berkeley helped catalyze tools, practices, and organizations that now define the Scientific Python ecosystem, and how SciPy and its conferences became a shared planning space that later informed cross-project efforts like the Scientific Python project.

I begin in 2000--2004, when I joined UC Berkeley's Brain Imaging Center at a time when Python was only starting to be used seriously for numerical work. SciPy 0.1 had just been released, the first SciPy workshop at Caltech in 2002 drew only a few dozen scientists, and our neuroimaging work was dominated by large, opaque lab-owned research software. My colleague Matthew Brett and I wanted to build something better for fMRI analysis in Python, a goal that quickly pulled us into broader discussions about the future of Numeric, numarray, and SciPy's architecture. Those conversations ultimately matured into the Neuroimaging in Python (NIPY) project and a series of tools and publications that showed what it meant in practice to build domain-specific software on top of a young ecosystem---where we could lean on NumPy, SciPy, and matplotlib as they were, and where we had to contribute upstream to make the work possible.

The core of the talk focuses on the 2005--2007 period. A 2005 meeting at Berkeley brought together John Hunter (matplotlib), Fernando Perez (IPython), Travis Oliphant (then developing what became NumPy), Perry Greenfield (numarray/STScI), and others to sketch out concrete plans to unify on a single array core, refactor SciPy around that core, and treat SciPy as the base of a larger ecosystem rather than a monolithic library. Out of those conversations, and the broader discussions they sparked in the early developer community, came the decision to converge on NumPy, to split SciPy's functionality into a "core" plus separately maintained domain packages, and to prioritize packaging and installation so that scientists could actually adopt these tools. I will describe how this initial gathering turned into a series of small follow-up meetings---alternating between Berkeley, Enthought's offices in Austin, and other locations---that refined these ideas and effectively set the development roadmap for NumPy, SciPy, and the emerging Scientific Python ecosystem.

The third act zooms out to the conference and community layer. Beginning in 2007, I served as release manager for NumPy and SciPy and later chaired the SciPy conference (2008--2011) and edited its proceedings (2008--2013) as it evolved from a small workshop into an international venue with peer-reviewed papers. During that time, we also built the pre-Curvenote proceedings machinery, an early example of shared documentation and publishing infrastructure that supported reproducible research across projects. I will connect those roles to the founding of NumFOCUS in 2012, formalizing community infrastructure that had grown out of the same set of collaborations.

Finally, I bring the story to the recent past. At Berkeley's Institute for Data Science we helped launch the Scientific Python project, including SPECs, cross-project tooling, and the Scientific Python developer summits, explicitly aiming to recreate the collaborative atmosphere of the early SciPy workshops in a modern, multi-project setting. The Berkeley Open Source Program Office now helps sustain this kind of cross-lab, cross-institution collaboration as part of the university's regular activity rather than a one-off effort.

Throughout, the intended audience is broadly the SciPy community: developers, researchers, and practitioners who use the ecosystem daily. Attendees will learn:

  • How one domain-specific frustration (fMRI analysis software) helped catalyze cross-project collaboration at a critical moment for scientific Python.
  • How small, in-person meetings and local institutional support can have long-term ecosystem impact, from the first SciPy workshop through Enthought and INRIA to the Scientific Python developer summits.
  • How Berkeley's roles---as an early scientific user, as SciPy conference chair and editor, and now as a home for the Scientific Python project---fit into the larger history of Scientific Python.

Jarrod Millman is the Executive Director for Berkeley's Open Source Program Office (OSPO). With a background in computer science, mathematics, and statistics, and degrees from Cornell and Berkeley, Millman is a founding member of the scientific Python ecosystem. His primary focus is on developing and sustaining open-source, community-owned scientific software tools. Millman serves on the steering council of NetworkX, is a core developer of scikit-image, and was an early contributor to NumPy, SciPy, and scikit-learn. He has co-founded several influential initiatives to advance open and reproducible research, including the Scientific Python project, the nonprofit NumFOCUS, and the Neuroimaging in Python project.

This speaker also appears in: