Blog

One of the first tasks for any OSPO is creating an open source policy. It's the charter for your open source program. It should express your company's take on the big questions: Why does your organization engage with open source? What are your goals? Who is allowed to engage with open source? The answers may be different for each organization, but there are two key concepts that will help you create the most effective policy for your organization.

It was a big week for Github CoPilot last week. There were new allegations of copyright infringement of open sourced code and an announced lawsuit. So how should you think about CoPilot and other machine learning tools trained on open source code?

You may remember the 2017 Equifax data breach. The records of more than 160 million people were exposed, making it one of the largest cybercrimes related to identity theft. Among various other penalties, Equifax was required to pay out $300 million to a fund for victim compensation, $175 million to the states and territories in the agreement, and $100 million to the CFPB in fines. The cause of the data breach? Not updating an open source component on Equifax's website.

Last year, the Biden administration issued the Executive Order on Improving the Nation's Cybersecurity. What most open source personnel don't realize - yet - is that one of the results of the Executive Order will be a contract requirement to manage open source risks as a mandatory contract term for anyone supplying the Federal Government.

So much of what we do in OSPOs is about trying to get things right. We usually focus on the positive sides of engaging with open source: lower costs, greater control, faster time-to-market, and higher developer satisfaction. But that doesn't mean that we also don't keep an eye on open source risks. A number of independent events have all converged to markedly increase the legal risk of poor open source practices.

This guide explains how organizations can build leadership and influence within the open source projects they’re involved in and on which they are commercially dependent. Learn about leadership culture and roles within a project, how decisions are made, how an organization can build leadership, and tips for being a good leader in open source communities.

Open source development requires a different approach to software engineering than many organizations are accustomed to. It becomes easier if you have a clear plan to follow. Fortunately, many companies and individuals have already forged a path to success by contributing to significant open source projects in strategic ways. This practical guide will help you and your company improve your internal development process and prepare you to contribute to the open source projects that matter most to your company.

Open source program managers must demonstrate the ROI of their efforts. This guide provides an overview of some of the standard ways that organizations evaluate their open source programs, projects, and contributions. Learn what to measure, how to define success, and how to best use this information to advance your open source program objectives, demonstrate effectiveness, and gain support.

So what is an open source program office (or "OSPO")? It is the hub of an open source program. The OSPO is a designated place where open source is supported, nurtured, shared, explained, and grown inside a company. With such an office in place, businesses can establish and execute on their open source strategies in clear terms, giving their leaders, developers, marketers, and other staff the tools they need to make open source a success within their operations.

This guide covers what it means to contribute to open source as an organization and how to become a good corporate citizen. Learn how open source projects are structured, how to contribute, why it’s important to devote internal developer resources to participation, and why it’s important to create a strategy for open source participation and management.