The open source versus commercial argument is usually conducted as a matter of principle and settled as a matter of budget. Both of those are the wrong frame. The useful question is narrower: for this specific layer of the stack, what does this organisation actually want to own?
Separate the decision by layer
A network automation stack is not one product. It is at least five distinct layers, and the right answer differs for each:
- Source of truth. The authoritative data model.
- Configuration and provisioning. Turning intent into device state.
- Orchestration. Multi-device, multi-domain, transactional service delivery.
- Observability. Telemetry collection, correlation, assurance.
- Workflow and integration. Approvals, ITSM, the glue between everything else.
Treating this as a single buy-or-build decision is how organisations end up with a commercial platform whose data model they cannot extend, or an open-source stack with five full-time engineers maintaining integrations that a vendor would have supported.
Three questions that decide each layer
1. Is this layer a differentiator or a utility?
Differentiators are worth owning. Utilities are worth buying. For most enterprises, the data model is a differentiator, because it encodes how that specific organisation thinks about its network, and no vendor's opinionated schema will fit it exactly. Telemetry collection at scale is a utility. Nobody has ever won a customer because of how they gather SNMP.
2. What is the real cost of the open-source option?
The licence is free. The cost is engineering time, and it is recurring, not one-off. Honest accounting includes integration development, upgrade testing, keeping up with breaking changes, and the risk concentration when two people understand the deployment and one of them leaves.
That cost is often worth paying. It is rarely zero, and comparing a licence fee against zero is the most common error in these evaluations.
3. What happens when you want to leave?
Ask this before signing, not after. Specifically: can the data be exported in a usable structure, is the API documented and stable, are the automation artefacts portable, and is there a migration path that does not mean starting again. A platform whose value depends on your inability to leave is not a partner.
The pattern that works most often
Open source or open-core at the data layer, where extensibility and ownership matter most. Commercial at the layers where scale, vendor certification and support economics dominate. Deliberate integration between them, designed rather than accumulated.
Where the hybrid approach goes wrong
Hybrid stacks fail in predictable ways.
Integration debt. Every connection between two systems is code someone has to maintain. Count them before committing. A stack with four components has six possible integration points; a stack with seven has twenty-one. Design the integration topology deliberately, usually with the source of truth at the centre, rather than letting every tool talk to every other tool.
Two sources of truth. The commercial platform brings its own inventory. The open-source source of truth has one too. Unless one is explicitly declared authoritative and the other is made to sync from it, they diverge, and nobody notices until an automation acts on the stale one.
Skills mismatch. Open-source components assume an engineering culture: version control, code review, testing, a release process. An organisation that has not built that culture will struggle regardless of how good the software is. This is a capability question, not a technology question, and it is answerable honestly in advance.
A defensible default
For a large enterprise starting from a low automation baseline, this ordering tends to hold up:
- Establish the source of truth first, on a platform with a strong data model and a real API. Own this layer.
- Add configuration and provisioning against it, starting with the highest-volume, lowest-risk change types.
- Bring in commercial orchestration where the estate genuinely needs transactional, multi-domain service delivery. Many estates do not, and buying it early is expensive shelfware.
- Choose observability on operational fit and support model, not on feature checklists. This layer is consumed by people at three in the morning.
- Keep workflow and integration thin, explicit and owned in-house. This is where organisational specificity lives and it is the layer you will change most often.
The stack that survives contact with production is rarely the one with the best components. It is the one whose boundaries were drawn on purpose.