This article was sponsored by The Linux Foundation. Read more about the research in this previous article.
The world runs on open source software. Its benefits are obvious: The code is free, making software development cheaper and faster than ever before. And the communities that develop and maintain it can be very supportive, providing users with everything from advice, documentation, discussion boards and tutorials, all the way up to training programs and conferences.
But as the open source ecosystem grows, it also becomes more complex. For organizations that rely on free code to build their internal or commercial products and services, using open source libraries comes with security and compliance risks — and, for commercial code, licensing implications.
In turn, open sourcing your developers’ own code can also create security issues and pose licensing risks.
Having your organization’s own open source program office (OSPO) can mitigate much of the risk in using or contributing open source code. An OSPO is a group at your company that collects in-house or external expertise, best practices, and tools, and offers advice to internal users and managers.
Sixty-three percent of survey participants who said their organization has an OSPO deemed it at least “very critical” to the success of their engineering or product teams. Among OSPO-hosting organizations in the survey, 57% said they use the program to further strategic relationships and build partnerships.
An OSPO can also provide a framework for evaluating the health of open source projects.
Keeping Track of Updates
One very basic task of an OSPO would be to keep track of what needs updating. Studies show it’s a problem. A big one.
Earlier this year, Synopsys, an electronic design automation company, released a report in which it reviewed the code of more than 1,500 enterprise software projects, both internal and commercial, and found that 98% of them contained some open source code. (In fact, for an average application, 75% of the codebase was open source.)
Here’s the scary part: In Synopsys’ analysis, 84% of the codebases had at least one vulnerability. Ninety-one percent of the open source components used hadn’t seen any maintenance of the past two years.
And even when updated versions of the open source code were available, companies didn’t always use them. According to the report, 85% of the codebases contained components that were more than four years old, sometimes when there were multiple newer versions available.
In addition, 65% of codebases had license conflicts, creating potential legal liabilities for the companies that used them.
One example of what could happen as a result is the 2017 Equifax breach, the result of a vulnerability in the Apache Struts framework. The breach could have been avoided because the vulnerability had been patched two months previously.
“Proprietary software vendors regularly assist customers in managing licenses, compliance issues, updates and other functions,” said Charles King, principal analyst and president at Pund-IT Research. “Those issues can be less clear in open source efforts.
“An OSPO can help there, as well as in [other] areas, including open source library management and development roadmaps,” he said. “Overall, well-designed OSPOs can help organizations improve code quality, reduce costs, avoid problems and capture other benefits.”
Companies that engage with open source communities surrounding the projects that they use the most or are the most critical to their success can connect with the top experts on those technologies, supply useful fixes and feature improvements, and even help guide the development roadmaps of those projects.
Organizations that open source their own codebases can leverage them to reach new users, connect with experts and, yes, sometimes get free development help and peer-to-peer support options.
But dealing with open source communities can also be perilous. Some companies see the developers who maintain and contribute to open source projects as free labor, but this approach can backfire.
She’s seen fights break out between companies and open source projects: “That’s not an isolated thing. You need someone listening to what the community wants and what the organization wants, and come up with an approach that benefits both.”
For example, if a company has its staff developers fix a problem or add a new feature to an open source project without doing any research first, it might turn out that the open source community had already been working on its own solution, or that the new feature doesn’t fit in with the project roadmap.
The new survey of OSPOs found that just over 59% of respondents said a primary responsibility of an open source program is to engage with developer communities so that the company contributes to other projects effectively.
But establishing an internal culture of open source must come before anything else, Jiménez said. “The company is spending time, money and effort. That’s why it’s key to have an open source culture first before going and starting things.”
Finding and Keeping Talent
In addition to helping build good relationships, an OSPO can also help a company retain its tech talent by creating opportunities for employees to participate in open source projects.
“Engineers and people, in general, want to build their personal brands,” Jiménez said. “Open source allows them to do that. It motivates people to know that their company or organizations are investing in that, in their personal brand, and they can keep growing as professionals.”
It can also help companies stay at the cutting-edge of technology since, by participating in open source projects, its developers can become deep experts in those tools.
“And if you help your developers and engineers to be more active in those projects, they can help decide where those projects will go,” she added.
The visualization tool maker Grafana Labs only uses open source software extensively, but it has also open sourced much of the software that it produces, making money by selling advanced features to larger enterprise customers.
“We are truly an open source-first company,” said Richard Hartmann, the company’s director of community, who has previously served as a volunteer developer for the Prometheus project.
Grafana’s open source community management group includes dedicated, full-time community managers, as well as people shared across other departments — user experience developers, tech writers, marketing, legal and many others.
The company is growing quickly, and Hartmann said open source community relationships have helped his company find good job candidates.
As new developers come on board, many of whom may not have worked with open source projects before, they have questions about how to interact with the open source communities. That’s where Grafana’s OSPO helps.
“Having a central place they can go is a huge benefit and helps empower people,” said Hartmann.
He’s seen other companies trying to leverage open source communities, simply mimicking others’ behavior without trying to understand how they work, and without changing the way they do things.
“They see the success of certain companies and want to replicate that success,” he said. “They see the behavior, but they don’t understand the reason for that behavior. There’s a name for it — cargo cults.”
For example, he said, “They see OSPOs, so they create an OSPO. But it’s just a toothless entity with no budget and no staff.”
Changing the Culture
One of the most important functions of an OSPO is changing a company’s own culture to be more friendly to open source.
Nearly 69% of participants in the new survey by Linux Foundation Research, the TODO Group, and the New Stack said that fostering a culture of open source within an organization is the primary responsibility of an OSPO.
That cultural change should apply to both external and internal open source projects, said Oleg Nenashev, principal software engineer at CloudBees, a company that specializes in software delivery management and automation.
Nenashev works full-time for his company’s OSPO, as a community manager for the Jenkins open source project. He’s been on the governance board for Jenkins since 2019, is on the technical oversight committee of the Continuous Delivery Foundation, and is active in the InnerSource Commons foundation.
“The most important thing for an OSPO is the culture,” he said. “If you’re an OSPO, you’ll definitely be involved in the company culture. You need an open source culture to ensure that you can collaborate.”
Successful collaboration can mean changing the way employees think about open source code, he said. “Many people think open source is something you get for free. That’s just not true. Open source is an investment.”
The Changing Role of the OSPO
Even as more companies are opening OSPOs, their function has changed.
“At the beginning, OSPOs were mostly in the software industry,” Jiménez said. “And now there are more OSPOs emerging in all industries. In retail, in academia. And that’s also something I see in the surveys.”
In its fourth year, the survey of open source program offices saw a broader cross-section of industries participating. The percentage of respondents in the technology industry is now at 36%, down from 45% in 2019.
And as open source becomes ubiquitous in enterprises, companies have to become much more strategic about managing the risks.
“Open source program offices offer a central place that organizations can take stock in and govern the use of different libraries being utilized,” said Steve Turner, an analyst at Forrester.
That also applies to out-of-the-box commercial applications and custom-built internal applications, he said.
“Most importantly, this central authority gives them the visibility and ability to assess their exposure from a security vulnerability, risk posture, and licensing standpoint,” Turner added.
Nearly 60% of participants in the new survey of OSPOs said maintaining open source license compliance reviews and oversight is a primary responsibility of those programs.
OSPOs can also help encourage developers within its organization to contribute upstream, and do so more frequently. Nearly 43% of participants with OSPOs said in the new survey that increased participation in external open source projects has been a primary benefit of having those programs.
“An open source project only thrives and is successful if people contribute to it,” Ambiel said. “If they just use it but don’t contribute to it, it will die a slow technological death because it will diminish over time.
“An open source program office can help you understand where open source is today, how you’re consuming and using it. And if you’re committed to this piece of open source software, have you contributed upstream, have you updated it lately, do you know what licenses are inside of it? All of those things are important to be a responsible user of open source.”
CloudBees, The Linux Foundation, Synopsys and VMware are sponsors of The New Stack.