Supporting the Python community by “Shifting Left”

By Kevin Fleming, Head of Open Source Community Engagement and member of the CTO Office

For many years now, software development experts have talked about, and put a lot of effort into, “shifting left.” This started as an effort to improve software quality by testing earlier in the development process (when changes are easier and less costly to make), but has grown to include other aspects of the Software Development Life Cycle (SDLC) as well.

As a refresher, here’s what a typical SDLC looks like:

However, in reality, for all of today’s moderate-to-large software development projects (especially those in enterprise engineering organizations), Development encompasses both the production of code and other assets, and the incorporation of code and other assets from outside the organization. Most often, these third-party materials will either be code under open source licenses or other forms of free-to-use assets.

The definition of Quality has also evolved, and now encompasses more than just reliability, consistency, and lack of bugs. Today, deciding whether a software-based product has met the quality requirements for delivery should include  an evaluation of its compliance with licenses, its reproducibility, and its security.

How can Quality be assured?

The quality assurance process for a product that consists entirely of internally-produced code is under the complete control of the organization which produced the code. A similar QA process for a product that consists of a mixture of internally-produced and third-party code is not entirely under that organization’s control.

When that organization which is using third-party code tries to ‘shift left’ in order to assess quality earlier and earlier in their SDLC and reaches the ‘Development’ stage, any further shifts leftward result in a fork in the road: one path is the internal path and the other path is the third-party path.

What can an organization do to try to assure software quality when their product contains third-party software?

Using Vendor-Provided Software

One option is to ensure that all third-party software used in the product is sourced from a vendor who has themselves produced the software they provide, and who will accept the responsibility for quality assurance. This allows the obligation to be delegated to the vendor, and is a path that some companies choose.

Using Vendor-Curated Software

Another option is to ensure that all third-party software used in the product is sourced from a vendor who has curated it from other third-parties, and who will accept the responsibility for quality assurance. This also allows the obligation to be delegated to the vendor, and is a path that even more companies choose.

Using Community-Provided Software

A third, very popular option is to use third-party software sourced from public communities, typically large open source software communities such as the Apache Software Foundation, the Python Software Foundation, the Linux Foundation, and similar non-profit organizations. Unfortunately, this does not allow the obligation for quality assurance to be delegated, because the community isn’t able to accept that responsibility; the organization consuming the software must find ways to ensure that its usage of this software meets its own requirements for quality assurance.

Quality Assurance for Community-Provided Software

This leaves the organization with a bit of a dilemma; they still must find ways to assure quality in their SDLC, but some of the ‘inputs’ into their product are not already quality-assured.

Bloomberg is such an organization; we use a large amount of community-provided open source software, and it comes from a number of communities. Surveys of those communities demonstrate that their ability to attest to various aspects of ‘quality’ in the software they publish varies greatly:

• Many communities do not use digital signatures to verify package authenticity
• Many communities do not provide mechanisms to assure that package names respect branding
• Many communities do not require all published packages to be produced on ‘controlled’ build systems

Because of this variety, it is challenging to create a ‘minimum standard’ set of requirements for the software that we use. To address this, we want to help these communities improve their ability to attest to the quality of the software that they provide.

Supporting the Python community by “Shifting Left”

This help will take many forms, but for the Python Software Foundation (PSF), it means that we’ve committed to providing two years of funding for a full-time Project & Community Manager for the Python Packaging ecosystem. We were thrilled to learn that the PSF had already been considering this concept when we approached them to find out what we could do to help, and that they have given us the opportunity to collaborate with them to address this important need.

We’re also happy to see that the Python ecosystem will benefit from a recent NSF grant that was awarded to NYU, which is specifically targeted at improving security in packaging. We expect the soon-to-be-hired Project/Community Manager will be involved in facilitating this work too.

Of course, we’ll also continue to provide code (some of our team members are involved in Warehouse, pip, setuptools, and other projects across the Python packaging ecosystem) and engage in PEP processes to help the community make decisions about improvements to Python packaging. We encourage our peers in the technology community, who also use Python and its community-provided packages, to join these efforts so that the entire community will benefit.

This means that when Bloomberg ‘shifts left’ and reaches the ‘community-provided’ fork in the Development stage of our SDLC, we’ll be doing everything we can to improve quality assurance — for us and for every other user of Python.

Thanks to PSF Fellow Mario Corchero, who leads Bloomberg’s Python Infrastructure team, for putting things in motion to make this happen. Thanks also to Ewa, Ee, Dustin, and everyone else at the PSF, who have been fantastic partners.