Thursday, May 11, 2023

PSF Board Election Dates for 2023

Board elections are a chance for the community to choose representatives to help the PSF create a vision for and build the future of the Python community. This year there are 4 seats open on the PSF board. You can see who is on the board currently here. (Dustin Ingram, Jeff Triplett, Nina Zakharenko and Thomas Wouters are at the end of their current terms.)

Timeline:

  • Nominations are open, Thursday, June 1st, 2:00 pm UTC
  • Board Director Nomination cut-off: Thursday, June 15, 11:59 pm UTC
  • Voter application cut-off date: Thursday, June 15, 11:59 pm UTC
  • Announce candidates: Friday, June 16th
  • Voting start date: Tuesday, June 20, 2:00 pm UTC
  • Voting end date: Friday, June 30, 11:59 pm UTC

You will need to be a contributing, managing, supporting, or fellow member by June 15th to vote in this election. Learn more about membership here or if you have questions about membership or nominations please email psf-elections@python.org

Who runs for the board? People that care about the Python community, who want to see it flourish and grow and also have a few hours a month to attend regular meetings, serve on committees, participate in conversations and promote the Python community. You can learn more about what the PSF board does here.

You can nominate yourself or someone else, but no one will be forced to run, so you may want to consider reaching out to someone before nominating them. Nominations open on June 1st, so you have a few weeks to research the role and craft a nomination statement.

You are welcome to join the discussion about the PSF Board election on our forum or come find us in Slack. This year we’ll also be running office hours in Telegraph to answer questions about running for the board and serving on the board. Those will be announced soon!

Friday, May 05, 2023

All-Python Humble Bundle out now from No Starch Press!

 

Have you been thinking about diving into a new topic in Python, or maybe just getting started? Here's a chance to get a whole batch of great Python books in a sweet deal, and help the PSF while you're at it!

 No Starch Press, an indie tech-book publisher and Partner sponsor of the PSF,  just announced a partnership with Humble Bundle that lets you pay what you want for all-Python DRM-free ebook titles for Python beginners to pros. And a share of the proceeds from the bundle goes to the PSF! The “Python, by No Starch Press” bundle runs now through May 22nd.

The bundle includes a curated selection of titles for all levels like Python Crash Course (Eric Matthes), Automate the Boring Stuff with Python (Al Sweigart), Make Python Talk (Mark Liu), and Learn to Code by Solving Problems (Daniel Zingaro). 

The promotion has a pay-what-you-want model, so you can choose your preferred pricing tier. Pricing starts at $1 for Mission Python - Code a Space Adventure Game! (Sean McManus) + Invent Your Own Computer Games With Python (Al Sweigart), or starting at $36 you can get all 18 Python ebooks!

Check it out and happy reading🐍📚

Thursday, April 13, 2023

Thank You for Many Years of Service, Van!

We are wishing farewell to Van Lindberg after 16 years of service to the PSF, who has decided to step down from his Board Director and General Counsel roles. He helped us grow from a small volunteer organization with no staff, to an organization with 9 staff members that supports the whole Python ecosystem and its global community. He has served on our board for 11 years, as Chair of the PyCon US committee for 3 years before that and most recently as the PSF’s General Counsel for 7 years.

For many years, Van has steered our IP policies as an open source project. He worked to make sure our trademark, license and contributor agreement policies kept pace with the evolving open source landscape. He has advised countless members of the PSF community on how to work with our licenses and how to properly think about trademarks, patents, cryptocurrency and much more.

Van served first as an elected board member and then later as an appointed board member. Less formally, Van has been an enthusiastic presence at many, many PyCons and a steadying presence for our volunteer Trademarks working group. He has spoken at many open source events sharing his experience as a Pythonista and the expertise gained at the other open source communities he is a participant in.

The PSF’s Board Chair Thomas Wouters said, “It's hard to imagine where the PSF would be today if it hadn't been for Van's experience, insight and strategic vision. He has been fundamental to the professionalisation of the Foundation and its Board of Directors, and a driving force behind the PSF's sustainability efforts, policies and of course legal direction. He is both a shining example of volunteer effort and a great mentor to many Board and staff members. I'm very grateful for the many years of service and dedication he gave to the PSF, and we're all the better for it.”

We wish Van all the best in his future non-PSF open source work on OSPOCO and as a well-respected voice in the many open source legal conversations he participates in. Thanks again!

Tuesday, April 11, 2023

The EU's Proposed CRA Law May Have Unintended Consequences for the Python Ecosystem

After reviewing the proposed Cyber Resilience Act and Product Liability Act, the PSF has found issues that put the mission of our organization and the health of the open-source software community at risk. While we support the stated goals of these policies of increasing security and accountability for European software consumers, we are concerned that overly broad policies will unintentionally harm the users they are intended to protect. We feel that it is important to consider the role vendor-neutral nonprofit organizations—especially public software repositories—play in the modern development of software. 

Many modern software companies rely on open-source software from public repositories without notifying the author, and certainly without entering into any kind of commercial or contractual relationship with them. If the proposed law is enforced as currently written, the authors of open-source components might bear legal and financial responsibility for the way their components are applied in someone else’s commercial product. The existing language makes no differentiation between independent authors who have never been paid for the supply of software and corporate tech behemoths selling products in exchange for payments from end-users. We believe that increased liability should be carefully assigned to the entity that has entered into an agreement with the consumer. We join our European open source colleagues at the Eclipse Foundation and NLnet Labs in voicing our concerns over how these policies could affect global open source projects.

Why does the Python Software Foundation care about CRA?


The Python Software Foundation (PSF) is a nonprofit charitable organization that exists to promote, protect, and advance the Python programming language, a cornerstone of the modern technology sector. We are based in the US, but for more than 20 years we have served a global open source community of students, teachers, entrepreneurs, academics, scientists, artists, public sector workers, hobbyists and commercial software developers. The PSF does not sell software, but we provide a public square for developers to download code and talk about code, and we host components that other entities may include in their products. We facilitate technical discussions for the ecosystem generally and support many educational opportunities for the worldwide community of Python developers.

We do many other things in the service of our charitable mission, but there are two activities that could be affected by the CRA:

1) We host and provide the core Python programming language, standard library and interpreter to any who wish to use it free of charge. It may be downloaded from our website, and a version of Python is downloaded over 300 million times per day.

2) We host the Python Packaging Index (PyPI), a vast library of software packages, written by thousands of different entities and individuals, that is made available in a single place where all packages are public and freely available. PyPI is critical infrastructure for the entire ecosystem, and thousands of individuals and enterprises depend on it, downloading 10 billion packages in an average month.


To be absolutely clear, nobody pays us for software, either for the core language or any of the packages that you can download from the repository we maintain. At first glance, that might lead one to believe that there is no money being made with Python or Python packages. In fact the reverse is true: a large number of people who build things with Python, analyze data with Python or create AI models with Python are doing so at a commercial company, academic institution or government agency that pays them to work there, and in fact a not-insignificant share of the profit-generating tech economy relies in some part on Python. For instance, many well known applications including YouTube, Instagram and Spotify are all built using Python code.

Hosting Python and Third-party Python Software in the Open is a Public Good

We host a lot of software that is used in commercial applications and nearly everyone—except the PSF itself—is making a lot of money selling products that use Python code and libraries. We host that software so that it can be examined by anyone for flaws or bugs. We also host that software so that it can be used to teach new coders and the next generation of tech pioneers. Any policy that does not provide clear carve outs for repositories offered for the public good will do irreparable harm to the individual’s accessibility to the power of modern software development.

We’re concerned that some of the current proposed policy language doesn’t make things clear enough for an ecosystem like Python’s. Under the current language, the PSF could potentially be financially liable for any product that includes Python code, while never having received any monetary gain from any of these products. The risk of huge potential costs would make it impossible in practice for us to continue to provide Python and PyPI to the European public. Certainly, everyone wants security, for consumers to have reasonable assurances, and for the software industry to be accountable to its customers. However, it is critical that those assurances are expected from the correct entity and that the legal burden for any lapse in accountability is levied against the correct entity. Many of the software elements that end up in commercial software or hardware products come from publicly available open source repositories like PyPI where no compensation is given. Open source languages and repositories shouldn’t be thanked for the public services they freely provide with an open-ended risk of ruinously costly legal action. The PSF should not be liable for every application or device that happens to contain some Python code.

Assigning liability to every upstream developer would create less security, not more. Leaving individual and/or under-resourced developers in a legally murky position when contributing to public repositories like the Python Package Index would almost certainly create a chilling effect for them. Only entities who are selling enough software or software/hardware combinations to absorb the ramifications of product liability could continue to operate in the open. The user improvements and shared security benefits of global software collaboration would only be accessible to those developers working on behalf of a few large companies. Growth and innovation would be stifled. The security of languages like Python depends on the continued availability of a neutral, non-commercial entity that can act as a clearinghouse for new software, improvements, and bug fixes that can be shared freely by the entire software community.

Increased Clarity is Needed

Rather than following the code all the way upstream, we would prefer to see policy makers follow the money. Many components are not a product by themselves and it is a mistake to risk any shift of financial burden from the entity that compiles and sells a product to the open source developer that they received a free bit of code from. All coders should be working towards a world of greater security for end-users, but no one developer can imagine all the ways in which an individual open source component will be used and combined with other components for consumer use. Consumer liability and responsibility cannot be assigned until a product is assembled and something is for sale.

In particular, we believe that there are two phrases in the CRA that cast too wide of a net. In Article 16, “A natural or legal person, other than the manufacturer, the importer or the distributor, that carries out a substantial modification of the product with digital elements shall be considered a manufacturer for the purposes of this Regulation.” is too broad. Open source is full of people who make a substantial modification to a piece of public code but do not have any contractual or financial relationship with the entity or entities that might eventually use that code in a commercial product. Secondly, in Recital 10, the phrase “…by providing a software platform through which the manufacturer monetises other services.” is not specific enough. Public code repositories and their hosts may offer paid classes or sell tickets to conferences about shared open source code while still having no control over the way commercial entities use that code in their products. Disincentivizing educational activities or curtailing public patches from third parties will not make European software consumers safer.

The existing, publicly available open source ecosystem already provides robust and evolving security mechanisms where we share news about where individual components should be used and more importantly how they shouldn’t be used. When a flaw is discovered in a popular piece of software, we publicize patches and get potential vulnerabilities addressed across hundreds of products and tools. Chilling participation in these processes makes us more vulnerable, not less.

Conclusion

We need it to be crystal clear who is on the hook for both the assurances and the accountability that software consumers deserve. 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. We believe these exemptions would help both consumers and the open source ecosystem, as well as the economic actors who depend on it. We hope that policy makers in the European Union will carefully consider complex and vital ecosystems like Python when drafting landmark policies that affect open-source software development.

PSF members and Python users in Europe may wish to write to their MEP voicing their concerns about the proposed CRA law before April 26th, while amendments that will protect public open source repositories are still being considered.

Thursday, March 23, 2023

Protecting the Python Trademarks

Who is the Trademarks Working Group?

The Python Software Foundation Trademarks Working Group was created by the PSF Board of Directors to  monitor and authorize (or prohibit) use of trademarks held by the PSF.  The WG—initially dubbed committee—was created in 2008, and has been co-chaired by me since 2010, adding Marc-André Lemburg in 2013.  We've had a variety of other members over the years, with Iqbal Abdullah being a wonderful and helpful member of the WG for the last couple years.

You can write to us any time at on the Trademarks WG mailing list.  If you ever want to use one of our marks, please do write to us.  Even for those uses that are completely non-contentious, we'd rather quickly approve them and have a record in the mailing list archives than just not know about the use (the archive is not public, however, since legal issues, even potential litigation, are sometimes discussed).

We would welcome participation by more Python community members (being a PSF member is not strictly required, just an interest in helping Python maintain its branding).  Helping with the working group is a pretty small time commitment, but as with many volunteer efforts, folks often drift away from such efforts over the course of years.  By all means contact us if you have an interest in trademarks and an hour or two a week to spend helping us in these discussions.


Our Goals


The PSF holds registered trademarks in a large number of jurisdictions—incrementally increasing in number over the years—and "use trademarks" worldwide.  Obviously, legal regimes around intellectual property, and trademarks specifically, vary somewhat around the world; for the most part trademarks serve a similar purpose everywhere though.

We don't want the brand and reputation of Python to be used in a deceptive manner. However, Python being free and open source software (FOSS), and the PSF being devoted to such freedom, the licensing policy adopted by the PSF is very liberal and serves the purpose of promoting the use and knowledge of Python rather than trying to obtain commercial advantage (as many for-profit product marks are used).

Let's go back to what marks the PSF maintains.  The name "Python" is a wordmark that is registered in many places.  Nominative use of the name is always permitted when it is used to describe the Python programming language. In contexts such as books devoted to the language or about associated libraries, tools, etc. we ask publishers to include a small notice in the front matter that mentions the PSF trademark.  We have an official usage policy and a Frequently Asked Questions that detail permitted usage, with the FAQ having more examples and a less formal tone (probably best to start with the FAQ if you have questions).

Similarly, the names "PyCon" and "PyLadies" are also wordmarks of the PSF. The policies around use of PyCon and of PyLadies are each a little bit different from the Python wordmark, since they serve  different purposes.  Essentially, we want to make sure that when those names are used, they maintain an identity and advance the goals for which the marks were created.  The PyLadies wordmark is monitored and authorized by the PyLadies leadership rather than the Trademarks WG, so email to them is the best place to ask questions of them.

Trademarks are Tricky


The trickiest part of what we do on the Working Group is approve use of the "two-snakes" Python logo.  A great many really wonderful Python-related user groups, conferences, software projects, publications, blogs, and other efforts that do a great job of promoting Python, understandably don't understand the arcana of trademark law. In particular, the rules we need to maintain about derived logos can feel obscure and counter-intuitive in the FOSS world.

The key issue is that trademark is not copyright.  For people familiar with copyleft and software freedom, it feels like the right to create derived products should be as little restricted as possible, perhaps not at all. While I endorse that wholeheartedly for copyright, that's not how trademarks work—nor, I believe, how they should work.  Trademark is instead a kind of consumer protection, it's a way of saying that a particular thing is what it purports to be.  In a way, a trademark is like a signature or a seal (whether a physical or a digital version of such); it's a testament to authenticity of a thing.

Apart from my particular philosophical attitudes about trademarks, the laws around them have a specific concept of dilution wherein merely permitting a use that makes a mark less distinct can remove the protection altogether.  Specifically, it means that if the PSF allows groups to make completely well-meaning, and often even beautiful, changes to the shape of the two-snakes logo, we could wind up losing the ability to stop malicious actors from misbranding their non-Python things with the logo.  To be clear, many derived logos are absolutely permissible, and the FAQ discusses what distinguishes permissible and impermissible derivations (and what can be "inspired by but not derived from").

Happily, all the good actors we've dealt with, in my 15 years working on this, have come to understand the concerns of the PSF, and have modified their customized logos in ways that allow us to authorize them.  It's slightly unfortunate that a few others have slipped through simply because the WG never knew they existed until they were already in use, but we've worked with those groups (largely conferences and user groups, sometimes software projects) to fix things going forward.  It's a little bit of politics, a little bit of professionalism, but mostly it's just reaching out to the truly wonderful people who make up our worldwide Python community.

David Mertz (mertz@gnosis.cx)

Wednesday, February 15, 2023

The Case for a Second Developer-in-Residence for Python

As the currently serving sole developer in residence, I’m often asked if there will be more people holding the same position in the future. I strongly believe there should be and that it’s crucial to the long term success of this role. The only open matter is finding sustainable sponsorship for the position.

The current developer in residence

My day-to-day work revolves around an array of maintenance tasks for the Python Software Foundation with focus on CPython. Since I started in July 2021, I’ve done among others:

  • PR review and merging: 627 merges to CPython that lead to closing of 276 issues on the bug tracker, and many more code reviews on Github;
  • release management for the 3.8 and 3.9 branches as well as release notes and announcements for other releases;
  • following the Python security response team reports that lead to several security releases of Python;
  • following the buildbot fleet status and reacting to failures, including maintenance of the only buildbot that runs big memory tests;
  • project management of the transition from our previous custom issue tracker to Github Issues;
  • migration from a previous custom CLA management bot to EdgeDB CLA bot;
  • co-administering discuss.python.org including responding to moderation requests;
  • co-administering core Python Discord;
  • co-chairing the Python Language Summit at PyCon US;
  • reviewing talk submissions on the Program Committee for PyCon US;
  • facilitating cooperation with other significant Python projects: HPy, PyPy, nogil;
  • public speaking (5 events in 2021, 4 events in 2022).

The missing big picture

While I find this work fulfilling and there’s always more things for me to do that other contributors suggest, one facet of the work can overshadow another. I cannot be in all places at once. Most importantly, while removing obstacles for other core developers (often volunteers) is indeed where we should put paid effort, I sometimes get asked: what’s your big project?

At this point I cannot say I had any large personal contribution over the past 18 months of work on CPython, which is ironic, given that I spent more time on it than in the preceding 11 years of core development combined. I had a few attempts at larger changes but inevitably the small busywork eats up my attention.

Adding another developer in residence more than doubles the position’s positive impact

It’s worth noting that the codebase of CPython is over a million lines of code now and even working on it full time does not mean a single person groks it all. That means that what you’re getting from Łukasz, the Developer in Residence, is something else than what you’d get from Magdalena, the Developer in Residence.

That alone means it would be worth having another person with a complementing skill set. But I believe there’s more.

Compared to working solo, having a team of two people paid full time to improve the developer experience for the rest of the core contributors, would allow us to take on larger sweeping projects. What we would end up doing would be definitely consulted with the Steering Council and we would take suggestions from the role’s sponsor. But there’s many possibilities!

We could add official build support for a new platform like iOS. We could improve test coverage of CPython tests, including coverage of trickier bits like the platform-specific code paths, C code, or code involved in CPython’s interpreter startup. We could revamp the buildbot master server to be more performant. We could be taking on implementation of accepted PEPs. We could upgrade speed.python.org to be more informative and easy to use. We could move the rest of the custom CPython bots to Github Actions, decreasing needed maintenance, improving performance and reliability. Those are just some ideas.

There is one more reason why I’m rooting for another person to join this position. Having another developer in residence would buffer any turbulence the other person has. Whenever I’m sick, or travel, or I’m stuck with a particularly stubborn problem, there would reliably be somebody else the other core developers could count on. This is important not only for them but also for me personally as it would decrease anxiety that builds up any time I’m unable to help somebody who needs me.

The ability to split work between two people is something I think about often. In theory there’s a whole team of core developers out there but since they’re mostly volunteers, I’m in no position to tell them what to do. Having a peer paid by the PSF would be different. It would be fair game to share the burden of a gnarly boring task, and that sounds like a wonderful improvement to me.

What if there isn’t another developer in residence?

I’m not saying the other person is required for me to stay productive. If we don’t find the budget for it, the situation is still better than having no developer in residence at all, I’d like to believe. So far I haven’t received much feedback on my work but I’m always open to hearing suggestions.

Friday, February 10, 2023

Python Packaging Strategy Discussion Summary - Part 1

As the Python Packaging Project Manager, my work has mostly concentrated on improving user experience on PyPI. As the Python Packaging ecosystem grows from strength to strength, one of the initiatives I have undertaken is to define a cohesive strategy for Python Packaging.


My Mission


Python Packaging is a diverse landscape dotted with many tools that cater to generic and niche user requirements. As a community, something that is poorly understood is where the community wants to be in 5 years. Understanding where we want to be is important to allow us to identify key goals for the future and how we will reach them, and to ensure we place users at the heart of everything we do. By defining key deliverables driven by community consensus, securing funding becomes easier as we can demonstrate that the community vision will drive innovation and enable better user experience and adoption of Packaging tools.


User Survey


In order to understand what end users are looking for when they use Packaging tools, Nicole Harris and I worked with the community to finalize the survey questions. Nicole developed the final set of survey questions. The survey results are summarized in this document.


From the survey responses, it was clear that while Packaging tools were improving with time, most users found the landscape too complex to navigate. Based on the survey responses, the strategy discussion was condensed to these topics-


  1. Development of a single Packaging tool or a more unified experience

  2. Better support for Packaging users

  3. Phasing out legacy systems

  4. Supporting each other in the community

  5. Encouraging long-term contribution


This post will summarize the discussion around a single Packaging tool. The other four topics will be the subject of future posts on Discuss.

One tool to rule them all?

An overwhelming majority of users recommended a more unified experience when using Packaging tools. The word cloud below shows the frequency of suggestions for the open-ended question- “If you could improve only one area of Python packaging, what would it be?”

To take this discussion further, I invited maintainers and contributors of any Packaging tool to answer this question:


“Can we reduce the number of tools and bring about some form of unification? Can we do anything else to reduce the complexity?”


After an interesting and lively discussion, we still do not have a clear consensus of what a solution should look like, but we do have a way forward. 


Since we are at the beginning of this conversation, we don’t know what unification means yet. As Pradyun Gedam suggested, there are many options as to what it could look like-


  1. Unification of PyPI/conda models 

  2. Unification of the consumer-facing tooling

  3. Unification of the publisher-facing tooling

  4. Unification of the workflow setups/tooling

  5. Unification/Consistency in the deployment processes

  6. Unification/Consistency in “Python” installation/management experience

  7. Unification of the interface of tools


Based on these criteria, there is (some) consensus in driving forward unification of workflow setups/tooling and unification of interface of tools. 


The next major question was, if we do go ahead with unification of specific elements, which elements of Packaging would offer the best solution. To provide a unified UI/UX for end users, some of the solutions that were suggested were


  1. Reusable libraries

  2. Expanding pip to include more functionalities

  3. Recommending existing tools such as hatch, poetry etc.


This discussion also raised a few interesting concerns. Understandably, there is concern over the time and effort that volunteers have devoted in developing tools and whether all this effort will come to naught if we recommend a specific tool. As the discussion continues, there is a large question over the part that PyPA plays and whether PyPA would be willing to take a stand on recommending a specific tool. One concern that keeps coming up is that historically there has been poor communication between PyPA, Packaging tools and end users and if anything will change this time.


The way forward


In order to flesh out the details of the actual solution, I recommend the following steps:


  1. Identify the tasks that a unified solution has to accomplish

  2. Identify the best way to deliver the solution. This could be a new tool, expanding an existing tool or developing standards/libraries.

  3. Submit PEPs to ensure community governance and consensus

  4. Ensure there is buy-in from end users for proposed solution(s)

  5. Define development roadmaps, milestones, key deliverables and timeline

  6. Generate funding to support development

  7. Develop and deliver

  8. Communicate, communicate, communicate


This will be a long and intensive process. But the time and effort invested in this project will be worth it as it will result in innovation and better user experience. 


We will be discussing four more big questions over the next three months that will be used to help us plan the future of Packaging at Python. As we continue the strategy discussions, I invite everyone to participate in the discussion threads on Discuss.  


We are grateful to Bloomberg for generously providing the funding for this role and making this valuable work possible.



Wednesday, February 08, 2023

Announcing Python Software Foundation Fellow Members for Q4 2022! 🎉

The PSF is pleased to announce its fourth batch of PSF Fellows for 2022! Let us welcome the new PSF Fellows for Q4! The following people continue to do amazing things for the Python community:


Chandan Kumar 
Danny Adair
Hugo van Kemenade 
Josef Heinen
Nicolas Laurance
Sayan Chowdhury
Soong Chee Gi
Yung-Yu Chen

Thank you for your continued contributions. We have added you to our Fellow roster online.

The above members help support the Python ecosystem by being phenomenal leaders, sustaining the growth of the Python scientific community, maintaining virtual Python communities, maintaining Python libraries, creating educational material, organizing Python events and conferences, starting Python communities in local regions, and overall being great mentors in our community. Each of them continues to help make Python more accessible around the world. To learn more about the new Fellow members, check out their links above.

Let's continue recognizing Pythonistas all over the world for their impact on our community. The criteria for Fellow members is available online: https://www.python.org/psf/fellows/. If you would like to nominate someone to be a PSF Fellow, please send a description of their Python accomplishments and their email address to psf-fellow at python.org. We are accepting nominations for quarter 1 through February 20, 2023.

Are you a PSF Fellow and want to help the Work Group review nominations? Contact us at psf-fellow at python.org.

Thursday, January 26, 2023

The PSF is hiring a Security Developer-in-Residence!

The Python Software Foundation (PSF) is happy to announce the launch of a year-long security enhancement initiative that will include a security audit and the creation of a new Security Developer-in-Residence role. Generous funding by the OpenSSF’s Alpha-Omega Project has made this work possible.

Recent open source supply chain security attacks on open source projects and infrastructure have increased awareness of the critical role projects like Python and the Python Package Index (PyPI) play in providing a safe and secure ecosystem for millions of open source users. Historically, the Python Software Foundation’s ability to make key security improvements has only been realized when dedicated teams of volunteers or its existing infrastructure staff make time, or when it has received occasional grants, such as the introduction of 2FA and other security improvements to PyPI in 2019.

The Security Developer-in-Residence will work full-time during the initiative to formalize existing security practices and become more proactive in Python-related security improvements. The new role will be responsible for addressing security issues across PSF projects such as CPython and PyPI, and applying knowledge and expertise and working with volunteers to implement key improvements in a timely manner. They will also establish new processes and features that make it easier to prevent, detect, and respond to security risks to lay a foundation that makes it easier and more sustainable for the community to identify and address security issues going forward.

The Security Developer-in-Residence job is posted HERE. Please take a look and and share with your friends and colleagues.

This role is funded by a substantial investment from the Open Software Security Foundation’s Alpha-Omega Project. The OpenSSF is a non-profit cross-industry collaboration that brings together leaders to improve the security of open source software by building a broader community, targeted initiatives, and best practices. The OpenSSF brings together open source security initiatives under one foundation to accelerate work through cross-industry support.

The PSF is a non-profit whose mission is to promote, protect, and advance the Python programming language, and to support and facilitate the growth of a diverse and international community of Python programmers. The PSF supports the Python community using corporate sponsorships, grants, and donations. Are you interested in sponsoring or donating to the PSF so it can continue supporting Python and its community? Check out our sponsorship program, donate directly here, or contact our team!

Tuesday, January 10, 2023

Starting 2023 with momentum, thanks to you!

We are grateful to each of you who shared or donated to our year-end fundraiser and membership drive. Over 300 individual donations plus new Supporting Memberships, renewals, and JetBrains’ generous match came together to raise $61,868 total for our work supporting Python and the Python community! This generosity means we can confidently start 2023 by investing in our key goals for the year, knowing the community is behind us.

Those goals include:

  • deepening our global reach
  • supporting more community endeavors
  • making Python even more sustainable, from both an infrastructure and security perspective

Community investment–of money, but also time, energy, ideas, and enthusiasm–is critical to reaching each of these goals. 

Supporting Membership is a great way for the community to invest in the PSF’s work. We were delighted to meet and then exceed our goal of 100 new Supporting Members: 174 new Supporting Members stepped up to become champions of the PSF! It was exciting to see that 29 of those new Supporting Members were able to join based on our new sliding scale rate option. Welcome aboard, new members, and thank you for joining us! We’re looking forward to having your voice take part in the PSF’s future.

Because the PSF doesn’t buy lists or ads, your help in sharing our fundraiser with your networks makes a big difference, and we really appreciate how many of you took the extra time to help promote it. We’re excited about where 2023 will take us together, and as always, we’d love to hear your ideas and feedback. Looking for how to keep in touch with us? You can find all the ways here.

Wishing you and yours a happy, healthy, and Pythonic new year,

Deb