Agata Skamruk: 2026 PSF Board Election Candidate Interview

Who are you?

Hi! My name is Agata Skamruk, and I've been deeply involved in the Polish and international tech community for years. Based in Gdańsk, I combine my passion for programming with education, IT event organizing, and fostering an open, inclusive environment for developers.

What I Do:

• Education & Teaching: I work as an IT and programming teacher at Zespół Szkół Chłodniczych i Elektronicznych in Gdynia. I also create programming recruitment assessments and help students comfortably grasp core concepts in mathematics, physics, and computer science.
• Python Community: My main ecosystem of choice is Python. I previously served as President of the Polish Python User Group (PLPUG), co-organized PyLadies Poland, and founded regional communities such as PyKosz and PyLadies Trójmiasto.
• IT Events: I am the founder and lead organizer of the PyCode Conference, and I've co-organized major events including PyCon PL, PyData Warsaw, and EuroPython over the years. In 2026, I had the honor of running as a candidate for the Python Software Foundation (PSF) Board of Directors.
• Tech & Media: I manage OSWorld.pl—an open-source technology news platform—and head Code Squat as CEO. My project and research work also covers natural language processing (NLP) and machine learning.

I bridge the gap between software development, technical education, and diversity advocacy for women in tech.

What would you bring to the PSF Board of Directors?

Running for the Python Software Foundation Board of Directors, my focus centers on strengthening community accessibility, expanding technical education, and building sustainable, diverse local ecosystems globally.

Core Qualifications & Vision:

• Community Leadership & Governance: Former President of the Polish Python User Group (PLPUG) and founder of PyKosz and PyLadies Trójmiasto. Organizer for major events including EuroPython, PyCon PL, PyData Warsaw, and PyCode Conference. I bring a practical understanding of non-profit operations and volunteer support.
• Education & Workforce Development: As a Computer Science educator, I have direct insight into entry-level programming education. Experienced in designing recruitment assessments and curricula, I bridge community learning with industry standards through hands-on mentorship.
• Diversity, Equity & Inclusion (DEI): Leadership in PyLadies Poland and Women in Technology, creating inclusive spaces for women and underrepresented groups. I advocate for regional access, grants, and support for emerging global Python communities.
• Practical Engineering & Open Source: Combining software engineering experience (Python, Django, Flask) with open-source advocacy (OSWorld.pl), I align high-level Board decisions with the real-world needs of developers.

What motivated you to run for the PSF Board of Directors?

I would like to collaborate in these groups because they combine all the key areas to which I have dedicated my energy within the local and global Python community for years. 

Working in the Code of Conduct and Diversity and Inclusion groups allows me to ensure safety, openness, and equal opportunities for everyone, which is the foundation of a healthy community. 

At the same time, engaging in Education & Outreach and Grants gives me the opportunity to directly support education, share my teaching experience on a broader scale, and strategically back initiatives and local leaders through financial support. 

Acting across these structures is a chance for me to comprehensively develop the Python ecosystem—from attracting and educating new talents and maintaining high ethical standards, to having a real impact on how the community grows worldwide.

What problem or challenge do you want to address if you are on the board?

The Challenge: Gender Imbalance at Python Conferences
The low representation of women among speakers and attendees remains a critical issue. This stems from a high barrier to entry, a lack of visible role models, and the vicious cycle of low CfP submissions from women, which reinforces the perception of a male-dominated field.

My Commitment on the PSF Board
Leveraging my experience leading PyLadies Poland and Women in Technology, I will actively drive changes to solve this:

• Targeted CfP Outreach: I will implement proactive recruitment and mentorship programs to help women prepare talk proposals, building their confidence to step on stage.
• Building Inclusive Local Spaces: I will support community initiatives that provide safe, growth-fostering environments for first-time speakers and emerging tech leaders.
• Enforcing Safety Standards: I will collaborate on standardizing and enforcing robust Codes of Conduct and anti-discrimination procedures across all PSF-funded events.

By breaking down entry barriers and establishing plug-and-play safety tools, I will help ensure our stage representation reflects the true diversity of our global ecosystem.

Where do you see the PSF 5 years from now?

Consistent implementation of anti-discrimination procedures and diversity systems will drive a profound transformation. Here is how I see the role of the PSF and the future of our community over the next five years:

• Natural Diversity on Stage: I envision conferences where proactive speaker recruitment and blind CfP reviews are standard practice. Moving toward gender balance will bring fresh technical perspectives and attract a broader audience.
• Plug-and-Play Safety Standards: I want safety procedures embedded into the DNA of every PSF-supported event. Proven CoC templates and trained Response Teams will lower incident rates, making ours the safest community in tech.
• Rise of Women Leaders and Technical Authorities: By championing mentorship programs and expanding initiatives like PyLadies, I will help women and underrepresented groups step into decision-making and technical leadership roles making visible role models in open source and boards completely natural.
• Maturity Built on Global-Local Collaboration: I see close cooperation between local groups and the PSF to build scalable best practices. We will make the Python ecosystem a global benchmark, proving that inclusivity and top-tier technical quality go hand in hand.

What areas of the Python community are you involved with?

Here is an overview of my key areas of involvement, leadership, and community-building within the Python ecosystem:

National Leadership & Governance

• Polish Python User Group (PLPUG): Served as President (now former President) and active board member, helping steer the formal organization of the Polish Python community.
• Python Software Foundation (PSF): Active contributor and board election candidate, aligning local Polish initiatives with global Python standards and safety policies.

Conferences & Major Events

• PyCode Conference: Founder and main organizer of this prominent conference dedicated to the Python community, focusing on advancing technical skills, sharing best practices, and driving diversity.
• PyCon PL: Co-organizer of early landmark editions (PyCon PL 2015 and 2016).
• International Involvement: Program committee contributions for global events like PyData Global and PyCon US, as well as co-organizing efforts surrounding major European milestones like EuroPython.

Diversity, Inclusion & Local Chapter Building

• PyLadies Poland & Regional Hubs: Instrumental in founding and driving local initiatives—including establishing PyLadies Trójmiasto and founding PyKosz (Koszalin Python User Group)—to foster inclusive spaces for underrepresented groups in tech.
• Cross-Community Collaboration: Partnering with broader networks like Women in Technology to advocate for inclusive cultures and support new developers entering the industry.

 ------

Note from the election administrators: 

Want to learn more about this candidate or ask them a question? 

Check out their nomination statement.

Check out their AMA thread on discuss.python.org.

How AWS Powers PyPI and the PSF

Written by Jacob Coffee, Director of Engineering at the Python Software Foundation

Working on infrastructure at the Python Software Foundation (PSF) as the Director of Engineering is a broad job with many hats. Python turns up everywhere. It's in healthcare systems and government agencies, in research labs and classrooms, in one-person side projects and in infrastructure at companies with six-figure headcounts. Somebody is using it to analyze a genome right now and somebody else is using it to automate a spreadsheet they hate arranging by hand. That range has always been the interesting part of the PSF's work, and it's only broadened in the last couple of years as AI continues to pull people from many disciplines into writing Python.

At the PSF we support and maintain the infrastructure behind PyPI, Python.org, PyCon US, CPython, and a growing number of community services. The majority of the PSF's infrastructure runs on AWS, and nearly all of that bill is covered by credits from the AWS Open Source Credits Program.

The shape of it

PyPI takes over six billion requests a day and about thirteen billion counting file downloads. Package egress runs around 10 petabytes a day.

Almost none of that reaches AWS. Fastly serves it at the edge through their Fast Forward program at a hit ratio just under 99%, so only about one request in seventy makes it to origin. That caching is the core reason our AWS bill is not measured in the millions of dollars a year.

What does reach us is the part that is not cached, including things like user uploads, logins, and account management. That work runs on:

• Amazon EC2 for the application fleet, almost entirely Graviton at this point. We're huge fans of Arm-based hardware at the PSF!
• Amazon RDS for the Postgres database behind Warehouse, which is the application you're looking at when you're on pypi.org.
• Amazon OpenSearch Service for project search.
• Amazon S3 holds ~100 TB of package archives, plus the release history (that nobody ever wants to need).
• Amazon EKS, newly stood up, as the target for migrating the whole fleet.

What changed this year

Our AWS spend is up about 69% comparing July 2026 to July 2025, and 40% across the trailing twelve months. That's new.

For context on how new: last October, Ee Durbin, our former Director of Infrastructure, noted that PSF's AWS credit usage had grown 25% over eight years while daily requests went from millions to billions. Eight years of holding that line. 2026 is the first year it broke.

Some of it is simply more of everything. Compute, search, and load balancing all climbed from 30% to 80%, which is the profile of more people and machines using the service. There are certainly more of both. A lot more Python being written, a lot more agents installing packages on someone's behalf, and a lot more CI runs from all the projects those people and agents are creating. Package repositories were designed around the assumption that a human decides to run pip install some number of times a day. That assumption is well past its expiration.

What we do about it

At the PSF, we take the credits seriously, which means spending real engineering time on utilizing what we have in an optimal way so our usage doesn't increase. Being frugal with the credits entrusted to us is vital.

When a widely used GitHub Action makes requests it doesn't need to make, fixing the Action beats anything we can do on our side. A popular Action can quietly turn a cache hit into a fresh download from PyPI on every run, and that adds up fast across thousands of CI pipelines. astral-sh/setup-uv shipped exactly that kind of fix.

On the PSF side, the EKS migration is the big one. Once we're there, autoscaling lets capacity track demand instead of sitting provisioned for peak at 3 AM (San Francisco time) on a Sunday.

There's just one little (read: major) constraint: Ee left the PSF earlier this year, and I'm currently the only person here working full time on infrastructure. Every item on that list is real and every one is slower than it should be. The PSF is hiring, and that hiring is possible in part because we aren't spending the same money on servers.

That said, hiring has a ceiling set by funding, and the growing gap between the demand placed on PyPI relative to staff operating and securing the service represents a risk to Python packaging. There is a very large amount of the software industry that sits on top of our services. Feature development, a rising volume of security reports, and day to day maintenance are currently being carried by one and a half full-time employees and one full-time employee on PyPI support requests. If your company installs from PyPI, ask internally about what your organization would be willing to fund. That question can be worth much more coming from inside a company than from the PSF. If you are interested in securing a service agreement with PyPI, please fill out our survey.

What the funding actually bought

AWS has backed PyPI two different ways, and both are worth outlining.

A very exciting investment was made in 2023, when AWS became PyPI's inaugural Security Sponsor, putting $144,000 into creating the PyPI Safety & Security Engineer role. That role is now funded by Alpha-Omega, and it's the reason malware comes down off PyPI in hours instead of whenever a volunteer has a spare moment. This investment also followed a pattern AWS had already established, having helped fund the rewrite, internationalization, and 2FA support for PyPI.

The credits do something quieter. They hold the infrastructure bill near zero, which means the PSF's general fund goes to employees, PyCon US, and other operational costs instead of servers. That's what pays for support staff handling the account recovery and project ownership requests that arrive every single day, and what makes it possible to ship things like Trusted Publishing, digital attestations, and organization accounts, instead of just keeping the lights on.

PyPI is free to use and will stay free to use at reasonable levels. Core publishing and installing stay free, permanently. What we are doing is building out real benefits for Organization accounts, and looking at sensible rate limits for the heaviest consumers at the top of the curve.

Which is exactly why in-kind support isn't just a line item to us. A sponsor choosing not to renew would mean an emergency migration or tens of thousands of dollars a month, either of which comes straight out of the work above. AWS has renewed every year since 2018, and the predictability of that is worth as much as the amount. The same goes for Fastly, Google Cloud, Datadog, Sentry, Depot, and PagerDuty, who carry other parts of this mountain of infrastructure.

How you can help

Four things, in order of how much they matter:

1. Cache your installs. If your CI pulls from PyPI on every run with a cold cache, you're a meaningful part of the graph. The PSF uses Docker cache mounts and pip's cache on our own builds, and npm and apt caching too, because it's faster for us and cheaper for everyone. Free package repositories aren't a limitless resource, and the fix is usually about six lines of config.
2. Sign up for a PyPI Organization if your company publishes to PyPI. Recurring revenue from Organizations is the most sustainable funding base we have, and Community organizations remain free. Look forward to announcements about future features for PyPI organization accounts soon.
3. Interested in a PyPI service agreement? Enhanced options like annual bulk seat purchases, higher project size limits, and prioritized support are available. The revenue helps fund the broader PyPI ecosystem while giving your organization benefits at scale. Fill out our service agreement interest survey and we'll follow up.
4. Ask your infrastructure vendors for multi-year commitments with open source foundations. Annual renewal cycles carry real risk for projects like ours. The five-year agreement the PSF signed with Fastly in 2024 is a sustainable model, and we'd like more of them.

The open letter the PSF co-signed last year called this a critical inflection point rather than a crisis. A year on, with our first real break in eight years of flat infrastructure costs, that still reads about right.

A big thanks to Mila Zhou and the AWS Open Source team, who have made the credits process about as painless as an annual funding renewal can be, and to everyone at AWS who's kept this program going for so long. PyPI would look very different without it.

This blog was recently edited to more accurately reflect numbers presented and work done.