Your observability vendor's renewal quote has gone up, and by more than a little. Procurement asks the obvious question. Can we move? The honest answer from the team is that every service imports the vendor's agent, every alert references the vendor's attribute names, and the migration would take a quarter nobody has.
That is lock-in, and it did not happen in the contract. It happened one pull request at a time, in code, while the team followed the vendor's quickstart because it was the fastest way to get a trace on screen. The decision to let that happen, or to prevent it, is the manager's. It is an engineering economics decision dressed up as a tooling one.
What OpenTelemetry is
OpenTelemetry describes itself as an observability framework and toolkit for generating, exporting and collecting telemetry, meaning traces, metrics and logs. It is a Cloud Native Computing Foundation project formed by merging two earlier efforts, OpenTracing and OpenCensus. Two things in that definition matter to a budget holder.
First, it is a producer of data and never the store for it. The project's own words are that OpenTelemetry "is not an observability backend itself". It produces the data and hands it to whatever stores and queries it, whether that is an open-source tool such as Jaeger or Prometheus or a commercial platform. Second, it states its purpose in terms of ownership. The two principles the project lists are that you own the data you generate, with no vendor lock-in, and that you learn a single set of APIs and conventions.
The components that deliver that are a specification, a wire protocol (OTLP), language APIs and SDKs, instrumentation libraries for common frameworks, and the Collector. The semantic conventions are the least glamorous and arguably the most valuable. They are "common names for different kinds of operations and data", so that the same operation is described the same way across every service and every library instead of in each vendor's dialect.
Where the switching cost moves to
The Collector is the piece that turns vendor neutrality from a principle into a line item. It is a vendor-agnostic proxy that receives telemetry, processes it, and exports it. Services send to a local Collector; the Collector handles retries, batching, encryption and filtering of sensitive data, and forwards to one or more backends.
Follow the consequence. If application code speaks only the OpenTelemetry API and uses the semantic conventions, then the vendor exists in exactly one place, which is the exporter configuration of the Collector. Changing vendors becomes a configuration change and a period of dual-shipping while the team checks the new backend. No service needs re-instrumenting. The project's own documentation recommends running a local Collector in production for this reason among others, and notes that its OTLP exporters emit data without loss of information, which is what makes dual-shipping an honest comparison rather than a degraded one.
That is the trade. You pay a little up front, in an extra component to run, a convention to enforce in code review and a slower first day than the vendor's quickstart. In return the cost of leaving drops from a quarter to a sprint, and your negotiating position at renewal changes completely.
The four decisions
Decide where the vendor is allowed to live. Write it down as a standard. Application code depends on the OpenTelemetry API and never on a vendor SDK, and vendor-specific configuration lives in the Collector. The instrumentation docs make this cheap to enforce for libraries too, since a library can take a dependency on the OpenTelemetry API with no effect on applications that do not import the SDK. Expect pushback the first time a vendor's agent would have saved an afternoon. That afternoon is the premium you pay for the option to leave.
Fund the Collector as a platform component. Something that every service sends its telemetry through needs an owner, an on-call path and a budget for its own capacity. If nobody owns it, the first time it drops data under load the team will route around it, straight to the vendor, and the lock-in returns through the back door.
Own the sampling policy as a cost decision. Telemetry volume is where the bill grows, and sampling is how it is controlled. The documentation is unusually candid about the trade-off. Sampling has its own costs in compute, in engineering effort to maintain as the system grows, and in the risk of discarding the one trace you needed. Head sampling decides early and cheaply but cannot guarantee that every error trace is kept; tail sampling can, but is stateful and operationally demanding. The docs also say plainly that sometimes paying for more observability is cheaper than paying for complex sampling. That is a judgment call with a number attached, and it belongs to you, with the team's input, rather than to whoever configured the pipeline last.
Refuse the fast path when it binds you. When a renewal is twelve months away, the vendor's one-line install looks free. Ask the question you would ask of any architectural decision. How reversible is this? A proprietary agent in forty services is a one-way door. An OpenTelemetry SDK with a vendor exporter is a two-way one.
What this looks like at renewal
The manager who made these four decisions walks into the renewal conversation with a different fact pattern. The team can stand up a second backend, point the Collector at both, and compare for a fortnight. The quote has to compete on query capability and price, because the exit cost no longer does the vendor's negotiating for it.
The manager who did not make them is explaining to finance why the quarter's roadmap just lost a third of its capacity to a migration, or why the increase has to be paid. Neither conversation is about observability. Both were decided a year earlier, in code review, by whether anyone asked where the vendor was allowed to live.
Where this sits in the standard
Engineering economics is competency SV-4 in the EMA Competency Framework, in the Strategy & Vision domain. The SV-4 unit of the Body of Knowledge covers how to put a cost on options like this one, and TJ-1 covers evaluating a technical decision by its organisational consequences, which is what lock-in is.
In EMA-I this appears as a trade-off under budget pressure, with a faster path that carries a hidden exit cost set against a slower one that keeps your options. See what EMA-I covers.