Here is something about the Open Semantic Interchange (OSI) that nobody at Snowflake wanted to say out loud: a vendor-neutral interchange format announced by a single vendor is structurally incapable of being trusted. Not because anyone acts badly, but because everyone has to anticipate that someone might.
That asymmetry just got fixed. In June 2026, the OSI project formally moved from Snowflake to the Apache Software Foundation as an incubating project called Apache Ossie. The repository now lives at github.com/apache/ossie. The old one is being archived. The spec didn’t change. The governance did, and for a standard whose entire job is to be trusted by parties who compete with each other, governance is the product.
The Structural Problem Snowflake Couldn’t Solve Alone
Let’s be direct about the awkward fact that everyone in the room was too polite to mention when Snowflake launched the Open Semantic Interchange in September 2025. Snowflake convened it. Snowflake did the right thing by open-sourcing it under Apache 2.0. And doing the right thing does not dissolve the structural problem: a vendor-neutral interchange format announced by a single vendor asks its participants to accept an asymmetry.
Everyone contributes business logic to a shared format. One participant also controls the venue.
That asymmetry doesn’t require anyone to act badly. It only requires everyone to anticipate that someone might. A competitor evaluating whether to encode its customers’ metric definitions in your format is not asking whether you are trustworthy today. It is asking what happens in year four, when the format’s roadmap and your product roadmap point in different directions. Absent a structural answer, the rational move is to hedge, and a standard that everyone hedges against is not a standard. It’s a format with good press.
Donating the project to the Apache Software Foundation is a structural answer. The ASF holds the trademark. Releases require a vote of the project management committee, not a decision by a sponsoring company. Merit accrues to individuals, not employers, and it does not expire. Committership is earned by contribution and cannot be purchased. Twenty-five years of institutional design at the ASF has been, in the main, an elaborate mechanism for making capture expensive.
The Ossie proposal says this plainly. Its interest in joining the ASF is “governance alignment, not brand leverage.” That sentence is the whole reason this matters.
What Actually Changed (and What Didn’t)
The spec didn’t change. The repository moved. The governance transformed. And that transformation is the entire story.
The core specification remains what it was: a vendor-neutral format, expressed in YAML and JSON, for writing down semantic models, the metrics, dimensions, entities, and relationships that define what a business’s data actually means. The spec ships as human-readable documentation alongside machine-readable schemas, so a tool builder can validate that a model conforms. This is the heart of the project: not software you run, but an agreement about how meaning is written down, the same way Parquet is fundamentally an agreement about how bytes are laid out.
Around the spec sit the pieces that make an agreement practical. A converters directory holds reference translators between Ossie and existing dialects, with converters for dbt, GoodData, Salesforce, and Apache Polaris already in the tree. A validation directory holds tooling to check models against the schema. An ontology directory holds the standardized vocabulary work. An examples directory includes a complete semantic model for the TPC-DS benchmark schema. And a Python package provides the core types for programmatic work.
The design philosophy threaded through all of it is decentralized: systems read semantic metadata from the source that owns it rather than depending on point-to-point field mappings between every pair of tools. Manual mapping between systems grows quadratically and breaks whenever a schema changes. Self-describing data, where the meaning travels attached to the source and every consumer reads the same description, converts that quadratic mess into a linear one. Define once, understood everywhere.
The Ossie Model: Four Layers of Meaning
An Ossie model is a structured document, YAML or JSON, that a human can read and a machine can validate. Think of it as having four kinds of entries, layered from concrete to abstract.
At the bottom are the pointers to physical reality: which datasets the model describes, the tables or views in your warehouse or lakehouse, and how the logical names in the model map to physical columns. This grounding layer is what lets a definition be executable rather than merely aspirational.
Above that sit the entities and relationships: the declaration that a customer is a thing, identified by this key, appearing in these datasets under these different column names, related to orders one-to-many. This is the layer that kills the “third system” problem, where the knowledge that Customer_Code and Account_UID mean the same person lived only in an engineer’s head or a stale wiki page.
Above that sit the dimensions and measures: the attributes you slice by, time at various grains, geography, segment, and the raw quantifiable facts that metrics are built from. And at the top sit the metrics themselves: named, documented calculations with their formulas, filters, exclusions, and grains.
Two properties of the format deserve emphasis. First, models are plain text files, which means they live in version control, changes arrive as reviewable diffs, history is preserved, and the workflows every engineering team already trusts apply to business definitions with no new machinery. Second, models are composable and referenceable rather than monolithic: a finance domain model and a product domain model can each own their pieces and reference each other, so a large organization’s semantics can be federated the way its data already is.
The Roster Tells the Real Story
Read an incubation proposal closely and the roster tells you more than the prose. Ossie’s is unusually revealing.
The core development today comes from three companies: Snowflake, Dremio, and dbt Labs, with Salesforce alongside in the initial governance. Snowflake and Dremio are the two companies that co-created Apache Polaris, and here they are again, joined by the company whose semantic layer work in dbt largely defined the modern metrics conversation. The initial project management committee spans all four companies, the mentors are veterans of the exact Apache data projects Ossie must integrate with, and the champion, JB Onofré, is a long-time ASF member who helped shepherd Polaris through its own incubation.
The contributor flow reaches wider still: the proposal documents merged work from Snowflake, Salesforce, Databricks, dbt Labs, AtScale, Atlan, RelationalAI, ThoughtSpot, GoodData, Honeydew, and Hex. That list contains direct competitors at nearly every layer, warehouses that compete with lakehouses, BI tools that compete with each other, semantic layer products whose entire commercial moat was, until now, the proprietary format Ossie replaces. When companies co-invest in dissolving their own lock-in, it is because they have concluded the market demands it.
Why the ASF, and Why Now
The deeper question is why a working initiative with fifty partners needed the Apache Software Foundation at all. The answer is the same argument that has played out across every layer of the data stack. A standard’s entire value is neutrality. Companies will only pour their business logic into an interchange format if they are certain the format cannot be tilted, stalled, or captured by any single vendor, including and especially the vendor that started it.
Snowflake launching OSI was necessary and commendable. It was also, inevitably, a reason for some rivals to hesitate. Donating the project to the ASF converts “trust Snowflake and friends” into “trust a twenty-five-year-old foundation whose entire constitution is preventing capture.” The proposal says this in its own words: the interest is “governance alignment, not brand decoration”, because a vendor-neutral interoperability standard requires consensus-based, multi-stakeholder governance.
This is exactly the same playbook that made Apache Iceberg the standard for table formats and Apache Polaris the standard for catalog interoperability. The arc of open data infrastructure is one sentence repeated at ascending layers: we standardized the bytes, then the files, then the tables, then the catalogs, and each time, competition moved up and users won. Apache Ossie is that sentence reaching the top of the stack, the layer where data becomes meaning.
What We’re Actually Watching For
Enthusiasm is cheap. Here is what determines whether this works.
Committer diversity. The proposal is candid that core development currently spans three companies, and it names homogeneous developers as a known risk rather than burying it. Incubation graduation should be gated on whether that changes. Watch the commit logs, not the logo wall.
The expression language. Ossie today standardizes structure: semantic models, datasets, fields, metrics, dimensions, relationships. The hard part, a portable expression syntax that survives translation across dialects, is a working group, not a solved problem. The current spec leans on per-dialect expression strings. That is honest and it is also not yet interchange in the strong sense.
Whether the neighbors show up. The roadmap points at Apache Polaris integration, Spark and Iceberg converters, and a semantic query standard. Ossie is the first ASF project whose success depends less on its own code than on adjacent projects agreeing to read it.
Version 0.1 is version 0.1. Fifty-plus organizations, five working groups, a financial services vertical group that held its first meeting in June. Momentum is real. Momentum is not the same as a stable specification.
The AI Agent Elephant in the Room
Everything in 2026 ends with AI agents, and Ossie is no exception. The emerging stack looks like this: MCP as the tool layer, A2A between agents, and a semantic standard as the layer that decides whether agents can be trusted with meaning. Ossie is that layer’s candidate, now with neutral governance to match the layers around it.
The end-to-end picture writes itself: an agent reaches the lakehouse through a governed MCP surface, the catalog vends it scoped credentials and, alongside the tables, the Ossie-formatted definitions of the metrics it is about to compute. The agent’s SQL encodes the company’s definition of churn rather than the model’s best guess, and its answer matches the CFO’s dashboard because both flowed from the same source of truth. Deterministic meaning is the phrase the proposal uses, and it is exactly the missing ingredient every enterprise AI post-mortem has been naming for two years.
This is precisely why the revival of semantic layers driven by AI is not just another tech cycle. The AI agent wave punishes semantic fragmentation more brutally every quarter, and no proprietary format can be the industry-wide answer by definition.
A Worked Example: One Metric’s Journey
Let’s make this concrete. A subscription business decides, after one too many Monday meetings, to fix churn. The analytics lead convenes finance, product, and the data team, and they hammer out the definition: churn rate is the count of subscriptions canceled in the period, excluding involuntary payment failures that recover within seven days, divided by subscriptions active at the period start, measured monthly.
Today, that hard-won agreement would be enshrined in a slide, and each tool would reimplement it slightly differently within a quarter.
Instead, the team writes it once as an Ossie model: the churn metric with its formula and exclusions, the subscription entity it depends on, the relationship between the billing system’s account identifier and the product database’s user identifier, the month dimension it is measured over. The model is validated against the schema, checked into version control like code, reviewed like code, and registered in the company’s Polaris catalog, where it lives next to the tables it describes, governed by the same access controls.
Now watch it travel. The BI platform reads the model through a converter and builds its dashboards from it, no re-definition, no drift. The dbt project consumes the same model through MetricFlow, so the transformation layer and the dashboard layer are provably computing the same thing. When the data science team’s notebook and the finance team’s spreadsheet plugin pull churn, they pull the definition, not a rumor of it. When an executive asks the company’s AI assistant how churn is trending, the agent retrieves the Ossie definition from the catalog through the same MCP surface it uses for the data, computes with the endorsed formula, and can cite the definition in its answer.
Six months later, the business decides recovered payment failures should count within fourteen days, not seven. The change is a pull request against one file. It is discussed, approved, versioned, and every consumer follows automatically. That is the entire pitch of Apache Ossie compressed into one metric’s life: define once, govern once, and let every tool and every agent read the same truth.
Honest Caveats, Because Every New Project Deserves Them
The specification is young. Version 0.1 shipped in January, the metrics language is still being formalized, and the hardest semantic problems, time and windowing logic, dialect-specific expressions, composability of models across domains, are exactly the ones the working groups are still designing in the open. Companies evaluating Ossie today should read it as a direction to align with and contribute to, not a finished contract to bet a migration on this quarter.
Translation is genuinely hard. The converter strategy is the right adoption path, and it collides with reality: existing semantic dialects encode subtly different assumptions, and lossless round-tripping between a decade of proprietary formats and a young neutral one will take years of grind. The measure of Ossie’s success will be boring converter release notes, not launch announcements.
The contributor base is concentrated. Three companies dominate core development today, the proposal names this as its top incubation risk, and the ASF’s diversity requirement exists precisely to force the issue before graduation. The Polaris precedent says it can be done. The precedent is a plan, not a guarantee.
And standards can lose. Adjacent efforts, proprietary semantic layers with enormous installed bases, catalog vendors with their own business-semantics ambitions, could fragment the territory Ossie means to unify. Enterprise inertia is the strongest force in software. The grounds for optimism are the roster of competitors already inside the tent and the structural tailwind: the AI agent wave punishes semantic fragmentation more brutally every quarter, and no proprietary format can be the industry-wide answer by definition.
This is exactly why the role of semantic layers in AI enablement has become such a contentious topic. The industry is realizing that without a neutral standard, every semantic layer is just another silo.
What This Means for You
If you lead data or analytics teams, the strategic move is to start treating your semantic definitions as an exportable asset now, whatever tools you run. Inventory where your metric definitions actually live, get the twenty that matter written down precisely, put them under version control, and watch Ossie’s converter coverage for your stack. Every hour spent paying down semantic debt appreciates under any future, and it appreciates fastest under the one where your agents need it.
If you are a data engineer or analytics engineer, the on-ramp is delightfully concrete: clone apache/ossie, read the core spec, and walk the TPC-DS example, which will teach you the format in an afternoon. If your company runs dbt, the MetricFlow path means you can experiment with consuming a neutral model today.
If you build data tools or work at a vendor, the calculus is the one Iceberg taught: implementing the standard early is how you inherit the ecosystem rather than fight it. The working groups are open, with the composability and sync API efforts particularly hungry for implementer perspectives.
The Bigger Picture: Open Source Trust in an Era of Consolidation
This move to the ASF comes at a time when the broader trend of open-source trust and governance in data engineering is under serious strain. The dbt-Fivetran merger sent shockwaves through the community, raising questions about whether any vendor-led open source project can truly remain neutral. Against that backdrop, Snowflake’s decision to donate OSI to the ASF is not just commendable, it’s strategically necessary.
The arc of open data infrastructure is one sentence repeated at ascending layers: we standardized the bytes, then the files, then the tables, then the catalogs, and each time, competition moved up and users won. Apache Ossie is that sentence reaching the top of the stack, the layer where data becomes meaning, arriving at exactly the moment AI agents made ungoverned meaning too expensive to tolerate, carried by many of the same people who standardized the layers below, into the same foundation that made those standards trustworthy.
It is a young podling with a v0.1 specification, a concentrated contributor base, and everything left to prove. The story is that the last proprietary stronghold in the data stack, the definitions themselves, now has an open, neutral challenger with the right architecture, the right roster, and the right home. Semantic drift has been the quiet tax on every data team’s credibility for as long as data teams have existed. For the first time, there is a serious, community-governed plan to end it.
The project is at github.com/apache/ossie, the site is ossie.apache.org, and the dev list is open to anyone. If you have opinions about what “revenue” means, the community would like to hear them.
