Open Source: Separating Fact from Fiction

Created with DALL·E with permission from Ashwin Ramaswami

Open source software is ubiquitous and makes up much of the software infrastructure that underlies the systems our society relies on, from mobile phones to Internet technologies to automotive and national security systems. But as open source software has taken the spotlight—particularly efforts to ensure the security and sustainability of the ecosystem—it’s important to separate fact from fiction when thinking about open source and how best to support and use it. Only when researchers, policymakers, developers, and funders truly understand what open source software is can they make the best and most well-informed decisions. Here, we address some common myths and misconceptions about open source software so that all constituents can make fully informed decisions about the ecosystem.

❌Fiction: Only physical roads and bridges can be considered infrastructure investments. Open source doesn’t count because it’s digital and built by individual coders and private companies.

✅Fact: Open source is infrastructure. It’s used everywhere and underlies private and public systems, from telecommunications networks to mobile phones to critical national security and military systems. In one study, 97% of the codebases audited contained open source software. Open source makes up not only the roads and bridges of industry, but the hearts and veins of our digital ecosystem. And open source is not only built by individuals and companies but also by academics, nonprofits, and governments. It’s a public good, and any investment into infrastructure should take the open source ecosystem into account.

❌Fiction: Any software tool that is free to use is therefore “open source.”

✅Fact: Licenses matter! To be open source, software must generally have its source code available and give others broad rights to modify and redistribute it, without restriction. Some software, though free to use, may not be open source—and can’t benefit from the positive feedback loop of user contributions, increased transparency, and the innovation and security benefits from collaborating in the open. Open source licenses vary widely, and the choice of open source license for the software you develop or depend on is important to understand correctly, and to understand limitations on how it can be used. See the Open Source Definition and the Open Source Initiative’s Approved Licenses for some guidelines.

❌Fiction: Open source software is inherently less secure than closed source software. Any “zero trust strategy” cannot rely on open source software.

✅Fact: Unlike closed source software, open source software is secure only if used correctly and responsibly. Users of both open source and closed source software can greatly benefit from keeping track of dependencies through SBOM and using secure coding practices when integrating dependencies. Closed source software isn’t secure just because a company maintains it; large vulnerabilities regularly impact closed source software as well. And if maintained properly, OSS may even have a security advantage because more eyes (and tools) can review or scan the code to detect and mitigate issues proactively. Any zero trust or cybersecurity strategy must ensure that both open source software and closed source software are used responsibly and securely, which includes giving back to the community.

❌Fiction: Because the entire open source ecosystem is on GitHub, any research into open source maintainers or intervention in the open source ecosystem only needs to target GitHub.

✅Fact: Though GitHub is an important platform for open source communities to collaborate on code, other OSS projects may use other platforms (such as GitLab, Bitbucket, and Gitee); self-host their own platforms, such as gerrit and Savannah; or use other platforms altogether such as mailing lists. And version control systems only cover part of the picture. Package repositories, such as PyPi, Maven Central, and Ruby Gems, are where OSS packages are usually downloaded and are thus critical to ecosystem security. Other platforms include developer tools such as IDEs, CI tooling such as GitHub Actions or Jenkins, and other collaboration and document management tools. One must consider all these platforms to understand and support the entire open source ecosystem.

❌Fiction: It’s too difficult to secure or fund open source software, as volunteers maintain it entirely in their spare time.

✅Fact: While much open source software maintenance depends on volunteer effort, that isn’t the full picture. Surveys have consistently shown that many contributors are paid for their FOSS contributions as part of their job, contractor arrangements, or deriving business from their contributions. Companies are also trying to hire people who have OSS skills and experience.

Moreover, funding open source has been shown to work, from company contributions, philanthropic programs, and government grant programs. The OSS ecosystem could also learn from the rich research software funding landscape. But we can improve: more funders should understand the importance of supporting open source, funding should be directed to maintenance and not just new features, it should be easier to find projects most in need, and open source maintainers should have more guidance on how to obtain and use funding.

❌Fiction: Most critical open source software is already adequately supported by companies, so additional financial or other support would not be helpful.

✅Fact: While some projects are widely used and well-funded, others are under resourced or unfunded. Why? There’s an information problem, in which consumers of OSS don’t fully know what software dependencies they’re using and, therefore, which ones require resourcing, and a funding problem, where funders aren’t prepared to give—or OSS projects aren’t structured to receive—funding for improvements that are most needed. However, projects are always willing to accept more help. Organizations with dependencies on OSS should map the software they rely on to a plan for contributing back. Projects can benefit from engineering time, access to test resources, documentation help, and many other forms of contribution beyond financial support.

❌Fiction: Because open source software is free to use, consumers have no obligation to give back. The burden is entirely on OSS maintainers to patch vulnerabilities and respond to users’ issues and questions in a timely manner.

✅Fact: Open source is not a one-way street but a community. The burden cannot be all on OSS maintainers; it is a problem both for equity and diversity if a few unpaid maintainers are overstretched, having to handle issues and answer questions from developers who companies pay. It’s also unfair and unsustainable to rely on another organization (that pays a maintainer to work on an open source project) to essentially pay for supporting your organization’s technical requirements. Ways that consumers of OSS can give back include financial support to maintainers, hiring engineers to work on a project (part-time is great too); in-kind contributions, such as assigning company developers’ time to share the burden of triaging issues, reviewing code, and building community; improving documentation and tests; and working with open source foundations to work on broader initiatives around open source sustainability, including diversity and equity initiatives such as mentorship programs.

❌Fiction: If open source software breaks or is insecure, blame the developers, maintainers, or other community members who developed the software.

✅Fact: Just because open source software is offered for free does not mean that users have no responsibility to use it securely and responsibly. Vendors who offer software as a paid or monetized product are best placed to bear legal liability around defective software, just like manufacturers who sell finished products. Vendors also have the most financial resources and information needed to keep users secure: for example, vendors can more easily notify their customers of a software flaw. Blaming the open source community hinders sharing and collaboration with open source code and puts pressure on those least resourced to handle it. Open source users need to support the dependencies they rely on, not expect them to do it for free.

❌Fiction: To be successful, all an open source project needs is more software engineers.

✅Fact: There is far more to an open source project than pull requests and code review. Successful open source projects require talented people from various roles, such as technical writers, community managers, security reviewers, marketing specialists, artists, and UI/UX designers. Note how many of these roles do not involve computer science backgrounds. When funding or contributing to an open source project, consider supporting the establishment of these additional non-coding roles needed to build a successful community. We also need to incorporate more education about open source software into our educational institutions so that people from a variety of backgrounds understand open source and can get involved. 

And that’s it! Next time someone has a question about or shares a misconception about open source software, point them to this webpage so they can learn more.