Astropy Project Keeps Astronomy Software Thriving

The Astronomers Who Refuse to Let Their Tools Rot

In 2012, a small group of astronomers faced a quiet crisis. Their software was dying. Not from bugs or bad code, but from neglect. Graduate students had written most of it for their PhDs, then left academia. Postdocs had moved on. The tools worked, but nobody was maintaining them. When the next generation of telescopes came online, generating petabytes of data, the old code would crumble.

So they did something unusual. They built a community that would outlast any single person's career. They called it the Astropy Project.

Now, a decade later, Adrian M. Price-Whelan and 130 co-authors published a paper documenting what happened next (Price-Whelan et al., 2022). The paper is not just a software release announcement. It is a case study in how to keep scientific infrastructure alive when the people who built it move on.

The numbers are staggering. The core Astropy package has been downloaded over 4 million times. Over 500 people have contributed code. The project now spans 40 affiliated packages, each handling a different slice of astronomy: spectroscopy, cosmology, stellar modeling, even the analysis of exoplanet atmospheres. It has become the backbone of modern astronomical research.

But the paper is not really about the software. It is about the people who keep it running, and the invisible labor that makes science possible.

What Happens When a PhD Student Writes the Code

The problem Astropy solves is older than most astronomers care to admit. Every scientific field has it.

A graduate student needs to analyze data. They write a script. It works. Their advisor says "nice job." The student graduates, gets a job in tech, and never touches the code again. The next student inherits a mess of undocumented functions, hardcoded paths, and mysterious variable names. They rewrite everything from scratch.

Astronomy had this problem worse than most fields. The data was enormous. The instruments were specialized. And the culture rewarded individual discovery over collective infrastructure. Building tools for other people did not get you tenure.

Price-Whelan and the Astropy team decided to fight this pattern. They did not just write better code. They wrote a social contract.

The paper describes how the project organized itself. A coordination committee oversees the core package. Affiliated packages have their own maintainers. Contributors sign a code of conduct. Decision making is public. The goal is to make the project feel like a community, not a corporation.

This matters because software dies when the original authors leave. The only way to keep it alive is to build a group of people who care about it collectively.

The v5.0 Release: A Milestone, Not an Endpoint

The paper announces version 5.0 of the core Astropy package. This is not a flashy update. It does not add a new feature that will make headlines. It does something more important.

The authors rewrote the entire I/O infrastructure (Price-Whelan et al., 2022). This is the part of the code that reads and writes data files. It is boring. It is essential. Without it, nothing else works.

They also improved the way Astropy handles units and constants. In astronomy, units are a nightmare. You have parsecs and light-years, solar masses and Jovian masses, fluxes in Janskys and magnitudes. One wrong conversion and your results are garbage. The new version makes it harder to make that mistake.

These are the kinds of improvements that do not get applause at conferences. They prevent errors that would otherwise waste months of work.

The authors also documented their development process in detail. They show how they manage contributions, how they handle breaking changes, how they decide what goes into a release. This is not glamorous. It is the plumbing that keeps the house standing.

How to Build a Community That Actually Works

The most interesting part of the paper is not the code. It is the social structure.

The Astropy Project has a coordination committee that oversees the core package. Affiliated packages have their own maintainers. There is a code of conduct. Decisions are made publicly. The goal is to make the project feel like a community, not a corporation.

The authors found that this structure worked because it was explicit. They did not assume people would figure things out. They wrote down the rules. They made it clear who could make decisions and how to appeal them.

This is rare in science. Most collaborations operate on unwritten norms and personal relationships. That works when the group is small and everyone knows each other. It breaks down when the group grows beyond a few dozen people.

The paper describes how they handle the tension between stability and innovation. The core package changes slowly. Affiliated packages can move faster. This lets researchers experiment without breaking the tools everyone depends on.

It is a model that other scientific projects could learn from.

The Hidden Cost of Free Software

The paper does not shy away from the hard parts.

Maintaining open source software is exhausting. The authors describe the burnout that comes from answering the same questions over and over, from dealing with entitled users, from watching your code get used without credit.

The Astropy Project has tried to address this by formalizing roles. Maintainers are not just volunteers. They have defined responsibilities. The project has a process for onboarding new contributors. It has a system for handling conflicts.

But the paper is honest: this is not enough. The authors note that the project still struggles with diversity. The contributor base is overwhelmingly white and male. The leadership is not representative of the broader astronomical community.

They also acknowledge that the project depends on unpaid labor. Most contributors are graduate students, postdocs, or faculty who work on Astropy in their spare time. This is not sustainable. The paper calls for more institutional support, but does not pretend to have solved the problem.

What This Actually Means

The Astropy paper is a document about software. But it is really about how science gets done in the 21st century.

• ▸Infrastructure is invisible until it breaks. Most astronomers never think about the code that handles their data. They should. The next generation of telescopes will produce data at a rate that makes current tools obsolete. Projects like Astropy are the only thing standing between astronomers and chaos.

• ▸Community is harder than code. The technical challenges of writing good software are real. The social challenges of keeping a community together are harder. The Astropy Project succeeded because they treated community building as a first class problem, not an afterthought.

• ▸Credit is a bottleneck. The paper has 130 authors. This is not vanity. It is a recognition that modern science depends on many kinds of work, not just the person who writes the final paper. The Astropy model shows one way to give credit to the people who build the tools.

• ▸Burnout is a design problem. The project has tried to address burnout by formalizing roles and processes. This is a start. But the underlying problem is that scientific software is expected to be free, and the people who maintain it are expected to be volunteers. That is not sustainable.

• ▸The next crisis is coming. The paper is about version 5.0. There will be a version 6.0, and a version 7.0, and so on. The project will need new maintainers, new funding, new ideas. The authors built something that can survive them. Whether it will depends on the next generation of astronomers.

The Astropy Project is not just a piece of software. It is an experiment in how to make scientific knowledge last. The code will be obsolete someday. The community might not. That is the real legacy.