Announcing the Deputy Developer in Residence and the Supporting Developer in Residence

We’re very happy to welcome Petr Viktorin as the Deputy Developer in Residence! Better yet, he is joined by Serhiy Storchaka as the Supporting Developer in Residence. This transforms the residency program into a full blown team! We couldn’t be happier.

It’s exciting to be able to begin to realize the full vision of the Developers in Residence program, with special thanks to Bloomberg for making it possible for us to bring Petr on board. The initial idea behind the Developer in Residence was to have three to five people hired directly by the Python Software Foundation to help with developer efficiency at CPython, where most of the contributors are volunteers. Three to five people is a good amount to allow for handling both day-to-day tasks, as well as planning and executing on larger-scale projects.

We were only able to start with a single Developer in Residence, initially sponsored by Google for the initial year, and by Meta for the following two years. We were clear that adding more developers in residence would multiply the impact of the role but, of course, the big question is funding. Fortunately, the success of the initial one-person program allowed for a new sponsor to participate, interested in extending the program with another developer. Thank you, Bloomberg!

We announced the job opening back in July, and the interview process was extensive. The Foundation received close to 100 applications, and it was a very tough decision, as most were excellent candidates. One surprise in particular was that despite the Deputy role being described as targeting programmers of various experience levels, we received many more applications from Python core developers than during the initial Developer in Residence job opening.

Naturally, the core developers bubbled up in the interview process. We were especially impressed by Petr Viktorin’s experience with maintaining Python at Red Hat, his interest in the C API, and his long-term existing contributions to Python. Given the transformative recent developments inside the interpreter in terms of performance and scalability, Petr’s skillset was the perfect match. We’re excited he accepted the offer!

However, there was one more person who we were also ready to hire on the spot: Serhiy Storchaka, a rare example of a core developer generalist, with plenty of C experience and contributions across the entire codebase. Consistently one of the top most prolific contributors to Python, we felt like we needed to secure him as a member for the Residents team. Unexpectedly, a generous anonymous donation allowed us to hire Serhiy as well. Thank you!

We are calling the role the Supporting Developer in Residence to make it clear the funding level here isn’t as high as in the Deputy case. Please contact us if your organization can help sponsor Serhiy to bump him to the Deputy salary. Serhiy sure deserves it!

After an initial meeting with the Steering Council, the Residents team is now ready to take on a more active role in shaping the development of the language. The Council advised that while every team member is expected to prioritize unblocking other contributors and keeping the developer experience smooth, with three people on the team each Resident can now also spend a percentage of their time on feature work aligned with their interests.

There are some exciting times ahead for Python!

EU’s Cyber Resilience Act Passes with Wins for Open Source

Back in April, we wrote to the community about our concerns for the future of the open source ecosystem generally and CPython and PyPI specifically if the European Cyber Resilience Act (CRA) were to pass in the form that had been shared. At the time, we were worried that in the course of providing software for anyone to use, analyze or change that the PSF and/or the Python community might become legally responsible for security issues in the products that are built with the code components that we are providing for free. We asked for increased clarity, specifically:

“Language that specifically exempts public software repositories that are offered as a public good for the purpose of facilitating collaboration would make things much clearer. We'd also like to see our community, especially the hobbyists, individuals and other under-resourced entities who host packages on free public repositories like PyPI be exempt.”

The good news is that CRA text* changed a lot between the time the open source community – including the PSF – started expressing our concerns and the Act’s final text which was cemented on December 1st. That text introduces the idea of an “open source steward.”

“'open-source software steward’ means any legal person, other than a manufacturer, which has the purpose or objective to systematically provide support on a sustained basis for the development of specific products with digital elements qualifying as free and open-source software that are intended for commercial activities, and ensures the viability of those products;” (p. 76)

Furthermore, the final text demonstrates a crisper understanding of how open source software works and the value it provides to the overall ecosystem of software development.

“More specifically, for the purpose of this Regulation and in relation to the economic operators referred therein, to ensure that there is a clear distinction between the development and the supply phases, the provision of free and open-source software products with digital elements that are not monetised by their manufacturers is not considered a commercial activity.” (p. 10)

So are we totally done paying attention to European legislation? Ah, while it would be nice for the Python community to be able to cross a few things off our to-do list, that’s not quite how it works. Firstly, the concept of an “open source steward” is a brand new idea in European law. So, we will be monitoring the conversation as this new concept is implemented or interacts with other bits of European law to make sure that the understanding continues to reflect the intent and the realities of open source development. Secondly, there are some other pieces of legislation in the works that may also impact the Python ecosystem so we will be watching the Product Liability Directive and keeping up with the discussion around standard-essential patents to make sure that the effects on Python and open source development are intentional (and hopefully benevolent, or at least benign.) 

Thank you to Open Forum Europe (OFE) — especially Ciarán O’Riordan – for bringing the FOSS community together to share our thoughts on how the proposed text would affect open source, thinking about how the goals of the proposed act might be achieved without unintentionally creating a chilling effect for open source and communicating those ideas to legislators. OFE’s work to coordinate our efforts certainly made it easier for the PSF’s concerns to be heard and I’m fairly certain it made it easier for legislators to assess and consider impacts to the open source ecosystem when we were able to speak with one voice. 

*The entire Regulation is published here, if you want to dive into the text more deeply.