GOVERNANCE AND SBOM
Open source governance maturity model.
Knowing where your governance stands tells you where a license change will catch you. This open source governance maturity model lays out five levels, from ad hoc to optimized, and how to move up so a relicense is caught at intake.
Published June 12, 2026. Commercial and licensing risk advisory, not legal advice.
An open source governance maturity model exists to answer two questions at once: where does our governance actually stand today, and what should we improve next. It does this by describing the stages organizations move through, usually from ad hoc up to optimized, with each stage defined by the controls in place and the evidence they produce. The value is not the label. It is the honest placement and the clear next step, because most organizations overestimate their maturity until a license change tests it. Where you sit on the model is, in practice, a prediction of how a relicense will reach you: at low maturity it arrives as an audit finding, and at high maturity it is caught at intake.
The model is a lens on the same governance disciplines covered across the cluster, organized as a ladder rather than a checklist. The foundations sit in the pillar on open source governance and SBOM, and the function that climbs the ladder is the subject of building an open source program office.
The five levels of an open source governance maturity model
A common shape uses five levels. At the first, ad hoc, there is no policy and no inventory; open source enters wherever a developer adds it, and nobody knows the full picture. At the second, reactive, issues are handled as they arise, so a license change is addressed only once it has already caused a problem. At the third, defined, a written policy exists and people can point to it, though enforcement is uneven. At the fourth, managed, controls actually run, intake is gated, an inventory stays current, and the program produces metrics. At the fifth, optimized, governance is continuous, monitoring feeds decisions, and the program improves itself from what it learns.
The line that matters most for license risk falls between defined and managed. A written policy that is not enforced still leaves a relicense to be discovered late. Only when controls actually run does the organization start catching changes early, which is why most of the value of climbing the model is concentrated in that one step up.
Place yourself honestly before you plan
A maturity model is only useful if the placement is honest, and honesty here is harder than it sounds. The temptation is to credit the policy document as proof of the defined level, or the existence of a scanning tool as proof of the managed level, when neither is actually enforced or acted on. The truer test is behavioral: when a component you run last relicensed, how did you find out, and how long did it take. If the answer is an audit or a vendor inquiry, the real level is lower than the org chart suggests. Placing yourself by what happened, rather than by what is written down, is the only placement that helps.
That honest placement matters most where the stakes are highest. Organizations under examination need both a high level and the evidence to prove it, which raises the bar on every control. The higher standard is the subject of open source governance for regulated industries.
Move up one level at a time
Maturity is built in order, because each level depends on the one below it. From ad hoc, the first move is an accurate inventory and a written policy, because you cannot govern what you cannot see and you cannot enforce a rule that does not exist. From defined, the decisive move is to make the policy real with an intake gate that runs in the pipeline, the step that takes an organization into the managed level. From managed, the move to optimized adds continuous monitoring and the feedback loop that lets the program improve. Trying to leap straight to monitoring without an inventory underneath produces alerts about an estate you cannot fully describe, which is motion without maturity.
The two enablers that recur at every level are an inventory that maintains itself and a gate developers will actually use. Their mechanics are covered in open source inventory automation and open source approval workflows for developers.
Match the target level to your actual risk
Not every organization needs the top level, and chasing it for its own sake wastes effort that could go elsewhere. The right target is the one that matches your exposure. A firm that depends heavily on the projects most likely to relicense, or that operates under examination, has reason to reach the managed or optimized levels. A smaller estate with little dependence on at risk components may be well served by a solid defined level with a working inventory. The model is a guide to proportionate investment, not a mandate to maximize. The goal is to be mature enough that a license change is a managed event, sized to the risk you actually carry.
An open source governance maturity model turns a vague sense of being underprepared into a placed position and a clear next step. Locate yourself by how the last relicense reached you, move up one level at a time, and aim for the level your exposure justifies rather than the highest one available. This article is commercial and licensing risk advisory, not legal advice. For interpretation of a specific license or your compliance obligations, your own counsel is the right place to turn.
COMMON QUESTIONS
Questions buyers ask.
What is an open source governance maturity model?
An open source governance maturity model describes the stages an organization moves through, typically from ad hoc to optimized, in how it consumes and governs open source. It gives a common language for where you are today and a sequence for where to invest next.
What are the levels of open source governance maturity?
A common shape is five levels: ad hoc with no policy, reactive where issues are handled as they arise, defined with a written policy, managed where controls run and produce metrics, and optimized where governance is continuous and feeds back into decisions.
Why does governance maturity matter for license risk?
A higher maturity level catches a relicense earlier. At low maturity a license change surfaces in an audit; at higher maturity it is caught at intake or by monitoring, while there is still room to respond cheaply and on your own timeline.
How do we move up a maturity level?
Move one level at a time, starting with an accurate inventory and a written policy, then adding intake controls, then monitoring and metrics. Each level builds on the one below, so skipping stages tends to leave gaps that show up under pressure.
Is this legal advice?
No. This article is commercial and licensing risk advisory, not legal advice. For interpretation of a specific license or your compliance obligations, we recommend your own counsel.
PREVENT THE NEXT ONE
Move your governance up a level.
Open source governance and policy advisory. Independent, buyer side, paid only by you.
Not ready to talk? Read the free open source license risk guides first.