Part III — THE GROUND IT STANDS ON

8.Assembled From the Commons

5 min read

what Hubs are actually built from, and the two open-source projects (Nebari and Nebi) that make assembly and distribution tractable. Assumes: Section 7 (the Hub).

Every Intelligence Hub is built almost entirely from parts nobody sells. The open-source AI ecosystem contains model servers, vector databases, orchestration frameworks, observability stacks, identity systems, schedulers, and more, several competing options in each category, each evolving monthly. This commons is enormously productive, and it has a well-known problem: it arrives as a warehouse of excellent parts and no vehicle. Assembling those parts into a coherent, governed, production-grade system is specialist work, and the specialists are concentrated in a few hundred firms.

So the infrastructure question underneath everything in this guide is really two questions. Who turns the commons into a working Hub for organizations that cannot do it themselves? And how do the artifacts of Part II, the Frames and Cogs and Ops, get packaged so they can be installed into any Hub and behave the same way? OpenTeams' answers are, respectively, a service model and two open-source projects.

Nebari: the curated stack

Nebari (nebari.dev) is OpenTeams' flagship contribution to the commons: an open-source ecosystem for deploying, managing, and scaling AI infrastructure reproducibly. Since mid-2025 it has been rearchitected as a modular stack: an infrastructure core with more than fifteen packs above it, spanning the Jupyter-based data-science tooling the project began with through open-weight LLM serving and generative-AI chat. Two design commitments matter more than the pack inventory. Nebari is additive: its components are curated open-source tools, usable à la carte alongside whatever an organization already runs, not a monolith demanding allegiance. And it is deliberately one contribution among many: the paper itself insists that "an Intelligence Hub is not 'a Nebari deployment'" but a purpose-built assembly of the right components for a specific organization, in which Nebari may play a role and rarely plays the only one.

That restraint is strategic, and it has a precedent the paper leans on by name.

The market context for betting on open infrastructure, rather than against it:

Nebi: the install primitive

Nebi is the quieter project and, for this guide's argument, the more load-bearing one. It is the packaging and environment-management layer: the mechanism by which environments, models, dependencies, Frames, Cogs, and Ops are specified, versioned, installed, updated, and removed. The paper's analogy is exact and familiar: if Nebari plays the role of the operating system, Nebi is pip, npm, or apt.

Keep the italicized caveat; the design depends on it. Two installations of one Op differ for two reasons, and only one of them is what the caveat concerns. The first is designed: the Op picks up each installer's Frames and memory, which is Section 5's whole point; the Ohio hospital's install is supposed to sound like Ohio. The second is stochastic: generative models do not return identical outputs even under identical conditions, and no packaging layer changes that. What Nebi reproduces is everything around the model: versions, dependencies, environments, configurations, pinned and logged so that every installation is auditable. Determinism is not the claim. The claim is that the installed artifact is verifiably the published one, and that its work is verifiable run by run, which is what Section 6's Guards are for.

The assembly business

Between the commons and a running Hub sits skilled labor, and the paper says outright that this is where OpenTeams earns money: selecting, integrating, hardening, and maintaining the open-source assembly for organizations that lack the in-house expertise, with accountability concentrated in one vendor relationship instead of forty. Stated as market structure rather than sales copy: whenever a rich commons meets scarce assembly skill, an integration business forms. Red Hat built one on Linux; Anaconda built one on scientific Python; the pattern is old and the economics are unmysterious. What the model requires to scale is that the assemblies themselves become standardized and reusable rather than perpetually bespoke, which is precisely what Nebari packs and Nebi packaging exist to do. McKinsey's talent finding (insufficient AI skills as the #1 integration barrier, with Deloitte finding only 20% of companies reporting high talent preparedness) is, read from this angle, the demand curve for that business.