A Day in an OSPO

After more than 30 years of free software and open source software shaping the technology industry, no serious or mature developer doubts their importance anymore. Open source has become infrastructure, and since software has been “eating the world” for decades now, a reasonable question follows quite naturally: if open source is everywhere, why do organisations still need an Open Source Program Office?

What is an OSPO, really?

Both the TODO Group and the OSPO Alliance offer solid, comprehensive definitions of what an OSPO is. They are accurate, well thought out, and widely accepted.

But after working in both small and very large organisations, I’ve come to see OSPOs as something more revealing: a clear signal of an organisation’s technological maturity.

Why? Because the more technologically mature an organisation is, the more it understands that using, contributing to, and managing open source software are core processes if the organisation wants to remain competitive, resilient, and credible. An OSPO exists to manage and nurture that organisation’s relationship with the open source ecosystem it depends on.

There is no single metric for “tech maturity”, but experience teaches you where to look. One simple exercise I’ve done is to check whether large enterprises actually have active public repositories on GitHub or GitLab, not just an account, but real activity. Some time ago, I compared how many companies from the IBEX35 and from the DAX had active public GitHub repositories. I’ll let you imagine the outcome.

 Do organisations really need an OSPO?

Let me start with a slightly provocative premise: no organisation should need an OSPO, but almost all of them benefit from having one.

In an ideal world, every development team would fully understand how to use open source software, how to contribute back to it, and how to release and manage their own open source projects. Over the years, I’ve yet to see that world exist at scale.

Many developers are excellent engineers but have never been trained in open source licensing or governance. Many organisations, especially those whose core business is not software, still underestimate how deeply open source runs through their infrastructure.

I’ve seen organisations surprised by licence obligations they didn’t know they had. I’ve seen confusion between “open source” and “source-available” code. I’ve seen dual-licensed software quietly become a legal or budget problem months later. And I’ve seen teams discover, too late, that security and regulatory requirements apply just as much to open source dependencies as to proprietary ones.

I’ve also seen how often organisations miss the value of contributing back. Contribution is one of the most effective ways to improve the software you already rely on and to influence the technologies that shape your products. Without clear policies, guidance, and support, developers simply won’t do it.

And if an organisation is not mature enough to enable contributions to existing open source projects, how can we realistically expect it to release and sustainably manage its own open source software?

So what is the role of an OSPO?

Based on what I’ve seen work and fail  across very different environments, the core role of an OSPO is to make open source easier for development teams. Easier to use. Easier to contribute to. Easier to release. Easier to manage responsibly.

That usually happens at three levels.

First, the OSPO acts as a central point of knowledge. Licences, obligations, responsibilities, dual licensing models, the difference between true open source and “open-like” software, community participation, conferences, and upstream engagement.

Second, the OSPO works closely with management to define frameworks, ways of working, and policies. These define how open source is used inside the organisation, how developers can contribute upstream, and how internal projects can be released as open source in a sustainable way.

Third, the OSPO provides and manages tooling. Tools to track open source dependencies, to ensure licence compliance, to validate contributions, and to support the lifecycle of released open source projects.

What does an OSPO actually look like?

There is no universal blueprint. But based on my experience, and on conversations with many other OSPO managers, some patterns do emerge.

An OSPO is usually a small team, ideally somewhere between five and twelve people, sitting under the umbrella of the organization's platform or technology team or close to the CTO’s office. What is essential is that the OSPO must establish key relations with other teams or areas, particularly legal and people teams, for compliance and policy development.

Team members should have real experience participating in open source projects. And in my view, experienced open source lawyers are not optional. Licence compliance and legal interpretation require deep expertise. Developers have their own language. Lawyers do too. A good OSPO knows how to translate between them.

So… what does a day in an OSPO look like?

Going back to the key question: what does a typical day look like?

A significant part of the day is spent answering licence questions. Clarifying doubts. Making sure that dual-licensed software (often AGPL or GPL with commercial alternatives) does not turn into an unexpected legal or budget issue. And when it does, helping the organisation manage it sensibly.

Another large chunk of time goes into supporting development teams that want to contribute to open source or release their own projects. Reviewing governance models, checking best practices, and helping teams avoid common mistakes before they become public.

Closely related to that is supporting developers who actively participate in the open source ecosystem through conferences, talks, and workshops. Active participation matters, not as marketing exercises, but as genuine engagement.

And, of course, the OSPO itself keeps evolving its tools and processes, constantly incorporating feedback from development teams and lessons learned from real incidents.

Periodically, the OSPO also needs to explain its value to leadership in concrete terms. Not just lists of dependencies, but stories that resonate: how many people globally are involved in maintaining the software the organisation relies on; how upstream contributions reduce long-term cost and risk; how engagement in released projects translates into real technical and budgetary impact.

Is that too much for a team of five to twelve people? Perhaps.

Now think about this the next time you hear that a large corporation’s OSPO consists of two or three people.

Maybe that, too, should be a metric of tech maturity.

-Jose Manrique Lopez de la Fuente