The next generation of Delta Sharing, now a Linux Foundation standard for zero-copy data and AI asset sharing
First, a quiet round of applause for Databricks. OpenSharing is the kind of move that does not always make the loudest headline, but it changes how the whole industry works for years.
Databricks took Delta Sharing, the open protocol it already built for sharing data across platforms, and pushed it further. It announced OpenSharing on June 10 2026, a next-generation open standard, and donated it to the Linux Foundation. That last part matters. When a company gives a standard to a neutral foundation, it is saying the standard belongs to everyone, not to one vendor.
This article is a calm walk through what OpenSharing is, why the old way of sharing data hurts, how OpenSharing fixes it, and how you as a data engineer can actually use it. We will keep it simple and detailed at the same time.
Imagine you work at a company that needs to share a dataset with a partner. Maybe it is sales numbers for a supplier, or patient data for a research lab, or product events for an analytics vendor.
Today, sharing usually means copying.
You export the data to a file. You drop it in cloud storage. The partner downloads it, loads it into their own system, and now there are two copies of the same data living in two places. Tomorrow the data changes, and both copies drift apart.
That is the quiet tax of data movement. Every copy costs storage. Every transfer costs egress fees. Every sync adds a pipeline that can break. And every copy is a fresh place where governance and security can slip.
The real problem is not sharing. It is that sharing has always meant moving, and moving always means copies.
It gets worse across platforms. Your partner might be on a different cloud, a different warehouse, or a different vendor entirely. Now the file formats do not match, the connectors are custom, and someone spends a week writing glue code that nobody wants to own.
If you have felt this pain, the Unity Catalog lesson is where we explain how governance is supposed to work when data stays in one place. OpenSharing builds directly on that idea.
Before OpenSharing, Databricks built Delta Sharing. It was the first widely adopted open protocol for sharing live data without copying it. Delta Sharing has now evolved into OpenSharing.
The idea was simple and powerful. Instead of sending a file, you send access. The data stays where it lives. The recipient reads it directly, in place, using an open protocol that any tool can implement.
This is called zero-copy sharing. There is no second copy to keep in sync, because there is no second copy at all. The recipient always sees the current data.
Delta Sharing worked across clouds and across tools. A team on one platform could read a shared table from a provider on another platform. That alone removed a lot of pain.
But the world moved on. Teams stopped sharing only tables. They started needing to share models, AI agent skills, documents, images, and other unstructured assets. Delta Sharing was built around tabular data. The new era needed something broader.
OpenSharing is the evolution of Delta Sharing into a wider open standard, now governed by the Linux Foundation.
Keep three ideas in your head.
First, it keeps zero-copy access. Data and assets stay where they live, and recipients read them in place. No duplication, no egress-heavy transfers, no drift.
Second, it shares more than tables. OpenSharing is designed to share AI assets too. That means machine learning models, AI agent skills, and unstructured data like documents and files. In the agentic era, this is the part people are most excited about. You can let a partner or another platform use your model or your agent skill without shipping the underlying data around.
Third, it is truly open and broad. On-prem systems are supported, not just cloud. And the ecosystem around it is wide, with partners like OpenAI, SAP, Stripe, and MinIO in the mix. That breadth is what turns a protocol into a standard.
A protocol becomes a standard when enough independent players agree to speak it. OpenSharing is aiming squarely at that.
Let us make this concrete, because the magic is easy to miss.
In the old model, sharing looked like a verb you had to schedule. Extract, copy, transfer, load, repeat. A whole pipeline existed just to keep two copies in agreement.
In the OpenSharing model, sharing looks like granting access to something that already exists. The provider publishes a share. The recipient adds that share and reads from it like it was a normal table or a normal asset in their own environment.
There is no nightly job to copy the data. There is no stale snapshot. When the provider updates the source, the recipient sees the update on the next read.
If you have worked through the Delta Lake lesson, this should feel familiar. Delta tables already track versions and changes carefully. OpenSharing rides on that same foundation, so what you share is consistent and current, not a frozen export from last Tuesday.
Here is the mental model that makes OpenSharing easy to reason about.
There are two roles. A provider shares assets. A recipient reads them. You will often play both roles, sometimes in the same project.
as a provider, you decide what to expose. You group tables, models, or other assets into a share. You grant a recipient access to that share. Governance lives with the share, so you control who sees what, and you can see how it is used.
As a recipient, you register a share that someone gave you. From that point, you query the shared tables or load the shared assets as if they were part of your own catalog. Your existing notebooks and SQL keep working, because the data shows up in the familiar places.
The key shift for engineers is this. You stop writing copy pipelines for cross-team and cross-company data. Instead of building ingestion for every partner, you read a governed share. The work moves from plumbing to permissions.
This pairs naturally with the patterns in our medallion architecture lesson. Shared data can land cleanly as a trusted source, and you layer your own bronze, silver, and gold logic on top, without ever owning a stale copy of someone else's data.
If you want to see how Unity Catalog has been opening up to outside engines, our post on Unity Catalog open APIs and external access is a good companion read. OpenSharing is the sharing side of that same open direction.
Step back and look at the business picture, because this is where OpenSharing earns its keep.
Less duplication. When you stop copying data to every partner, you stop paying to store the same data many times. You also stop paying egress fees to move it around.
Faster partner onboarding. Bringing on a new partner used to mean a custom data feed and weeks of integration work. With an open standard, you publish a share and they read it. Days, not months.
Governance that holds. Because data stays in place and is shared through controlled shares, your access rules, auditing, and lineage stay intact. You are not scattering ungoverned copies across the internet. Our Unity Catalog governance lesson covers exactly why keeping one governed source matters.
Cross-platform collaboration. Your partner does not need to be on your platform. They can be on a different cloud, a different vendor, or even on-prem. An open standard meets them where they are.
And then the part that makes this a 2026 story. AI collaboration without data movement. Enterprises want to share models and agent skills with partners, or use a partner's model on their own governed data, without handing over the raw data itself. OpenSharing is built for that. If agentic AI is on your roadmap, our pieces on the AI Gateway as a control plane and on building production AI agents with Agent Bricks show where this is heading.
It is tempting to treat standards as boring. They are not. They quietly decide who has power.
When sharing depends on one vendor's private format, that vendor holds the keys. You are locked in, and so is everyone you share with. Switching costs become a wall.
An open standard governed by the Linux Foundation flips that. No single company owns it. Any tool, any cloud, any database can implement it. That neutrality is what convinces cautious enterprises and competing vendors to adopt the same protocol.
Open standards win not because they are technically perfect, but because everyone can trust that no one controls them.
This is the same story that played out with open table formats. Our post on Unity Catalog becoming a full Iceberg catalog walks through how openness in storage formats changed the game. OpenSharing is that same energy, applied to sharing.
When a standard is open and widely supported, a network effect kicks in. Each new participant makes it more useful for everyone already in. That is how a protocol quietly becomes the default way an entire industry shares data and AI.
If you remember one thing, remember this. OpenSharing turns sharing from an act of copying into an act of granting access.
Data stays put. Assets stay put. Governance stays put. What travels is permission, not duplication.
For you as a data engineer, that means fewer brittle copy pipelines and more time on real work. For your enterprise, it means lower cost, faster partnerships, and AI collaboration that does not require giving away your data. For the industry, it means a shared language for sharing, owned by no one and usable by all.
That is a rare combination, and it is worth being excited about.
Let us picture a small, real example, the kind you might actually meet.
Your company sells products online. A logistics partner needs your daily shipment events so they can plan delivery routes. In the old world, you would build an export job. Every night it writes a file, pushes it to shared storage, and the partner pulls it in. Two copies, one pipeline, plenty of ways to break.
With OpenSharing, the shape of the work changes.
You create a share that contains your shipment events table. You grant the logistics partner access to that share. That is the provider side, and it is mostly about permissions, not pipelines.
On the partner side, they register the share you gave them. The shipment events show up in their environment like a normal table. They query it directly. When your data updates during the day, their next query sees the fresh rows. No nightly file, no waiting, no drift.
Now extend the story into the AI era. Suppose you also trained a small model that scores delivery risk. With OpenSharing, you can share that model as an asset too. The partner can use your model on their side, without you shipping the raw training data along with it. The value moves, the sensitive data stays home.
That is the quiet superpower here. You share exactly what you mean to share, and nothing more.
A few questions come up almost every time this topic lands on a team.
Is the recipient seeing live data or a snapshot? Live, in the sense that each read returns the current state. There is no copy sitting on their side going stale.
Do both sides need to use the same platform? No. That is the whole point of an open standard. A provider on one platform can share with a recipient on another, including on-prem systems.
What about security and governance? Access flows through controlled shares. You decide who gets which share, and you keep your auditing and lineage. Sharing does not mean losing control. Our Unity Catalog lesson explains the governance model that sits underneath.
Does this replace pipelines entirely? No, and that is fine. You still build pipelines to clean, join, and shape data. What goes away is the copy-and-ship pipeline whose only job was to move data to someone else. You spend that saved time on real engineering.
A new standard is a journey, not a switch you flip. A few things are worth watching with calm eyes.
Watch the ecosystem. A standard is only as strong as the tools that speak it. The early list of partners is broad, and the Linux Foundation home gives it a neutral center. The more independent adopters, the stronger it gets.
Watch the asset types. Sharing tables is well understood. Sharing models, agent skills, and unstructured data is newer ground. Expect the patterns and best practices to mature over the next while.
Watch your own habits. The biggest change is mental. Once your team trusts that sharing means granting access, not copying, you start designing differently. You stop reaching for an export job by reflex.
None of this needs to happen overnight. Learn the foundations, try a small share, and grow from there.
OpenSharing sits on top of ideas we teach throughout BricksNotes. If you want the foundations underneath it, these are the natural next steps.
Start with the Delta Lake lesson to understand the storage layer that makes zero-copy sharing safe. Then move to the Unity Catalog lesson to see how governance and access control hold everything together. Finish with the medallion architecture lesson to see how shared data fits into a clean, layered pipeline.
When you understand those three, OpenSharing stops feeling like a headline and starts feeling like an obvious next step. Take it slow, build something small, and let the idea settle. That is the BricksNotes way.