What an SLA on an open-source stack actually means

A support contract on software the supplier wrote is a straightforward promise: they own the code, so they can fix anything. A contract on open-source software is a different promise, and pretending otherwise is the most common dishonesty in this business. The useful version starts by being clear about which parts can be committed to and which cannot.

What can honestly be promised

Response time. Somebody competent looking at your problem within a defined window, by severity. This is entirely within a supplier’s control and it is the core of what you are buying.

Diagnosis. Telling you what is wrong, whether it is your configuration, your infrastructure or the software, and what the options are. In practice this is the majority of the value: most incidents are configuration or environment, and knowing which within an hour is what stops a bad day becoming a bad week.

Workaround. Getting you running again, which is usually not the same as fixing the root cause. Rollback, reconfiguration, capacity, a temporary switch to a different path.

Fix or upstream. Where the defect is in the software, either patching it for you or carrying it upstream. Both are real work and both can be committed to.

What cannot honestly be promised

A fix by a specific time, for any bug. Nobody can promise this — not even a vendor who owns the code, though they are more likely to imply it. What can be promised is effort, escalation and a workaround, and a supplier who commits to more than that is either inexperienced or counting on you not reading the exclusions.

Upstream acceptance. A patch carried to a project may be rejected, redesigned or take a year. The commitment can be to maintain it for you in the meantime, not to control a community you do not run.

Behaviour of a model. Especially relevant here. “The forecast looked wrong” is not a defect until it is characterised, and the process for turning it into one is different from a crash. That belongs in the contract explicitly rather than being discovered during the first disagreement.

The parts nobody reads that matter most

Severity definitions. Whose definition of critical? If the supplier grades severity, every incident is a negotiation. Write the criteria in terms of business impact — the warehouse is stopped, the close cannot complete — and the argument disappears.

The clock. When does response time start: when you send the mail, when a human reads it, or when it is assigned? Does it run overnight? Small print with large consequences.

Scope boundaries. Which components, which versions, which integrations. A support contract covering the stack but not the integration into your ERP covers the part that rarely breaks.

Escalation. Who you reach when the first response is not working, and how fast. A named person beats a queue, and a queue beats a form.

Why the exit clause belongs in the same conversation

The uncomfortable truth about support contracts is that the supplier’s incentive is for you to keep needing them. On proprietary software you have little choice. On open source you do — and that only matters if the practical exit exists.

So the contract should say what happens when you leave: configuration handed over in a usable form, documentation of what was changed and why, a defined transition period. Agreed at the start, when you have leverage.

A supplier unwilling to write that down is telling you what their retention strategy is.