Open Source Program Office: what it is and when you need one

I spent the better part of a year watching small companies try to manage their open source footprint with a shared spreadsheet and a Slack channel. Some of them got away with it. Most of them did not. The ones that did get away with it had a quiet, designated person who happened to know where every dependency lived. The moment that person went on vacation, the audit fell apart. The Open Source Program Office, the OSPO, exists to stop that.

What an OSPO actually does

An Open Source Program Office (a team or individual inside a company that owns open source strategy, compliance, and contribution policy) is a fairly small thing in practice. It owns three jobs and only three jobs. First, it sets the rules for what your engineers can and cannot use. Second, it makes sure your code going out the door is compatible with the licenses of every dependency you pull in. Third, it represents the company in the open source communities you depend on. Everything else, including writing the actual policy, is secondary.

In most companies I have watched, the OSPO started as one engineer with a side mandate. The mandate usually arrived because a customer asked a question about license compliance, or a security audit flagged a GPL dependency in a product, or a competitor announced an open source program and the marketing team wanted a response. The first six months of an OSPO are almost entirely reactive. After that, the patterns settle and the office starts to look like a real team.

Why small companies think they do not need one

The standard objection is that the OSPO is a thing big companies have, with lawyers and dedicated budgets. A four-person startup does not need that, the argument goes, and they are mostly right. What they do need is the OSPO’s job done by somebody, not a thing called an OSPO. There is a useful distinction between the function and the org chart.

I have seen the OSPO function survive in companies as small as fifteen people. In one case it was the CTO with two hours a week. In another it was a senior engineer who had been burned by a license issue two years earlier and never wanted to be burned again. Both of those setups worked. They worked because the person had clear ownership and a clear set of questions to answer, not because the company had a program office.

What does not work is when the responsibility is shared across the engineering team, with no single person tracking it. In that case, the SBOM (Software Bill of Materials, a machine-readable inventory of every dependency in your product) gets stale, the contribution policy is whatever the last engineer read on a blog, and the day a customer asks for a license attestation, the answer takes three weeks to assemble.

What an OSPO needs in its first year

The first deliverable of a new OSPO is a license policy that fits your product. Not a generic one borrowed from a large company, but one that names the licenses you will accept, the ones you will not, and the exceptions process for the ones in between. The most common setup I see is a three-tier list. Permissive licenses (MIT, BSD, Apache 2.0) are fine anywhere. Copyleft licenses (GPL, LGPL, AGPL) require review. Network copyleft (the AGPL clause that requires source release for network-served code) gets the strictest review because it changes the legal posture of your SaaS.

The second deliverable is a contribution policy. If your engineers are sending pull requests to upstream projects, you need to know they have the right to do that under your employment agreement. The CLA (Contributor License Agreement) conversation is annoying, but it is the one that bites when you least expect it, usually the day before a product launch.

Inventory is the third deliverable, and it does not need to be fancy. A spreadsheet that lists every third-party dependency, its license, its source, and who owns the relationship is enough to start. The point is that the list exists and gets updated when a new dependency is added. Most dependency scanners, including the free ones, will produce the initial list for you in an afternoon. From there, the office can layer in something more sophisticated if the spreadsheet stops being workable.

A short reference list that I have used at more than one small company:

• MIT, BSD, Apache 2.0. Permissive. Allowed everywhere, including in commercial products, with attribution.
• LGPL. Permissive with conditions. Allowed in dynamically linked products. Review required for static linking.
• GPL. Strong copyleft. Allowed in internal tools. For commercial products, requires legal review and may force source release.
• AGPL. Network copyleft. Requires source release for network-served code. Most companies treat this as a hard stop for SaaS.
• No license. Treat as proprietary. Do not depend on it for any product that ships.

The five-line list above is not a complete license policy. It is a starting point that the OSPO can extend as the product grows.

The community half of the office

The part that gets overlooked is the contribution side. An OSPO is not just compliance. It is also the team’s relationship with the projects they depend on. If your product is built on a single open source project and you have not contributed back in two years, you are in a fragile position. The maintainer burns out, the project forks, and your roadmap gets a new dependency crisis.

The shape of community engagement varies. Some companies fund maintainers directly. Some sponsor events. Some send engineers to work on the project for a quarter. The cheapest and most reliable one is just paying attention: tracking the issue queue, sending useful bug reports, and being present in the discussions. None of that costs money, and all of it builds the kind of goodwill that helps you when you need a fix urgently.

In a small company this is where the OSPO’s job overlaps with developer relations. The office can be one person who does both, and that is fine. The key is that someone in the company has the time to maintain the relationship, and that the relationship is real, not performative.

When the OSPO is not the right answer

There is a class of company for which the OSPO is overkill, and I want to name it directly. If your product is a thin wrapper over a single open source project, and you do not modify the upstream, and you have fewer than ten engineers, you do not need a program office. You need a one-page license note in your repo and a named person who answers license questions. That is the whole program.

The other case is the consulting shop that delivers bespoke work for clients. There, the open source posture is per-project, and the OSPO function lives inside the engagement. Setting up a central program for that is bureaucracy. The exception is when the consulting shop starts packaging its own product. Then the rules change.

Trade-offs

Setting up an OSPO is not free. The first three months are a real time sink, mostly because the policies have to be written in language the engineers will actually read. A 40-page compliance document nobody opens is worse than no policy, because it gives the illusion of governance. The right size for a small company is two to three pages.

The cost of NOT setting one up is harder to see. It shows up as a six-week scramble the first time a customer asks for a license attestation, or as a forced relicense the day you find out a transitive dependency is AGPL. Both of those cost more than the OSPO would have.

If you have a single product, fewer than thirty engineers, and you can name the person who answers license questions, you do not need a program office. If you cannot name that person, or if the answer is “it depends on who you ask,” you need one, and you need it this quarter.

Bottom line

An OSPO is a small function. In a small company it is one person, two to three pages of policy, and a spreadsheet that gets updated. The expensive part is not setting it up, it is running it for a year without a customer incident to justify the time. The companies that get the most out of an OSPO are the ones that treat it as a steady job, not a fire drill.