Reject open-ended LGU+ RHEL/OEL support commitments — best effort only

May 8, 2026 at 5:15 PMstrategyhigh

Situation

Nathan surfaced (via Justin) a CIQ <> LGU+ contract proposal requiring CIQ to provide workarounds and answer customer SR tickets for RHEL 6 (already EOL), RHEL 7/8/9, and OEL 6/7. Peter intervened in the same-day group DM with Bjorn, Art, and Ramesh to draw the line at best effort only — no commitments to deliver workarounds or answers. Asked Nathan if it is not yet in force so he can get in front of it before signing.

Reasoning

Third member of the GDC/Rakuten contract-discipline arc — Peters first move was to ask Nathan if it matched that pattern (his words: is it as dumb as the GDC and rakuten contracts?). Supporting RHEL/OEL EOL releases for a single customer is open-ended commitment to a non-differentiating, non-strategic, capacity-eating function — exactly what the 5/4 engineering-veto-on-custom-deals decision was meant to block. The best effort / we tell them if we know framing preserves the relationship without creating paper commitment to deliver answers on a third-party kernel CIQ has no patch authority over. Speed matters: get in front of it BEFORE signing because once signed, engineering eats the cost forever.

Additional Context

Justin raised it to Nathan; Nathan flagged Peter via DM at 9:00 AM with the doc link. Peter read between meetings, came back at 9:22 AM in the group DM with Bjorn/Art/Ramesh asking what the deal is. Bjorn pushed back lightly (we agreed to give answers since they couldnt move everything over immediately). Peter held firm with the best-effort line. Ramesh agreed in-thread (any support we offer for RHEL/Oracle Linux will be best effort). The contract section Peter quoted requires CIQ technical support to be capable of generating Service Request tickets for RHEL 6/7/8/9 plus workarounds — exactly the open-ended SR commitment Peter is rejecting.

Observed Evidence

Multiple direct quotes across DM Nathan + group DM Bjorn/Art/Ramesh; Peter explicitly compared to GDC/Rakuten patterns; Ramesh in-thread agreement establishes the boundary before LG QBR

Matching Patterns

40%
Protect Engineering Capacity(1 keyword match, same category, explicit capacity protection)
47%
Route Non-Differentiating FTE Classes to Partners(non-differentiating support work, involves Bjorn/Ramesh, same category)

Confidence Breakdown

33/35
Evidence
28/30
Pattern
20/20
Source
13/15
Corroboration

Reasoning Depth Analysis

Org Signal:Engineering veto applies to support contracts too, not just deal terms — 5/4 decision extended to a new contract type
Who Affected:Bjorn (relationship/sales side), Ramesh (post-sales/QBR owner), Art (BD context), Nathan (kernel team that would absorb the work)
Precedent:Confirms multi-contract pattern (GDC, Rakuten, now LGU+); each intervention earlier in the lifecycle — this one before signing rather than after
Consequences:Real — if signed as drafted, kernel team eats RHEL 6/7/8/9 SR tickets indefinitely; directly competes with the D1 build/test investment for capacity
Timing:Now because contract not yet in force; same-day intervention before LG QBR; pre-signing leverage > post-signing renegotiation

Source

reflection

AI Confidence

94%

Related Context

💬
Group DM Bjorn/Art/Ramesh — best effort line

slack

We cant commit to giving them workarounds. We cant commit to giving them answers to their questions. We can best effort it. We can tell them if we know. But thats it.

💬
DM Nathan — get in front of it

slack

Is this a contract proposal though? Not currently in force? So I can get in front of it?

💬
DM Nathan — pattern recognition

slack

no. Ill read it after this next meeting. is it as dumb as the GDC and rakuten contracts?

💬
Group DM — quoted contract section

slack

Even if CIQ is unable to provide patches for RHEL 6 or RHEL 7,8,9 (including OEL 6 and 7), it must still be capable of offering workarounds — Peter surfaced the specific clause

Outcome

No outcome recorded yet.

Decision ID: 0aea4795-3418-4f36-af2b-099544e4b6db