There’s a lot of uncelebrated work to power the open source ecosystem, keep it secure and encourage new participation.
We spoke with Jessica Marz, Open Source Program Office Director, about the role an Open Source Program Office (OSPO) plays in securing open source software. Our conversation touched on how the OSPO helps secure the software supply chain, encourages upstream contribution, and about what it means to be a good open source citizen.
Katherine Druckman: No two OSPOS are the same – what's the traditional role of the OSPO?
Jessica Marz: As you alluded, every OSPO is different, but the most basic definition of an OSPO is that it's a centralized unit within an organization that manages and coordinates that organization's open source activities. This includes things like governance, compliance and community engagement. Of course, it's a little different at Intel where your team focuses on the community and evangelism side. But the OSPO is involved in engaging the community with good code, secure code, and behaving like good open source citizens.
There are four main responsibilities of an OSPO. The first is managing the open source policies for the company. The next is facilitating open source contributions. The third is to promote open source adoption and use and foster an open source mindset across the organization. And, finally, we help manage legal risks.
I think that's the reason why OSPOs were originally created. It was really about license compliance and helping companies manage legal risk in using open source software, making sure that they weren't inadvertently putting GNU General Public License (GPL) code into proprietary products and making sure that all their distributions comply with all the license obligations.
Katherine Druckman: We could talk for hours about what it means to be a good open source citizen, and people may not agree.
Everyone’s talking about software supply chain security right now. It’s an important topic, and there are challenges unique to open source as a developer and as a user. What are the supply chain challenges can the OSPO help address?
Jessica Marz: First, I don’t think an OSPO can do it by themselves. Open source is unique because of its whole nature. There’s a collaborative, decentralized nature that’s highly distributed and involves people and organizations from all around the world. You might not even know the true identity of some people you work with, so if there’s a security issue, it can be a challenge to know who to go to or how to reach out to someone because they're just a GitHub* ID somewhere out there in the universe.
OSPOs have spent a lot of time working to understand code bases, communities and the norms of different communities, whether they're a Benevolent dictator for Life (BDFL) or have a neutral governance entity, ways to ways to communicate, ways to get in touch with projects based on the licensing work that they've done. This can extend to security work as well.
We take that knowledge of how open source communities work and help educate the security professionals in our company. There was a security incident last year, for example, going back to the anonymity issue, and people wondered: “Can't you call up the project maintainer and have them fix this thing?” And I said, “Well, in this case, no, actually. I can't and that's not exactly how it works. And we can't just demand. In fact, what we should do is propose a change.”
That’s the currency or the way that you communicate in open source. You want something fixed? You don't just say ‘I want this thing fixed,’ and demand that someone do it by a certain date that you open a pull request, or you propose a fix yourself. You become part of the part of the solution. That's one way that an OSPO can help both in educating internally and then using some of its muscle or knowledge to work in the outside world.
Katherine Druckman: It's challenging to put yourself in the position of bringing people into this culture who don’t necessarily understand how things work...You're not born knowing how open source communities function, and it’s nice to have a guide.
Jessica Marz: A big part of the OSPO is about education. We want people to be good citizens. So how can you be good citizens if you don't kind of know or understand the lay of the land or what the norms are? The OSPO can be a guide.
Katherine Druckman: How does your knowledge of governance and compliance and community engagement translate to a more secure ecosystem?
Jessica Marz: I don't want to say that OSPOs are the groups who say “no” or that they're bossy or that they're bureaucrats. But policies are the bread-and-butter of the open source program office, and most bosses have a lot of experience in drafting policies, policies that are understood and implemented by software development engineers, which is not to say that another organization might not, but that’s just what we do day in and day out. Understanding the audience, knowing how to effectively communicate with them, and being able to convey your message are extremely valuable skills that the OSPO can offer. They've been saying for years, “OK, these licenses are OK in these circumstances. These licenses are not OK in these circumstances.” It's not hard to imagine extending it so that you're saying, “And these kinds of dependencies or these kinds of libraries are OK to use.” Or: “these are the kind of things that you should stay away from.” It's an education and a counseling process. But again, because we do this every day, we're already a familiar voice for the developers who need to hear the message as opposed to it coming from some other organization that they've never heard of before it suddenly comes down from on high with mandates about security.
Katherine Druckman: They know you as a friendly entity, right? You’re the go-to source for a little handholding.
Jessica Marz: I hope they think we're a friendly entity! They might just think that we're a pain-in-the-butt entity. But they know that generally there’s a good reason why we are doing something.
The OSPO also has eyes, monitoring and seeing all sorts of open source software consumption across the enterprise to develop a picture of what's being used and where. By having that vision of the inventory, the OSPO is in a great position to be able to say, “Hey, these are projects that are super important for the company. Let’s make a proposal. I think that we should be more active in this community. We should be making it more robust. We should help harden it. We should pay the developers.” I don't know what the correct answer is, and it might be different for different organizations and different OSPOS, but having that position of visibility is another advantage the OSPO has compared to other organizations in terms of being able to highlight where there’s risk for the company and coming up with strategies to help promote security in those projects or in those components.
Katherine Druckman: A topic near and dear to my heart is upstream contribution, contributing back upstream to various projects that you benefit from. How do you help educate developers about best practices? And beyond that, how do you communicate that it's an opportunity not a burden?
As a developer, I always wanted to follow best practices just for my own confidence, so I would go to people in the community where I was contributing and ask for advice on giving better code reviews, on being a better contributor, communicating more effectively within the community.How do you approach those issues?
Jessica Marz: Again, education is important and goes back to that idea of being a good citizen in the community. How we behave upstream -- whether we submit fixes for common vulnerabilities and exposures (CVEs) or any help we can offer to upstream projects helps. Maybe it's not code. Maybe there are other resources or documentation or reaching out to try to influence to help prioritize particular fixes, coordinating funding or rewards, or something for projects that fix high severity CVEs in a timely manner. Those are all things that OSPOs can do that help promote best practices and best-known methods in the community.
Participating in events, talking with folks, keeping up with what's going on in development communities, staying up to date with the latest open source trends and best practices, as well as building relationships with other users and contributors is a way that we can help promote best practices and strengthen the software security supply chain.
Katherine Druckman: Sometimes we focus too much on code. It's always good to have a reminder of the human aspect of software development especially in an open source community.
Jessica Marz: It's always good to be building those relationships and bridges.
For more of this conversation and others, subscribe to the Open at Intel podcast:
- Openatintel.podbean.com
- Google Podcasts
- Apple Podcasts
- Spotify
- Amazon Music
- Or your favorite podcast player (RSS).
About the Author
Katherine Druckman, an Intel Open Source Evangelist, is a host of podcasts Open at Intel, Reality 2.0 and FLOSS Weekly. A security and privacy advocate, software engineer, and former digital director of Linux Journal, she's a long-time champion of open source and open standards.