Platforms

Open Semantic Interchange became Apache Ossie: fifty logos, one YAML file, verdict pending

The semantic-layer interchange standard has a real spec, a real Apache incubator and a real gap between signing and shipping. We read the YAML so you can read the roadmaps.

By The editors · · 3 min

A standards initiative is reviewable the day it produces an artifact. Open Semantic Interchange produced one: a first specification, published January 27, defining a vendor-neutral YAML representation for the semantic layer's working parts: datasets, metrics, fields, relationships. It has since acquired a different name, which we will come to. We have read the spec. This is the review.

Illustrative chart of vendors announcing OSI support versus vendors shipping native support

First, the case for taking it seriously, which is stronger than the usual consortium press release earns. The member list now covers most names a data platform buyer would recognize, and crucially it includes direct competitors: Snowflake started the initiative and Databricks joined anyway, alongside AtScale, Qlik, Coalesce and the BI mid-field. Standards die when the second-largest vendor abstains. This one has the awkward guests at the table, which is the sign of a party worth attending.

Then, in July, it did the thing consortia usually only promise. The project was donated to the Apache Software Foundation and renamed Ossie, entering the incubator on July 10, with contributors from Snowflake, Dremio, Salesforce, Databricks, dbt Labs, RelationalAI, GoodData and Honeydew, and the launch coalition of 17 grown past 50 organizations. The rename exists because too many things in open source already answer to OSI. The donation matters more than the name: vendor-neutral governance stopped being a sentence in a Snowflake blog post and became a mailing list, a public repository and a vote you can lose.

Second, what the artifact actually is. The spec, now at github.com/apache/ossie, is a declarative YAML and JSON format: define a metric once, with the fields and relationships it rests on, and any conforming tool can read the definition. If you have ever re-implemented "net revenue" in four BI tools and gotten three answers, this is aimed at you, and the aim is correct. The metric definition is the most re-typed artifact in analytics, and the re-typing is where the numbers diverge.

Now the gap, because there is one and it is load-bearing. A published spec is not the same thing as native support, and the version number is still below 1.0. What ships in the repository today is a set of reference converters, translating between Ossie and dbt, GoodData, Polaris and Salesforce. A converter is a bridge somebody else maintains. It is not an import button in the tool you already pay for. The roadmap past that point runs to an expression language, metric logic, further converters and a semantic query specification, every item of it subject to a community vote rather than a ship date, which is exactly what good governance costs. Announced membership and shipped support are different populations, as our first chart illustrates. The chart is illustrative; the pattern it draws is not. We have covered this distance before in the semantic layer reality check, and the distance has a habit of being measured in years.

There is also the quieter question of what travels and what stays. The YAML carries definitions. It does not carry the query planner that makes them fast, the caching that makes them cheap, or the governance hooks that decide who sees the metric at all. Portability of definition is real value; it is also the layer vendors can afford to give away, precisely because the layers underneath still hold you. Read the second chart before writing "no lock-in" in any deck.

Illustrative chart of which semantic layer components the OSI YAML carries and which stay with the vendor

So, verdicts, plural, because this one splits cleanly.

As an export format and a hygiene practice: worth adopting now. Keep your semantic definitions in the interchange format, or demand an export path to it from whatever tool holds them. The cost is small, the downside is nil, and on the day you switch BI tools you will write us a thank-you letter.

As an interoperability promise, the "define once, run anywhere" future in the launch materials: wait. Wait specifically for two shipping native implementations you can round-trip a real model between, then test the round trip with your own gnarliest metric, the one with the fiscal-calendar join. If it survives, adopt with our blessing. If the industry's history of interchange formats is any guide, budget for "mostly survives".

Fifty logos signed a YAML file, then handed it to a foundation. That is genuinely more than most standards achieve, and genuinely less than the press releases imply. Both clauses are the review.