Head of Amazon OSPO Nithya Ruff on the accidental relationship between open source supplier and consumer

On June 7th, for the third year in a row, we hosted Upstream, a virtual, one-day celebration of open source, the developers who use it, and the maintainers who make it. It was our biggest Upstream yet, with hundreds of attendees joining us in discussions about the current state of open source and how to make it better for everyone. 

In her Upstream keynote, Nithya Ruff, Head of the Amazon Open Source Program Office, spoke about how we have found ourselves in this unintended relationship between open source supplier and consumer and figuring out which is responsible for making it work, aptly titled: The accidental relationship. We asked her to share some of the highlights from her talk in this post.

With an increase in requirements coming from the U.S. government and industries, the demands on often unpaid, volunteer open source maintainers are growing. Maintainers who joined the open source community to create a fix for a problem they saw or to provide help on a passion project are being asked to meet an evolving list of standards without support or pay. For me, it brings to mind a pretty interesting analogy.

Fine dining with home cooks

Most independent open source developers never intended to be a supplier to a Fortune 500 or the nation’s critical infrastructure projects. Imagine being told as a home cook that you are now cooking at a Michelin 2-star, fine dining restaurant with all of the demands of what that includes.  Meeting food inspection regulations, cooking at scale, repeatable and identical meals, having flawless presentation and more. You never trained nor intended to be cooking or serving at this level, you were just trying to create something you and a few friends and family would consume.    

With the success of open source, this is almost how it feels sometimes to the creator of an open source project. Small one or two person projects suddenly come into the spotlight and discover that the world is now depending on them. Just like the home cook never intended to be in the kitchen at a Michelin star restaurant, the relationship between producers of open source software and the organizational consumers is an accidental one.

To be fair, the Michelin restaurant did not know that they were dependent on someone who had never cooked professionally. Often in open source, projects get pulled in as a dependency by another component that the consumer selects. So the whole relationship feels accidental for the consumer and producer. We find ourselves in a world where open source has become wildly successful and our ‘fine dining’ customers are gorging themselves on home-cooking goodness while experiencing a Michelin-worthy experience.

Bridging the gap

One of the issues with this accidental relationship is that it creates a big gap between producer and consumer. The home cook was not expecting to end up in a fine dining restaurant—they weren’t ready for the demands and expectations of the customer. Just like the open source maintainer was not expecting their project to be a large part of a company’s critical infrastructure. The producer is not set up to handle the demands of  commercial or at scale use. What happens when there is a security issue? A vulnerability in the project software that gets exploited? Who is responsible? These issues highlight that perhaps there should be a more formal supply chain relationship and not just a random relationship.   

The question in front of all of us is: How should we work together across the supply chain to manage these risks, and who is responsible for fixing the gap?

Where to go from here 

Over 44% of project maintainers are solo maintainer projects with little funding, yet increasingly the global digital infrastructure is dependent on them. They are often underpaid and overworked volunteers who have no contractual obligation to support their users. The companies that incorporate these open source projects into their infrastructure can be intentionally or accidentally  consuming thousands of unique projects that can become very complex to try and manage. It is hard for the consumer to have a relationship with each of these projects and know what the status of each project is. 

So it begs the question of how do we work with thousands of dependencies? What is the solution then? Many in the open source space have turned to non-profit foundations to provide a neutral place for competing organizations and communities to gather and host key projects. For example, Kubernetes is hosted at the CNCFoundation. Foundations are able to create more funding, governance, and best practices for projects that we all depend upon.

Some commercial enterprises try to manage all their open source components internally on their own. This is not easy to do, but organizations can gauge what their top 50 or 100 critical dependencies are and try to manage these. Organizations can also do a better job of curation and choosing the right projects based on security scores, licenses, and community health. But it is hard for companies to manage all of the projects that come in as there are generally thousands.. A recent study by BlackDuck puts organization, or company, consumption of open source at over 70% of their software stacks.

The U.S. government as both consumer and regulator has recently stepped up the requirements for software supply chain security. The government has intervened with actions such as the White House Executive Order 14028 and the Office of Budget and Management’s memorandum M-22-18 (and the follow-up M-23-16). These guidelines proposed in these recent movements in government are created to understand and ask for more transparency on what software is being consumed during the making of a product or  service. A lot of what the government is requiring starts with creating a software bill of materials (SBOM). An SBOM helps users better understand what  goes into a product, just like a label on a food product lists the ingredients so that the consumer can make better decisions about what they are consuming.

An emerging player in the software supply chain are companies, like Tidelift, who act as a mentor or a relationship builder with open source projects on behalf of its customers. Tidelift helps connect companies with the open source projects they depend on. As companies cannot connect and manage all of the projects they use, companies like Tidelift use their relationships with open source maintainers to strengthen the projects with tools, mentoring, and compensation on behalf of organizations that subscribe to their service. This helps organizations scale their open source reach to hundreds of projects and to raise the project’s ability to meet the needs of enterprise customers. 

But none of these movements towards supply chain security on their own bridge the gap between producer and consumer. Every player in the supply chain has to work together and fulfill their role in the supply chain for it to work.  For that, we can take a page from the farm to table movement that started in the 1970s in California. Its key goals and initiatives could and should be applied to the open source community:

• More transparency on what we consume 
• More sustainability in our production 
• Relationship and knowledge of where our supply comes from
• And to create a healthier supply chain and ecosystem

Cross-collaboration is key to bridging the gap between producers and consumers. We need empathy for each of the players in the supply chain. And by working together, we can close the gap and expectations that exist today between the producer and the consumer of open source software. 

You can watch Nithya's entire Upstream keynote here.