You already run on open source
Ask any engineering team whether they use open source and the answer is yes. Ask them to list every open-source component in production, with its licence and version, and the room usually goes quiet. Modern applications are assembled from hundreds of packages, each pulling in more. The software is free to obtain. Understanding what you have, and meeting the obligations that come with it, is not.
Licences are permissions with conditions. Some ask only for attribution. Some require you to share changes under the same terms. Some have conditions triggered by distribution or network use. None of this is exotic, but it does need someone to own it.
What an OSPO is for
An open-source programme office is the function that owns an organisation's relationship with open source. In a large enterprise it may be a small dedicated team; in a smaller one it may be a part-time role and a well-run working group. The size matters less than the mandate.
A good programme office does four things. It sets policy, so engineers know what is allowed without asking each time. It runs process, so components are reviewed, recorded and approved consistently. It supports contribution, so the organisation can give back fixes and features safely. And it builds strategy, so open source is chosen deliberately rather than inherited by accident.
Whatever its size, the programme office should be easy to reach. Engineers will ask questions in the middle of a sprint, and an answer that takes three weeks teaches them to stop asking.
Standards worth adopting
You do not need to invent this from scratch. The OpenChain Project publishes two international standards that describe what a quality open-source programme looks like. ISO/IEC 5230 covers licence compliance: the policies, roles, training and processes that let an organisation meet its obligations reliably. ISO/IEC 18974 covers open-source security assurance: knowing your components and handling known vulnerabilities in them.
Both standards are deliberately concise and describe outcomes rather than tools, which makes them practical for organisations of any size. They are also useful in procurement: you can ask a supplier whether they conform, and you can state your own conformance to customers. We state our own position as it stands and call work in progress in progress; we recommend everyone does the same.
A practical first ninety days
A programme office earns trust by being useful quickly. A sensible first quarter might look like this:
- Write a one-page open-source policy covering use, contribution and licence categories, and publish it internally.
- Name an owner and a small review group with representation from engineering, security and legal.
- Generate software bills of materials for your most important applications to see what you actually ship.
- Agree a simple approval route for new components, with pre-approved licence categories to keep it fast.
- Run a short training session for developers on licences and on reporting vulnerabilities.
Beyond compliance
Compliance is the floor, not the ceiling. Once an organisation knows what it uses, it can make better choices: favouring well-maintained projects, contributing fixes upstream instead of carrying private patches, and avoiding dependence on any single supplier, including the one that helped set things up. That last point matters to us. A programme office should leave you more independent, not less.
There is a cultural benefit too. Engineers who are allowed and encouraged to contribute become better engineers, and organisations that contribute gain a voice in the projects they rely on. The programme office makes that safe by handling the questions of copyright, licence and disclosure that would otherwise stop people from trying.
This is not legal advice, and licence questions with real consequences deserve a qualified lawyer. But most of the work of an open-source programme office is organisational, and it is well within reach of any competent engineering leadership.