Open Source vs Vendor

Decision criteria.

Overview

Open source has zero licence cost; vendors have a sticker price. That is the surface conversation. The real conversation is about who pays for upgrades, who runs the on-call rotation when the tool is the cause of an incident, and who reads the security advisory at 2am. Free software still costs people.

• Open source. No licence cost, full control, transparent issue tracker, modifiable. You own operations, upgrades, security patching, and on-call.
• Commercial vendor. Licence cost in exchange for managed operations, SLA, support contract, and someone else's pager during outages.
• Operational fit. OSS wins when the team has platform-engineering bandwidth and the workload is core differentiation; vendors win when the tool is non-differentiating infrastructure.
• Per-tool decision and total cost of ownership. Headcount cost of running OSS is real. Compare against vendor licence honestly across a 12-month projection.

The approach

Score each tool by whether it is core to your differentiation and whether the team has bandwidth to operate it. Default to vendor for non-core; default to OSS where the team can credibly absorb the operational burden.

• Differentiation classification. If the tool's behaviour is part of what makes the product unique, lean OSS for control; if not, lean vendor for managed operations.
• Operational bandwidth check. Honestly count how many hours per week the team can spend operating the tool; OSS without that bandwidth becomes shadow tech debt.
• Total cost of ownership model. Add headcount cost (engineering hours, on-call time) to OSS; add support tier and overage to vendor.
• Document the choice and the trigger to revisit. Capture rationale and the conditions (incident frequency, vendor pricing change, scale milestone) that would flip it.

Why this compounds

The right model per tool keeps paying back: engineers spend their hours where the team differentiates, vendors absorb the operational burden everywhere else, and the bill stays linear with growth.

• Operational fit. Matching tool to team capacity prevents shadow operations cost from compounding.
• Cost discipline at scale. Honest TCO modelling beats either "OSS is free" or "vendor is too expensive" reflexes.
• Engineering velocity. Engineers operate the few things that matter for differentiation; vendors handle everything else.
• Decision trail for the next tool. Each documented choice teaches the next team which questions to ask, not which model to default to.