The open-source question is really a question about what a company wants to own—and what it is prepared to maintain.
Every serious company will eventually hear some version of the same argument.
We should use open-source models.
The argument may be about privacy. Or cost. Or avoiding dependence on one provider. Or keeping sensitive work inside the company. Or the belief that a company doing serious AI should own more of its stack.
Sometimes that is right.
Sometimes it is a very expensive way to avoid admitting that the company has not yet decided what it needs from AI.
The first mistake is treating “open source” as one decision.
It can mean using an open-weight model through someone else’s managed service. It can mean hosting weights in your own environment. It can mean adapting a model for a narrow task. It can mean training something yourself. Those choices have radically different costs, skills, risks, and reasons for existing.
The vocabulary is already doing too much work. “Open weight” does not automatically mean “open source,” and it certainly does not mean “free of obligations.” Google's current Gemma terms, for example, set conditions for use and redistribution, including passing use restrictions to downstream users. The legal question is not a footnote after the architecture decision. It is part of the architecture decision. Read the Gemma terms.
The useful question is not, “Should we use open source?”
It is, “What problem are we trying to solve by owning more of this layer?”
The market is no longer a binary choice
The old picture was simple: rent a proprietary model, or run an open one yourself.
That is no longer the useful split. Cloud platforms now offer managed access to open-weight models alongside proprietary models. AWS added fully managed open-weight models to Bedrock in 2025 and expanded that set in 2026. Microsoft Foundry now offers managed compute for open-source, partner, and custom models—though the service is still in preview and Microsoft explicitly does not recommend it for production workloads yet. AWS announcement · Microsoft deployment overview
This creates three distinct choices, not two:
- a frontier model through a managed API;
- an open-weight model through a managed service; or
- a model hosted and operated by the company.
The middle path matters. It can give a team model choice, familiar enterprise identity and networking controls, and a common application surface without making the team responsible for GPUs, runtimes, and patching. It may also leave them with provider constraints, regional limits, or a preview service that is not ready for a critical workflow. The point is not that it is always the answer. The point is that “we need to self-host for control” now needs a more precise explanation.
Control is not a strategy by itself
Companies often reach for self-hosting because control feels prudent.
The model is inside the boundary. The data does not leave the environment. The team can decide when to upgrade. The provider cannot change the terms tomorrow. The architecture diagram looks more self-sufficient.
All of that can be valuable.
But control is not free. Someone has to run the infrastructure. Someone has to evaluate model changes. Someone has to patch vulnerabilities, manage access, monitor performance, handle outages, control costs, decide which model is fit for which task, and explain why a model that looked good in a benchmark is behaving poorly in a real workflow.
The company has not eliminated dependency. It has moved the dependency inward.
That can be the right trade. It should be a conscious one.
There are a few reasons to own more
There are strong reasons to use or host an open model.
The first is data and deployment constraints. Some work cannot reasonably be sent to an external service because of legal, contractual, sovereignty, network, or operational requirements. A model that can run in the required environment may make a workflow possible that otherwise could not exist.
The second is economics at real scale. If a narrow, repeatable task runs at high volume, a company may find that the cost of a managed frontier model no longer makes sense for that job. This is not a reason to self-host everything. It is a reason to examine a specific unit of work.
The third is latency and resilience. Some systems need an answer quickly, locally, or even when an external service is unavailable. Again, this is a workflow reason, not an identity statement.
The fourth is specialization. A company may need a model or small model stack that is predictable enough for a bounded domain, an internal language, or a specific output format. The advantage is not that the company owns a model. The advantage is that it has designed the whole workflow around a task it understands deeply.
The fifth is negotiating power. A firm that can move workloads between providers, models, or environments is less exposed than one that has welded its product to a single model's quirks and commercial terms.
Notice what these reasons have in common. They begin with a constraint in the work.
They do not begin with a desire to own infrastructure.
The costs are not only compute
The model serving bill is the visible cost. It is rarely the whole cost.
The harder costs are organisational.
Who decides when a newer model is good enough to replace the old one? Who maintains the evaluation set? Who notices that an upgrade improved generic answers and made an important edge case worse? Who sets the permissions around the data and tools? Who supports the team when the model is slow, wrong, or unavailable? Who owns the risk when a supposedly private system produces an unsafe output?
These jobs exist whether the model is proprietary or open. When a company hosts its own model, it owns more of them directly.
That is why “open source is cheaper” is usually an incomplete sentence.
Cheaper for which workload? At what volume? Compared with which managed service? Including what people, hardware, security, evaluation, support, and opportunity cost?
The company may still choose it. It should choose it with the full sentence in view.
The real asset is not the model
Model capability will keep changing.
That is the part of the market most companies do not control, whether they rent or host. A better model will arrive. Pricing will move. Context windows will change. A provider will add a feature. An open model will close a gap.
The durable asset is the company’s ability to evaluate and switch.
Can the team say what a good answer looks like for its important workflows? Can it test a candidate model against real cases? Can it keep the context, prompts, tools, permissions, and logs separate enough from the model that a change does not require rebuilding everything? Can it tell whether a model change improved the work or only improved a benchmark?
That is a more useful form of independence than simply owning servers.
For many companies, the best near-term strategy is not “choose open source” or “choose the best frontier model.” It is to avoid becoming structurally unable to change either choice.
Use the strongest appropriate model where it makes sense. Use a smaller or self-hosted model where a real constraint makes it sensible. Keep the workflow, evaluation, and governance layers clear enough that the model can change without the company relearning everything from scratch.
That is not glamorous infrastructure strategy.
It is better. It is the ability to make a technology choice without turning it into a permanent identity.