Open models are easy to access. Production still needs an owner.

Mozilla's July 2026 State of Open Source AI report draws partly on a Mozilla-commissioned SlashData survey of 1,494 qualified developers who were adding AI functionality to applications with open or closed models. Fieldwork ran May 19–29, 2026. Among adopters of each model type, the survey found that 51% of open-model adopters reported reaching production, compared with 63% of closed-model adopters.

That 12-percentage-point gap matters to leaders weighing an open model, a managed closed endpoint, or a mix of the two. It does not settle which option is better. It gives teams a sharper decision to make before changing models: determine whether the current blocker is task quality or production work that lacks budget, tools, and an accountable owner.

Open-model use is common, and half of the sample used both types

The Mozilla/SlashData survey found that 79% of its qualified respondents used open models and 71% used closed models. Half used both, while 29% used only open models and 21% used only closed models. Those results describe overlap as much as competition: many developers were already selecting different model types for different needs.

The sample boundary is important. Respondents came through specialist research panels and qualified only if they were developers adding AI functionality to applications. SlashData fielded the survey for Mozilla, offered it in five language variants, and weighted results by region using Developer Nation benchmarks. The findings do not represent all developers, all companies, or general business adoption.

The production figures also use adopters of each model type as their bases. They show how often respondents said those models reached production; they do not measure the amount of traffic, business value, reliability, or cost of the resulting systems. A team using both model types may also appear in both adoption groups.

The survey describes a production gap without proving its cause

Mozilla interprets the gap as a problem of operational tooling and trust rather than model capability. That is Mozilla's diagnosis, informed by the wider report. The 51% and 63% survey results alone cannot establish that explanation.

Several factors could affect the difference. Open- and closed-model adopters may have different team sizes, tasks, deployment goals, support arrangements, or compliance requirements. Respondents may also interpret “reaching production” differently, and the public material reviewed for this article does not establish one uniform deployment threshold. Mozilla commissioned the research, and no public respondent-level data or independent replication of these two production rates was identified in the supplied sources.

The survey establishes a narrower point. Open-model access was widespread in this qualified sample, while a smaller share of open-model adopters reported reaching production than closed-model adopters. Each organization still has to find the cause in its own workload and system.

Open weights and open source grant different kinds of access

The terminology affects what a team can inspect, change, and redistribute. “Open model” is often used as a broad category. “Open weights” usually means that the trained parameter files can be downloaded under stated license terms, although the release may omit training data, training code, or other material needed to reproduce and modify the system fully.

The Open Source AI Definition from the Open Source Initiative sets a stricter standard. It requires the freedoms to use, study, modify, and share the system, along with access to the preferred form for making modifications. That preferred form includes the required data information, code, and parameters described by the definition. A downloadable checkpoint therefore does not automatically qualify as open-source AI.

This distinction clarifies rights; it does not remove operating work. A permissively licensed model may still need substantial compute, serving software, security controls, monitoring, updates, and recovery procedures. Our Inkling deployment analysis shows the point at one-model scale: access to weights can coexist with infrastructure requirements that place self-hosting beyond an ordinary workstation or small server.

Task acceptance and operating responsibility need separate reviews

A task review asks whether the model does the work well enough. Use representative inputs and accepted outputs to measure quality, latency, context and modality fit, tool behavior, and failure patterns. Keep prompts, surrounding tools, cache conditions, and evaluation rules fair to each candidate; our production model comparison guide explains how the surrounding system can distort a model result.

An operations review asks whether the organization can keep that result available and safe. It covers infrastructure capacity, scaling, updates, security, data handling, compliance evidence, monitoring, incident response, rollback, support, staffing, and total cost under realistic demand. A model can clear task acceptance while the proposed deployment fails this review because nobody owns one or more of those responsibilities.

Run the task review first when output quality is uncertain. A model that misses the required work should not receive an infrastructure project as compensation. Document the failed cases closely enough to tell a model limitation from an adapter, retrieval, prompt, or evaluation defect.

When the model clears the task bar, run the operations review against the exact deployment being considered. Name who patches the serving stack, approves model updates, watches errors and resource use, responds to security findings, restores service, and authorizes rollback. Estimate cost with expected utilization, redundancy, engineering time, and support included. Checkpoint access cost and per-token API price answer only small parts of that calculation.

The same discipline applies to managed endpoints. A provider may operate the model service and supply contractual support, but the customer still owns application behavior, access policy, data flows, output validation, user communication, and fallback decisions. Provider deprecations and behavior changes also require preparation; our guide to AI migration windows covers that continuing work.

Choose open, hybrid, or managed based on evidence and ownership

An open deployment is a sound choice when the model clears the task review and control produces a concrete benefit. Privacy requirements, deployment location, customization, latency, predictable high utilization, or reduced dependence on one endpoint can justify the operating investment. Proceed only when the organization can name owners for the serving, security, update, monitoring, recovery, and cost responsibilities in the proposed environment.

A hybrid deployment fits workloads with materially different needs. Predictable or sensitive tasks may run on infrastructure the organization controls, while difficult or variable work goes to a managed endpoint. This choice adds routing, evaluation, fallback, and data-boundary decisions, so it works best when the team can observe both routes and test what happens when either one is unavailable.

A managed closed endpoint is reasonable when speed to production, provider support, packaged compliance evidence, or access to a needed capability outweighs the benefits of self-operation. It can also be the right current choice for a small team whose open-model operations would consume more time and money than the workload justifies. The decision should be revisited when usage, requirements, model quality, pricing, or internal capacity changes.

These options are deployment choices, not a permanent ranking of model types. Local evidence should determine where each workload runs and who carries the associated responsibility.

Name the owner before approving a wider model change

Select one production candidate and complete both reviews with the people who will run it. If task quality fails, change the model or the surrounding application and test again. If operating ownership fails, assign and fund the missing work or choose a deployment that transfers more of it to a managed provider.

BaristaLabs can help teams review one open-model production candidate and compare the open, hybrid, and managed options against the actual workload. Our AI consulting and strategy service focuses that decision on evidence, cost, and accountable ownership. Do not authorize the broader migration until each production responsibility has a named owner.

Sources

• Mozilla: The State of Open Source AI
• Mozilla: The State of Open Source AI 2026 report (PDF)
• Open Source Initiative: Open Source AI Definition