What Does It Cost to Build Open Source Governance In-House?
You have created an SBOM. It contains 800 open source projects. For every single one, you are responsible under DORA, NIS2, or the CRA — for vulnerabilities, patches, documentation, and governance. The obvious question is: Can we do this ourselves?
The honest answer: Probably not.
The dimensions of the problem #
800 projects initially sounds like a manageable number. But behind this number lies a complexity that is nearly impossible to replicate internally:
- 15 or more programming languages. Your SBOM does not contain only Java and Python. It contains C, C++, Rust, Go, Perl, Shell, Lua, Ruby, and more. For each language, you need developers who can not only read the code but understand, assess, and if necessary patch it.
- Heterogeneous stacks and platforms. Linux kernel, PHP, nginx, curl, LibreOffice, OpenSSL, zlib — the projects in your supply chain span operating systems, web servers, cryptography libraries, image processing, and dozens of other domains. No single developer masters all of this.
- Hundreds of maintainers and communities. Each project has its own processes, its own communication channels, its own release cycles. Anyone who wants to get a patch upstream must know the respective community and follow its rules.
- No SLAs, no contracts. There is no contact person you can call. There are no guaranteed response times. There is no escalation path.
The staffing question #
In a client discussion on NIS2 implementation, the question was raised: How many full-time positions would be needed to manage 800 open source projects internally?
An initial estimate came to 5 to 7 FTEs. On closer examination, it became clear: even this number is not realistic. Because the question is not how many people you need but whether you can find and retain the necessary expertise at all.
You would need:
- Developers with experience in 15 or more programming languages, various stacks, specialist domains, and platforms
- Knowledge of different release processes and hosting platforms: some projects are developed on GitHub, others on GitLab, Bitbucket, SourceForge, or exclusively via mailing lists
- Specialists in cryptography, operating systems, network protocols, compilers
- People with active relationships to the respective upstream communities
- Security analysts who can detect Silent Fixes — security corrections applied without CVE registration
- Documentation specialists for audit-ready compliance evidence
On top of this: projects may communicate in other spoken languages. Contribution guidelines differ considerably from project to project. Some expect signed commits, others require a specific commit message format, yet others demand tests in a particular framework. The precise knowledge of project customs — how decisions are made, who holds which role, which communication channels are relevant — must be painstakingly acquired. And acceptance by existing maintainers does not happen overnight but through continuous, high-quality contributions over an extended period.
This combination of breadth and depth cannot realistically be built in-house. Not because the budget is lacking but because the people with this expertise work elsewhere — often as precisely the maintainers you would need.
The hidden costs #
Even if you could build a team, further costs arise that are often missing from workforce planning:
- Onboarding time for hundreds of different projects and their codebases
- Ongoing monitoring of mailing lists, issue trackers, and commit histories
- Building and maintaining test infrastructure for different platforms
- Documenting every measure in audit-ready form
- Redundancy: What happens when your only C expert resigns?
What does this mean for you? #
The question is not whether you can afford to outsource open source governance. The question is whether you can build the expertise in-house at all. In most cases, the answer is no — not from inability but because the task requires a breadth that no single company can sensibly maintain.
OTTRIA bundles precisely this expertise: a network of specialists who work in the relevant languages, stacks, and communities. Instead of building an internal team that you will not find, you gain access to an organisation that is already embedded in the ecosystem.
Further reading #
Want to know what OTTRIA can concretely deliver for your SBOM? Arrange an initial consultation.