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 💛

• When: Thursday, 6 November 2025 10:00 AM Mountain Time - 12:15 PM Mountain Time
• Where: Interactive webinar with live demos

Cost

Prices are in US Dollars. This workshop not only provides you with expert training, but it also supports the work that pyOpenSci does to support scientific open source.

Register Now on Eventbrite

Your research code deserves to reach more people. In this hands-on workshop, you’ll learn how to transform your Python scripts into professional packages that others can easily install, use, and contribute to. Walk away with a complete packaging workflow and the confidence to share your work with the world.

This workshop is part of pyOpenSci’s commitment to building better research software through accessible packaging practices. Whether you’re sharing analysis tools with colleagues or building the next great Python library, you’ll gain practical skills to package like a pro.

Workshop Structure

Part 1: Modern Python packaging foundations (30 minutes)

• Package Structure: Set up your project the right way from day one
• Essential Files Walkthrough: pyproject.toml, README, and what actually matters
• Tool Decision Framework: Navigate the packaging ecosystem with confidence

Part 2: Build your Python package (30 minutes)

• Live Build Demo: See packaging in action with real code
• Setup Tests: Make sure your package works everywhere and as new pull requests come in
• Quality Checklist: Professional packaging standards made simple

Break (10 minutes)

Part 3: Publish and share your Python package (30 minutes)

• PyPI Publishing: Get your package on the Python Package Index
• Security Best Practices: Protect your package and users when you are publishing using Trusted Publishing.
• Automation Setup: Never manually release your package again; instead use GitHub actions with trusted publishing.

Part 4: Documentation for a healthy project (20 minutes)

• What docs matter most?: A brief overview of documentation to make it easier to onboard both contributors and new maintainers to your project.

Wrap up: Questions (20 Minutes)

• Q&A: Get your questions answered

Why attend

• Learn modern packaging practices used by successful Python projects
• Get production-ready templates and automation you can use immediately
• Understand publishing security best practices from day one
• See live demos of the complete packaging workflow
• Learn from pyOpenSci’s experience reviewing dozens of packages

Perfect for you if…

• You have Python code that others could benefit from using
• You’re tired of sharing code via email or messy file transfers
• You want people to be able to install and use your tools
• You’ve heard of PyPI but don’t know how to get your package there and how to do it securely.
• You want to better understand the complex Python packaging ecosystem

What you’ll walk away with

• Complete Package Template: Ready-to-use project structure
• Automation Workflows: GitHub Actions for testing and publishing
• Quality Checklists: Never miss important packaging steps
• Publishing Guide: Step-by-step instructions for secure PyPI deployment using GitHub actions

Pre-requisites

To successfully follow along in this workshop, you should:

• Know how to write Python code
• Understand how to write and use functions
• Have a Free account to create a GitHub account (you can work using GitHub codespaces during this workshop, and setting this account up is free if you don’t already have one.
• You should have internet access

Your instructors & helpers

• Leah Wasser, the Executive Director and Founder of pyOpenSci, brings over 20 years of experience teaching technical data science topics in the scientific space. pyOpenSci has worked with hundreds of scientific Python package maintainers and has helped over 50 packages improve their structure and distribution through our peer review process.
• Jeremiah Paige: is an open source author, contributor, and speaker, specifically working with Python for over 12 years. He is also a software engineer in the secure supply chain industry during work hours.
• Avik Basu: is an open source contributor, speaker, and mentor. He is a seasoned machine learning engineer with extensive experience in both major tech companies and fast-moving startups.

• When: Thursday, 2 October @ 10:00 AM Mountain Time // 9:00AM Pacific Time
• Where: We will use the Spatial Chat platform to create a classroom-like learning experience.

This event, hosted in partnership with Stanford’s Open Source Program Office, teaches participants best practices for packaging their Python code. You will learn how to build more reliable research tools and software development skills.

Setup instructions

You can choose to work on your own machine during the workshop or use the GitHub Codespace we’ve set up for you. Codespaces include all the tools needed to create your first package—preinstalled and ready to go.

We encourage you to use GitHub Codespaces! If you prefer to install things locally, please do so before the workshop.

1. Make sure you have a GitHub and Test PyPI account

Before the workshop, please create and log into the following accounts:

1. Create a free GitHub account if you don’t already have one.
2. Create a free account on Test PyPI — we’ll use this to practice publishing packages.

Important: To follow along when we publish to Test PyPI, you must enable two-factor authentication (2FA) on your Test PyPI account. We strongly recommend doing this before the workshop!

2a. Setup for working locally on your laptop

We recommend using GitHub Codespaces (see next section) to avoid issues with environment setup. However, if you prefer to work locally, please ensure your environment is set up and ready before the workshop.

If you’re comfortable with Python environments, arrive with an environment that has:

• Hatch installed
• Copier installed
  • You can install both via pipx, uv, pixi, or any preferred package manager.
• VS Code (or any IDE you prefer for packaging)

Note:

• We strongly suggest that you visit GitHub.com and Fork our packaging workshop repository in case any issues arise with your local installation. This will ensure that you can follow along with us regardless of your environment setup.
• JupyterLab or Jupyter Notebook is not ideal for the packaging work we’ll be doing.

2b. If you plan to use GitHub Codespaces (SUGGESTED)

We strongly recommend using our curated GitHub Codespace, which can be found in your forked workshop repository. This workspace is already set up with:

• VSCode, copier, Hatch, and everything you need to create your first Python package successfully. Codespaces also allows you to easily commit your work during the workshop to your own forked GitHub repository.

Before the workshop do the following

• Go to GitHub.com and Fork our Python package workshop repository

• Launch the codespace before the workshop:

The initial spin-up for a codespace can take up to 15 minutes or longer. Once GitHub creates the cloud environment, it will be quicker to relaunch. Please do this before attending the workshop session.

To open your Codespace,

• Go to your forked workshop repository on GitHub,
• Switch to a branch that you want to work on during the workshop,
• Click the code drop-down button (where you’d find a link to clone a repo)
• Click on the Codespaces tab in the drop-down.

Within the Codespaces tab you will see a button: Create codespace on main . This button launches a Codespace from the currently active branch. It will default to the main branch if you haven’t changed your branch in the repository.

The animated gif below walks you through how this works.

To follow GitHub best practices, always create a new branch before making changes to a repository, even if you own the repository. Avoid working directly on the main branch.

About GitHub Codespaces: Working in the cloud

What is a codespace

GitHub Codespaces are cloud-based development environments that let you code directly in your browser—no local setup needed. They provide fully configured, container-based environments connected to your GitHub repository.

You can customize Codespaces with .devcontainer files to match your development setup. The Codespace for this workshop opens in Visual Studio Code by default, but you can configure it to use any IDE you prefer.

Learn more in the GitHub Codespaces docs.

Codespaces are free for up to 60 hours/month on GitHub’s free plan. Be sure to shut yours down after the workshop to conserve your allocated time.

Codespaces are associated with your personal GitHub account, even if you open one from the pyOpenSci repository. The usage counts toward your own GitHub credits.

View & manage open codespaces

Once you’ve opened a Codespace, you can return to it later without needing to start from scratch. GitHub will reuse the environment, making it launch significantly faster the second time.

If possible, resume the same Codespace you started in, rather than creating a new one in your fork. Read on to learn how to find and reopen a codespace.

View all active Codespaces associated with your account

When you delete a Codespace, you’re ending the session, but the configuration remains available so you can launch a new one anytime. Learn more in the GitHub docs

How to relaunch a codespace

To relaunch a Codespace:

1. Go to your fork of the workshop repository.
2. Click the Code dropdown (same as when you first created the Codespace).
3. Select the Codespaces tab to view existing environments.
4. Select the codespace that you want to resume from the list (see image below).

As you can see in the animated gif below, GitHub codespaces always have fun names.

As founding Executive Council Chair Tracy Teal transitions from her leadership role after three transformative years, we’re excited to welcome Karen Cranston as our new Executive Council Chair and April Johnson as a new Executive Council member. This transition represents not just changing leadership, but the successful maturation of pyOpenSci as an organization.

From grassroots vision to established organization

pyOpenSci began in 2018 as a passion project born from engagement in the Python, open source community. As a volunteer who deeply cared about scientific open source software, I saw numerous pain points in how the Python scientific community approached software quality and sustainability. We brought together a small group of like-minded open source leaders to pilot what peer review of scientific Python software could look like—creating something that didn’t exist but was clearly needed.

Five years later, our grassroots effort had evolved into something much larger. In 2022, with Sloan Foundation funding secured, we transitioned to fiscal sponsorship under the 501(c)(3) fiscal host, Community Initiatives, establishing pyOpenSci as an independent, fiscally-sponsored project. This transition marked our transformation from a purely volunteer-driven initiative to a structured organization with formal governance, funding, and accountability structures.

Building strong governance: The Executive Council’s role

The pyOpenSci Executive Council was founded in 2022 as the cornerstone of our governance structure. The Council provides strategic oversight, organizational guidance, and accountability while serving as ambassadors for our mission and as a support system for our Executive Director. Working alongside our Advisory Council, which offers domain-specific expertise, this governance structure has been instrumental in our steady growth.

Three years of shared accomplishments

Under Tracy’s leadership as our founding Executive Council (EC) Chair, the EC has achieved remarkable milestones over the past three years. Together, we:

• Established our foundational identity: Crafted a powerful mission while directing the vision and values of our organization that guide our work together.
• Built robust governance structures: Created transparent decision-making processes and accountability mechanisms.
• Fostered a healthier and inclusive community: Implemented a comprehensive code of conduct with clear procedures that support inclusive community engagement.
• Secured sustainable funding: We have also secured over $1,000,000 in funding while building relationships for future support.

These achievements reflect the successful synergy between Executive Council members who brought diverse expertise in nonprofit management, open source communities, and scientific software development to guide our strategic direction.

Celebrating transition: a sign of success

Three years into our journey as an independent organization, this Executive Council transition marks a milestone we’re celebrating as a symbol of organizational maturity and success.

Tracy’s non profit leadership experience, strategic vision and steady guidance have been foundational to everything we’ve accomplished—from establishing our governance structures to guiding us through the critical early years of organizational development. As she transitions from her EC Chair role, we’re deeply grateful for the strong foundation she’s helped build.

Karen Cranston will continue to serve on the pyOpenSci leadership team, moving into the role of EC Chair. Karen brings extensive experience in open science, having served in leadership roles at organizations such as The Carpentries and the Open Bioinformatics Foundation that bridge community, research and data science. Karen’s deep understanding of both the scientific community and organizational development makes her ideally suited to guide pyOpenSci through our next phase of growth.

We’re also thrilled to welcome April Johnson to our Executive Council. April brings invaluable expertise as a technology executive and consultant to humanities and civil rights nonprofits, most recently as People Lead at 2i2c and as Board Chair for He She Ze & We. Her experience in organizational development and people-centered leadership will be crucial as we continue to scale our community, work on sustainability, and impact.

What this maturity enables

This successful transition demonstrates that pyOpenSci has evolved into a growing, sustainable organization. Succession is success as it demonstrates that we’ve built something larger than any individual contributor—with proven governance structures, institutional knowledge, and a thriving community that transcends leadership changes.

As we move forward under Karen and April’s guidance, we’re excited about our next chapter. This includes a strategic focus on sustainability—thoughtfully considering how we generate revenue as an organization, and ways we can scale that also support long-term sustainability. We’re also exploring deeper collaborations with aligned communities like rOpenSci, PREreview, The Carpentries, and Open Life Science.

This transition positions us to take on bigger challenges, expand our impact on the scientific Python ecosystem, and continue building the future of open scientific software. We can’t wait to see what comes next!