pyOpenSci Funded to Tackle Thoughtful Adoption of AI Tools in Scientific Open Source

Oct 15, 2026 • Leah Wasser

The Alfred P. Sloan Foundation has funded pyOpenSci to study how AI tools are changing scientific open source, and to build practical guidance that helps contributors and maintainers use them deliberately.

Contributors smile around laptops during a conference sprint, with more people working at tables in a bright room behind them.

AI tools are changing how scientists write and review software. More importantly to us, they are also changing the dynamics among the people doing that work. The Alfred P. Sloan Foundation has funded pyOpenSci to understand those changes and build practical resources to help our community navigate them.

That matters to us because pyOpenSci supports the people who build and maintain the scientific Python software research depends on: researchers learning to write better software, maintainers reviewing software contributions, and the trust between them that makes open source possible.

What we’ve been hearing

Over the past six months, pyOpenSci has led this conversation in many different spaces. We lead an AI tool adoption session at UN Open Source Week, hosted a open space and a AI Tool conversation at the Maintainers SUmmit at PyCon US 2026](/blog/pycon-us-2026-generative-ai-open-source.html), we held a birds of a feather sessions at SciPy 2026, and lead a strategic focus group sessions at EuroPython. This combined with the day-to-day conversations in our peer review process where we see how these tools land on people who are still learning to build software and on people who are reviewing the code.

Three things stood out in these sessions:

  1. The strain on human systems is real. People and their networks that sustain open source are feeling the weight of AI tool adoption. Maintainers, in particular, miss the natural human interactions that used to fuel open source.
  2. The conversation around AI tool use can be polarizing. Polarization pushes certain voices to the top and leaves people unsure where they stand in a community.
  3. Many people find these tools genuinely useful in specific, well-defined ways. pyOpenSci data collected from peer review shows that most are using AI tools daily in their work.

What we’re going to do

While many projects have developed AI policies on their own, what struck us across all of this is that no one has systematically explored what “good” or “thoughtful” AI tool use actually looks like in scientific open source, or how its rapid adoption is directly affecting the community.

pyOpenSci wants to understand what’s really happening, and then build useful resources grounded in what we learn from the community.

Our work has two parts. First, we’re listening at scale. We’ll run a survey and a series of focus groups with maintainers, contributors, and research software engineers, and we’ll review the AI policies projects have already written to see what’s working and where the gaps are.

Second, we’ll build from what we learn. We’re developing practical guidance for contributors on working with these tools deliberately: designing alongside the tool rather than just accepting its output, asking it questions, iterating, and using it to learn concepts you didn’t know before. All of it starts from the software design principles that make good software good in the first place — modularity, legibility, scoping work before you write it. Those principles don’t change when the tools do, which is what makes them worth anchoring to.

We’re also developing a resource to help maintainers set clear expectations for AI-assisted contributions without having to write a policy from scratch.

Running through both is a commitment to critical, responsible adoption. Using these tools effectively means reckoning with what they cost — licensing questions, environmental impact, and the impact on the people and communities doing this work. Those tradeoffs belong in guiding the conversation, not as a footnote to it.

Why pyOpenSci

We’ve been teaching people to build better scientific software for years, and that teaching has always been grounded in data around both on how researchers learn, what their pain points are and how they actually build software. That combination matters here: these questions are as much about learning and behavior as they are about software.

We also have reach into the places where this is playing out. Our peer review process and mentored sprints show us how these tools affect people who are still building their skills. Our university partnerships connect us to researchers and research software engineers. And our community spans industry, academia, core Python, and the scientific Python ecosystem, which means we can bring the maintainers of widely used tools into the same conversation as the people just getting started.

Get involved

We succeed together. This only works if it reflects what’s actually happening across the community, so we want to hear from you. There will be a survey, focus groups, and an open review period where you can help shape what we build. Everything we produce will be openly licensed and free to adapt. Sign up here to get involved.

There’s something hopeful in all of this, and we’ve seen it firsthand. Even with the strain AI tools are placing on open source, what works is making space for people to connect and work together — especially volunteers. We’ve seen it in our peer review process, and in the work our Community and Research Lead, Shauna McKeon-Gordon, has done to strengthen how we bring new reviewers in and how we support the editorial and reviewer teams. The human parts of this are still the parts we have the most control over.

Last modified:

Keep reading