The Open-Weight Strategy: Why Give a Model Away?

Giving away something expensive to produce looks like altruism or like a marketing expense. It is usually neither. It is a bet about where in a stack profit accrues, and the bet can be written down.

Commoditising the complement

Two goods are complements when demand for one rises as the price of the other falls: hardware and software, cars and fuel, a platform and the applications on it. The strategic consequence has been understood for a long time and is not specific to this industry — a firm profits when its complements are cheap. If you sell A and B is a complement to A, anything that lowers the price of B raises demand for A, and you capture the difference.

Releasing model weights is the strongest available way to lower the price of the model layer, because it drives the licence fee for that capability to zero and can never be reversed. Whoever does it is implicitly saying: the model is not the layer I intend to be paid for.

Which layer they do intend to be paid for is the whole question, and there are only a few possibilities: the compute the model runs on; the device it runs on; the application it sits inside; the data or workflow it operates over; the support, tooling and assurance around it. Each gives a coherent reason to release, and each predicts different behaviour afterwards — which licence terms are chosen, whether the largest variant is released or only the small ones, and how much effort goes into making it easy to run somewhere other than the releaser’s own service.

A second-order effect matters as much as the first. A widely adopted open model becomes the thing tooling is built for, the thing engineers have already used, and the default assumption in tutorials and job descriptions. Setting the de facto standard is worth a great deal even when no licence fee is attached, because it shapes what every downstream tool is compatible with.

The decision, as an inequality

Release when the gain from the complement exceeds what you give up:

Release if:

  dD * m_complement  >  L  +  E

  dD               additional demand for the thing you do
                   sell, caused by the release
  m_complement     your margin on that thing
  L                licence or API revenue forgone, over the
                   period the model would have stayed
                   competitive — which is shorter than it
                   feels, because capability decays
  E                enabling cost: value the release hands to
                   competitors, including their ability to
                   distil from it and to serve it themselves

Two structural observations:

  · L shrinks as the frontier moves. Releasing a model
    that is no longer your best costs less every month
    you wait, which is why releases so often lag the
    frontier by a predictable interval.

  · E is smallest when the complement you sell is one
    competitors cannot easily replicate — capital-heavy
    infrastructure, a device, an installed base.

The inequality also explains who does not release. A firm whose only product is the model has no complement to be paid for, so dD * m_complement is near zero while L is its entire business. Nothing about openness as a value is needed to predict the split; the cost structure predicts it.

It explains the partial cases too, which are the majority. Releasing the small variants and withholding the largest keeps L intact for the customers who pay most while collecting the ecosystem benefits. Releasing weights under a licence that restricts large-scale commercial hosting targets the same split by contract instead of by size. Releasing a model one generation behind the current best costs almost nothing in forgone revenue because the capability was about to be commoditised anyway — per the drift argument — while still buying standard-setting and goodwill. Each of these is the same inequality solved with a different term binding, which is why the pattern of releases looks inconsistent from outside and is not.

Four reasons that are not about complements

What releasing costs

• It is irreversible. Weights that have been downloaded cannot be recalled, so the decision is a one-way door taken with incomplete information about how the model will be used.
• The metering point disappears. Once anyone can serve it, the price of serving it converges toward cost, and it converges for you too. If some part of your business depended on that price, you removed it deliberately.
• It accelerates competitors. A strong open model is a teacher: it can generate training data and be distilled into something smaller. That is one of the mechanisms driving the decay rate in the moat condition, and it operates on you as well as for you.
• Responsibility does not transfer cleanly. The releaser cannot control downstream use but is not entirely detached from it either, in reputation or, increasingly, in regulation.

A fifth cost is easy to overlook and lands on the releaser’s own users: once weights are public, the releaser is no longer the only party whose serving quality matters to the model’s reputation. Someone else’s heavily quantised deployment, served badly, is experienced by users as the model being worse than it is. That is a real cost of releasing and it is one the releaser cannot manage, only document.

Note also that “open” covers a wide range of actual permissions, and licences attached to released weights frequently restrict commercial use, scale of deployment, or training other models on the outputs. The distinction between open weights and open source is not pedantry; it decides what you are allowed to build, and it is set out in the difference between the two.

Reading it as a buyer

For someone choosing what to build on, the strategy behind a release matters only through its consequences, and there are three worth planning around.

• Nobody is obliged to keep releasing. The inequality above can flip. Build so that a future model in the same family being closed is an inconvenience rather than an emergency.
• Read the licence for your actual use. Deployment scale limits, field-of-use restrictions and terms about training on outputs are where the surprises are, not in the headline word “open”.
• Open weights change your options, not your obligations. The genuine benefit is optionality — you can run it yourself, you can move between hosts, you can keep serving an old version when an API deprecates one. Whether exercising that option is worth it is an arithmetic question, and the arithmetic is in the local-versus-API comparison.