The 2023 TODO Group survey results dropped recently, and one number jumped out: 66% of surveyed organizations now have a dedicated Open Source Program Office or some formal open source initiative. That’s a 32% jump from the previous year.

Two years ago, OSPOs were something you’d find at Google, Microsoft, Meta — the usual suspects. Big tech companies with the resources and the open source exposure to justify a dedicated team. The idea that two-thirds of organizations would have formal open source governance would’ve seemed optimistic at best.

So what changed?

The Security Catalyst #

Log4Shell happened. That’s an oversimplification, but not by much.

When a vulnerability in a widely-used open source logging library — maintained essentially by two volunteers — cascaded across virtually every Java deployment on the planet, boards started asking uncomfortable questions. Who maintains the open source software we depend on? How do we know it’s secure? What’s our exposure?

The survey confirms this: 93% of OSPOs reported actively improving their organization’s security posture. Security isn’t just one of many OSPO responsibilities — it’s become the primary justification for their existence in many organizations.

This tracks with what I saw at Google. The open source security conversation shifted dramatically after Log4Shell. Before, it was “we should contribute back to projects we use.” After, it was “we need to understand our dependency graph at a level we currently don’t.” The urgency changed.

The OpenSSF (Open Source Security Foundation) has been pushing frameworks for scoring open source project security health, and OSPOs are the natural organizational unit to implement those frameworks. You need someone whose job it is to audit, track, and remediate open source risk. That’s an OSPO function.

Where OSPOs Live Now #

Here’s a telling data point: 77% of organizations placed their OSPO within the IT domain. Not legal. Not marketing. Not a standalone function reporting to the CIO. IT.

That placement signals something specific about how companies think about open source governance. It’s an engineering concern first. License compliance and community strategy matter, but the operational reality — dependency management, security scanning, contribution workflows — is engineering work.

When I was at Google, the Developer Relations function sat adjacent to engineering, which gave us visibility into both the community-facing and the infrastructure-facing sides of open source. Most companies don’t have that structure, so placing the OSPO in IT is a pragmatic choice. It means the people making decisions about open source dependencies have organizational proximity to the people writing the code.

The alternative — OSPOs in legal or corporate strategy — tends to produce governance that’s heavy on policy and light on practice. You get beautiful open source policies that nobody follows because the engineering team doesn’t even know they exist.

The Mainstreaming Problem #

Sixty-six percent adoption sounds like open source governance has gone mainstream. And in a sense, it has. But “having an OSPO” and “having an effective OSPO” are different things.

The survey reveals some cracks. Budget is a persistent challenge; many OSPOs operate with minimal dedicated funding, relying on borrowed time from engineers who have other primary responsibilities. Executive support exists in name but often doesn’t translate into headcount or tooling investment.

I’ve seen this pattern before. Companies establish an OSPO because a competitor did, or because a board member read about Log4Shell and asked “do we have one of those?” The OSPO gets created, a charter is written, maybe one person is assigned part-time. Six months later, the “program” is a Confluence page that nobody reads and a Slack channel with 12 members.

Effective OSPOs need three things: dedicated headcount (not borrowed), executive sponsorship that includes budget authority, and integration into the software development lifecycle. If the OSPO isn’t involved in dependency decisions before code ships, it’s a compliance checkbox, not a governance function.

The Gaps #

Two underrepresentation patterns in the survey concern me.

First, healthcare. The healthcare industry’s open source adoption is growing, but OSPO formation lags significantly behind tech and finance. Given that healthcare software increasingly relies on open source components — and that healthcare data is among the most sensitive — the governance gap is a ticking clock. HIPAA compliance doesn’t exempt you from supply chain vulnerabilities.

Second, small businesses. The survey skews toward larger organizations, and that’s not accidental. Small companies often can’t justify a dedicated OSPO; the overhead doesn’t scale down well. But small companies use open source just as heavily (often more so, because open source reduces their infrastructure costs). They need governance frameworks that work without a dedicated team.

The TODO Group and Linux Foundation have been working on lightweight governance templates, and that’s the right direction. A three-person startup doesn’t need an OSPO. But they do need a documented policy for evaluating dependencies, a process for responding to CVEs in their stack, and some level of awareness about the licenses they’re consuming. You can fit that in a one-page document and a quarterly review.

What I’d Recommend #

Having worked inside one of the largest open source ecosystems in the world (Google’s), I have a biased but informed perspective on what makes open source governance work.

Start with inventory. You cannot govern what you don’t know you use. Most organizations dramatically underestimate their open source footprint. A proper Software Bill of Materials (SBOM) is step one — and I mean a real one, generated from your actual build artifacts, not a spreadsheet someone filled in manually.

Make security the entry point. Don’t try to boil the ocean with community strategy, contribution programs, and developer advocacy on day one. Start with: what are our riskiest dependencies? Are they maintained? Are they funded? What’s our remediation plan if one of them has a critical vulnerability tomorrow?

Connect governance to the developer workflow. If your open source policy lives in a document that developers access through three clicks and a VPN, it’s not a policy — it’s a suggestion. Integrate dependency checks into CI/CD. Make license scanning automatic. Put guardrails where the code flows, not where the lawyers sit.

The Trajectory #

The jump from 50% to 66% in a single year is significant, but I’d be cautious about projecting a straight line. The organizations that were going to form OSPOs reactively — in response to security incidents or regulatory pressure — have largely done so. The next wave of adoption depends on proactive recognition that open source governance is infrastructure, not insurance.

That’s a harder sell. Insurance is something you buy after a scare. Infrastructure is something you invest in because you understand the long-term compound value. The organizations that treat their OSPO as infrastructure — embedded in engineering, funded properly, empowered to influence technical decisions — will outperform those that treat it as a compliance function.

The survey tells us open source governance is mainstream. The open question is whether mainstream means mature or just widespread. From what I’ve seen, we’re closer to widespread. Maturity takes longer.