The "Free" Myth and Why It Distorts Budgets
The single most expensive error in software cost analysis is treating an open source vs commercial total cost decision as a licence-fee comparison. Open source software is free to download; it is not free to run. The global open source market is projected to grow from $48.5bn in 2025 to $56.6bn in 2026 — a 16.5% annual rate — and almost all of that spend is support, services and staffing, not licences. The licence line, in other words, is the smallest part of the number that matters.
When a vendor charges a licence fee, it is bundling deployment tooling, tested release builds, security backports, documentation, and an SLA-backed support desk into that price. Drop the licence and those functions do not disappear — they transfer to your own engineering team. One analysis found an organisation spending roughly 40% of its total technology resources purely on maintaining a homegrown platform. That is the cost a licence comparison hides.
The Eight Cost Lines a Real TCO Model Includes
A credible total cost of ownership model runs over a three-to-five year horizon and accounts for every cost the software generates, not just the one on the invoice. We use eight lines in client engagements: licence or subscription; implementation; integration; ongoing maintenance labour; support contracts; security and compliance; training; and exit or migration cost. The discipline is to apply a fully-loaded labour rate to the engineering hours each option consumes — because that is where open source spends what it saves on licensing.
The numbers are concrete. Running an open source component in production typically demands 10 to 20 hours of dedicated engineering time per month for deployment, patching and incident response. At a senior DevOps rate, 20 hours a month is around $1,730 in labour — for a single component. Multiply that across a stack of a dozen self-hosted open source tools and the "free" software is carrying a six-figure annual operating cost before a single licence has been paid. This is the same labour-versus-licence trade-off that sits underneath right-sizing enterprise software deployments and any honest software asset management ROI calculation.
The rule we give every client: licence costs are not operating costs. If your comparison stops at the licence line, you have not compared the two options — you have compared one number on each side and ignored the budget that actually gets spent.
Open Source vs Commercial: Side-by-Side
The table below frames the trade-off as buyers actually experience it. The pattern is consistent: open source wins decisively on licence and lock-in, commercial wins on support certainty and predictable staffing load, and the deciding variable is almost always the depth of your in-house engineering capability.
| Cost / risk dimension | Open source (self-hosted) | Commercial / proprietary |
|---|---|---|
| Licence / subscription | $0 core; optional support | Recurring fee, often 15–25% annual maintenance |
| Maintenance labour | 10–20 eng hours/month per component | Vendor-absorbed; minimal internal load |
| Support response | Community / your team | Contractual SLA, 24/7 on premium tiers |
| Security patching | Self-managed CVE remediation | Vendor backports and advisories |
| Vendor lock-in | Low — open standards | High — proprietary formats and APIs |
| Audit / compliance risk | Licence-compatibility review | Licence-count audit exposure |
Note the lock-in line. The recurring 15–25% maintenance uplift and renewal leverage that proprietary vendors hold is precisely the exposure we work to cap during a licence agreement structure negotiation and across the wider software licensing negotiation practice. Open source removes that renewal leverage entirely — a benefit that rarely appears in a licence-only comparison.
Commercial Open Source: The Middle Path
Most enterprises do not choose between pure community open source and closed proprietary software. They choose a commercial open source subscription — Red Hat Enterprise Linux being the canonical example — which keeps the open standard while buying tested builds, security backports and vendor support. RHEL Server subscriptions start at around $349 for a two-socket server and tier into Self-Support, Standard and Premium (24/7 severity 1–2). In 2025 Red Hat also widened its no-cost tiers to cover up to 16 individual developer nodes and 25 business-developer instances — but those explicitly exclude one-to-one engineering support.
That detail reframes the whole decision. The real choice is rarely "free versus paid software" — it is "self-support versus paid support." A paid open source subscription converts an unpredictable internal staffing load into a fixed, negotiable contract line, which is often the cheaper and lower-risk outcome for a regulated enterprise. It also gives you a renewal to manage, which is where disciplined co-terming of software contracts and a structured contract consolidation playbook recover further value.
Making the Decision Defensible
The output you want is a single multi-year number for each option that a CFO will accept. Build the eight-line model, apply a realistic loaded labour rate, and be honest about whether your team genuinely has the capacity to absorb open source maintenance — or whether that 10–20 hours a month will quietly displace product work. Enterprises with deep platform-engineering teams routinely make open source the cheaper option; those without typically find a supported subscription wins on both cost and risk. This sits inside the broader discipline set out in our enterprise IT cost optimization framework and the 2026 cost optimization framework, and connects directly to defending the resulting budget.
For a model template and benchmark inputs, see our SaaS optimisation guide and the price benchmarking report. If you want the comparison built and pressure-tested for a specific buying decision, request a confidential briefing and we will model both options against your actual estate.