I first attended the PyCon US Maintainer Summit five years ago as a speaker. I’m still here — now as a co-organizer. This year felt like a milestone for many different reasons.

Building the summit: a year-round labor of love

What most people don’t realize is that organizing the PyCon US Maintainer Summit is a year-round effort. We start thinking about the next one almost as soon as the last one wraps — collecting participant feedback, reflecting on what worked, and thinking about what to change.

This year we focused on something we’ve been working toward for a while: making the Maintainer Summit a more formal part of the PyCon US schedule. The Maintainer Summit has been running since 2019; this year we took a big step forward. Attendees could officially register, we could communicate directly with them through the PyCon US registration website, and we were formally listed on the PyCon US schedule. These might seem like small steps, but it takes a lot to make these types of changes in a large event like PyCon US that is organized by both PyCon US staff but also depends on a large team of volunteers.

This year’s successes wouldn’t have happened without the incredible support of PyCon US co-chairs Elaine Wong and Jon Bonafato, and PSF infrastructure lead Jacob Coffee.

New structure and event features for the day

We also rethought the structure of the Maintainer Summit this year. We added a Tools Track, inspired by the Tools Track at SciPy. We also added a GenAI Birds of a Feather session, and roundtables focused on lively discussions around packaging, security, and AI tools in open source.

We also helped launch an unofficial Discord with an automated bot — built with help from some wonderful folks in the Python community — that provided real-time session updates and gave attendees a way to connect with each other throughout the day. A first for the summit. This was a great way to help attendees connect with each other and follow the conference schedule without having to keep checking the schedule website.

None of this happens without an incredible team. Inessa Pawson and Mariatta Wijaya bring deep experience organizing events like this, and I’ve learned so much working alongside them. From the call for proposals, to reading submissions, to managing last-minute schedule changes — there’s an enormous amount of work that goes into making a day like this feel seamless.

A day full of energy

This year our registrations peaked at 150+ people for a full day of conversation around packaging, security, and AI. The event ran from 10am to 6pm, and while attendance dipped after lunch (this always happens at these types of events), energy in the room kept building. People sticking around until 6pm when they closed down the room was a great sign that the community is growing and that people are interested in the topics we were discussing.

It was especially meaningful to have pyOpenSci community members represented. Felipe Moreno spoke about the translations infrastructure he built for our Python packaging guide — work that started at our 2024 sprint and has grown into a multilingual contribution community. Part 3 of this series tells the full 2026 sprint story, including Portuguese translation work that built on Felipe’s infrastructure. Avik Basu shared work on a package he’s been developing. Having pyOpenSci members on stage alongside maintainers of core Python tools like uv (Zanie Blue) and Hatch (Cary Hawkins), and community leaders like Carol Willing and Mike Fiedler from the PSF covering security and AI, made for a powerful and well-rounded day.

Roundtables: where the magic happens

The roundtables are always the best part of this event. I will never forget my first roundtable discussion at this event four years ago. I sat with Travis Oliphant (creator of NumPy, SciPy, Numba) and Chase Million (Million Concepts CEO) and we talked about business development in open source. Chase, to this day, is not only a long-standing colleague but also a good friend. These types of events allow attendees to build connections that they never forget.

This year, roundtable topics included packaging led by Zanie Blue from uv and Cary Hawkins from Hatch, security led by Mike Fiedler from the Python Software Foundation, and AI tools in open source led by the incredible Carol Willing.

What makes roundtables so powerful is that they’re real conversations with experts and peers. At the end of a long day, when energy could easily be fading, the roundtables sparked connection and lifted the room.

The most electric moment

Our Generative AI Birds of a Feather session, co-hosted with Jackie Kazil, was an energizing addition to this year’s summit. Jackie reached out to us about hosting this part of the day. Maintainers everywhere are feeling overwhelmed and drained by the pace of AI change. Now more than ever, protecting our mental health and making space to connect, problem-solve together, and support each other matters.

But there’s also genuine hope. The majority of people in the room are already using GenAI tools thoughtfully, and that energy of working through hard things together was everywhere — echoed beautifully in Amanda Casari’s keynote on hope in the age of AI.

I have a lot more to say about AI tools and generative AI in open source in Part 4 of this series.

Wrap up

This year’s Maintainer Summit felt like a turning point — 150+ maintainers in one room, a more formal home within PyCon US, and new formats that gave people space to connect, learn, and work through hard problems together. That’s exactly what this community needs.

pyOpenSci is proud to be an organizing partner for the PyCon US Maintainer Summit. Maintainer work can be isolating; days like this remind us we’re not doing it alone. If you couldn’t join us in Long Beach, we hope to see you next year.

See you in there.

This is Part 2 of a 4-part series on pyOpenSci at PyCon US 2026. Part 1: community and connection · Part 3: pyOpenSci sprints · Part 4: generative AI and open source.

When things get hard, when the ground shifts beneath us, we need each other more than ever. We need spaces to connect, to learn together, to solve challenging problems as a community. PyCon reminded me why I love this work so much.

I’ll never forget my very first PyCon in Salt Lake City. I was intimidated. It’s a really big conference, and I only knew a few people. That first sprint? We had one person show up who wasn’t already part of our community. He sat down and spent the entire day working on our website, helping us improve our infrastructure. He gave his time to help a nonprofit organization like pyOpenSci grow.

Read more about that first PyCon experience in Salt Lake City.

Fast forward three years to Long Beach, California. We filled rooms with our open spaces. We had tables of people sprinting, working on pyOpenSci projects, learning together. People who attended multiple sprints with us — people I remembered struggling to submit their first pull request, now confident in their GitHub skills. This is what community support looks like. This is what pyOpenSci’s mission is all about: helping people grow. Read about the Maintainer Summit and the full sprint story from PyCon US 2026.

PyCon US has become my favorite conference. Not because of the topics covered or how it’s organized, but because of the people. The people who were strangers a few years ago and have now become my closest friends and colleagues. The hallway conversations. The way people show up for each other.

Even in a hard year — especially in a hard year — I left the conference feeling fulfilled, feeling whole, and so grateful for the friendships and relationships I’ve deepened over time.

In this series

Part 1: Community, connection, and what comes next — You’re reading it. An overview of PyCon US 2026 and why the people in the room are what make open source work.

Part 2: The Maintainer Summit — A milestone year for the summit: formal PyCon registration, 150+ maintainers, and roundtables on packaging, security, and generative AI.

Part 3: The sprints — From one person in Salt Lake City to a room full of contributors working together. Growth, learning, and community in action.

Part 4: Generative AI and open source — GenAI was everywhere at PyCon this year. Not as hype, but as a real challenge the community is wrestling with. Between our open space, the Maintainer Summit BoF, and Amanda Casari’s powerful closing keynote, a theme emerged: the path forward is human.

What it all comes down to

If there’s one thing that tied all of these experiences together, it’s this: the humans are what make open source work. The tools change, the challenges evolve, but the connections, the learning, the care people bring to this work — that’s the irreplaceable part.

This is Part 1 of a 4-part series on pyOpenSci at PyCon US 2026. Part 2: Maintainer Summit · Part 3: pyOpenSci sprints · Part 4: generative AI and open source.

What is Ship It?

Ship It is a 10-day, fully online, asynchronous cohort course that takes you from zero to a published Python package — with tests, documentation, and automated workflows built on the pyOpenSci packaging template.

The course was designed as an accessible entry point for researchers, academics, research software engineers, and anyone who wants to package and share their work using modern best practices. Participants learn how to use packaging tools like Hatch for environment management and task running, uv for fast dependency resolution, and pytest for testing — all inside GitHub Codespaces, so nobody gets stuck on local setup.

Each weekday, a new module drops, made up of videos and text lessons. Each week, participants complete interactive “milestones” in which they share their own package or day’s work and then test a classmate’s. This project-based learning approach mirrors the spirit of open source collaboration. Engagement was also encouraged by a gamified points system, where participants earned points working toward a final LinkedIn badge and completion certificate. For many, the community aspect of the course was an unexpected — but carefully designed — highlight.

In response to “what was your favorite part of the course”, one participant said:

Probably the community part. Don't misunderstand me, the lectures are great, clear and well structured. Easy to follow. But interacting with the community, testing each other's code, has been sincerely great.

Learning from the people who build the tools

Sprinkled throughout the course were interviews with open source leaders like Carol Willing (Jupyter, CPython) and Melissa Mendonça (NumPy, Napari), so learners got more than technical skills — they received insights from the people building the tools they use every day.

The async format was a deliberate choice. pyOpenSci has run synchronous training events for years, but fixed timing limits who can attend, leaves little room for digestion, and tends to keep engagement within single institutions. An async cohort format gives participants flexibility to learn at their own pace while still building real connections across universities.

We also wove a thread of responsible AI throughout the course. We’ve been thinking deeply about this topic for a few years, and we wanted to offer a clear framework for using AI tools in ways that grow your skills and sustain — rather than drain — the open source ecosystem.

Ship It by the numbers

This first cohort was generously sponsored by Open Source at Stanford University and supported by the CURIOSS OSPO network, making it free for all 55 participants.

• 55 registered participants from universities across the US
• 27 videos across 10 modules
• 6 gamified milestones — 14 participants completed all of them
• ~30 participants created and published a Python package — for many, their first ever
• Sponsored by Stanford University and supported by the CURIOSS OSPO network

It was incredible to see that ~30 people published a Python package, many for the very first time. But the numbers only tell part of the story.

What participants experienced

Ship It was designed to be hands-on from day one — and that showed in the outcomes. One participant, a structural biologist,was able to clean up a package they had been working on and share it at her departmental retreat. She shared her story with us:

This week I presented my Python package 'PDBCleanV2' at the Structural Biology Departmental Retreat. It was well received by attendees and, overall, a great experience. I wanted to thank you because pyOpenSci was a great influence in getting my package in shape.

That’s the goal. Real code, real learning, real impact.

The community made it real

The milestone structure pushed participants to engage with each other’s work — and that turned out to be one of the most talked-about parts of the course.

I finally caught up on the content of the workshop, and I have been loving it. Some concepts used to seem very intimidating, but I liked how they were explained clearly. I have also been enjoying the community aspect, checking other people's packages and getting comments on mine.

Structure and clarity mattered

Participants consistently called out the clear, step-by-step progression as a highlight. Going from “what even is a pyproject.toml” on Day 2 to “I just published my package to TestPyPi on Day 3 allowed for big early wins that helped people stay oriented and keep moving.

My favorite part of the course has been the step-by-step guidance and the hands-on experience of building a package. I also really liked the videos where the mentor shares the challenges they faced — it made the process feel more real and relatable. Testing classmates' packages was another highlight, as it helped me learn from others and see different approaches.

Loved how interactive the workshop was, and how responsive the instructors were. The content was great, and the videos made it so easy to understand the concepts. And having the text below helped me when I wanted to review.

Hands-on from day one

Learners also commented on how the course broke down technical packaging terms and content into easy to digest lessons. Imposter syndrome is real and pyOpenSci works hard to break down those barriers for everyone.

I am very motivated. The workshop made me less afraid of certain aspects of creating the package; the explanations have been very clear and to the point. I am planning to implement what we learned on my own package, and I feel confident that I can do it.

Honest takes on GenerativeAI

Several participants specifically called out the AI content — not just the technical pieces, but the perspective. The responsible AI framing resonated, as did the expert interviews.

In response to a question about the Generative AI content, one participant had this to say about the associated Generative AI milestone activities:

[the genAi module] It was an interesting session. I got more than I expected, in particular from the milestone. Seeing how other people interacted with AI and what we learned from it. I think it is important to have these discussions.

GenerativeAI has such a profound impact on all aspects of writing code right now. We encouraged participants to experiment with using GenAI tools to write tests and implement “defensive code strategies” in their package modules and then reflect and share the outcomes of this effort with each other.

The course design flexibility made it accessible

I attended a conference during this course (full day for two days) and was still able to complete the course once the conference ended. I appreciate the structure of the course, and the flexibility was also needed.

A window into the Python ecosystem — and the AI conversation

Ship It was about more than packaging mechanics. Through interviews with Python leaders like Carol Willing, CPython core developer, and Melissa Mendonça from Quansight, participants got an inside look at the Python ecosystem that most of us simply aren’t exposed to in traditional academic environments.

That included an honest conversation about AI — specifically, how the explosion of generative AI is placing real pressure on the open source human ecosystem. The people maintaining the tools you rely on are volunteers. That context matters.

The course also explored how to use AI thoughtfully — as a tool for building more robust test suites, writing defensive code, and deepening your own understanding. Not something to become reliant on, but something to grow with.

What we learned from cohort one

The flexibility of the async format resonated more than we expected. Participants were logging in at 2 am, at 7 am, whenever it fit their lives and time zones.

My favorite part of running this course was the cross-institutional engagement. Learners at Stanford, Berkeley, UC Davis, UC Santa Barbara, Harvard, Wisconsin, and universities across the country were connecting with each other in ways that simply don’t happen within a single institution. That’s exactly what pyOpenSci is built for — bringing the broader community together rather than keeping expertise siloed.

That community connection extended to the experts, too. Participants learned directly from the people building the tools they use every day through real conversations. That kind of engagement is what makes pyOpenSci’s trainings shine, and it’s hard to replicate.

For pyOpenSci, the async cohort model also supports our sustainability goals. Running the course multiple times for different groups, at their own pace, means we can reach more people — and build toward long-term sustainability by doing what we do best: making packaging and sharing code more accessible so researchers can spend more time solving the world’s greatest challenges and less time fighting with tooling.

Bringing Ship It to your institution

If you’re running an OSPO, a research computing program, or any initiative that supports academics who write and share code, ShipIt was built with you in mind. The course gives your community direct access to modern Python packaging practices, responsible AI frameworks, and — crucially — real connections to the people building the tools within the open source ecosystem.

Click here to learn more about our partnership program.. We’d love to talk with you about how we can support your community.

What’s next

The first cohort proved the model works. Researchers published packages, made connections across institutions, and left with skills and confidence they didn’t have before. We’re building on that for fall 2026.

Keep an eye on our events page for cohort announcements.

I’m not going to sugarcoat it—2025 was hard.

Watching organizations like the Python Software Foundation turn down million-dollar National Science Foundation (NSF) grants because DEIA work was no longer supported made something painfully clear: the funding landscape that has grounded so many of us is no longer reliable.

At the same time, Generative AI fundamentally changed how open source work happens. Maintainers found themselves reviewing more code than ever—much of it machine-generated—while navigating ethical questions about authorship and responsibility they didn’t sign up to solve on their own.

For many of us, the ground felt unstable—not just months out, but sometimes day to day.

And yet, something important happened.

Instead of pulling back, the pyOpenSci community leaned in. People showed up for each other. They reviewed, mentored, taught, organized, and adapted—often quietly, often while navigating uncertainty of their own.

The moment that changed everything

One moment from 2025 keeps coming back to me: our sprint at SciPy.

We had record attendance at that sprint compared to previous years! The large group self-organized. Tables moved. Whiteboards filled with ad-hoc lessons on Git and GitHub. Experienced contributors mentored newcomers.

I think about the colleague who sat down, saw the size of the sprint group, and asked—”how can I help?”. He spent the day working with other sprinters, helping them make their first contributions to open source.

This is one example of how baking structure and strong value systems into a community can yield incredible returns. The community members show up for each other because that is just how pyOpenSci operates. It’s who we are, and it’s magical.

Community members show up for each other because that is how pyOpenSci operates. It’s who we are and it’s magical.

That day felt like the manifestation of a blueprint. It showed what happens when you create the right environment and empower a community to help each other. That model— shared ownership, peer learning, mutual support—changed how I think about building sustainable infrastructure and community.

Resilience is about building inclusive spaces for people to both engage, learn, and support each other.

What we’re building in 2026

Shifting how we think about sustainability

One of the clearest lessons from 2025 is that a grant-dependent model alone can’t support the community-centered infrastructure pyOpenSci is building. Grants will always matter, but they can’t be the only pillar holding us up.

As we move into 2026, pyOpenSci is shifting toward a more diversified sustainability plan–one that centers on training, sponsorship, and community support. And as always, our focus will remain on human-centered growth and development, which is particularly critical in our current moment of Generative AI-driven rapid change.

Value-alignment will continue to be critical as we make this shift.

Training that connects people and builds responsible practice

In 2026, we’re investing in a new type of training: programs that bring researchers from around the world together to learn both software development best practices and the responsible use of Generative AI in scientific and open source workflows. The training will be held asynchronously to reduce barriers to participation and increase accessibility. And it will feature incredible leaders in the open source community in an effort to connect learners to the real heart of Open Source–people.

We’re piloting this new training format through our partnership with Stanford’s Open Source Program Office (OSPO). Building on the momentum, we’ll expand this model to other university OSPOs, leveraging the strong connections within the CURIOSS network and building an organizational membership program that supports researchers at scale. While our courses will initially be designed for OSPO researchers they will be valuable to anyone looking to develop the open source and responsible us of Generative AI skills that are in high demand in today’s tech-driven job market.

Generative AI can support open source workflows, but it can’t fully replace the thought, design, and vision that only a human can implement. It also can’t replace mentorship, care, and compassion—human parts of the tech world that both fuel the open source ecosystem and are also straining the fragile social web that supports it. Our training will continue to emphasize foundational open source skills, critical thinking and shared open source norms and workflows.

Our goal is to create learning spaces that reduce isolation, build confidence, connect learners to the humans that drive open source, and strengthen the communities behind scientific software.

The people who make this possible

None of what we learned in 2025—or what we’re building toward in 2026— happened in isolation.

I’m deeply grateful to our 2025 Executive Council, Karen Cranston and April Johnson, for their steady guidance and support as we navigated a challenging year. They encouraged me to embrace sustainable leadership and supported me as I developed new programs to ensure our long-term sustainability.

Our Editors-in-Chief—James Balamuta, Eliot Robson, and Lauren Yee— led the peer review process through a period of rapid change, navigating AI-fueled submissions while keeping quality and care at the center. Carter Rhea stepped up as an editor numerous times, supporting volunteers who were overburdened and leading one of our largest reviews—Astropy—which was just accepted in early 2026.

Members of our Advisory Council—Carol Willing, Inessa Pawson, and Chase Million— helped me think through sustainability, partnerships, and long-term direction with wisdom and generosity.

And to the many community members who contributed through reviews, workshops, sprints, writing, mentoring, and quiet acts of support—thank you. This organization exists because you choose to show up.

Community matters most

When things are uncertain, community infrastructure matters most. It’s how people find support that institutions can’t provide. It’s how knowledge gets shared when traditional collaboration pathways break down. It’s how we take care of each other.

That SciPy sprint showed me what’s possible. When you create spaces where people can show up, learn together, and support each other—when you do that consistently—the community becomes the infrastructure.

This is how we build resilience. This is how we help make the world better. Together.

Many tasks related to these models, particularly influence maximization, require running simulations on large graphs many times, which can be computationally expensive. There has been significant prior work on reducing the number of simulations needed for these tasks, demonstrating the importance of an efficient implementation.

While researchers often prefer high-level languages like Python for their flexibility and quick development, these computationally intensive tasks are better suited for low-level, compiled languages. To bridge this gap, we’ve developed CyNetDiff, a Python library that uses components written in Cython to provide the performance of a compiled language with the flexibility of a high-level language.

Package Features

The performance-critical parts of CyNetDiff are written in Cython, a language extension that compiles to C++ while remaining callable from Python. To take advantage of Cython’s speed, the library uses the compressed sparse row (CSR) format in an array-based representation. This data structure has low memory overhead and allows for efficient, repeated traversals, making it ideal for diffusion process simulations.

The implementation also uses a BFS-based traversal algorithm that only explores the out-neighbors of nodes activated in the previous iteration. This means the work done is proportional to the number of edges connected to activated nodes, which can be much smaller than the size of the entire graph, especially when there are few seed nodes.

The package also includes utility functions to easily convert well-established NetworkX graphs into the CSR format, allowing for seamless integration into existing research pipelines.

Development

The development and review process for CyNetDiff was lengthy, partly due to the complex packaging requirements for Cython. After trying many different tools, we eventually settled on PDM and Meson as the packaging tools for this project. Our greatest difficulty in converting from prior tools was understanding the configuration files necessary for building and releasing our package.

Use of Generative AI

During development, we used Google Gemini to help interpret and understand Meson’s configuration syntax for our project’s build system. The AI-generated configuration suggestions were carefully reviewed, tested, and adapted to our specific project needs before implementation. All code was validated through our test suite and the pyOpenSci review process.

pyOpenSci encourages transparency about AI tool use in package development. To learn more about our approach to generative AI in open source software, see our generative AI peer review policy.

Citing

This library is joint work with Dhemath Reddy and Abhishek K. Umrawal. This post is adapted from our VLDB paper, which should be used for citations.

Generative AI meets scientific open source

Some developers believe that using Generative AI products increases efficiency. However, in scientific open source, speed isn’t everything—transparency, quality, and community trust are just as important as understanding the environmental impacts of using large language models in our everyday work. Similarly, ethical questions arise when tools may benefit some communities while harming others.

Why we need guidelines

At pyOpenSci, we’ve drafted a new policy for our peer review process to set clear expectations for disclosing the use of LLMs in scientific open-source software.

Our goal is transparency and fostering reproducible research. For scientific rigor, we want maintainers to disclose when and how they’ve used LLMs so editors and reviewers can fairly and efficiently evaluate submissions. Further, we want to avoid burdening our volunteer editorial and reviewer team with being the initial reviewers of generated code.

This is the beginning of our work to ensure that Gen AI tools are not creating undue burden on our volunteer software review team. Humans cannot perform in depth reviews at the rate at which these tools can create large volumes of code.

A complex topic: benefits and concerns

LLMs are perceived as helping developers:

• Explain complex codebases
• Generate unit tests and docstrings
• Simplify language barriers for participants in open source around the world
• Speed up everyday workflows

Some contributors perceive these products as making open source more accessible. And for some, maybe they do. However, LLMs also present unprecedented social and environmental challenges that we have to critically evaluate.

Incorrectness of LLMs and misleading time benefits

Although it is commonly stated that LLMs help improve the productivity of high-level developers, recent scientific explorations of this hypothesis indicate the contrary. What’s more is that the responses of LLMs for complex coding tasks tend to be incorrect and/or overly verbose/inefficient. It is crucial that, if you use an LLM to help produce code, you should independently evaluate code correctness and efficiency.

Environmental impacts

Training and running LLMs requires massive energy consumption, raising sustainability concerns that sit uncomfortably alongside much of the global-scale scientific research that our community supports.

Impact on learning

Heavy reliance on LLMs risks producing developers who can prompt, but not debug, maintain, or secure production code. This risk undermines long-term project sustainability and growth. In the long run, it will make it harder for young developers to learn how to code and troubleshoot independently.

We’re really worried that if humans don’t learn, if they start using these tools as a crutch and rely on it, then they won’t actually build those fundamental skills to be able to use these tools effectively in the future. Hamsa Bastani

Ethics and inclusion

LLM outputs can reflect and amplify bias in training data. In documentation and tutorials, that bias can harm the very communities we want to support.

Our approach: transparency and disclosure

We acknowledge that social and ethical norms, as well as concerns about environmental and societal impacts, vary widely across the community. We are not here to judge anyone who uses or doesn’t use LLMs. Our focus centers on supporting informed decision-making and consent regarding LLM use in the pyOpenSci software submission, review, and editorial process.

Our community’s expectation for maintainers submitting a package is simple: be open and disclose any Generative AI use in your package when you submit it to our open software review process.

• Disclose LLM use in your README and at the top of relevant modules.
• Describe how the Generative AI tools were used in your package’s development.
• Be clear about what human review you performed on Generative AI outputs before submitting the package to our open peer review process.

Transparency helps reviewers understand context, trace decisions, and focus their time where it matters most. We do not want the burden of reviewing code generated from a model, placed on a volunteer. That effort belongs to the maintainer who ran the model that generated that code.

Human oversight

LLM-assisted code must be reviewed, edited, and tested by humans before submission.

• Run your tests and confirm the correctness of the code that you submitted.
• Check for security and quality issues.
• Ensure style, readability, and concise docstrings. Depending on the AI tool, generated docstrings can sometimes be overly verbose without adding meaningful understanding.
• Explain your review process in your software submission to pyOpenSci.

Please don’t offload vetting of generative AI content to volunteer reviewers. Arrive with human-reviewed code that you understand, have tested, and can maintain. As the submitter, you are accountable for your submission: you take responsibility for the quality, correctness, and provenance of all code in your package, regardless of how it was generated.

Watch out for licensing issues.

LLMs are trained on large amounts of open source code, and most of that code has licenses that require attribution (including permissive licenses like MIT and BSD-3). The problem? LLMs sometimes produce near-exact copies of that training data, but without any attribution or copyright notices. LLM output does not comply with the license requirements of the input code, even when the input is permissively licensed, because it fails to provide the required attribution.

Not all code carries the same licensing risk. The risk varies depending on what you’re generating.

Risk of license infringement is lower for routine tasks like refactoring existing code, test suite improvements, creating boilerplate code, simple utility functions, and docstring generation. These tasks are more common, often use widely documented patterns, and are not as likely to be substantially similar to copyrighted training data.

Tasks that are higher risk include:

• Algorithm implementations
• Developing workflows for complex data structures
• Domain-specific logic that is potentially already published or copyrighted

For high-risk content (e.g., algorithm implementations), you need to understand the algorithm to vet its correctness, ensure the approach is not already published and copyrighted, vet its performance, and evaluate edge cases. If you understand it well enough to review it thoroughly, you can often implement it yourself. In these cases, use LLMs as learning aids—ask questions, study approaches, then write your own implementation.

Why this matters:

• LLM-generated code may be substantially similar to copyrighted training data; sometimes it is identical. Copyright law focuses on how similar your content is compared to the original.
• You can’t trace what content the LLM learned from (the black box problem); this makes due diligence impossible on your part. You might accidentally commit plagiarism or copyright infringement by using LLM output in your code even if you modify it.
• License conflicts occur because of both items above. Read on…

When licenses clash, it gets particularly messy. Even when licenses are compatible (e.g., MIT-licensed training data and MIT-licensed output), you still have a violation because attribution is missing. With incompatible licenses (say, an LLM outputs GPL code and your package uses MIT), you can’t just add attribution to fix it—you’d technically have to delete everything and rewrite it from scratch using clean-room methods to comply with licensing requirements.

The reality of all of this is that you can’t eliminate this risk of license infringement or plagiarism with current LLM technology. But you can be more thoughtful about how you use the technology.

What you can do now

Consider the following:

• Assess the licensing risk based on what you’re generating: routine refactoring carries lower risk than implementing novel algorithms or domain-specific logic.
• Be aware that when you directly use content from an LLM, there will be inherent license conflicts and attribution issues.
• Use LLMs as learning tools: Ask questions, review outputs critically, then write your own implementation based on understanding. Often the outputs of LLMs are messy or inefficient. Use them to learn, not to copy. This is especially important for high-risk content like algorithms.
• Understand and transform code returned from an LLM: Don’t paste LLM outputs directly. Review, edit, and ensure you fully understand what you’re using. You can ask the LLM questions to better understand its outputs. This approach also helps you learn, which addresses the education concerns that we raised earlier.
• Consider clean-room techniques: Have one person review LLM suggestions for approach; have another person implement from that high-level description.
• Document your process: If you plan to submit a Python package for pyOpenSci review, we will ask you about your use of LLMs in your work. Document the use of LLMs in your project’s README file and in any modules where LLM outputs have been applied. Confirm that it has been reviewed by a human prior to submitting it to us, or any other volunteer-led peer review process.

You can’t control what’s in training data, but you can be thoughtful about how you use these tools.

Review for bias

Inclusion is part of quality. Treat AI-generated text with the same care as code. Given the known biases that can manifest in Generative AI-derived text:

• Review AI-generated text for stereotypes or exclusionary language.
• Prefer plain, inclusive language.
• Invite feedback and review from diverse contributors.

Things to consider in your development workflows

If you are a maintainer or a contributor, some of the above can apply to your development and contribution process, too. Similar to how peer review systems are being taxed, rapid, AI-assisted pull requests and issues can also overwhelm maintainers too. To combat this:

• If you are using generative AI tools in your daily workflows, keep each task small, focused, and well-defined. This is particularly important if you are using agent mode. This will produce smaller changes to your codebase that will be easier to thoughtfully review and evaluate.
• Open an issue first before submitting a pull request to a repository that you don’t own to ensure it’s welcome and needed
• Keep your pull requests small with clear scopes.
• If you use LLMs, test and edit all of the output before you submit a pull request or issue.
• Flag AI-assisted sections of any contribution so maintainers know where to look closely.
• Be responsive to feedback from maintainers, especially when submitting code that is AI-generated.

Where we go from here

A lot of thought and consideration has gone into the development of pyOpenSci’s Generative AI policies.

We will continue to suggest best practices for embracing modern technologies while critically evaluating their realities and the impacts they have on our ecosystem. These guidelines help us maintain the quality and integrity of packages in our peer review process while protecting the volunteer community that makes open peer review possible. As AI tools evolve, so will our approach—but transparency, human oversight, and community trust will always remain at the center of our work.

Join the conversation

This policy is just the beginning. As AI continues to evolve, so will our practices. We invite you to:

👉 Read the full draft policy and discussion 👉 Share your feedback and help us shape how the scientific Python community approaches Generative AI in open source.

The conversation is only starting, and your voice matters.

The members of pyOpenSci spend a great deal of time selecting these tools, debating tradeoffs, test-driving them in new situations, looking at new community trends, and listening to feedback from events we run. But up until now we haven’t typically posted in the open either how or why we have come to the decisions we did. This post outlines, in not very strict terms, the rubric we use when selecting a project that we want to recommend. We focus on a beginner-leaning happy path for packaging workflows. In other words, what works really well for new projects that don’t have a lot, if any, non-conventional requirements to share their code.

Our rubric comes from five categories, approximately ordered as follows:

Tools that are free and open

We love open software! It’s even in our name. We are always looking to nurture and support open source software, even beyond packaging projects. It should come as no surprise, then, that we only choose tools in our packaging guide that are themselves open source.

We don’t just appreciate open source, though, we also look for projects that are open contribution – that do most of their maintenance, stewardship, and designing in public. This means there is a public bug tracker where new issues are accepted from anyone, and fixes for those bugs are also accepted from non-maintainers. It may also mean that new feature ideas are accepted from the community, or even given a period of public comment. Contributions from everyone, including members and non-members, should be respected as the exchange of free ideas. Project authors should not seek to take exclusive ownership of the collaborative efforts of the community they are a part of. This means that contributors of any level and for any purpose of the project should be recognized publicly. It also means that the project is not asking for the exclusive rights to those contributors’ ideas (through overly restrictive Contributor License Agreements).

Our commitment to open software goes beyond just projects that choose to host their code and bugs in a public manner. We also value Free Software; both as in Beer and as in Freedom. Permissive open source software empowers its users to take control of their tools and fix, extend, secure, and adapt code for the purposes that will best fit their own needs. Choosing projects that do not require a financial exchange in order to be used ensures that we can recommend our choices to anyone no matter their situation or location.

Tools that are inclusive

Inclusivity is very important to us; it is a critical component of tooling projects we select. Programming, including packaging of that software, is a skill that should be available to everyone.

The tools we advocate for should not seek to limit their use through actions such as: adoption of a restrictive license; poor, missing, obfuscated, or expert-only documentation; charging for use of the tool or any process related to its successful usage; not supporting mainstream operating systems. The projects behind the tools should welcome constructive bug reports from users of all levels, and ideally also welcome contributions from all their users.

There are some signals that we look for to tell if the project is inclusive. We want all of our recommended tools to have a code of conduct for their project. The project should also have a contributors guide that is easy to find. Labeling issues or running sprints aimed at fostering commits from new contributors is also a great indicator.

Projects that manage to attract and maintain a broad base of contributors will be viewed more positively. We value projects that strive to do this not only in code, but also in documentation, engagement with the bug tracker, external write-ups and tutorials, and so forth.

Tools that implement open standards

It is very important to us that the tools and processes we stand behind support the full set of community standards.

For Python, this typically means conforming to Python Enhancement Proposals, but may also involve other standard bodies such as Scientific Python Ecosystem Coordination.

Supporting community standards demonstrates that the project respects the community it is working within and is serious about interoperability with other tools and processes. When done right, these tools empower their users to move this workflow, or any of its inputs or outputs, to another standards-compliant tool or process with little to no friction. It also makes it easier to teach since many of the concepts, as well as in some cases entire parts of project data, are tool-agnostic and can feel “familiar” even to those that have never used the tool before. There is also likely to be more documentation developed through forums, blogs, workshops, and other online platforms, because they apply to more than one tool.

It can be a lot of work for tool maintainers to keep up-to-date with changes in standardization, especially in a large and eclectic community such as Python. While we understand that it can take time to implement new features imposed from outside of a project, we also know that a selectively-implemented standard is often worse than no standard.

Tools that are well supported

We would like to only recommend projects that we can confidently say are healthy, correct, and here to stay. A well-maintained project is a somewhat subjective metric that is hard to pin down, but whenever possible we would apply our same standard for Peer Reviews of Scientific Software.

Authors and maintainers should respond to open issues and continue to make fixes to the project. We do not have any expectation or metric of response time, open bug count, time to close commit requests, security artifacts, or any other level of effort requirement; only that the project is alive and healthy to the degree that is appropriate for its function. We also strongly prefer projects that have a team of core maintainers as opposed to an individual maintainer.

Tools that reduce user choices

Python packaging suffers, perhaps infamously, from Too Many Options. We would like to make as many pragmatic choices as we can on behalf of the learner. Better yet is to make choices that will eliminate further choices and complexity later on in the process; this can help learners from getting stuck in runaway analysis paralysis.

This means that these tools should implement sensible defaults for any configurable value. Like with Python, they should make the simple easy and the difficult possible.

It also means that we will generally select one tool when two or more could do the same job. So long as the one tool fits our other criteria it doesn’t have to “win” at every single task it is capable of doing when compared against a plethora of other tools.

Open science has transformed how research is conducted, shared, and reused. Yet the organisations at the heart of this transformation are often left vulnerable, underfunded, and disconnected from one another. To move from simply surviving to truly thriving, five leading open science organisations -- The Carpentries, OLS, rOpenSci, pyOpenSci, and PREreview) -- are convening to chart a collective path forward. We are so grateful to The Navigation Fund for supporting this work, and invite our communities to review the full proposal online.

Why This Convening Matters

Our work has reshaped scientific culture by modeling inclusive, participatory, and transparent practices. But despite the global reach and impact of our communities, we face shared challenges:

• Chronic underfunding that undermines our ability to plan and grow.
• Fragmentation across networks, which weakens collective visibility and coordination.
• Unsustainable engagement models that over-rely on volunteers without adequate support systems.

Like a single thread, each of our organisations is fragile alone; together, we can weave a stronger, more resilient open science fabric.

Current Gaps

Open science is built on collaboration and transparency, but too often the organisations building this infrastructure operate in silos. The result is uneven visibility, duplicated efforts, and missed opportunities to align strategies. Community-driven organisations like ours face distinct challenges compared with technical infrastructure projects: recruiting contributors is not enough if the structures and motivation to sustain their engagement are missing.

This fragmentation is not just an internal problem; it’s a loss for the broader research ecosystem that depends on our work.

Our Approach

We are planning a strategic, in-person convening of leadership from our five organisations. This gathering will focus on:

• Shared financial sustainability: Developing collective, value-aligned models for funding and resource generation.
• Collaborative engagement strategies: Designing systems that strengthen and connect our communities across roles, regions, and lived experiences.
• Equity-centered design: Ensuring accessibility, usability, and meaningful participation for all involved.

Facilitated by Wildly Open, we are excited to explore and better understand what is (and isn’t) working, and then build durable models for collaboration and sustainability.

What We Aim to Deliver

• A coordinated sustainability strategy that reflects the shared values of our organisations.
• A funder-facing pitch to mobilise resources in support of this strategy.
• Stronger ties among our organisations that extend beyond the convening, creating lasting impact.

The Bigger Picture

This convening is not an isolated event. It’s the first step in scaling a movement that reimagines how values-driven open science organisations can grow together, share resources, and strengthen the ecosystem we collectively serve. By working together, we can ensure that the future of open science is not only innovative, but also equitable, sustainable, and resilient.

Here’s what’s been happening 👇

💬 Community Shoutouts

Welcome, Philip Narteh!

We’re thrilled to welcome Philip Narteh as pyOpenSci’s very first Open Source Infrastructure Intern, supported by Quansight, Melissa Mendonça, and Tania Allard. Philip will be helping us migrate our website to Django, bringing valuable experience in accessibility within the Django ecosystem. We’re so excited to have you here, Philip!

Contributor milestones

We’ve also had some meaningful leadership transitions happen.

• Tracy Teal completed her term as our founding Executive Council Chair after three transformative years. The Executive Council is the leadership body that guides pyOpenSci’s strategy, governance, and long-term sustainability. You can think of it as the group that helps us make big-picture decisions and ensures our work stays aligned with our mission. Learn more about the Executive Council.
• Karen Cranston has stepped in as our new Executive Council Chair, and April Johnson has joined as a new Council member.

These transitions highlight pyOpenSci’s growing maturity and sustainability as an organization.

We also want to celebrate our editorial team:

• Eliot Robson transitioned into the Editor-in-Chief role for our peer review process.
• Chiara Marmo and Isabel Zimmerman wrapped up their terms as Editors after years of thoughtful reviews and community care. Thank you both!

🎤 SciPy 2025 Highlights

Over 60 people joined our Birds of a Feather (BoF) session to discuss challenges in research software and what community-driven peer review can do to help. It was one of our most energizing community sessions yet!

We also:

• Kicked off the conference with our packaging workshop, introducing folks to our user-friendly template and modern tools like Hatch and UV.
• Welcomed many first-time contributors at our community sprint, with over 30 PRs opened in one day!
• Shared lightning talks, saw Pixi in action, and even got a SciPy Song shoutout.

Big thanks to everyone who contributed to our SciPy presence—especially Jonny Saunders, Avik Basu, Jeremiah Paige, Inessa Pawson, Carol Willing, Tetsuo Koyama, and many others who made our workshop and sprints welcoming and impactful.

📖Read: Highlights from SciPy 2025: Building Community, Code, and Culture

🔍 Peer Review Updates

We’re excited to see continued momentum in our software review process! Right now, 13 packages are actively under review, and another 10 are in prereview (the early stage before formal review begins). You can explore the live review status board anytime to follow along.

🎉 Recently accepted packages include:

• PIVA (August 4, 2025) — A visualization and analysis toolkit for experimental data from Angle-Resolved Photoemission Spectroscopy (ARPES).
• CyNetDiff (August 22, 2025) — A performance-focused library for simulating network diffusion processes using Cython.

A big congratulations to the maintainers of these projects, and a thank you to the reviewers and editors who supported them through the process.

📦 Interested in submitting your own Python package?

👉 Read our guide and submit here

🧠 Community Learning + Behind-the-Scenes

Event Recap: Improving Research Software through Peer Review

On August 7, we partnered with Stanford’s OSPO for a virtual session exploring how pyOpenSci’s peer review model strengthens research software and supports contributor recognition.

New blog updates

If our blog posts feel a little more structured, community-centered, and friendly lately—say hi to our new Communications and Community Lead, Mandy Moore! She’s been working behind the scenes on everything from SEO-friendly image tags to blog polish to social media storytelling.

Bonus: She even learned a little HTML for it. 😉

📖Read: Meet Mandy Moore, pyOpenSci’s new Communications and Community Lead!

📅 Upcoming Events

October 2, 2025 – Create a Python Package: A Hands-On Workshop

This workshop is being held for the Stanford Open Source Program office community through our new membership model. We are excited to host another live online workshop on Spatial Chat, where we’ll walk you through building your first Python package using Hatch, UV, and other modern tools—complete with a ready-to-use GitHub Codespace. (9 AM PT / 10 AM MT)

November 6, 2025 – Create a Python Package: A Hands-On Workshop

It’s not too late to grab a seat in our second Python packaging workshop. Python packaging at your fingertips!

Here, we’ll walk you through building your first Python package using Hatch, UV, and other modern tools—complete with a ready-to-use GitHub Codespace using a custom pyOpenSci template. (9 AM PT / 10 AM MT)

✨ More workshops and events are always in the works—stay tuned via our events page for the latest updates.

🛠️ How You Can Get Involved

• Volunteer with pyOpenSci – from peer review to outreach, we welcome contributors of all kinds.
• Follow us – LinkedIn, Mastodon, Bluesky.

👀 On Our Radar

• We’re working on new policies around the role of generative AI in peer review and open source. It’s a challenging and timely topic, and we’ve opened a GitHub discussion to gather thoughts from the community.
• We’re also developing policies to support review of packages already reviewed by our partner journal, JOSS.
• Curious about next-gen Python packaging? Check out uv, Pixi, and Hatch.
• Keep an eye out for more blogs and contributor spotlights—we’ll be highlighting both technical insights and the people who make this community thrive.

✨ Let’s keep building together.

Until next time,

The pyOpenSci Team 💛