Blog·AI Sovereignty·No. 018 / 132

Open Models, Closed Communities

Open-weight models are now commodity. The bottleneck has moved to who can actually deploy, evaluate, and maintain them. The community that solves this captures 100x the leverage of the lab that releases another open model.

1,133
words
5m
read time
6,867
characters
14
paragraphs
75
sentences
O
signature
Open Models, Closed Communities
AI Sovereignty · Essay 018 of 132

For most of the last five years, the dominant news cycle in AI has been about new models from a small set of labs. Each release was treated as a landmark. The lab released a model, the world looked at the benchmarks, and the conversation moved to the next release. This was a useful narrative for a period when capability was the bottleneck. It has stopped being a useful narrative now that capability is increasingly commoditized at the open-weight layer.

Today, anyone with a few thousand dollars of GPU credit and a weekend can pull a serious open model, fine-tune it on domain-specific data, and serve it. The capability gap between the best closed model and the best open model has narrowed to a fraction of what it was three years ago. The gap that remains, and that has actually widened, is between the labs that can ship a model and the organizations that can deploy one in a way that survives contact with real users. The next breakthrough, if "breakthrough" still means anything, is not going to be a new architecture. It is going to be the community design that turns open weights into deployed systems at scale.

Why deployment is the new bottleneck

Deployment is a specific kind of work that the model-building world has consistently undercounted. It includes everything that happens between "the weights exist" and "an actual user gets value from them." Fine-tuning on relevant data. Evaluation against domain-specific tests. Integration with existing workflows. Cost optimization at inference. Monitoring for drift and abuse. User feedback loops. Documentation. Training. Trust-building with the people who will rely on the system.

Each of these is unglamorous on its own. Together, they are most of the actual labour of making AI useful. And almost none of this labour is well-organized in the open-source AI world, which has poured enormous energy into the model layer and almost none into the layers above it. The result is a strange asymmetry: there are dozens of capable open models any team can use, and almost no shared infrastructure for the work of using them.

The capability gap between closed and open models is closing. The deployment gap between labs and the rest of the world is widening. Whoever closes the deployment gap wins the decade.

Open code did not close the deployment gap

It is worth remembering that the open-source software movement went through this same arc. For the first decade, the heroes were the people writing the code. For the next two decades, the heroes were quietly the people running the systems, maintaining the dependencies, and writing the boring infrastructure that made the code usable. Linux did not win because the kernel was good. It won because a community emerged around making the kernel deployable, packagers, distributors, sysadmins, the boring layer above the brilliant core. The brilliant core was necessary. It was not sufficient.

Open AI is at the equivalent of Linux in 1996. The kernel, the open model, is here, getting better every six months, free for anyone to use. The community of deployers, evaluators, and maintainers is not yet here at the same scale. The brilliant core is necessary. It is not sufficient.

What an AI deployment community looks like

A working community for AI deployment has a few specific properties. It maintains a small set of well-tested open models that members agree to deploy and evaluate together. It shares evaluation harnesses, fine-tuning recipes, and inference-cost data publicly so that no member has to re-derive them. It runs working groups around specific verticals, health, legal, education, agriculture, where the people who know the domain can collaborate with the people who know the model. It produces, slowly, the kind of deployment documentation that is currently locked inside the few large labs.

Critically, the community is not a marketplace. There is no vendor in the room. The labs that release the models are welcome but are not in charge. The members are practitioners, engineers, evaluators, domain experts, who are deploying AI in their own contexts and want to do so better. The community's product is shared knowledge and shared infrastructure, not any single deployed application.

The Indian asymmetry, again

India is unusually well-positioned for this kind of community because its AI industry is unusually deployment-heavy. The country does not have a frontier lab competing with OpenAI. It has thousands of teams deploying AI inside Indian banks, hospitals, schools, government departments, and startups. Each of those teams is solving variants of the same deployment problems. Most of them are solving them alone. A community that coordinates these efforts, sharing what works, what doesn't, what costs what, would compound the productivity of the entire Indian AI workforce.

The opportunity is to flip the usual frame. India does not need to win the model race to win the AI decade. It needs to win the deployment race. The deployment race is contestable. It rewards organizations and countries that can coordinate practitioners at scale. India has more AI practitioners per capita than almost any country and less coordination infrastructure than it should have. The gap is closeable in years, not decades, with the right community design.

What this looks like in practice

In practice, an Indian AI deployment community would do unglamorous things every week. Publish a curated list of open models with notes on real-world performance from Indian deployments. Maintain a shared evaluation suite for Indic languages. Run monthly tables of practitioners working in specific verticals. Host hackathons that are explicitly about deployment, not about model-building. Train, deliberately, the next generation of evaluators and deployers. Negotiate group purchases of inference infrastructure when scale demands it. Publish honest reports on what is working and what isn't.

None of this is exciting in the press-release sense. All of it is the actual work of moving an industry forward.

The mistake the labs will continue to make

The labs will continue to release models and to be celebrated for the releases. They will, for some time, continue to behave as if the model itself is the strategic asset. This is the same mistake the early Unix workstation vendors made: each company assumed its core technology was the strategic asset, and almost all of them lost to the community that organized around the open kernel.

The Indian AI community has an opening, narrow and time-limited, to be the organization that absorbs the open models and turns them into the cognitive infrastructure of a generation. Bharath.CLUB, AI.Bharath.CLUB, Sarasvat.ai, and Eval.qa are pieces of that organization. The community is the architecture. The models are inputs. The deployment is the output. The 100x leverage is in the middle.

Join the conversation

This essay is part of an ongoing community. If it resonated, the next step is to be in the room.

Join Bharath.club → Read more essays